EPD contract vaak onvoldoende uitgewerkt
De invoering van het landelijke Elektronisch Patiënten Dossier (EPD) in Nederland houdt de gemoederen in de zorg en de politiek al geruime tijd bezig. Er wordt hevig gediscussieerd over issues als beveiliging, privacy, patiëntenrechten en aansprakelijkheid. Dát het EPD er komt is echter wel duidelijk en de meeste ziekenhuizen en zorginstellingen zijn momenteel dan ook al bezig met de invoering van een EPD softwarepakket, vaak in combinatie met een nieuw Ziekenhuis Informatie Systeem (ZIS). Dergelijke projecten worden wel vergeleken met een hart-long-lever transplantatie, omdat alle vitale werkprocessen van het ziekenhuis erdoor geraakt worden. Terecht, want het zijn omvangrijke, langdurige, kostbare en risicovolle projecten, waarin leverancier en opdrachtgever intensief zullen moeten samenwerken. In de praktijk zien wij vaak dat het contract bij deze projecten niet de aandacht krijgt die het verdient.
Met dank aan Theo Bosboom en Ernst-Jan van de Pas, Dirkzwager advocaten
Na een lang voortraject waarin eindelijk de keuze is gemaakt voor een bepaalde leverancier, willen partijen meestal graag zo snel mogelijk aan de slag en wordt er onvoldoende tijd genomen om de afspraken goed uit te werken en vast te leggen. In veel gevallen is het contract te eenzijdig in het voordeel van de leverancier, bijvoorbeeld omdat op basis van de algemene voorwaarden van de leverancier of de ICT~Office voorwaarden wordt gecontracteerd. Ook wordt nogal eens volstaan met een standaard IT-contract, dat onvoldoende aansluit bij het ingrijpende traject dat partijen met elkaar aangaan. Het spreekt voor zich dat dit grote risico’s met zich meebrengt. Dit geldt met name voor het ziekenhuis, dat na de invoering in grote mate afhankelijk zal worden van de goede werking van het EPD en dus van de leverancier. In dit artikel zullen we aantal pijnpunten uit de praktijk benoemen en bespreken.
Hét EPD-pakket bestaat niet: weet wat u koopt!
Het opstellen van zo duidelijk en volledig mogelijke specificaties voor het EPD is een absolute must. Dit is natuurlijk een open deur, maar in de praktijk zien we nog steeds ziekenhuizen die onvoldoende nagaan wat ze eigenlijk nodig hebben en daardoor een product kopen dat (nog) niet geschikt is voor hun organisatie. Daarbij komt ook geregeld voor dat bepaalde specialisaties binnen het ziekenhuis te weinig of juist te veel betrokken zijn bij het opstellen van de specificaties, waardoor de specificaties onvolledig en/of onevenwichtig zijn. Een goed uitgebalanceerd intern projectteam is dan ook zeer belangrijk voor het verzamelen en opstellen van de relevante specificaties voor het EPD.
Onduidelijke of onvolledige specificaties leiden later onherroepelijk tot discussies over de prijs en de vraag of het EPD na oplevering wel of niet voldoet aan de gestelde eisen. Specificaties vormen immers de lat waarlangs de software tijdens de acceptatietests moet worden gelegd.
Overigens zal er bij dit soort complexe projecten bijna altijd wel sprake zijn van enig voortschrijdend inzicht, waardoor de specificaties moeten worden bijgesteld. In het contract zal dan ook een werkbare procedure moeten worden opgenomen over meerwerk. Zo zou bepaald kunnen worden dat de leverancier pas meerwerk mag verrichten als daar een door het ziekenhuis schriftelijke opdracht aan ten grondslag ligt, die is gebaseerd op een gespecificeerde kostenbegroting. Zodoende houdt het ziekenhuis grip op de meerkosten en kan de leverancier zijn extra werkzaamheden toch facturen.
Wanneer de aankoop van een EPD wel zorgvuldig wordt voorbereid aan de hand van lijsten met concrete eisen en wensen en verschillenanalyses, speelt er nog een ander belangrijk risico. In die situaties kan het bij de contracteerfase alsnog helemaal misgaan, omdat die prachtige specificaties in het contract (vaak onbewust) subtiel naar de prullenbak worden verwezen. Dit kan bijvoorbeeld door een bepaling als: “de leverancier garandeert dat de software zal voldoen aan de documentatie”, in combinatie met een andere bepaling die aangeeft dat de leverancier geen verdere garanties verstrekt ten aanzien van de werking van het EPD. Als met “documentatie” alleen de standaard gebruikshandleiding van de leverancier wordt bedoeld en er niet expliciet wordt verwezen naar de stukken uit het voortraject, loopt het ziekenhuis het risico dat zij zich juridisch niet meer kan beroepen op de in die stukken vastgelegde specificaties en beloftes. In een goed EPD-contract zal dus een duidelijke koppeling moeten worden aangebracht naar die specificaties uit het voortraject.
Houd grip op het project
Zoals gezegd is de invoering van een EPD binnen een ziekenhuis bepaald geen sinecure. Het goed managen van een dergelijk complex project is niet eenvoudig. Partijen gaan vaak een traject van jaren in, waarbij er zich ongetwijfeld tegenslagen en onvoorziene omstandigheden gaan voordoen. Het contract moet hierbij geen bron van discussies en irritaties zijn, maar geeft idealiter een duidelijke leidraad voor de organisatie van het project en het oplossen van meningsverschillen. Dit betekent dat het een uitgebalanceerd contract moet zijn, waarin evenwichtige procedures en regels zijn opgenomen en waarin de projectorganisatie duidelijk is uitgewerkt.
Het ziekenhuis zal zich terdege moeten realiseren dat de implementatie van een EPD – meer nog dan bij de implementatie van andere software – ook een forse inspanning van zijn eigen organisatie zal vergen. Er zullen voldoende specialisten moeten worden gemobiliseerd voor het opstellen van specificaties en het inrichten en testen van de software. Dit is niet altijd eenvoudig, door de drukte en hectiek van alledag en door de specifieke zeggenschapsverhoudingen binnen een ziekenhuis. Hier gaat het in de praktijk nogal eens mis, wat tot vertraging van het project kan leiden. Die vertraging kan dan gelijk fors oplopen, omdat de leverancier in de regel meerdere implementatietrajecten tegelijk heeft lopen en zijn mensen vaak al vele maanden vooruit heeft ingepland bij andere opdrachtgevers. Een verzoek om een uitstel van slechts twee weken van het ziekenhuis kan daardoor tot gevolg hebben dat er een volledig nieuwe planning zal moeten worden gemaakt en dat er gelijk een vertraging van vele maanden optreedt.
In het contract zal met dit alles rekening moeten worden gehouden. Uiteraard moeten er heldere afspraken worden gemaakt over verdeling van verantwoordelijkheden en oplevertermijnen, eventueel versterkt met boetes of incentives. Opdrachtgevers doen er verstandig aan om de betrokken specialisten en maatschappen binnen het ziekenhuis te laten tekenen voor hun commitment aan het project en voor het tijdig leveren van de afgesproken inzet. Indien er onzekerheid blijft bestaan over de vraag of deadlines intern kunnen worden gehaald, kan worden geprobeerd in het contract met de leverancier wat flexibiliteit te creëren en bijvoorbeeld te bepalen dat termijnen door de opdrachtgever mogen worden verschoven met een bepaald aantal weken, zonder dat dit gevolgen heeft voor de totale doorlooptijd van het project. Hieraan kunnen uiteraard wel extra kosten verbonden zijn, maar die zijn soms te verkiezen boven een forse uitloop van het project.
Enkele juridische aandachtspunten bij ASP en SaaS
Ook bij dit soort projecten raken ASP en SaaS-constructies steeds meer in trek. Daarbij kan het gaan om het uitbesteden van het onderhoud of beheer van het pakket aan een derde of de hosting van het pakket en de data bij een derde. Dit brengt belangrijke juridische aandachtspunten met zich mee, waarvan wij enkele hieronder aanstippen.
ASP/SaaS-constructies leiden tot een hoge afhankelijkheid van het ziekenhuis van de continuïteit en de kwaliteit van dienstverlening van de leverancier (vendor lock-in). Wat gebeurt er vervolgens als die dienstverlening hapert? Men kan in een ziekenhuis simpelweg niet werken zonder dat het EPD en/of de daarin opgeslagen data beschikbaar is. Dit betekent niet alleen dat er een goede SLA nodig is, in combinatie met speciaal op ASP/SaaS toegesneden escrow- en noodregelingen voor faillissement of andere calamiteiten, maar ook dat er goede fysieke uitwijk– en backupvoorzieningen worden ingericht zodat het EPD en de daarin opgeslagen data bij uitval en storingen beschikbaar blijft voor het ziekenhuis.
Als het EPD gehost gaat worden door een derde, moet rekening worden gehouden met de Wet geneeskundige behandelingsovereenkomst (WGBO) en de Wet bescherming persoonsgegevens (WBP). Er worden dan namelijk bijzondere persoonsgegevens (gezondheidsgegevens) verwerkt buiten het ziekenhuis en door een derde partij. Genoemde wetten stellen zware eisen aan bijvoorbeeld de beveiliging en geheimhouding van die gegevens. Die eisen zullen goed moeten worden geborgd in het hostingcontract. In sommige gevallen zal zelfs de vraag moeten worden gesteld of er toestemming nodig is van de patiënten voor de gekozen constructie.
Ook zal moeten worden nagegaan of een ASP/SaaS-constructie wel wordt toegestaan door de leverancier(s) van de EPD-software, indien dit niet de partij is die de ASP/SaaS-diensten verricht. Veel licentiemodellen verbieden dat de software buiten de instelling van de klant wordt gebruikt of beheerd. Leveranciers staan er over het algemeen niet op te springen om een derde bepaalde onderhouds- of beheerwerkzaamheden te laten verrichten aan hun software.
Verder zal goed moeten worden nagedacht over een exit regeling, waarin de gevolgen worden geregeld als het contract met de derde wordt beëindigd en het ziekenhuis wil overstappen naar een ander systeem. Denk bijvoorbeeld aan afspraken over de migratie en conversie van data naar dat nieuwe systeem of aan een afspraak dat het ziekenhuis het oude systeem nog zolang mag gebruiken – tegen de eerder afgesproken tarieven – totdat het nieuwe systeem helemaal klaar is.
Dit artikel van Theo Bosboom en Ernst-Jan van de Pas is ook gepubliceerd in de Automatiseringgids 1/2010.
Dit bericht is oorspronkelijk verschenen op https://dirkzwagerieit.nl/2010/03/01/epd-contract-vaak-onvoldoende-uitgewerkt/
