20/01/2017 : adaptation : ajout de quelques explications en vue du fonctionnement question/réponse de l’échange contextuel.
16/07/2015 : version publiée comme « recommandation »
Nous cherchons une manière simple de gérer/communiquer l’historique sinistres, en vue d’une tarification.
Dans la pratique, une tarification nécessite un minimum d’informations, y compris un minimum d’informations à sujet des sinistres.
Le système du « échange contextuel » fonctionne grâce à une standardisation des formats et une normalisation du contenu significatif de ce qu’est échangé entre le système de gestion du courtier et le module/environnement de l’assureur.
Une solution simple est :
Que le preneur d’assurance s’exprime/déclare (Edifact : QRS « Declaration ») avoir oui/non un historique sinistres.
Dans le cas « oui » cet historique est à détailler.
Des déclarations supplémentaires, par sinistre, offrent ce détail.
La majorité des assureurs demandent tel historique que pour une ancienneté limitée dans le temps ; typiquement ils demandent l’historique des 3/5 dernières années.
Du point de vue du courtier, ceci est une fenêtre sur tel historique, se déplaçant dans le temps.
Un élément individuel de tel historique peut se présenter comme : RDT (Edifact « response detail ») composé des
- Année/mois/jour : DTM+048 en formats variantes permises AAA / MMAAAA / JJMMAAAA
- Garantie : idéalement le ICD avec son qualifiant sectoriel
- Responsabilité : ATT+C250 « Responsabilité ou responsabilité probable »
Il n’y a donc que trois éléments à fournir par sinistre vécu.
- L’élément date est plus ou moins « complète » suivant ce que le client a encore en mémoire.
- L’élément garantie et exprimé en langage sectoriel et donc uniforme.
- L’élément responsabilité est aussi exprimé en langage sectoriel.
Ainsi le courtier a la possibilité de compléter/maintenir en permanence tel historique pour ses clients.
On peut imaginer une fonction en direction de la demande de tarification, laquelle va regarder/analyser tel historique par une « fenêtre » de 3 ou 5 années
Exemple imaginaire de tel genre d’historique :
| N° d'ordre | Date | Garantie | Responsabilité |
|---|---|---|---|
| 8 | 20/09/2014 | 510 – RC Véhicule Automoteur | 2 – Partie adverse est responsable |
| 7 | 15/03/2013 | 310 – Incendie | 8 – Non applicable |
| 6 | 20/12/2011 | 553 – Bris de vitres (Véhicule) | 8 – Non applicable |
| 5 | 15/09/2011 | 412 – RC Familiale (AR + extensions) | 1 – Assuré est responsable |
| 4 | 07/2010 | 553 – Bris de vitres (Véhicule) | 8 – Non applicable |
| 3 | 01/2010 | 552 – Vol (Véhicule) | 8 – Non applicable |
| 2 | 12/2009 | 540 – Omnium totale | 8 – Non applicable |
| 1 | 2008 | 510 – RC Véhicule Automoteur | 1 – Assuré est responsable |
Le 19/06/2015 :
Une application tarifaire « auto » regardant les 3 dernières années prendra en compte les cas : 8
Une application tarifaire « auto » regardant les 5 dernières années prendra en compte les cas : 8 / 6 / 4
Le Groupe de Travail de Normalisation, en session le 02/07/2015, accepte cette approche.
Après une analyse détaillée du Telebib2 existant, est opté pour :
- Un nouveau qualifiant QRS+AV00 « historique sinistres communiqué / schadehistoriek medegedeeld ».
- Une élaboration du RDT+A1D2 « type de sinistre / type schadegeval » existant en y ajoutant les codes de nos qualifiants ICD – garanties.
- L’ajout sous tel RDT+A1D2 des DTM+048 et ATT+C250.
Notre idée devient alors que le courtier communique l’historique dans son ensemble, et que l’assureur y regarde/recherche ce que lui intéresse.
Le concept/principe de fonctionnement de l’échange contextuel est que l’un « pose une question » à laquelle l’autre « répond ».
- La « question » est un string edifact composé de tag qualifiés mais sans contenu.
- La « réponse » est ce string y compris le contenu.
- La documentation (historique) de ce concept/principe ne s’exprime pas clairement au sujet de la multiplicité éventuelle en sein de la réponse.
Si je vous demande combien et quels sinistres vous avez eu, je ne sais pas à l’avance si il y en a eu 0/1/2/3/ Il est donc plausible que tel string-question est de style :
- XRH+1’
- PTY+003’
- ...
- XRH+2’
- QRS+AV00’
- XRH+3’RDT+A1D2’DTM+048’ATT+C250’XRT+3’
- XRT+2’
- XRH+1
- ...
Et il est plausible que la réponse peut être de style :
- XRH+1’
- PTY+003’
- ...
- XRH+2’
- QRS+AV00’
- XRH+3’RDT+A1D2’DTM+048’ATT+C250’XRT+3’
- XRH+3’RDT+A1D2’DTM+048’ATT+C250’XRT+3’
- XRH+3’RDT+A1D2’DTM+048’ATT+C250’XRT+3’
- XRT+2’
- XRH+1’
- ...
Ce commentaire au sujet du concept/principe a été formulé après relecture du document « Assurnet2 – Interfaces entre le package et les applications client/serveur AS/2 ».