Direct naar content

Aanvraagprocedure nieuwe data producten

Aanvraagprocedure nieuwe data producten

Gepubliceerd: 18-11-2025

Ontwikkelen nieuwe Data Producten

Wanneer een behoefte heeft aan Energiedata welke nog niet opgenomen is in de Data Producten Catalogus, maar waarvan de data elementen wel vermeld staan in de Ministeriële Regeling, kan zij een verzoek indienen om een nieuw te realiseren.

De aanvraag voor een nieuw Data Product kan ingediend worden bij middels het Data Product Aanvraag formulier. In afstemming met Dienstverleners en de betreffende Registerbeheerders zal het Data Product gedefinieerd en geprioriteerd worden en op de realisatieplanning van Het Normo komen ter realisatie. Schematisch ziet de procedure voor het realiseren van nieuwe Data Producten er als volgt uit.

Figuur: het realiseren van een nieuw Data Product verloopt via bovenstaande procedure.

Procesbeschrijving Ontwikkelen nieuwe Data Producten

  1. De Dienstverlener (Dataverzoekende partij) gebruikt het Data Product Aanvraag formulier om de data behoefte te expliceren.
  2. Het ingevulde Data Product Aanvraag Formulier wordt ingediend bij Het Normo (via vragen@hetnormo.nl). Aan de hand van het toetsingskader in het Data Aanvraag Formulier beoordeelt Het Normo of het gevraagde Data Product kan worden gerealiseerd. Om niet voor elk nieuw te ontsluiten data element of een combinatie van elementen een aanpassing aan de systemen te moeten doen zal tevens bij de aanvraag zorgvuldig bekeken worden of de data behoefte niet reeds door een bestaand Data Product of een combinatie van Data Producten kan worden ingevuld. Het (middels de CoP intake) ontvangt de uitkomst van de toetsing en kan desgewenst om advies worden gevraagd.
  3. Het Normo doet een uitvraag onder Dienstverleners en de Registerbeheerders waar de benodigde Data Elementen geregistreerd zijn (in de Ministeriële Regeling staat beschreven welke data elementen per worden bijgehouden). Het Normo plant een aantal workshops met deze werkgroep om het Data Product te definiëren. De behoefte wordt uitgewerkt met in achtneming van de Design Principes (onderstaand). Vervolgens wordt de Data Product Definitie overgedragen aan het ontwikkelteam van Het Normo voor verdere specificatie.
  4. In het Data Product Overleg wordt het Data Product geprioriteerd voor realisatie. Eventuele impact op de releaseplanning wordt besproken met het MFF (middels het ).
  5. Indien het gevraagde Data Product aanpassing vergt aan de systemen van de betreffende Registerbeheerder, neemt het ontwikkelteam van de Het Normo contact op met de betreffende Registerbeheerders om de impact te bepalen en een implementatie pad te bepalen. Hierbij is tevens afstemming met het MFF (middels het IPPO). Indien het een wijziging aan een bestaand Data Product betreft zal een migratieplan inclusief overgangsperiode worden afgesproken.
  6. Op gezette tijden informeert Het Normo over updates in de Data Producten Catalogus en de Data Producten welke op de roadmap staan voor realisatie.
Download het Data Product Aanvraag formulier Bekijk de beschikbare Data Producten Bekijk de actuele Ministeriële Regelingen

Design Principes ontwikkelen Data Producten

Design Principes bieden een kader om op een gestructureerde en transparante manier Data Producten te ontwikkelen die zowel technisch robuust als beleidsmatig verantwoord zijn.

Ze helpen om bewust afwegingen te maken over architectuur, privacy, toegang, interoperabiliteit en gebruiksvriendelijkheid.

Door deze keuzes expliciet te bespreken in het ontwikkelproces, ontstaat gedeeld begrip, betere besluitvorming en uiteindelijk Data Producten die aansluiten bij wetgeving, gebruikersbehoeften van de , toekomstige schaalbaarheid, rekening houdend met de positie van de .

Wanneer een Dienstverlener behoefte heeft aan data die nog niet ontsloten is middels een is het de aanbeveling deze Design Principes door te nemen bij het invullen van het Data Product Aanvraag Formulier.

#    Design Principe Waarom  Hoe 
1  van de aansluiting als basis

De aansluiting is de basis voor het opvragen van Data Producten.

 Het unieke kenmerk waarmee een aansluiting/ wordt aangeduid is de EAN code in de registers van de . Bij een aansluiting/ punt hoort een specifieke .

Voordat gegevens op verzoek van de Datarechthebbende kunnen worden gedeeld moet er een EAN-code aan die persoon kunnen worden gekoppeld.

Dit zorgt voor Identificatie, en van de Datarechthebbende waarmee privacy en rechten van de Datarechthebbende worden gerespecteerd en geborgd. Dit garandeert dat uitsluitend gegevens worden gedeeld waarvoor expliciet is verzocht door de Datarechthebbende.

 Bij het verzoek om data te delen dient de EAN-code op te worden gegeven.
2  Fit for purpose 

Een Data Product bevat elementen uit één enkel Register.

Per Register zijn er één of meerdere Data Producten die bestaan uit één of meerdere (logisch gekozen) subsets van Data Elementen.

 Met deze manier van ontsluiten kan eenvoudiger geborgd worden dat niet meer gegevens worden opgevraagd dan voor (het doel van) een dienst noodzakelijk is (zie ook Design Principe #3, #4 en #5).

 

 Voor de ontsluiting van data uit meerdere Registers zal een Dienstverlener verschillende Data Producten opvragen.

Een verzoek (autorisatie) kan gaan over meerdere Data Producten.

In de klantreis wordt de autorisatie voor meerdere Data Producten in één keer geregistreerd.

In het autorisatie proces ziet de Datarechthebbende de Data Elementen die worden opgevraagd.
3  Wettelijke reikwijdte

Bij het ontwikkelen van nieuwe Data Producten kunnen alleen de Data Elementen uit de Ministeriële Regeling worden geselecteerd.

 Om zorg te dragen dat er geen data wordt uitgevraagd die niet is opgenomen de Ministeriële Regeling en ook niet door een Registerbeheerder beheerd wordt. Een in een Data Product bevat alleen Data Elementen, die zijn opgenomen in de Ministeriële Regeling.
4  Beheersbaarheid

Via kunnen alleen vastgestelde, geïmplementeerde en in de Data Product Catalogus gepubliceerde Data Producten geleverd worden.

 Om het proces van opvragen uniform, efficiënt en beheersbaar te houden. De koppeling tussen de Registerbeheerder en de Dienstverlener via Het Normo kan uitsluitend vastgestelde Data Producten leveren.

De faciliteiten van Het Normo zijn beveiligd tegen het opvragen van meer Data Elementen dan in het Data Product zijn vastgesteld of waarom verzocht wordt.
5  Dataminimalisatie

Een Data Product bevat alleen die Data Elementen die logischerwijs relevant zijn voor de dienst.

 Om zorg te dragen dat een Dienstverlener niet meer data opvraagt dan nodig is voor het doel van de dienst. Door het zorgvuldig vaststellen van de Data Producten en het opnemen van voorwaarden voor het gebruik van deze Data Producten in de Data Producten Catalogus.
6 Herbruikbaarheid

Data Producten worden gedefinieerd uit Data Elementen die logisch bij elkaar horen en niet meer data bevatten dan nodig voor een bepaald inzicht. Hierdoor ontstaan herbruikbare Data Producten.

 Dit voorkomt ook een wildgroei aan Data Sets die door de Registerbeheerders ontsloten moeten worden. Vanuit een Data Set worden meerdere Data Producten gedefinieerd. Hierdoor wordt ‘wildgroei’ aan datasets bij de Registerbeheerder voorkomen.
7  Zorgplicht 

Er dient te worden voorkomen dat er een wildgroei aan Data Producten ontstaat.

 De Registerbeheerder dient zo veel als mogelijk te worden ontzorgd in het aantal wijzigingen dat hij iedere keer moet doorvoeren. Om niet voor elk nieuw te ontsluiten of een combinatie van elementen een aanpassing aan de systemen te moeten doen zal bij elke aanvraag voor een nieuwe Data Product zorgvuldig bekeken worden of de databehoefte niet reeds door een bestaand Data Product of een combinatie van Data Producten kan worden ingevuld.
8  Heldere foutafhandeling 

Op een dataverzoek komt een response. Als het goed gaat, de gevraagde data. Als het niet goed gaat, een foutmelding met oorzaak.

 

 Het is voor de Dienstverlener belangrijk om zonder omstanden te begrijpen welke data is geleverd, welke delen van het opgevraagde Data Product daadwerkelijk zijn geleverd en welke niet. Daarnaast is inzicht nodig in de redenen achter eventuele problemen. Dit helpt om verbeterpunten te identificeren en te verbeteren. Wanneer een dataverzoek naar een Registerbeheerder een foutmelding oplevert of er een lege response komt, zal de Dienstverlener deze response ontvangen. In een dergelijke situatie wordt deze niet geregistreerd als een data-transactie en is een eenmalige autorisatie nog steeds geldig en kan op een later moment nogmaals worden uitgevoerd.

De mogelijk voorkomende (fout)situaties worden in kaart gebracht en in afstemming tussen Het Normo, Registerbeheerders en de Dienstverleners de mogelijke meldingen vastgesteld.
9  Performance Performance vereisten dienen aan te sluiten op het verwachte / te verwachten gebruik van een Data Product (en daarmee de aanvragen van de bijbehorende Data Sets bij de Registerbeheerders).

 

 Om te voorkomen dat te hoge beschikbaarheids- en performancevereisten worden geëist, terwijl dit voor het gebruik van het Data Product niet noodzakelijk is. De beschikbaarheid, uptime en responsetijden van de registerontsluiting moet passen bij het karakter en gebruik van het Data Product.

Dit betekent dat de ‘purpose’ van een Data Product onderdeel wordt van de gebruiksvoorwaarden van het Data Product.

Data opvragingen worden door de Dienstverlener gedaan wanneer de data nodig is, daarbij zoveel mogelijk verspreid in de tijd uitgevoerd (dwz niet in batch alle data verzoeken in een keer doen).
10  Rolzuiverheid 

De gegevensuitwisseling geschiedt op een gestructureerde wijze waarbij iedere partij zuiver zijn rol vervult.

 Om de gegevensuitwisseling conform de wet uit te voeren is het zaak dat iedere partij zuiver zijn rol kan vervullen. Registerbeheerders leveren Data Sets aan op een gestructureerde wijze, met een minimum aan inspanning. Er wordt van de Registerbeheerder geen effort verwacht voor het berekenen en samenvoegen van data.

In haar rol om de identificatie, authenticatie en autorisatie in te richten, is Het Normo verantwoordelijk voor de intelligentie/logica voor de koppeling van de Datarechthebbende en het allocatiepunt.

De Dienstverlener kan voor haar Energiedata Dienst meerdere Data Producten opvragen. Zij is zelf verantwoordelijk voor het combineren of samenvoegen van verschillende (type) producten.

Voorbeelduitwerking van Design Principe Performance:

Onderstaand een voorbeeld hoe het Design Principe Performance voor een Data Product kan worden uitgewerkt. Deze uitwerking vormen de voorwaarden voor het gebruik van het Data Product en zullen worden opgenomen bij de beschrijving van het Data Product in de Data Product Catalogus.

Performance vereisten dienen aan te sluiten op het verwachte / te verwachten gebruik van een Data Product, oftewel:

  • Data Producten die worden gebruikt/bedoeld voor adviesdiensten worden opgevraagd in de ‘werktijden’ voor adviesdiensten.
  • Data Producten voor het dagelijks vullen van dashboard worden uitgevraagd als de data beschikbaar is / zou moeten zijn en tot een bepaalde eindtijd. Een dergelijke data opvraag kan bijvoorbeeld ‘s nachts gepland worden.

Hiermee wordt maximaal ingespeeld op het beschikbaar zijn van data, maar wordt ook ruimte gecreëerd voor onderhoud aan de systemen.

De beschikbaarheid, uptime en responsetijden van de registerontsluiting moet passen bij het karakter en gebruik van het Data Product.

De schrijft voor dat data onmiddellijk gedeeld dient te worden wordt als deze beschikbaar is:

  • Alle aanroepen (dataverzoeken) worden uitgevoerd met een synchrone API-call
  • Responsetijd tussen 0,5 en 25 seconden (een langere responsetijd van 25 seconden bijvoorbeeld voor het samenstellen van een grotere response zoals een jaar aan 15 minuten data)
    • De dataverzoeken voor een Data Product met een ‘grotere’ data Set (bv de eenmalige toestemming voor historische energievolumes) worden door de Dienstverlener sequentieel uitgevraagd (dus niet allemaal tegelijk/parallel, waardoor piekbelastingen bij Registerbeheerder worden verminderd)
      • Een enkele Dienstverlener zal daardoor op ieder moment altijd maar 1 data-uitvraag tegelijkertijd hebben uitstaan (voor alle autorisaties die hij dit type Data Product heeft)
      • Dataverzoeken worden gedaan als de data nodig is/daadwerkelijk verwerkt gaat worden, daarbij worden de dataverzoeken zoveel mogelijk verspreid in de tijd uitgevoerd (dwz niet in batch alle dataverzoeken uitvoeren als deze niet verwerkt gaat worden. Op deze wijze worden er geen piekbelastingen gecreëerd doordat iedere Dienstverlener in de ochtend om 8:00 zijn batch-proces laat draaien).