Votre modèle de données pour la gestion des sinistres
Votre modèle de données pour la gestion des sinistres
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d’extraction pour Guidewire ClaimCenter
Attributs de la Gestion des sinistres
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Date et heure précises auxquelles l’activité s’est produite. | ||
| Description Cet horodatage indique le moment exact où l’activité a été enregistrée dans le système. Il est indispensable à toute analyse temporelle des processus. Le classement chronologique des valeurs EventTime pour un Claim ID donné permet de reconstituer le flux du processus. L’écart entre deux événements consécutifs sert à calculer les délais de cycle, les temps d’attente et les temps de traitement, qui sont essentiels pour analyser la performance, identifier les goulots d’étranglement et suivre les SLA. Pourquoi c’est important Cet horodatage est essentiel pour ordonner les événements, calculer les délais de cycle et les durées, et identifier les retards dans le processus. Où les obtenir Il se trouve avec les données d’événements ou d’activités dans les tables d’historique ou d’audit de Guidewire ClaimCenter, souvent sous la forme d’un champ « CreateTime » ou « UpdateTime ». Exemples 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| Identifiant du sinistre ClaimID | Identifiant unique de chaque sinistre d’assurance, utilisé comme identifiant principal du dossier. | ||
| Description Le Claim ID est la clé de voûte de l’analyse du processus de gestion des sinistres. Il identifie de manière unique chaque dossier, de sa soumission à sa clôture. Il relie toutes les activités, tous les documents, paiements et échanges associés, afin de fournir une vision complète et cohérente du cycle de vie du sinistre. Dans le Process Mining, chaque événement du jeu de données est associé à un Claim ID, ce qui permet de reconstituer le flux du processus de bout en bout. Cette association est essentielle pour analyser les délais de cycle, identifier les variantes du processus et suivre le parcours d’un sinistre entre les différents services et gestionnaires. Pourquoi c’est important Il s’agit de la clé fondamentale qui relie tous les événements associés et permet de retracer et d’analyser l’intégralité du parcours d’un sinistre donné. Où les obtenir Il s’agit d’une clé primaire dans Guidewire ClaimCenter, généralement présente sous la forme de Claim.ClaimNumber ou d’un champ similaire dans l’entité Claim principale. Exemples 000-123-45678000-987-65432001-456-11223 | |||
| Nom de l’activité ActivityName | Nom de l’activité métier ou de l’événement survenu à un moment précis du cycle de vie du sinistre. | ||
| Description Cet attribut décrit une étape ou une étape clé précise du processus de gestion des sinistres, comme « Claim Created », « Investigation Started » ou « Payment Issued ». La séquence de ces activités pour un Claim ID donné constitue le flux du processus. L’analyse de la séquence, de la fréquence et de la durée entre les activités est au cœur du Process Mining. Elle permet de découvrir les modèles de processus, d’identifier les goulots d’étranglement, de détecter les boucles de reprise et d’analyser les écarts du processus. Pourquoi c’est important Il définit les étapes du processus et permet de visualiser les cartes de processus, ainsi que d’analyser le flux et les goulots d’étranglement. Où les obtenir Il est généralement dérivé des tables d’événements ou des journaux d’audit de ClaimCenter, souvent en associant certains événements système ou changements de statut à des noms d’activité standardisés. Exemples Sinistre crééDécision de responsabilité prisePaiement émisSinistre clôturé | |||
| Cause du sinistre LossCause | Raison ou cause précise de l’événement à l’origine du dommage, par exemple collision, incendie ou dégât des eaux. | ||
| Description Cet attribut fournit un contexte détaillé sur la raison de la déclaration du sinistre. La cause du dommage détermine souvent les étapes d’instruction nécessaires, le type d’experts à mobiliser et la complexité globale du sinistre. L’analyse du processus par cause du sinistre peut révéler des tendances difficiles à détecter. Par exemple, les sinistres liés à un « dégât des eaux » peuvent présenter davantage de reprises ou nécessiter l’intervention de spécialistes plus souvent que les sinistres liés à un « vol ». Ces analyses contribuent à concevoir des procédures de traitement plus spécialisées et plus efficaces. Pourquoi c’est important Fournit un contexte sur la nature du sinistre et permet d’analyser l’incidence des différentes causes sur le déroulement et la durée du processus. Où les obtenir Il s’agit d’un champ standard de l’entité Claim, généralement nommé « LossCause ». Exemples CollisionIncendieDégât des eauxVol | |||
| Gestionnaire de sinistre affecté AssignedAdjuster | Nom ou identifiant de l’utilisateur chargé de traiter le sinistre ou une activité donnée. | ||
| Description Cet attribut identifie le gestionnaire de sinistre responsable d’un dossier à un moment donné. Un gestionnaire peut être affecté à l’ensemble du sinistre ou à certaines tâches seulement. L’analyse par gestionnaire de sinistre affecté est essentielle pour équilibrer la charge de travail, suivre les performances et repérer les besoins de formation. Elle permet notamment de répondre aux questions suivantes : « Quels gestionnaires ont le plus grand nombre de dossiers ? », « Existe-t-il des écarts de performance entre les gestionnaires ? » et « La charge de travail est-elle répartie équitablement ? » Pourquoi c’est important Suit l’implication des utilisateurs et permet d’analyser la charge de travail, de comparer les performances et d’identifier les goulots d’étranglement liés aux ressources. Où les obtenir Disponible dans l’entité Claim ou Exposure de ClaimCenter, souvent associé à l’objet User, par exemple Claim.Assignee. Exemples j.doem.smiths.jones | |||
| Statut du sinistre ClaimStatus | Statut global du sinistre au moment de l’événement, par exemple ouvert, clôturé ou refusé. | ||
| Description Cet attribut reflète l’état général du sinistre. Les principaux statuts sont « Open », « Closed », « Denied » et « Reopened ». Le statut final d’un sinistre constitue un indicateur de résultat essentiel. Le suivi des changements de statut du sinistre permet de définir les principales étapes et les résultats du processus. Il sert à identifier la résolution finale d’un sinistre, à calculer les taux de refus et à analyser la fréquence des réouvertures après clôture, qui peut révéler des problèmes de processus ou une insatisfaction des clients. Pourquoi c’est important Indique le résultat d’un sinistre, ce qui est essentiel pour analyser les taux de refus, les schémas de clôture et la fréquence des réouvertures. Où les obtenir Il s’agit d’un champ central de l’entité Claim, généralement nommé « State » ou « Status ». Exemples OuvertClôturéRefuséRouverte | |||
| Type de sinistre ClaimType | Catégorie du sinistre d’assurance, par exemple automobile, habitation ou responsabilité civile. | ||
| Description Le type de sinistre constitue une catégorisation fondamentale fondée sur la branche d’activité ou la nature du dommage. Les différents types de sinistres suivent souvent des processus distincts, présentent des niveaux de complexité différents et sont soumis à des réglementations spécifiques. La segmentation de l’analyse du processus par type de sinistre est essentielle pour obtenir des résultats pertinents. Elle permet de comparer les performances entre différentes branches d’activité, d’identifier les goulots d’étranglement propres à chaque type et d’adapter les initiatives d’amélioration aux caractéristiques de chaque catégorie de sinistre. Pourquoi c’est important Permet de segmenter les sinistres, car les différents types, par exemple automobile et habitation, suivent souvent des processus distincts et répondent à des objectifs de performance différents. Où les obtenir Dérivé de l’entité Policy ou Claim dans ClaimCenter, souvent à partir du code Line of Business (LOB). Exemples Automobile particulièreDommages aux biens professionnelsResponsabilité civile généraleAccidents du travail | |||
| Date cible de résolution ResolutionTargetDate | Date à laquelle le sinistre doit être résolu conformément aux SLA internes ou réglementaires. | ||
| Description La date cible de résolution correspond à l’échéance fixée pour la clôture du sinistre. Elle est souvent déterminée par la juridiction, le type de sinistre et les conditions de la police. Elle sert de référence pour mesurer les performances et la conformité. Cet attribut est essentiel à la création de Dashboards et de KPI de respect des SLA. En comparant la date réelle de clôture du sinistre à cette date cible, l’analyse peut signaler automatiquement les sinistres en retard, mesurer le taux de respect des délais et identifier les types de sinistres ou les services qui peinent à atteindre leurs objectifs. Pourquoi c’est important Constitue la référence pour mesurer le respect des Service Level Agreements (SLA) et identifier les sinistres susceptibles d’être traités en retard. Où les obtenir Il peut s’agir d’un champ personnalisé ou d’une valeur dérivée de règles métier configurées dans ClaimCenter, éventuellement liées à des indicateurs spécifiques des sinistres. Exemples 2023-06-142023-07-202023-08-28 | |||
| Date du sinistre LossDate | Date à laquelle s’est produit l’incident ou le dommage à l’origine du sinistre. | ||
| Description La date du sinistre correspond à la date de l’événement réel, par exemple un accident de voiture ou un dommage matériel, à l’origine de la déclaration. Elle se distingue de la date de déclaration ou de création du sinistre. Le délai entre la date du sinistre et l’activité « Claim Created », appelé délai de déclaration, constitue un KPI important. Son analyse peut fournir des indications sur le comportement des clients et sur l’efficacité des canaux de première déclaration de sinistre. Pourquoi c’est important Fournit un contexte essentiel sur l’origine du sinistre et permet d’analyser le délai de déclaration, c’est-à-dire le temps écoulé entre l’incident et la déclaration. Où les obtenir Il s’agit d’un champ de date fondamental de l’entité Claim, souvent nommé « LossDate ». Exemples 2023-05-102023-04-202023-05-28 | |||
| Demande d’informations répétée RepeatedInfoRequestFlag | Indicateur précisant si « Additional Info Requested » s’est produit plusieurs fois pour le même sinistre. | ||
| Description Cet indicateur booléen prend la valeur true lorsqu’un sinistre comporte plusieurs activités « Additional Info Requested ». Cette situation révèle souvent des inefficacités lors de la collecte initiale des informations. Cet attribut alimente directement le KPI « Repeated Info Request Rate ». Il permet de quantifier les lacunes de la collecte initiale des faits, susceptibles d’entraîner des retards importants et de mécontenter les clients. L’analyse des sinistres associés à cet indicateur peut contribuer à améliorer les listes de contrôle et les procédures des gestionnaires afin que toutes les informations nécessaires soient demandées dès le départ. Pourquoi c’est important Identifie les inefficacités liées à une collecte d’informations incomplète au premier passage, qui entraîne des retards et des reprises dans le processus. Où les obtenir Calculé dans l’outil de Process Mining en comptant les occurrences de l’activité « Additional Info Requested » pour chaque cas. Exemples truefalse | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation ou extraction des données depuis le système source. | ||
| Description Cet attribut fournit l’horodatage de l’extraction la plus récente des données depuis le système source. Il s’agit d’un champ de métadonnées essentiel pour évaluer la fraîcheur de l’analyse. Les Dashboards et les analyses doivent afficher cette information de manière visible afin que les utilisateurs connaissent l’actualité des données. Elle permet de déterminer si les analyses reflètent l’état actuel des opérations ou si elles reposent sur des données plus anciennes. Pourquoi c’est important Indique la fraîcheur des données afin que les utilisateurs sachent dans quelle mesure l’analyse du processus est à jour. Où les obtenir Cette valeur est générée et enregistrée pendant le processus ETL. Elle correspond à l’horodatage du chargement des données. Exemples 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
| Est automatisé IsAutomated | Indicateur précisant si une activité a été exécutée automatiquement par le système ou par un utilisateur humain. | ||
| Description Cet attribut booléen distingue les activités exécutées par le système, par exemple la création automatique d’une provision ou la génération d’une correspondance, de celles réalisées manuellement par un gestionnaire de sinistre. Son analyse est essentielle pour comprendre le niveau d’automatisation du processus de gestion des sinistres. Elle permet d’identifier les points nécessitant une intervention manuelle, de mesurer l’efficacité des initiatives de traitement automatisé de bout en bout et de repérer de nouvelles possibilités d’automatisation en ciblant les tâches répétitives fondées sur des règles qui sont encore réalisées par des personnes. Pourquoi c’est important Distingue les activités pilotées par le système de celles réalisées par des personnes, ce qui est essentiel pour analyser l’automatisation et identifier les goulots d’étranglement manuels. Où les obtenir Cette valeur doit souvent être déduite. Par exemple, les événements enregistrés par un utilisateur générique « system » peuvent être considérés comme automatisés. Exemples truefalse | |||
| Est une reprise IsRework | Indicateur précisant si une activité correspond à une boucle de reprise, c’est-à-dire à un retour à une étape précédente du processus. | ||
| Description Cet attribut calculé signale les activités qui font partie d’une boucle de reprise. Par exemple, si le processus passe de « Investigation Completed » à « Investigation Started », la seconde activité « Investigation Started » est signalée comme une reprise. L’identification des reprises est fondamentale pour révéler les inefficacités du processus et les problèmes de qualité. Le Dashboard « Rework and Rejection Frequency » s’appuie sur cette mesure pour quantifier la fréquence à laquelle les sinistres s’écartent du parcours nominal. L’analyse des causes des reprises peut entraîner des améliorations importantes de la qualité et de la rapidité du processus. Pourquoi c’est important Met en évidence les inefficacités du processus et les problèmes de qualité en signalant explicitement les activités qui font partie d’une boucle de reprise. Où les obtenir Cette valeur est calculée dans l’outil de Process Mining en analysant la séquence des activités pour chaque cas. Exemples truefalse | |||
| Heure de fin EndTime | Horodatage indiquant la fin d’une activité. | ||
| Description L’heure de fin marque l’achèvement d’une activité, en particulier pour les tâches dont la durée peut être mesurée, comme « Investigation » ou « Document Review ». De nombreuses activités de Process Mining sont instantanées, et StartTime suffit alors. En revanche, les activités qui comportent un début et une fin distincts sont mieux représentées par les deux horodatages. Cet attribut permet de calculer précisément le temps de traitement d’une activité, indépendamment du temps d’attente. Il aide à identifier les tâches qui prennent réellement du temps, plutôt que de simplement constater de longs délais entre différentes étapes. Pourquoi c’est important Permet de mesurer précisément le temps nécessaire à l’achèvement d’une activité, en distinguant le temps de traitement du temps d’attente. Où les obtenir Cette valeur peut devoir être déduite en recherchant un événement ultérieur qui clôt logiquement l’activité, par exemple le passage du statut « In Progress » à « Completed ». Exemples 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
| Juridiction compétente JurisdictionState | État ou juridiction régissant le sinistre et déterminant les exigences réglementaires applicables. | ||
| Description Cet attribut précise la juridiction légale, par exemple l’État américain, dans laquelle le sinistre est traité. Les réglementations d’assurance peuvent varier considérablement d’une juridiction à l’autre et avoir une incidence sur les étapes requises, les délais de communication et les documents à fournir. Cet attribut est essentiel au suivi de la conformité. L’analyse du processus par juridiction permet de vérifier le respect des exigences réglementaires propres à chaque État. Elle peut également expliquer les variations de durée de traitement ou de parcours du processus qui résultent de contraintes légales plutôt que d’une inefficacité opérationnelle. Pourquoi c’est important Essentiel à l’analyse de la conformité, car les différentes juridictions appliquent des réglementations distinctes qui influencent le traitement des sinistres. Où les obtenir Champ standard de l’entité Claim, généralement nommé « JurisdictionState ». Exemples CANYTXFL | |||
| Montant déclaré ClaimedAmount | Montant total initialement réclamé par le titulaire de la police. | ||
| Description Cet attribut représente la valeur du dommage déclarée par le demandeur. Il s’agit souvent d’une première estimation, susceptible d’évoluer au cours de l’instruction du sinistre et de la constitution des provisions. L’analyse du montant déclaré permet de segmenter les sinistres selon leur impact financier. Les sinistres de montant élevé suivent souvent un processus plus rigoureux et plus complexe que ceux de faible montant. La comparaison des processus par tranche de valeur peut révéler des possibilités de simplification pour les petits sinistres ou justifier des contrôles plus stricts pour les montants élevés. Pourquoi c’est important Permet de segmenter les sinistres selon leur valeur financière, car les sinistres de montant élevé peuvent suivre des processus différents et plus complexes. Où les obtenir Cette information peut ne pas correspondre à un champ unique. Elle peut être déduite des premières estimations du dommage enregistrées dans les objets Exposure. Exemples 5000.00150000.00750.50 | |||
| Montant du paiement PaymentAmount | Montant effectivement versé pour une activité de paiement. | ||
| Description Cet attribut enregistre la valeur de chaque paiement effectué au titre d’un sinistre. Un même sinistre peut donner lieu à plusieurs paiements au cours de son cycle de vie. Il est essentiel à l’analyse financière dans le contexte du Process Mining. Il permet de suivre le montant total versé par sinistre, d’analyser les délais d’approbation des paiements selon leur montant et de mettre en relation les inefficacités du processus avec les résultats financiers. Par exemple, les sinistres dont le cycle est long peuvent être associés à des montants totaux plus élevés. Pourquoi c’est important Suit les transactions financières liées à un sinistre et permet d’analyser les montants des paiements ainsi que leur relation avec les activités du processus. Où les obtenir Se trouve dans les entités liées aux paiements et associées au sinistre, souvent dans une table de transactions ou de chèques. Exemples 4500.00125000.00500.00 | |||
| Service Department | Unité opérationnelle ou service chargé de traiter l’activité liée au sinistre. | ||
| Description Cet attribut indique le service ou l’équipe auquel appartient le gestionnaire de sinistre affecté, par exemple « Auto Claims », « Property Claims » ou « Special Investigations Unit ». Il fournit un contexte organisationnel au processus. L’analyse par service est essentielle pour comprendre les performances du processus à l’échelle de l’organisation. Elle permet d’identifier les délais lors des transferts entre services, de comparer l’efficacité des équipes et de répartir plus efficacement les ressources au sein de l’organisation chargée des sinistres. Pourquoi c’est important Fournit un contexte organisationnel qui permet d’analyser les performances de différentes équipes et de mettre en évidence les problèmes liés aux transferts entre services. Où les obtenir Ces informations sont généralement associées au profil de l’utilisateur ou du groupe affecté dans ClaimCenter. Exemples Division des sinistres automobilesUnité des sinistres dommages aux biensUnité des enquêtes spéciales (SIU) | |||
| Statut du SLA SLAState | Indique si le sinistre a été clôturé dans le délai cible de résolution. | ||
| Description Cet attribut calculé fournit, pour chaque sinistre clôturé, un statut catégoriel de respect du SLA. Il est obtenu en comparant l’horodatage de l’activité « Claim Closed » à la « Resolution Target Date ». Cet attribut alimente directement le Dashboard « Claim Resolution Target Adherence » en simplifiant l’analyse au moyen de catégories claires telles que « On Time » ou « Late ». Il facilite le filtrage et l’agrégation nécessaires au calcul du taux global de respect des SLA, ainsi que l’analyse détaillée des causes des retards. Pourquoi c’est important Fournit un résultat catégoriel clair sur le respect des SLA et facilite le filtrage, l’agrégation et l’analyse des performances dans les délais. Où les obtenir Champ calculé : IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late'). Exemples Dans les délaisEn retard | |||
| Système source SourceSystem | Système à partir duquel les données ont été extraites. | ||
| Description Cet attribut identifie l’origine des données d’événements. Dans un environnement d’entreprise moderne, les événements liés aux sinistres peuvent provenir de plusieurs systèmes, comme un système central tel que Guidewire, un système de gestion documentaire ou un portail client. La précision du système source est essentielle pour la gouvernance des données, le diagnostic des incohérences et la compréhension de l’environnement technologique du processus. Elle permet de distinguer les étapes du processus principal des activités de support réalisées dans des systèmes périphériques. Pourquoi c’est important Il identifie l’origine des données, ce qui est essentiel pour la gouvernance des données et les analyses portant sur plusieurs systèmes intégrés. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) des données. Exemples Guidewire ClaimCenter v10API du portail clientDocumentum | |||
| Type de police PolicyType | Type précis de police d’assurance au titre de laquelle le sinistre a été déclaré. | ||
| Description Le type de police fournit une classification plus détaillée que le type de sinistre en précisant le produit d’assurance concerné, par exemple « Homeowners », « Commercial Auto » ou « Cyber Liability ». Ce niveau de détail peut révéler des variations de processus liées à certains produits. L’analyse du processus par type de police aide à repérer les inefficacités propres à certains produits. Par exemple, les sinistres liés à une police récemment lancée peuvent suivre un processus moins mature et entraîner des retards. Cette analyse peut guider la conception des produits et les efforts de standardisation des processus. Pourquoi c’est important Permet d’analyser le processus pour des produits d’assurance précis et d’identifier les différences de traitement liées aux caractéristiques des polices. Où les obtenir Ces informations se trouvent dans l’entité Policy, qui est liée à Claim. Exemples Multirisque habitationResponsabilité civile automobile professionnelleTransport maritime intérieur | |||
Activités de la Gestion des sinistres
| Activité | Description | ||
|---|---|---|---|
| Exposition créée | Cette activité correspond à la création d’une exposition, qui représente un engagement potentiel précis ou un type de perte couvert par le sinistre, par exemple des dommages au véhicule ou des blessures. Il s’agit d’un événement explicite dans Guidewire. | ||
| Pourquoi c’est important Les expositions sont fondamentales pour segmenter et analyser les sinistres. Le suivi de leur création permet de comprendre les variations du processus selon la complexité du sinistre et le type de perte. Où les obtenir L’événement est extrait du CreateTime d’un nouvel enregistrement dans la table cc_exposure. Chaque enregistrement est rattaché à un Claim ID unique. Collecte Identifiez l’horodatage de création d’un nouvel enregistrement dans la table de l’entité Exposure. Type d’événement explicit | |||
| Paiement approuvé | Cette activité représente l’approbation officielle d’un paiement de règlement. Il s’agit d’un événement d’audit important, enregistré explicitement lorsqu’un utilisateur habilité approuve la transaction. | ||
| Pourquoi c’est important Cette étape clé débloque l’étape finale du paiement. L’analyse du temps avant et après cette activité permet d’isoler les retards liés aux flux de travail d’approbation ou à la disponibilité des responsables. Où les obtenir Il s’agit souvent d’un événement explicite enregistré dans la table cc_history et lié à une entité cc_check ou cc_transaction, qui consigne le changement de statut de « Pending Approval » à « Approved ». Collecte Suivez l’événement de changement de statut vers « Approved » pour une transaction de paiement donnée. Type d’événement explicit | |||
| Paiement émis | Cette activité marque la dernière étape du processus de paiement, lorsque le paiement est officiellement émis et transmis au système financier. Il s’agit d’une transaction financière explicite et enregistrée. | ||
| Pourquoi c’est important Cette activité est essentielle pour mesurer l’efficacité du processus d’émission des paiements. Elle permet de distinguer les retards d’approbation des retards liés à l’émission effective des fonds. Où les obtenir L’événement est extrait de l’IssueDate ou d’un changement de statut vers « Issued » ou « Submitted » sur l’entité cc_check ou cc_transaction. Il s’agit souvent d’un événement explicite horodaté. Collecte Identifiez l’IssueDate ou l’horodatage du changement de statut vers « Issued » sur l’enregistrement du paiement. Type d’événement explicit | |||
| Réserve initiale définie | Cette activité marque la création de la première transaction de réserve financière pour une exposition, afin d’estimer le coût potentiel du sinistre. Il s’agit d’un événement financier important, enregistré explicitement. | ||
| Pourquoi c’est important Cette étape est essentielle pour l’analyse financière et pour comprendre la rapidité avec laquelle l’engagement potentiel est évalué. Les retards peuvent avoir une incidence sur la planification et le reporting financiers. Où les obtenir L’événement est extrait de la création du premier enregistrement cc_reserveline associé à une exposition du sinistre. Le CreateTime de la transaction constitue l’horodatage de l’événement. Collecte Trouvez l’horodatage de création minimal de toutes les lignes de réserve associées aux expositions d’un sinistre donné. Type d’événement explicit | |||
| Sinistre clôturé | Cette activité marque la clôture réussie d’un sinistre, une fois toutes les activités et tous les paiements terminés. Il s’agit du principal événement de fin réussi, déduit d’un changement du statut principal du sinistre. | ||
| Pourquoi c’est important En tant qu’événement de fin principal, cette activité est essentielle pour calculer le délai de cycle de bout en bout et mesurer le respect des SLA. Elle signale la fin du cycle de vie du sinistre. Où les obtenir L’événement est déduit du changement du champ State de la table cc_claim vers « Closed ». L’horodatage de l’événement est le CloseDate de l’enregistrement du sinistre. Collecte Identifiez le moment où le champ de statut principal du sinistre est mis à jour vers « Closed ». Type d’événement inferred | |||
| Sinistre créé | Cette activité correspond à la première déclaration de sinistre (FNOL) et à la création officielle d’un nouveau dossier de sinistre dans Guidewire ClaimCenter. Elle est enregistrée explicitement lorsqu’une nouvelle entité Claim est sauvegardé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 délai de cycle de bout en bout du sinistre. Elle constitue la référence pour tous les KPI ultérieurs de performance et de durée. Où les obtenir Il s’agit d’un événement explicite extrait du CreateTime de la table cc_claim. La création d’un nouvel enregistrement doté d’un Claim ID unique déclenche l’événement. Collecte Identifiez l’horodatage de création du nouvel enregistrement dans la table de l’entité Claim principale. Type d’événement explicit | |||
| Sinistre refusé | Cette activité représente la décision finale de refuser un sinistre et constitue le point terminal du processus. L’événement est déduit du passage du statut du sinistre à un état fermé, avec le motif « Denied ». | ||
| Pourquoi c’est important Il s’agit d’un événement de résultat important. L’analyse de la fréquence des refus, de leurs motifs et des parcours qui y mènent permet d’identifier les problèmes liés à la réception du sinistre, à l’instruction ou à l’interprétation de la police. Où les obtenir L’événement est déduit du changement du champ State de la table cc_claim vers « Closed », associé à la valeur « Denied » ou à une valeur similaire dans le champ CloseReason. L’horodatage de l’événement est le CloseDate. Collecte Filtrez les changements de statut des sinistres vers « Closed » lorsque le code motif indique un refus. Type d’événement inferred | |||
| Décision de responsabilité prise | Cette activité indique le moment où la décision concernant la responsabilité ou la faute a été prise pour une exposition. L’événement est généralement déduit d’un changement de statut de l’entité Exposure. | ||
| Pourquoi c’est important Il s’agit d’une étape de décision essentielle, qui conditionne les phases de règlement et de paiement. L’analyse du délai nécessaire pour parvenir à cette décision permet d’identifier les goulots d’étranglement lors de l’instruction et de l’évaluation. Où les obtenir L’événement est déduit de la table cc_history en suivant une modification du champ State ou d’un champ personnalisé de statut de responsabilité sur l’entité cc_exposure. L’horodatage de l’enregistrement d’historique indique le moment de l’événement. Collecte Surveillez les journaux d’audit ou les tables d’historique pour détecter les mises à jour de l’état ou du statut de responsabilité de l’exposition. Type d’événement inferred | |||
| Informations complémentaires demandées | Cette activité représente une demande envoyée au déclarant ou à un tiers pour obtenir des informations ou des documents supplémentaires. Elle est généralement enregistrée comme une Activity, c’est-à-dire une tâche créée dans ClaimCenter. | ||
| Pourquoi c’est important Cette activité constitue le point de départ du KPI « Additional Info Gathering Cycle Time ». Une fréquence élevée peut signaler des processus FNOL incomplets ou une collecte d’informations inefficace. Où les obtenir L’événement est extrait du CreateTime d’un enregistrement cc_activity dont l’ActivityPattern concerne une demande de documents ou d’informations auprès d’un tiers. Collecte Identifiez la création d’une tâche destinée à demander des informations externes. Type d’événement explicit | |||
| Informations complémentaires reçues | Cette activité marque la clôture d’une demande d’informations complémentaires. Elle est enregistrée lorsque l’Activity correspondante, c’est-à-dire la tâche de demande d’informations, est marquée comme « Completed ». | ||
| Pourquoi c’est important Il s’agit du point final du KPI « Additional Info Gathering Cycle Time ». Les délais importants entre la demande et la réception sont une source fréquente de retard dans le traitement des sinistres. Où les obtenir L’événement est extrait du CloseTime d’un enregistrement cc_activity dont l’ActivityPattern concerne une demande d’informations. Le statut de l’activité doit être « Completed ». Collecte Identifiez l’horodatage d’achèvement d’une tâche destinée à demander des informations externes. Type d’événement explicit | |||
| Instruction commencée | Cette activité indique le début officiel de la phase d’instruction d’un sinistre ou d’une exposition. Elle est souvent déduite de la création de la première Activity liée à l’instruction dans Guidewire. | ||
| Pourquoi c’est important Cette activité marque le début d’une phase essentielle, souvent longue. L’analyse du délai avant le début de l’instruction et de sa durée permet de révéler les principaux goulots d’étranglement. Où les obtenir L’événement est déduit du CreateTime d’un enregistrement cc_activity dont l’ActivityPattern est lié à l’instruction, par exemple « Initial Investigation » ou « Contact Witness ». Collecte Identifiez la première création d’une tâche dont le modèle ou l’objet est lié à l’instruction. Type d’événement inferred | |||
| Montant du règlement calculé | Cette activité correspond au moment où le montant du règlement a été déterminé, mais pas encore approuvé pour paiement. Elle peut être déduite de la création d’un paiement à l’état « Pending Approval ». | ||
| Pourquoi c’est important Elle marque le passage de l’évaluation au paiement. Elle constitue le point de départ du KPI « Payment Authorization Lead Time » et permet de repérer les retards dans la chaîne d’approbation. Où les obtenir L’événement est déduit du CreateTime d’un enregistrement cc_check ou cc_transaction dont le statut initial est « Pending Approval » ou un état similaire précédant « Approved ». Collecte Identifiez la création d’un enregistrement de paiement ou de transaction dans un statut préalable à l’approbation. Type d’événement inferred | |||
| Sinistre attribué | Cette activité représente l’attribution d’un sinistre à un utilisateur précis, généralement un gestionnaire de sinistres, ou à un groupe chargé de son traitement. Elle est généralement déduite du suivi des modifications apportées aux champs d’attribution de l’entité Claim. | ||
| Pourquoi c’est important Le suivi des attributions est essentiel pour analyser la charge de travail des gestionnaires de sinistres, repérer les goulots d’étranglement dans l’orientation des dossiers et mesurer le délai avant la première intervention du responsable désigné. Où les obtenir L’événement est déduit de la table cc_history en suivant les modifications des champs AssignedUser ou AssignedGroup associés à un Claim ID précis. L’horodatage de la modification indique le moment où l’événement s’est produit. Collecte Surveillez les journaux d’audit ou les tables d’historique pour détecter les mises à jour des champs d’attribution du sinistre. Type d’événement inferred | |||
| Sinistre rouvert | Cette activité représente le passage d’un sinistre de l’état « Closed » à l’état « Open » afin d’effectuer des travaux supplémentaires. L’événement est déduit d’une séquence précise de changements de statut. | ||
| Pourquoi c’est important Cette activité signale une reprise du traitement. Un volume élevé de sinistres rouverts peut indiquer des problèmes liés au règlement initial, des dommages non pris en compte ou d’autres défaillances du processus, avec à la clé une hausse des coûts et une baisse de l’efficacité. Où les obtenir L’événement est déduit de la table cc_history en identifiant le passage du champ State de l’entité cc_claim de « Closed » à « Open » ou à un autre état actif. Collecte Surveillez le champ de statut principal du sinistre pour détecter le passage d’un état fermé à un état ouvert. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Vérification des prérequis : confirmez que vous disposez des autorisations et des identifiants nécessaires pour accéder à la base de données du Data Mart Guidewire DataHub / InfoCenter avec des droits de lecture. Vérifiez que les tâches 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, tel que DBeaver, SQL Server Management Studio ou un outil similaire, pour vous connecter au serveur hébergeant 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 consacrées aux sinistres, aux expositions, aux activités et aux transactions financières. Les tables clés portent généralement des suffixes tels que _dim (dimension) et _fact (fait). Vous pourrez ainsi vérifier les noms de tables et de colonnes utilisés comme espaces réservés dans le script fourni.
- Préparation de la requête SQL : copiez l’intégralité du script SQL fourni dans la section consacrée à la requête, puis collez-le dans l’éditeur de requêtes de votre client SQL.
- Personnalisation des espaces réservés : examinez attentivement le script et remplacez toutes les valeurs génériques. Cela comprend le nom de la base de données ou du schéma, par exemple [YourDataMart], les paramètres de période ('[StartDate]', '[EndDate]') et les valeurs de configuration propres au système, telles que les modèles d’activité et les codes de statut.
- Exécution de la requête : exécutez la requête SQL modifiée sur le Data Mart. La durée d’exécution peut varier selon la période sélectionnée et le volume de données de votre système.
- Première vérification des données : une fois la requête terminée, examinez les premières centaines de lignes du résultat. Vérifiez que les colonnes ClaimID, ActivityName et EventTime sont renseignées comme prévu et que plusieurs types d’activités sont présents.
- Export au format CSV : exportez l’intégralité du résultat depuis votre client SQL vers un fichier CSV. Donnez-lui un nom explicite, par exemple guidewire_claimcenter_event_log.csv.
- Mise en forme pour ProcessMind : enregistrez le fichier CSV avec un encodage UTF-8. Vérifiez qu’il contient une ligne d’en-tête correspondant aux alias de colonnes de la requête SQL. Le fichier est maintenant prêt à être importé dans ProcessMind.
Configuration
- Source de données : Data Mart des sinistres Guidewire DataHub/InfoCenter. 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 ClaimCenter active.
- Autorisations requises : accès en lecture seule à la base de données SQL qui héberge le Data Mart. Vous aurez besoin d’un nom d’utilisateur, d’un mot de passe et des informations de connexion, notamment l’adresse du serveur et le nom de la base de données.
- État des tâches ETL : la fiabilité de cette extraction dépend de l’exécution correcte et ponctuelle des tâches ETL Guidewire qui alimentent le Data Mart. Vérifiez l’heure de la dernière exécution réussie afin d’évaluer l’actualité des données.
- Filtrage par période : la requête fournie contient des clauses WHERE avec les espaces réservés '[StartDate]' et '[EndDate]'. Il est recommandé de commencer par une période limitée, par exemple 3 à 6 mois, afin de maîtriser les performances. Le filtre de date s’applique à CreateTime du sinistre.
- Valeurs propres à la configuration : Guidewire est hautement configurable. Vous devez adapter les valeurs des clauses WHERE à la configuration de votre organisation. Cela comprend :
- les noms d’ActivityPattern, par exemple 'fnol', 'investigation', 'Request additional information' ;
- les codes ClaimStatus, ExposureStatus et CloseReason, par exemple 'denied', 'closed' ;
- les codes TransactionStatus, par exemple 'pendingapproval', 'approved', 'issued'.
- Performances : l’interrogation de grandes tables d’historique ou d’audit peut mobiliser beaucoup de ressources. Pour les volumes très importants, il est recommandé d’exécuter la requête en dehors des heures de pointe. Vérifiez que les colonnes ClaimID ou ClaimNumber sont indexées dans les tables concernées.
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
- Confirmez que votre organisation dispose d’un partage de données Snowflake Guidewire Cloud Data Access, CDA, actif pour l’environnement ClaimCenter. Demandez à votre administrateur Guidewire Cloud l’identifiant du compte Snowflake, la base de données, le schéma, le warehouse, le rôle, la méthode d’authentification et la configuration réseau autorisée.
- Confirmez les objets et les colonnes CDA effectivement exposés dans votre partage. Les schémas CDA et les noms de colonnes peuvent varier selon le tenant, la version, la configuration et le modèle de partage des données. Remplacez chaque espace réservé entre crochets de la requête par l’objet correspondant dans votre environnement. Ne supposez pas que les noms des entités opérationnelles ClaimCenter sont exposés tels quels dans Snowflake.
- Identifiez la source de la création du sinistre, de l’historique des affectations, de la création des expositions, des transactions de réserves, des activités, de l’historique des statuts d’exposition, de l’historique des statuts de paiement et de l’historique des statuts de sinistre. Si votre partage n’expose pas les tables d’historique ou les enregistrements d’audit, configurez une source approuvée qui conserve l’ancienne valeur, la nouvelle valeur, l’horodatage de l’événement et l’auteur de chaque transition requise.
- Connectez-vous au partage CDA Snowflake à l’aide d’un client Snowflake, d’une feuille de calcul, d’un notebook ou d’un outil d’exécution SQL autorisé. Utilisez si possible un rôle en lecture seule. Définissez dans la requête les horodatages de début et de fin de l’analyse à l’aide de [Start timestamp] et [End timestamp], puis appliquez tout filtre approuvé sur l’entreprise ou l’unité opérationnelle à l’aide de [Company filter].
- Remplacez les espaces réservés aux sources dans la requête par des noms d’objets et de colonnes CDA vérifiés. La requête crée explicitement des lignes pour les 14 activités requises : Claim Created, Claim Assigned, Exposure Created, Initial Reserve Set, Investigation Started, Additional Info Requested, Additional Info Received, Liability Decision Made, Settlement Calculated, Payment Approved, Payment Issued, Claim Denied, Claim Closed et Claim Reopened.
- Exécutez la requête et examinez le schéma du résultat. La sortie doit contenir ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus et LossCause. ClaimID, ActivityName et EventTime sont obligatoires pour ProcessMind. Conservez une ligne par événement et n’agrégez pas les événements par sinistre.
- Validez les horodatages, les transitions de statut, les changements d’affectation, la gestion des doublons et le nombre d’activités avant l’export. Vérifiez que les horodatages des événements utilisent un fuseau horaire cohérent et que plusieurs événements portant le même horodatage restent sur des lignes distinctes lorsqu’ils correspondent à des activités métier différentes.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Mappez ClaimID comme identifiant de dossier, ActivityName comme activité et EventTime comme horodatage de l’événement. Conservez les attributs recommandés comme attributs supplémentaires des événements, puis importez le fichier dans ProcessMind sans ajouter d’activités déduites en dehors de cette extraction.
Configuration
- Connexion et autorisation : utilisez le partage de données Snowflake fourni par Guidewire via un compte Snowflake, un rôle, un warehouse et un chemin réseau autorisés. Du point de vue du consommateur, CDA est en lecture seule. Les accès requis dépendent de la configuration de votre tenant et peuvent inclure l’autorisation d’interroger la base de données partagée ainsi que certains schémas ou vues.
- Configuration des objets sources : remplacez toutes les références entre crochets par des objets vérifiés dans votre partage CDA. La requête n’impose volontairement pas de noms universels de tables ou de colonnes ClaimCenter, car les structures CDA varient selon la version et le tenant.
- Période : commencez par une période de trois à six mois pour la validation et l’analyse opérationnelle. N’élargissez cette période qu’après avoir vérifié la capacité du warehouse, la durée de conservation de l’historique des événements et la durée d’exécution acceptable de la requête. Filtrez les enregistrements sources selon l’horodatage pertinent de l’événement, et pas uniquement selon la date de création du sinistre, afin de ne pas exclure les activités ultérieures.
- Sortie requise : ClaimID, ActivityName et EventTime doivent être présents et non nuls pour chaque ligne d’événement. ActivityName doit utiliser exactement les libellés attendus par le modèle de processus ProcessMind.
- Sortie recommandée : incluez AssignedAdjuster, ClaimType, ClaimStatus et LossCause. Lorsque cela est possible, ces valeurs peuvent provenir de l’instantané correspondant à l’événement. Si seules les valeurs de l’état actuel sont exposées, documentez cette limite, car les attributs historiques peuvent ne pas refléter la valeur au moment de l’événement.
- Filtres : appliquez [Company filter] uniquement après avoir confirmé la colonne correspondant au tenant, à l’entreprise, à l’organisation, à l’unité opérationnelle ou à l’entité juridique concernée. Ne filtrez pas selon le type de document, sauf si la configuration ClaimCenter expose un champ de type de document vérifié et pertinent pour les activités demandées.
- Historique des événements : les affectations, les enquêtes, les demandes d’informations, les décisions de responsabilité, les statuts de paiement et les réouvertures de sinistres nécessitent des données d’historique ou d’audit pour identifier les transitions. Les seules tables d’état actuel ne permettent pas de reconstituer les événements antérieurs de manière fiable.
- Déduplication : utilisez un identifiant d’événement source vérifié lorsqu’il est disponible. La requête utilise ROW_NUMBER uniquement comme mesure de protection configurable. Ne dédupliquez pas les événements uniquement à partir de ClaimID et de l’horodatage lorsque plusieurs activités distinctes peuvent légitimement se produire au même moment.
- Performances : limitez la période, sélectionnez uniquement les colonnes nécessaires, filtrez chaque source selon son horodatage d’événement et utilisez un warehouse Snowflake de taille adaptée. Pour les volumes importants, envisagez de matérialiser une vue d’événements validée ou de mettre en place une extraction incrémentielle.
- Fuseau horaire : standardisez EventTime selon un fuseau horaire documenté. Vérifiez si les horodatages CDA sont stockés en UTC, en heure locale ou dans l’une des variantes d’horodatage Snowflake avant de charger l’Event Log.
- Prérequis : confirmez que les données financières, d’activité, d’affectation, d’exposition, de paiement et d’historique des statuts ClaimCenter nécessaires sont incluses dans le partage et que les règles de conservation préservent les transitions historiques requises.
a Exemple de requête sql
WITH
params AS (
SELECT
TO_TIMESTAMP_TZ('[Start timestamp]') AS start_ts,
TO_TIMESTAMP_TZ('[End timestamp]') AS end_ts
),
claim_created AS (
SELECT
CAST(c.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Created' AS ActivityName,
CAST(c.[Claim created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(c.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(c.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(c.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(c.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(c.[Claim event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim source object] c
CROSS JOIN params p
WHERE c.[Claim created timestamp column] >= p.start_ts
AND c.[Claim created timestamp column] < p.end_ts
AND [Company filter]
),
claim_assigned AS (
SELECT
CAST(h.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Assigned' AS ActivityName,
CAST(h.[Assignment event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(h.[New assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(h.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(h.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(h.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(h.[Assignment event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim assignment history object] h
CROSS JOIN params p
WHERE h.[Assignment event timestamp column] >= p.start_ts
AND h.[Assignment event timestamp column] < p.end_ts
AND h.[New assigned adjuster column] IS DISTINCT FROM h.[Previous assigned adjuster column]
AND [Company filter]
),
exposure_created AS (
SELECT
CAST(e.[Claim ID column] AS VARCHAR) AS ClaimID,
'Exposure Created' AS ActivityName,
CAST(e.[Exposure created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(e.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(e.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(e.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(e.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(e.[Exposure event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure source object] e
CROSS JOIN params p
WHERE e.[Exposure created timestamp column] >= p.start_ts
AND e.[Exposure created timestamp column] < p.end_ts
AND [Company filter]
),
initial_reserve_set AS (
SELECT
CAST(r.[Claim ID column] AS VARCHAR) AS ClaimID,
'Initial Reserve Set' AS ActivityName,
CAST(r.[Reserve transaction timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(r.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(r.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(r.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(r.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(r.[Reserve transaction identifier column] AS VARCHAR) AS SourceEventID
FROM [Your reserve transaction source object] r
CROSS JOIN params p
WHERE r.[Reserve transaction timestamp column] >= p.start_ts
AND r.[Reserve transaction timestamp column] < p.end_ts
AND r.[Reserve transaction sequence or first reserve indicator column] = [Value identifying first reserve]
AND [Company filter]
),
investigation_started AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Investigation Started' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured investigation activity value]'
AND [Company filter]
),
additional_info_requested AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Requested' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND [Company filter]
),
additional_info_received AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Received' AS ActivityName,
CAST(a.[Activity completion timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity completion timestamp column] >= p.start_ts
AND a.[Activity completion timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND a.[Activity status column] = '[Configured completed status value]'
AND [Company filter]
),
liability_decision_made AS (
SELECT
CAST(eh.[Claim ID column] AS VARCHAR) AS ClaimID,
'Liability Decision Made' AS ActivityName,
CAST(eh.[Exposure status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(eh.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(eh.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(eh.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(eh.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(eh.[Exposure status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure status history object] eh
CROSS JOIN params p
WHERE eh.[Exposure status event timestamp column] >= p.start_ts
AND eh.[Exposure status event timestamp column] < p.end_ts
AND eh.[New exposure status column] = '[Configured liability decision status value]'
AND eh.[New exposure status column] IS DISTINCT FROM eh.[Previous exposure status column]
AND [Company filter]
),
settlement_calculated AS (
SELECT
CAST(pay.[Claim ID column] AS VARCHAR) AS ClaimID,
'Settlement Calculated' AS ActivityName,
CAST(pay.[Payment created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(pay.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(pay.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(pay.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(pay.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(pay.[Payment identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment source object] pay
CROSS JOIN params p
WHERE pay.[Payment created timestamp column] >= p.start_ts
AND pay.[Payment created timestamp column] < p.end_ts
AND pay.[Payment status column] = '[Configured pending approval status value]'
AND [Company filter]
),
payment_approved AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Approved' AS ActivityName,
CAST(ph.[Payment approval timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Approving user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment approval timestamp column] >= p.start_ts
AND ph.[Payment approval timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured approved status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
payment_issued AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Issued' AS ActivityName,
CAST(ph.[Payment issued timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Issuing user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment issued timestamp column] >= p.start_ts
AND ph.[Payment issued timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured issued status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
claim_denied AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Denied' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND ch.[Claim closure reason column] = '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_closed AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Closed' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND COALESCE(ch.[Claim closure reason column], '') <> '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_reopened AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Reopened' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[Previous claim status column] = '[Configured closed status value]'
AND ch.[New claim status column] = '[Configured open status value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
all_events AS (
SELECT * FROM claim_created
UNION ALL SELECT * FROM claim_assigned
UNION ALL SELECT * FROM exposure_created
UNION ALL SELECT * FROM initial_reserve_set
UNION ALL SELECT * FROM investigation_started
UNION ALL SELECT * FROM additional_info_requested
UNION ALL SELECT * FROM additional_info_received
UNION ALL SELECT * FROM liability_decision_made
UNION ALL SELECT * FROM settlement_calculated
UNION ALL SELECT * FROM payment_approved
UNION ALL SELECT * FROM payment_issued
UNION ALL SELECT * FROM claim_denied
UNION ALL SELECT * FROM claim_closed
UNION ALL SELECT * FROM claim_reopened
),
deduplicated_events AS (
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause,
SourceEventID,
ROW_NUMBER() OVER (
PARTITION BY ActivityName, COALESCE(SourceEventID, ClaimID || '|' || TO_VARCHAR(EventTime))
ORDER BY EventTime
) AS duplicate_rank
FROM all_events
WHERE ClaimID IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
)
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause
FROM deduplicated_events
WHERE duplicate_rank = 1
ORDER BY ClaimID, EventTime, ActivityName; Étapes
- Confirmez que l’accès direct en lecture à la base de données opérationnelle Guidewire ClaimCenter sur site est autorisé, que la plateforme de base de données et la version du schéma sont documentées et qu’une connexion en lecture seule est disponible. N’interrogez pas la base de production sans fenêtre d’extraction approuvée.
- Identifiez les tables physiques et les colonnes utilisées par votre implémentation ClaimCenter. Faites correspondre les entités de sinistre, d’exposition, d’activité, d’affectation, de réserve, de paiement, d’historique des statuts et d’utilisateur ou de groupe aux espaces réservés de la requête. Les noms physiques et les structures d’audit variant selon l’implémentation et la version, ne remplacez chaque espace réservé qu’après l’avoir vérifié dans le catalogue de votre base de données et le modèle de données ClaimCenter.
- Définissez la période d’extraction à l’aide de [Start date parameter] et [End date parameter]. Prévoyez une période de chevauchement, par exemple un ou deux jours avant la date de début demandée, lorsque les changements de statut, l’achèvement des tâches ou les transactions financières peuvent être enregistrés en dehors de la période principale de création des sinistres.
- Exécutez l’instruction SQL complète avec des privilèges en lecture seule. Chaque activité est produite sous la forme d’une ligne d’événement explicite. La requête ne demande pas à ProcessMind de déduire les événements après l’importation. Les événements déduits des changements de champs sont calculés dans l’instruction SQL à partir des enregistrements d’historique ou d’audit pertinents.
- Validez les correspondances sources pour chaque activité. Vérifiez que la création du sinistre utilise le premier enregistrement Claim enregistré, que l’affectation utilise les changements d’affectation, que la création de l’exposition utilise les enregistrements de création d’exposition, que la réserve initiale utilise la première transaction de réserve par exposition, que les enquêtes et les demandes d’informations utilisent les enregistrements d’activité, que la responsabilité utilise la transition de statut d’exposition configurée, que le règlement utilise un état de paiement en attente d’approbation et que l’approbation et l’émission du paiement utilisent les états d’audit financiers correspondants.
- Normalisez la sortie selon la structure requise pour l’Event Log. ClaimID doit être l’identifiant du dossier, ActivityName doit contenir exactement l’un des quatorze noms d’activités documentés et EventTime doit être un horodatage. Conservez les attributs recommandés, notamment AssignedAdjuster, ClaimType, ClaimStatus et LossCause, lorsque la correspondance source les fournit.
- Examinez les doublons et l’ordre des événements. Si la source contient plusieurs lignes d’audit pour une même transition métier, appliquez la clé de déduplication propre à l’implémentation dans l’expression de table commune concernée. Ne regroupez pas des événements métier distincts dont les horodatages ou les identifiants sources diffèrent.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Incluez une ligne d’en-tête avec ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus et LossCause. Vérifiez que les horodatages contiennent les informations de fuseau horaire ou utilisent de manière cohérente le fuseau horaire documenté de la base de données. Importez le fichier dans ProcessMind et mappez ClaimID comme identifiant du dossier, ActivityName comme activité et EventTime comme horodatage de l’événement.
Configuration
- Accès à la base de données : utilisez un compte en lecture seule autorisé à interroger les tables opérationnelles, les tables d’historique, les tables d’activités et les tables de transactions financières ClaimCenter nécessaires. N’accordez aucun privilège d’écriture, de modification du schéma ou d’administration pour l’extraction.
- Correspondance du schéma : remplacez [Your claim table], [Your exposure table], [Your activity table], [Your reserve table], [Your payment table], [Your claim history table], [Your exposure history table] et les espaces réservés associés par des noms vérifiés dans l’implémentation cible. Ne supposez pas que le nom logique d’une entité Guidewire correspond au nom de la table physique.
- Période : commencez par trois à six mois de données. Utilisez [Start date parameter] et [End date parameter] et prévoyez une période de chevauchement lorsque des événements peuvent être enregistrés après la création du sinistre ou lorsque des sinistres réouverts couvrent plusieurs périodes de reporting.
- Filtres : n’appliquez [Company Code filter], [Document Type filter], les filtres de juridiction, de branche d’activité ou d’organisation qu’après avoir confirmé les colonnes physiques correspondantes et leur signification métier. Évitez d’exclure les sinistres sans paiement ou sans exposition, car ces enregistrements sont nécessaires à une analyse complète du cycle de vie.
- Noms des activités : conservez exactement les quatorze valeurs ActivityName définies dans la requête afin que ProcessMind reçoive des libellés d’événements cohérents.
- Sémantique des événements : les activités décrites comme déduites sont générées en SQL à partir des transitions de statut, d’affectation, d’historique ou d’activité des sources. ProcessMind ne déduira pas ces événements à partir d’autres lignes après l’importation.
- Performances : limitez la période d’extraction, sélectionnez uniquement les colonnes nécessaires, filtrez les tables sources avant les jointures et vérifiez les index sur les identifiants de sinistre, les identifiants d’exposition, les horodatages d’événements, les champs de statut et les identifiants de transaction. Lorsque cela est possible, exécutez les extractions volumineuses sur une réplique de reporting.
- Cohérence : utilisez un niveau d’isolation des transactions adapté au reporting et définissez une limite d’extraction cohérente. Évitez de lire les tables pendant l’exécution partiellement validée d’un traitement financier ou d’une mise à jour massive des statuts.
- Fuseaux horaires : documentez le fuseau horaire de la base de données et convertissez tous les horodatages sources vers un fuseau convenu avant l’export. Ne mélangez pas les horodatages locaux de l’application et ceux du serveur de base de données.
- Prérequis : confirmez que les modules ClaimCenter nécessaires, les autorisations financières, la conservation des données d’audit ou d’historique et la connectivité à la base de données sont disponibles. Si la conservation de l’historique ou des audits est désactivée, les activités déduites correspondantes ne peuvent pas être reconstituées de manière fiable.
- Configuration de validation : consignez pour chaque export la version de ClaimCenter, la plateforme de base de données, la correspondance du schéma, l’horodatage de l’extraction, les paramètres de période, les filtres et le nombre de lignes.
a Exemple de requête sql
WITH
claim_created AS (
SELECT
c.[Claim ID column] AS ClaimID,
CAST('Claim Created' AS VARCHAR(100)) AS ActivityName,
c.[Claim Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim table] c
WHERE c.[Claim Created Timestamp column] >= [Start date parameter]
AND c.[Claim Created Timestamp column] < [End date parameter]
),
claim_assigned AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Assigned' AS VARCHAR(100)) AS ActivityName,
h.[Assignment Change Timestamp column] AS EventTime,
h.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim assignment history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Assignment Change Timestamp column] >= [Start date parameter]
AND h.[Assignment Change Timestamp column] < [End date parameter]
AND h.[Assigned Adjuster column] IS NOT NULL
),
exposure_created AS (
SELECT
e.[Claim ID column] AS ClaimID,
CAST('Exposure Created' AS VARCHAR(100)) AS ActivityName,
e.[Exposure Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure table] e
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = e.[Claim ID column]
WHERE e.[Exposure Created Timestamp column] >= [Start date parameter]
AND e.[Exposure Created Timestamp column] < [End date parameter]
),
initial_reserve_set AS (
SELECT
x.ClaimID,
CAST('Initial Reserve Set' AS VARCHAR(100)) AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
r.[Claim ID column] AS ClaimID,
r.[Reserve Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause,
ROW_NUMBER() OVER (
PARTITION BY r.[Exposure ID column]
ORDER BY r.[Reserve Timestamp column], r.[Reserve Transaction ID column]
) AS reserve_sequence
FROM [Your reserve transaction table] r
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = r.[Claim ID column]
WHERE r.[Reserve Timestamp column] >= [Start date parameter]
AND r.[Reserve Timestamp column] < [End date parameter]
) x
WHERE x.reserve_sequence = 1
),
investigation_started AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Investigation Started' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Investigation activity type value])
),
additional_info_requested AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Requested' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
),
additional_info_received AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Received' AS VARCHAR(100)) AS ActivityName,
a.[Activity Completed Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Completed Timestamp column] >= [Start date parameter]
AND a.[Activity Completed Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
AND a.[Activity Status column] = [Completed activity status value]
),
liability_decision_made AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Liability Decision Made' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Exposure Status column] IN ([Liability decision status value])
),
settlement_calculated AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Settlement Calculated' AS VARCHAR(100)) AS ActivityName,
p.[Payment Status Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Payment Status Timestamp column] >= [Start date parameter]
AND p.[Payment Status Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Pending approval payment status value]
),
payment_approved AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Approved' AS VARCHAR(100)) AS ActivityName,
p.[Approval Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment approval history table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Approval Timestamp column] >= [Start date parameter]
AND p.[Approval Timestamp column] < [End date parameter]
AND p.[Approval Status column] = [Approved payment status value]
),
payment_issued AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Issued' AS VARCHAR(100)) AS ActivityName,
p.[Issued Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment issuance table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Issued Timestamp column] >= [Start date parameter]
AND p.[Issued Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Issued payment status value]
),
claim_denied AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Denied' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] = [Denied status reason value]
),
claim_closed AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Closed' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] <> [Denied status reason value]
),
claim_reopened AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Reopened' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim status history table] previous_h
ON previous_h.[Claim ID column] = h.[Claim ID column]
AND previous_h.[Status Change Timestamp column] = (
SELECT MAX(prior_h.[Status Change Timestamp column])
FROM [Your claim status history table] prior_h
WHERE prior_h.[Claim ID column] = h.[Claim ID column]
AND prior_h.[Status Change Timestamp column] < h.[Status Change Timestamp column]
)
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND previous_h.[New Claim Status column] = [Closed claim status value]
AND h.[New Claim Status column] = [Open claim status value]
)
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_assigned
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM exposure_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM initial_reserve_set
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM investigation_started
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_requested
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_received
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM liability_decision_made
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM settlement_calculated
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_approved
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_issued
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_denied
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_closed
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_reopened
ORDER BY ClaimID, EventTime, ActivityName; Prêt à commencer ?
Utilisez ce modèle pour préparer vos données à l’analyse et obtenir une meilleure visibilité sur votre gestion des sinistres. Commencez dès aujourd’hui à optimiser vos flux de travail.
Accélérez la gestion des sinistres et résolvez les dossiers plus rapidement
Éliminez les retards accumulés, prévenez la fraude et visez 70 % de traitement de bout en bout sans intervention.
Aucune carte bancaire requise, configuration en quelques minutes.