11 - Een veralgemeende schadehistoriek

20/01/2017 – Aanpassing:** toevoeging van enkele toelichtingen met betrekking tot de vraag-en-antwoordwerking van de contextuele uitwisseling.  
16/07/2015 – Publicatie:** versie gepubliceerd als “aanbeveling”.

We zoeken naar een eenvoudige manier om de schadehistoriek te beheren en te communiceren met het oog op een tarifering.

In de praktijk vereist een tarifering een minimum aan informatie, waaronder informatie over de schadegevallen.

Het systeem van de “contextuele uitwisseling” werkt dankzij de standaardisering van de formaten en de normalisering van de betekenisvolle inhoud die wordt uitgewisseld tussen het beheersysteem van de makelaar en de module of omgeving van de verzekeraar.

Een eenvoudige oplossing bestaat erin dat de verzekeringnemer verklaart of hij al dan niet een schadehistoriek heeft — EDIFACT: QRS “Declaration”.

Indien het antwoord “ja” is, moet deze historiek nader worden toegelicht.

Aanvullende verklaringen per schadegeval verschaffen deze details.

De meeste verzekeraars vragen slechts een historiek over een beperkte periode. Doorgaans betreft dit de laatste drie of vijf jaar.

Vanuit het standpunt van de makelaar is dit een in de tijd verschuivend venster op de schadehistoriek.

Een afzonderlijk element van deze historiek kan worden weergegeven als een RDT — EDIFACT “Response Detail” — bestaande uit:

• Jaar/maand/dag:** DTM+048, in de toegestane formaten AAAA, MMAAAA of JJMMAAAA;
• Waarborg:** bij voorkeur de ICD-code met de bijbehorende sectorale kwalificatie;
• Aansprakelijkheid:** ATT+C250 “Aansprakelijkheid of vermoedelijke aansprakelijkheid”.

Per schadegeval moeten dus slechts drie elementen worden verstrekt.

• Het datumelement is meer of minder volledig, afhankelijk van wat de klant zich nog herinnert.  
• Het waarborgelement wordt uitgedrukt in uniforme sectorale termen.  
• Ook het aansprakelijkheidselement wordt in sectorale termen uitgedrukt.

Zo kan de makelaar de schadehistoriek van zijn klanten permanent aanvullen en bijhouden.

Men kan zich een functie voor de tariferingsaanvraag voorstellen die deze historiek analyseert aan de hand van een venster van drie of vijf jaar.

Fictief voorbeeld van een dergelijke historiek

Op 19/06/2015:

Een tariferingstoepassing voor motorrijtuigen die rekening houdt met de laatste drie jaar, zal geval 8 in aanmerking nemen.

Een tariferingstoepassing voor motorrijtuigen die rekening houdt met de laatste vijf jaar, zal de gevallen 8, 6 en 4 in aanmerking nemen.

De Werkgroep Normalisatie heeft deze aanpak tijdens de vergadering van 02/07/2015 goedgekeurd.

Na een gedetailleerde analyse van het bestaande Telebib2 is gekozen voor:

• een nieuwe qualifier QRS+AV00: “schadehistoriek meegedeeld”;
• een uitbreiding van het bestaande RDT+A1D2 “type schadegeval”, door de codes van onze ICD-qualifiers voor waarborgen toe te voegen;
• de toevoeging van DTM+048 en ATT+C250 onder dit RDT+A1D2.

Ons uitgangspunt wordt dan dat de makelaar de volledige schadehistoriek meedeelt en dat de verzekeraar daarin de voor hem relevante informatie opzoekt.

• Het werkingsconcept van de contextuele uitwisseling houdt in dat de ene partij “een vraag stelt”, waarop de andere partij “antwoordt”.
• De “vraag” is een EDIFACT-string die bestaat uit gekwalificeerde tags zonder inhoud. Het “antwoord” bestaat uit diezelfde string, aangevuld met de inhoud.
• De documentatie en historiek van dit concept geven geen duidelijke uitleg over een mogelijke meervoudigheid binnen het antwoord.

Als ik u vraag hoeveel en welke schadegevallen u hebt gehad, weet ik niet vooraf of het er 0, 1, 2, 3 of meer zijn.

Het is daarom aannemelijk dat een dergelijke vraagstring er als volgt uitziet:

• XRH+1’
• PTY+003’
• ...
  • XRH+2’
  • QRS+AV00’
    • XRH+3’RDT+A1D2’DTM+048’ATT+C250’XRT+3’
  • XRT+2’
• XRH+1
• ...

Het is eveneens aannemelijk dat het antwoord er als volgt uitziet:

• 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’
• ...

Deze opmerking over het concept en het werkingsprincipe werd geformuleerd na herlezing van het document “Assurnet2 – Interfaces entre le package et les applications client/serveur AS/2”.