Andra

Dit artikel is gericht aan zowel artsen als ontwikkelaars. Voor beide doelgroepen zullen er zaken in dit artikel staan die als voor de hand liggend zullen worden beschouwd. Reacties kunnen geplaatst worden bij een korte versie van het artikel op LinkedIn.

Huisartsen proberen steeds meer informatie over hun patiënten gestructureerd vast te leggen. Denk hierbij aan persoonsgegevens en afspraken, maar ook de voorgeschiedenis van de patiënt en medicatie gegevens. In Nederland zijn er ongeveer twintig zogenaamde Huisarts Informatie Systemen (HIS) in gebruik om dit soort gegevens vast te leggen. In zijn column “Mijn HIS is het best!”[1] roept Rob Dijkstra, bestuursvoorzitter van het Nederlands Huisartsen Genootschap (NHG), de leden van het NHG op samen te werken om de ontwikkeling van die verschillende HIS-en zoveel mogelijk gelijk te trekken. Het doel van Dijkstra’s oproep is om alle HIS-en te verbeteren en informatie beter uitwisselbaar te maken.

Na het lezen van de column vroeg ik me het volgende af: wat zou er gebeuren als de lessen die geleerd zijn bij het ontwikkelen van open source successen als WordPress[2] en Drupal[3], toegepast zouden worden op de ontwikkeling van een open source huisarts informatie systeem?

Traditioneel gezien krijgt een gebruiker van software niet de code van de programmeur te zien, alleen het resultaat ervan. Open source software (OSS) is software waarbij naast het programma ook de broncode beschikbaar wordt gesteld. Hierdoor kan deze code door derden gecontroleerd worden. Er kunnen zelfs verbeteringen of uitbreidingen worden voorgesteld.

Waarom dat nu weer?

Het ontwikkelen van een nieuw, open source HIS biedt de gelegenheid om de sterkste kanten van de verschillende bestaande HIS-en te bundelen. Organisaties als het NHG, de Landelijke Huisartsen Vereniging (LHV) en NedHIS, een belangenorganisatie voor HIS-gebruikers in Nederland, zouden een sterke adviserende rol kunnen spelen, op basis van de ervaringen die zij van hun achterban gemeld krijgen.

Voor we verder gaan is het nodig duidelijk onderscheid te maken tussen een HIS, een elektronisch patiënten dossier en het elektronisch patiënten dossier. Dit voorstel heeft betrekking op de administratie van een huisarts. Hierbij wordt, in de eerste plaats, niet gekeken naar enige koppeling met andere huisartsen of andere collega’s. Het draait om een uniformiteit in de manier waarop huisartsen (ieder voor zich) met hun data omgaan, die de kwaliteit van de zorg ten goede moet komen.

Een HIS is een verschijningsvorm van een elektronisch patiënten dossier. Er wordt tenslotte gebundelde informatie over een patiënt op elektronische wijze vastgelegd. Het heeft echter slechts indirect te maken met het elektronisch patiënten dossier, zoals dat inmiddels de afgelopen jaren in de publiciteit is geweest. Hierover later meer.

In dit artikel verken ik de verschillende aspecten van software ontwikkeling. Daarbij geef ik aan welke eisen een HIS hieraan stelt en welke mogelijkheden het ontwikkelen van een open source HIS zou kunnen bieden. Het voornaamste doel van dit artikel is om het idee voor te leggen aan zowel huisartsen als software ontwikkelaars. Ik probeer daarbij aan te tonen dat de ontwikkeling van een open source HIS wenselijk en, onder de juiste omstandigheden, haalbaar is.

Wie ontwikkelt zoiets?

Kenmerkend voor open source projecten is dat het overgrote deel van de ontwikkelaars geen of slechts een indirect commercieel belang heeft bij de software. De meeste contributers (ontwikkelaars die bijdragen aan het project) hebben vooral een persoonlijke interesse in een goed functionerend product, veelal omdat ze het product zelf willen gebruiken.

In het geval van een HIS is het natuurlijk zo dat de mensen die het product willen gebruiken zelf geen software ontwikkelaars zijn. Van hen kan dus nooit verwacht worden dat ze zelf een HIS ontwikkelen. Maar we kunnen het idee van “persoonlijke interesse” ook breder zien. Vrijwel iedereen in Nederland is ingeschreven bij een huisarts. Alle software ontwikkelaars in Nederland hebben dus een persoonlijk belang bij een goed functionerend, betrouwbaar en flexibel HIS.

Organisatie

De meest succesvolle open source projecten worden geleidt vanuit een centrale organisatie. Het bekendste voorbeeld van zo’n organisatie is de Apache Software Foundation, genoemd naar de open source webserver software waar op het moment van dit schrijven meer dan de helft van alle websites op draaien[4]. Ook projecten als WordPress en Drupal hebben een duidelijke organisatorische structuur, waarin bijvoorbeeld duidelijk is vastgelegd welke ontwikkelaars bepalen of een bijdrage opgenomen wordt in het project.

Ook hebben deze projecten duidelijke doelen en voorwaarden vastgesteld. Een mooi voorbeeld hiervan is de ontwikkelfilosofie uit het Core Contributer Handbook van WordPress[5], waarvan een aantal elementen ook prima van toepassing zouden kunnen zijn op de ontwikkeling van een open source HIS:

• Out of the Box: er moet weinig configuratie nodig zijn om de software in gebruik te kunnen nemen. De installatie van een basis WordPress duurt bijvoorbeeld niet langer dan vijf minuten[6].
• Design for the Majority: het overgrote deel van de eindgebruikers heeft weinig technische kennis, dus dat mag niet nodig zijn om de applicatie te gebruiken.
• Decisions not Options: probeer tijdens de ontwikkeling weloverwogen beslissingen te nemen, in plaats van onnodig veel opties te bieden aan eindgebruikers. In het kader van een HIS komen hier al dan niet vastgelegde standaarden ook bij aan bod.
• Striving for Simplicity: iedere nieuwe versie zou makkelijker moeten zijn om te gebruiken, niet moeilijker.

Critical Mass

Het is lastig om absolute cijfers te vinden, maar voor ieder succesvol project zijn er zeker honderden projecten die een stille dood sterven. Een open source project heeft momentum nodig. Dit betekent dat er een vaste groep ontwikkelaars ontstaat die gezamenlijk regelmatig werken aan het verbeteren en uitbreiden van de code. Een goede organisatie kan, zoals eerder omschreven, dat momentum in stand houden. Een actief en goed lopend project trekt vervolgens steeds nieuwe developers aan.

Maar waar komt dat momentum in de eerste plaats vandaan? In sommige gevallen kan de betrokkenheid van een commerciële partij het project juist op gang helpen. Dit is bijvoorbeeld gebeurd in het geval van Hadoop, een platform om complexe berekeningen op grote hoeveelheden data te verdelen over een cluster van relatief goedkope computers. Het project werd aanvankelijk ontwikkeld als onderdeel van een open source zoekmachine voor Internet Archive. Doug Cutting, de oorspronkelijke ontwikkelaar, werd door Yahoo! in dienst genomen. Men was onder de indruk van het project en besloot Cutting een team te geven om Hadoop verder te ontwikkelen[7]. Inmiddels is Hadoop ondergebracht bij de eerder genoemde Apache Software Foundation. Het wordt gebruikt en verder ontwikkeld door grote namen als Facebook[8], LinkedIn[9] en Twitter[10]. Dit is natuurlijk een extreem voorbeeld, maar illustreert goed dat een commerciële partij weldegelijk betrokken kan zijn bij de ontwikkeling van een open source project en zelfs van groot belang kan zijn. Een belangrijk gegeven hierbij is dat het commerciële belang niet moet liggen in de verkoop van de ontwikkeling, maar in de implementatie of het gebruik ervan. Daarnaast komt het bijdragen aan open source projecten het publieke imago van bedrijven alleen maar ten goede.

“Open source code betaalt zo lastig in de supermarkt…”

Dat de ontwikkelaars van een applicatie geen commerciële belangen hebben bij het project, wil niet zeggen dat er geen handel zit in open source projecten. Zo verhuurt de organisatie van WordPress ruimte om een WordPress website te plaatsen en worden er verschillende betaalde upgrades aangeboden[11]. Red Hat heeft versies van haar besturingssysteem specifiek gericht op het bedrijfsleven[12].

Maar er zijn ook business modellen voor derden. Een open source content management systeem (CMS) als WordPress maakt het makkelijker en sneller om een website te ontwikkelen, maar er is nog steeds technische kennis voor nodig. Bedrijven als Hoppinger en Triquanta ontwikkelen websites die als basis een open source CMS hebben, maar die zowel qua functionaliteit als uiterlijk volledig toegespitst worden op de opdrachtgever.

Ontwikkelaars van de huidige HIS-en of een bedrijf als HIS-Support zouden een vergelijkbare rol kunnen spelen in de implementatie van een open source HIS. Hoewel een open source project zou betekenen dat iedere huisarts in de gelegenheid is om het systeem zelf te implementeren en zelfs naar eigen inzicht te wijzigen, zal vrijwel niemand dit kunnen en zelfs willen. Waar nu handel wordt gedreven in het ontwikkelen en implementeren van twintig verschillende HIS-en, zou op termijn gezamenlijk gewerkt kunnen worden aan één HIS die iedere partij voor haar eigen klanten implementeert.

Het slot ligt op straat, niet de sleutel

Als men kijkt naar de algemene kwaliteit van software, wijst in ieder geval één onderzoek[13] erop dat de kwaliteitsontwikkeling van open source software vergelijkbaar is met die van closed source applicaties.

Een HIS bevat veel gevoelige informatie. Veel mensen verwachten dat als de code van een HIS openbaar is, die kennis ook gebruikt kan worden om ongeoorloofd toegang te krijgen tot die persoonlijke informatie. Het tegenovergestelde zal echter het geval zijn.

Beveiligingssystemen bestaan uit twee onderdelen: een algemene methode en een stuk informatie dat de beveiliging uniek maakt. De methode kan vergeleken worden met een slot en de unieke informatie met de sleutel. In het verleden is verschillende malen geprobeerd om een systeem te beveiligen door de werking van het slot geheim te houden. Dat soort systemen worden vrijwel altijd gebroken, zoals het geval bleek bij de OV-chipkaart[14] en bij Blu-ray schijven[15]. Doordat de methode geheim gehouden wordt, hebben relatief weinig mensen over de methode nagedacht en blijven er vaak zwakheden in de methode achter. Die zwakheden kunnen door derden ontdekt en misbruikt worden.

TrueCrypt is een voorbeeld van een open source beveiligingssysteem. Het wordt gebruikt om harde schijven of delen ervan te beveiligen. TrueCrypt is op dit moment alleen te kraken als de indringer langere tijd fysieke toegang tot de computer zelf heeft en beschikt over forensische software.

Methoden die openbaar zijn, worden door veel meer mensen onderzocht. Slechts een klein deel van deze groep heeft kwade bedoelingen. De rest draagt bij aan het veiliger maken van het systeem. Juist door het systeem openbaar te maken, kun je de data veilig opbergen.

Wie krijgt er toegang?

Een nieuw te ontwikkelen HIS biedt direct de gelegenheid om de koppeling met het Landelijk Schakelpunt (LSP; eerder bekend als het EPD) te implementeren. Het LSP is een systeem dat zorginstellingen, zoals dienstdoende huisartsen of een afdeling Spoed Eisende Hulp (SEH), in staat stelt om actuele medische gegevens op te vragen op het moment dat een patiënt zelf niet in staat is deze te verschaffen.

Het LSP is ontwikkeld en wordt beheerd door CSC Computer Sciences[16]. Daarbij heeft CSC zich ertoe verplicht te zorgen dat bij het gebruik van het LSP de Wet Bescherming Persoonsgegevens (WBP) nageleefd wordt[17]. Daarnaast is de Vereniging van Zorgaanbieders voor Zorgcommunicatie van plan een patiënten portaal te ontwikkelen[18] waarbij de patiënt:

1. Een (email of sms-) bericht ontvangt als zijn gegevens worden opgevraagd.
2. Elektronische inzage kan krijgen in hoe hij staat geregistreerd en welke gegevens door welke zorgaanbieder(s) zijn opgevraagd.
3. Een persoonlijk toestemmingsprofiel kan maken om zo gedifferentieerd toestemming te geven voor gegevensuitwisseling via de zorginfrastructuur.

Ondanks de vergelijkingen met open source webservers en content management systemen, is het wel de bedoeling dat een open source HIS een gesloten systeem is dat lokaal op de praktijk draait, of via een versleutelde verbinding op servers bij een toeleverancier toegankelijk wordt gemaakt.

Gezamenlijk verbeteren

Geloof het of niet, ook programmeren is mensenwerk. Ieder systeem, open source of niet, zal problemen bevatten. Dit kan variëren van een typefout tot het verkeerd begrijpen van de behoeften van de eindgebruikers. Er zijn steeds meer middelen en methoden beschikbaar om dergelijke problemen te beperken, maar het risico blijft altijd bestaan. Vergelijk maar met de spellingscontrole van een tekst verwerker: wanneer je “grip” schrijft, weet het programma niet dat je “griep” bedoelde, omdat beide woorden in het woordenboek staan.

Wanneer alle huisartsen hetzelfde systeem gebruiken, betekent dit ook dat er een grotere groep gebruikers is die problemen kunnen tegenkomen en rapporteren. Het rapporteren van dit soort problemen heeft altijd zin, ook bij closed source systemen. De wetenschap dat jouw melding iedere huisarts in Nederland kan helpen, kan er mogelijk toe leiden dat gebruikers ook actiever gaan melden wat er mis gaat en wat er verbeterd kan worden.

De medische wetenschap staat niet stil. Wet- en regelgeving evenmin. Met een verzameling systemen, ieder met een eigen ontwikkel team, is het maar afwachten wanneer wijzigingen op basis van nieuwe inzichten of regels volledig doorgevoerd worden.

In het geval van één open source HIS kunnen wijzigingen op basis van gemelde problemen of wijzigende regelgeving centraal en eenduidig doorgevoerd worden.

Conclusie

Er zijn genoeg mensen die de lof zingen over open source software. Echter, de meest succesvolle open source projecten hebben een brede toepassing. Ik heb getracht aan te duiden dat open source projecten ook waardevol kunnen zijn voor specifiekere toepassingen, zoals een Huisarts Informatie Systeem. Zoals Dijkstra in zijn column al aangaf, is een kleinere groep gebruikers er juist bij gebaat om de krachten te bundelen.

Discussie

Ieder nieuw systeem roept weerstand en wantrouwen op, zeker als de eindgebruikers maar zeer beperkt inzicht hebben in de aard van het systeem. Dit geldt wellicht nog sterker voor een uitdagend concept als open source software. Ik heb getracht in dit artikel een deel van dat wantrouwen weg te nemen. Verdere discussie en heldere informatie zal moeten leiden tot draagvlak voor dit concept.

De grootste praktische uitdaging voor een open source HIS zal naar mijn idee het begin zijn: wie gaat dit maken? In een ideale wereld slaan de ontwikkelaars van de huidige HIS-en de handen ineen om, geadviseerd door het NHG en de LHV, gezamenlijk het ultieme HIS te ontwikkelen. Daarbij verschuift hun commerciële belang van de ontwikkeling naar de implementatie van HIS-en en het ondersteunen van hun gebruikers.

Verder moet onderzocht worden wat de juridische implicaties zijn van het ontwikkelen en gebruiken van open source software. Wie is precies aansprakelijk op het moment dat een fout in de software leidt tot een probleem in de praktijk? Hierop heb ik nog geen concrete antwoorden kunnen vinden.

Over het algemeen hebben open source projecten al snel een internationaal karakter. De verwijzingen naar organisaties als het NHG en de LHV en een systeem als het Landelijk Schakelpunt geven het idee dat het toch vooral om een Nederlands project zou gaan. Toch zou het voordelig zijn om ook contact te zoeken met vergelijkbare organisaties in het buitenland. Hoe meer partijen bij een dergelijk project betrokken zijn, hoe groter ook het draagvlak voor ontwikkeling is. Om te zorgen dat die niet tot verwatering of versplintering leidt, zullen ook deze partijen alleen een adviserende rol moeten hebben. Op deze manier kan de centrale organisatie van de ontwikkeling zelfstandig en slagvaardig blijven.