GGM en GIZO: één conceptmodel of twee werelden?

Wie in een gemeentelijke organisatie iets wil bouwen op data uit het sociaal domein, loopt vroeg of laat tegen twee modellen aan. Het Gemeentelijk Gegevensmodel (GGM) van VNG en het GIZO-conceptmodel van Zorginstituut Nederland. Op het eerste gezicht doen ze hetzelfde: ze beschrijven hoe je gegevens rond cliënten, toewijzingen, leveringen en declaraties modelleert. Op het tweede gezicht zitten er belangrijke verschillen tussen.

Die verschillen zijn geen modelleerfout. Het zijn bewuste keuzes vanuit verschillende invalshoeken. GGM is breed: alles wat een gemeente over inwoners en hun voorzieningen vastlegt. GIZO is gefocust: precies wat er via iWmo, iJw en iEb tussen gemeenten en aanbieders wordt uitgewisseld. Maar als je een datawarehouse bouwt of een nieuw applicatielandschap inricht, moet je weten waar je voor kiest.

De drie soorten verschillen

We mapten alle 32 objecten uit het GGM Sociaal Domein tegen GIZO. Het resultaat zit grofweg in drie categorieën.

1. Naamgevingsmismatches (zelfde concept, andere naam)

De klassieker. GGM heet het Leverancier, GIZO noemt het Aanbieder. Allebei dezelfde partij — de zorgaanbieder met een AGB-code. GGM kent Declaratieregel, GIZO heeft Prestatie. Functioneel identiek.

Deze mismatches zijn geen technisch probleem maar wel een communicatieprobleem. Als je modelleur GGM gebruikt en je dataleverancier praat in GIZO-termen, ontstaan er eindeloze afstemmingsoverleggen die met een mapping-tabel voorkomen hadden kunnen worden.

2. Structurele verschillen (andere modelleer-diepte)

Hier wordt het interessanter. GGM heeft een keten van vier objecten: Beschikking → Beschikte Voorziening → Voorziening → Voorzieningsoort. GIZO heeft één plat veld: een productcategorie en productcode op de Toewijzing.

Geen van beide is fout. GGM's keten geeft je flexibiliteit: je kunt dezelfde Voorziening aan meerdere cliënten toekennen met verschillende parameters. GIZO's platte aanpak is simpeler maar dwingt je tot duplicatie als één beschikking meerdere voorzieningen omvat.

3. Gaps aan beide kanten

Sommige concepten staan alleen in GGM. Huishouden bijvoorbeeld, of Beperking en Zelfredzaamheidmatrix. GIZO erkent dit zelf: gezinsgerichte producten en beperkingscores zijn buiten scope gehouden omdat ze niet in het berichtenverkeer voorkomen. Voor een gemeente die hun eigen casus-administratie wil modelleren is dat een gat dat je elders moet vullen.

Andersom heeft GIZO concepten die GGM niet kent. Verzoek antwoord, Verzoek om wijziging, Kostprijs, DeclaratieAntwoord. Allemaal afkomstig uit het berichtenverkeer. Wie GGM gebruikt mist deze ketenobjecten en zal ze zelf moeten toevoegen.

Wat betekent dat voor je datastrategie?

Drie scenario's. Welke je kiest hangt af van je positie en plannen.

Scenario A — GGM als basis, GIZO als koppelvlak. Je modelleert je eigen administratie op GGM, en gebruikt GIZO alleen op de raakvlakken met aanbieders. Werkt goed voor gemeenten die zelf veel rond hun cliënten willen vastleggen (casusregie, gezinsbeeld, hulpvraag-historie).

Scenario B — GIZO als basis, GGM als aanvulling. Je houdt je datawarehouse strak op GIZO en breidt alleen uit waar nodig (Huishouden voor gezinsanalyse, Beperking voor grondslagen). Werkt goed voor gemeenten die hun focus op berichtenverkeer en monitoring leggen.

Scenario C — beide modellen leven naast elkaar. Met een expliciete mapping tussen beide. Werkt goed in grote organisaties waar verschillende teams verschillende leveranciers hebben en je een gemeenschappelijke vertaaltabel nodig hebt.

Aan de slag

Geen van deze keuzes maak je in een vrijdagmiddag. Maar de mapping zelf hoort wel ergens te bestaan in je organisatie. Zonder die mapping word je verrast door discrepanties tijdens implementatie — en dat zijn dure uren.

We bouwden een viewer waarmee je voor elk GGM-object direct ziet wat de GIZO-tegenhanger is. Per object: definitie, attributen, mapping-notitie, en de bevindingen die we tegenkwamen tijdens het mappen. De viewer is opgenomen in onze demo-omgeving.