TECHNISCH NOTA RDR E-PLATFORM Stap1

Transcriptie

1 Versie 6. 01/10/ Inleiding. TECHNISCH NOTA RDR E-PLATFORM Stap1 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 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. 1

2 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 verzekeraartegenpartij, 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 RDRprocedure 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. 2

3 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. 3

4 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: 4

5 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 36 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 helpdesk@datassur.be 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. 5

6 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. 6

7 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 adres (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. 7

8 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 Veridass 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 Veridass 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 Veridass 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. 8

9 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 GMWF 15 (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. 9

10 versturen van s, 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 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 voorzien, zodat eventuele versies horend bij het initieel schadebericht naar hem kunnen g d 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 10

11 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. 11

12 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, van afdeling schade). De tabel user geeft informatie rond de geautoriseerde gebruikers voor elke maatschappij (userid (= adres), 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 adres 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. 12

13 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 13

14 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 ( of batch xml). Voor het beantwoorden van een schadebericht geldt het analoge. 14

15 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 15

16 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. 16

17 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: 17

18 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 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 ( adres), 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. 18

19 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. 19

20 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. 20

21 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: 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 encryptie van de verzonden informatie waarbij de confidentialiteit en integriteit van de informatie 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. 21

22 Doel Directory Naamgeving input xml/pdf Levering bulk root/ /request schadeberichten Export records root/ //export Datassur Levering versie root/ //versionupload files Aftap versie files root/ //versiondownload (en versiondownloadbackup ) rdrinsurance_timestamp.x ml rdrinsuranceexport_timest amp.xml Geen beperking? Ophogend volgnummer + identificatienummer.pdf Naamgeving output xml/pdf (genereerd door Datassur) rdrinsurance_timestamp1_output.xml rdrinsuranceexport_timestamp1_output. xml Ophogend volgnummer + identificatienummer.pdf / rdr refereert naar de applicatie, timestamp heeft het formaat yyyymmdd-hh-mmss-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 rdrinsurance xml en output rdrinsurance _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_ xml 3411b f14-9f f590c525] 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. 22

23 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 '{" 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 adres 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 23

24 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). 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, subelementen, 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: De 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: 24

25 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 gebruiker 21, 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 adres) geregistreerd is in het systeem; 25

26 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: 26

27 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) Voorbeelden van elke xml 22 Alle bijlagen kunnen worden gedownload op de link 23 De parser van het platform die de xml zal behandelen laat geen Byte Order Mark toe ( ). 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 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. 27