Modèle de données : Traitement des réclamations
Votre modèle de données pour le traitement des sinistres
- Attributs recommandés pour une analyse détaillée
- Activités clés à suivre dans le traitement des réclamations
- Guide pratique d'extraction de données
Attributs de Gestion des Sinistres
| Nom | Description | ||
|---|---|---|---|
Heure de l'événement EventTime | L'horodatage indiquant quand une activité ou un événement spécifique s'est produit. | ||
Description L'Event Time enregistre la date et l'heure exactes auxquelles une activité de traitement des sinistres a eu lieu. Ces données chronologiques sont cruciales pour ordonnancer correctement les événements et comprendre la chronologie d'un sinistre. Lors de l'analyse, ce timestamp est utilisé pour calculer les durées, les temps de cycle et les temps d'attente entre les différentes étapes. Il est fondamental pour identifier les retards, mesurer les performances par rapport aux SLA et appréhender la dynamique temporelle du processus. Pourquoi c'est important Ce timestamp fournit l'ordre chronologique des events, ce qui est essentiel pour calculer toutes les métriques basées sur le temps comme le cycle time et identifier les goulots d'étranglement. Où obtenir Ces informations sont généralement disponibles sous forme de timestamp de création ou de mise à jour associé à chaque event ou enregistrement de statut dans FINEOS Claims. Exemples 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
Nom de l'activité ActivityName | Le nom de l'événement commercial ou de la tâche spécifique qui s'est produit à un moment donné du processus de réclamation. | ||
Description Cet attribut décrit une étape ou un jalon unique au sein du processus de traitement des sinistres, tels que 'Sinistre soumis', 'Examen initial effectué' ou 'Paiement émis'. Chaque activité représente une action distincte effectuée sur le dossier de sinistre. L'analyse de la séquence et de la fréquence de ces activités constitue le fondement du Process Mining. Elle révèle le flux de processus réel, aide à identifier les goulots d'étranglement où le travail s'accumule et met en lumière les parcours communs ou exceptionnels que suivent les sinistres. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation de la cartographie des processus et l'analyse des schémas de workflow et des déviations. Où obtenir Généralement dérivé des event logs, des changements de statut des tâches ou des pistes d'audit au sein du système FINEOS Claims. Exemples Sinistre EnregistréSinistre évaluéPaiement autoriséSinistre Clos | |||
Numéro de Sinistre ClaimId | L'identifiant unique d'une réclamation d'assurance, servant d'identifiant principal du dossier pour l'analyse des processus. | ||
Description L'ID de la réclamation est la clé fondamentale qui relie toutes les activités, événements et points de données tout au long du cycle de vie d'une réclamation. Il garantit que chaque point de contact, de la soumission initiale à la clôture finale, peut être suivi de manière cohérente dans le cadre d'un même dossier. En process mining, cet attribut est essentiel pour reconstituer le parcours de bout en bout de chaque réclamation. Il permet l'analyse des flux de processus, le calcul des temps de résolution totaux et l'identification des variations dans la manière dont les différentes réclamations sont traitées. Pourquoi c'est important C'est l'identifiant central qui relie tous les events associés en une seule instance de processus, rendant possible l'analyse de bout en bout du lifecycle du sinistre. Où obtenir Il s'agit d'une clé primaire dans les principales tables de gestion des claims au sein de FINEOS Claims. Exemples CL-2023-001234CL-2023-005678CL-2024-009101 | |||
Dernière mise à jour des données LastDataUpdate | Timestamp indiquant la dernière fois que les data pour cet event ont été rafraîchies depuis le système source. | ||
Description Cet attribut indique la date et l'heure de la dernière extraction ou mise à jour des données. Il est essentiel pour comprendre la fraîcheur et l'actualité des données analysées. Ces informations sont cruciales pour la gouvernance des données et permettent aux utilisateurs de savoir s'ils consultent les données de processus les plus récentes. Elles aident à gérer les attentes concernant la latence des données et sont vitales pour le reporting sur les processus quasi en temps réel. Pourquoi c'est important Indique la fraîcheur des données, garantissant que les utilisateurs comprennent la période couverte par l'analyse et quand elle a été rafraîchie pour la dernière fois. Où obtenir Ce timestamp est généralement généré et stocké par l'outil d'extraction de data ou ETL à la fin d'une tâche de chargement de data. Exemples 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
Système source SourceSystem | Identifie le système informatique d'où les données ont été extraites. | ||
Description Cet attribut précise l'origine des données de processus. Pour cette analyse, il s'agira systématiquement de 'FINEOS Claims', mais dans un environnement multi-systèmes, il est crucial pour la traçabilité des données et la garantie de leur qualité. Dans un contexte analytique plus large, il aide à différencier les processus qui peuvent s'étendre sur plusieurs systèmes et assure que l'interprétation des données est correcte en fonction de leur source. Pourquoi c'est important Il fournit un contexte essentiel sur l'origine des données, ce qui est crucial pour la gouvernance des données, la validation et l'intégration avec d'autres systèmes. Où obtenir Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction des data pour étiqueter l'origine du dataset. Exemples FINEOS ClaimsFINEOS Claims v11.2 | |||
Canal de soumission SubmissionChannel | La méthode ou le canal par lequel la réclamation a été initialement soumise. | ||
Description Cet attribut enregistre la manière dont le sinistre a été reçu, par exemple, via un portail en ligne, par e-mail, par courrier postal ou par l'intermédiaire d'un agent. Les différents canaux de soumission peuvent avoir un impact significatif sur la qualité des données et les délais de traitement initiaux. L'analyse du processus en fonction du canal de soumission aide à déterminer si certains canaux conduisent à un traitement plus rapide, à des taux de retravail plus élevés (par exemple, en raison d'informations manquantes) ou à de meilleurs résultats. Ces informations peuvent orienter les investissements dans l'optimisation des canaux, par exemple en améliorant les formulaires en ligne pour réduire les erreurs. Pourquoi c'est important Permet de déterminer si certains canaux d'entrée conduisent à un traitement plus efficace ou à des taux de retraitement plus élevés, informant ainsi la stratégie et les investissements liés aux canaux. Où obtenir Consultez la documentation FINEOS Claims. C'est généralement saisi lors du processus d'ouverture de réclamation et stocké dans le dossier de réclamation principal. Exemples Portail en ligneCourrierCourtierTéléphone | |||
Date cible de résolution ResolutionTargetDate | La date cible à laquelle la réclamation doit être résolue, conformément aux accords de niveau de service (SLA) ou à la réglementation. | ||
Description Cet attribut représente la date limite pour achever le processus de sinistre, telle que définie par les accords de niveau de service (SLA) ou les exigences réglementaires. Il sert de référence pour mesurer la performance réelle. Cette date est essentielle pour le suivi de la conformité aux SLA. En comparant la date réelle de clôture du sinistre avec la Date cible de résolution, il est possible de calculer le taux de conformité aux SLA, d'identifier les sinistres risquant de ne pas respecter leurs SLA et d'analyser les causes profondes des retards menant à la non-conformité. Pourquoi c'est important C'est la référence pour mesurer la conformité aux SLA. Cela permet d'identifier les sinistres en retard et d'analyser les raisons des délais. Où obtenir Consultez la documentation FINEOS Claims. Cette date est souvent calculée par des règles métier basées sur la date et le type de soumission de la réclamation. Exemples 2023-11-15T23:59:59Z2024-01-30T23:59:59Z | |||
Département Department | Le département ou l'unité commerciale responsable du traitement de l'activité ou de la réclamation. | ||
Description Cet attribut spécifie l'unité organisationnelle, telle que le 'Service de réception initiale', l''Unité d'enquête' ou le 'Département des paiements', qui est responsable d'une activité particulière ou qui est en charge du sinistre à une certaine étape. L'analyse du processus par département est cruciale pour comprendre les transferts interfonctionnels, sources fréquentes de retards. Elle aide à identifier les départements qui constituent des goulots d'étranglement, mesure l'efficacité départementale et soutient l'analyse de l'allocation des ressources à l'échelle de l'organisation. Pourquoi c'est important Permet une analyse de la performance par unité organisationnelle, mettant en évidence les retards de transfert interdépartementaux et les goulets d'étranglement au niveau des départements. Où obtenir Consultez la documentation FINEOS Claims. Cela peut être associé au profil utilisateur de l'expert en sinistres assigné ou à la file d'attente à laquelle une tâche est attribuée. Exemples Admission et enregistrementUnité des enquêtes spécialesTraitement des paiementsExamen médical | |||
Expert en sinistres désigné AssignedAdjuster | Le nom ou l'ID du gestionnaire de sinistres ou de l'utilisateur responsable de l'activité. | ||
Description Cet attribut identifie la personne ou l'équipe ayant effectué une tâche spécifique dans le processus de gestion des sinistres. C'est le moyen principal de relier les activités du processus aux ressources humaines. L'analyse des données par expert en sinistres désigné est essentielle pour comprendre la répartition de la charge de travail, la performance individuelle et l'efficacité des ressources. Elle permet de repérer les experts surchargés, d'identifier les opportunités de formation en comparant les performances et de soutenir de meilleures stratégies d'allocation des ressources pour équilibrer les charges de travail. Pourquoi c'est important Cet attribut relie les étapes du processus aux personnes qui les exécutent. Il permet ainsi l'analyse de la charge de travail, l'évaluation de l'efficacité des ressources et la comparaison des performances. Où obtenir Consultez la documentation FINEOS Claims. Ces informations sont généralement stockées dans les champs de propriété de tâche ou d'affectation d'utilisateur associés aux événements de réclamation. Exemples John SmithEmily JonesADJ-4561 | |||
Gravité du Sinistre ClaimSeverity | Une classification de la complexité ou de l'impact financier potentiel du sinistre (par ex., Faible, Moyen, Élevé). | ||
Description La gravité du sinistre attribue une évaluation à la complexité, à l'urgence ou à l'exposition financière d'une réclamation. Les réclamations de gravité élevée peuvent nécessiter plus d'étapes, un examen spécialisé ou des délais de traitement plus longs que celles de faible gravité. Analyser le processus par gravité aide à comprendre si l'allocation des ressources et la conception du processus sont appropriées pour les différents niveaux de complexité des réclamations. Cela peut révéler si les réclamations de gravité élevée subissent des retards disproportionnés ou si les réclamations de faible gravité sont sur-traitées, permettant ainsi une meilleure segmentation des processus et une meilleure gestion des ressources. Pourquoi c'est important La segmentation par gravité aide à vérifier si le processus priorise correctement les sinistres à fort impact et à identifier si certains niveaux de complexité engendrent des goulots d'étranglement. Où obtenir Consultez la documentation FINEOS Claims. Il peut s'agir d'un champ dédié ou être dérivé d'autres attributs, comme le montant estimé du sinistre. Exemples FaibleMoyenÉlevéComplexe | |||
Heure de fin EndTime | L'horodatage indiquant quand une activité ou un événement spécifique a été achevé. | ||
Description L'attribut « Heure de fin » enregistre le moment précis où une activité se termine. Associé à l'heure de début (EventTime), il permet de calculer exactement le temps qu'a pris chaque étape pour être achevée (c'est-à-dire son temps de traitement). Dans l'analyse, cet attribut est crucial pour distinguer le temps de traitement actif du temps d'attente inactif. Il permet de créer des analyses détaillées des goulots d'étranglement, montrant quelles activités spécifiques consomment le plus de temps et où des files d'attente se forment entre les étapes. Pourquoi c'est important Permet le calcul précis du temps de traitement pour chaque activité, ce qui est essentiel pour identifier les étapes inefficaces et mesurer l'utilisation des ressources. Où obtenir Consultez la documentation FINEOS Claims. Ces informations peuvent être disponibles dans les journaux d'événements ou être dérivées de l'heure de début de l'event suivant. Exemples 2023-10-26T11:30:00Z2023-10-26T15:00:15Z2023-10-27T17:00:00Z | |||
Statut du Sinistre ClaimStatus | Le statut actuel ou historique de la réclamation au moment de l'événement. | ||
Description Le statut du sinistre indique l'état de la réclamation dans son cycle de vie, tel que 'Ouvert', 'En attente d'informations', 'Approuvé', 'Refusé' ou 'Clos'. Cet attribut offre un aperçu de l'état d'avancement de la réclamation à tout moment donné. Dans l'analyse des processus, les changements de statut correspondent souvent directement aux activités du processus. Le suivi du statut est crucial pour comprendre les résultats des réclamations, identifier les goulets d'étranglement où les réclamations restent bloquées dans un statut particulier pendant de longues périodes, et analyser les raisons des résultats finaux comme 'Refusé' ou 'Clos'. Pourquoi c'est important Cet attribut est essentiel pour comprendre les issues des sinistres, filtrer les dossiers actifs par rapport aux dossiers clôturés et identifier les étapes où les sinistres stagnent. Où obtenir Consultez la documentation FINEOS Claims. Il s'agit d'un champ fondamental du dossier de réclamation principal, mis à jour tout au long de son cycle de vie. Exemples EnregistréEn cours de révisionPaiement en attenteClos - PayéClos - Refusé | |||
Type de Sinistre ClaimType | La catégorie de la réclamation d'assurance, telle que l'invalidité, les biens ou la responsabilité civile. | ||
Description Le type de sinistre classifie les réclamations en fonction de la nature de la police ou du sinistre. Différents types de réclamations suivent souvent des variations de processus distinctes, ont des exigences réglementaires différentes et nécessitent une gestion spécialisée. C'est une dimension critique pour l'analyse comparative. En filtrant ou en segmentant la vue du processus par type de sinistre, les analystes peuvent découvrir les goulets d'étranglement spécifiques à chaque type, comparer les performances entre les catégories et adapter les initiatives d'amélioration des processus aux besoins uniques de chaque type de réclamation. Cela permet de déterminer si certains types de réclamations sont intrinsèquement moins efficaces à traiter. Pourquoi c'est important Cela permet de segmenter le processus pour comparer les performances et identifier les variations entre différentes catégories de réclamations, menant à des améliorations plus ciblées. Où obtenir Consultez la documentation FINEOS Claims. Il s'agit d'un attribut essentiel d'une réclamation, généralement défini lors de l'enregistrement et stocké dans le tableau principal des dossiers. Exemples Invalidité de courte duréeInvalidité de longue duréeAssurance-vieDécès accidentel | |||
Date du sinistre LossDate | La date à laquelle l'événement ayant déclenché la réclamation d'assurance s'est produit. | ||
Description La « Date de perte » précise quand l'incident réel (par exemple, accident, blessure) s'est produit. Elle est distincte de la date de soumission de la réclamation et peut être un facteur important dans la validation et le traitement de celle-ci. Cet attribut fournit un contexte précieux. Le décalage temporel entre la date de perte et la date de « Réclamation soumise » (délai de déclaration) peut être un indicateur clé de performance. L'analyse de ce décalage peut révéler des problèmes dans les processus de déclaration et son impact sur le cycle de vie global de la réclamation. Pourquoi c'est important Fournit un contexte important et permet le calcul du décalage de déclaration (temps entre le sinistre et la soumission), ce qui peut influencer la complexité et les résultats du sinistre. Où obtenir Consultez la documentation FINEOS Claims. Cette date est un champ standard capturé lors du processus de 'Première déclaration de sinistre' ou d'enregistrement de la réclamation. Exemples 2023-10-152023-09-012024-02-20 | |||
Est un retravail IsRework | Un indicateur booléen signalant si une activité est une répétition ou une reprise de travail. | ||
Description Cet attribut calculé signale les activités qui représentent du retravail, comme un deuxième événement 'Demande d'informations supplémentaires' pour le même sinistre. Il est généralement identifié en détectant des activités répétées ou des boucles de retour dans le flux de processus. Le fait de signaler explicitement le retravail simplifie l'analyse axée sur l'inefficacité. Il permet une quantification aisée du taux de retravail, un indicateur clé de performance. Les dashboards peuvent utiliser ce drapeau pour visualiser la fréquence et l'impact du retravail, aidant à identifier les causes profondes de ces boucles inefficaces. Pourquoi c'est important Identifie directement les boucles de processus inefficaces, facilitant le calcul du taux de retouche et l'analyse des causes du retrabail. Où obtenir Ceci est dérivé pendant l'analyse de Process Mining en identifiant les activités répétées pour le même case. Par exemple, signaler la deuxième occurrence de 'Investigation Started'. Exemples truefaux | |||
État du SLA SLAState | Un statut calculé indiquant si un sinistre clôturé a respecté sa date cible de résolution. | ||
Description Cet attribut offre un statut catégorique clair concernant la performance des SLA pour chaque sinistre. Il est établi en comparant la date de 'Clôture du sinistre' à la 'Date cible de résolution' et en classant le résultat comme 'Dans les délais' ou 'En retard'. Cela simplifie la production de rapports et l'analyse du respect des SLA. Au lieu de travailler avec des dates brutes, les analystes peuvent utiliser cette catégorie simple pour créer des dashboards affichant le taux de conformité aux SLA, filtrer tous les sinistres en retard pour en analyser les caractéristiques communes et suivre l'évolution des performances des SLA au fil du temps. Il soutient directement le dashboard et le KPI de respect des SLA. Pourquoi c'est important Fournit un indicateur clair et simple de la performance SLA pour chaque dossier, facilitant ainsi la mesure et l'analyse du taux de conformité SLA. Où obtenir Il s'agit d'un champ calculé obtenu en comparant le timestamp de l'activité finale avec la 'ResolutionTargetDate' pour chaque case. Exemples À tempsEn retard | |||
Montant du paiement PaymentAmount | Le montant réel payé pour la réclamation. | ||
Description Le montant du paiement est la somme finale déboursée suite au règlement et à l'approbation d'une réclamation. Pour les réclamations avec paiements multiples, cela peut représenter une transaction de paiement individuelle. Cet attribut est essentiel pour la réconciliation financière et pour l'analyse des résultats monétaires du processus. Il permet de comparer la perte estimée initialement et le décaissement final. Dans l'analyse de processus, il aide à comprendre l'impact financier des différentes variantes ou décisions de processus. Pourquoi c'est important Suit le résultat financier du processus, ce qui est essentiel pour mesurer la performance financière et analyser la valeur des sinistres. Où obtenir Consultez la documentation FINEOS Claims. Ces données se trouvent dans les tables de transactions de paiement liées au dossier de la réclamation. Exemples 4850.00145000.000.00 | |||
Montant du sinistre LossAmount | Le montant financier estimé ou réservé associé à la perte. | ||
Description Le montant du sinistre représente l'estimation initiale ou la réserve financière constituée pour une réclamation. Cette valeur peut être mise à jour à mesure que la réclamation est examinée et évaluée. Ces données financières sont cruciales pour segmenter les réclamations et comprendre comment l'impact financier est corrélé au comportement du processus. Par exemple, elles aident à répondre à des questions telles que : Les réclamations de valeur plus élevée prennent-elles plus de temps à être traitées ou nécessitent-elles plus de retouches ? C'est également un intrant clé pour les prévisions financières et la gestion des risques. Pourquoi c'est important Apporte un contexte financier au processus, permettant d'analyser l'impact de la valeur du sinistre sur le temps de traitement, la complexité et les parcours. Où obtenir Consultez la documentation FINEOS Claims. Ces informations se trouvent généralement dans les tableaux financiers ou de réserves liés à la réclamation. Exemples 5000.00150000.00250.50 | |||
Motif de refus DenialReason | Un code ou une description expliquant le motif du refus d'un sinistre. | ||
Description Lorsqu'une réclamation est « Refusée », cet attribut fournit la raison spécifique de cette décision. Les raisons pourraient inclure « Non couvert par la police », « Fraude suspectée » ou « Informations incomplètes ». C'est un attribut essentiel pour l'analyse des causes profondes des refus de réclamations. En analysant la fréquence des différentes raisons de refus, l'organisation peut identifier les problèmes courants dans le processus de soumission, les sources de confusion pour les clients concernant la couverture de la police ou les besoins potentiels en formation pour les experts en sinistres. Cette compréhension peut conduire à des initiatives visant à réduire les taux de refus et à améliorer la satisfaction client. Pourquoi c'est important Crucial pour l'analyse des causes profondes des processus défaillants, il permet d'identifier les opportunités de réduire les refus de réclamations et d'améliorer la qualité de l'ouverture des dossiers. Où obtenir Consultez la documentation FINEOS Claims. Il s'agit généralement d'un champ structuré ou d'un code sélectionné lorsque l'activité « Réclamation refusée » est effectuée. Exemples Exclusion de policeInformations non fourniesRéclamation en doubleFraude suspectée | |||
Motif de réouverture ReopenReason | Un code ou une description expliquant la raison pour laquelle un sinistre clôturé a été rouvert. | ||
Description Cet attribut enregistre la raison pour laquelle un dossier de sinistre est passé d'un état 'Clôturé' à un état actif. Les raisons fréquentes incluent la réception de nouvelles informations, un recours de la part du demandeur ou la correction d'une erreur. L'analyse des motifs de réouverture est un moyen direct d'évaluer la qualité et la finalité d'un processus. Un volume élevé de sinistres rouverts, surtout pour certaines raisons, indique que la clôture initiale était défaillante. Ces données permettent d'identifier les lacunes dans les phases d'enquête ou de prise de décision, offrant des pistes claires pour l'amélioration des processus afin de garantir une clôture correcte dès la première fois. Pourquoi c'est important Offre un aperçu direct des échecs de processus lorsqu'un sinistre a été clôturé prématurément ou incorrectement, soulignant les opportunités d'améliorer la résolution dès la première fois. Où obtenir Consultez la documentation FINEOS Claims. Cette raison est généralement enregistrée lorsqu'un utilisateur exécute l'action « Réouvrir la réclamation » dans le système. Exemples Appel déposéNouvelles preuves médicales reçuesCorrection d'erreur administrativeAjustement de paiement nécessaire | |||
Numéro de police PolicyNumber | L'identifiant unique de la police d'assurance au titre de laquelle la réclamation est effectuée. | ||
Description Le numéro de police est l'identifiant du contrat d'assurance qui couvre la réclamation. Il relie la réclamation à un client spécifique, aux conditions de la police et aux détails de la couverture. Bien qu'il ne s'agisse pas directement d'un attribut de processus, il fournit un contexte métier essentiel. Il permet d'agréger les données de réclamations par police ou par client, ce qui peut être utile pour analyser la fréquence des réclamations, l'expérience client et identifier les polices qui génèrent un volume élevé de réclamations complexes. Pourquoi c'est important Fournit un contexte commercial essentiel, reliant le sinistre à un contrat client spécifique et permettant une analyse des processus centrée sur le client. Où obtenir Consultez la documentation FINEOS Claims. C'est une donnée fondamentale saisie lors de l'enregistrement de la réclamation et stockée dans le dossier de réclamation principal. Exemples POL-987654321POL-123456789 | |||
Région du client CustomerRegion | La région géographique ou l'état du demandeur ou du titulaire de la police. | ||
Description Cet attribut indique la localisation géographique associée au sinistre, qui peut être basée sur l'adresse du demandeur ou le lieu de l'incident. L'analyse géographique peut révéler des variations régionales dans les types de sinistres, leurs fréquences et l'efficacité de leur traitement. Elle peut aider à déterminer si certains bureaux régionaux sont plus performants que d'autres, ou si des facteurs spécifiques à un lieu (par exemple, réglementations, événements météorologiques) ont un impact sur le processus de gestion des sinistres. Cela permet une gestion et une allocation des ressources plus ciblées. Pourquoi c'est important Permet une segmentation géographique pour identifier les différences de performance régionales, les variations de conformité ou les goulets d'étranglement spécifiques à un lieu. Où obtenir Consultez la documentation FINEOS Claims. Ces informations sont généralement dérivées des détails d'adresse de l'assuré ou du demandeur stockés dans le système. Exemples NortheastCalifornieMidwestFL | |||
Temps de traitement ProcessingTime | Le temps passé à travailler activement sur une activité. | ||
Description Le "Temps de Traitement" est une métrique calculée qui mesure le temps écoulé entre le début et la fin d'une activité. Il représente le "temps d'interaction" ou la période pendant laquelle une ressource était activement engagée dans la tâche. C'est une métrique fondamentale pour l'analyse des performances. Elle permet de distinguer le temps de travail actif du temps d'attente inactif, offrant ainsi une évaluation plus précise de l'efficacité des ressources et l'identification des activités intrinsèquement chronophages. C'est un facteur clé pour le calcul des coûts opérationnels et des taux d'utilisation des experts en sinistres. Pourquoi c'est important Mesure le « temps de contact » actif pour les activités, aidant à identifier les tâches spécifiques les plus chronophages et à mesurer précisément l'efficacité des ressources. Où obtenir Ceci est calculé en soustrayant le StartTime de l'activité de son EndTime. Exemples 2 heures 30 minutes3 jours 4 heures15 minutes | |||
Activités de Gestion des Sinistres
| Activité | Description | ||
|---|---|---|---|
Décision sur le Sinistre Prise | Une étape clé où l'assureur prend une décision formelle d'approuver, d'approuver partiellement ou de refuser la réclamation. Ceci est presque toujours enregistré comme un changement de statut explicite dans FINEOS vers un état tel que 'Approved', 'Denied' ou 'Settled'. | ||
Pourquoi c'est important C'est un jalon majeur qui dicte le cheminement du processus suivant (paiement ou clôture). Il est crucial pour mesurer le délai de décision et analyser les issues des sinistres. Où obtenir Déduit du timestamp dans la table d'historique des statuts du sinistre correspondant à un statut de décision finale (par ex., 'Approuvé', 'Rejeté', 'Refusé'). Capture Timestamp du changement de statut à 'Approuvé' ou 'Refusé'. Type d'événement inferred | |||
Paiement autorisé | Représente l'approbation formelle du montant de règlement calculé à payer. Il s'agit souvent d'une étape distincte de la décision de sinistre, nécessitant qu'un gestionnaire ou une équipe spécifique autorise le décaissement. Ceci est enregistré par un changement de statut tel que "Approuvé pour paiement". | ||
Pourquoi c'est important Cette activité est essentielle pour le KPI « Temps de cycle d'autorisation de paiement ». Les retards entre la décision et l'autorisation peuvent constituer un goulot d'étranglement caché important, affectant la satisfaction client. Où obtenir Déduit du timestamp d'un changement de statut vers 'Paiement en attente', 'Prêt pour paiement' ou 'Paiement autorisé' dans l'historique des statuts du sinistre. Capture Timestamp du changement de statut à 'Approuvé pour paiement' ou similaire. Type d'événement inferred | |||
Paiement émis | Marque le moment où le paiement est effectivement traité et envoyé au demandeur ou au fournisseur. Dans FINEOS, ceci est souvent déclenché par une intégration avec un système financier et est enregistré comme un journal de transaction ou une mise à jour du statut final du paiement. | ||
Pourquoi c'est important Il s'agit d'un moment de vérité crucial pour le client. L'analyse du temps écoulé entre l'autorisation et l'émission permet de fluidifier le processus de paiement et d'améliorer l'expérience client. Où obtenir Peut être un événement explicite issu d'une table de journal des transactions de paiement au sein de FINEOS ou d'un système de comptes fournisseurs intégré. Un changement de statut à 'Payé' est également une source probable. Capture Utilisez la date de transaction du grand livre des paiements ou le timestamp du changement de statut à 'Payé'. Type d'événement explicit | |||
Sinistre Clos | Marque l'état final et terminal d'une réclamation dans le système, une fois toutes les activités, y compris le paiement ou le refus, achevées. Cet événement est enregistré lorsque le statut de la réclamation est mis à jour à 'Clôturée' ou 'Finalisée' dans FINEOS. | ||
Pourquoi c'est important Cette activité est l'événement de fin principal du processus. Le temps écoulé entre la « Réclamation soumise » et la « Réclamation clôturée » est un KPI maître pour mesurer la performance et l'efficacité globales du processus. Où obtenir Déduit du timestamp du changement de statut final vers 'Fermé' dans le journal d'historique des statuts du sinistre. Il s'agit de la dernière mise à jour de statut enregistrée pour un sinistre traité avec succès. Capture Timestamp du changement de statut final à 'Clôturé' ou 'Finalisé'. Type d'événement inferred | |||
Sinistre Déclaré | Marque la réception initiale d'une réclamation par l'organisation, souvent via divers canaux comme les portails web, les e-mails ou le courrier. C'est le point de départ du processus de réclamation et est généralement capturé lorsque la Première Notification de Sinistre (FNOL) est saisie dans une zone de transit ou directement dans FINEOS. | ||
Pourquoi c'est important Cette activité est l'événement de début principal du processus. L'analyse du temps entre la soumission et l'enregistrement aide à identifier les retards dans la saisie des données et la configuration initiale de la réclamation, impactant ainsi le temps de cycle global. Où obtenir Probablement capturé à partir de la date de création de l'enregistrement de notification de sinistre initial ou de l'entrée FNOL dans FINEOS. Il peut s'agir d'un journal d'événements explicite ou déduit du timestamp le plus ancien associé à l'ID de la réclamation. Capture Utilisez le timestamp de création de la Première Déclaration de Sinistre (PDS) ou de l'enregistrement initial du sinistre. Type d'événement inferred | |||
Sinistre Enregistré | Représente la création formelle de l'enregistrement du sinistre au sein du système FINEOS. À ce stade, un ID de sinistre unique est officiellement attribué et le dossier est formellement ouvert pour traitement. Cet événement est généralement capturé à partir de l'horodatage de création de l'objet sinistre principal. | ||
Pourquoi c'est important C'est un jalon crucial qui fait passer le sinistre d'une simple notification à un case actif. Il constitue un point de départ fiable pour mesurer le lifecycle de traitement interne. Où obtenir Dérivé de l'horodatage de création de l'entité de dossier de réclamation principale dans la base de données FINEOS. La plupart des objets système principaux ont une « date de création » suivie à des fins d'audit. Capture Utilisez le timestamp de création de l'enregistrement principal du case de sinistre. Type d'événement explicit | |||
Enquête démarrée | Représente le début de la phase formelle d'enquête ou d'adjudication du sinistre. Ceci est souvent enregistré lorsque le sinistre est attribué à un enquêteur ou lorsque son statut est explicitement modifié en "Sous enquête" dans FINEOS. | ||
Pourquoi c'est important Ce jalon marque le début d'une partie potentiellement longue et complexe du processus. Le suivi de son heure de début est essentiel pour mesurer la durée et l'efficacité de la phase d'investigation. Où obtenir Déduit du timestamp d'un changement de statut vers 'Enquête en cours' ou 'Jugement en cours'. Pourrait également être lié à la date d'affectation d'un rôle d'enquêteur au sinistre. Capture Timestamp du changement de statut du sinistre à 'Sous investigation'. Type d'événement inferred | |||
Enquête terminée | Indique que toutes les activités d'enquête nécessaires sont terminées et que la réclamation est prête pour une décision finale. Ceci est déduit d'un changement de statut, passant de « Enquête en cours » à un état ultérieur tel que « Décision en attente » ou « Prêt pour évaluation ». | ||
Pourquoi c'est important Cette activité marque la fin de la phase de collecte de preuves. L'analyse du temps écoulé entre le début de l'« Enquête » et ce point aide à identifier les goulots d'étranglement dans le processus d'arbitrage lui-même. Où obtenir Déduit du timestamp lorsque le statut du sinistre passe d''Enquête en cours' à un état indiquant que la phase de décision ou d'évaluation est la suivante. Capture Timestamp du changement de statut du sinistre de 'Sous investigation' à 'Prêt pour décision'. Type d'événement inferred | |||
Examen initial effectué | Indique qu'un expert ou un gestionnaire a terminé la première évaluation de la validité, des détails et des documents requis du sinistre. Ceci est souvent déduit d'un changement de statut dans FINEOS, comme le passage de 'New' ou 'Registered' à 'Under Review' ou 'Assigned'. | ||
Pourquoi c'est important Le suivi de l'achèvement de cette étape aide à mesurer le délai avant la première action et identifie les arriérés dans la phase initiale de triage et d'affectation. Les retards à ce stade peuvent prolonger considérablement le lifecycle global du sinistre. Où obtenir Déduit du timestamp lorsque le statut du sinistre passe à un état indiquant que l'examen est terminé (par ex., 'Examen initial terminé', 'Informations en attente', 'Enquête en cours'). Ces données se trouvent généralement dans une table d'historique des statuts du sinistre. Capture Identifier le timestamp du changement de statut de 'New' ou 'Open' vers un statut post-examen. Type d'événement inferred | |||
Informations supplémentaires demandées | Cette activité se produit lorsque le gestionnaire de réclamations détermine que des informations supplémentaires sont nécessaires de la part du demandeur ou d'un tiers pour poursuivre le traitement. Dans FINEOS, cela est souvent enregistré par un changement de statut vers « Informations en attente » ou par l'enregistrement d'un événement de communication sortante spécifique. | ||
Pourquoi c'est important Cette activité est critique pour l'analyse des retouches et des boucles de processus. Une fréquence élevée de cet event suggère des problèmes de collecte initiale des data et peut être une source majeure de retards. Où obtenir Déduit d'un changement de statut du sinistre vers 'Informations en attente' ou similaire. Il pourrait aussi s'agir d'un event explicite enregistré lorsqu'une correspondance demandant des informations est générée par le système. Capture Timestamp du changement de statut à 'Information en attente' ou entrée de log pour une demande d'information par lettre/email. Type d'événement inferred | |||
Informations supplémentaires reçues | Marque la réception des documents ou informations demandés, permettant la reprise du traitement de la réclamation. Cet événement est généralement déduit lorsque le statut de la réclamation passe de 'En attente d'informations' à un état actif comme 'En cours d'examen' ou 'Prêt pour évaluation'. | ||
Pourquoi c'est important Mesurer le temps entre la demande et la réception d'informations met en évidence les retards externes. Cela signale également le redémarrage du traitement interne, ce qui en fait un élément clé pour analyser les temps d'attente et les blocages de processus. Où obtenir Déduit du timestamp lorsque le statut du sinistre passe d'un état 'En attente' à un état 'Actif' ou 'En cours'. Un event de téléversement de document associé pourrait également fournir un timestamp spécifique. Capture Timestamp du changement de statut de 'Information en attente' à un statut de traitement actif. Type d'événement inferred | |||
Réclamation rouverte | Se produit lorsqu'une réclamation précédemment clôturée est réactivée pour un examen ou un traitement supplémentaire, souvent en raison d'un appel ou de nouvelles informations. Cet événement est capturé par un changement de statut, passant d'un état 'Clôturée' ou 'Refusée' à un état actif comme 'En cours d'examen'. | ||
Pourquoi c'est important Le suivi des sinistres rouverts est essentiel pour comprendre les exceptions et les défaillances de processus. Il met en évidence les cases qui n'ont pas été résolus correctement du premier coup, qui impactent l'efficacité et les coûts opérationnels. Où obtenir Déduit d'un changement de statut d'un état terminal (par ex., 'Fermé') à un état non-terminal et actif (par ex., 'Rouvert', 'En cours d'examen'). Ceci nécessite l'analyse de la séquence des changements de statut au fil du temps. Capture Identifier le timestamp où le statut passe d'un état fermé à un état ouvert. Type d'événement inferred | |||
Règlement calculé | Intervient après une décision d'approbation, où le montant exact du paiement est calculé en fonction des limites de la police, des franchises et des pertes évaluées. Ceci est probablement capturé lorsque le champ du montant final du paiement ou du règlement est saisi et confirmé dans FINEOS. | ||
Pourquoi c'est important Cette activité isole l'étape de calcul des étapes d'approbation et d'autorisation de paiement. Elle aide à analyser l'efficacité de l'équipe financière dans la finalisation des montants de paiement. Où obtenir Déduit du timestamp lorsque le montant final du règlement ou du paiement est entré ou mis à jour dans les dossiers financiers du système pour le sinistre. Capture Utilisez le timestamp de 'dernière mise à jour' sur le champ du montant de règlement final. Type d'événement inferred | |||
Sinistre évalué | Indique que l'impact financier du sinistre a été calculé et enregistré. Cela peut impliquer l'évaluation des dommages, des coûts médicaux ou d'autres responsabilités. Cet event est souvent capturé lorsque des champs d'évaluation financière spécifiques sont remplis et sauvegardés dans FINEOS. | ||
Pourquoi c'est important C'est un jalon financier clé. Le temps nécessaire pour évaluer la perte après la fin de l'investigation peut être un indicateur de performance pour l'équipe d'évaluation. Où obtenir Probablement déduit du timestamp lorsque les champs de réserve financière ou d'estimation de perte sont renseignés ou finalisés pour la première fois dans le système. Il ne s'agit peut-être pas d'un statut distinct, mais plutôt d'un événement de saisie de données. Capture Utilisez le timestamp de 'dernière mise à jour' sur les champs de data liés à l'évaluation financière ou aux réserves. Type d'événement inferred | |||
Sinistre Refusé | Représente le résultat final pour un sinistre qui n'est pas approuvé pour paiement. Cet événement est enregistré lorsque le statut du sinistre est définitivement défini comme "Refusé" ou "Rejeté". Il s'agit d'un point de terminaison alternatif au processus. | ||
Pourquoi c'est important Cette activité est un point de terminaison essentiel du processus. L'analyse des parcours menant au refus peut fournir des informations sur la qualité de la réception des réclamations, l'interprétation des politiques ou les schémas de fraude potentiels. Où obtenir Déduit du timestamp lorsque le statut final du sinistre est enregistré comme 'Refusé' ou 'Rejeté' dans la table d'historique des statuts. Capture Timestamp du changement de statut final à 'Refusé' ou 'Rejeté'. Type d'événement inferred | |||
Guides d'extraction
Les méthodes d'extraction pour ce processus sont en cours de validation. Veuillez revenir plus tard ou contactez-nous pour obtenir de l'aide.
