Met enige regelmaat komt de vraag voorbij: waarom hebben we niet 1 (elektronisch) dossier voor alle Nederlanders? Dat zou toch handig zijn, als alle zorgprofessionals in het zelfde dossier zouden werken? Het lijkt een elegant idee. Maar er zijn ook veel redenen waarom dat niet het geval is.

Een belangrijke reden is hoe in Nederland beroepsgeheim is geregeld. Zorgverleners hebben, vanzelfsprekend, beroepsgeheim. Maar ze mogen in Nederland ook niet met collega zorgverleners informatie delen als er geen sprake is van bijvoorbeeld waarneming, consultatie of overdracht over de huidige behandeling. Informatie delen uit een andere behandeling, vroeger of zelfs gelijktijdig, mag alleen met toestemming van de cliënt. Ook als het gaat om het verantwoorden van het professioneel handelen, bijvoorbeeld in het kader van toezicht of tuchtrecht, wordt het dossier van de zorgverlener zelf beschouwd. Dat eigen dossier kan niet zo maar aangepast door een andere zorgverlener. Want ook voor die aanpassingen is de dossierhouder zelf medisch en juridisch verantwoordelijk. Er zijn daarom heel veel medische waarheden, op heel veel plekken.

Gegevens, bijvoorbeeld de ontslagbrief van de medisch specialist aan de huisarts, zijn daarom in meerdere dossiers beschikbaar. Want een zorgverlener moet ook als een dossier bij een andere zorgverlener niet (meer) beschikbaar is kunnen aantonen waarom en hoe gehandeld is. Omdat de bewaartermijnen van dossiers verschilt kan ook niet aangenomen worden dat gegevens blijven bestaan bij een ander. Alleen de cliënt mag de eigen gegevens voor altijd bewaren. Wellicht is het op te lossen met regelgebaseerde toegang, versiecontrole, etc. Maar dat wordt wel een heel complex stelsel. Kortom: beroepsgeheim, dossierplicht en bewaartermijnen zijn belangrijke redenen voor eigen dossiervoering en die regels zijn niet makkelijk te verwerken tot één dossier in één systeem.

Zeker als dat ene dossier ook alle zorgsectoren (denk aan huisartsenzorg, ziekenhuiszorg, langdurige zorg, wijkverpleging, jeugdzorg, etc.) zou moeten afdekken. In landen waar sprake is van gezamenlijke dossiervoering, bijvoorbeeld omdat de overheid de zorg levert, blijft die vaak beperkt tot medisch specialistische zorg. Want de verschillende zorgsectoren verschillen sterk in taal en in dossiervoering. Eenheid van taal tussen de sectoren is nog wel te bereiken. Daarvoor worden bijvoorbeeld de zorginformatiebouwstenen ontwikkeld. Een systeem voor dossiervoering voor alle vormen van zorg is veel complexer. De verschillende (vaak internationale) talen in de verschillende sectoren (zoals ICPC in de eerstelijn, OMAHA voor verpleegkundigen en SNOMED in de ziekenhuiszorg) plat slaan tot één taal in de dossiervoering, dat is nauwelijks te doen. Want daarvoor moet ook internationaal van alles gebeuren, en moeten zelfs opleidingen worden aangepast.

Gezamenlijke dossiervoering in één systeem heeft meer beperkingen. Het maakt kwetsbaar, bijvoorbeeld voor inbreuken op privacy en cyberaanvallen. In plaats van bescherming door redundantie ontstaan “single points of failure” die bij uitval grote delen van de zorgverlening zouden raken.

Ook maakt het innovatie minder vanzelfsprekend. Want die kan maar op één plek plaatsvinden. En is als gevolg daarvan vaak beperkt in scope en beperkt in variatie. Waar nu in elk ziekenhuis de eigen inrichting anders kan zijn en innovatie op veel plekken kan ontstaan vraagt één centraal systeem om regie. Regie die moet zorgen dat dat systeem overal hetzelfde blijft. Dat wijzigingsverzoeken nationaal worden besproken en beoordeeld. Dat levert niet vanzelf een wendbare situatie op en snelle toepassing van innovatie. Want innovatie voor een bepaald zorgproces moet dan eerst door alle zorgverleners in Nederland die bij dat proces betrokken zijn worden besproken en bepaald.

Tot slot, met de nodige zelfspot: komen tot één systeem vergt overheidsinterventie en een nationaal systeem. Wie zou mij vertrouwen als het gaat om het nemen van die besluiten en de innovatie daarna?

Tegelijkertijd: zonder een centraal systeem is het de uitdaging om te zorgen dat zorgverleners wel over de juiste informatie beschikken om hun werk te doen. Gegevensuitwisseling is daarvoor nodig (passend binnen de regels voor beroepsgeheim en privacy). Daarom is interoperabiliteit en standaardisatie van gegevensuitwisseling zo belangrijk.

Koop ik een nieuwe auto of investeer ik nog in mijn oude? Het is een keuze waar autobezitters helaas wel eens voor komen te staan. En wie kent niet het gevoel dat de enkele reparatie wel meevalt in vergelijking met de kosten van een nieuwe auto, maar dat achteraf en opgeteld alle reparaties en alle dagen dat je even niet kon rijden wel erg kostbaar en irritant waren? Mensen die in een oud brik doorrijden worden vaak meewarig aangekeken. Merkwaardigerwijs geldt hetzelfde de laatste tijd voor organisaties die juist kiezen voor nieuwe ICT.

Vragen over de vervanging van auto's en van ICT lijken op elkaar. Hoe lang kan het oude systeem nog mee en worden opgelapt? Hoe vaak krijg ik dan onverwacht onderhoud en lange zoektochten naar de oorzaak van een probleem? Hoeveel is me dat waard? En kan het oude systeem mijn nieuwe eisen wel aan?

Eerder schreef ik een column over de oproep van Chris Verhoef om vooral in stapjes te vernieuwen. Ik vergeleek het met alle onderdelen van een auto stapsgewijs vervangen. Ik heb niet zoveel met nieuwe auto’s, dus stond waarschijnlijk wat vaker dan gemiddeld voor de keuze om nog een keer te investeren of een nieuwe tweedehandse aan te schaffen. Gelukkig koos ik vaak tijdig voor dat laatste.

Maar wanneer kies je als het gaat om ICT voor doorgaan met het oude en wanneer voor iets nieuws? Dat vraagt, net als bij auto’s, een “diepgaand onderzoek op pijnpunten” zoals Chris Verhoef het noemt. Hoe verweven is de code of juist hoe modulair, hoe veilig, hoe begrijpelijk, hoe kwetsbaar, hoe schaalbaar? Kan het nieuwe eisen aan, of niet? Pas na een goede analyse kun je kiezen wat verstandig is.

Voor het beoordelen van softwarekwaliteit bestaat een ISO-norm. Die beschrijft helaas vooral kwaliteitskenmerken en is dus weinig concreet. Ik wil namelijk de vraag kunnen stellen “wat zijn de voordelen en de nadelen van het kopen van een nieuwe auto en van het houden van mijn oude in het licht van mijn vervoerswensen”, en daar dan een antwoord op krijgen dat niet afhankelijk is van de specifieke monteur maar gebaseerd is op een analyse waar de hele garagebranche het over eens is. Of, in ICT termen, ik wil code kunnen laten analyseren en aanhouden tegen (nieuwe of bestaande) eisen en op basis van een door iedereen geaccepteerde norm weten wat de risico's en kansen zijn van doorontwikkelen en van nieuwbouw.

Afgelopen weken lieten wij zo'n analyse doen voor een specifiek ICT-systeem. Van dat bestaande systeem werd de code doorgelicht en aangehouden tegen nieuwe eisen (10 maal zo hoog volume, bijvoorbeeld). De conclusie: nieuwbouw of verbouw zijn ongeveer even duur en zullen ongeveer even lang duren. Maar de risico’s voor onder meer uitval bij hoog volume zijn in het nadeel van verbouw. Op dat soort doorwrochte analyses van de broncode onder de motorkap kun je beslissingen nemen. Helaas is daar nog geen standaardaanpak voor en zijn de analyses van verschillende monteurs vaak heel verschillend.

Vandaar mijn oproep aan iedereen die zich bezig houdt met het toetsen van softwarekwaliteit: kom tot een norm. Een NEN-norm bijvoorbeeld, met daarin een industriestandaard (gebaseerd op ISO 25010) om op basis van analyse van broncode expliciet de kansen en risico’s van doorontwikkeling versus nieuwbouw te schetsen. Ik zou erg blij zijn met een dergelijke gestandaardiseerde aanpak. Dan ontstaan namelijk analyses over de gevolgen van nieuwbouw en verbouw waar een bestuurder of CIO echt iets mee kan en die ook de toets der kritiek van auditors en anderen kan doorstaan.

The biggest risk is not taking any risk. In a world that is changing really quickly, the only strategy that is guaranteed to fail is not taking risks. (Mark Zuckerberg)

Deze uitsprak kwam in mij op toen ik de column van Chris Verhoef over beheerst vernieuwen las.

In zijn betoog pleit Chris, terecht, ervoor om niet zomaar hele ICT-systemen ineens te vernieuwen. Veel beter is het, zo stelt hij, om stap voor stap te vernieuwen.

En juist daar zit een paradox. Want systemen die stap voor stap te vervangen zijn, die waren daartoe al voldoende op orde. Daar kon je stukjes uithalen en beheerst vernieuwen. Als dat kan, dan moet je vooral niet tot volledige nieuwbouw overgaan. Hoewel, zelfs dat is niet altijd waar. Je kunt prima alle onderdelen van een auto stuk voor stuk vervangen. De ene maand de versnellingsbak, dan de motor, dan het chassis en ga zo maar door. Maar een nieuwe auto is soms echt verstandiger, goedkoper en gaat weer langer mee. En van een auto een heel nieuw vervoersmiddel maken (de drone-auto van Audi en Airbus bijvoorbeeld) door stuk voor stuk de onderdelen te vervangen, het lijkt me nogal lastig.

Juist organisaties die niet snappen dat hun bestaande systemen hun grootste bezit zijn, zijn onvoldoende toegerust voor grootschalige nieuwbouw. Hoe vaak doet men dat, zulke nieuwbouw? Gezien de omvang van dit soort programma’s: nooit! (Chris Verhoef)

Beste Chris, om aan te tonen dat “nooit” niet waar is nodig ik je uit voor een bezoek aan het CIZ. Deze organisatie verving in 2014 haar hele ICT-landschap. Een landschap van meer dan 7000 functiepunten dat in 1 keer vervangen werd. Maar niet onbeheerst. De hele organisatie was betrokken (oh ja, ze gebruikten een “agile” aanpak, één van de buzzwoorden die jij "toeten-nog-blazen-prietpraat" noemt) en elke week werd de gemaakte code tegen het licht gehouden. Niet goed genoeg? Dan opnieuw.

Hoeveel ICT-systemen ken jij die zo blijvend van hoge kwaliteit zijn? Door die aanpak is er nu een ICT-landschap dat elke paar weken, via geautomatiseerd testen, nieuwe functionaliteit in productie kan brengen. Er is aantoonbaar sprake van software van hoge kwaliteit. En, nog belangrijker, een nieuwe wet (voor kenners: de WLZ als opvolger van de AWBZ) kon zonder gedoe in de systemen verwerkt worden.

Ik pleit niet voor onbeheerst risico’s nemen. Maar de tegenhanger “altijd veilig en in kleine stapjes” is in sommige gevallen juist “guaranteed to fail”. De crux wat mij betreft? Van te voren heel goed weten of kleine stapjes mogelijk zijn (daarover hier meer) en als dat niet kan dan juist heel beheerst grote stappen nemen.