Soorten benodigde gegevens

Voor de toepassing van de sociale zekerheid en de gezondheidszorg zijn er grosso modo 2 soorten gegevens nodig

• veranderlijke gegevens: gegevens waarvan de waarde/status over relatief korte tijdsperiodes voortdurend verandert, bv. werkelijk verrichte arbeidsprestaties, werkelijk verdiend loon, …

• (relatief) stabiele gegevens: gegevens die een welbepaalde, zelfde waarde/status hebben vanaf een bepaald moment tot een bepaald moment, bv. hoofdverblijfplaats, arbeidsrelatie werkgever-werknemer, … ; de tijdsperiode tussen de momenten waarop de waarde/status van de stabiel gegeven verandert, en dus de mate van stabiliteit, verschilt uiteraard van gegeven tot gegeven

Veranderlijke gegevens worden ingezameld

• op vastgelegde tijdstippen
• m.b.t. vastgelegde periodes

De frequentie van inzameling van de onderscheiden veranderlijke gegevens en de periode waarover ze worden geaggregeerd is afhankelijk van de behoeften. Het is mogelijk dat de frequentie anders is dan de periode waarover ze worden geaggregeerd (bv. driemaandelijkse inzameling van gegevens geaggregeerd per kalendermaand).

De waarde/status van  stabiele gegevens wijzigt wanneer zich bepaalde feiten of events (bv. verhuis, begin of einde van nieuwe arbeidsrelatie) voordoen. Wanneer de wijzigingen van de waarde/status van een stabiel gegeven relevant is voor toepassing van de sociale zekerheid of de gezondheidszorg, is het nuttig dat de betrokken instanties zo snel mogelijk op de hoogte zijn van de juiste gewijzigde waarde/status en eventueel van het feit dat de wijziging van de waarde/status veroorzaakt.

Het heeft geen zin om te proberen uit het geheel van meegedeelde events en wijzigingen van een waarde/status van stabiele gegevens te pogen de regelmatige inzameling van veranderlijke gegevens te vermijden. Dit dreigt immers te leiden tot een kostelijke en onnodige proliferatie van events en wijzigingen van de waarde/status van stabiele gegevens en tot fouten. Wel is het voor het waarborgen van de consistentie en het vermijden van fouten of pogingen tot fraude nodig om ingezamelde stabiele gegevens (bv. DIMONA-aangifte) te confronteren met ingezamelde veranderlijke gegevens (bv. DMFA).

Eenmalige gegevensinzameling van feitelijke gegevens volgens een gestandaardiseerd gegevensmodel

Diverse regelgeving waarborgt sedert decennia dat gegevens eenmalig worden ingezameld bij werkgevers en burgers, en door alle instellingen van sociale zekerheid worden gebruikt. Dit veronderstelt dat feitelijke gegevens worden ingezameld waarop de onderscheiden regelgeving kan worden toegepast, en geen gegevens die door de verstrekker juridisch zijn gekwalificeerd in functie van een bepaalde regelgeving. De juridische kwalificatie geschiedt door de onderscheiden instellingen van sociale zekerheid op basis van de beschikbare feitelijke gegevens overeenkomstig de regelgeving die ze dienen toe te passen.

De gegevensinzameling geschiedt overeenkomstig een gestandaardiseerd gegevensmodel. De wijze waarop dergelijk gegevensmodel wordt opgesteld en de concepten die dergelijk model zou moeten bevatten wordt lager toegelicht.

Gegevensminimalisatie en kwaliteit van gegevens

De Algemene Verordening Gegevensbescherming vereist het respect van een aantal principes bij de verwerking van persoonsgegevens. Een eerste belangrijk principe is dat van de gegevensminimalisatie: enkel die persoonsgegevens mogen worden verwerkt die nodig zijn voor het bereiken van rechtmatige doeleinden. Elke instelling van sociale zekerheid moet kunnen beschikken over de persoonsgegevens die nodig zijn voor de uitvoering van haar opdrachten, maar wel enkel over die persoonsgegevens en niet over meer persoonsgegevens.

Bij de toepassing van het principe van gegevensminimalisatie zijn minstens 4 dimensies in rekening te brengen

• welke gegevens zijn nodig (materieel toepassingsgebied)
• over welke personen (personeel toepassingsgebied)
• over welke periode (temporeel toepassingsgebied)
• over welke plaatsen (bv. hoofdverblijfplaats, werkplaats, …) (territoriaal toepassingsgebied)

Het principe van de gegevensminimalisering impliceert dat enkel die gegevens systematisch worden ingezameld die door één of meerdere instellingen van sociale zekerheid nodig zijn voor de uitvoering van hun opdrachten. Indien voor deze opdrachten slechts bepaalde gegevens over bepaalde personen over bepaalde tijdsperiodes en/of over bepaalde plaatsen nodig zijn, mogen die niet systematisch worden ingezameld, maar enkel occasioneel voorzover ze nodig zijn.

Een ander belangrijk principe is dat van de kwaliteit van de gegevens: de verwerkte gegevens moeten juist zijn en doorheen de tijd juist blijven. Daartoe zijn en worden in uitvoering van de KSZ-wet afspraken vastgelegd om

• vóór de inzameling van persoonsgegevens bepaalde kwaliteitscontroles te laten uitvoeren door de verstrekker van de gegevens
• na de inzameling van persoonsgegevens overeenkomstig een vastgelegde taakverdeling en service level agreements (SLAs) bepaalde kwaliteitscontroles te laten uitvoeren door de instelling die daartoe over de meeste competentie beschikt of daartoe het meeste belang heeft, alvorens ze ter beschikking worden gesteld aan andere instellingen via het netwerk
• mogelijke onjuistheden te melden, te laten onderzoeken en desgevallend te laten corrigeren door de instelling die overeenkomstig de taakverdeling belast is met de uitvoering van de kwaliteitscontroles
• de verbetering van de gegevens automatisch mee te delen aan alle instellingen die voorheen onjuiste gegevens hebben gekregen via het netwerk
• voor elk gegeven vast te leggen welke instelling welke gegevens bewaart in een authentieke bron en ter beschikking stelt via het netwerk

De afspraken rond taakverdeling omtrent inzameling en controle van de juistheid vastgelegd in uitvoering van KSZ-wet en de rol van authentieke bronnen dienen  te worden gerespecteerd. Er dient per soort wijziging van de waarde/status afgesproken te worden of de nieuwe waarde/status wordt meegedeeld door degene die het event publiceert, dan wel of de consument van het event de nieuwe waarde/status gaat opvragen bij de authentieke bron.

Gegevensmodel

Om het gestandaardiseerd gegevensmodel vast te leggen en te onderhouden, worden volgende beginselen gehanteerd

• modelleer via entity-relationship diagrams
  • de relevante concepten (entities)
  • hun betekenis
  • hun relevante eigenschappen
  • hun relevante onderlinge verhoudingen (relationships)
  • de relevante eigenschappen van de onderlinge verhoudingen
• modelleer zo werkelijkheidsgetrouw en begrijpbaar mogelijk
  • beschrijf feiten of feitelijke toestanden, geen juridische interpretaties ervan in functie van bepaalde regelgeving of bepaalde processen
  • gebruik natuurlijke taal, geen juridische definities
• bepaal voor de eigenschappen de mogelijke waarden die ze kunnen aannemen (waardenset), door een lijst van mogelijke waarden op te stellen en door de karakteristieken ervan vast te leggen (bv. type (numeriek, alfanumeriek, datum, …), minimum- en maximumwaarde, …)
• modelleer op een hoog niveau van abstractie zodat je nodige wijzigingen maximaal kan aanbrengen in de waardensets van de eigenschappen van entities en relationships ipv in de structuur van het gegevensmodel
• beperk het gegevensmodel tot de benodigde informatie, maar heb de ambitie om een gegevensmodel op te stellen dat op zeer lange termijn standhoudt
  • zorg dat het gegevensmodel kan worden aangevuld
  • maar dat wat reeds gemodelleerd is niet moet worden gehermodelleerd
• werk in verschillende lagen van verfijning
• maak het gegevensmodel publiek toegankelijk en begrijpbaar en zorg dat elkeen die regelgeving of processen uitwerkt zich daarop baseert

Basisconcepten die het gegevensmodel zeker zou moeten bevatten, zijn (in oranje: m.i. nog onvoldoende (gestandaardiseerd) uitgewerkt)

• natuurlijke persoon met
  • identiteit (INSZ, naam, voornamen, …)
  • basiseigenschappen (nationaliteit, burgerlijke staat, geboortegeslacht, genderidentiteit, …)
  • situering in de tijd (geboortedatum, overlijdensdatum, …)
  • situering in de ruimte (geboorteplaats, opeenvolgende hoofdverblijfplaatsen, overlijdensplaats, …)
  • contactgegevens (postadres, telefoonnummer, elektronisch adres, …)
• organisatie met
  • identiteit (KBO-nummer, naam, …)
  • basiseigenschappen (rechtsvorm, …)
  • situering in de tijd (oprichtingsdatum, …)
  • situering in de ruimte (maatschappelijke zetel, …)
  • contactgegevens (postadres, telefoonnummer, elektronisch adres, …)
• gezinsverhouding
  • tussen natuurlijke personen onderling
  • situering in de tijd (begindatum, einddatum, …)
  • situering in de ruimte (hoofdverblijfplaats)
  • specifieke eigenschappen van de gezinsverhouding (gezinspositie, …)
• arbeidsverhouding
  • tussen natuurlijke persoon enerzijds en natuurlijke persoon en organisatie anderzijds
  • situering van de verhouding in de tijd (begindatum, einddatum, …)
  • situering van de verhouding in de ruimte (arbeidsplaats, …)
  • specifieke eigenschappen van de arbeidsverhouding (soort arbeidsovereenkomst, …)
• verhouding tussen natuurlijke persoon en instelling van sociale zekerheid
  • situering van de verhouding in de tijd (begindatum, einddatum, …)
  • specifieke eigenschappen van de verhouding
• andere verhoudingen tussen
  • natuurlijke personen onderling
  • natuurlijke personen en organisaties
  • organisaties onderling
  • met voor elke verhouding
    • aard van de verhouding
    • situering in de tijd (begindatum, einddatum, …)
    • situering in de ruimte
    • specifieke eigenschappen van de verhouding
• inkomen
  • uit arbeidsverhouding(en)
  • uit andere bronnen
• arbeidstijd en daarmee gelijkgestelde tijd
• sociale rechten en statuten
• werkmelding
  • binnen welke verhouding(en)
  • situering in de tijd (beginmoment, eindmoment, …)
  • situering in de ruimte (plaats/zone van tewerkstelling, …)
  • met welke hulpmiddelen (voertuig, …)

De keuze van een gepaste achterliggende ICT-architectuur

Het is van groot belang dat voor de toepassing van eGov 3.0 achterliggende ICT-architecturen worden geïmplementeerd die waarborgen dat wordt voldaan aan de hogervermelde functionele vereisten. Sommigen pleiten voor een event driven architectuur voor de inzameling van de wijzigingen van de waarde/status van stabiele gegevens. Dergelijke architectuur is een ICT-technische architectuur waarbij ontkoppelde informatiesystemen asynchroon

• events kunnen publiceren (rol van ‘producent’)
• zich kunnen ‘abonneren’ op het verkrijgen van de events via een event broker (rol van ‘consument’)
• elke consument zelf beslist of en hoe hij reageert op dat event
• zonder dat de producent feedback krijgt over de reacties van de consumenten

 

De eventuele toepassing van een ICT-technische event driven architectuur vergt een aantal aandachtspunten.

Het basisbeginsel van gegevensminimalisering uit de Algemene Verordening Gegevensbescherming (AVG) vereist dat enkel events worden gepubliceerd die relevant zijn voor de consumerende informatiesystemen en dat elk van de consumerende informatiesysteem enkel de relevante events en gewijzigde waarden/statussen ontvangt.

Overigens vereist de publicatie en verwerking van events een actie door de publicerende en consumerende informatiesystemen, en kost ze dus verwerkingscapaciteit, tijd en geld.

Er is een onderscheid tussen het event en de waarde/status die ten gevolge van het event verandert. Beiden moeten niet noodzakelijk op hetzelfde ogenblik en door dezelfde instantie worden meegedeeld.

Er is nood aan voldoende zekerheid over de juistheid van de nieuwe waarde/status. De hogervemelde afspraken rond taakverdeling omtrent inzameling en verificatie van de juistheid vastgelegd in uitvoering van KSZ-wet en de rol van authentieke bronnen dient te worden gerespecteerd. Er dient per soort wijziging van de waarde/status afgesproken te worden of de nieuwe waarde/status wordt meegedeeld door degene die het event publiceert, dan wel of de consument van het event de nieuwe waarde/status gaat opvragen bij de authentieke bron.

In heel wat gevallen zal het niet voldoende zijn om events en wijzigingen van waarde/status te publiceren, maar is ook feedback nodig omtrent welke consumerende informatiesystemen welke events en/of wijzigingen goed ontvangen hebben en/of tot welke acties dat heeft geleid.

De volgorde waarmee events worden gepubliceerd of worden geconsumeerd is niet op voorhand vastgelegd. Dit is afhankelijk van verschillende factoren.

Bij publicatie van foute events moet er een corrigerend event worden gepubliceerd en alle consumerende systemen moeten gepaste correctieve acties implementeren.

Indien voor bepaalde processen wordt gekozen voor een ICT-technisch event driven architectuur, dient er dus goed beredeneerd omgesprongen te worden met het publiceren en verwerken van events om

• onnodige kosten te vermijden
• fouten te vermijden
• de regelgeving zoals de AVG te respecteren.