De motie van CDA en GroenLinks is niet behandeld in het afgelopen Kamerdebat eind september maar aangehouden tot eind oktober. Staatssecretaris Van Rijn neemt dan het onderwerp mee in een brief die hij naar de Tweede Kamer stuurt over hoe hij de pgb-problematiek verder gaat aanpakken en wat de voortgang is van het nieuwe portaal.
Dat blijkt dus door de zorgverzekeraars te worden gebouwd, meldde NOS vandaag op zijn website. Brancheorganisatie Zorgverzekeraars Nederland krijgt een voortrekkersrol bij het opzetten van het nieuwe systeem. Volgens de NOS stelt de bewindsman wel als voorwaarde dat alle partijen, zoals de gemeenten en de belangenorganisaties, worden betrokken bij de ontwikkeling, alsook de SVB.
Volgens CDA-Kamerlid Mona Keijzer is de motie aangehouden omdat zij en collega Voortman benieuwd zijn hoe serieus Van Rijn om gaat met open source. In 2002 nam de Tweede Kamer de motie-Vendrik aan waarin de norm opgenomen is om te werken met opensource-ict; daaruit spreekt dat het nieuwe betalingssysteem voor de pgb’s een opensourcesysteem wordt, aldus Keijzer en Voortman in de motie.
Dat de verzekeraars de nieuwe betaalportaal gaan ontwikkelen, doet daar niets aan af, zegt Keijzer in een korte reactie. Regeringspartijen VVD en Pvda hebben overigens al herhaaldelijk gesteld voor open source te zijn, onder andere bij de discussies over de BRP (Basisregistratie Personen). Pvda-Kamerlid Astrid Oosenbrug diende afgelopen vrijdag zelfs nog een (aangepaste) motie in in het kader van het VAO Actieplan open overheid 2016-2017 waarin zij constateert dat nog niet overal binnen de Rijksoverheid en de decentrale overheden gewerkt wordt met open standaarden en open source software. Zij verzoekt de regering in de motie om het gebruik van open standaarden te verplichten bij wet.
De NOS meldt in zijn artikel dat de zorgverzekeraars het systeem zullen bouwen en dat later wordt beslist wie de website en ook het geld gaat beheren. Aanvankelijk was het de bedoeling dat de SVB een nieuw systeem zou ontwikkelen, maar verschillende partijen in de Kamer, waaronder coalitiepartij VVD, hebben aangegeven geen vertrouwen meer in die organisatie te hebben.
SVB nog verantwoordelijk
De SVB is nu nog verantwoordelijk voor de uitbetaling van de persoonsgebonden budgetten, waarmee zorg kan worden ingekocht. Vanaf het moment dat die dat ging uitvoeren, regende het klachten. Uit meerdere onderzoeksrapporten, waaronder van het Bureau ICT Toetsing (BIT), blijkt dat het computersysteem bij de SVB krakkemikkig is. Behalve dat het om de zoveelste ict-ramp bij het Rijk ging, handelde het ook om dramatisch bestuurlijk falen.
Het nieuwe systeem zou, als het aan de Tweede Kamer ligt, in 2018 operationeel moeten zijn. Dat is erg ambitieus: de migratie van de data vanuit de it-omgeving van de SVB is alleen al een immense opgave.
CDA-Kamerlid Keijzer heeft afgelopen april nog geprobeerd de broncode en ontwerpdocumentatie op te vragen van de falende ict-systemen die het SVB gebruikt voor de uitkeringen van het persoonsgebonden budget (pgb). Staatsecretaris Van Rijn vond dat uit oogpunt van beveiliging niet wenselijk. 'Onbevoegden zouden mogelijkheden vinden in het systeem privacygevoelige informatie op te zoeken en te manipuleren' schreef hij als antwoord. Wel stelde hij voor om een briefing te organiseren door de Sociale Verzekeringsbank waarbij kan worden aangegeven hoe het zit met zaken rondom de broncodes en ict.
Reacties
Hoe zou zoiets gaan in de tweede kamer..
ok, volgende agendapunt, iets met open en ict.
Heb het ge-googled en het gaat over over automatisering.
eeeh, soooorses of die meer open kunnen.
Das beter en veiliger of juist niet. Geen idee. Wie is er voor ?
Wordt allemaal gebouwd door de zorgverzekeraars, dan zal het wel goed zijn.
Oh, standaarden kunnen ook open lees ik. Voor, tegen, wie ?
Hoe zou je zaken kunnen manipuleren als het systeem uitgeschakeld is?
'Volgens de NOS stelt de bewindsman wel als voorwaarde dat alle partijen, zoals de gemeenten en de belangenorganisaties, worden betrokken bij de ontwikkeling, alsook de SVB.'
De bewindsman vergeet de belangrijkste partij: de echte eindgebruikers. Open source lost het vraagstuk van een goede requirementsanalyse die hier hard nodig is NIET op. Politiek en ICT.....
Ik zou toch wel eens willen weten welk probleem de kamerleden denken op te lossen door de gehele applicatie open source te maken. Dat de standaarden en de interface definities open source, of op z'n minst vrij opvraagbaar zouden moeten zijn kan ik begrijpen.
Maar wat is de reden om de hele spullenboel open source te maken?
Let wel: ik ben helemaal niet tegen open source, sterker nog ik ben een fervent voorstander van Linux en de vele distro's die er te gebruiken zijn. Maar ik snap weinig van de achterliggende redenen om open source af te dwingen.
Niet erg wijs om politici een dergelijke implementatiekeuze te laten maken. Een geloof in maakbaarheid en idealisme zijn meestal geen goede leidraden in een ICT omgeving.
Open Source met de bijbehorende brakke applicatie stacks en "veilige" code gemaakt door scrum teams die een nu al onmogelijke datum moeten halen. Bovendien gaan de zorgverzekeraars het systeem bouwen en zal er dus een vrijwel zeker een enorme backdoor inkomen. Maar aangezien ss. van Rijn niemand de broncode laat inspecteren komt niemand daar achter.
We zullen het ergens in 2020 wel horen als de eerste schandalen openbaar worden.
Na alle ellende met de PGB's is open source blijkbaar het belangrijkst???????
SInds wanneer zijn de zorgverzekeraars toegetreden tot de IT ontwikkelaars? Schoenmaker blijf bij je leest, ofwel, maak requirements, en laat het vervolgens ontwikkelen.
Ik laat toch ook geen banksysteem door door een kruidenier ontwikkelen?
Belachelijk gewoon.
Weer een bus politici die de klok hebben horen luiden, maar totaal geen idee van de klepel hebben. Alsof je een PGB systeem als 'Open Source' kan aanschaffen. Zelfs als het op Linux/Apache/MySQL/PHP gebaseerd wordt, zal de broncode nog steeds 'gesloten' zijn. Of gaat men deze code op Internet zetten, zodat de 'community' lekken kan opsporen ?
Heren,
U kunt het beide volksvertegenwoordigers, Mona Keijzer (CDA) en Linda Voortman (GroenLinks) bijna niet kwalijk nemen. Er is blijkbaar niemand bereid of in staat om het daadwerkelijke probleem te duiden. Ook wij moeten "hand in eigen boezem steken".
Antwoorden heren, daar wacht men op, en allemaal in Jip en Janneke taal alstublieft.
Dat het ontwikkelen van een betrouw-, beheers- en betaalbaar software systeem voor onze overheid geen kwestie is van open of gesloten software , maar vooral een kwestie is van goed opdrachtgever-schap en bijbehorende verantwoordelijkheden en controle mechanismen. Daar valt, mede op dit platform meer dan voldoende informatie over te lezen.
Dat het in open source model programmeren en dus beter toegankelijke broncode van software op voorhand geen voordelige invloeden zal hebben, is ook ieder van ons duidelijk. Immers open zegt niets over kwaliteit van ontwerp tot aan realisatie! Maar wat dan wel? Zolang het zich laat aanzien, lijkt beteugelen van "financieel pervers geprikkelde" opdrachtnemers die op geen enkele wijze rekenschap hoeven af te leggen in de zin van aangetoonde werkende systemen en tevreden eindgebruikers, een eerste oplossing!
Ook zal de roep om meer open source geen enkele bijdrage gaan leveren! De roep om een goed herontwerp (architectuur) en uitgevoerde realisatie waar de belastingbetaler in de BV Nederland werkelijk iets aan heeft, is meer iets wat ik meen te lezen in de goedbedoelde acties van beide Kamerleden. U en ik weten dat, ook in Den Haag sommigen proberen het "beest te temmen", maar is men afhankelijk van kennis dragende 2e kamer leden die zich kunnen verdiepen in de reële problematiek en het Kabinet op juistheid kunnen bevragen.
Mijn angst blijft dat, zonder deze goede intenties teniet te willen doen, er zonder begeleiding van deskundigen niemand in staat zal zij om de minister met de juiste feiten te confronteren. Gesloten of Open broncode geeft nou eenmaal geen enkele vrijbrief voor goede software...goed uitgevoerd opdrachtgever-schap bied meer kansen.
Verder valt het helemaal niet op dat er verkiezingen aankomen of zo.
Jammer dat de waan van de dag de politiek moet regeren. Open Source zou de oplossing moeten zijn... maar als je de commentaren op dit artikel leest, weten weinig mensen wat Open Source vandaag de dag inhoudt.
Alle grote spelers zijn tegenwoordig met Open Source initiatieven op de markt, ja markt want het is nog steeds commercieel. Source Code en Open Source zijn twee verschillende dingen. Open Source is vaak een freemium model tegenwoordig, gratis tenzij...
De rechtszaken tussen Google en Oracle over het gebruik van Sun Java gaan niet over "het gebruik van" maar "de gelden voor" !! Linux voor thuis gebruik is gratis maar Enterprise varianten van bv RedHat of Canonical vragen gewoon geld en sluiten de broncode van de extra's.
Jammerlijke ontwikkelingen die alleen maar meer stof doen opwaaien en het werkelijk doel verbergen !!
Jammer dat de waan van de dag de politiek moet regeren. Open Source zou de oplossing moeten zijn... maar als je de commentaren op dit artikel leest, weten weinig mensen wat Open Source vandaag de dag inhoudt.
Alle grote spelers zijn tegenwoordig met Open Source initiatieven op de markt, ja markt want het is nog steeds commercieel. Source Code en Open Source zijn twee verschillende dingen. Open Source is vaak een freemium model tegenwoordig, gratis tenzij...
De rechtszaken tussen Google en Oracle over het gebruik van Sun Java gaan niet over "het gebruik van" maar "de gelden voor" !! Linux voor thuis gebruik is gratis maar Enterprise varianten van bv RedHat of Canonical vragen gewoon geld en sluiten de broncode van de extra's.
Jammerlijke ontwikkelingen die alleen maar meer stof doen opwaaien en het werkelijk doel verbergen !!
In aanvulling op de eerdere reacties. Ik zou het vooral laten ontwikkelen op een RAD platform van deze tijd. Dus zoiets als Mendix of Outsystems. Als het dan toch om de platformkeuze zou gaan.. Maar nogmaals; de requirements, dat is waar het mee valt of staat volgens mij. En betrek ook de klanten die het moeten gaan gebruiken. Ben zelf vertegenwoordiger van een PGB-er en werk met de huidige PGB oplossing van SVB. Nou, daar kan een hoop beter aan (lees ook makkelijker, gebruikersvriendelijker en slimmer).
Ik sluit me aan bij CPT: welk probleem denkt men hiermee op te lossen?
Daarnaast kan dit ook een weerslag hebben op het prijskaartje: wanneer ik als bedrijf een aantal hele slimme algoritmen bedacht heb om bijvoorbeeld berekeningen te doen of slimme queries uit te voeren wil ik deze misschien wel voor mezelf houden (intellectueel eigendom). Wordt ik nu verplicht gesteld deze openbaar te maken, wil ik daar als bedrijf wel graag geld voor zien, waardoor de oplossing duurder uit kan vallen.
Per saldo teleurstellend, deze reacties. De vandaag aangenomen motie van Astrid Oosenbrug (PvdA, niet herkiesbaar) bevat in de considerans een aantal belangrijke argumenten waarom ook de PGB open source moet worden: https://twitter.com/AstridOosenbrug/status/785829654569611264
En let wel: als de PGB broncode van de SVB (Treks) wordt vrijgegeven dan heb je een maand late een schandaal eerste klas.
Wat ik hier niet aan begrijp is dat de verzekeraars dit systeem gaan bouwen. Wat is dat voor een gek idee om nu de bouw van een pgb systeem, met vele belanghebbenden, bij deze commerciële partijen neer te leggen. Het pgb waar de verantwoordelijkheid voor de uitvoering bij de overheid ligt. En wie gaat dat betalen? Een krankzinnig idee wat onvermijdelijk gesteggel gaat opleveren. Alleen maar omdat de overheid zijn zaken niet voor elkaar krijgt? Onbegrijpelijk en hoe is het mogelijk. Het kan altijd weer gekker.
Dan de vraag van de sp en cda om voor Open source oplossingen te kiezen. Ik lees dat politici niet op de stoel van de ict er moeten gaan zitten. Maar toch vind ik het een leuke suggestie. De vraag is hoe in andere gevallen de oplossing bepaald wordt. Dan denk ik aan het uitbestedings model wat gemeengoed is bij de overheid. Dan krijg je niet alleen de grillen van de ict leverancier kado maar ook de software van preferred supplier. Met bijbehorende licentiekosten. Alleen daarom al vind ik het idee van cda en sp serieus te nemen.
Misschien moeten de zorgverzekeraars weer staatsbedrijven worden, dan denk ik dat de premies omlaag gaan en er weer geld is om "zorg aan de patient" te leveren.
Zorg verlenen gaat met mensen, ICT is slechts een faciliterende randvoorwaarde.
Wat me nu niet helemaal duidelijk gaat het om gebruik van Open source alternatieven of om de bron code openbaar te maken. Openbaar is betrekkelijk maar de opdrachtgever moet ze zeker hebben. Ben voor beide ook al kies je misschien voor een variant waar je voor ondersteuning en kennis betaalt. Blijf het een goed idee van cda en sp vinden. Die zitten er bovenop en zij kritisch.
@jan Eens, zaken voor het algemeen nut moet je niet aan de markt overlaten. We zien al jaren wat de marktbureaucratie brengt. Veel overhead en registratiedrift gevoed door wantrouwen en de zucht naar controle.
@redactie Wat is er toch mis met het reactiesysteem? Zie namen niet altijd meer terugkomen boven reacties, al geruime tijd. Zit het bij mij? Of is de site niet in orde?
Ik twijfel geen moment aan de reactie van René hierboven, dat zodra er inzage gegeven moet worden in broncode van opgeleverde software bij de overheid er heibel ontstaat. Getuige de uitlatingen van onder andere René zal er behoorlijk wat "spaghetticode" ...Ja, misschien zelfs wel broddelwerk aan het daglicht komen. Betreurenswaardig natuurlijk, maar niet onoverkomelijk, want te verbeteren!
Wat me daarentegen wel zeer aan het hart gaat, is waarom er (Ja ik heb alle interviews van de hoorzittingen v.d. commissie Elias gezien) schijnbaar geen veranderingen plaatsvinden in het opdrachtgever-schap bij onze overheid voor software ontwikkeltrajecten. Het BIT (bureau ict toetsing) heeft , een paar uitzonderingen daargelaten, nog niet voor zoveel commotie veroorzaakt.
Wellicht kan iemand (beter ingeleid in de materie) ons hier beter duiden waarom er sprake blijft van slecht opdrachtgever-schap van overheidswege bij dit soort aanbestedingen. Ik heb zelfs al eens ooit heel verontrustende dingen aan mogen horen van dhr Leether (destijds bedrijfsjuridisch adviseur ministerie van Veiligheid en Justitie). https://youtu.be/b1jxhAfm_pI?t=17m40s
Vraag blijft natuurlijk. Hoe nu verder, waarom toch zo doormodderen? is de roep om opleveren in Open source (broncode die inzichtelijk wordt gesteld) de oplossing. Wie gaat dat op voorhand reviewen? Wat moet inzage in de broncode,ons achteraf gezien opleveren? Bewijslast? Waarvoor? Er is nog geen enkele opdrachtnemer ter verantwoording geroepen door het Kabinet! En bij de eerstvolgende aanbesteding doet men gewoon weer mee... "Past Performance my ass...!!!!"
Prima natuurlijk. Open maken, herbruikbare bouwblokken identificeren en publiceren. Alleen zo kan de belasting-euro het efficiëntst renderen. Martin van Rijn heeft een punt; Niet alle Overheidsdocumenten moeten zomaar publiek gemaakt worden. Denk aan het ontwerp van een briefje van 100 of de details van een communicatiesysteem van de hulpdiensten. Sommige software valt hier ook onder. Echter, de standaard zou moeten zijn:"Open ontwikkeling, tenzij...[landsbelang, etc]".
Ik droom van broncode.overheid.nl en een land vol programmeurs. Dan kan eindelijk de innovatiesnelheid omhoog en hoeven we niet meer 20x hetzelfde wiel te bedenken. Voor software-ontwikkelaars ontstaat er een nieuwe wereld; samen (interdepartementaal) werken aan de beste oplossingen. Wat mij betreft inclusief, badges, ratings, comments, net als op Stackoverflow en Github. Laat maar eens zien waar de paarlen liggen!
Ik ben met veel mensen eens dat het Open Source maken niet perse het grootste probleem oplost maar aangezien het vrijwel geen effort is om bij de bouw van een nieuw systeem het open source te maken zou per definitie al een reden moeten zijn om het te doen. Hierdoor worden partijen die eraan werken gedwongen kwaliteit te leveren, immers (en helemaal na het drama van het huidig systeem) zullen externe mensen de ontwikkelingen prima in de gaten houden en worden prima en kan er sneller worden ingegrepen. Als ze dan ook nog eens het systeem laten bouwen door een goede partij die het op een agile manier aanpakt met als focus de eindgebruiker dan is het al een enorme verbetering vergeleken met de vorige keer.
De reactie van staatssecretaris van Rijn is natuurlijk goud waard. 'Onbevoegden zouden mogelijkheden vinden in het systeem privacygevoelige informatie op te zoeken en te manipuleren' schreef hij als antwoord. Juist in dit antwoord ligt hét argument voor open source ontwikkeling besloten. Het bekijken van een stuk frontend software mag NOOIT de sleutel bieden tot beschermde gegevens in de backend! Zeker in een open source model worden ontwikkelaars gedwongen hier goed over na te denken.
Ik probeer hieronder uit te leggen hoe dat precies zit. Een tikkie lang, wellicht (TLDR?), maar volgens mij begrijpelijk voor iedereen.
Een veel gehoord argument tegen Open Source is, dat “de informatie” op straat ligt. Maar is dat wel zo? Bij een goed ontworpen en ontwikkeld informatiesysteem is sprake van scheiding van functies. We zijn gewend om functiescheiding toe te passen binnen organisaties. Dit type scheiding zien we ook binnen een informatiesysteem. Er zijn blokken in het systeem die interactie aangaan met de gebruiker en er zijn onderdelen die juist wijzigingen op de database bewerkstelligen. Vaak is er ook nog sprake van een middleware laag (broker), die ervoor zorgt dat onderliggende architecturen gemakkelijk vervangen kunnen worden.
Vergelijk een informatiesysteem met de kaartenbak bij een Gemeente (het oude “bevolkingsregister”). Een ouder komt aangifte doen van de geboorte van een dochter, bij de ambtenaar aan het loket (de baliemedewerker). Deze medewerker schrijft op een formulier hoe de nieuwe burger heet, haar geboortedatum en andere kenmerken. De ouder plaatst een handtekening ter bevestiging. Daarna wordt het formulier overgedragen aan een andere medewerker (de archiefmedewerker). Deze persoon heeft de sleutelcode van de archiefkast, waarin de persoonskaarten van de alle inwoners van de gemeente zijn opgeborgen. Met behulp van de informatie op het formulier maakt de ambtenaar een nieuwe persoonskaart aan, opent de archiefkast, plaatst de persoonskaart op de juiste plek en doet de archiefkast weer op slot. Daarna geeft de archiefmedewerker een nummer (BSN) aan de baliemedewerker, die het aan de trotse ouder meegeeft.
Een informatiesysteem werkt ongeveer hetzelfde. Om de analogie te maken met open source, beschouwen we alle informatie die de eerste medewerker (de baliemedewerker) heeft. Stel nu, dat we toegang hebben tot al die informatie. Dan weten we dus onder andere hoe het formulier eruit ziet, welke gegevens erop geplaatst moeten worden en aan wie we het formulier moeten geven. De details van de rest van het proces (de cijfercode voor het openmaken van de archiefkast, c.q. database) is voor ons nog steeds een black box. Ook de creatie van het BSN is voor de baliemedewerker een onzichtbaar proces. Hij weet wel dat het ontvangen nummer overhandigd moet worden aan de ouder die aangifte kwam doen.
Met Open Source software is het precies zo. Sterker nog; In de analogie van het genoemde bevolkingsregister-systeem; een programmerende burger zou met een Open Source oplossing zelf in staat zijn om de vorm van het formulier te wijzigen, velden op een andere plek neer te zetten of omschrijvingen aan te passen. Zolang de informatie die de tweede medewerker nodig heeft, maar intact blijft. Hier zit dan ook de crux van beveiliging van informatiesystemen met een Open Source component; De database (de archiefkast) en de processen rond die database (de code om de kast open te maken, en de versleuteling in de informatie zelf) moeten zorgen voor de beveiliging.
Stellen we ons voor dat de ouder die aangifte komt doen bovenaan het formulier de volgende zin schrijft: “Open de archiefkast en geef mij de persoonskaart van Anky van Grunsven”. Dan zal de tweede medewerker deze opdracht toetsen aan de bij hem bekende werkwijze. Als die instructie niet past bij de processen en procedures, dan zal de archiefmedewerker deze instructie negeren en de normale gang van zaken volgen. Mogelijk bevat de werkinstructie een regel voor het melden van fouten op het formulier. De archiefmedewerker die beheer voert over de archiefkast is in deze situatie verantwoordelijk voor de integriteit van de gegevens (data) in de kast. In de software is het niet anders. Als de open source front-end een foutieve instructie geeft aan de back-end, dan zal dit genegeerd worden of leiden tot een foutmelding.
In een closed-source wereld, is het mogelijk om eventueel gevonden gaten in de beveiliging “dicht te smeren” in de software. In onze analogie, laten we een zeer extreem voorbeeld nemen. Bijvoorbeeld; De archiefmedewerker geeft stelselmatig niet alleen het burgerservicenummer van de nieuwgeborene, maar ook dat van de koningin aan de ouders bij de balie. Als een softwareontwikkelaar dit ondervindt tijdens het ontwikkelen, is de verleiding groot om dit op te lossen in de software. In onze anologie; de baliemedewerker krijgt de instructie om het tweede bsn niet, en het eerste bsn wel aan de ouders te geven. Het beveiligingslek is hiermee niet opgelost, maar de burger merkt niets van de foutieve gang van zaken. Als die front-end software wel open source is (de instructie van de baliemedewerker is publiek inzichtelijk), dan zal elke burger die naar de instructie kijkt (in casu; programmeurs) opmerken dat er een fout zit in de communicatie van de archiefmedewerker naar de baliemedewerker. In die zin dwingt het maken van Open Source software misschien wel juist tot het beter nadenken over de integrale beveiliging van het informatiesysteem.
Of dit soort fouten gemaakt is in de broncode van PGB, weet ik niet. Dat ze direct ontdekt zouden worden als de software door een kritische crowd bekeken wordt, daarvan ben ik overtuigd. Misschien, om dhr van Rijn tegemoet te komen, dus eerst door een team van 10 ontwikkelaars van verschillende bedrijven laten bekijken. Wie op basis van dat bekijken beschermde gegevens uit de database weet te peuteren, wint de hoofdprijs (wel even uitleggen hoe, aub). Andere concrete suggesties voor verbetering worden beloond. Als het goed gebouwd blijkt te zijn, kan de broncode gepubliceerd worden. Hele traject zou niet langer dan 2 maanden moeten duren.