Brief regering : Broncode van het PGB2.0-systeem
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 participatiemaatschappij1. Met de juiste licentie kan een open source applicatie dus samen met anderen worden
ontwikkeld. De broncode wordt dan ergens neergezet waar iedereen erbij kan2. 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 Overheid3 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
4 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
Ondertekenaars
-
Eerste ondertekenaar
H.M. de Jonge, minister van Volksgezondheid, Welzijn en Sport