Preview document (🔗 origineel)

---

Tweede Kamer der Staten-Generaal	2
Vergaderjaar 2018-2019

25 657 Persoonsgebonden Budgetten

Nr. 317 BRIEF VAN DE MINISTER VAN VOLKSGEZONDHEID, WELZIJN EN SPORT

Aan de Voorzitter van de Tweede Kamer der Staten-Generaal

Den Haag, 6 mei 2019

In het VAO van 6 februari 2019 heb ik u een brief toegezegd over het openbaar maken van de broncode van het PGB2.0-systeem.

Ik zal de broncode van onderdelen van het PGB2.0-systeem openbaar maken. Het betreft de broncode van de kern van het PGB2.0-systeem; ik heb niet de bevoegdheid alle broncode openbaar te maken. De delen van de broncode die ik openbaar kan maken, maak ik openbaar nadat een aantal aanbevelingen is opgevolgd en diverse toetsen zijn afgerond. Mijn verwachting is dat de broncode in de tweede helft van dit jaar openbaar gemaakt kan worden.

Ik zal onderdelen van de broncode openbaar maken met alle rechten voorbehouden. Daarmee zal deze broncode niet beschikbaar komen voor hergebruik door derden en kwalificeert het niet als open source. Er gelden hiervoor wettelijke belemmeringen voor de overheid. Bovendien is de kern van het PGB2.0-systeem volledig toegesneden op de uitvoering van de PGB en acht ik daarom de herbruikbaarheid van deze broncode voor IT-systemen in een andere context laag.

Ik zal mijn besluit in deze brief toelichten. Vanwege het technische karakter van het vraagstuk licht ik eerst een aantal relevante begrippen toe uit de softwareontwikkeling, vervolgens ga ik in op het begrip open source en het verschil met openbaar maken. Tot slot licht ik toe hoe de huidige opbouw van het PGB2.0-systeem is en van welke delen ik de intentie heb om de broncode openbaar te maken.

Introductie van gebruikte begrippen

Om de toelichting helder te kunnen verwoorden licht ik eerst een aantal gebruikte begrippen toe, aangezien die begrippen ook onder IT-professionals nog weleens verschillend worden gebruikt. Dit doe ik door op vereenvoudigde wijze het proces van software ontwikkelen en het maken van een IT-systeem als PGB2.0 te beschrijven.

Software ontwikkelen ofwel programmeren is het proces waarin computers voorzien worden van instructies om ze te laten doen wat ze moeten doen. Die instructies worden in de vorm van een applicatie geïnstalleerd op de computer.

Een applicatie wordt ontwikkeld door broncode te schrijven. Broncode is een tekstbestand die de instructies bevat in een bepaalde programmeertaal, bijvoorbeeld Java. Een forse applicatie wordt gemaakt uit miljoenen regels tekst verdeeld over duizenden tekstbestanden.

Om te zorgen dat de computer de instructies beschreven in de broncode kan uitvoeren wordt deze omgezet (vertaald) naar instructies die door de computer uitvoerbaar zijn. Deze uitvoerbare code afkomstig van verschillende broncode tekstbestanden worden vervolgens weer samengevoegd tot een applicatie.

Bij het installeren van de applicatie komt de broncode meestal niet mee. De applicatie heeft die meestal niet meer nodig, alleen de uitvoerbare code is nodig. Sommige applicaties zijn daarop een uitzondering, deze kunnen ook na installatie nog worden geconfigureerd of gescript. Bij het configureren worden instellingen gewijzigd die de werking van de applicatie beïnvloeden. Bij het scripten kan de applicatie zelf instructies uit een bestand lezen, vertalen en direct uitvoeren. Dit bestand lijkt soms sterk op broncode maar wordt hier een script genoemd.

Een applicatie werkt tijdens het uitvoeren vaak samen met andere applicaties, ze zijn dan afhankelijk van elkaar. De ene applicatie kan niet gebruikt worden zonder samen te werken met de andere applicatie. Een IT-systeem bestaat uit meerdere applicaties die samenwerken. Soms zijn daar applicaties bij die op de achtergrond hun werk doen, ze zijn dan niet direct zichtbaar voor eindgebruikers. Deze applicaties worden ook vaak een service genoemd.

Soms kan men een geheel IT-systeem hergebruiken, omdat al eerder een dergelijk systeem is ontwikkeld. Vaak is er echter geen herbruikbaar kant-en-klaar IT-systeem te verkrijgen omdat een IT-systeem gezocht wordt voor een unieke situatie waar nog niemand eerder een systeem voor heeft ontwikkeld. Dit is bij de rijksoverheid regelmatig het geval, als het de uitvoering betreft van een unieke Nederlandse wet die uitgevoerd wordt met één IT-systeem. Nergens op de wereld bestaat dan immers een organisatie die hetzelfde IT-systeem nodig heeft. Er zijn dan dus ook geen leveranciers die een dergelijk systeem al een keer ontwikkeld hebben. In dat geval wordt er een op maat gemaakt IT-systeem ontwikkeld.

Op maat maken betekent in de meeste gevallen dat een IT-systeem wordt samengesteld door bestaande applicaties te combineren met nieuw ontwikkelde applicaties. Die bestaande applicaties kunnen dan verworven worden bij een leverancier. Door deze te configureren of te scripten kan dan de werking nog beperkt aangepast worden aan de specifieke wensen van opdrachtgever en gebruikers en ingepast worden in het IT-systeem.

Onderstaande figuur visualiseert dit proces.

Achterliggende gedachte en doelstelling van open source

Bij broncode, bij uitvoerbare code en applicaties is sprake van intellectueel eigendom en kunnen deze onder een licentie zijn geplaatst. Dit bepaalt welke rechten een ander heeft met betrekking tot die broncode, uitvoerbare code of applicatie. Als iemand de juiste rechten heeft op de broncode kan hij er zelf een applicatie mee maken. Afhankelijk van de licentie kan deze persoon de applicatie zelf gebruiken of een licentie verkopen aan anderen zodat die de applicatie kan gebruiken. Een applicatie «kopen» betekent dat je rechten krijgt die applicatie te installeren en te gebruiken met een aantal restricties. Je krijgt dan geen rechten op de broncode.

Open source is dus broncode die onder een open source licentie is gebracht. Er zijn tientallen verschillende open source licenties en het staat eenieder vrij om een nieuwe variant te maken. Vrijwel alle open source licenties staan het bewerken, hergebruiken en distribueren om niet, toe. Iedere licentie heeft daarnaast zijn eigen invulling met betrekking tot de beschikbaarheid van de broncode en de rechten en plichten van gebruikers en verspreiders van de applicaties die er mee gemaakt zijn. Zo is het bijvoorbeeld niet onder alle licenties verplicht om de broncode die iemand aangepast heeft ook weer openbaar te maken.

De gedachte achter open source is dat broncode open en vrij beschikbaar moet zijn voor iedereen. Zo kan iedereen voortbouwen op het werk van anderen, daarin fouten herstellen, verbeteringen aandragen en delen daarvan hergebruiken bij het maken van andere applicaties. De licentie zorgt ervoor dat het niet mogelijk is voor individuen om het gezamenlijk werk van velen alsnog toe te eigenen en commercieel te gebruiken.

Open source gaat dus over meer dan alleen openbaar maken. In een onderzoek dat Gartner in opdracht van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties heeft uitgevoerd wordt gewezen op de maatschappelijke baten van open source software. Het vrijgeven van de eigen code als open source software verhoogt de transparantie, innovatiekracht, realiseert synergie en bevordert de participatiemaatschappij¹. Met de juiste licentie kan een open source applicatie dus samen met anderen worden ontwikkeld. De broncode wordt dan ergens neergezet waar iedereen erbij kan². Iedereen kan de broncode daar ophalen en er een applicatie mee maken en vaak ook aanpassingen maken aan de broncode en deze terug plaatsen op die locatie. Of de aanpassingen die terug geplaatst worden ook overgenomen worden door anderen, mag iedereen zelf bepalen. In de praktijk valt het gebruiken van open source in te delen in drie varianten:

• In de eerste variant werken de voortrekkers, vaak innovatieve bedrijven en organisaties, met open source. Zij starten zelf met een open source initiatief en borduren intensief voort op de open source broncode. Daarbij gebruiken ze de broncode voor eigen gebruik en ontwikkelen er verder aan en leveren netjes hun bijdragen terug. Voorbeelden hiervan zijn RedHat, Netflix, Apache Software Foundation, Canonical, Google. Iedere organisatie bepaalt zelf welke variant van de gezamenlijk ontwikkelde broncode ze gebruiken.

• In de tweede variant hergebruiken de ontwikkelaars open source broncode maar laten deze onveranderd. Ze combineren deze broncode vaak met eigen broncode. De eigen broncode brengen ze niet onder in een open source licentie.

• In de derde variant maakt men gebruik van applicaties die gebaseerd zijn op open source, maar het complexe werk om de applicatie te maken uit de open source broncode laat men over aan de bedrijven uit de eerste variant. Een voorbeeld van een dergelijk bedrijf is RedHat. Dit lijkt sterk op het gewoon kopen van een standaard applicatie met dat verschil dat er niet een licentie wordt gekocht maar dat de leverende organisatie alleen wordt betaald voor het maken van de applicatie.

Als broncode niet beschikbaar is voor anderen om ze op een of andere manier te hergebruiken dan heet dat closed source. Dat is vaak het geval bij het kopen van een licentie voor gebruik en installatie van een applicatie van een leverancier. Dan verkrijgt men meestal geen rechten op de broncode.

Verschil tussen open of closed source en openbaar maken

Bij het ontwikkelen van een IT-systeem worden keuzes gemaakt. Welke bestaande applicaties zijn herbruikbaar? Welke moeten worden gekocht of zijn ze open source? Waar kan wel en waar kan niet open source gebruikt worden? Wordt de zelf te ontwikkelen software als open source ontwikkeld?

Het Rijksbeleid is hierbij dat bij gelijke geschiktheid van herbruikbare applicaties gekozen moet worden voor open source varianten. Er zijn echter lang niet altijd geschikte open source applicaties beschikbaar.

Bij het zelf ontwikkelen van eigen applicaties wordt ook bekeken of er open source broncode is die hergebruikt kan worden. Dit gebeurt vrij vaak, omdat er veel open source deeloplossingen zijn die het ontwikkelen van een eigen applicatie versnellen. Bij het hergebruiken is vaak geen noodzaak tot aanpassingen aan de hergebruikte broncode en daarmee ook niet aan het bijdragen aan de doorontwikkeling van de open source broncode.

Tot slot kan de rijksoverheid er zelf voor kiezen de ontwikkeling van een applicatie op te zetten als een open source project. Hiervoor gelden op dit moment echter nog wettelijke restricties doordat onder de Wet Markt en Overheid³ een open source project gezien kan worden als een economische activiteit die niet volgt uit de wettelijke taak van de overheid. Een door de overheid opgezette open source ontwikkeling heeft vooral zin als de betreffende broncode herbruikbaar is bij het ontwikkelen van andere IT-systemen.

Ook al is de broncode niet onder een open source licentie gebracht dan nog kan deze openbaar gemaakt worden. De broncode wordt dan gepubliceerd met alle rechten voorbehouden. Het gevolg hiervan is dat derden de broncode niet kunnen hergebruiken voor het ontwikkelen van eigen applicaties of voor commerciële doeleinden. Wel draagt het bij aan een transparante werkwijze.

Opzet PGB2.0-systeem

Het PGB2.0-systeem is een voorbeeld van een maatwerk IT-systeem dat is samengesteld uit bestaande en zelfontwikkelde applicaties. In het PGB2.0-systeem komen dan ook diverse van de eerder genoemde varianten voor. De applicaties zijn als volgt te groeperen:

1) Deelsysteem Z-Domein (ontwikkeld door DSW/ZN)

a) Kern applicaties

Dit zijn de applicaties die vooral gebruikt worden door budgethouders en zorgverleners, maar ook door de verstrekkers en SVB.

Deze bevatten de functionaliteit voor het toekenningsbericht, de zorgovereenkomst, de declaraties, de budgetten, de werkvoorraad, ziekte & herstel, en het gebruikers profiel.

b) Document applicaties

Dit zijn de applicaties voor het omgaan met documenten, zoals printen, scannen en opslaan.

c) Ondersteunende applicaties

Dit zijn de applicaties in een ondersteunende rol, bijvoorbeeld om adressen te verifiëren.

2) Deelsysteem F-Domein (ontwikkeld door SVB)

a) Kern applicaties

Dit zijn de applicaties die gebruikt worden voor de financiële en de salaris administratie.

b) Ondersteunende applicaties

Dit zijn de applicaties in een ondersteunende rol bijvoorbeeld voor het afhandelen van transacties met de bank.

Daarnaast zijn er nog zogenaamde externe applicaties. Dit zijn applicaties die het PGB2.0-systeem nodig heeft en mee samenwerkt maar die niet tot het PGB2.0-systeem behoren. Zo wordt bijvoorbeeld de DigiD applicatie gebruikt om budgethouders veilig in te laten loggen. Ook zijn er externe applicaties bij gemeenten en zorgkantoren die samenwerken met het PGB2.0-systeem. Deze externe applicaties worden hier verder buiten beschouwing gelaten aangezien ze niet onderdeel zijn van het PGB2.0-systeem. Ze zijn echter wel randvoorwaardelijk. Onderstaand figuur visualiseert de genoemde groepering van de applicaties.

Gemaakte keuzes in de opzet van het PGB2.0-systeem

Voor het PGB2.0-systeem is gekozen voor het hergebruiken van bestaande applicaties in combinatie met het ontwikkelen van eigen applicaties. Sommige applicaties van het PGB2.0-systeem zijn standaard applicaties en goed verkrijgbaar bij leveranciers. Een voorbeeld hiervan in het F-Domein deelsysteem is de applicatie waarmee de salarisadministratie wordt uitgevoerd. Het is niet nodig een dergelijke applicatie zelf te ontwikkelen, aangezien er een goede en betaalbare applicatie reeds beschikbaar is.

Bij het ontwikkelen van het Z-Domein deelsysteem heeft DSW ook de keuze gemaakt om een aantal applicaties te hergebruiken. Van deze applicaties is een aantal verworven als licentie om te mogen installeren en gebruiken. Daarnaast is een aantal applicaties ontwikkeld door DSW, sommige specifiek voor PGB2.0, anderen waren al eerder door DSW ontwikkeld. Deze laatste applicaties worden ook gebruikt door DSW zelf en andere zorgverzekeraars.

De gemaakte keuzes voor standaardapplicaties acht ik zeer doelmatig net als het hergebruiken van de applicaties van DSW. Hierdoor waren zowel SVB als DSW in staat snel en met weinig risico’s een goed werkend IT-systeem op te leveren.

Contractueel is bij de overdracht van het Z-Domein van DSW/ZN naar VWS afgesproken dat van de door DSW specifiek voor het PGB2.0-systeem ontwikkelde applicaties het intellectueel eigendom overgedragen wordt naar VWS. Van de overige door DSW ontwikkelde applicaties blijft het intellectuele eigendom bij DSW en verstrekt DSW/ZN een onherroepelijk, niet-exclusief, overdraagbaar, eeuwigdurend recht aan VWS om deze applicaties te gebruiken (inclusief het verder ontwikkelen op basis van de overgedragen broncode). Deze licentie maakt het niet mogelijk om de broncode van de applicaties die niet specifiek voor het PGB 2.0 systeem zijn ontwikkeld openbaar te maken.

In onderstaande figuur zijn alle applicaties benoemd met een indicatie van de rechten die op de applicatie rusten.

Openbaar maken

Zoals toegezegd ben ik voornemens om waar dat kan en mag de broncode openbaar te maken. Ik ben van mening dat het inzicht geven in de broncode kan bijdragen aan het succes van het PGB2.0-systeem en het is daarnaast passend in het licht van een transparante overheid.

Gelet op de bovengenoemde informatie heb ik heb niet de bevoegdheid om het geheel van broncode van het PGB2.0-systeem openbaar te maken, omdat de auteursrechten op een deel van de applicaties die onderdeel uitmaken van het PGB2.0-systeem niet bij VWS liggen. In bijlage 1 Overzicht applicaties PGB2.0-systeem ⁴ geef ik op onderdelen aan of de auteursrechten bij VWS liggen en of ik de broncode openbaar ga maken. Aangezien het PGB2.0-systeem constant wordt aangepast en verbeterd kan dit overzicht over enige tijd weer zijn veranderd.

Samengevat ben ik voornemens van de volgende applicaties van het deelsysteem Z-domein de broncode openbaar te maken (de nummers verwijzen naar de nummering van de applicaties in de bijlage):

• PGB Portaal (1)

• Processing Engine (2)

• Koppeling service (3)

• GGK Berichten service (4)

• Vecozo Berichten service (5)

De applicaties van het deelsysteem F-domein zijn vooral standaard applicaties waar ik niet beschik over de broncode en de auteursrechten en deze dus niet openbaar kan en mag maken. Eén applicatie is open source en is daarmee al openbaar.

Het openbaar maken zal ik doen met alle rechten voorbehouden. Daarmee zal de broncode niet beschikbaar zijn voor hergebruik door derden en zal het dus niet beschikbaar komen onder een open source licentie. Gezien het unieke karakter van deze applicaties ligt dat ook niet voor de hand. Deze kernapplicaties zijn volledig toegesneden op de uitvoering van de PGB en de herbruikbaarheid voor IT-systemen in een andere context acht ik laag.

Ten slotte

Dit jaar zal er nog intensief worden doorontwikkeld aan het PGB2.0-systeem. Dit zal het grootste deel van de genoemde applicaties raken. Het betreft dan onder andere functionaliteit die noodzakelijk is om de landelijke uitrol mogelijk te maken, functionaliteit om handmatige werkzaamheden te reduceren en verdere opschaling mogelijk te maken en om aspecten als rechtmatigheid en bestrijding van fraude afdoende te ondersteunen.

Ik maak de broncode, zoals hierboven beschreven, openbaar nadat de onderstaande aanbevelingen, eisen en toetsen zijn afgerond:

• De aanbevelingen uit de eerdere kwaliteitstoets op de software door SIG.

• De aanbevelingen naar aanleiding van de juridische toets die uitgevoerd is door de landsadvocaat.

• Eisen aan het systeem die nodig zijn om landelijke uitrol te kunnen starten.

• Toets op belemmeringen vanuit het oogpunt van informatiebeveiliging en privacy.

Mijn verwachting is dan ook dat de broncode in de tweede helft van 2019 openbaar kan worden gemaakt. Indien daartoe aanleiding is zal ik daarna ook nieuwe versies van deze broncode openbaar maken.

De Minister van Volksgezondheid, Welzijn en Sport,
H.M. de Jonge

---

1. https://www.rijksoverheid.nl/documenten/rapporten/2017/10/11/onderzoek-open-source-software↩︎

2. Een veel gebruikte locatie is github.com. Dit is ook de plek waar de broncode van OperatieBRP beschikbaar is.↩︎

3. http://wetten.overheid.nl/BWBR0029818↩︎

4. Raadpleegbaar via www.tweedekamer.nl↩︎