TECHNISCH NOTA RDR E-PLATFORM Stap1

Versie 6. 01/10/2012

1. Inleiding.

De verzekeringsondernemingen zoeken een enkel elektronisch kanaal om de uitwisseling van de RDR gegevens af te werken. Dit kanaal moet de verschillende bestaande communicatiemiddelen tussen de maatschappijen onderling vervangen en de doorstroming verbeteren. Om de wildgroei aan partners tegen te gaan, opteert men voor een structuur waarbij alle verbindingen via Datassur verlopen. Datassur wordt dus als het ware de as van een reuzenrad, waarbij de spaken de gegevensstromen zijn, en de verzekeringsondernemingen in de gondels zitten. De afdelingsvergadering Auto heeft beslist om een eerste fase te ontwikkelen beperkt tot de volgende processen:1

1. Het versturen van het schadebericht door de directe verzekeraar aan de verzekeraar-tegenpartij.

2. Het beantwoorden van het schadebericht door de verzekeraar-tegenpartij.

3. Het uitwisselen van de versies.

De betrokken verzekeraars binnen dit platform zijn deze die tot de overeenkomst zijn toegetreden en in eenzelfde ongeval betrokken zijn. Dit kunnen bijgevolg een directe verzekeraar, verzekeraar tegenpartij, of verzekeraar eigen schade zijn.

Het gebruik van de velden beschreven in dit ontwerp zijn:

− ofwel verplicht (V).

− ofwel facultatief (F).

− ofwel moet minstens één rubriek worden ingevuld (1).

− ofwel automatisch aangeleverd door het platform zelf (A).

De andere stappen in het RDR proces zullen in een volgende fase eveneens via dit kanaal gebeuren maar komen nu nog niet aan bod.

Dit platform za in werking treden op 1 januari maart 2013. De uitwisseling van de berichten tussen verzekeringsondernemingen zal alleen via dit kanaal verlopen.

2. ProcessFlow.

Onderstaande figuur geeft een schets weer van de ganse flow en de verschillende processen met betrekking tot de uitvoering van de drie hierboven genoemde stappen.

1 Er bestaan een 19 tal stappen in het RDR proces. Het uitgewerkt systeem is uitbreidbaar en de volgende stappen kunnen dan ook in een later stadium stapsgewijs worden toegevoegd.

Figuur 1: ProcessFlow van het RDR platform rond de uitwisseling van schadeberichten.

In figuur 1 kan men de verschillende betrokken instanties onderscheiden: de verzekeraar, de tegenpartij, Veridass en het centraal platform van Datassur. Het gans proces voor de uitwisseling van de berichten zal op een gecoördineerde manier in verschillende stappen verlopen (aangeduid met een omcirkeld cijfer):

1. Versturen van het schadebericht.

Deze procedure vormt het eerste contact tussen de directe verzekeraar en de verzekeraar- tegenpartij, wanneer de eerste overgaat tot een expertise van de schade aan het voertuig van zijn verzekerde in het raam van de toepassing van de overeenkomst. Deze verzending is verplicht (410-D-1, punt 3.3.) en stelt de tegenpartij in gebreke. In het kader van een RDR- procedure is het zo dat wanneer een verzekeraar de verzending van een document bewijst, de geadresseerde geacht wordt dit ontvangen te hebben, ook al is dit niet zo. In het raam van de verzending van het schadebericht kan deze procedure de verzekeraar tegenpartij in problemen brengen wanneer hij de niet-verzekering wil laten gelden, wat hij moet doen uiterlijk 30 dagen na de verzending van het schadebericht (410-D-2, punt 3.6.). Dit is echter onmogelijk wanneer het schadebericht nooit op zijn bestemming is aangekomen. De verzending van dit schadebericht via elektronische weg biedt de verzekeraars een garantie betreffende de verzending zelf en maakt het mogelijk data na te kijken ingeval van geschil.

De verschillende verzekeringsmaatschappijen registreren de schadeberichten bij Datassur ofwel via een online webapplicatie (geval per geval) ofwel via een batch-xml met gegroepeerde schadeberichten voor een groot aantal gevallen (“RDRinsurance.xml”), dit via FTP op de directory (root\requests) (zie stap 1 in ProcessFlow) of eventueel ook via de webapplicatie .

🡺 Normaal worden alle schadeberichten die via xml gebeuren, binnen de 10 minuten behandeld.2 De maatschappijen kunnen ook vrij het tijdstip van het opsturen van de xml bepalen. Er verschijnt een antwoord RDRinsurance_output.xml (zie stap 1’ in ProcessFlow).

In deze schadeberichten worden steeds volgende gegevens vermeld:

• Gegevens over verzekeraar X

- Soort document (V).

Aan de hand van deze code wordt herkend over welke boodschap het gaat. In deze fase gaat het over het versturen van een schadebericht door verzekeraar X. Voor elk soort document zal in de batch xml een nieuwe blok voorzien worden. In de webapplicatie, wordt het soort document automatisch achter de schermen gegenereerd omdat de context dan automatisch gekend is.

-Datum verzending (A). Deze datum wordt automatisch aangemaakt door het platform op het ogenblik van het verkrijgen van dit bericht.

-NBB-code van verzekeraar X (V). De identificatie van verzekeraar X gebeurt door een verplichte opgave van het NBB-nummer.

-Hoedanigheid van verzekeraar X (V). De verzekeraar kan verschillende hoedanigheden hebben en kan optreden als: 3

▪ directe verzekeraar (1).

▪ eigen verzekeraar (2).

▪ of beide (3).

-Contractnummer (F). Het betreft het polisnummer van verzekeraar X. Het gegeven is echter facultatief.

-Schadenummer (V). De opgave van het schadenummer van verzekeraar X is verplicht.

-Naam van de verzekerde (V).

-Voornaam van de verzekerde (F).

-Merk van het voertuig (V).

-Identificatie van het voertuig (V). Deze rubriek is verplicht en minstens 1 van de 3 hierna vermelde rubrieken moet worden ingevuld:

▪ Nummerplaat

▪ Onderstelnummer

2 Dit is mogelijk door de implementatie van een webservice van het “file binding” type op het centraal platform.

3 De codes tussen haakjes in het blauw geven de waarden weer die in de xml tag of database voor dit veld zullen worden gebruikt.

▪ Geen gegevens: Indien de verzekeraar geen informatie heeft rond het plaatnummer en/of onderstelnummer, dan dient de rubriek “geen gegevens” te worden ingevuld, teneinde aan te tonen dat hij niet vergeten heeft de aanwezigheid over deze informatie te hebben opgezocht.

-Adres (V): straat, postcode en gemeente verplicht; huisnummer, busnr en landcode (default is België) zijn niet verplicht.4

-Bestuurder (F). De gegevens (naam en voornaam) over de bestuurder van het voertuig van verzekeraar X zijn echter facultatief.

• Gegevens over verzekeraar Y

-NBB-code (V) . De identificatiecode van de verzekeraar-tegenpartij is een verplicht gegeven om te weten aan wie het schadebericht moet worden overgemaakt.

-Contractnummer (1).

-Naam van de verzekerde (1).

-Voornaam van de verzekerde (F).

-Adres (1).

-Merk van het voertuig (1).

-Nummerplaat (1).

-Naam en voornaam bestuurder (F).

Minstens het contractnummer of de gegevens van de verzekerde van verzekeraar Y, of de gegevens van het voertuig van verzekeraar Y, dienen te worden opgegeven om de verzekeraartegenpartij toe te laten over voldoende informatie te beschikken om zijn dossier te identificeren. De identiteit van de bestuurder van het voertuig van verzekeraar Y is facultatief.

• Gegevens over het ongeval (volgens aanrijdingformulier)

-Datum van het ongeval (V). Dit mag maximum 5 jaar in het verleden gebeurd

zijn.

-Postcode van de plaats van het ongeval(F).

-Andere voertuigen betrokken(V). De aanduiding of andere voertuigen

betrokken zijn bij het ongeval naast die van X en Y is een verplicht gegeven. Minstens 1 van de 3 hierna vermelde rubrieken moet ingevuld worden:

▪ Ja (1).

▪ Neen (2).

▪ Niet gekend (3).

-Voorbehoud lichamelijke schade (V). Minstens 1 van de 3 hierna vermelde rubrieken moet ingevuld worden:

▪ Ja (1).

▪ Neen(2).

4 De landcode is niet verplicht, maar als het ingevuld is, dient het de telebib norm te respecteren (maximaal 3 posities) zodat over de verzekeraars heen een uniforme standaard zal gehanteerd worden. Deze norm is te vinden op: xxxx://xxx.xxxxxxx0.xxx/xxxxxXxxxXxxxxxxXxxx.xxx?xxxxxxx000X&Xxxxxxxx0

▪ Niet gekend(3).

• Gegevens over het schadebeheer

-Geval van RDR-barema (F).

Het betreft het baremanummer dat verzekeraar X meent te kunnen toepassen. Dit gegeven kan niet worden verplicht omdat er ook in RDR kan geregeld worden op basis van een akkoord buiten de toepassing van een baremageval.

-Expertise (V). Verzekeraar X dient verplicht te melden of er een expertise door hem zal worden uitgevoerd: ja/nee. De gegevens van de gemandateerde expert (volgens expertiseovereenkomst of volgens eigen schade) kunnen worden vermeld :

▪ Naam.

▪ Voornaam.

- Soort versie (V). Verzekeraar X dient verplicht te melden over welke versie van zijn verzekerde hij beschikt:

▪ Een gemeenschappelijk aanrijdingformulier (1).

▪ Een eenzijdige versie (2).

- Bijlage (F). De versie van de aanrijding van de verzekerde van verzekeraar X kan steeds als bijlage worden toegevoegd.

🡺 Het systeem aanvaardt alleen versies in PDF formaat.5 Deze versies kunnen via de webapplicatie opgestuurd worden of via FTP op de directory (root\versionupload) van de server. De bestanden die gekoppeld zijn aan de schadeberichten in de batch xml moeten eerst opgeladen worden, daarna de batch xml. Indien het schadebericht in de batch xml verwijst naar een versie en deze bestaat nog niet in de directory, wordt het schadebericht verworpen.6 Deze versies zullen gekopieerd worden naar de verzekeraar tegenpartij op de directory (root\versiondownload) van de server.7

🡺 Het systeem kan meerdere versies per berichttype aanvaarden; Er is dus geen beperking van het aantal versies voor een bericht.8 De chronologie van de ingediende berichten zullen kunnen worden vastgesteld. Voorlopig wordt er

5 Datassur moet de onveranderlijkheid van de doorgestuurde documenten kunnen garanderen. Er is geen beperking wat betreft het type PDF document.

6 Een PDF kan in theorie ook als attachment in binary formaat worden toegevoegd. In praktijk kan dit tot fouten leiden bij het opladen (problemen met character sets, voorkomen van tags waardoor de xml onleesbaar wordt,…) en kunnen de bestanden te groot worden.

7 Wegens de grootte van PDF bestanden zullen de versies tot 3 6 maanden na de definitieve compensatie (of bij gebrek aan compensatie, 1 jaar na opening van het platform dossier) bewaard worden en dan gearchiveerd.. De versies zullen in eerst drie maanden in de directory “versiondownload” van de verzekeraar worden bewaard en dan naar een andere raadpleegbare directory “versiondownloadbackup” worden gemigreerd. Indien na die periode alsnog een versie geconsulteerd zou moeten worden, dient een mail naar xxxxxxxx@xxxxxxxx.xx opgestuurd te worden met vermelding van het uniek identificatienummer (of het schadenummer en nbb van de verzekeraar tegenpartij) waarvoor de versie dient opgezocht te worden..

8 Voor het versturen van versies via de web applicatie, kunnen twee zelfde bestanden worden opgestuurd. Bij het versturen van de versie, wordt op de server dit bestand hernoemd met als naam een concatenatie van een ophogend volgnummer + identificatienummer van het daarmee gekoppeld bericht. Zo worden versies van andere berichten met dezelfde bestandsnaam niet overschreven. Voor het versturen van versies via FTP, zullen de bestanden ook hernoemd worden. Bij de verspreiding van de versies mogen immers geen conflicten optreden: twee bestanden met dezelfde bestandsnaam komend van twee verschillende verzekeraars en die naar dezelfde verzekeraar tegenpartij moeten opgestuurd worden moeten behouden blijven en er mag geen versie overschreven worden daar de versies in één bepaalde directory op de server bewaard worden. De bestandsnaam van het origineel bestand zal wel steeds worden bewaard. Via FTP zullen er geen rechten worden toegekend om bestanden te schrappen, waardoor bestanden die door de webapplicatie werden verzonden niet per ongeluk worden verwijderd. Er is geen richtlijn voor de naamgeving van de versie , maar voor de gemakkelijkheid is het aangewezen om dit te noemen naar het intern polisnummer “polisnummer.pdf” (of intern schadenummer). Indien er meerdere versies zouden zijn wordt de volgende “polisnummer_v2.pdf” genoemd enz.

Field Code Changed

geen beperking gelegd op de grootte van het bestand. De testen zullen uitwijzen of een beperking nodig is.

Een schadebericht zal een aantal validiteitcontroles ondergaan voordat het geregistreerd kan worden. Die controles betreffen onder andere de verplichting tot invulling van de verplichte rubrieken en de validiteit van de ingevulde velden. Als het schadebericht niet conform is, wordt het verworpen met vermelding van de reden van verwerping. Indien het schadebericht via de webapplicatie gebeurt, wordt de reden van weigering onmiddellijk getoond. Indien het schadebericht via xml gebeurt, wordt de reden van weigering aan de hand van een specifieke foutcode weergegeven. Een xml dat niet conform het schema is, wordt door het systeem verworpen en dus nooit opgeladen (zie paragraaf 7 en8).

Er wordt door het centraal platform voor elke nieuw bericht een uniek identificatienummer

toegekend dat de twee verzekeraars verbindt en heeft als structuur:

XXXXX/NNNNNN/YYYYY

met XXXXX de NBB-code van de directe verzekeraar, NNNNNN een ophogend volgnummer en YYYYY de NBB-code van de verzekeraar tegenpartij (bvb 14/25/37 ).

🡺 Het systeem laat dubbel gebruik toe in zake het versturen van schadeberichten. In praktijk is het trouwens best mogelijk dat een directe verzekeraar, vanuit zijn uniek schadedossier, twee schadeberichten moet kunnen versturen naar eenzelfde verzekeraar die twee tegenpartijen verzekert. Indien er toch een dubbel gebruik zou ontstaan dan dienen de betrokken verzekeraars hiermee op dezelfde wijze mee om te gaan dan in eenzelfde situatie die al altijd heeft bestaan bij het gebruik van papier. Gelieve te controleren of het dubbel gebruik gefundeerd is! Een link met de compensatiekas zal met het identificatienummer en schadenummer worden voorzien, voor de schadeberichten die werden geïdentificeerd door de verzekeraar tegenpartij .9

Meerdere dossiers kunnen worden gelinkt betreffende eenzelfde ongeval. Bijvoorbeeld:

▪ Een dossier van een BA-verzekeraar en een dossier van een MS-verzekeraar.

▪ Dossiers van meerdere verzekeraars wanneer meer dan twee partijen in het ongeval betrokken zijn.

▪ Dossiers met gedeelde aansprakelijkheid of waarin de 2 verzekeraars menen dat hun verzekerde niet aansprakelijk is.

Dit kan door rekening te houden met het schadenummer van de verzekeraar Y. Bijvoorbeeld twee dossiers 39/23/165 en 79/12/165 kunnen gelinkt worden wanneer hetzelfde schadenummer door verzekeraar 165 wordt ingediend.

9 Een export van de database zal voorzien worden met onder andere het identificatienummer, het schadenummer van de partij en tegenpartij. Deze export zal doorgestuurd worden en dan geïmporteerd worden in een tijdelijke tabel van de RDR database. Aan de hand van de gegevens van de tijdelijke tabel wordt de link dan aangemaakt met de nodige programmatuur.

Het opzoeken van links tussen dossiers kan ook gebeuren via een controle van de nummerplaat, datum van het ongeval en de betrokken verzekeraars.

Normaal vereist de overeenkomst het bestaan van een eerste versie van de verzekerde om tot een regeling te komen. Het systeem voorziet bijgevolg dat in deze fase een bijlage, namelijk de versie van de verzekerde van verzekeraar X, kan toegevoegd worden. Er wordt echter beslist om het schadebericht niet te verwerpen als dit document niet als bijlage gevoegd werd omdat het ook later kan worden verstuurd (zie paragraaf 6 hierna)Noot: Men kan een nieuw schadebericht via de web-applicatie opsturen en het antwoord hierop ontvangen via batch.xml. Men kan een initieel schadebericht ontvangen via batch-xml en deze beantwoorden via de web-applicatie. Dit kan wel als gevolg hebben dat er geen synchronisatie meer bestaat tussen de database van de verzekeringsonderneming en de database van het centraal platform. Het is steeds zo dat indien een schadebericht via de web-applicatie werd ingevoerd, deze niet meer via batch-xml kan worden ingevoerd.

2. Verspreiden van de geregistreerde schadeberichten naar de verzekeraar tegenpartij.10

De schadeberichten worden via twee manieren verspreid afhankelijk van de configuratie van de verzekeraar tegenpartij:

▪ Indien de verzekeraar tegenpartij geen schadeberichten via xml wenst te verkrijgen, kan deze de nieuwe schadeberichten via mail ontvangen (zie stap 2 in ProcessFlow). Het e-mailadres (bijvoorbeeld de dienst claims) waarnaar het schadebericht moet verstuurd worden, dient dan aan Datassur worden gecommuniceerd. Deze mails worden dagelijks op een nog af te spreken tijdstip door het systeem aangemaakt.11 De bestanden met versies worden gekopieerd naar de directory van de (tegenpartij) verzekeraar.

🡺 Indien de versie al beschikbaar is, zal deze in bijlage van de mail worden toegevoegd.12

▪ En / of via een batch xml (“RDRexport.xml”) (zie stap 2’ in ProcessFlow) die in de directory (“root\export”) op het centraal platform wordt gedeponeerd waarin een transactienummer wordt vermeld. Er bestaan twee mogelijkheden voor het genereren van een export in het systeem:

10 Het platform houdt twee data bij: de datum wanneer het schadebericht en/ of versie werd ontvangen en de datum wanneer het schadebericht en/of versie werd verspreid naar de verzekeraar tegenpartij. Het is deze laatste datum dat geldt als begintermijn van 30 dagen waarin de verzekeraar-tegenpartij moet antwoorden.

11 Een mail geraakt soms verloren. Een overzicht van de (nieuwe) schadeberichten kunnen steeds bekeken worden aan de hand van de webapplicatie.

12 Indien de bijlage(n) samen een grootte van 4MB bereikt hebben, wordt/en deze bijlage(n) niet met de mail verstuurd, zodat de mails toch naar de bestemmeling kunnen geraken. De beheerder kan de web applicatie gebruiken om de versie(s) te consulteren. De waarde van 4MB kan eventueel nog tijdens de testfase aangepast worden . De mail heeft als onderwerp “RDR schadebericht “ met het registratie nummer gevolgd door het initieel intern schadenummer van de initiële aanvrager gevolgd door de gebruikte omgeving (Test of Productie). In de mail zelf, wordt vermeld of het een initieel schadebericht is, het antwoord op een schadebericht of de toevoeging van een versie.

a) Het transactienummer is nog niet gebruikt: de schadeberichten die nog niet geëxporteerd zijn, worden geëxporteerd; dit transactienummer wordt dan aan de nog niet geëxporteerde schadeberichten gekoppeld.

b) Het transactienummer is al gebruikt: door één of andere reden is de export xml verloren. Alle schadeberichten gekoppeld aan dat transactienummer worden opnieuw geëxporteerd.

Wanneer er geen gegevens te exporteren zijn (geen nieuwe schadeberichten dus), zal het transactienummer gekoppeld aan de export zonder gegevens, steeds leiden tot een export zonder gegevens. Het hergebruik van dit transactienummer om gegevens te verkrijgen zal niet lukken.

🡺 Wanneer het schadebericht is verstuurd naar de tegenpartij (via mail of xml), impliceert dit dat het schadebericht niet meer aangepast kan worden.

3. Raadpleging Veridass platform

Elke dag wordt ook de Veridass gegevensbank geraadpleegd. Hiervoor wordt door het systeem een csv bestand (“RDRexport.csv”) (zie stap 3 in ProcessFlow) gecreëerd met daarin de nummerplaten en/of de onderstelnummers (dit dient nog te worden nagekeken bij Veridass) die in de schadeberichten vermeld werden en naar Veridass verstuurd. Het antwoord van Xxxxxxxx wordt terug in het systeem geïntegreerd met eventueel de verzekeringsmaatschappij die aan de nummerplaat of onderstelnummer is gekoppeld. De informatie dat de in de gegevensbank vermelde verzekeraar een andere verzekeraar is dan de op het schadebericht vermelde verzekeraar of dat Xxxxxxxx geen informatie bezit over de verzekeraar, zal pas eventueel te zien zijn in het antwoord van de verzekeraar tegenpartij op het schadebericht (zie hierna). De raadpleging van Xxxxxxxx heeft geen invloed op het initieel schadebericht, maar geeft een aanduiding van de nieuwe tegenpartij aan de directe verzekeraar indien de initiële verzekeraar tegenpartij het schadebericht verworpen heeft.

4. Antwoord op het schadebericht

De verzekeraar-tegenpartij is verplicht om te antwoorden op het schadebericht (binnen de 30 dagen; dit is geen door de overeenkomst vastgestelde verplichting maar een vraag van de leden van de WG in dit kader).13 Zo kan hij de gegevens die op het schadebericht staan bevestigen of wijzigen. Door de elektronische verzending van het antwoord kunnen de vervaltermijnen in geval van niet-verzekering worden nagegaan

13 Er worden geen rappels door het systeem gegenereerd.

zoals bepaald in de tekst van de overeenkomst. Dit is belangrijk aangezien dit aspect beslissend is voor de toepassing of niet van de RDR.

Het antwoord betreft dezelfde rubrieken als de in het schadebericht vermelde rubrieken waarbij de verzekeraar-tegenpartij de hem betreffende gegevens kan wijzigen. Daar bovenop moet de verzekeraar-tegenpartij kunnen antwoorden op de volgende rubrieken:

- Schadenummer van de verzekeraar Y (FV).14 Dit nummer is door de directe verzekeraar meestal niet gekend. Aan de hand van dit nummer kunnen later eventueel meerdere dossiers worden gelinkt.

- Dossier is geïdentificeerd (V).

Verzekeraar Y kan hierbij laten weten dat hij niet in de mogelijkheid verkeert om zijn dossier te vinden

- Verzekeringsbevestiging: (V). Er zijn 2 hoofdopties:

• Er is geen identificatie mogelijk van het schadebericht (en dus kan men zich niet uitspreken over de dekking) met de identificatiegegevens opgenomen op het schadebericht.

• Er is identificatie mogelijk van het schadebericht: er zijn verschillende opties mogelijk, :

▪ Dekking voorzienOK/opening van een dossier GMWF15 (1).

▪ Niet-bestaan van een overeenkomst (=contract) (2).

▪ Opzegging van de overeenkomst (3).

▪ Opschorting van de overeenkomst (4).

▪ Nietigheid van de overeenkomst (5).

▪ Geen overeenstemming over het voertuig (6). Voor de 5 laatste gevallen is er geen dekking voorzien.

- Overeenstemmende Identieke versies (F). Verzekeraar Y kan ook bevestigen dat hij geen versie overmaakt omdat de versie die hij heeft van zijn verzekerde, hetzelfde document is als die gevoegd bij het schadebericht (16a=17a).

- Bijlage (F).Verzekeraar Y krijgt hierbij eveneens de mogelijkheid om in bijlage de versie van zijn verzekerde toe te voegen. De verzending van de versie kan ook hier in datum uitgesteld worden net als bij verzekeraar X, maar daarvoor zal dan stap 6 hierna moeten worden gevolgd.

🡺 Het antwoord op het schadebericht kan gebeuren aan de hand van de webapplicatie of aan de hand van een batch xml (zie stap 4 in ProcessFlow).

🡺 Aangezien bij het gebruik van de web-applicatie, de beheerder is geïdentificeerd, zal bij de verdere behandeling van het dossier bij het

14 Daardoor wordt het schadenummer damagenumber in het blok “CounterPartInformation “(verzekeraar tegenpartij) aanwezig in versie 4 van de xsd-schema’s , een niveau opgeschoven en in twee gesplitst: CounterpartDamageNumber1 is het schadenummer van het initieel schadebericht van de verzekeraar tegenpartijen is niet verplicht, CounterpartDamageNumber2 is het schadenummer van het respons op het schadebericht en dient door de verzekeraar tegenpartij te worden ingevuld.

15 Indien een schadebericht verstuurd wordt naar het GMWF dan kan het GMWF, dat als instantie geen dekking levert, enkel antwoorden dat een dossier geopend wordt en de refertes meegeven.

versturen van e-mails, deze persoon in C.C. staan, naast die van de dienst claims, om het dossier sneller te behandelen.

🡺 Er zullen zoals voor het initieel validiteitcontroles op het antwoord worden toegepast.

🡺 De nodige versies zullen eveneens gekopieerd worden voor het gebruik van batch xml.

🡺 De verzending van schadeberichten en het antwoord op die schadeberichten kunnen vervat worden in eenzelfde xml, omdat die in aparte blokken worden vervat.

🡺 Er is maar één antwoord voorzien. Eens een antwoord in het systeem werd ingebracht en verspreid naar de oorspronkelijke verzekeraar, kan er geen tweede antwoord worden ingebracht. Voor de web-applicatie bestaat er de mogelijkheid, vóór de verspreiding van het bericht, het antwoord nog aan te passen.

Indien verzekeraar Y niet de verzekeraar is van tegenpartij dan geeft het platform de informatie van verzekeraar Z mee die men desgevallend heeft teruggevonden binnen Veridass.

🡺 Er mag dan door de directe verzekeraar X een nieuw schadebericht opgesteld worden maar dan naar verzekeraar Z.

5. Verspreiden van de geregistreerde antwoorden op schadeberichten naar de directe verzekeraar.

Dit gebeurt analoog als stap 2 afhankelijk van de configuratie van de directe verzekeraar (via mail of via batch xml) (zie stap 5 in ProcessFlow). Er wordt bij de initiële aanvraag per schadebericht een (niet verplicht) veld “email” voorzien in de batch xml, waarbij een mail gegenereerd kan worden met informatie betreffende het schadebericht naar de beheerder van het dossier van de directe verzekeraar X wanneer er antwoord komt van de tegenpartij. Deze beheerder moet wel geregistreerd zijn in het systeem. Indien de beheerder een initieel schadebericht via de web-applicatie heeft ingevoerd, zullen 2 mails verzonden worden bij het antwoord hierop: één naar de claimsafdeling en één naar de beheerder zelf. Bij het antwoord op de aanvraag via batch xml, is eveneens een veld “email” voorzien, zodat eventuele versies horend bij het initieel schadebericht naar hem kunnen gemaild worden.

6. Uitwisseling van versies

Een verzekeraar, zowel X als Y kan op ieder moment een versie verzenden naar de andere verzekeraar (zie stap 6 in ProcessFlow). Dit gebeurt op basis van het identificatienummer (of eventueel schadenummer). De versies worden bijgehouden en dagelijks verspreid analoog als stap 2, via mail of xml. Wanneer in het antwoord op een

schadebericht gemeld wordt dat, de versie identiek is (16a=17a), moet geen bijlage verzonden worden. Anders moet wel een bijlage verstuurd worden.

Einde procedure

Alle andere aspecten binnen het beheer van een RDR dossier vallen buiten de scope van het huidig voorstel tot oprichting van het platform. Die aspecten dienen verder te worden behandeld volgens de huidige werkwijze buiten het platform.

3. Structuur van de database van Datassur.

Onderstaande figuur geeft een overzicht weer van de structuur van de database bij Datassur die de gegevens van de verschillende verzoeken zal bijhouden. De database bevat verschillende tabellen met veldnamen. De unieke sleutels van de tabellen zijn in het vet weergegeven. De verbindingen tussen de velden van twee tabellen tonen de relaties aan tussen de unieke sleutels van een tabel en de “foreign keys” van een andere tabel. Er wordt eveneens de syntax (string, integer, boolean) weergegeven met de bijhorende lengte, volgens de officiële telebib norm.

Figuur 2: Implementatie van de database van Datassur voor het RDR platform

De tabel message is het hart van de toepassing. Hierin worden alle gegevens voor de verschillende types berichten bijgehouden. Er werd geopteerd voor 1 enkele tabel i.p.v. eentje per berichttype, aangezien elk bericht steeds verder bouwt op het eerste, en dus eigenlijk een verdere aanvulling ervan is. Indien er later nog berichttypes bijkomen, kunnen die gewoon verder deze tabel uitbreiden, en blijven de vorige applicaties gewoon verder werken zonder aanpassing wat eenvoudiger is dan een nieuwe te introduceren.

De tabel messagetype definieert de mogelijke berichttypes.

De tabel attachment tabel verwijst naar de plaats waar de bijlagen worden bijgehouden.

De tabel veridassinformation dient voor de raadpleging van het Veridassplatform en geeft voor een bepaald identificatienummer de mogelijke NBB van de tegenpartij. Dit gegeven wordt dan later in het antwoord van tegenpartij toegevoegd.

De tabel company bevat de gegevens van de aangesloten verzekeraars (NBB, naam, adres, telefoon, email van afdeling schade).

De tabel user geeft informatie rond de geautoriseerde gebruikers voor elke maatschappij (userid (=emailadres), paswoord, familienaam, voornaam, login, taal).

De tabel transaction bevat de aanvragen tot export van een bepaalde verzekeringsmaatschappij: deze bevat de NBB-code en het transactienummer.

De tabel messagexml houdt de verschillende messageid bij van de xml’s die werden doorgestuurd. Een xml wordt geïdentificeerd door deze id. Een xml met een bepaalde id kan maar één keer worden opgeladen (indien deze succesvol opgeladen is geweest). De oorspronkelijk ingediende xml kan hiermee ook sneller worden teruggevonden.

De tabel batch geeft een overzicht weer van de files die al dan niet succesvol werden opgeladen met het aantal berichten vervat in deze xml.

De tabel error geeft de verschillende fouten die kunnen optreden bij het indienen van de schadeberichten bij Datassur.

4. Gebruik van de web-applicatie met betrekking tot de schadeberichten.16

Eerst identificeert de gebruiker zich aan de hand van de gebruikersnaam (dit is het e- mailadres), het paswoord en de NBB code.17

Figuur 3: Webapplicatie voor de identificatie van de gebruiker.

Er kunnen verschillende pagina’s opgeroepen worden.

16 Men kan de gegevens bekijken met elke CSS3 compatibele browser: bvb vanaf internet Explorer versie 7.0 of Firefox versie 3.6 of opera versie 10 of Google Chrome.

17 Indien een gebruiker zijn paswoord kwijt is, kan hij deze door de webapplicatie terug verkrijgen door het e-mailadres in te tikken en de aanvraag in te dienen via een button met het link “paswoord verloren?” rechts boven het inlog scherm. Via mail recupereert de gebruiker zijn/haar paswoord.

• Invoeren gegevens

Dit is de eerste pagina die verschijnt na de login:

Figuur 4: Webapplicatie voor het invoeren en beantwoorden van schadeberichten en opsturen van versies.

Het invoeren en beantwoorden van schadeberichten alsook het versturen van versies gebeurt aan de hand van één webpagina. Er is een onderverdeling naargelang het type

bericht: de eigen berichten naar een verzekeraar tegenpartij (type bericht =1) en de inkomende berichten komend van een andere verzekeraar tegenpartij (wordt bij beantwoording type bericht=2).

Voor de eigen berichten is er een onderverdeling met:

• het indienen van een nieuw schadebericht.

• het wijzigen van een (pas ingediend) schadebericht.

• het opladen van een versie.

Voor de inkomende berichten is er een onderverdeling met:

• het beantwoorden van het hem geadresseerd schadebericht.

• het aanpassen van het hem geadresseerd schadebericht.

• het opladen van een versie.

Voor deze laatste vijf gevallen verschijnt rechts een button “opladen gegevens” waarbij de beheerder de gegevens van het bericht aan de hand van het uniek identificatienummer eerst moet verkrijgen van de database

of aan de hand van het schadenummer.

Het identificatienummer is in drie vakken gesplitst:

Het NBB nummer van de verzekeraar, het volgnummer en het NBB nummer van de tegenpartij. Om fouten te vermijden bij het ingeven van het identificatienummer wordt het NBB nummer automatisch weergegeven in één van de vakken (links of rechts), omdat deze automatisch gekend is bij de identificatie van de gebruiker. Velden met een

* dienen verplicht te worden ingevuld.

Velden die niet meer aangepast kunnen worden, worden in de webapplicatie getoond maar zijn niet aanpasbaar. Velden die niet nodig zijn naargelang de context worden niet getoond (bvb voor een nieuw schadebericht, zal men geen gegevens zien over het antwoord van het schadebericht en eveneens geen identificatienummer). De beheerder kan steeds een versie toevoegen.

🡺 Alvorens het schadebericht wordt ingediend, wordt gecheckt naar de juistheid van alle velden (lengte, syntax, verplicht veld,..) en worden eveneens andere validatie routines uitgevoerd (bvb nakijken of er een minimum aantal velden van de tegenpartij zijn ingevuld).

🡺 Indien door de beheerder een fout is geconstateerd na het indienen van het schadebericht (bvb nummerplaat niet juist ingevuld), kan hij de gegevens van dit schadebericht terug opvragen, de gegevens wijzigen en terug indienen. Dit kan slechts gebeuren indien de gegevens nog niet verspreid zijn door het systeem (email of batch xml). Voor het beantwoorden van een schadebericht geldt het analoge.

🡺 Een wijziging van de selectiebutton rond het type invoer, zullen de bestaande gegevens rond de vroegere invoer op de webapplicatie steeds wissen.

🡺 De beheerder kan nooit meer karakters in de webapplicatie toevoegen als toegelaten door de database.

🡺 Wanneer een antwoord op een schadebericht wordt ingediend, moet de beheerder aanduiden of identificatie mogelijk was van het schadebericht en indien wel of er al dan niet een dekking voorzien was (cfr punt 2.4). De beheerder moet ook aanvinken of er een overeenstemmende versie was. De mogelijke nbb afkomstig van het Veridass platform kan worden getoond.

🡺 Er zijn geen default waarden voor radiobuttons voorzien (bv; bij het antwoord van een schadebericht dient de beheerder zelf aan te vinken of de identificatie van het schadebericht al dan niet mogelijk is). De bedoeling is om fouten te vermijden.

Wanneer de velden van het formulier zijn ingevuld/aangepast en het schadebericht is ingediend, wordt een nieuw web pagina getoond met het (nieuw) identificatienummer, een overzicht van de geregistreerde records en eventueel de toegevoegde versie.

Door op de link “nl” of “fr” rechtsboven de applicatie te klikken, kan men steeds de vertaling van de pagina in het Nederlands of Frans bekomen. De gebruiker kan de webapplicatie steeds verlaten door op de link “afmelden” te drukken.

• Overzicht gegevens

Als men in deze webapplicatie op de link “overzicht” klikt, kan men de gegevens met betrekking tot een schadebericht bekijken.

De gegevens moeten aangevraagd worden op basis van het identificatienummer of op basis van het schadenummer via de button “aanvraag”. Indien de aanvraag wordt gedaan op basis van het schadenummer en verschillende identificatienummers gekoppeld zijn aan dit schadenummer, worden de identificatienummers getoond en moeten de beheerders dan de gegevens opvragen op basis van het identificatienummer. Er verschijnt een overzicht van de gegevens van de laatste status van het schadebericht met betrekking tot dit identificatienummer: de gegevens van de directe verzekeraar, tegenpartij, gegevens ongeval, schadebeheer en eventueel antwoord op het schadebericht en de mogelijke NBB.

Onderaan verschijnt een overzicht van de historieken (of berichttypes) met het identificatienummer, het soort document en de datum van toevoeging in het systeem. Het identificatienummer in de tabel zal voorzien worden met een link. Door in de tabel op deze link te klikken, zal men de gegevens gekoppeld aan dit soort document kunnen zien.

Men kan eveneens alle gegevens verbonden met dit dossier op de browser in een PDF formaat zien door op de link “aanmaak PDF” te drukken. Deze PDF kan men afdrukken of bewaren indien men dit wenst (hiervoor wordt nog geen voorbeeld getoond).

Verder onderaan verschijnt een overzicht van de opgeladen bestanden. Men kan een bestand opladen op de PC door op de link “download versie” te klikken in de

overeenstemmende rij of onmiddellijk bekijken op de browser door op de link “bekijk versie” te klikken.

🡺 Een opgeladen bericht en versie zal door de tegenpartij pas bij de verzending gezien worden. Het bericht of versie kan toch worden bekeken door de beheerder die deze versie heeft opgestuurd. De status van de verzending zal in de

2 overzichten zien zijn: versie/bericht verzonden of versie/bericht nog niet verzonden.

Figuur 5: Webapplicatie voor het raadplegen van gegevens rond schadeberichten.

• Opzoeken gegevens

Als men op de link “opzoeken” klikt, komt men op een nieuwe pagina terecht waarbij men in tabelvorm een overzicht van de schadeberichten kan verkrijgen aan de hand van verschillende selectiecriteria:

• het type bericht: een uitgaand bericht vertrekkend van de verzekeringsmaatschappij of een inkomend bericht komend van een andere verzekeringsmaatschappij. Als een gebruiker een NBB-code 14 heeft, zal een uitgaand bericht een identificatienummer 14/NNNNNN/YYYYY hebben en inkomend bericht een identificatienummer XXXXX/NNNNN/14 hebben.

• selectie gebruiker: de gebruiker in de webapplicatie of alle gebruikers.

• een datuminterval.

• de NBB van de verzekeringstegenpartij (alle of één bepaalde).

Er verschijnt een tabel met het identificatienummer, het email van de beheerder, de datum van toevoeging, het schadenummer en het type bericht.

Figuur 6: Webapplicatie met overzicht van de schadeberichten.

Er verschijnt een melding indien er aan de hand van de selectiecriteria meer dan 100 records worden gevonden. De selectiecriteria moeten dan verfijnd worden.

Andere selectiecriteria kunnen nog worden toegevoegd. Door op het link “identificatienummer” te klikken, zal men automatisch naar de webpagina “overzicht” gaan en alle gegevens gekoppeld aan dit soort document kunnen zien. Aangezien een mail soms verloren kan geraken, kan een beheerder langs deze weg op een snelle manier bekijken welke schadeberichten dienen behandeld te worden.

5. Indienen van gegroepeerde schadeberichten via batch xml.

De verzekeringsmaatschappijen kunnen een groot aantal schadeberichten tegelijkertijd indienen om tijd en moeite te besparen. Dit zal gebeuren door het indienen van een batch-xml (meestal gegenereerd aan de hand van extractie uit een database) in een folder van de dedicated server. Dit bestand dient volgens een strikte lay-out worden ingevuld en is onderverdeeld in twee blokken: een blok met algemene gegevens (NBB, id van de xml, user (emailadres), omgeving 18 en timestamp) en een groot blok onderverdeeld in kleinere “subblokken” waarin de feitelijke schadeberichten (1 tot n)

18 Dit is het veld “targetenvironnment”; Er zijn twee omgevingen: de test en de productieomgeving.

per type gegroepeerd zijn met dezelfde informatie als deze zou ingetikt zijn in bovenstaand browser. Voor meer informatie rond de lay-out van dit xml: zie “lay-out xsd-schema’s” onder paragraaf 9. Een schadebericht kan dus aangemaakt zijn via een batch-xml en later aangepast worden door de browser. De status van een bepaald schadebericht kan steeds via een snelle manier met de browser worden bekeken.

De xml kunnen via 2 manieren opgestuurd worden:

a) Via FTP

Voor elke verzekering wordt een eigen input directory voorzien waarin deze bestanden zullen moeten gedeponeerd worden.19 Verzekeringsmaatschappijen krijgen daardoor geen inzage in de xml’s van de andere verzekeringsmaatschappijen. De inhoud van de directories van de verschillende maatschappijen worden op regelmatige basis via JBI (“Java business integration”) components door de “open service bus” ingelezen. De bestanden zullen eerst naar hun juistheid gecontroleerd worden en vervolgens in de database worden opgeladen.

🡺 Bij het opladen van een batch-xml, zal in deze folder van de maatschappij enkele minuten later een response xml verschijnen met daarin de vermelding van de geregistreerde records (met hun (eventueel nieuw) identificatienummer)), de geweigerde records (records die in het systeem niet worden opgeladen).

b) Via de webapplicatie

Er is een webpagina voorzien waarbij je de batch xml gegevens kan indienen (deze pagina wordt getoond door op de link “batch” te klikken in de andere webpagina’s .

Figuur 7: Webapplicatie voor het invoeren van een batch xml en opladen versies.

Het opladen van versies kan gebeuren door het opsturen van een bestand (in formaat zip) waarbij de versies gebundeld zijn. Men selecteert op de PC het bestand en via de button “opladen zip” wordt deze naar de server verstuurd. De server zal het bestand automatisch “unzippen” waardoor de verschillende versies dan kunnen verspreid worden. Voor de verwerking van de batch xml selecteer je het bestand op de PC en met de button “opladen” wordt het bestand op de server opgeladen en verwerkt. Met deze pagina kan je ook een aanvraag tot export doen van de schadeberichten van de verzekering tegenpartijen. Analoog verschijnt kort na het indienen van de xml een button waar je het antwoordbestand kan opladen op de PC. In geval van problemen, wordt op de browser een melding gemaakt van het probleem (bvb het opladen van een verkeerd bestand, file niet geselecteerd). Via de hyperlink in de tabel onder de kolom “zip version”, kan men voor de export aanvragen de gebundelde versies in zip versie horend bij dit export downloaden op de PC.

Door op de button “overzicht bestanden” te klikken, krijgt men een overzicht van de zip versies, de xml schadeberichten of antwoorden op schadeberichten. Men kan de xml’s downloaden of verwijderen door op de link te klikken onder de kolom “down” of “del”. Indien mogelijk wordt er eveneens de xml-id of het transactienummer van de xml getoond. Het antwoord op bestanden die tot fouten hebben geleid worden eveneens weergegeven.

🡺 Er is wel een beperking qua gebruik van de batch xml via de web-applicatie: gebruik niet te veel aanvragen per keer, daar de bestanden niet te groot mogen zijn om ze via http terug te kunnen opladen.

🡺 De verzekeringsondernemingen zullen echter de webpagina pas zien wanneer de nodige technische ontwikkelingen werden verricht om de xml aan te maken. Er dient op de server een configuratiefile opgesteld te worden om automatisch de bestanden door het platform op te pikken en te verwerken.

🡺 De directory voor het afhalen van xml bestanden zijn dezelfde voor ftp en web.

6. Gebruikte kanalen voor de uitwisseling van de gegevens bij Datassur.

Het uitwisselen van informatie tussen Datassur en de verzekeringsmaatschappijen kan verlopen via 2 manieren:

a) Via FTP.

File transfer protocol (FTP) met onderliggend TCP/IP laag (het standaard protocol gebruikt bij het internet, een “point to point” communicatie): de bestanden worden gedeponeerd of afgehaald op de server.

De gegevens zullen via een beveiligde manier naar het platform worden verzonden worden. Hiervoor zijn twee opties mogelijk die de verzekeringsmaatschappij zal moeten gebruiken:

encryptie van de verzonden

integriteit van de informatie

Field Code Changed

• het gebruik van FTPS met een uitbreiding voor het veelgebruikte File Transfer Protocol (FTP) dat ondersteuning geeft voor Transport Layer Security (TLS) en Secure Sockets Layer (SSL) waardoor het verkeer, als het onderschept wordt, niet uit te lezen valt zonder het encryptie-algoritme te kraken door het gebruik van publieke en private sleutel

• het gebruik van SFTP met onmiddellijke informatie waarbij de confidentialiteit en verzekerd wordt.

b) Via een webapplicatie.

Het online indienen van een schadebericht via een webapplicatie zal gebeuren via het http protocol of indien gewenst via https, met het gebruik van een certificaat.

7. Standaardnaamgeving van de uitgewisselde bestanden.20

Volgende tabel geeft een overzicht weer van de bestanden die worden uitgewisseld tussen Datassur en de verzekeringsmaatschappijen met de rubrieken “doel” en “directory” waar de bestanden kunnen gedeponeerd en afgehaald worden. Het antwoord wordt op dezelfde directory gegenereerd als waar de xml is gedeponeerd. Bestanden die niet aan deze naamgeving voldoen, zullen in de queue blijven en niet opgeladen worden. Files zonder deze xml extentie worden eveneens geweigerd.

20 De uitgewisselde bestanden worden gecodeerd in het standaard UTF-8 variabel byte lengte formaat.

Doel	Directory	Naamgeving input xml/pdf	Naamgeving output xml/pdf (genereerd door Datassur)
Levering bulk schadeberichten	root/ /request	rdrinsurance_timestamp.x ml	rdrinsurance_timestamp1_output.xml
Export records Datassur	root/ //export	rdrinsuranceexport_timest amp.xml	rdrinsuranceexport_timestamp1_output. xml
Levering versie files	root/ //versionupload	Geen beperking?	Ophogend volgnummer + identificatienummer.pdf
Aftap versie files	root/ //versiondownload (en versiondownloadbackup )	Ophogend volgnummer + identificatienummer.pdf	/

“rdr” refereert naar de applicatie, “timestamp” heeft het formaat yyyymmdd-hh-mm- ss-xxx (hh-mm-ss-xxx is echter facultatief) met xxx gaande van 000 tot 999 (geeft de milliseconden), xml omdat het een xml is. Voor een export van de Database komt bijkomend “export” erbij. Bij de login met de FTP zal men voor elke onderneming vier subfolders in de root zien “request” voor de schadeberichten en “export” voor de aanvraag tot export van de database, versionupload voor het opladen van de versies en versiondownload voor het aftappen van de versies van de verzekering tegenpartij.

🡺 De files met de versie moeten eerst geleverd worden, daarna pas moet de xml met de bulk schadeberichten geleverd worden !! Het systeem kijkt immers na of de files met de versie wel aanwezig zijn.

🡺 Voor elk record dat in een systeem zal worden opgeladen, zal een antwoord bestand met dezelfde naam als het inputbestand met bijkomend de extensie “- output” gegenereerd worden (bvb input rdrinsurance20091211.xml en output rdrinsurance20091212-15-01-30_output.xml).

🡺 De files die in behandeling zijn komen in de directory “filebc-in-processing”.

🡺 Er wordt door het systeem ook een archief gegenereerd van de opgeladen file.

Deze komt in een subfolder “archive”.

🡺 In het outputbestand is de timestamp1 gegenereerd op het ogenblik van de aanmaak van de respons (verschillend van de timestamp van het input bestand).

Indien een xml verkeerd gevormd (bvb foute tags, verkeerde of afwezige blokken) is, verschijnt er een errorfilein de directory “error” in de directory. Bvb Error Details: FILEBC- E00716: Input file [C:\rdr\0032\request\filebc-in-processing\rdrinsurance_20110520.xml 3411b645-5188-4f14-9f02-7038f590c525] failed processing, an exception was raised: The element type "ns0: Message1a" must be terminated by the matching end-tag "</ns0:Message1a>". Cause: org.xml.sax.SAXParseException: The element type "ns0: Message1a" must be terminated by the matching end-tag "</ns0: Message1a>".

Voor de naam van het PDF bestand bestaat er geen beperking. Deze mag wel niet langer zijn dan 100 karakters en wordt hernoemd naar een unieke naam.

8. Errorcodes.

Allerhande fouten kunnen optreden bij het laden van de batch-xml door het systeem en worden in de respons weergegeven.

• Op niveau van de xml structuur: de xml is niet geldig conform het schema: bvb velden zijn alfanumeriek ingevuld terwijl men een numerieke waarde verwacht, velden zijn te lang, verkeerde formattering van de datum, verplichte velden zijn niet ingevuld,…)

🡺 Er verschijnt een antwoord met errorcode 100. De reden van weigering wordt in de errordescription gegeven: bvb line number 1 cvc-complex-type.2.4.a: Invalid content was found starting with element 'street'. One of '{"xxxx://xxx.xxxxxxxx.xx/xxxxxx/ rdrschema":streetnumber is expected.

• Op niveau van het individueel schadebericht: bvb het registratienummer is niet gekend, het schadenummer is al gekend, te weinig velden ingevuld met betrekking tot de verzekeraar tegenpartij, … . Aan deze fouten zullen in de respons errorcodes geassocieerd worden in het blok van de geweigerde records op niveau van de aanvraag. Als er op een bepaald schadebericht een fout is, kunnen de andere schadeberichten wel opgeladen worden.

• Op algemeen niveau: de hele xml wordt hier geweigerd: bvb de informatie in de header is niet juist: NBB nummer is niet gekend, het aantal schadeberichten is niet gelijk aan de effectief aantal schadeberichten van de “Messages”-blok; de database is niet beschikbaar,… . Er is voor dit geval een error-blok voorzien op het zelfde niveau als de blok van de aanvaarde en geweigerde records.

De errrorcodes zijn:

1 probleem met de database: neem contact op met Datassur 2 aantal numberofcases is niet juist

3 verkeerde targetenvironement of targetenvironment niet ingevuld 4 usernaam is niet gekend in het systeem voor de nbb

5 UniqueId bestaat al 6

7 emailadres niet gekend: neem contact op met de administrator 8 pdffile niet aanwezig in de directory file versionupload

9 geen antwoord mogelijk; het identificatienummer bestaat niet 10 geen antwoord mogelijk; deze werd al ingegeven

11 geen geldig identificatienummer (moet nbb bevatten van de verzekeringsmaatschappij)

12 nbb code verzekeraartegenpartij niet gekend/ niet meer actief

13 geen identificatie aan de hand van identificationinformation

14 geen éénduidige identificatie aan de hand van identificationinformation

15 zipfile bevat niet PDF bestanden

16 minimale informatie verzekeraartegenpartij afwezig

17 datum ongeval ligt in de toekomst

18 probeem met het unzippen van het bestand: contacteer Datassur 19 niet compatibele nbbout in combinatie met identificatienummer 20 ongeldige landcode

21 identieke versie niet conform met Type2bericht 22 datum ongeval ouder dan 5 jaar.

23 versie is niet overeenstemmend maar er is geen versie aanwezig.

100 xml schema niet conform

Er kunnen eventueel nieuwe errorcodes komen.

9. Lay-out van de batch bestanden (xsd-schema’s).

xxxx://xxx.xxxxxx-xxxxxxxxxxxx.xxx/XxxXxxxxx/XxxXxxxxx.xxxx . De

Field Code Changed

De xml’s die door het systeem van Datassur worden opgeladen en gegenereerd, moeten aan strikte voorwaarden voldoen. Voor het valideren van xml’s zijn xml-schema’s (xsd) voorzien die aan deze xml’s een bepaalde informatiestructuur oplegt en dus dicteert wat er in een xml mag/moet voorkomen en wat niet mag voorkomen (elementen, attributen, sub- elementen, verplichte velden, …). Deze schema’s dienen opgeladen te worden in het applicatiesysteem van de verzekeringsmaatschappijen zodat het systeem daarna op de juiste manier de batch-xml’s kan genereren aan hand van de gegevens in hun database. Alvorens de xml wordt opgestuurd dient de maatschappij de xml zelf te valideren. Er bestaan verschillende tools op het net om deze xml’s te valideren. Een freeware versie kan gevonden worden op:

xml is lowercase/uppercase sensitive, gelieve hiermee rekening te houden (bvb GroupHeader!= groupheader). De labels werden genoemd volgens de Pascal Case conventie. Er werd ook een versie toegevoegd voor de targetnamespace prefix. Er werden twee schema’s uitgewerkt. In het schema zelf wordt bijhorend commentaar geleverd voor elk nieuw veld. Hieronder wordt de xsd schematisch weergegeven:

Figuur 8: xsd structuur van het verzoek en respons komend van een verzekeringsmaatschappij.

a) Voor het indienen van schadeberichten bevat het schema twee blokken (request-response type):

• Het eerste blok bevat het verzoek (hier dus informatie rond de berichten) die door een bepaalde entiteit worden doorgestuurd. Het verzoek bevat steeds twee “subblokken”: algemene informatie rond het verzoek in de Groupheader (NBB gebruiker21, aantal berichten, omgeving (test of productie) en datum) (dit is de enveloppe van de xml) en daarna de schadeberichten zelf ( de “Messages” blok) met daarin (voorlopig) 3 hoofdblokken:

de nieuwe schadeberichten “Type1Messages” die dienen verstuurd te worden naar de verzekeraar tegenpartijen, de antwoorden op de schadeberichten “Type2Messages” van de directe verzekeraar en de versies van de verzekeraar “Type19Messages” (er dient in het antwoord op een schadebericht aangegeven te worden of de verzekeraar al dan niet beschikt over een identieke versie en indien niet moet een link naar de bijlage gegeven worden). Elk hoofdblok bevat 1…n schadeberichten, met afhankelijk van het type hun al dan niet verplichte blokken en velden: gegevens over de verzekeraar, tegenpartij, ongeval, het schadebeheer,

21 Er wordt als bijkomende security check gecontroleerd of de gebruiker (ahv emailadres) geregistreerd is in het systeem;

antwoord op het schadebericht, locatie PDF bestand. De Type1Message bevat zijn eigen gegevens “insuranceinformation”, de gegevens van de tegenpartij “counterpartinformation”, de gegevens betreffende het ongeval “accidentinformation”, gegevens betreffende het beheer “ damagemanagement information” en eventueel de bijlagen “attachments”. De Type2Message dat het antwoord is van TypeMessage1 bevat de gegevens die kunnen aangepast worden counterpartinformation, accidentinformation, “ damagemanagement information”, eventueel de bijlagen “attachments” en het antwoord al dan niet identificatie van het schadebericht “damageresponsinformation”. De blokken “complex type” bevatten informatie die verschillende keren worden gebruikt (zowel in het verzoek als respons).

• Het tweede blok bevat de respons die door het systeem wordt gegenereerd wanneer het systeem de verzoeken heeft binnengekregen: de opgeladen schadeberichten (“RegistratedMessages”), de geweigerde schadeberichten (“RejectedMessages”) met elk hun eigen subblokken zoals deze in het verzoek en indien een algemene fout (niet per schadebericht dus) een errorblok met een vermelding van de errorcode (bvb Database is niet beschikbaar, het NBB nummer is niet meegedeeld,…). In de geweigerde records komt steeds de errorcode met de bijhorende beschrijving waarom een record geweigerd werd.

🡺

Aan de nieuwe berichten is er nu in het antwoord een registratienummer gekoppeld. Het blok “Type1Messages” (en de andere Type2 en Type19) van het respons “Registrated Messages” moet best door de verzekeringsmaatschappij terug opgeladen worden!! Indien men het identificatienummer van het platform niet wenst te gebruiken, kan men gebruik maken van het blok identificationinformation, gebaseerd op de nbbcode en het schadenummer van de directe verzekeraar alsook de nbbcode en nummerplaat het schadenummer van de verzekeraar tegenpartij (in het antwoord MessageType2). Pas op : deze identificationinformation ligt echter nog niet vast en dient nog in een volgens xsd release te worden gefinaliseerd. Dit blok zal ook aanwezig zijn in de Type19Messages en in het export van de schadeberichten.

Formatted: Not Highlight

b) Voor de export van schadeberichten bevat het schema twee blokken:

• De eerste blok bevat het verzoek met daarin de NBB-code, de gebruiker, de omgeving (test of productie) en het transactienummer gekoppeld aan de export.

• De tweede blok bevat de feitelijke export met daarin twee subblokken: algemene informatie rond de export in de Groupheader (NBB-nummer, het transactienummer, aantal aanvragen en versies vervat in de xml en datum) en daarna de feitelijke schadeberichten zelf (de “Messages” met daarin terug de nieuwe schadeberichten en antwoorden van de tegenpartijen. Noteer ook dat er steeds voor elke individueel bericht de NBB-code van de verzekeringsmaatschappij wordt vermeld).

Voor alle duidelijkheid, de export van de database dient om de schadeberichten komend van andere verzekeraars te verkrijgen.

Volgende schema’s worden in de bijlage voorzien:

a. Schema voor aanvraag van gegevens vanuit de verzekering (met twee blokken: de berichten en het antwoord gegenereerd door het platform): verzekering-datassur.xsd

b. Schema voor de aanvraag tot export voor de verzekering(met twee blokken: de aanvraag tot export en de aftap uit de database): datassur-verzekering.xsd

De flow van de xml wordt nog eens verder geïllustreerd aan de hand van volgend schema:

Figuur 9: Batch xml flow voor RDR platform. Noteer ook het verschil tussen de inkomende en uitgaande berichten. Bijkomende nota:

De versies horend bij een xml kunnen ook gebundeld opgestuurd worden via FTP in zip formaat. Het platform zal eerst nakijken of de file “uniqueid.zip” bestaat met de uniqueid deze vermeld in deze xml en de versies automatisch unzippen in de daartoe toegewezen directory. Analoog zal het systeem automatisch bij het aanmaken van een export xml automatisch een bestand “transactionnumber”.zip aanmaken met transactionnumber deze die vermeld is in de export aanvraag. Deze zip-file kan daarna gedownload worden vanuit de server in de daartoe toegewezen directory.

Deze schema’s kunnen nog enkelen wijzigingen ondergaan. Nieuwe versies zullen op de downloadlink worden gevonden (voorlopig zit men aan versie45). 2223 Voorbeelden van elke xml

22 Alle bijlagen kunnen worden gedownload op de link xxxx://xxx.xxxxxxxx.xx/xxxxxxxxx/XXXxxxxxxx.xxx

23 De parser van het platform die de xml zal behandelen laat geen Byte Order Mark toe (xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_Xxxxx_Xxxx ) . Dit karakter dat 3 bytes bevat, wordt soms in het begin van de xml file geplaatst en geeft ondubbelzinnig de Unicode transformatie dat gebruikt wordt (en de Byte Order). Meer info op xxxx://xxxxxxxxxxxxxxx.xxx/xxxxxxxx/xxxxxxxxxxxxx-xxx-xxx-xxxxxx-xxxxxx-xxxx-xxxxx .

Gelieve dus steeds de xml te beginnen met “<” zonder de BOM. Pas op de BOM wordt met de meeste editors (bvb textpad of de IE explorer) niet met het menselijk oog waargenomen. Gebruik een hexadecimale tekst editor om dit waar te nemen (bvb hexedit). Indien de BOM toch gebruikt wordt, komt de xml file onder de errors sub directory met de melding “org.xml.sax.SAXParseException: Content is not allowed in prolog”. Bij het saven van een xml-file door een editor, wordt soms een BOM karakter toegevoegd.

Field Code Changed Field Code Changed Field Code Changed

zullen in deze bijlage voorzien worden.24 25Een document met het verschil tussen de huidige versie van het schema en de voorlaatste versie wordt eveneens in deze bijlage voorzien.

10. Gebruikte softwares bij Datassur.

De verschillende softwares zullen geïnstalleerd worden op een windows2008R2-server. In deze architectuur staat centraal de objectgeoriënteerde Java platform (xxxx://xxxx.xxx.xxx), JDK versie

1.6. In deze omgeving zal men de open source Java Sun System Application Server “glassfish” (xxxxx://xxxxxxxxx.xxx.xxxx.xxx) versie 2 gebruiken waarop de applicaties zullen draaien.

Voor het verwerken van de batch bestanden zal de vrije source “open enterprise service bus” (open ESB; xxxxx://xxxx-xxx.xxx.xxxx.xxx) geïnstalleerd worden. Open ESB is een initiatief van Sun MicroSystems op basis van de JBI-specificaties (Java Business Integration) om een fundering te leggen voor de integratie - gebaseerd op de standaarden- van toepassingen in een SOA (”software oriented architecture”)-optiek. Deze ESB bestaat uit 3 elementen: Een berichtenrouter gebaseerd op de norm NMR (Normalised Messages Router)

• De service engines (BPM (Business Process Management), BAM (Business Activity Monitoring), Workflow, engine voor orchestratie en transformatie, scripts, ...)

• De verbindingscomponenten (Binding) zoals web services, (S)FTP, Rosetta Net, Com/DCom, ebXML, enz.

De logica van het systeem zal geïntegreerd worden in een “Model-View-Control” model. Het Model definieert de representatie van de informatie waarmee de applicatie werkt. Aan ruwe gegevens wordt betekenis gegeven door relaties te leggen tussen data en logica toe te voegen. De daadwerkelijke opslag van data wordt gedaan met behulp van een persistent opslagmedium, hier de database. De applicatie zal gegevens die gebruikt worden in het model, ophalen en wegschrijven van en naar de dataopslag via een datalaag. De informatie wordt weergegeven via de View. De view doet geen verwerking (zoals berekeningen, controles,...) van de gegevens die getoond worden. De controller (hier a.h.v. servlets) verwerkt en reageert op events, die meestal het gevolg zijn van handelingen van de gebruiker. De controller kent de view en het model. De view kent alleen het model. Concreet zal hier voor de view (de webapplicatie) beroep gedaan worden op “Java server pages”. Java Server Pages (JSP) (xxxx://xxxx.xxx.xxx/xxxxxxxx/xxx) is een onderdeel van de J2EE- standaard. JSP is een manier om dynamisch HTML, XML of andere inhoud te genereren op basis van statische en dynamische elementen. Voor het model wordt gebruik gemaakt van “entity beans”, dat onder andere persistente data van een database voorstelt. Het genereren van e-mails gebeurt a.h.v. javax.mail en com.sun.mail klassen.

Als database zal MYSQL geïnstalleerd worden. MySQL (xxxx://xxx.xxxxx.xxx) is een open source relationele databasemanagementsysteem (RDBMS), dat gebruikmaakt van SQL. MySQL zorgt voor het opslaan van de gegevens in tabellen, uitvoeren van queries, beheer van de database. Het grote voordeel van MySQL is dat deze database gratis is, zelfs als men MySQL commercieel gebruikt. Daarenboven is MySQL zeer snel, werkt met ongeveer elk besturingssysteem en kan een enorm grote database en veel gelijktijdige gebruikers aan.

Field Code Changed

24 Het gebruik van namespace prefixen is toegelaten: bvb voor de aanvraag van een export <ns0:exportinsurance xmlns:ns0='xxxx://xxx.xxxxxxxx.xx/xxxxxx/XXXxxxxxx0/x0'> in plaats van <exportinsurance xmlns='xxxx://xxx.xxxxxxxx.xx/xxxxxx/XXXxxxxxx0/x0'> maar het respons van het systeem geeft echter geen prefixen. Er wordt

gezocht naar een oplossing om toch namespace prefix te gebruiken, maar vermijd dit als het kan.

25 Gelieve in het begin van de xml « <?xml version="1.0" encoding="UTF-8" ?> toe te voegen om problemen met de encodering te vermijden.

Formatted: Dutch (Belgium)

Om correct de link te leggen tussen de databasegegevens en de objectgeoriënteerde taal zal Hibernate (xxxx://xxx.xxxxxxxxx.xxx) gebruikt worden. Hibernate is een Object/Relational Mapping (ORM) oplossing voor de Java programmeertaal. Het is een open source framework en is een eenvoudig te gebruiken framework voor het koppelen van een object georiënteerd domeinmodel aan een traditionele relationele database. Locking van tabellen kunnen met het gebruik van hibernate ook vermeden worden. Het gebruik van annotations in klassen, variabelen en methodes vereenvoudigt de programmering en laat onder andere toe interface records tussen twee systemen te definiëren en aan te maken bij compilatie. Anders moeten deze interface records voorafgaandelijk manueel aangemaakt worden.

Voor het lezen en aanmaken van batch-xml’s zullen we het door Sun aangeboden framework JAXB (java xml binding; xxxxx://xxxx.xxx.xxxx.xxx) gebruiken. Het gaat om een tool die Java-klassen genereert vanaf een XSD. Dankzij deze klassen kunnen objecten in XML worden omgezet en omgekeerd. Het is niet nodig om hiertoe codes te schrijven. JAXB biedt verschillende mogelijkheden aan om de nodige Java-bronnen en –klassen te genereren. Voor de software ontwikkeling (schrijven, compileren, debuggen en implementeren van de java-code, generen van xml schema’s) zal men de integrated development environment (IDE) NetBeans (xxxx://xxx.xxxxxxxx.xxx) gebruiken. Netbeans is een open source project en bevat tools om alle Java EE components, Enterprise Java Beans (EJBs), web pagina’s, servlets en web services te schrijven.

Gevolgde testprocedures: voor het testen van het opladen van xml bestanden door de ESB worden xml bestanden met random aangemaakte “request blokken” in de juiste directories aangemaakt via JAXB. Voor het testen van de webapplicatie wordt de selenium open source software (xxxx://xxxxxxxxxx.xxx) gebruikt. Deze software is een Firefox add-on en laat toe automatisch webpagina’s op te roepen en gegevens in deze webpagina’s toe te voegen. Deze testprocedure zal op de testomgeving en productie omgeving regelmatig gedraaid worden om problemen sneller te kunnen opsporen bvb database inactief, de ESB pikt de xml bestanden niet op. Sommige problemen kunnen eventueel via automatische weg worden opgelost. Indien deze problemen niet opgevangen kunnen worden, wordt een e-mail opgestuurd.

11 Dedicated Server, toegang en planning.

De software zal geïnstalleerd worden op een (virtuele) Windows 2008R2-server, dat door een firma ter beschikking zal worden gesteld. Datassur krijgt de totale toegang tot deze server (administrator rechten) en kan de server gaan gebruiken en inrichten volgens de eigen noden. Voor deze toepassing zullen een WEB server en Mailserver worden voorzien. Deze server kan door Datassur op afstand worden bediend in geval van problemen (via Remote Desktop SSL verbinding). De server kan op ieder moment worden upgegrade. De server is 24 uur per dag operationeel (24 u monitoring) met een minimale beschikbaarheid van 99.99 %. Er wordt een dagelijkse back-up voorzien van de database.

Alle bestanden van de server worden door een Full Data procedure dagelijks bijgehouden met een “content based” back-up systeem van Symantec waarbij de “agent” dagelijks een lijst maakt van alle bestanden op de server. Een restore van één of meerdere bestanden kan zeer snel aangevraagd worden via controlepanelen van de server. Bij de server zitten ook de nodige veiligheidsdiensten (firewalling, vulnerability scan, antispam, virusscanner) en beheersdiensten (24h server- en applicatie monitoring, e-mail en SMS alerting, bandbreedte monitoring, cold reboot). Interventies kunnen altijd binnen enkele minuten worden uitgevoerd, 24 uren per dag, 7 dagen in de week. Voor

Field Code Changed

de virtualisatie wordt Hyper-V als hypervisor voor de dynamic cloud gebruikt: deze is zeer performant en veilig en biedt volledige autonomie omdat voor iedere virtuele machine een eigen veiligheidsbeleid en een eigen patch management kan gebeuren.

Elke verzekeringsonderneming zal een toegewezen directory krijgen waarop de bestanden met de aanvraag van schadeberichten en de aanvragen tot export van de database kunnen gedeponeerd en afgehaald worden. Men kan dus steeds deze schadeberichten indienen, ongeacht het tijdstip.26 Het antwoord van het platform is onmiddellijk. Binnen de minuut is de aanvraag verwerkt en verschijnt het antwoord (met de aanvaarde en geweigerde records) in xml formaat terug. Voor het verkrijgen van een administrator en FTP-account in test en productie moet het ingevulde document

« TECHNISCHEREGISTRATIERDR.docx » in bijlage worden ingevuld. De instructies staan in dat document.

Het testplan « TESTPLANRDR.docx » dat door elke verzekeringsmaatschappij dient ingevuld te worden, wordt eveneens in bijlage toegevoegd. De instructies staan in dat document.

De testomgeving zal operationeel zijn vanaf begin juli 2012. De productieomgeving vanaf ~~begin~~ ~~januari~~1 maart 2013.

12 Toekennen van de gebruikers in het systeem

Aan elke gebruiker van het systeem wordt een gebruikersnaam en een paswoord voorzien. De gebruiker wordt geïdentificeerd aan de hand van zijn/haar e-mailadres. Het toekennen van de gegevens van de gebruiker wordt door de administrator van de verzekeringsonderneming (1 per verzekeringsonderneming met eventueel een backup administrator) gedaan aan de hand van de webapplicatie. Na login van de administrator, wordt een pagina getoond waarbij de administrator de gegevens(e-mailadres (dit is de sleutel in de tabel), NBB, naam en voornaam, gebruikersnaam en paswoord en taal ) van een gebruiker kan toevoegen, aanpassen of verwijderen. De gebruiker krijgt automatisch een mail toegestuurd met het paswoord. De administrator kan eveneens een overzicht in tabelvorm krijgen van alle gebruikers binnen de verzekeringsmaatschappij. Door op de link onder de kolom “email” te drukken, wordt automatisch de gegevens van de gebruiker op het scherm getoond. De domeinnaam van het e-mailadres van de gebruiker kan verschillen moet die van die van de verzekeringsonderneminginstelling. zijn of dus dezelfde zijn als die vanHet behoort toe aan de administrator om hier van af te wijken wanneer een mandaat is gegeven aan een externe partij.die de gebruiker aanduidt (bvb xxxxxxx.xx, xxx.xx,…). Indien andereEr kunnen eventueel ook domeinnamen worden gebruikt, maar dan moet dit aan Datassur worden gecommuniceerd. Dit kan aan de hand van de registratiefiche. Zo kan een e-mailadres verbonden worden aan verschillende NBB-codes zodat die externe partij dossiers kan beheren van verschillende verzekeringsondernemingen. Hotmail of Yahoo accounts en dergelijke zijn echter niet toegelaten. Het paswoord moet minimaal 8 karakters bezitten.

26 Er zal wel elke dag om middernacht stipt een korte onderbreking zijn van het systeem (een tiental minuten) waarbij een gesloten backup wordt genomen van de database. Alleen op dat ogenblik zal het systeem niet operationeel zijn.

Figuur 10: Webapplicatie voor het toekennen van gebruikersnaam en paswoord door de administrator van de verzekeringsmaatschappij.

🡺 Alleen het toekennen van de gebruikersnaam en het paswoord van de administrator van een verzekeringsonderneming zal door Datassur worden behandeld

Voor bijkomende informatie of suggesties betreffende een verandering in de software kan U

steeds terecht bij: xxxxxxxx@xxxxxxxx.xx Field Code Changed

Document Metadata

Table of Contents

TECHNISCH NOTA RDR E-PLATFORM Stap1

Document Metadata