Binnen PRLG zijn we bezig met een mapping te maken van het RGBZ (StUF3) op het GFO Zaken (StUF2). Daarbij komt het volgende aan het licht.
In onze huidige Midoffice oplossing m.b.t. Zaakgericht werken speelt het element typeCode binnen Zaak een belangrijke rol. Op basis van typeCode (dat gelijk is aan de code uit de Zaaktypencatalogus) wordt geïdentificeerd wat voor zaak het betreft. De afhandeling van de zaak is daarvan afhankelijk.
Nu blijkt dat in het RGBZ er geen (code) element bestaat voor een unieke codering van een zaaktype. In het RGBZ wordt beschreven dat de unieke identificatie van een zaaktype d.m.v. het element omschrijving Generiek tot stand gebracht kan worden. De keuze van een omschrijvingveld voor het uniek identificeren van zaaktypen lijkt ons echter niet werkbaar. Afhandeling definiëren o.b.v. omschrijvingen is namelijk erg foutgevoelig, beter is het hiervoor dus coderingen te blijven gebruiken. Daarnaast is binnen de StUF expertgroep in het verleden een best practice gedefinieerd die elementen met veel mogelijke waarden die lange omschrijvingen bevatten en die onderhevig zijn aan wijzigingen, van een codering voorziet.
De vraag is of er een gegronde reden is waarom niet is gekozen voor een element vergelijkbaar met typeCode.
Vanuit PRLG bij deze in ieder geval het verzoek het element code (alfanumeriek 10) toe te voegen.
Bijgevoegd de definities uit het GFO Zaken en het RGBZ.
Er is zowel binnen het RSGB en RGBZ bewust gekozen om zo weinig mogelijk met codetabellen te werken en alleen de omschrijving op te nemen. We hebben het hier immers over een informatiemodel voor het uitwisselen van gegevens en niet over een datamodel van een of andere applicatie. Een datamodel richt zich onder andere op correcte invoer van gegevens in een applicatie. Overigens zijn in het RSGB de coderingen zoals ze voorkomen in de basisregistraties wel overgenomen (het RSGB volgt immers de basisaministraties). In een enkel geval is toch een codering toegevoegd om redene zoals vermeld is in deze post ("best practise" expertgroep STUF)
Uitgangspunt vanuit informatiemodellering is zo weinig mogelijk gebruik te maken van coderingen.
Voor zaaktype-omschrijving generiek kan ik me voorstellen om wel gebruik te maken van de "best practise" van de expertgroep STUF. Ook omdat in de ZTC ook al sprake is van een codering voor zaaktype en we deze kunnen overnemen voor het RGBZ.
Mijn vraag is hoe anderen er tegenover staan om voor zaatype-omschrijving generiek een zaaktypecode te hanteren?
Ik kan me wel vinden in het gemaakte onderscheid tussen informatiemodel en datamodel, maar aangezien het vooral bedoeld is voor uitwisseling/uniformiteit, prefereer ik eenduidigheid. Ik ben nu even niet meer actief in de wereld die overheid heet, maar ik dacht dat er voor Ja/Nee of Man/Vrouw/Onbekend ook coderingen gebruikt worden als 1/0, J/N, M/V/O.
Ik tref het RFC hierbij in en zal een RFC plaatsen op het StUF forum !
Dat klopt. Maar iedere applicatie doet dat op haar eigen manier en daar is ook niets mis mee. Wij hebben het hier over een informatiemodel voor gegevensuitwisseling en kunnen dus volstaan met een generieke omschrijving zonder een codering.
In het RGBZ zal naast zaaktype-omschrijving generiek de attribuutsoort zaaktype code opgenomen worden. Deze is N4 en komt overeen met de in de (nieuwe) ZTC gehanteerde code voor een zaaktype.