Hoofdstuk 7. Koppelvlakken

• 7.1 Raadplegingen (pull­‐berichten)
• 7.2 Meldingen (push‐berichten)
• 7.2.1 Signalen
• 7.2.2. Suwinet-Meldingen
• 7.2.3 Correctieverzoeken

De inrichting van de keten werk en inkomen is gebaseerd op een servicegerichte architectuur (service oriented architecture, SOA). In deze architectuur ligt de nadruk op goed gedefinieerde services die zinvol zijn voor de business. Servicegerichte architectuur gaat over dienstverlening van ketenpartijen aan klanten en andere partijen, maar ook over services op functioneel niveau: van het ene systeem aan een ander systeem.

Dit hoofdstuk gaat over die functionele invulling van de servicegerichte architectuur en over de standaardisatie en koppelvlakken die we op dat gebied nastreven.

• Welke services?

Welke services een ketenpartij aan andere partijen en/of aan klanten biedt, hangt nauw samen met de ketenregistraties waar die partij verantwoordelijk voor is. Zoals beschreven in hoofdstuk 6 heeft een registratiehouder van een ketenregistratie verantwoordelijkheden op het gebied van ontsluiting van de data uit de ketenregistratie, ten behoeve van de afnemers. De ontsluiting moet zo veel mogelijk op een gestandaardiseerde manier gebeuren, met nauwkeurig gespecificeerde koppelvlakken.

We maken onderscheid tussen gegevensdiensten en informatiediensten. Gegevensdiensten leveren ‘kale’ gegevens vanuit de registratie. Informatiediensten implementeren een bewerking op die gegevens.

Die bewerking kan bestaan uit het bij elkaar brengen van gegevens rond eenzelfde zoeksleutel uit verschillende achterliggende bronsystemen (zoals Suwinet-­‐Inkijk dat doet), maar ook uit het daadwerkelijk toepassen van bedrijfsregels om dienstverleningsrelevante informatie te creëren uit de kale gegevens.

De wijze waarop de betrokken gegevensdienst een webservice implementeert, is aan de registratiehouder zelf. Ook de wijze waarop de applicatie die de webservice gaat aanroepen gebouwd wordt, is aan de afnemende partij zelf. De servicegerichte architectuur bemoeit zich hier voornamelijk met de informatie-­‐ uitwisseling en de koppelvlakken, op basis van berichtenverkeer.

• Wat is een koppelvlak?

Bij geautomatiseerde koppelingen tussen gedistribueerde systemen (machine-­‐machine) is er sprake van een interface waarmee communicatie mogelijk wordt gemaakt. Zo’n interface wordt een koppelvlak genoemd. De beschrijving van een koppelvlak noemen we koppelvlakspecificaties.

Dit is analoog aan niet-­‐ geautomatiseerde interacties tussen een professional en een front end-­‐applicatie (mens-­‐machine), waar de grafische gebruikersinterface communicatie mogelijk maakt. De beschrijving hiervan wordt vastgelegd in een functioneel ontwerp van de schermen.

Afbeelding 12. Beschrijving koppelvlak

Bij de realisatie van bedrijfsapplicaties zijn beide varianten van belang. Behalve dat het te bouwen systeem aan de gebruikers de juiste functionaliteit moet bieden, moet het systeem aan de achterkant de voorgeschreven koppelvlakken implementeren. Zo moet bijvoorbeeld ieder GSD-­‐systeem onder andere de webservices 'GSDDossierPersoon' en 'AanvraagWWB' implementeren conform de betreffende koppelvlakspecificaties.

• Standaard voor koppelvlakspecificaties

Voor webservices is de Web Services Description Language (WSDL) een internationaal breed geaccepteerde standaard voor het maken van koppelvlakspecificaties. Deze standaard wordt volop ondersteund in veel software. De beschrijving van de technologie van WSDL en het bijbehorende XML-­‐schema valt buiten de scope van deze ketenarchitectuur. De SuwiML Transactiestandaard geeft hiervan een uitgebreide beschrijving, inclusief de manier waarop we WSDL in de keten werk en inkomen toepassen. 

Afspraak 28       Ketenpartijen gebruiken gestandaardiseerde koppelvlakken; bijvoorbeeld op basis van open standaarden en/of SUWI-­standaarden.

 In de Suwiketen wordt ook gekeken naar andere standaarden waaronder de landelijke e-­‐overheid standaard Digikoppeling. Digikoppeling is een standaard voor logistieke berichtuitwisseling. Digikoppeling regelt een aantal logistieke aspecten van de gegevensuitwisseling zoals beveiliging, vertrouwelijkheid, integriteit, betrouwbaarheid en onweerlegbaarheid. Digikoppeling standaardiseert de logistieke laag (header); de inhoud (body) is domeinspecifiek (bijvoorbeeld SuwiML voor uitwisselingen tussen Suwipartijen). De SuwiML Transactiestandaard wordt op Digikoppeling aangepast.

• Digikoppeling

De landelijke e-­‐Overheid heeft behoefte aan een goede standaardisatie op het gebied van berichtenverkeer. De standaarden voor Digikoppeling (voorheen Overheidsservicebus) zijn opgesteld op basis van enkele relevante internationale standaarden, zoals de WS-­‐* standaarden en de ebXML-­‐ familie.

Services op basis van Digikoppeling moeten zich houden aan profielen gebaseerd op de Nederlandse keuzen voor de doorvertaling van die internationale standaarden. De services zelf zijn niet door het Digikoppeling-­‐project ontwikkeld maar moeten gespecificeerd, geïmplementeerd en beschikbaar gesteld worden door de landelijke basisregistraties, de grote landelijke uitvoeringsorganisaties en verschillende andere overheden.

Allerlei overheidsinstellingen kunnen die services (mits geautoriseerd) vervolgens aanroepen en gebruiken. Ter ondersteuning heeft het Digikoppeling-­‐project een serviceregister en een compliancevoorziening opgeleverd.

Bij Digikoppeling zijn wat andere keuzes gemaakt dan oorspronkelijk in de keten werk en inkomen. De SuwiML Transactiestandaard licht deze verschillen toe. In de doorontwikkeling van de SuwiML standaard naar versie 4.0 wordt de beweging in de richting van Digikoppeling 3.0 vormgegeven.

Digikoppeling vereist dat gegevenstransport beveiligd moet zijn met TLS. Hiernaast biedt het mogelijkheden om de onweerlegbaarheid en identiteit van de afnemers vast te stellen op basis van het met PKI-­‐certificaten ondertekende berichten. Zeer vertrouwelijke of geheime gegevens kunnen end-­‐to-­‐end ge-­‐encrypt getransporteerd worden. Het autorisatiemodel is gebaseerd op organisatieniveau.

 Afspraak 29       Voor ieder koppelvlak met webservices worden specificaties gemaakt in SuwiML conform de SuwiML Transactiestandaard.

• Fysieke implementatie

Na vaststelling van de koppelvlakspecificaties voor een service kan men de service fysiek implementeren. De webservice komt dan beschikbaar op een applicatieserver. De webservice houdt zich precies aan de koppelvlakspecificaties: hij ontvangt, herkent en valideert de gespecificeerde requests en hij stuurt responses terug die ook aan de koppelvlakspecificaties voldoen.

• Soorten services

Er zijn verschillende soorten services, ieder met eigen kenmerken voor de bijbehorende koppelvlakken:

• Raadplegingen (bevragingen).
• Meldingen (waaronder: Suwinet Meldingen, Signalen en Abonnementenregistratie).

Deze tweedeling is in lijn met Digikoppeling waarbij het onderscheid tussen profielen gebaseerd is op wie de uitwisseling initieert, de afnemer of de leverancier (pull of push).

• Randvoorwaarden

Bepaalde randvoorwaarden zijn bij de verschillende soorten services soms wel en soms niet aan de orde. Dat hangt af van het type uitwisseling (Architectuur Digikoppeling). Deze randvoorwaarden zijn met name:

• Reliable messaging

Bij sommige uitwisselingen van meldingen vereisen het bedrijfsproces en de ondersteunende applicatie absolute zekerheid dat een bericht aankomt. Dit is vooral vereist bij meldingen. Een melding is namelijk vaak een trigger voor het proces bij de andere partij.

• Tussenstations

Bij sommige uitwisselingen is de toepassing van tussenstations gewenst of zelfs noodzakelijk. Hierbij loopt de communicatie van de bron naar de bestemming via het tussenstation. Een tussenstation is een oplossing als de bestemming via de bestaande netwerken niet rechtstreeks bereikbaar is vanaf de bron.

Er bestaan transparante en niet-­‐transparante tussenstations. Niet-­‐transparante tussenstations hebben vaak ook de functie om te ontkoppelen. Dit kan bijvoorbeeld nodig zijn om downtijden bij de bestemming te ondervangen, het bericht door te kunnen verwijzen of berichten op maat te kunnen afleveren.

Het tussenstation kan dan zorgen voor caching, adressering, gegevenslogistiek, performance management en transformatie. Wanneer tussenstations worden gebruikt, is meer aandacht voor reliable messaging noodzakelijk. Bij tussenstations is het ook wenselijk om berichten te ondertekenen en eventueel te versleutelen.

Bovendien kan de service van het tussenstation (iets) afwijken van de service die de bestemming levert. Dit moet dan ook in de koppelvlakspecificaties tot uiting komen.

Alle bovenstaande varianten worden ondersteund door en besproken in de SuwiML Transactiestandaard.

• Opname in het serviceregister

In de keten werk en inkomen wordt geen gebruik meer gemaakt van een centraal serviceregister. Wel wordt zo nu en dan het Digikoppeling Serviceregister geraadpleegd.

• Services voor registraties buiten de keten

Ketenpartijen kunnen gegevens nodig hebben uit een (basis)registratie buiten de keten. Hiervoor kan een vertaling gemaakt worden in SGR / SuwiML. Vervolgens kunnen ook deze gegevens ontsloten worden met SuwiML webservices.

Momenteel zijn er bijvoorbeeld al SuwiML webservices beschikbaar voor het ontsluiten van gegevens uit de Basisregistratie personen (BRP, voorheen GBA), de Rijksdienst voor het Wegverkeer (RDW) en de Kamers van Koophandel. Deze SuwiML-­‐varianten van externe services worden centraal in de keten beschikbaar gesteld aan afnemers, dan wel gebruikt door Suwinet Inkijk.

Dit vraagt om een transformatie van een extern gegevensformaat van en naar SuwiML, en eventueel een transformatie op het gebied van autorisatie. De externe registratie kan verlangen precies te weten wie de afnemer is.

Bij verzoeken die via een SuwiML webservice naar de registratie gaan, kan het BKWI als centrale beheerder voor de SuwiML webservice zich niet voordoen alsof zij de afnemer zelf is. BKWI voert het beheer in opdracht van ketenpartijen of de registratiehouder. De bron is altijd leidend voor de eisen aan authenticatie en autorisatie. Op welke plek dit geïmplementeerd wordt, is ook aan de bron. Afnemers kunnen dit uitbesteden aan BKWI.

• Verbeteren transparantie

De NORA stelt met betrekking tot transparantie onder andere:

P15. ‘Organisaties in het publieke domein maken zichtbaar wat zij doen, welke besluiten zij nemen, welke gegevens zij hebben en gebruiken en wat hun werkwijze is.’

P12. ‘Overheidsorganisaties betrachten maximale transparantie voor de betrokkenen wat betreft de op hen betrekking hebbende verwerking van persoonsgegevens en verstrekkingen aan derden van die persoonsgegevens. Zij streven daarom naar inzage langs elektronische weg voor die betrokkenen.’

Dit is binnen het SUWI-‐domein grotendeels te realiseren door voor iedere raadpleging en ieder signaal een afslag naar de Berichtenbox op Mijnoverheid.nl te sturen. Dit leidt tot veel extra berichtenverkeer, maar het geeft de geïnteresseerde burger een beter beeld van wat er met zijn gegevens gebeurt.

Wat weer bijdraagt aan de bewustwording bij overheidspartijen over het gebruik van gegevens. De Berichtenbox op MijnOverheid.nl zou de burger de mogelijkheid kunnen bieden om aan te vinken of hij dit soort mededelingen wil ontvangen of niet.

Een minder vergaande mogelijkheid om de burger transparantie te bieden is de website www.burgerservicenummer.nl. Per organisatie zou daar kunnen staan welke soorten gegevens gebruikt worden. Dit is op het moment van schrijven nog niet gerealiseerd. Organisaties met een FG (Functionaris Gegevensbescherming) hebben bovendien geen meldingsplicht naar het College Bescherming Persoonsgegevens (CBP), waardoor hun gebruik ook niet te vinden is op de site van het CBP.

7.1 Raadplegingen (pull­‐berichten)

Raadplegingen zijn de meest gebruikte webservices in de keten. Webservices van het type raadplegingen ontsluiten de informatie uit de verschillende ketenregistraties. Meestal is een burgerservicenummer vereist in de request, de response geeft vervolgens informatie over de persoon met dat burgerservicenummer.

Hieronder gaan we dieper in op de eisen die worden gesteld aan raadplegingen. Het burgerservicenummer is niet altijd de identificerende sleutel. Andere identificerende sleutels of nummers zijn ook mogelijk, bijvoorbeeld de identificatie van een werkgever met het zogenaamde KVK-­‐nummer of (in de toekomst) RSIN (Rechtspersonen Samenwerkingsverbanden Informatie Nummer).

Andere raadplegingen zijn zoekopdrachten en niet-­‐vertrouwelijke raadplegingen; zij krijgen aan het eind van deze paragraaf nog kort de aandacht.

Afbeelding 13. Push berichten

• Hoge beveiligingseisen

Bij de meeste raadplegingen wordt vertrouwelijke informatie over een klant verstuurd. Daarom worden hoge eisen aan de beveiliging gesteld. De webservice is alleen toegankelijk voor bevragingen door afnemers die geautoriseerd zijn. In de service level agreements staan afspraken over het gecontroleerd beschikbaar stellen van de gegevens aan de gebruikers bij de afnemer, dat wil zeggen: alleen aan geautoriseerde professionals.

• Doelbinding

Bij het maken van koppelvlakspecificaties moet het principe van doelbinding een van de uitgangspunten zijn. Het principe van doelbinding heeft gevolgen voor de koppelvlakken van het type raadplegingen: de informatieset in de response moet aansluiten bij het werkproces waarvoor de informatie op dat moment van belang is.

Wanneer een ketenregistratie verschillende logische subsets bevat, dan moeten die subsets in de koppelvlakken afzonderlijk opvraagbaar zijn. Zo kan de gevraagde informatie goed afgestemd zijn op de informatiebehoefte van de gebruiker op dat moment (proportioneel), en bij de stap in het werkproces die door de gebruiker uitgevoerd wordt.

Afspraak 30    De partij die een raadpleging-­‐webservice van een ketenregistratie aanroept zal de verkregen informatie niet zelf opslaan, behalve als bewijslast bij de genomen besluiten. 

• Granulariteit in de koppelvlakken

Doordat de logische subsets afzonderlijk beschikbaar gesteld worden in de koppelvlakken van raadplegingen, ontstaat er een zekere granulariteit in de koppelvlakken. Deze granulariteit moet goed zijn, maar ook werkbaar. Te fijnkorrelig is niet werkbaar, bijvoorbeeld als in de koppelvlakken per gegeven een aparte raadpleging gespecificeerd wordt.

Aan de andere kant doet te grofkorrelig geen recht aan het principe van doelbinding, bijvoorbeeld als er hele dossiers meegestuurd worden in de response op een raadpleging. Er ligt momenteel een voorstel om te gaan werken met ‘logische gegevensclusters’ die aansluiten op de functionele behoeften van de afnemers in de keten, en recht doen aan de samenhang van de gegevens in de registraties.

Afspraak 31      De partij die een raadpleging-­‐webservice aanroept is verantwoordelijk voor zorgvuldig gebruik van de geraadpleegde informatie door zijn medewerkers en ziet toe op autorisaties, doelbinding, beveiliging en de proportionele gegevenslevering binnen zijn organisatie.

•  SuwiML koppelvlakspecificaties per raadpleging

Voor iedere raadpleging worden SuwiML koppelvlakspecificaties gemaakt. Het heengaande bericht bevat ten minste het burgerservicenummer, het teruggaande bericht bevat de gevraagde informatie over de persoon met dat burgerservicenummer. In het heengaande bericht kunnen daarnaast aanvullende parameters gespecificeerd zijn wanneer die voor de betrokken ketenregistratie nodig zijn om tot een juiste response te komen.

Afspraak 32       De bevraging van ketenregistraties geschiedt op basis van webservices. 

• Zoekopdrachten

Naast raadplegingen aan de hand van een burgerservicenummer zijn allerlei andere zoekopdrachten mogelijk. Op basis van een zoeksleutel in het request zal de response een aantal treffers bevatten. De kadaster-­‐webservice kent bijvoorbeeld de mogelijkheid om de gerechtigden (eigenaren) van een kadastraal object op te vragen. Belangrijk is dat de koppelvlakspecificaties de oplevering van treffers scheiden van allerlei nadere informatie over die treffers. Dat zijn namelijk verschillende soorten raadplegingen waarvoor verschillende autorisaties kunnen gelden.

• Niet‐vertrouwelijke raadplegingen

De PostcodeTabelwebservice is een voorbeeld van een raadpleging zonder vertrouwelijke informatie. In het request zit een postcode of een gemeentecode, en in de response de bijbehorende plaatsnaam of gemeentenaam. Dit betreft openbare informatie en daarom gelden hierbij minder strenge eisen aan de beveiliging en aan de mogelijkheden voor tracking en tracing. Daardoor zijn bijvoorbeeld minder veiligheidsmaatregelen vereist in de koppelvlakspecificaties.

7.2 Meldingen (push‐berichten)

Naast webservices voor raadplegingen kennen we webservices voor meldingen. Waar raadplegingen zijn bedoeld om informatie op te halen, gebruiken we meldingen om informatie te sturen. De keten werk en inkomen kent verschillende soorten meldingen. Een belangrijk onderscheid daarbij is of er wel of geen inhoudelijke gegevens meegestuurd worden.

Een Signaal bevat alleen de mededeling DAT er gegevens beschikbaar zijn gekomen, een Melding bevat ook de te leveren gegevens. We noemen dat respectievelijk een dun of een dik bericht.

We bespreken hieronder de voorziening Suwinet Meldingen en de Signalen. Daarnaast bespreken we de Centrale Abonnementenregistratie inclusief het landelijke Digilevering.

7.2.1.        Signalen

Signalen zijn hier elektronische berichten die een gebeurtenis melden, zoals de start of beëindiging van een uitkering, een dienstverband of een opleiding. Het gaat om veranderingen in de ketenregistraties. Omdat die veranderingen invloed kunnen hebben op de dienstverlening van ketenpartijen, worden koppelvlakspecificaties gemaakt van signalen. Een signaal bevat het burgerservicenummer van de betrokkene en de precieze gebeurtenis die heeft plaatsgevonden.

Afhankelijk van de noodzaak om naast het gemelde feit middels een signaal (dun bericht) een eerste beoordeling van het gemelde feit te kunnen doen worden enige inhoudelijke gegevens toegevoegd. Er wordt dan gesproken over een melding (dik bericht).

Echter niet alle daadwerkelijke gegevens die de gebeurtenis beschrijven worden toegevoegd. De afnemer moet de gegevens die nodig zijn voor een verdere beoordeling met een aparte bevraging ophalen. Het signaal wordt direct of via een centrale of decentrale abonnementenregistratie verspreid naar de partijen die de betrokkene als klant hebben of krijgen, en waarbij de gebeurtenis mogelijk van invloed is op de dienstverlening.

Afbeelding 14. Signalen

• Centrale Abonnementenregistratie

De signalen worden bij voorkeur gegenereerd door de eigenaar van de (keten)registratie. Om de verspreiding van signalen naar afnemers te ondersteunen, wordt een Centrale Abonnementenregistratie ingericht in de GeVS. In de Abonnementenregistratie wordt bijgehouden welke signalen (en onder welke condities) op welke manier naar welke partijen of systemen gestuurd moeten worden. De ketenregistratie hoeft alleen zijn signalen naar de Abonnementenregistratie te sturen; de registratie verzorgt de verdere verspreiding.

Registratiehouders kunnen ook een eigen abonnementenregistratie inrichten en zelf signalen naar abonnees versturen. Een mogelijke variant is dat de ketenregistratie wel via de Abonnementenregistratie achterhaalt waar men op een bepaald moment een bepaald signaal heen moet sturen, maar dat de ketenregistratie het daadwerkelijk versturen van het signaal aan abonnees zelf voor zijn rekening neemt.

Voor de landelijke basisregistraties is een dergelijke voorziening in het leven geroepen die op dit moment geleidelijk wordt uitgerold. Deze heet Digilevering. Het is nadrukkelijk de bedoeling dat de Suwiketen op Digilevering gaat aansluiten voor het gebruik van de basisregistraties.

Om de verspreiding van signalen ook voor ketenregistraties mogelijk te maken is het nodig een ketenvoorziening in te richten voor de abonnementenregistratie en de afhandeling ervan. Deze dient dan als tussenliggende voorziening tussen Digilevering en de ketenpartijen, en handelt abonnementen ten aanzien van de ketenregistraties af.

Afspraak 33       De Abonnementenregistratie voorziet in beheerschermen waarin afnemers zelf hun abonnementen kunnen starten, beëindigen en onderhouden.

Afspraak 34       De Centrale Abonnementenregistratie wordt beheerd door BKWI.

Afspraak 35       Voor al het berichtenverkeer met de SUWI-­‐abonnementenservice wordt gebruik gemaakt van Digikoppeling WSRM-­‐profielen en de uitwisselingsstandaarden van Digilevering.

Afspraak 36       Signalen worden gegenereerd door de (keten-­‐ of basis)registraties.

Afspraak 37       Alle gestructureerde informatie die ketenpartijen uitwisselen, is gedefinieerd en vastgelegd in het SUWI Gegevens Register.

Afspraak 38       Voor ieder signaal worden conform SGR de SuwiML koppelvlakspecificaties gemaakt.

Het heengaande bericht bevat de gebeurtenis (zo nodig aangevuld met relevante parameters bij deze gebeurtenis) en het burgerservicenummer; het teruggaande bericht bevat een ontvangstbevestiging.

Afspraak 39       Afnemers richten webservices in (conform de koppelvlakspecificaties) om signalen te ontvangen die voor hen relevant zijn en waarvoor zij geautoriseerd zijn.

Afspraak 40       De Centrale Abonnementenregistratie heeft voor ieder signaal een webservice die voldoet aan de vastgestelde koppelvlakspecificaties en aan de SuwiML Transactiestandaard.

De dienstverlening van de afnemer reageert op de ontvangst van signalen. Daarom is gegarandeerde aflevering noodzakelijk bij signalen. Dit is een belangrijk verschil met raadplegingen, en het stelt extra eisen aan het systeem dat de signalen verstuurt én aan het systeem dat de signalen ontvangt.

De SuwiML Transactiestandaard wordt op dit punt doorontwikkeld om een profiel te realiseren waarin conform Digikoppeling 3.0 een WSRM (WebservicesReliable Messaging) beschikbaar komt. Na ontvangst van een signaal kan de afnemer besluiten om via een raadpleging gedetailleerde informatie (over de gebeurtenis, of over de klant) op te halen.

7.2.2.        Suwinet-Meldingen

Suwinet Meldingen is de voorziening waarmee berichten betrouwbaar op de juiste bestemming kunnen worden afgeleverd. Het gaat op dit moment om het doorsturen van aanvragen voor Bijstand bij gemeenten. Suwinet Meldingen is nog in ontwikkeling. Zo is het nog nodig het berichtenverkeer conform Digikoppeling in te vullen met een vorm van reliable messaging, in plaats van de tijdelijke store-­‐and-­‐forward.

Van belang is dat het in het geval van Suwinet Meldingen gaat om ‘dikke’ berichten. Het zijn berichten die de daadwerkelijk relevante gegevens bevatten. Er is dus geen bevraging nodig na het ontvangen van de melding.

• Verschil met signalen

Een belangrijk verschil tussen signalen en de Suwinet Meldingen is dat er met de Suwinet Meldingen meer informatie uitgewisseld wordt tussen de ketenpartijen. De signalen beperken zich veel meer tot hun signaalfunctie, namelijk een melding dat een gegeven of een situatie veranderd is. De gegevens zelf blijven opgeslagen in de ketenregistratie waar ze thuis horen, maar kunnen uiteraard wel geraadpleegd worden via Suwinet-­‐Inkijk of via andere bevragende applicaties.

Het versturen van onnodig grote hoeveelheden gegevens en/of informatie door de keten moet worden voorkomen. Een signaal dat de gegevens zijn opgenomen in een ketenregistratie heeft daarom de voorkeur. Op deze manier worden de meest actuele gegevens gebruikt en overal beschikbaar gesteld.

7.2.3.        Correctieverzoeken

Het doorvoeren van mutaties in een ketenregistratie moet gecontroleerd gebeuren en wordt voornamelijk uitgevoerd door bevoegde professionals in een front end-­‐applicatie van de ketenregistratie zelf. Aanlevering van correctieverzoeken kan echter ook vanuit andere applicaties plaatsvinden, door andere professionals of door burgers zelf. De centrale SUWI Correctieservice faciliteert dit.

De correctieverzoeken moeten voldoende informatie bevatten om een onderzoek te starten en om uiteindelijk te beslissen of het correctieverzoek wordt geaccepteerd of verworpen. Daarom zijn er ook koppelvlakspecificaties beschikbaar voor correctieverzoeken. Deze specificaties worden geïmplementeerd in de Correctieservice.

Iedere applicatie die zijn gebruikers correctiemogelijkheden biedt, kan de correctieverzoeken van zijn gebruikers conform deze specificaties aanleveren bij de centrale Correctieservice. De Correctieservice stuurt het correctieverzoek door naar de verantwoordelijke ketenregistratie.

Bezien vanuit het bovenstaande gaat het bij correctieverzoeken over meldingen (Digikoppeling, push).

Afbeelding 15. Correctieverzoeken

 

 

Afspraak 41       Ketenregistraties sluiten aan op de Correctieservice. Afspraak 42       Bevragende applicaties sluiten aan op de Correctieservice.

Samenvattend onderkennen we voor het koppelingen domein de volgende componenten:

	Componentnaam	Doel
1	SuwiML	Gemeenschappelijke taal
2	Suwinet-Inlezen	Leveren van gegevens in de vorm van vraag-­‐ / antwoord-­‐berichten
3	Suwinet-Meldingen	Aanleveren van gegevens in de vorm van push berichten
4	Filtermechanisme	Voorziening t.b.v. implementeren proportionaliteit
5	IB broker	Centraal gemeentelijk verdeelstation
6	SUWI bulk Servcies	Service voor ondersteunen van beperkte bulkverwerking
7	Stekker 4	Ontsluitingsmethodiek van gemeenschappelijke voorzieningen tussen gemeenten en         UW
8	Digilevering	Signalen doorgeven
9	RINIS	Connectiviteit en transformatieberichten
10	Digikoppeling	Informatielogistiek protocol
11	Digimelding	Terugmelding op basisregistraties
12	Berichten op Maat (BOM)	Berichten die op maat worden samengesteld uit berichten van de bron