Cursus samenwerkingen
Hoi, Ik ben op zoek naar een cursus/opleiding over de juridische kant van informatie-en archiefbeheer ...
Uniek identificatiekenmerk aan informatieobjecten
- apr 2024
- Wouter Verdaas
- ·
- Aangepast jun 2024
- 6
- 727
Samenvatting
Ik heb een vraag over unieke identificatiekenmerken aan informatieobjecten.
De nieuwe DUTO-eis registreren geeft het volgende aan: Het moet mogelijk zijn om op elk aggregatieniveau een uniek identificatiekenmerk toe te wijzen aan informatieobjecten. Het kenmerk is uniek binnen de bijbehorende bron.
Zoals ik deze eis interpreteer is dat (in theorie) iedere applicatie dezelfde nummering kan gebruiken. M.a.w. het kenmerk i.c.m. de bron maakt het uniek. Maar kun je dan spreken van een uniek kenmerk?
Intern zou dit nog wel kunnen werken. Maar de burger/ondernemer heeft alleen maar een nummer en beschikt niet over informatie over de bron. Hoe weet je dan als (KCC)medewerker waar je moet zoeken over de betreffende vraag van de klant?
Ik zou liever zien dat iedere applicatie een eigen unieke opbouw in kenmerken heeft. Dan is er m.i. pas echt sprake van een uniek kenmerk. Maar ik snap dat we weinig tot geen invloed op een leverancier hebben wat betreft dit onderwerp.
Ik heb zelf gemerkt dat verschillende (legacy) applicaties dezelfde nummering gebruiken/gebruikt hebben. Daar kwamen we pas op een later tijdstip achter bij het analyseren van ons centraal DMS waar verschillende applicaties aan gekoppeld zijn. We kwamen er achter dat verschillende dossiers hetzelfde dossierkenmerk hadden. Later zagen we dat er een andere bron aan gekoppeld zat. Het was erg handig geweest als ik van tevoren een overzicht had gehad van welke applicaties welke kenmerken (ranges) gebruiken/gebruikten.
Ik ben wel nieuwsgierig hoe andere organisaties hier mee omgaan?
Zijn er organisaties die een register 'kenmerken' hebben gebouwd waarin wordt vastgelegd welke nummering door welke applicatie wordt gebruikt? Of dat een bepaalde applicatie niet begint bij nr. 1 van de nummering, maar bv. bij 150000 als er al een andere applicatie dezelfde nummering gebruikt? Of heb je een andere gedachte/werkwijze?
Ik ben benieuwd naar jullie inzichten.
Verken
KPI vraag 8.4 Afwijzing raadpleging of gebruik
Samenvatting: Wat is het verschil tussen de kpi-vragen 8.4b en 8.4c?
Ervaring gevraagd: archivering IFC-bestanden
Samenvatting: Vanuit de bouwsector is een sterke lobby gaande om bij de invoering van de Omgevingswet de bouwvergunningen te verstrekken op basis van ingediende IFC-modellen. IFC is een internationale open standaard is.
Reacties
Hé Wouter,
In de praktijk ben ik er (nog) niet mee bekend. Wel een goed vraagstuk! Wellicht is het volgende een optie zonder mezelf erin te hebben verdiept.
Elk informatiesysteem heeft bij ons een applicatienummer. Dat is vastgelegd in het DSP (I-navigator). Een combinatie van het nummer uit de applicatie met voorafgaand het applicatienummer zorgt m.i. altijd voor een unieke nummering. En dan kunnen we meteen tot in de lengte van dagen achterhalen met welk informatiesysteem de informatie is gecreëerd of in is opgeslagen. Zou dat een oplossing kunnen zijn?
@stefanheirbaut1
Ha Stefan,
klinkt als een oplossing wat zou kunnen werken. Maar hoe krijg je het applicatienummer bij een zaak of document toegevoegd? Exporteer je dat dan uit de i-navigator naar een apart veld in je zaaksysteem? Doe je dat zichtbaar of ergens onder water? Communiceer je dat applicatienummer dan ook naar de burger/ondernemer toe? Of wordt het 1 nummer met de opbouw applicatienummer_zaaknummer?
@stefanheirbaut1
Hey Wouter,
Daar is vast een technische oplossing voor. Volgens mij moet bijvoorbeeld een preingesttool (RMTool?) in bulk een aanpassing kunnen doen. Maar dit is op basis van een aanname en zeker niet op feitelijke kennis. Wellicht heb ik iets teveel vertrouwen in de techniek :)
Dag Wouter,
Het is zinvol, noch relevant om een applicatie als bron aan te merken; sterker nog, het druist in tegen de Common Ground-gedachte om data van applicatie te scheiden. Een applicatie is daarom per definitie niet de bron van het informatieobject (ondanks dat een applicatie het object kan hebben gecreëerd) en zou dus ook niet in de identificatie moeten worden opgenomen.
Een veel logischere identificatie zou bijv. het gemeentenummer, OIN of RSIN zijn. Daarmee is een informatieobject direct te relateren aan het BG dat de juridische en technische validatie van het object heeft verzorgd. De identificatie van de data staat daarmee los van de applicatie. De criteria voor een goede identificatie zou m.i. in het MDTO moeten zijn vastgelegd. Ik zal eens bij de MDTO-expert in onze organisatie nagaan of dat ook het geval is.
IMRO had ooit best een goed identificatiemethode trouwens.
Grt,
Bastiaan
@bastiaanligt
Hoi Bastiaan,
Ik ben het met je eerste alinea volledig eens. In de common ground wereld is er mijn inziens maar sprake van 1 bron en dat is de datalaag van je organisatie. Maar je wilt nog steeds aan ieder object een uniek kenmerk koppelen.
Het gemeentenummer o.i.d. alleen is m.i. niet voldoende, dat geef je aan heel je archief mee, bij bv. overdracht naar een archiefinstelling. In het TMLO was wel een mogelijkheid om het gemeentenummer o.i.d. op het aggregatieniveau 'Archief' mee te nemen. In het MDTO weet ik het zo niet uit mijn hoofd.
Een losse component die unieke identificatienummers uitgeeft lijkt me dan veel logischer.
Een centraal DMS als documentenregister zou m.i. een goede optie zijn om op dat aggregatieniveau unieke kenmerken in te regelen. Alle applicaties zouden dan via API's de documenten moeten wegschrijven in het DMS en het betreffende documentnummer en document moet bevragen uit het DMS i.p.v. eigen documentnummers uitgeven.
Een zaakregistratiecomponent o.i.d. zou dat wellicht op zaakniveau kunnen doen, maar niet alle processen wordt zaakgewijs behandeld. Wellicht zou je die component kunnen uitbreiden voor alle processen?
Maar ik weet niet of deze gedachtegang technisch mogelijk is. ;-)
Gr. Wouter
@stefanheirbaut1
Ik heb vroeger geleerd dat een sleutel met betekenis géén best practise is. Een nummer waaraan je de applicatie kunt herkennen is volgens mij de verkeerde oplossing voor dit probleem. Los van de scheiding tussen applicatie en data, zijn applicaties ook tijdelijk en de data soms 'eeuwig'. Als ik het plat sla heb je nodig dat: a) elke applicatie die aan de wieg staat van een informatie-object daar een GUID aan kan toekennen, b) je beschikt over een (door services te bevragen) index waarin per informatie-object wordt bijgehouden waar dat object zich bevindt (cq het pad daar naar toe).