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
- Consignes d’extraction pour Guidewire ClaimCenter
Attributs du traitement des sinistres
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | La date et l’heure précises auxquelles l’activité a eu lieu. | ||
| Description Cet horodatage indique le moment exact où l’activité a été enregistrée dans le système. Il est indispensable à toute analyse temporelle du processus. L’ordre chronologique des EventTime pour un même ID de sinistre permet de reconstituer le flux du processus. L’écart entre deux événements consécutifs sert à calculer les temps de cycle, les temps d’attente et les durées de traitement, des mesures essentielles pour analyser les performances, repérer les goulots d’étranglement et suivre les SLA. Pourquoi est-ce important ? Cet horodatage est essentiel pour ordonner les événements, calculer les temps de cycle et les durées, et repérer les retards dans le processus. Où trouver ces données Cette information figure avec les données d’événement ou d’activité dans l’historique ou les tables d’audit de Guidewire ClaimCenter, souvent dans un champ nommé « CreateTime » ou « UpdateTime ». Exemples 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| ID de sinistre ClaimID | Identifiant unique de chaque sinistre, qui sert d’identifiant principal du cas. | ||
| Description L’ID de sinistre est la clé de voûte de l’analyse du processus de traitement des sinistres : il identifie chaque cas de manière unique, de sa soumission à sa clôture. Il relie toutes les activités, tous les documents, paiements et échanges associés, pour donner une vue complète et cohérente du cycle de vie du sinistre. En process mining, chaque événement du jeu de données est associé à un ID de sinistre, ce qui permet de reconstituer le flux de travail de bout en bout. C’est indispensable pour analyser les temps de cycle, repérer les variantes du processus et suivre le parcours d’un sinistre entre les différents services et gestionnaires. Pourquoi est-ce important ? Cette clé fondamentale relie tous les événements associés et permet de retracer et d’analyser le parcours complet d’un sinistre. Où trouver ces données Il s’agit d’une clé primaire dans Guidewire ClaimCenter, généralement présente dans Claim.ClaimNumber ou dans un champ similaire de l’entité Claim principale. Exemples 000-123-45678000-987-65432001-456-11223 | |||
| Nom de l’activité ActivityName | Nom de l’activité ou de l’événement métier survenu à un moment précis du cycle de vie du sinistre. | ||
| Description Cet attribut décrit une étape ou un jalon précis du processus de gestion des sinistres, par exemple « Sinistre créé », « Enquête commencée » ou « Paiement effectué ». La succession de ces activités pour un ID de sinistre donné constitue le flux du processus. L’analyse de leur ordre, de leur fréquence et du temps écoulé entre elles est au cœur du Process Mining. Elle permet de découvrir les modèles de processus, de repérer les goulots d’étranglement, de détecter les boucles de reprise et d’analyser les écarts du processus. Pourquoi est-ce important ? Il définit les étapes du processus et permet de visualiser les cartes de processus, ainsi que d’analyser le flux du processus et les goulots d’étranglement. Où trouver ces données Cette information est généralement extraite des tables d’événements ou des journaux d’audit de ClaimCenter, en associant souvent des événements système ou des changements de statut précis à des noms d’activité normalisés. Exemples Sinistre crééDécision sur la responsabilité prisePaiement émisSinistre clôturé | |||
| Cause du sinistre LossCause | Raison ou cause précise du sinistre, par exemple une collision, un incendie ou un dégât des eaux. | ||
| Description Cet attribut précise la raison de la déclaration du sinistre. La cause détermine souvent les étapes d’enquête nécessaires, le type d’experts requis et la complexité globale du dossier. L’analyse du processus par cause du sinistre peut révéler des tendances moins visibles. Par exemple, les sinistres liés à un dégât des eaux peuvent nécessiter davantage de reprises ou l’intervention de plus de spécialistes que les sinistres liés à un vol. Ces résultats aident à définir des procédures de traitement plus spécialisées et efficaces. Pourquoi est-ce important ? Précise 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ù trouver ces données Champ standard de l’entité Claim, généralement nommé « LossCause ». Exemples CollisionIncendieDégât des eauxVol | |||
| Expert en sinistres affecté AssignedAdjuster | Nom ou ID de l’utilisateur chargé du sinistre ou d’une activité précise. | ||
| Description Cet attribut identifie l’expert en sinistres chargé d’un dossier à un moment donné. Un expert peut être affecté à l’ensemble du dossier ou à certaines tâches seulement. L’analyse par expert en sinistres affecté est essentielle pour équilibrer la charge de travail, suivre les performances et repérer les besoins de formation. Elle permet de répondre à des questions telles que : « Quels experts ont le plus de dossiers à traiter ? », « Les performances varient-elles d’un expert à l’autre ? » et « Le travail est-il réparti équitablement ? ». Pourquoi est-ce important ? Suit la participation des utilisateurs afin d’analyser la charge de travail, de comparer les performances et de repérer les goulots d’étranglement liés aux ressources. Où trouver ces données 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 général du sinistre au moment de l’événement, par exemple ouvert, clôturé ou refusé. | ||
| Description Cet attribut indique l’état général du sinistre. Les principaux statuts sont « Ouvert », « Clôturé », « Refusé » et « Réouvert ». Le statut final d’un sinistre est un indicateur de résultat essentiel. Le suivi des changements de statut permet de définir les principaux jalons et résultats du processus. Il sert à déterminer l’issue finale d’un sinistre, à calculer les taux de refus et à analyser la fréquence des réouvertures après clôture, souvent révélatrices de problèmes de processus ou d’insatisfaction des clients. Pourquoi est-ce important ? Indique l’issue du sinistre, une information essentielle pour analyser les taux de refus, les modalités de clôture et la fréquence des réouvertures. Où trouver ces données Champ central de l’entité Claim, généralement nommé « State » ou « Status ». Exemples OuvertClôturéRefuséRéouvert | |||
| Type de sinistre ClaimType | Catégorie du sinistre, par exemple automobile, habitation ou responsabilité civile. | ||
| Description Le type de sinistre est une catégorie fondamentale, définie selon le secteur 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. Pour obtenir des résultats pertinents, il est essentiel de segmenter l’analyse du processus par type de sinistre. Cela permet de comparer les performances entre secteurs d’activité, de repérer les goulots d’étranglement propres à chaque type et d’adapter les initiatives d’amélioration aux caractéristiques de chaque catégorie de sinistres. Pourquoi est-ce 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ù trouver ces données Dérivé de l’entité Policy ou Claim dans ClaimCenter, souvent à partir du code Line of Business (LOB). Exemples Automobile individuelleBiens commerciauxResponsabilité civile généraleAccidents du travail | |||
| Automatisé IsAutomated | Indique si une activité a été réalisée automatiquement par le système ou par un utilisateur. | ||
| Description Cet attribut booléen distingue les activités exécutées par le système, comme la création automatique de provisions ou l’envoi de courriers générés par le système, de celles réalisées manuellement par un expert en sinistres. Son analyse est essentielle pour comprendre le degré d’automatisation du processus de gestion des sinistres. Elle permet de repérer les étapes qui nécessitent une intervention manuelle, de mesurer l’efficacité des initiatives de traitement entièrement automatisé et de trouver de nouvelles possibilités d’automatisation en identifiant les tâches répétitives, fondées sur des règles, qui sont encore réalisées par des personnes. Pourquoi est-ce important ? Distingue les activités réalisées par le système de celles effectuées par des personnes, ce qui est essentiel pour analyser l’automatisation et repérer les goulots d’étranglement liés aux interventions manuelles. Où trouver ces données Cette information doit souvent être déduite. Par exemple, les événements enregistrés par un utilisateur système générique peuvent être considérés comme automatisés. Exemples truefalse | |||
| Date cible de résolution ResolutionTargetDate | Date à laquelle le sinistre devrait être résolu, conformément aux SLA internes ou réglementaires. | ||
| Description La date cible de résolution est l’échéance fixée pour la clôture du sinistre. Elle dépend souvent de facteurs tels que 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 pour créer des Dashboards et des indicateurs de suivi des SLA. En comparant la date réelle de clôture du sinistre à la date cible, l’analyse peut signaler automatiquement les dossiers en retard, mesurer le taux de clôture dans les délais et repérer les types de sinistres ou les services qui peinent à atteindre leurs objectifs. Pourquoi est-ce important ? Sert de référence pour mesurer le respect des accords de niveau de service (SLA) et repérer les sinistres susceptibles d’être en retard. Où trouver ces données Il peut s’agir d’un champ personnalisé ou d’une valeur calculée selon les règles métier configurées dans ClaimCenter, éventuellement à partir de mesures propres aux 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 lui-même, par exemple un accident de voiture ou un dommage matériel. Elle diffère de la date de déclaration ou de création du dossier. L’intervalle entre la date du sinistre et l’activité « Sinistre créé », appelé délai de déclaration, est un indicateur clé de performance. Son analyse peut éclairer les comportements des clients et l’efficacité des canaux de première déclaration de sinistre. Pourquoi est-ce important ? Apporte un contexte essentiel sur l’origine du sinistre et permet d’analyser le délai entre l’incident et la déclaration. Où trouver ces données 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 | Indique si l’activité « Informations complémentaires demandées » s’est produite plusieurs fois pour un même sinistre. | ||
| Description Cet indicateur booléen prend la valeur vraie lorsqu’un sinistre comporte plusieurs activités « Informations complémentaires demandées ». Cette situation révèle souvent des lacunes dans la collecte initiale des informations. Cet attribut alimente directement l’indicateur de performance « Taux de demandes d’informations répétées ». Il permet de mesurer le problème des vérifications initiales incomplètes, qui peuvent entraîner des retards importants et mécontenter les clients. L’analyse des sinistres signalés peut aider à améliorer les listes de contrôle et les procédures des experts, afin que toutes les informations nécessaires soient demandées en une seule fois. Pourquoi est-ce important ? Repère les inefficacités dues à une collecte d’informations incomplète dès la première demande, qui entraîne des retards et des reprises. Où trouver ces données Calculé dans l’outil de Process Mining en comptant, pour chaque cas, les occurrences de l’activité « Informations complémentaires demandées ». Exemples truefalse | |||
| Dernière mise à jour des données LastDataUpdate | L’horodatage indiquant la dernière actualisation ou extraction des données depuis le système source. | ||
| Description Cet attribut indique l’horodatage de la dernière extraction des données depuis le système source. Ce champ de métadonnées est essentiel pour savoir si l’analyse repose sur des données récentes. Les Dashboards et les analyses doivent afficher clairement cette information afin que les utilisateurs sachent de quand datent les données. Ils peuvent ainsi déterminer si les résultats reflètent l’état actuel des opérations ou s’ils reposent sur des données plus anciennes. Pourquoi est-ce important ? Indique la fraîcheur des données et permet aux utilisateurs de savoir si l’analyse du processus est à jour. Où trouver ces données 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 | |||
| État de la juridiction JurisdictionState | État ou juridiction régissant le sinistre et déterminant les exigences réglementaires applicables. | ||
| Description Cet attribut précise la juridiction compétente, par exemple l’État américain, dans laquelle le sinistre est traité. La réglementation de l’assurance varie considérablement d’une juridiction à l’autre et peut influer 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 aussi expliquer les différences de temps de cycle ou de parcours du processus dues à des contraintes juridiques plutôt qu’à des inefficacités opérationnelles. Pourquoi est-ce important ? Essentiel à l’analyse de la conformité, car les réglementations qui influent sur le traitement des sinistres varient selon les juridictions. Où trouver ces données Champ standard de l’entité Claim, généralement nommé « JurisdictionState ». Exemples CANYTXFL | |||
| Heure de fin EndTime | L’horodatage indiquant la fin d’une activité. | ||
| Description L’heure de fin marque l’achèvement d’une activité, en particulier lorsqu’il s’agit d’une tâche dont la durée peut être mesurée, comme une enquête ou l’examen d’un document. Dans le Process Mining, de nombreuses activités sont instantanées et un StartTime suffit. Pour celles qui ont un début et une fin distincts, il est préférable d’utiliser les deux horodatages. Cet attribut permet de calculer précisément la durée de traitement d’une activité, indépendamment du temps d’attente. Il aide à repérer les tâches qui prennent réellement du temps, plutôt que de constater uniquement de longs délais entre les étapes. Pourquoi est-ce important ? Il permet de mesurer précisément le temps nécessaire à l’achèvement d’une activité et de distinguer la durée de traitement du temps d’attente. Où trouver ces données Il peut être nécessaire de déduire cette information à partir d’un événement ultérieur qui marque logiquement la fin de l’activité, par exemple le passage du statut « En cours » à « Terminé ». Exemples 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
| Montant du paiement PaymentAmount | Montant effectivement versé au titre d’une activité de paiement. | ||
| Description Cet attribut enregistre le montant de chaque paiement effectué pour un sinistre. Un même dossier peut donner lieu à plusieurs paiements au cours de son cycle de vie. Il est essentiel à l’analyse financière dans le cadre 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 relier les inefficacités du processus aux résultats financiers. Par exemple, les sinistres dont le temps de cycle est long peuvent être associés à des paiements totaux plus élevés. Pourquoi est-ce important ? Suit les transactions financières liées à un sinistre et permet d’analyser les montants versés ainsi que leur lien avec les activités du processus. Où trouver ces données Figure 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 | |||
| Montant réclamé ClaimedAmount | Montant total initialement réclamé par le souscripteur. | ||
| Description Cet attribut correspond au montant du dommage déclaré 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 réclamé permet de segmenter les sinistres selon leur impact financier. Les dossiers portant sur des montants élevés suivent souvent un processus plus rigoureux et complexe que ceux portant sur de faibles montants. La comparaison des processus selon les tranches de montant peut révéler des possibilités de simplifier le traitement des petits sinistres ou de renforcer les contrôles pour les dossiers plus importants. Pourquoi est-ce important ? Permet de segmenter les sinistres selon leur montant, car les dossiers portant sur des montants élevés peuvent suivre des processus différents et plus complexes. Où trouver ces données Cette information ne figure pas nécessairement dans un champ unique. Elle peut être calculée à partir des premières estimations de dommages enregistrées pour les expositions. Exemples 5000.00150000.00750.50 | |||
| Reprise IsRework | Indique si une activité fait partie d’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 « Enquête terminée » à « Enquête commencée », la seconde activité « Enquête commencée » est signalée comme une reprise. Repérer les reprises est essentiel pour mettre au jour les inefficacités du processus et les problèmes de qualité. Le Dashboard consacré à la fréquence des reprises et des refus s’appuie sur cette mesure pour quantifier les écarts par rapport au « parcours nominal ». L’analyse des causes des reprises peut améliorer sensiblement la qualité et la rapidité du processus. Pourquoi est-ce 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ù trouver ces données Cette valeur est calculée dans l’outil de Process Mining à partir de la séquence d’activités de chaque cas. Exemples truefalse | |||
| Service Department | L’unité opérationnelle ou le service chargé de traiter l’activité liée au sinistre. | ||
| Description Cet attribut indique le service ou l’équipe auquel appartient l’expert affecté, par exemple « Sinistres automobiles », « Sinistres habitation » ou « Unité spéciale d’enquête ». Il situe le processus dans son contexte organisationnel. L’analyse par service est essentielle pour comprendre les performances du processus à l’échelle de l’organisation. Elle permet de repérer les retards lors des transferts entre services, de comparer l’efficacité des équipes et de mieux répartir les ressources au sein de l’organisation chargée des sinistres. Pourquoi est-ce important ? Situe le processus dans son contexte organisationnel, permet de comparer les performances des équipes et met en évidence les difficultés liées aux transferts entre services. Où trouver ces données Cette information est généralement associée au profil de l’utilisateur ou du groupe affecté dans ClaimCenter. Exemples Service des sinistres automobilesUnité des sinistres habitationUnité spéciale d’enquête (SIU) | |||
| Statut du SLA SLAState | Indique si le sinistre a été clôturé avant la date cible de résolution. | ||
| Description Cet attribut calculé indique, sous forme de catégorie, si chaque sinistre clôturé respecte le SLA. Il est obtenu en comparant l’horodatage de l’activité « Sinistre clôturé » à la « Date cible de résolution ». Cet attribut alimente directement le Dashboard « Respect de la date cible de résolution des sinistres » en répartissant les résultats dans des catégories claires, comme « Dans les délais » ou « En retard ». Il facilite le filtrage et l’agrégation des données pour calculer le taux global de respect des SLA et examiner les causes des retards. Pourquoi est-ce important ? Indique clairement, sous forme de catégorie, si le SLA a été respecté, ce qui facilite le filtrage, l’agrégation et l’analyse des clôtures dans les délais. Où trouver ces données Champ calculé : IF (ActualCloseDate <= ResolutionTargetDate, 'Dans les délais', 'En retard'). Exemples Dans les délaisEn retard | |||
| Système source SourceSystem | Le système dont les données ont été extraites. | ||
| Description Cet attribut indique l’origine des données d’événement. Dans une grande entreprise, les événements liés aux sinistres peuvent provenir de plusieurs systèmes : le système central Guidewire, un système de gestion documentaire ou encore un portail client. Préciser le système source est essentiel pour la gouvernance des données, la résolution des incohérences et la compréhension de l’environnement technologique du processus. Cela permet de distinguer les étapes principales du processus des activités de soutien réalisées dans des systèmes périphériques. Pourquoi est-ce important ? Indique l’origine des données, une information essentielle pour leur gouvernance et pour les analyses portant sur plusieurs systèmes intégrés. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL). 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 apporte une classification plus détaillée que le type de sinistre et précise le produit d’assurance concerné, par exemple « Assurance habitation », « Assurance automobile commerciale » ou « Responsabilité civile cyber ». Ce niveau de détail peut révéler des différences de processus propres à certains produits. L’analyse du processus par type de police aide à repérer les inefficacités propres à chaque produit. Par exemple, les sinistres liés à une police récemment lancée peuvent suivre un processus moins éprouvé et entraîner des retards. Ces résultats peuvent éclairer la conception des produits et les efforts de normalisation des processus. Pourquoi est-ce important ? Permet d’analyser le processus pour des produits d’assurance précis et de repérer les différences de traitement liées aux caractéristiques des polices. Où trouver ces données Cette information se trouve dans l’entité Policy, liée à Claim. Exemples Assurance multirisque habitationResponsabilité civile automobile commercialeAssurance maritime intérieure | |||
Activités de traitement des sinistres
| Activité | Description | ||
|---|---|---|---|
| Paiement approuvé | Cette activité correspond à 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 est-ce important ? Cette étape importante permet de passer au paiement final. L’analyse du temps écoulé avant et après cette activité aide à isoler les retards liés au flux d’approbation ou à la disponibilité des responsables. Où trouver ces données Il s’agit souvent d’un événement explicite enregistré dans la table cc_history pour une entité cc_check ou cc_transaction, qui consigne le changement de statut de « En attente d’approbation » à « Approuvé ». Données à recueillir Suivez le changement de statut vers « Approuvé » 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 : le paiement est officiellement émis et transmis au système financier. Il s’agit d’une transaction financière explicite et enregistrée. | ||
| Pourquoi est-ce important ? Cette activité est essentielle pour mesurer l’efficacité de l’émission des paiements. Elle permet de distinguer les retards d’approbation de ceux liés à l’émission effective des fonds. Où trouver ces données L’événement est enregistré à partir de IssueDate ou d’un changement de statut vers « Émis » ou « Soumis » dans l’entité cc_check ou cc_transaction. Il s’agit souvent d’un événement explicite horodaté. Données à recueillir Repérez IssueDate ou l’horodatage du changement de statut vers « Émis » dans l’enregistrement du paiement. Type d’événement explicit | |||
| Poste de responsabilité créé | Cette activité indique la création d’un poste de responsabilité, qui correspond à une responsabilité potentielle ou à un type de perte précis dans le cadre du sinistre (par exemple, des dommages au véhicule ou des blessures). Il s’agit d’un événement explicite dans Guidewire. | ||
| Pourquoi est-ce important ? Les postes de responsabilité sont essentiels pour segmenter et analyser les sinistres. Le suivi de leur création permet de comprendre les variantes du processus selon la complexité du sinistre et le type de perte. Où trouver ces données L’événement est enregistré à partir de CreateTime d’un nouvel enregistrement dans la table cc_exposure. Chaque enregistrement est associé à un seul ID de sinistre. Données à recueillir Repérez l’horodatage de création d’un nouvel enregistrement dans la table de l’entité Exposure. Type d’événement explicit | |||
| Première provision définie | Cet événement marque la création de la première transaction de provision financière pour un poste de responsabilité, afin d’estimer le coût potentiel du sinistre. Il s’agit d’un événement financier important, enregistré explicitement. | ||
| Pourquoi est-ce important ? Cette étape est essentielle à l’analyse financière et permet de comprendre à quelle vitesse la responsabilité potentielle est évaluée. Les retards peuvent nuire à la planification et au reporting financiers. Où trouver ces données Cet événement est enregistré lors de la création du premier enregistrement cc_reserveline associé à un poste de responsabilité du sinistre. CreateTime de la transaction fournit l’horodatage de l’événement. Données à recueillir Recherchez l’horodatage de création le plus ancien parmi toutes les lignes de provision des postes de responsabilité d’un sinistre donné. Type d’événement explicit | |||
| Sinistre clôturé | 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 en cas de résolution favorable, déduit d’un changement du statut principal du sinistre. | ||
| Pourquoi est-ce important ? En tant qu’événement de fin principal, cette activité est essentielle pour calculer le temps de cycle de bout en bout et mesurer le respect des SLA. Elle marque la fin du cycle de vie du sinistre. Où trouver ces données Déduite du passage du champ State de la table cc_claim à « Closed ». CloseDate de l’enregistrement du sinistre fournit l’horodatage de l’événement. Données à recueillir Repérez 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 dans Guidewire ClaimCenter. Elle est enregistrée explicitement lors de la première sauvegarde d’une nouvelle entité Claim dans la base de données. | ||
| Pourquoi est-ce important ? En tant qu’événement de début principal, cette activité est essentielle pour mesurer le temps de cycle du sinistre de bout en bout. Elle sert de référence pour tous les KPI de performance et de durée qui suivent. Où trouver ces données Cet événement explicite est enregistré à partir de CreateTime dans la table cc_claim. La création d’un nouvel enregistrement doté d’un ID de sinistre unique déclenche l’événement. Données à recueillir Repérez l’horodatage de création du nouvel enregistrement dans la table de l’entité Claim principale. Type d’événement explicit | |||
| Sinistre refusé | Correspond à la décision finale de refuser un sinistre et marque la fin du processus. Cet événement est déduit du passage du sinistre à un statut fermé avec le motif « Refusé ». | ||
| Pourquoi est-ce 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 conduisent permet de repérer les problèmes liés à la réception des sinistres, à l’enquête ou à l’interprétation des polices. Où trouver ces données Déduite du passage du champ State de la table cc_claim à « Closed », associé à la valeur « Denied » ou à une valeur similaire dans le champ CloseReason. CloseDate fournit l’horodatage de l’événement. Données à recueillir Filtrez les changements de statut des sinistres vers « Closed » dont le code de motif indique un refus. Type d’événement inferred | |||
| Décision sur la responsabilité prise | Indique le moment où la responsabilité ou la faute est déterminée pour un poste de responsabilité. Cet événement est généralement déduit d’un changement de statut de l’entité Exposure. | ||
| Pourquoi est-ce important ? Cette décision importante conditionne les étapes de règlement et de paiement. L’analyse du délai nécessaire pour la prendre permet de repérer les goulots d’étranglement dans les phases d’enquête et d’évaluation. Où trouver ces données Déduite de la table cc_history en suivant une modification de State ou d’un champ personnalisé de statut de responsabilité dans l’entité cc_exposure. L’horodatage de l’enregistrement d’historique indique le moment de l’événement. Données à recueillir Surveillez les journaux d’audit ou les tables d’historique pour repérer les mises à jour de l’état ou du statut de responsabilité du poste de responsabilité. Type d’événement inferred | |||
| Enquête commencée | Indique le début officiel de la phase d’enquête sur un sinistre ou un poste de responsabilité. Cet événement est souvent déduit de la création de la première « Activity » (tâche) liée à l’enquête dans Guidewire. | ||
| Pourquoi est-ce important ? Cette activité marque le début d’une phase importante, souvent longue. L’analyse du délai avant le début de l’enquête et de sa durée permet de repérer les principaux goulots d’étranglement. Où trouver ces données Déduite de CreateTime d’un enregistrement cc_activity dont ActivityPattern est lié à une enquête (par exemple, « Enquête initiale », « Contacter un témoin »). Données à recueillir Repérez la première création d’une tâche dont le modèle ou l’objet est lié à une enquête. Type d’événement inferred | |||
| Informations complémentaires demandées | Cette activité correspond à une demande d’informations ou de documents complémentaires adressée au demandeur ou à un tiers. Elle est généralement enregistrée comme une « Activity » (tâche) créée explicitement dans ClaimCenter. | ||
| Pourquoi est-ce important ? Cette activité marque le début de la mesure du KPI « Temps de cycle de collecte des informations complémentaires ». Des occurrences fréquentes peuvent révéler des processus FNOL incomplets ou une collecte d’informations inefficace. Où trouver ces données L’événement est enregistré à partir de CreateTime d’un enregistrement cc_activity dont ActivityPattern concerne une demande de documents ou d’informations auprès d’un tiers. Données à recueillir Repérez la création d’une tâche de demande d’informations à un tiers. Type d’événement explicit | |||
| Informations complémentaires reçues | Marque la fin d’une demande d’informations complémentaires. L’événement est enregistré lorsque l’« Activity » (tâche) correspondante est marquée comme « Terminée ». | ||
| Pourquoi est-ce important ? Cette activité marque la fin du KPI « Temps de cycle de collecte des informations complémentaires ». Les longs délais entre la demande et la réception sont une cause fréquente de ralentissement du traitement des sinistres. Où trouver ces données L’événement est enregistré à partir de CloseTime d’un enregistrement cc_activity dont ActivityPattern concerne une demande d’informations. Le statut de l’activité doit être « Terminée ». Données à recueillir Repérez l’horodatage de fin d’une tâche de demande d’informations à un tiers. Type d’événement explicit | |||
| Montant du règlement calculé | Cette activité correspond au moment où le montant du règlement est déterminé, mais pas encore approuvé pour paiement. Elle peut être déduite de la création d’un paiement au statut « En attente d’approbation ». | ||
| Pourquoi est-ce important ? Elle marque le passage de l’évaluation au paiement. C’est le point de départ de la mesure du KPI « Délai d’autorisation du paiement », qui met en évidence les retards dans la chaîne d’approbation. Où trouver ces données Déduite de CreateTime d’un enregistrement cc_check ou cc_transaction dont le statut initial est « En attente d’approbation » ou un statut similaire avant « Approuvé ». Données à recueillir Repérez la création d’un enregistrement de paiement ou de transaction dont le statut indique que l’approbation n’a pas encore été donnée. Type d’événement inferred | |||
| Sinistre attribué | Cette activité correspond à l’attribution d’un sinistre à un utilisateur précis (gestionnaire de sinistres) ou à un groupe chargé de son traitement. Elle est généralement déduite du suivi des modifications des champs d’attribution de l’entité Claim. | ||
| Pourquoi est-ce 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’acheminement et mesurer le délai avant la première action du responsable désigné. Où trouver ces données Déduite de la table cc_history en suivant les modifications des champs AssignedUser ou AssignedGroup associés à un ID de sinistre donné. L’horodatage de la modification indique le moment où l’événement s’est produit. Données à recueillir Surveillez les journaux d’audit ou les tables d’historique pour repérer les mises à jour des champs d’attribution des sinistres. Type d’événement inferred | |||
| Sinistre rouvert | Correspond au passage d’un sinistre du statut « Closed » au statut « Open » pour effectuer des travaux supplémentaires. Cet événement est déduit d’une séquence précise de changements de statut. | ||
| Pourquoi est-ce important ? Cette activité signale une reprise. Un nombre élevé de sinistres rouverts peut révéler des problèmes lors du règlement initial, des dommages non pris en compte ou d’autres défaillances du processus, qui augmentent les coûts et réduisent l’efficacité. Où trouver ces données Déduite de la table cc_history en repérant le passage du champ State de l’entité cc_claim de « Closed » à « Open » ou à un autre statut actif. Données à recueillir Surveillez le champ de statut principal du sinistre pour repérer le passage d’un statut fermé à un statut ouvert. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Vérification des prérequis : Vérifiez que vous disposez des autorisations et des identifiants nécessaires pour accéder en lecture à la base de données du data mart Guidewire DataHub / InfoCenter. Assurez-vous 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 ou SQL Server Management Studio, pour vous connecter 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. Repérez les tables principales relatives aux sinistres, aux garanties, aux activités et aux transactions financières. Les noms des tables principales se terminent généralement par _dim (dimension) ou _fact (fait). Vous pourrez ainsi vérifier les noms des tables et des colonnes de remplacement dans le script fourni.
- Préparation de la requête SQL : Copiez le script SQL complet fourni dans la section de requête et collez-le dans l’éditeur de requêtes de votre client SQL.
- Remplacement des valeurs de remplacement : Examinez attentivement le script et remplacez toutes les valeurs de remplacement. Il s’agit notamment du nom de la base de données ou du schéma (par exemple, [YourDataMart]), des paramètres de période ('[StartDate]', '[EndDate]') et des valeurs de configuration propres à votre système (par exemple, 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.
- Vérification initiale 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 différents types d’activité sont présents.
- Export au format CSV : Exportez l’ensemble du résultat depuis votre client SQL dans un fichier CSV. Donnez-lui un nom explicite, par exemple guidewire_claimcenter_event_log.csv.
- Mise au format pour ProcessMind : Enregistrez le fichier CSV en UTF-8. Vérifiez que la première ligne contient les en-têtes correspondant aux alias de colonnes de la requête SQL. Le fichier peut maintenant ê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 la création de rapports et l’analyse, distincte de la base de production ClaimCenter en temps réel.
- 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 précision 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 pour connaître l’actualité des données.
- Filtrage par période : La requête fournie contient des clauses WHERE avec les valeurs de remplacement '[StartDate]' et '[EndDate]'. Il est recommandé de commencer par une période limitée, par exemple de 3 à 6 mois, afin de maîtriser les performances. Le filtre de date s’applique à CreateTime du sinistre.
- Valeurs propres à la configuration : Guidewire offre de nombreuses possibilités de configuration. Vous devez adapter les valeurs des clauses WHERE à la configuration de votre organisation. Cela comprend :
- les noms 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 très grands jeux de données, 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.
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érifiez que votre organisation dispose d’un partage de données Snowflake Guidewire Cloud Data Access (CDA) actif pour l’environnement ClaimCenter. Demandez à l’administrateur Guidewire Cloud l’identifiant du compte Snowflake, la base de données, le schéma, l’entrepôt, le rôle, la méthode d’authentification et la configuration réseau autorisée.
- Vérifiez les objets et les colonnes CDA exacts exposés dans votre partage. Les schémas et les noms de colonnes CDA peuvent varier selon l’environnement, la version, la configuration et le modèle de partage des données. Remplacez chaque valeur de remplacement entre crochets dans la requête par l’objet correspondant dans votre environnement. Ne partez pas du principe que les noms des entités opérationnelles ClaimCenter sont exposés tels quels dans Snowflake.
- Repérez les sources des données relatives à la création des sinistres, à l’historique des affectations, à la création des garanties, aux transactions de réserves, aux activités, à l’historique des statuts de garantie et de paiement, ainsi qu’à l’historique des statuts de sinistre. Si votre partage ne donne pas accès aux tables d’historique ou aux enregistrements d’audit, configurez une source approuvée qui conserve, pour chaque changement d’état requis, l’ancienne valeur, la nouvelle valeur, l’horodatage de l’événement et son auteur.
- Connectez-vous au partage Snowflake CDA à l’aide d’un client, d’une feuille de calcul, d’un notebook ou d’un outil d’exécution SQL Snowflake autorisé. Dans la mesure du possible, utilisez un rôle en lecture seule. Indiquez les horodatages de début et de fin de l’analyse dans la requête à l’aide de [Start timestamp] et [End timestamp], puis appliquez tout filtre approuvé par entreprise ou unité opérationnelle à l’aide de [Company filter].
- Remplacez les valeurs de remplacement des sources dans la requête par les 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 vérifiez le schéma du résultat. La sortie doit contenir ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus et LossCause. ProcessMind exige les colonnes ClaimID, ActivityName et EventTime. Conservez une ligne par événement et n’agrégez pas les événements par sinistre.
- Vérifiez les horodatages, les changements de statut, les changements d’affectation, la gestion des doublons et le nombre d’activités avant l’export. Assurez-vous que les horodatages des événements utilisent le même fuseau horaire et que les événements distincts ayant le même horodatage restent sur des lignes séparées.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Associez ClaimID à l’identifiant du cas, ActivityName à l’activité et EventTime à l’horodatage de l’événement. Conservez les attributs recommandés comme attributs d’événement supplémentaires, puis importez le fichier dans ProcessMind sans ajouter d’activités déduites qui ne figurent pas dans cette extraction.
Configuration
- Connexion et autorisation : Utilisez le partage de données Snowflake fourni par Guidewire avec un compte, un rôle, un entrepôt et un accès réseau Snowflake autorisés. Du point de vue de l’utilisateur, CDA est en lecture seule. Les droits requis dépendent de la configuration de votre environnement 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 ne présume volontairement pas de noms de tables ou de colonnes ClaimCenter universels, car les structures CDA exposées varient selon la version et l’environnement.
- 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é de l’entrepôt, la durée de conservation de l’historique des événements et la durée d’exécution acceptable. 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 reprendre exactement les libellés attendus par le modèle de processus ProcessMind.
- Sortie recommandée : Incluez AssignedAdjuster, ClaimType, ClaimStatus et LossCause. Lorsque ces valeurs sont disponibles, elles peuvent provenir de l’instantané correspondant à l’heure de l’événement. Si seules les valeurs actuelles sont exposées, consignez cette limite, car les attributs historiques peuvent différer de leur valeur au moment de l’événement.
- Filtres : Appliquez [Company filter] uniquement après avoir confirmé la colonne correspondant à l’entreprise, à l’organisation, à l’unité opérationnelle ou à l’entité juridique propre à votre environnement. Ne filtrez pas par 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 changements d’affectation, 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 repérer 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é, s’il est disponible. La requête utilise ROW_NUMBER uniquement comme mesure de protection configurable. Ne dédupliquez pas les événements en vous fondant uniquement sur ClaimID et l’horodatage lorsque plusieurs activités distinctes peuvent légitimement survenir au même moment.
- Performances : Limitez la période, sélectionnez uniquement les colonnes requises, filtrez chaque source selon l’horodatage de son événement et utilisez un entrepôt Snowflake de taille adaptée. Pour les volumes importants, envisagez de matérialiser une vue d’événements validée ou de procéder à une extraction incrémentielle.
- Fuseau horaire : Normalisez EventTime dans un fuseau horaire unique et documenté. Avant de charger le journal d’événements, vérifiez si les horodatages CDA sont stockés en UTC, en heure locale ou dans différentes variantes de type d’horodatage Snowflake.
- Prérequis : Vérifiez que le partage comprend les données requises de ClaimCenter sur les finances, les activités, les affectations, les garanties, les paiements et l’historique des statuts, et que les règles de conservation préservent les transitions historiques nécessaires.
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
- Vérifiez 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.
- Repérez les tables physiques et les colonnes utilisées par votre implémentation de ClaimCenter. Faites correspondre les entités sinistre, garantie, activité, affectation, réserve, paiement, historique des statuts et utilisateur ou groupe aux valeurs de remplacement de la requête. Comme les noms physiques et les structures d’audit varient selon l’implémentation et la version, ne remplacez chaque valeur qu’après l’avoir vérifiée 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 des changements de statut, l’achèvement de tâches ou des 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 droits en lecture seule. Chaque activité est produite sous la forme d’une ligne d’événement explicite. Après l’importation, ProcessMind ne déduit pas les événements. Les événements déduits des changements de champs sont générés dans l’instruction SQL à partir des enregistrements d’historique ou d’audit concernés.
- Vérifiez la correspondance des sources pour chaque activité. Confirmez que la création d’un sinistre utilise le premier enregistrement Claim enregistré, que l’affectation repose sur les changements d’affectation, que la création d’une garantie utilise les enregistrements de création correspondants, que la réserve initiale correspond à la première transaction de réserve par garantie, que les enquêtes et les demandes d’informations reposent sur les enregistrements d’activité, que la responsabilité correspond à la transition de statut de garantie configurée, que le règlement correspond à un état de paiement en attente d’approbation, et que l’approbation et l’émission du paiement reposent sur les états d’audit financiers correspondants.
- Normalisez la sortie selon la structure requise pour le journal d’événements. ClaimID doit servir d’identifiant du cas, ActivityName doit contenir exactement l’un des quatorze noms d’activité documentés et EventTime doit être un horodatage. Conservez les attributs recommandés, notamment AssignedAdjuster, ClaimType, ClaimStatus et LossCause, lorsque la correspondance avec la source le permet.
- Examinez les événements en double et leur ordre. 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 les événements métier distincts ayant des horodatages ou des identifiants sources différents.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Ajoutez une ligne d’en-tête contenant ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus et LossCause. Veillez à ce que les horodatages comportent des 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 associez ClaimID à l’identifiant du cas, ActivityName à l’activité et EventTime à l’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 ClaimCenter requises, les tables d’historique, les tables d’activité et les tables de transactions financières. N’accordez aucun droit 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 autres valeurs de remplacement 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 rouverts couvrent plusieurs périodes de rapport.
- Filtres : Appliquez [Company Code filter], [Document Type filter], la juridiction, la branche d’activité ou d’autres filtres propres à l’organisation uniquement après avoir confirmé les colonnes physiques correspondantes et leur signification métier. Évitez d’exclure les sinistres sans paiement ou sans garantie, 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énement cohérents.
- Sémantique des événements : Les activités indiquées comme déduites sont générées en SQL à partir des transitions de statut, d’affectation, d’historique ou d’activité des sources. Après l’importation, ProcessMind ne déduira pas ces événements à partir d’autres lignes.
- Performances : Limitez la période d’extraction, sélectionnez uniquement les colonnes requises, filtrez les tables sources avant les jointures et vérifiez les index sur les identifiants de sinistre et de garantie, les horodatages d’événement, les champs de statut et les identifiants de transaction. Si possible, exécutez les extractions volumineuses sur une réplique de rapports.
- Cohérence : Utilisez un niveau d’isolation des transactions adapté aux rapports et définissez une limite d’extraction cohérente. Évitez de lire les tables pendant qu’un traitement financier par lots ou une mise à jour groupée des statuts est en cours de validation.
- Fuseaux horaires : Documentez le fuseau horaire de la base de données et convertissez tous les horodatages sources dans un même 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 : Vérifiez que les modules ClaimCenter requis, 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 pourront pas être reconstituées de manière fiable.
- Configuration de validation : Pour chaque export, consignez 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.
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 mieux comprendre le traitement de vos sinistres. Commencez dès aujourd’hui à optimiser vos flux de travail.
Accélérez le traitement des sinistres et résolvez les dossiers plus rapidement
Résorbez les retards, prévenez la fraude et visez un traitement automatisé de bout en bout à 70 %.
Aucune carte bancaire requise. Configuration en quelques minutes.