Met de komst van de Woo in 2022 volgde al snel de vraag hoe we actieve openbaarmaking met IT kunnen ondersteunen. Destijds dachten we nog dat openbare documenten inclusief metadata bij het landelijke PLOOI aangeboden moesten worden. In de gemeente Rotterdam worden documenten in diverse systemen opgeslagen. We voorzagen dus dat er meerdere koppelingen met PLOOI gewenst zouden worden. Zo ontstond het idee om een intern centraal knooppunt te realiseren dat alle benodigde integraties bijeen zou brengen, het Openbare Publicatie Component (OPC). Dit knooppunt zou vanuit diverse bronsystemen openbaar te maken documenten kunnen ophalen (of aangeleverd krijgen), zou alle benodigde handelingen kunnen ondersteunen en zou uiteindelijk openbare documenten kunnen publiceren op PLOOI en op een eigen website1. Om de haalbaarheid van zo’n OPC te toetsen hield de gemeente rond de jaarwisseling een openbare marktconsultatie. Hieruit kwam naar voren dat leveranciers op onderdelen al mooie oplossingen op de plank hadden liggen, maar dat zij andere onderdelen nog in ontwikkeling hadden of hier slechts ideeën over hadden. Halverwege de consultatie kwam bovendien het nieuws naar buiten dat de ontwikkeling van PLOOI een andere koers zou inslaan. De gemeente moest zelf de openbare documenten hosten en zelf ontsluiten. Het werd duidelijk dat er niet gedacht moest worden in een component, maar aan een keten. De spreekwoordelijke olifant moest in stukjes gesneden worden.

Terug naar de tekentafel

Uit de marktconsultatie kwam duidelijk naar voren dat leveranciers de Common Ground-principes hadden omarmd. Aangeboden oplossingen maakten een heldere knip tussen de opslag en ontsluiting van data enerzijds (laag 1 en 2) en de ondersteuning van processen en gebruikers anderzijds (laag 4 en 5). Daarmee kon de olifant horizontaal doorgesneden worden. Daarnaast was er in de marktconsultatie een onderscheid zichtbaar tussen leveranciers die zich focusten op het interne deel van de beoogde oplossing, versus leveranciers die zich focusten op het externe deel. Met het interne deel worden hier de data en functionaliteiten bedoeld die medewerkers nodig hebben om openbaarmakingen voor te bereiden en uit te voeren. Met het externe deel worden hier de data en functionaliteiten bedoeld die burgers nodig hebben om openbare documenten te vinden en te raadplegen. Hiermee kon de olifant verticaal doorgesneden worden. Met deze twee sneden is wat voorheen het OPC werd genoemd, opgedeeld in vier kwadranten. Momenteel wordt de doel-architectuur, waarin deze vier kwadranten centraal staan, in verder detail uitgewerkt. Hierna lichten we alvast een tipje van de sluier op. De ambitie is om een generieke werkwijze met bijbehorende IT-functionaliteit te realiseren. In de gemeente Rotterdam wordt echter met diverse systemen voor de opslag van documenten gewerkt, die niet op uniforme en gestandaardiseerde wijze zijn ingericht. Om toch een generiek publicatieproces te kunnen realiseren, dienen bronsystemen openbaar te maken documenten aan te bieden aan een gestandaardiseerde opslag-omgeving. OpenZaak lijkt daarbij voor de hand te liggen. In OpenZaak wordt een nieuwe zaak aangemaakt, waarin de openbaar te maken documenten worden opgeslagen. Dit geldt ook wanneer OpenZaak zelf het bronsysteem is. Een “bron-zaak” kent immers een andere afhandeltermijn (bijvoorbeeld 6 weken) dan de actieve openbaarmaking (doorgaans 2 weken) en kan al afgesloten zijn voordat de openbaarmaking van het laatste stuk al is afgerond. Ook kan gedurende de looptijd van de “bron-zaak” op meerdere momenten een openbaarmaking gestart worden.

Interne functionaliteit

Boven op de zaak met de openbaar te maken documenten kan een workflow ingericht worden. Deze workflow koppelt onder meer met een laktool, zodat privacygevoelige en anderszins vertrouwelijke gegevens afgeschermd kunnen worden. Mogelijk dient intern vervolgens het een en ander afgestemd te worden en/of moeten er akkoorden opgehaald worden. Ook is het wenselijk om voorafgaand aan de publicatie de documenten te versleutelen met een elektronisch zegel, zodat een burger van een online rondzwervend document de authenticiteit en integriteit kan verifiëren. De publiceerbare documenten worden naast de originele documenten in de zaak opgeslagen, inclusief een logging van het doorlopen publicatieproces. Zo kan achteraf gereconstrueerd en verantwoord worden hoe de publicatie van een document tot stand is gekomen. Aan het eind van de publicatie-workflow dienen de publiceerbare documenten opgeslagen te worden in een publiek toegankelijke omgeving. De discussie loopt nog of dit OpenZaak zelf kan zijn of een afzonderlijke omgeving. Afwegingen hierin moeten vooral gezocht worden in de hoek van informatiebeveiliging. Landelijk zien we dat medeoverheden een diversiteit aan oplossingen hanteren voor de publiek toegankelijke opslag en ontsluiting van documenten, waaronder eDepots2, OpenPub3 en Open Data platforms. De openbare documenten zullen door burgers online gezocht, gevonden en geraadpleegd moeten kunnen worden. Hiervoor moet erboven op de externe dataopslag een gebruiksvriendelijke en digitaal toegankelijke website gerealiseerd worden. Een belangrijk onderdeel hiervan is de zoekmachine, die de openbare documenten inclusief metadata indexeert en door middel van full-tekst search en filtering doorzoekbaar maakt. Deze website zal ook aangemeld moeten worden bij PLOOI. PLOOI omvat immers zelf ook een zoekmachine. Deze zal echter niet direct op de externe dataopslag inprikken, maar zal de website “scrapen”. De eisen waaraan een website moet voldoen om dit proces te optimaliseren, moeten nog bekendgemaakt worden. Op lange termijn kan de website eventueel uitgebreid worden met extra functionaliteiten, die de burger verder kunnen helpen. Denk bijvoorbeeld aan een abonneer-functie en/of het bijhouden van favorieten.

Veel ambitie, weinig geduld

Op hoofdlijnen is het helder waar we met de vier kwadranten, zoals hiervoor beschreven, heen willen. Er liggen echter nog een aantal vragen op tafel waar we het antwoord nog op zoeken. Welke metadata hebben we nodig voor de vindbaarheid van openbare documenten? Welke bewaartermijnen hanteren we voor de openbare documenten? Hoe ondersteunen we zienswijzen, bezwaarschriften, voorlopige voorzieningen en beroepschriften? Wat vormt de trigger in de bronsystemen voor het starten van een openbaarmaking? Wanneer gebruiken we deze generieke voorzieningen en wanneer wijken we af? Er is veel tijd voor nodig om de bovenstaande vier kwadranten uit te werken, te realiseren en te implementeren. Ze bestaan uit verschillende applicatie-componenten, die deels nog ontwikkeld moeten worden en die allemaal onderling gekoppeld moeten worden. Dat duurt jaren. Ondertussen is er – mede door media-aandacht en de intern reeds lopende bewustwordingscampagne – al veel vraag naar concrete (IT-)oplossingen. Op zo’n kort mogelijke termijn moeten we dus datgene realiseren wat minimaal nodig is om de eerste documenten actief openbaar te maken. Hiervoor worden met name alle koppelingen uitgesteld en dienen medewerkers vooralsnog documenten te downloaden uit het ene systeem en te uploaden naar het andere systeem. De interne kwadranten worden beperkt tot de al aanwezige laktool. De grote uitdagingen die dan nog resteren is om op korte termijn de externe kwadranten te realiseren en medewerkers goed te trainen. Voor kleine aantallen documenten is deze werkwijze te doen, maar naarmate het volume stijgt zal de behoefte aan koppelingen, betere vastlegging en andere toeters en bellen toenemen.