De eerste stappen op weg naar implementatie van MDTO bij gemeente Heusden

Inleiding

De gemeente Heusden wilde een werkwijze ontwikkelen voor het meten van kwantiteit en kwaliteit van metagegevens in het zaaksysteem. Hierbij wilden we ook gelijk rekening houden met de MDTO metagegevens (aangezien dit de nieuwe norm is), zodat we weten welke metagegevens wel of niet verplicht zijn en zodat we als team DIV uniform advies kunnen geven aan de gebruikers. We hebben daarom een metagegevensschema op basis van MDTO opgesteld, wat toepasbaar is voor alle applicaties binnen de organisatie. Dit is de basis voor het maken van een mapping, een vertaling van de MDTO metagegevens uit het schema naar de velden die de gebruikers invullen in het zaaksysteem of andere applicaties die binnen de gemeente gebruikt worden.

Toepassingen; meten van kwantiteit en kwaliteit + programma van eisen bij aanschaf nieuwe applicatie

Naast de eerste toepassing voor de gemeente Heusden van de MDTO bij het meten van kwantiteit en kwaliteit van metagegevens en advies geven aan de gebruikers/behandelaars, is de tweede toepassing inmiddels ook in praktijk gebracht: het opnemen van de MDTO metagegevens in het programma van eisen bij de aanschaf van een nieuwe zorgapplicatie. Zodat we op voorhand al weten of de applicatie kan voldoen aan deze eisen, en zo niet, dan kan er gekeken worden of de leverancier dit nog kan aanpassen of dan weten we in elk geval waar we risico lopen. We hebben een aantal specifieke MDTO metagegevens opgenomen in het programma van eisen, bijvoorbeeld dat alle documenten een uniek, persistent identificatie kenmerk hebben en dat bij alle documenten/zaken een wettelijke bewaartermijn wordt geregistreerd. Daarnaast hebben we ook in het algemeen benoemd dat de zorgapplicatie aan de MDTO moet voldoen en het MDTO metagegevensschema als bijlage toegevoegd.

Proces (hoe hebben we dit aangepakt)

Het moeilijkste deel was om de MDTO om te zetten naar een metagegevensschema dat praktisch bruikbaar is voor de gemeente. Er waren nog geen voorbeelden beschikbaar van andere gemeenten en Heusden had geen vastgesteld metagegevensschema op basis van TMLO.

1. We zijn begonnen met het opbouwen van het metagegevensschema vanaf de informatie op de website van het Nationaal Archief.

2. We hebben een Excel bestand gemaakt met de verschillende attributen per klasse en deze vervolgens aangevuld met de attributen per gegevensgroep. We hebben daarbij de te metadateren informatie verdeeld in drie sets, op basis van de bewaartermijn van de informatie. De verplichte metadata verschilt per set. Zo hebben we voor alle soorten informatie een passende set metagegevens. En ben je als organisatie niet onnodig veel metagegevens aan het registreren/controleren.

a. Zo zijn de MDTO metagegevens ‘verplicht’ of ‘verplicht indien bekend’ voor te bewaren informatie. Deze set metagegevens noemen we de uitgebreide set MDTO metagegevens.

b. Voor te vernietigen informatie hebben we twee sets met metagegevens samengesteld, o.a. op basis van wat er in ons besluit informatiebeheer aan minimum metagegevens wordt genoemd. De ene set metagegevens, de beperkte set, is voor informatie die binnen maximaal 7 jaar wordt vernietigd.

c. En de andere set, de standaard set, is voor informatie die na meer dan 7 jaar wordt vernietigd.

3. Vervolgens hebben we ook in Excel voor de metagegevens uit het schema een mapping gemaakt met de velden in ons zaaksysteem. Hierbij hebben we alleen gekeken naar de handmatig in te vullen metagegevens omdat bij de automatisch ingevulde metagegevens geen invloed van de gebruiker is.

Struikelblokken

Er waren een aantal lastige punten waar we tegen aan liepen bij het maken van het metagegevensschema.

1. In de eerste plaats waren dat de keuzes die je als organisatie zelf moet maken bij het toepassen van MDTO.

a. Zo moet je zelf bepalen wanneer iets een verzameling van informatieobjecten is en wanneer een aggregatie.

Bijvoorbeeld: is een e-mail met bijlagen een aggregatie (verzameling van onderdelen) of een ongedeeld informatieobject?

b. Ook gelden er verschillende niveaus van verplichtingen, zoals verplicht en verplicht indien bekend. Verplicht indien bekend betekent dat als de gegevens bekend zijn in de organisatie dat ze worden ingevuld. Tenzij het vastleggen van de gegevens niet in verhouding staat tot de tijd/kosten die er tegenover staan. Hier is dus ook ruimte voor eigen invulling. Deze ruimte geeft natuurlijk aan de ene kant flexibiliteit aan de organisatie om het naar eigen wens in te vullen, aan de andere kant is het niet perse duidelijk wat nu de beste keuze is.

2. Verder was het niet eenvoudig voorbeelden en modellen van metagegevensschema’s te vinden. Er is een model MDTO metagegevensschema beschikbaar via de website van kia pleio, maar je moet dan net weten waar dit te vinden is. En ook was het lastig om het schema praktisch en overzichtelijk te houden, aangezien er veel informatie in wordt opgenomen.

Vervolgstappen

De mapping van het metagegevensschema naar het zaaksysteem zoals we die nu voor de handmatig ingevulde metagegevens hebben gemaakt, willen we uitbreiden naar alle metagegevens in het zaaksysteem, dus ook de automatisch ingevulde gegevens. We kunnen dan ook kijken of er nog metagegevens zijn die geautomatiseerd kunnen worden. Daarna willen we kijken of we ook een mapping per applicatie kunnen maken voor de overige applicaties waarin informatie is opgeslagen. Verder wordt het metagegevensschema onderdeel van het kwaliteitssysteem (als beheerinstrument) en daarmee willen we borgen dat het actueel en levend blijft.

We zijn als gemeente Heusden heel erg benieuwd of jullie iets hebben aan onze praktijkervaring en horen graag hoe jullie dit hebben aangepakt. Ook zijn we op zoek naar verdere tips voor onze vervolgstappen. Alle reacties op deze blog zijn welkom!