In de bedrijfsarchitectuur is beschreven dat de Migratieketen een keten is waarin de ketenpartners elk verantwoordelijk zijn voor het uitvoeren van de eigen bedrijfsprocessen. Om de afhankelijkheden tussen deze bedrijfsprocessen op te vangen, moet er informatie worden uitgewisseld.
Bij het uitwisselen van informatie in de keten is het van belang dat er een goed gedeeld beeld is van de betekenis en samenhang van de informatie die binnen de keten wordt uitgewisseld. Dit moet worden beschreven in een ketenbreed informatiemodel. Binnen de Migratieketen wordt het Metamodel voor Informatiemodellering (MIM) gehanteerd als kader voor het opstellen van informatiemodellen. Het MIM bevat duidelijke afspraken over het vastleggen van gegevensspecificaties en biedt tegelijkertijd ruimte aan de verschillende niveaus van modellering.
Het MIM is opgenomen op de lijst met aanbevolen standaarden van het Forum Standaardisatie. Belangrijk element uit het MIM zijn de verschillende 'lagen' of 'beschouwingsniveaus' waarop informatie binnen een bepaald domein beschreven kan worden. In de MIRA bedrijfsarchitectuur is al een pagina opgenomen over hoe er wordt gekeken naar de in het MIM gedefinieerde soorten informatiemodellen.
In de keten bestaat een Gegevenswoordenboek Migratieketen (GMK). Deze geeft invulling aan laag 1, de semantische laag van het MIM. De MIRA Bedrijfsarchitectuur beval al een bedrijfsobjectenmodel. Deze geeft een overzicht van de typen bedrijfsobjecten in de keten en hun onderlinge samenhang (laag 2 van het MIM).
In de context van de MIRA informatiearchitectuur wordt er gekeken naar het niveau van het logisch informatiemodel. Dit is laag 3 in het MIM. Een logisch informatiemodel is volgens het MIM een 'ontwerpmodel', dat het 'gegevensgebruik specificeert'.
Toegepast op de keten is dit een model waarmee beschreven wordt welke gegevens uitgewisseld worden en hoe deze samenhangen, zonder daarbij ook al keuzes te maken voor de technische oplossing. Het vormt de basis voor het informatielandschap van de keten.
Een logisch model bevat volgens het MIM [1]:
Nu is dit voor meerdere interpretatie vatbaar, maar duidelijk is dat het, itt. het bedrijfsobjectenmodel niet bedoeld is als 'bespreekmodel', om het domein te expliciteren, maar meer om de daadwerkelijke uitwisseling (op logisch niveau) te specificeren. Hiertoe worden uit te wisselen gegevens gedefinieerd en getypeerd, geclusterd en wordt de samenhang tussen de gegevens beschreven dmv. relaties. Voor de keten komt er nog bij dat dit model de gegevens over de verschillende bronnen heen uniformeert in een gedeeld model, zodat er tussen de ketenpartners geen misterstand of discussie kan bestaan over betekenis of samenhang van gegevens.
Uit de MIRA architectuurprincipes en bedrijfsarchitectuur kan behoorlijk wat richting over het structureren van het informatielandschap in de keten worden afgeleid.
Allereerst is er in de MIRA bedrijfsarchitectuur een bedrijfsobjectenmodel opgenomen. Deze geeft een overzicht van de typen bedrijfsobjecten in de keten en hun onderlinge samenhang vanuit business-perspectief. Hoewel het hiermee een ander doel dient dan het logisch informatiemodel, kan de samenhang zoals in het BOM geschetst (en vanuit de business herkend) wordt wel als startpunt worden genomen voor het opstellen van een logisch informatiemodel. Het is immers wenselijk dat gegevensgroepen in het logisch model, en later de op basis daarvan gerealiseerde API's of services gebieden bestrijken die door de business als zodanig worden herkend.
De MIRA Architectuurprincipes en de daarbij beschreven implicaties geven ook veel richting aan de inhoud en de structuur van het informatielandschap:
Op basis van bovenstaande, kunnen we enkele inrichtingsprincipes definiëren voor het informatielandschap in de keten. Deze zullen deels ook uitwerking hebben op het logisch informatiemodel.
Persoonsgegevens, i.e. de basis biografische en biometrische gegevens over de vreemdeling definiëren we op uniforme wijze voor de hele keten. Deze kunnen door meerdere bronhouders in de keten kunnen worden geregistreerd en bijgewerkt. Daarom worden ze in de keten in de centrale registers bijgehouden (zie verderop de uitwerking van patroon 2A).
De ketenpartner die het gegeven geregistreerd/laatst gewijzigd heeft blijft wel bronhouder. Deze persoonsgegevens zijn de uitzondering, omdat ze vanuit meerdere processen door meerdere ketenpartners gewijzigd kunnen worden. Wanneer de Politie de naam en de vingerafdrukken heeft geregistreerd en de IND later de geboortedatum en nationaliteit aanpast, dan zijn er meerdere bronhouders over de basisgegevens van één vreemdeling. Dit is in principe onwenselijk, maar zoals de Migratieketen op dit moment is ingericht onvermijdelijk. Daarom registreren we deze gegevens in een centraal register en hebben we hier goede afspraken over gemaakt in het PIL.
Deze set persoonsgegevens wordt beperkt tot de kern. Aangehaakte gegevens worden zoveel mogelijk bij de registrerende ketenpartner (=bronhouder) gepositioneerd.
In de principes (1b en 2A) wordt voor het beter informeren van de vreemdeling en elkaar, gesteld dat er een generieke manier moet komen om het bestaan, de status, en de fasering van alle soorten processen in de keten beschikbaar te stellen. Dit kan heel generiek door per proces heel generiek aan te geven van welk type deze is; welke ketenpartner de proceseigenaar is; wanneer deze gestart is; welke status het proces heeft en (indien van toepassing) wie de behandelend ambtenaar is. Ook wordt er een relatie gelegd naar de vreemdeling waarop het proces betrekking heeft. Dit laatste is bij veel processen vanzelfsprekend, maar zal in handhavingsprocessen, of processen die vooral diensten aan de bredere samenleving leveren, wellicht minder makkelijk zijn. Procesgegevens worden m.a.w. erg dun en generiek over alle bedrijfsprocessen in de keten heen gemodelleerd.
Enkel gegevens die generiek over alle processen te definiëren zijn zuivere procesgegevens. Gegevens die als basis dienen voor een proces, of uit een bepaald proces komen, kunnen wel worden gerelateerd aan een bepaald proces. Zo kan bijvoorbeeld een besluit, maatregel of aanvraag worden gerelateerd aan het proces waar dit een resultaat of input voor is.
Voor het overzicht en efficiëntie van de informatie-uitwisseling in de keten, is het belangrijk om gegevens die bij elkaar horen en eenzelfde bronhouder kennen zo veel mogelijk te clusteren. Alle gegevens in zo'n cluster kunnen dan via het zelfde patroon worden opgevraagd (zie verder onder verantwoordelijkheden). Relaties naar andere elementen worden duidelijk beschreven. Dit kan al in het logisch informatiemodel gedaan worden.
De Migratieketen staat niet op zichzelf. In toenemende mate worden er in de Migratieketen gegevens gebruikt die hun oorsprong elders vinden, zoals Europese gegevens uit de JBZ-systemen of gegevens uit aanpalende ketens of het bredere Federatief Datastelsel (FDS). Deze gegevens moeten, mits ze van belang zijn op ketenniveau, in het logisch model worden opgenomen, zodat er in de keten een gedeeld beeld is over de samenhang met de ketengegevens.
Het is echter niet de bedoeling om kopieën van deze gegevens op te nemen in onze registraties. Waar mogelijk wordt er naar de bron gerefereerd.
Idealiter heeft één gegeven één duidelijke eigenaar/bronhouder. Zie MIRA principe 5B. Dit zal niet voor alle gegevens lukken of wenselijk zijn. De tabel hieronder geeft een overzicht van groepen gegevens naar verantwoordelijkheid. Er zijn gegevens die heel duidelijk bij één ketenpartner als bronhouder te verkrijgen zijn, maar ook gegevens die bij meerdere ketenpartners kunnen ontstaan en dus meerdere bronhouders kunnen hebben.
| Bronhouder gegeven | Afnemer gegeven | Voorbeeld | Soort gegeven | Patroon |
|---|---|---|---|---|
| 1 bronhouder | geen | kamerindeling bij COA | geen ketengegeven | - |
| 1 bronhouder | 1 of meerdere afnemers | resultaat fit-to-fly | decentraal | patroon 2B |
| meerdere bronhouders | meerdere afnemers | ziektebeeld | decentraal, gestandaardiseerd | patroon 2B |
| meerdere bronhouders per record | meerdere afnemers | persoonsgegevens vreemdeling | centraal | patroon 2A |
Van persoonsgegevens hebben we eerder al gezien dat ze in een centraal register worden bijgehouden.
De tweede categorie gegevens kan meerdere bronhouders hebben, maar heeft voor elke instantie wel steeds één bronhouder. Meerdere ketenpartners kunnen een ziektebeeld waarnemen en registreren. Maar voor elke registratie hiervan is er maar één bronhouder. Als er meerdere waarnemingen door verschillende ketenpartners zijn, dan zijn dit verschillende registraties. Deze gegevens worden bij de bron opgehaald (de registrerende ketenpartner), maar het verdient wel aanbeveling om de definities hiervan te standaardiseren in de keten. Maar niet kost wat kost. Waarnemingen vinden altijd plaats binnen een bepaalde context, wat maakt dat het wellicht om verschillende gegevens kan gaan. Ook is de ene aanvraag de andere niet, bijvoorbeeld een aanvraag asiel versus een aanvraag reisautorisatie.
De derde en laatste categorie gegevens is het makkelijkst. De gegevens in deze categorie hebben altijd maar één bronhouder. Deze gegevens halen we bij de ketenpartners, direct uit de bron. Dit patroon is uitgewerkt in patroon 2B. Het is aan beginsel aan de ketenpartners zelf om deze gegevens te definiëren, te groeperen in een register en deze via een API te ontsluiten en aan te bieden (dienst) naar de keten. Maar we nemen ze wel op in het logisch model (ze worden immers uitgewisseld), dus dienen wel zo gedefinieerd te worden dat ze hier goed in passen.
Een ordeningsprincipe dat we in de informatiearchitectuur en de verdere uitwerking hanteren is dat van 'registers'. Een register slaat op de implementatie van een cluster samenhangende gegevens over één of meerdere gerelateerde entiteiten. Op registerniveau kan zo bronhouderschap en gegevenskwaliteit bepaald worden en kunnen samenhangende API's gedefinieerd worden.
Naast de 3 centrale registers zie de uitwerking van patroon 2A, kunnen er nog enkele registers gedefinieerd worden bij ketenpartners. Een eerste poging is gedaan op basis van het bedrijfsobjectenmodel. Wanneer er in de zijbalk (bij het bedrijfsobjectenmodel) gekozen wordt voor 'register' zijn van enkele gegevens de 'registers' aangegeven, waaronder de bekende centrale (BVV) registers uit de keten, maar ook de bekende Europese JBZ-systemen (SIS, VIS, EES, ..).
Een snelle blik met bovenstaande in gedachte, herkent o.a. een cluster met procesgegevens (bron: alle ketenpartners), een cluster met gegevens over verblijfsrecht (hoofdzakelijk IND?), een cluster met gegevens over ingezette rechtsmiddelen en uitspraken en een cluster met gegevens over aanvragen (meerdere ketenpartners) en een cluster met gegevens over maatregelen (meerdere ketenpartners).
Maar de ondergrond hier is het bedrijfsobjectenmodel, dat is meer bedoeld om een domein te analyseren, minder gericht op het ontwerpen. Dus dit moet in het logisch informatiemodel, dat expliciet de gegevensuitwisseling in de keten beschrijft, beter naar voren kunnen komen.
--
Deze pagina is voor het laatst bewerkt op 10 mrt 2025 om 15:25.