Het patroon "Informatie verkrijgen" is uitgewerkt in twee sub-patronen:
Hieronder wordt patroon 2b uitgewerkt. Voor een algemene beschrijving van het patroon "Informatie verkrijgen" en de verschillen tussen 2a en 2b verwijzen we door naar de Inleiding op Informatie verkrijgen en de inleiding op patroon 2a.
Bij gegevens die uit meerdere bronnen komen, of kan komen, is het voor de vragende partij niet zonder meer duidelijk welke ketenpartner bevraagd moet worden. Deze informatie kan worden gevonden in de Gegevenscatalogus. Bijvoorbeeld de vraag "wie heeft er gegevens over visumaanvragen?" Op basis hiervan kunnen de ketenpartners of andere bronnen die deze gegevens beschikbaar stellen gericht worden bevraagd op deze informatie.
Van zoeken zoals in patroon 2a is in dit patroon geen sprake: bij het opvragen is altijd bekend over welk v-nummer (één of meerdere) of ander uniek kenmerk informatie opgevraagd wordt.
In termen van de MIDO Domeinarchitectuur gegevensuitwisseling, is de ketenpartner hier zowel de Bronhouder als de aanbieder van de gegevens.
Een toekomstig op API's gebaseerd ketenlandschap, waarbij gegevens zoveel mogelijk bij de bron worden opgevraagd, is inherent peer-to-peer qua architectuur. Op basis van het principe 5c: De keten werkt op basis van gestructureerde gegevens direct uit de bron kan de gewenste specifieke vraag direct aan de ketenpartner worden gesteld waarvan men inmiddels (via de gegevenscatalogus) weet dat deze de benodigde gegevens zou kunnen hebben. Een ketenloket is in dit patroon dus strikt genomen ook niet nodig. En afhankelijk van hoe streng je principe 5c interpreteert ook niet wenselijk.
Toch hebben we in de uitwerking van dit patroon een "Ketenloket" ingetekend. De meerwaarde van zo'n ketenloket is gelegen in het ontzorgen van de afnemende ketenpartner. Deze kan zo één vraag stellen die door het loket wordt uitgesplitst naar vragen aan verschillende ketenpartners, waarna het loket de antwoorden weer samenvoegt in één antwoord. Het zou ook nog wat aggregatie- of privacy-by-design-functies kunnen implementeren zoals het inhoudelijk samenvoegen (bijvoorbeeld optellen), vergelijken of abstraheren (hit-no-hit over ketenpartners heen) van gegevens uit de antwoorden van verschillende ketenpartners. Het voordeel is dan dat je dit dan eenduidig en eenmalig kunt implementeren voor alle ketenpartners. In termen van de domeinarchitectuur gegevensuitwisseling vervult het ketenloket de rol van intermediair. Het is belangrijk dat de intermediair de gegevens niet bewerkt; anders ontstaan er afgeleide gegevens waarvan de intermediair zelf de bron wordt. Dit druist dan zeker in tegen eerdergenoemd MIRA principe 5c. Volgens het principe "afspraken boven standaarden boven voorzieningen" (zie ook MIRA principe 4A) heeft het bewerkstelligen van deze uniformiteit met ketenbrede afspraken of standaarden de voorkeur.
Maar we zijn echter nog niet direct in deze situatie. In de transitie hier naartoe moeten we van een situatie met ebMS-berichten en brokers hier stapsgewijs naartoe bewegen. Dit kan niet allemaal en voor iedereen op het zelfde moment. Een ketenloket is juist erg nuttig om deze transitie te faciliteren. Het kan zo een deel van de afnemers of aanbieders nog een tijdje ondersteunen door api-calls te vertalen naar ebMS berichten of vice-versa.
Om deze reden staat het patroon hieronder uitgewerkt mét ketenloket. Dit ketenloket is echter schuingedrukt en wat lichter gearceerd om de tijdelijkheid te benadrukken. Met uitzondering van de API op de gegevenscatalogus. Deze zal altijd via het ketenloket beschikbaar blijven (zie ook patroon 2a).
De aanbiedende ketenpartners of andere bronnen registeren hun gegevens in de eigen gegevenscatalogus, die periodiek door de keten-catalogus wordt uitgelezen (1).
De afnemende ketenpartner zoekt benodigde gegevens in keten-gegevenscatalogus: welke gegevenssets zijn er beschikbaar bij welke bronnen? (2). In de gegevenscatalogus vindt de afnemer ook de URL waar het deze gegevens kan opvragen.
De afnemende ketenpartner vraagt via het Ketenloket (3a) de gewenste gegevens op bij de gevonden bronnen (3b). In de plaat hebben we dit "ketenapi" genoemd. Dit kunnen echter meerdere api's op één of meerdere registers bij een ketenpartner of andere bron zijn.
De afnemende ketenpartner geeft een doelbindingsclaim mee. Op basis van deze claim (ik ben x en/of heb dit gegeven nodig voor y) wordt bij het opvragen gecontroleerd of de opvrager recht heeft om dit gegeven op te vragen (3c). Deze controle geschiedt door de API en een autorisatiesysteem van de aanbieder zelf. Deze laatste wordt daarbij gevoed door ketenbrede afgesproken en beheerde autorisatieprofielen. In een transitiesituatie kan deze check door het ketenloket en het centrale autorisatieregister worden uitgevoerd (3c*).
Wanneer er door de afnemer wordt getwijfeld aan de juistheid van een gegeven, kan deze dit door middel van een terugmeld-api melden aan de bronhouder (4). In de transitiesituatie is er misschien nog een terugmeldvoorziening nodig die helpt de juiste bronhouder te vinden. In de eindsituatie is dit niet meer nodig en kan er rechtstreeks worden gemeld bij de aanbieder.
Binnen dit patroon moeten enkele afspraken gemaakt worden voor een goede en effectieve werking (zie de afspraken onderaan de figuur). Deze zijn niet specifiek patroon en kunnen teruggevonden worden in het hoofdstuk over Technologie.
Een standaard manier om doelbindingsclaims mee te geven met een zoek- of informatievraag, zodat deze getoetst kunnen worden aan een autorisatieregister met een federatieve werking. Geadviseerd wordt om dit in eerste instantie grofmazig in te richten met de mogelijkheid om door te groeien naar een meer fijnmazige inrichting, indien nodig.
Enkele voorbeelden van grof naar fijn (zie verder het onderwerp toegang/autorisatie):
Waarbij, nogmaals benadrukt, de wet en of de business bepaalt hoe fijnmazig dit in de praktijk ingeregeld dient te worden.
We gaan hier telkens uit van een federatieve werking. De aanbieder hoeft enkel te controleren of de gegevens verstrekt mogen worden op basis van de meegestuurde claim. Als hulpmiddel voor de transitie richten we hiervoor een ketenbreed autorisatieregister, dat wordt gevoed door de autorisatiecomponenten bij de bronnen, in dat aangeeft met welke claims je welke gegevens (obv gegevenscatalogus) mag opvragen. De opvrager dient te controleren en bewaken dat de opvraag en opvragende ambtenaar ook daadwerkelijk aan de gestelde claim voldoet. (dwz. dat de medewerker ook daadwerkelijk een beslismedewerker is). Achteraf kan hier dan periodiek op geaudit worden.
In de situatie zonder ketenloket vervalt het centrale autorisatieregister en wordt het vervangen door gezamenlijke afspraken/standaarden over het actueel houden van de doelbindingclaims).
Zie ook de standaard (in wording) rondom Federatieve Toegangsverlening (FTV) in het Federatief Datastelsel.
Een break-the-glass mechanisme om gegevens toch te kunnen opvragen in geval van nood wanneer een juiste doelbindingsclaim ontbreekt maakt deel uit van de ketenapi's.
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Autorisatieregister | Component in centrale voorzieningen waarin ketenbreed is vastgelegd op basis van welke claim welke gegevens mogen worden opgevraagd. |
|
| Gegevenscatalogus | Een centrale voorziening waarin de gegevens die aangeboden worden door centrale registers en individuele ketenpartners binnen de Migratieketen worden bijgehouden en gepubliceerd. |
|
| Ketentransitieloket | Tijdelijk loket om de transitie van berichten geaseerd op ebMS naar API's te ondersteunen |
|
| Terugmeldvoorziening | Component in centrale voorzieningen dat terugmeldingen van afnemers in geval van gerede twijfel over de kwaliteit van ene gegeven routeert naar beherende ketenpartners. |
|
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Gegevenscatalogus api | API waarmee API’s gezocht kunnen worden in de ketenbrede catalogus |
|
| Ketenapi | API waarmee gegevens van ketenpartners kunnen worden opgevraagd |
|
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Autorisatiesysteem aanbieder | Component bij ketenpartner waarin is vastgelegd op basis van welke claim welke gegevens mogen worden opgevraagd. | |
| Bronsysteem gegevens | Systeem van partij die gegevens aanbiedt | |
| Gegevens afnemend systeem | Systeem van partij die gegevens afneemt | |
| Gegevenscatalogus Ketenpartner | Gegevenscatalogus per aanbieder van gegevens die de gegevenssets die door de aanbieder worden aangeboden ontsluit en publiceert naar de ketenbrede gegevenscatalogus. |
| Has target element | Omschrijving | Toelichting |
|---|---|---|
| Terugmeld api | API waarmee melding van verdenking van onjuistheid / verzoek tot aanpassing aangeleverd kan worden aan de bronhouder |
|
| Ketenapi | API waarmee gegevens van ketenpartners kunnen worden opgevraagd |
|
Op de opvraag API’s implementeren de ketenpartners (volgens ketenbrede afspraak) vraaggestuurde dataminimalisatie. Dat betekent dat de vrager expliciet moet specificeren welke informatie (attributen/elementen) opgevraagd worden. Als een opvrager geen lijst met gewenste gegevens opgeeft in de query dan wordt er niet alles geantwoord maar niets (privacy by design principe van minimalisatie).
Enkel keten- en samenwerkingspartners kunnen deze gegevens opvragen. Samenwerkingspartners kunnen wel zien welke gegevens er beschikbaar zijn via de catalogus, maar krijgen enkel toegang tot specifieke gegevens indien dit expliciet is toegestaan in het autorisatieregister (white-listing).
Uiteraard worden bevragingen aan vraag- en aanbodkant gelogd, zodat er ketenbreed een audittrail te reconstrueren is.
Er komt steeds meer informatieuitwisseling tussen NL en Europese ketenpartners. Zie Thema 3: Klaar voor Europese Samenwerking. Met het Migratiepact komen er op korte termijn al enkele grote veranderingen en dit zal naar verwachting in de toekomst alleen nog maar toenemen.
In bovenstaand patroon staat het Europaloket als centrale voorziening getekend die zich gedraagt als een ketenpartner die gegevens kan aanbieden aan de afnemers. Gegevens die in Europa beschikbaar zijn worden op een vergelijkbare wijze in de Gegevenscatalogus geregistreerd. Terugmelden kan ook op dezelfde manier gebeuren, mits de Europese bron terugmeldingen accepteert uiteraard.
Dit hoofdstuk beschrijft hoe de transitie van de huidige situatie naar de in deze architectuur geschetste stip zou kunnen verlopen. Dit is geen zuivere architectuur meer, maar door dit uit te werken kan de impact en betekenis van hetgeen hierboven geschetst wordt beter ingeschat worden. Deze uitwerking is enkel indicatief. Na goedkeuring van deze architectuur moeten dit verder worden uitgewerkt in een meer gedetailleerde en liefst integrale planning.
Voorziene stappen voor de transitie zijn:
Hierbij is telkens aangegeven of deze vraagstukken in een volgende versie van deze architectuur of in de onderliggende solutions moeten worden uitgewerkt.
| Onderwerp | Toelichting | Wanneer uitwerken | Uitwerking |
|---|---|---|---|
| Omgaan met documenten | Voor documenten is er conform MIRA principe 5c geen afzonderlijk patroon of register getekend. Opvragen geschiedt volgens het zelfde patroon als gestructureerde gegevens. Zo wordt dubbel gebruik van CDD (archief en uitwisselvoorziening) voorkomen, (confom MIRA principe 4c). Dit wijkt af van huidige werkwijze met CDD en ketendocumenten. | In een volgende versie impact verder uitwerken | - |
| Logging | Kunnen we volstaan met generieke afspraken over logging, of moet dit nog in de platen worden getekend? | Volgende versie | - |
| Terugmelden | De terugmeldvoorziening verdwijnt in dit patroon uiteindelijk helemaal, maar heeft nog een rol in het transitiescenario met het ketenloket. Past deze rol bij de huidige opzet? | Volgende versie | - |
| Inkijk | De inkijkvoorziening is in de huidige opzet beperkt tot inzage in gegevens uit de centrale registers. Wellicht wordt de behoefte ook voor dit patroon relevant. | Volgende versie | Er is momenteel inkijk op het kaartregister dat we decentraal willen positioneren. Hiermee manifesteert deze vraag zich al. |
Deze pagina is voor het laatst bewerkt op 10 mrt 2025 om 15:25.