Het patroon "Informatie verkrijgen" is uitgewerkt in twee sub-patronen:
Informatie die in gezamenlijke registraties wordt opgenomen is informatie die door verschillende ketenpartners kan worden aangemaakt of worden bewerkt. In de Migratieketen gaat het hier concreet over persoonsgegevens, biometrie en gegevens over vreemdelingendocumenten in de centrale registers in de keten. Dit staat hieronder uitgewerkt onder patroon 2a.
Alle overige informatie die in de keten wordt gebruikt komt uit één of meerdere bronnen bij ketenpartners of andere bronnen (o.a. Europese Bronnen). Dit is patroon 2b.
Het ligt aan het soort gegevens welk patroon van toepassing is. Dit is verder uitgewerkt in het hoofdstuk over het Informatielandschap van de Migratieketen. Op basis van de principes in de MIRA: 5B: Elk gegeven heeft een verantwoordelijke en 5C: De keten werkt op basis van gestructureerde gegevens direct uit de bron kan wel worden afgeleid dat patroon 2b de voorkeur heeft boven 2a. En binnen patroon 2b heeft het de voorkeur dat er één duidelijke bronhouder voor een bepaalde set gegevens is.
In het logisch informatiemodel kan hier deels rekening mee worden gehouden door gegevens waar mogelijk te groeperen naar groepen gegevens met één duidelijke bronhouder. Dit lukt uiteraard niet altijd. Er zijn in de keten verzamelingen gegevens of 'registers', waarbij meerdere identificerende ketenpartners de gegevens kunnen opvoeren of muteren. In dit geval is patroon 2a van toepassing.
Verdere belangrijkste richtinggevende principes uit de MIRA Thema's en architectuurprincipes, van toepassing zijn op dit patroon zijn:
Dit principe gaat over het vraaggericht informatie delen.
Centrale registers apart benoemen en positioneren. Duidelijk onderscheid maken tussen register- en eventuele bijkomende functionaliteit.
Sluit zoveel mogelijk aan bij overheidsbrede standaarden obv. api's, autorisatie en netwerken.
Binnen de vreemdelingenketen zijn enkele administraties van gegevens (in registers) die gezamenlijk beheerd worden door meerdere ketenpartners. Dit doen we alleen voor registers waar meerdere ketenpartners de taak hebben om dezelfde administratie te beheren en het daarbij niet praktisch uitvoerbaar dat ketenpartners dit individueel doen (MIRA principes 2B, 2A, 2C).
Voor dergelijke administraties zorgen we dat:
In termen van de MIDO Domeinarchitectuur gegevensuitwisseling, zijn de ketenpartners hier de Bronhouder van de gegevens in het centrale register en is de Beheerder van het centrale register de Aanbieder.
Bij het beheren van gezamenlijke registers is het essentieel dat er goede afspraken en protocollen zijn voor het beheer van de registers. Per register wordt hier door de bronhouders een protocol voor afgesproken (MIRA principe 2B), vergelijkbaar met het bestaande Protocol Identificatie en Labeling (PIL).
In de keten zijn de volgende registers centraal:
De Europese JBZ-systemen gedragen zich ook vergelijkbaar aan Centrale registers waarin gegevens opgevraagd, gezocht, of gemuteerd kunnen worden. Deze worden in de keten geabstraheerd en ontsloten door het Europaloket.
Bij de uitwerking van dit patroon wordt ook het registreren of muteren van gegevens in de centrale registers beschreven. Omdat de registrerende ketenpartner bronhouder van de gegevens blijft, is dit strikt genomen geen interactie tussen 2 ketenpartners en is dit daarom niet aanwezig in de bedrijfsarchitectuur.
Zoeken is een tweede verschil met sub-patroon 2b, het verkrijgen van informatie bij ketenpartners en andere bronnen. In de keten kan er op diverse manieren worden gezocht naar vreemdelingen. Dit zoeken gebeurt altijd op de centrale registers, meestal op basis van biografische of biometrische persoonsgegevens, maar er kan bijvoorbeeld ook op 'locatie' gezocht worden om een overzicht te krijgen van vreemdelingen per verblijfsobject. Indien er één of meerdere vreemdelingen is/zijn gevonden, dan kunnen de overige gegevens over deze vreemdelingen worden opgevraagd bij de desbetreffende ketenpartners op basis van het gevonden v-nummer.
Een bespreking van alle mogelijke zoekvarianten gaat voorbij aan de scope van deze informatiearchitectuur. Hier is belangrijk dat we enkel zoeken op persoonsgegevens en biometrie uit de centrale registers en dat eens het v-nummer bekend is, we niet meer spreken van zoeken, maar van opvragen.
In onderstaande figuur de architectuur voor het patroon opvragen, zoeken en muteren van gegevens in centrale registers.
De gegevens uit de centrale voorzieningen worden geregistreerd in de Gegevenscatalogus (1)[1]. Optioneel kan dit ook voor gegevens in Europese systemen (niet getekend).
De ketenpartners die gegevens aanleveren voor de "centrale registers" doen dit door vanuit hun systeem (“Bronsysteem gegevens”) middels de "registreer/muteer in centraal register API" van het betreffende register (2) of het Europaloket.
Het “Gegevens afnemend systeem” is in dit patroon het systeem van waaruit keten- of samenwerkingspartners een verzoek om informatie initiëren. Zij doen dit door vanuit hun systeem in de "Gegevenscatalogus API" te zoeken naar de gewenste gegevens en de gegevens van de bevragen registers API op te halen (3). Vervolgens gebruiken zij de "Opvragen gegevens API" (4) of "Zoek gegevens API" (7) van het betreffende register of het Europaloket (4c) om de gegevens op te halen. De verschillende componenten binnen de centrale voorzieningen geven na autorisatie antwoord op de informatie vraag; hierbij is geen afhankelijkheid van systemen van andere ketenpartners.
Bij zowel het muteren/registreren (2a), het opvragen van gegevens uit de centrale voorzieningen (4a, 6a), en het zoeken van gegevens in centrale voorzieningen (7a) vindt er een check plaats op het autorisatieregister of de betreffende ketenpartner gerechtigd is om dit te doen. Is dit het geval, dan kan de mutatie of registratie doorgaan (2b, 4b, 7b, 6b). Voor muteren en opvragen/zoeken van gegevens in Europa via het Europaloket (2c, 4c, 7c) is deze check in de toekomst wenselijk, maar vooralsnog optioneel.
Terugmeldingen kunnen gedaan worden via de "Terugmeld register API" van een register. Bij ieder register (maar ook breder: bij iedere API die gegevens aanbiedt in de keten) hoort verplicht een API om een melding over gerede twijfel over deze gegevens te kunnen ontvangen. De Terugmeldvoorziening zal afhankelijk van het register de melding doorsturen naar een van de bronsystemen (5) voor verdere behandeling. De terugmelder kan aangeven of hij al dan niet een terugkoppeling op de terugmelding wenst. Wanneer er afspraken rondom gezamenlijk bronhouderschap gemaakt zijn voor een bepaald register of gegevens, dan geldt terugmelden enkel voor niet-bronhoudende ketenpartners. De bronhouders kunnen dan rechtstreeks wijzigen.
Niet-ketenpartners kunnen onder voorwaarden gebruik maken van de "inkijkvoorziening" (6) maar niet van de hierboven beschreven API’s.
Terugmeldingen naar Europa en inkijk in Europese gegevens via de inkijkvoorziening is vooralsnog niet in beeld.
De meeste interacties zijn getekend via het 'ketenloket'. Dat moet in dit patroon geïnterpreteerd worden als een 'dunne' voorziening die de achterliggende API's ontsluit. Te vergelijken met een API-gateway.
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.
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Autorisatieregister | Component in centrale voorzieningen waarin ketenbreed is vastgelegd op basis van welke claim welke gegevens mogen worden opgevraagd. |
|
| Biometrieregister | Centraal register in de Migratieketen dat biometrie van vreemdelingen bevat | |
| Centrale registers | Logische en afgebakende sets informatie waarvoor meerdere bronhouders zijn en welke dus centraal in de keten ("als ketenvoorziening") gepositioneerd worden |
|
| Europaloket | Een centrale voorziening in de migratieketen die de brug vormt tussen de nationale systemen en de Europese (JBZ-)systemen voor migratie, opsporing en veiligheid. | |
| Gegevenscatalogus | Een centrale voorziening waarin de gegevens die aangeboden worden door centrale registers en individuele ketenpartners binnen de Migratieketen worden bijgehouden en gepubliceerd. |
|
| ID-documentenregister | Centraal register in de Migratieketen dat gegevens over buitenlandse identificerende persoonsdocumenten (ID-documenten, reisdocumenten,..) bevat | Hieronder vallen niet de nederlandse vreemdelingenkaarten. Deze zitten in het kaartregister. |
| Inkijkvoorziening | Portal waar externe partijen (selectief) toegang kunnen krijgen tot informatie uit centrale registers |
|
| Ketenloket | Een digitaal loket via de welke APIs in de keten ontsloten kunnen worden |
|
| Personenregister | Centraal register in de Migratieketen dat gegevens over vreemdelingen bevat | |
| 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 |
|
| Opvragen gegevens api | API waarmee gegevens uit de centrale gegisters opgevraagd kunnen worden |
|
| Registreer/muteer in centraal register API | API waarmee gegevens aan een centraal register toegevoegd of gewijzigd kunnen worden |
|
| Terugmeld register api | API waarmee melding van verdenking van onjuistheid / verzoek tot aanpassing gedaan kan worden. |
|
| Zoek gegevens api | Api om centrale registers te doorzoeken |
|
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Bronsysteem gegevens | Systeem van partij die gegevens aanbiedt | |
| Gegevens afnemend systeem | Systeem van partij die gegevens afneemt |
| Has target element | Omschrijving | Toelichting |
|---|---|---|
| Terugmeld api | API waarmee melding van verdenking van onjuistheid / verzoek tot aanpassing aangeleverd kan worden aan de bronhouder |
|
Op de bevraag register API’s implementeren we voor ketenpartners vraag gestuurde dataminimalisatie. Dat betekent dat de vrager expliciet moet specificeren welke informatie (attributen/elementen) nodig is en hierbij moet aangeven welke doelbindingsclaim bij deze vraag hoort. Als een ketenpartner geen lijst met gewenste gegevens opgeeft in de query dan wordt er niet alles geantwoord maar niets (privacy by design principe van minimalisatie).
Voor niet-ketenpartners (vrienden van de keten en andere externe partijen) worden alle gegevens standaard afgeschermd. Op basis van while-listing worden er attributen/elementen open gezet. Dit kan alleen als er een wettelijke grondslag is.
Bij zoeken wordt ook een minimalisatie patroon geïmplementeerd: Een zoek vraag (query) geeft een eenvoudige lijst waarop je daarna specifiek kan kijken (dus niet meteen van resultaten alle gegevens opsturen). Daarnaast is het aantal resultaten per zoekopdracht gemaximaliseerd.
Dataminimalisatie vindt bij ketenpartners plaats binnen de systemen door middel van autorisaties, break-the-glass mechanismes en logging. Dat is geen technisch onderdeel van de keten voorzieningen maar een afspraak.
Uiteraard worden bevragingen aan vraag- en aanbodkant gelogd, zodat er ketenbreed een audittrail te reconstrueren is.
Er komt steeds meer informatie-uitwisseling tussen NL en Europese registraties. 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 Europa ontstaan ook "centrale registers", waarbij telkens specifieke Europese afspraken en protocollen horen. Per register zal er bekeken moeten worden of het Europese register de taak van een centraal register overneemt of dat het aanvullend is en er een interface/vertaling/synchronisatie moet komen met bestaande centrale registers. Zie ook de twee openstaande vraagstukken over dit onderwerp.
Voor ontzorging van partijen in de Migratieketen wordt er voor bevragen en muteren van gegevens in Europese registers gebruik gemaakt van het Europaloket.
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. In de volgende fase moet e.e.a. verder worden uitgewerkt in een meer gedetailleerde en liefst integrale planning.
Voorziene stappen in 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 |
|---|---|---|---|
| Synchronisatie met Europese databases | Als er voor een van de centrale administraties een Europese equivalent komt, hoe gaan we dan om met synchronisatie hiervan? | In een volgende versie impact verder uitwerken | - |
| Koppelregisters apart of onderdeel van een ander register? | De BVV kent nu reeds een koppelregister, waarin meerdere koppelingen tussen V-nummers en externe nummers worden onderhouden. IS dit een afzondelrijk register, of zijn deze koppelingen te zien als reguliere attributen van een vreemdeling. | Volgende versie | - |
| Terugmelden | Komt er op een terugmelding altijd een terugkoppeling? Via patroon verzoeken of anders? En is er nog een generieke terugmeldvoorziening nodig, of enkel een terugmeldapi per bron/register? Hoe kan de behoefte aan ketenbreed inzicht in deze opzet gefaciliteerd worden? | In een volgende versie adresseren | - |
| Uitwisseling met andere ketens | De uitwisseling met andere ketens verder uitwerken. Nu enkel benoemd irt. koppelregister en in hoofdstuk informatielandschap over opnemen gegevens van buiten de keten (bv. BRP). Hoe positioneren we bv. zoeken vanuit strafrecht in de Migratieketen of andersom de positionering van VRIS. | In een volgende versie adresseren | - |
| Uitwerking bronhouderschap irt PIL | bronhouderschap van gegevens in de centrale registers blijft een discussiepunt. Bronhouder per gegeven of per record? | Volgende versie | Kijken hoe het in het PIL staat beschreven en obv daarvan aanscherpen of detailleren. |
--
Deze pagina is voor het laatst bewerkt op 10 mrt 2025 om 15:25.