Modèle de données : Traitement des réclamations

FINEOS Claims
Modèle de données : Traitement des réclamations

Votre modèle de données pour le traitement des sinistres

Ce modèle propose une approche structurée pour la collecte des data essentielles à une analyse efficace du processus de sinistres. Il décrit les attributs clés et les activités principales à suivre, ainsi que des conseils pratiques pour extraire ces informations de vos systèmes source. Utilisez-le pour préparer votre event log et accélérer votre parcours vers un traitement des sinistres optimisé.
  • 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
Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de Gestion des Sinistres

Voici les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de vos workflows de traitement des réclamations.
5 Obligatoire 8 Recommandé 10 Facultatif
NomDescription
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
Obligatoire Recommandé Facultatif

Activités de Gestion des Sinistres

Ce sont les étapes clés du processus et les jalons à enregistrer dans votre journal d'événements pour une découverte précise des processus et l'identification des goulets d'étranglement.
6 Recommandé 9 Facultatif
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
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de FINEOS Claims

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.