Datadiensten

Beschrijving

Datadiensten is één van de Stelselfuncties en beschrijft hoe de uitwisseling van gegevens via services wordt gestandaardiseerd. Dit heeft betrekking op de wijze waarop Application Programming Interfaces (API’s) worden vormgegeven. Het standaardiseren van API’s vergemakkelijkt het uitwisselen van gegevens, in het bijzonder voor afnemers die gegevens van verschillende aanbieders combineren.

Deelfuncties

De stelselfunctie omvat de volgende deelfuncties:

• Bevragen op sleutel
• Zoeken
• In bulk bevragen
• Notificeren
• Terugmelden

Het afsprakenstelsel FDS richt zich op het ontsluiten van een reeds opgebouwde dataset vanuit een aanbieder naar meerdere afnemers. Dit betekent dat uitwisseling ten behoeve van het bijhouden van een dataset (zoals een bericht om een verhuizing te laten registreren in een dataset) of het afnemen van een dienst (zoals een bericht met een verzoek voor een parkeervergunning) niet onder het FDS afsprakenstelsel vallen. Voor andere (domein)datastelsels kan dit anders zijn.

Relatie met Europese initiatieven

De stelselfunctie Datadiensten is gebaseerd op het Technical Building Block Data Exchange van het Blueprint van het Data Spaces Support Centre. Dit komt overeen met het Data Exchange API’s building block zoals beschreven in het OPEN DEI design principles position paper on Resources.

Relatie met de GDI en NORA

In de Domeinarchitectuur Gegevensuitwisseling is de stelselfunctie Datadiensten gerelateerd aan de functies Aanbieden gegevens en Afnemen gegevens. Daarbij is binnen FDS geen splitsing gemaakt in functies voor het aanbieden en het afnemen. Bij elke functie vullen de aanbieder en de afnemer ieder hun deel in.

Bevragen op sleutel

GDI Domeinarchitectuur Gegevensuitwisseling: subfuncties Beschikbaar stellen actuele gegevens, Beschikbaar stellen historische gegevens en Ontvangen gegevens. GDI maakt hierbij geen onderscheid tussen bevragen op sleutel en in bulk bevragen.

Bevraging op sleutel heeft betrekking op het ophalen van kenmerken van een object, zoals een persoon, organisatie of locatie, op basis van een sleutelwaarde van dit object, zoals een bsn. Dit object kan ook een gebeurtenis zijn, zoals een geboorte, een correctie of de vaststelling van een jaarinkomen. De afnemer geeft op van welk object de kenmerken worden opgehaald door in de vraag de sleutelwaarde van het object, zoals een bsn of KvK-nummer, op te nemen. Dit betekent dat de afnemer al geïdentificeerd heeft van welk object het kenmerken wil ophalen.

Vanuit het oogpunt van dataminimalisatie dient de afnemer in te perken welke kenmerken van het object teruggeven dienen te worden. Inperking kan door deze in de gestelde vraag op te nemen, door de inperking in de Toegang in te richten, of door een combinatie van deze twee methodes.

Afspraken

Standaarden

REST-API Design Rules
Digikoppeling (REST-API)

Zoeken

GDI Domeinarchitectuur Gegevensuitwisseling: subfunctie Selecteren van gegevens.

Zoeken heeft betrekking op het ophalen van de sleutelwaarde van één of enkele objecten, zoals een persoon, organisatie of locatie, op basis van kenmerken van een object. Bijvoorbeeld het ophalen van de bsn van enkele personen op basis van een een adres (bag-id) als vestigingsadres. Dit heeft tot doel een specifiek object te vinden.

Vanuit het oogpunt van dataminimalisatie dient de afnemer in te perken binnen welke populatie naar objecten dient te worden gezocht. Inperking kan door deze in de gestelde vraag op te nemen, door de inperking in de Toegang in te richten, of door een combinatie van deze twee methodes.

Afspraken

Nog geen afspraken

Standaarden

REST-API Design Rules
Digikoppeling (REST-API)

In bulk bevragen

GDI Domeinarchitectuur Gegevensuitwisseling: subfuncties Beschikbaar stellen actuele gegevens, Beschikbaar stellen historische gegevens en Ontvangen gegevens. GDI maakt hierbij geen onderscheid tussen bevragen op sleutel en in bulk bevragen.

Het ophalen van kenmerken van meerdere objecten in één keer. Een variant van een bulkbevraging is de ‘selectie’ waarbij in één keer de kenmerken van een (potentieel omvangrijke) groep objecten worden opgehaald. Vanwege de benodigde verwerkingstijd om een selectie samen te stellen kan het noodzakelijk zijn een ‘selectie’ asynchroon samen te stellen. In dat geval kan de aanbieder de afnemer notificeren zodra de selectie is samengesteld en kan worden opgehaald, bijvoorbeeld via de Digikoppeling Koppelvlakstandaard Grote Berichten.

Vanuit het oogpunt van dataminimalisatie dient de afnemer in te perken welke populatie objecten, en welk kenmerken van het object teruggeven dienen te worden. Inperking kan door deze in de gestelde vraag op te nemen, door de inperking in de Toegang in te richten, of door een combinatie van deze twee methodes.

Afspraken

Nog geen afspraken

Standaarden

Nog geen voorgenomen standaarden

Notificeren

GDI Domeinarchitectuur Gegevensuitwisseling: subfuncties Abonneren en notificeren en Gegarandeerd afleveren.

Naast het bevragen van gegevens is het van belang dat de afnemer pro-actief op de hoogte kan worden gebracht van gebeurtenissen. Dit pro-actief op de hoogte brengen noemen we notificeren. Een notificatie kent een soort gebeurtenis (wat is er gebeurd) en een subject (wie of wat betreft het). Denk aan de geboorte van een kind, of de correctie van een belastbaar inkomen. De standaard NL GOV Profile voor Cloudevents is geschikt als standaard voor het bericht dat bij een notificatie wordt verstuurd.

Bijzondere aandacht verdient het notificeren van correcties. Een afnemer kan rechtsgevolgen verbinden aan opgevraagde gegevens. In dat geval is het van belang dat de afnemer op de hoogte wordt gebracht van correcties op gebruikte gegevens, zodat het de (rechts)gevolgen opnieuw kan beoordelen en adequaat kan reageren. Dit betekent enerzijds dat de aanbieder notificaties moet kunnen sturen van correcties op eerder geleverde gegevens, en anderzijds dat de afnemer op basis van deze notificaties moet kunnen bepalen welke verwerkingen met rechtsgevolgen potentieel opnieuw beoordeeld moeten worden.

Een variant van notificeren is het leveren. Bij leveren worden berichten veelal voorzien van de (gewijzigde) gegevens zelf. Dit is echter een kopie van de bron. En deze bron kan ten tijde van verwerking inmiddels zijn verouderd. Zuiverder is daarom om de notificatie alleen te gebruiken als ’trigger’ van een verwerkingsproces, en de voor de verwerking benodigde actuele gegevens via bevraging op te halen. Dit vereenvoudigt tevens de dataminimalisatie doordat per verwerkingsstap om minimale data kan worden gevraagd, in plaats dat bij een aanbieder op voorhand bekend dient te zijn wat de minimale set gegevens is die de afnemer nodig heeft voor de verwerking.

Ten behoeve van leveren is de ebMS standaard in Digikoppeling opgenomen. EbMS is echter een redelijk ‘zware’ en complexe standaard om te implementeren. Met de introductie van NL GOV Profile voor Cloudevents wordt er een deel ingevuld om leveren te kunnen vervangen door notificeren.

Een aanbieder stuurt notificaties vanuit een ‘abonnement’ dat aangeeft voor welke soorten gebeurtenissen en voor welke populatie een afnemer notificaties wenst te ontvangen. Vanuit het principe van dataminimalisatie is het onwenselijk dat een afnemer notificaties ontvangt waarop de afnemer geen verwerking hoeft te laten volgen. Dit heeft raakvlakken met de inperkende functionaliteit in de context van de stelselfunctie Toegang.

Momenteel is er een werkgroep actief om verdere invulling van Notificeren verder vorm te geven (nog geen webpagina beschikbaar).

Afspraken

Nog geen afspraken

Standaarden

Terugmelden

GDI Domeinarchitectuur Gegevensuitwisseling: subfunctie Terugmelden.

De deelfunctie ‘Terugmelden’ heeft betrekking op het ter beschikking stellen van een (data)service ten behoeve van het terugmelden. Met deze terugmeldservice kan een afnemer van data een terugmelding doen bij de aanbieder als de afnemer gerede twijfel heeft over de juistheid van een afgenomen gegeven. De mogelijkheid tot terugmelden is een belangrijk onderdeel van het afsprakenstelsel FDS en vervat in de afspraak KW003: Terugmelden . Er zijn echter (nog) geen afspraken over het faciliteren van terugmelding met een terugmeldservice.

Afspraken

Nog geen afspraken

Standaarden

Nog geen voorgenomen standaarden

• ←Vorige
• Volgende→