ECLI:NL:RBOBR:2016:3387

vonnis RECHTBANK OOST-BRABANT Handelsrecht Zittingsplaats 's-Hertogenbosch zaaknummer / rolnummer: C/01/261623 / HA ZA 13-257 Vonnis in hoofdzaak en in incident van 29 juni 2016 in de zaak van

1. de besloten vennootschap met beperkte aansprakelijkheid ALERT LIFE SCIENCES COMPUTING B.V., gevestigd te Utrecht, hierna te noemen Alert NL,
2. de rechtspersoon naar Portugees recht ALERT LIFE SCIENCES COMPUTING S.A., gevestigd te Vila Nova de Gaia (Portugal), hierna te noemen Alert PT, eiseressen in conventie, verweersters in reconventie, eiseressen in het incident, advocaat mr. F. van der Woude te Amsterdam, tegen
3. de stichting STICHTING JEROEN BOSCH ZIEKENHUIS, gevestigd te 's-Hertogenbosch, gedaagde in conventie, verweerster in het incident, hierna te noemen JBZ, advocaat mr. drs. H.J.S.M. Langbroek te Den Haag,
4. de stichting STICHTING ZIEKENHUIS BERNHOVEN, voorheen gevestigd te Oss, thans te Uden, gedaagde in conventie, eiseres in reconventie, hierna te noemen Bernhoven, advocaat aanvankelijk mr. F.A.M. Knüppe, thans mr. E.J. van de Pas te Arnhem,
5. de stichting STICHTING ATRIUM-ORBIS MEDISCH CENTRUM, rechtsopvolgster van STICHTING ATRIUM MEDISCH CENTRUM PARKSTAD, gevestigd te Heerlen, gedaagde in conventie, eiseres in reconventie, hierna te noemen Atrium, advocaat mr. J.M.W. Werker te Arnhem,
6. de coöperatie met uitgesloten aansprakelijkheid COÖPERATIE ZANOB U.A., als rechtsopvolger van Stichting Ziekenhuisapotheek Noord-Oost Brabant, gevestigd te 's-Hertogenbosch, gedaagde in conventie, eiseres in reconventie, hierna te noemen ZANOB, advocaat aanvankelijk mr. F.A.M. Knüppe, thans mr. E.J. van de Pas te Arnhem,
7. de stichting STICHTING TWEESTEDEN ZIEKENHUIS, gevestigd te Tilburg, gedaagde in conventie, hierna te noemen TSZ, advocaat aanvankelijk mr. F.A.M. Knüppe, thans mr. E.J. van de Pas te Arnhem. Eiseressen in conventie zullen hierna gezamenlijk worden aangeduid met het enkelvoud Alert. Gedaagden in conventie zullen hierna gezamenlijk worden aangeduid met “de ziekenhuizen”, ook al exploiteert ZANOB geen ziekenhuis. 1De procedure 1.
8. Het verloop van de procedure blijkt uit: het tussenvonnis van 16 april 2014 de akte overlegging productie 201 van Alert JBZ de akte overlegging producties van Alert de akte overlegging producties van JBZ het proces-verbaal van comparitie van 13 maart 2015 de incidentele conclusie inhoudende een vordering ex art. 843a Rv van Alert (genomen op de comparitie) de antwoordconclusie in het 843a Rv incident, tevens antwoordakte wijziging grondslag eis van JBZ Bernhoven de conclusie van antwoord in reconventie de akte overlegging producties van Bernhoven het proces-verbaal van comparitie van 29 januari 2015 Atrium - de conclusie van antwoord in reconventie - de akte overlegging aanvullende producties van Atrium (met producties 72 tot en met 86) de akte correctie, uitbreiding bewijsaanbod en bespreekpunten ten behoeve van de comparitiezitting van Atrium de akte overlegging aanvullende producties ten behoeve van de comparities van Atrium (met producties 87 tot en met 91) het proces-verbaal van comparitie van 5 februari 2015 ZANOB de conclusie van antwoord in reconventie het proces-verbaal van comparitie van 12 februari 2015 TSZ De rechtbank heeft de comparitie in de zaak tussen Alert en TSZ op verzoek van die partijen uitgesteld tot na het arrest in de appelprocedure tussen Alert en TSZ. Het gerechtshof ’s‑Hertogenbosch heeft bij arrest van 3 november 2015 een deskundigenbericht gelast en in dat kader bij arrest van 23 februari 2016 een comparitie van partijen bevolen. Op verzoek van Alert en TSZ heeft de rechtbank daarna opnieuw de comparitie aangehouden. 1.
9. Ten slotte is vonnis bepaald in het incident ten aanzien van JBZ en in de hoofdzaak ten aanzien van JBZ, Bernhoven, Atrium en ZANOB. 1.
10. Vervolgens is mr. Crombeen, lid van de meervoudige kamer dat alle vier zittingen van de comparitie van partijen ter zake JBZ, Bernhoven, Atrium en ZANOB heeft bijgewoond, wegens ziekte langdurig uitgevallen. De rechtbank heeft aanvankelijk herstel afgewacht, maar uiteindelijk mr. Crombeen vervangen door mr. Bartels. De rechtbank heeft partijen schriftelijk over die vervanging ingelicht. Geen van partijen heeft daarna om een nieuwe mondelinge behandeling verzocht. Alert heeft wel verzocht om het vonnis aan te houden tot na het herstel van mr. Crombeen, maar dat verzoek heeft de rechtbank afgewezen omdat er geen zicht was op herstel op korte termijn en verdere aanhouding tot een onredelijke vertraging van de procedure zou leiden. 2De feiten (algemeen) 2.
11. Hierna vermeldt de rechtbank algemene feiten die zij vaststelt ten aanzien van JBZ, Bernhoven, Atrium en ZANOB. Om een beter beeld van de kwestie te kunnen schetsen, heeft de rechtbank ook feiten verwerkt over het verloop van de projecten bij de individuele ziekenhuizen. Deze laatste feiten zullen niet worden gebruikt bij de beoordeling van de zaken tussen Alert en de andere ziekenhuizen. Later in dit vonnis zal de rechtbank nog nadere feiten per ziekenhuis vaststellen. 2.
12. Alert PT houdt zich bezig met het ontwikkelen, leveren en onderhouden van software ten behoeve van de gezondheidszorg. Voor ziekenhuizen biedt zij onder de naam “Alert® PFH” een integraal ICT-systeem bestaande uit een ziekenhuisinformatiesysteem (ZIS) en een elektronisch patiëntendossier van de derde generatie (EPD) aan. Met dit ICT-systeem worden alle zorgprocessen - zoals klinische documentatie, medische orders, verslaglegging, planning, rapportages en facturatie - gedigitaliseerd en ontstaat uiteindelijk een papierloze omgeving (‘paper free hospital’). De software van Alert bestaat uit verschillende, onderling koppelbare modules. De belangrijkste modules van Alert® PFH zijn EDIS voor de Spoedeisende Hulp (SEH), ORIS voor de Operatiekamer, Inpatient voor de verpleegafdelingen en Outpatient voor de poliklinieken. Daarnaast biedt Alert PT onder de naam “Alert® Pharmacy”, een Ziekenhuis Apotheek Informatie Systeem (ZAIS) voor ziekenhuisapotheken. 2.
13. Alert PT heeft klanten in Portugal, Brazilië en diverse andere landen verspreid over de wereld. Zij biedt Alert® PFH en Alert® Pharmacy aan als standaardsoftware. Individuele eisen of wensen van klanten kunnen echter in Alert® PHF en Alert® Pharmacy worden verwerkt, indien en voor zover Alert PT die een zinvolle aanvulling op haar standaardsoftware acht. Daartoe wordt eerst een zgn. gapanalyse gemaakt, waarbij in hoofdlijnen wordt vastgesteld welke door de klant gevraagde functionaliteiten ontbreken. Vervolgens worden zgn. “AS IS” documenten vastgesteld, waarin de huidige werkwijze van de klant wordt beschreven. Daarna worden zgn. “TO BE” documenten vastgesteld, waarin wordt beschreven hoe Alert de nieuwe functionaliteiten in haar standaardsoftware wil verwerken. Nadat die AS IS en TO BE documenten door de klant zijn goedgekeurd, maakt Alert zgn. “Drawings”, waarin de nieuwe functionaliteiten in detail zijn uitgewerkt. Nadat ook die Drawings door de klant zijn goedgekeurd, ontwikkelt Alert PT de nieuwe functionaliteiten. Na de release van de versie waarin de nieuwe functionaliteiten zijn opgenomen, wordt die versie door de klant getest in drie testronden. De klant meldt aan Alert de “issues” die bij de eerste testronde zijn geconstateerd. De rechtbank zal dat begrip “issues” hanteren als een verzamelnaam voor foutmeldingen (de software werkt niet naar behoren), voor meldingen van ontbrekende functionaliteiten die contractueel wel aanwezig hadden moeten zijn, en voor pas na tests kenbaar gemaakte wensen van het ziekenhuis over nieuwe functionaliteiten en aanpassing van bestaande functionaliteiten. Indien sprake is van “blocking issues” (issues die in de visie van de klant moeten zijn opgelost voordat goedkeuring kan worden gegeven aan de software en deze vervolgens wordt geaccepteerd), brengt Alert een herstelversie uit, waarna een tweede testronde volgt. Als er daarna nog steeds sprake is van blocking issues, volgt een nieuwe herstelversie en een derde testronde. Na acceptatie door de klant kan de software door de klant in gebruik worden genomen. De nieuwe versie van de software met nieuwe functionaliteiten die op verzoek van een individuele klant zijn aangebracht, wordt door Alert ook aan al haar andere klanten in de wereld ter beschikking gesteld. Die andere klanten hebben de keuze om de nieuwe functionaliteiten al dan niet te activeren. 2.
14. In 2007 besloot Alert PT om zich op de Nederlandse markt te gaan richten. Dat betekende dat Alert PT haar software geschikt moest maken voor de Nederlandse markt (bijvoorbeeld moest de software voorzien in het Nederlandse DBC-systeem voor de declaratie van medische verrichtingen bij zorgverzekeraars, dat per 1 januari 2012 is verbeterd middels het zgn. DOT-systeem). Daarnaast moest een organisatie worden ingericht die zich bezig zou gaan houden met de implementatie in Nederland van de door Alert PT in Portugal ontwikkelde software. Alert PT verkreeg daartoe een meerderheidsaandeel in Orcinus B.V., waarvan de naam werd gewijzigd in Alert NL. De [bestuurder van Alert] (hierna [bestuurder van Alert] ) is thans statutair bestuurder van Alert PT en van Alert NL. 2.
15. Onder implementatie wordt verstaan alle activiteiten die nodig zijn om software in gebruik te kunnen nemen, waaronder in ieder geval valt: - het aanpassen van hardware - het installeren van de software op de nieuwe hardware - het configureren en parametriseren van de software, waarbij onder meer gegevens van de klant worden ingevoerd, gebruikers worden ingevoerd met hun bevoegdheden, instellingen worden aangepast zoals door de klant gewenst en door de klant aangeleverde “content” wordt verwerkt (details zoals typen afspraken (tussen patiënt en zorgverlener) die in Alert® voor iedere klant anders kunnen worden ingericht) - het migreren van data uit het oude ICT systeem naar het nieuwe ICT systeem (bij de meeste projecten geheel of gedeeltelijk verzorgd door het ziekenhuis zelf) - het opleiden van gebruikers. 2.
16. Alert sloot raamovereenkomsten met JBZ, Bernhoven, Atrium, ZANOB en TSZ. Bij deze Nederlandse klanten zette Alert “on site” teams in, die in de ziekenhuizen aanwezig waren voor de implementatie en ook ondersteuning konden bieden aan de medewerkers van de ziekenhuizen bij de werkzaamheden die door de ziekenhuizen zelf moesten worden verricht, zoals het testen van de software. Die on site teams bestonden zowel uit Nederlandse werknemers van Alert NL als Portugese werknemers van Alert PT. Daarnaast was Alert vertegenwoordigd in stuurgroepen (met o.a. vertegenwoordigers van het bestuur van Alert en het ziekenhuis), projectmanagementteams (met o.a. projectmanagers van het ziekenhuis, Alert PT en in de beginfase ook Alert NL) en werkgroepen (met medewerkers van het ziekenhuis en van Alert). Bij elk ziekenhuis zijn andere namen voor deze groepen gehanteerd. Bij Atrium ontbrak een stuurgroep en nam Alert niet deel aan het projectmanagementteam, dat stuurgroep werd genoemd. 2.
17. JBZ was het eerste ziekenhuis in Nederland dat voor Alert® PFH koos. JBZ exploiteerde op dat moment drie ziekenhuizen in ’s‑Hertogenbosch, die in de eerste helft van 2011 zouden verhuizen naar nieuwbouw op één locatie waarin JBZ papiervrij wilde gaan werken. Alert en JBZ sloten op 16 juli 2008 een raamovereenkomst over de levering onder licentie, de implementatie en het onderhoud van Alert® PFH. 2.
18. Er werd een gapanalyse uitgevoerd om vast te stellen welke functionaliteiten moesten worden ontwikkeld om de software in het algemeen geschikt te maken voor de Nederlandse zorgmarkt en welke functionaliteiten moesten worden ontwikkeld om te voldoen aan de individuele eisen en wensen van JBZ die Alert geschikt achtte voor haar standaardproduct. Alert ontwikkelde voor JBZ een “roadmap” waarin Alert aangaf in welke versie van Alert® PFH zij welke van deze nog ontbrekende functionaliteiten zou opnemen en wanneer de release van deze versies zou plaatsvinden. Toen Alert later met Bernhoven en Atrium contracteerde, voegde zij aan de voor JBZ geplande versies nieuwe functionaliteiten toe ter voldoening aan de individuele eisen en wensen van Bernhoven en Atrium. De individuele eisen en wensen van TSZ werden opgenomen in een nieuwe versie aansluitend op de versies voor JBZ, Bernhoven en Atrium. Daardoor ontstond feitelijk een algemene Alert® PFH-roadmap voor Nederland, al verstrekte Alert die niet aan al haar Nederlandse klanten. Alert verstrekte (ook) individuele roadmaps aan haar nieuwe Nederlandse klanten waarin was vermeld in welke versies zou worden voldaan aan de individuele eisen en wensen van dat ziekenhuis. Voor Alert® Pharmacy voor ZANOB werd een eigen roadmap gemaakt, al werd die later wel aangesloten op de roadmap voor Alert® PFH. 2.
19. In de loop der tijd gaf Alert nieuwe nummers aan de voorziene versies, splitste zij versies en voegde zij nieuwe versies toe. Het volgende overzicht van versienummers is gebaseerd op de gegevens uit het dossier van JBZ, aangevuld met gegevens uit de andere dossiers: Februari 2008 15 april 2009 29 april 2009 2010 en 2011 2.4.3 Laatste versie ontwikkeld voor andere landen 1) 2.4.4 2.5.0 2.5.1 2.5.2 2.5.0 2.5.1 2.5.2 2.5.0 2.5.1 2.5.2 2) 2.4.5 2.6 2.6.0 2.6.0.0 2.6.0.1 2.6.0.2 2.6.0.3 2.6.0.4 2.6.0.5 3) 2.4.6 3.0 2.6.1 2.6.1 2.6.1.1 (Pharmacy v.1.0) 2.6.1.2 (Pharmacy v.2.0) 2.6.2 (TSZ) 4) 2.4.7 2.4.8 3.1 3.0 3.0 2.
20. In de voor JBZ gemaakte roadmap van februari 2008 en het Project Plan v.1.0 van mei 2008 was het nog de bedoeling dat Alert in het tweede kwartaal van 2008 zou starten met de ontwikkeling van v.2.4.4 (later v.2.5), maar bij de ondertekening van de raamovereenkomst tussen Alert en JBZ half juli 2008 was al duidelijk dat die roadmap zou worden vervangen. In oktober 2008 werd een nieuw Project Plan v.1.10 vastgesteld, waarin was opgenomen dat de start van de ontwikkeling was uitgesteld tot diezelfde maand. Volgens deze planning zou de “Go Live” (het daadwerkelijk in gebruik nemen van de software in het ziekenhuis) bij JBZ plaatsvinden na de release van v.2.4.6, die op 28 februari 2010 was gepland. De Go Live zou op 3 mei 2010 starten met de SEH, direct gevolgd door de Go Live bij steeds andere (groepen van) afdelingen. De Go Live bij JBZ zou dan zijn voltooid voor de verhuizing naar de nieuwbouw, die volgens de planning toen nog in maart 2011 zou plaatsvinden maar uiteindelijk op 15 april 2011 startte. Vanwege vertragingen in de releases stelde Alert eind april 2009 voor om v.2.4.6 te splitsen en het deel daarvan dat JBZ nodig had voor de Go Live, te verhuizen naar v.2.6.0; het restant werd opgenomen in v.2.6.
21. JBZ stemde hiermee in omdat zij daardoor toch op 3 mei 2010 kon starten met de Go Live, nu met v.2.6.
22. In december 2009 bleek sprake van nieuwe vertragingen, waarna JBZ besloot om de Go Live uit te stellen tot na de verhuizing. In juli 2010 werden Alert en JBZ het erover eens dat JBZ Live zou gaan met v.2.6.0.3 (v.2.6.0 was inmiddels in meerdere versies gesplitst) en dat de Go Live bij JBZ zou starten op 15 april 2011, de dag van de start van de verhuizing naar de nieuwbouw, zodat de SEH al direct papiervrij zou kunnen werken. De release van v.2.6.0.3 vond plaats in augustus/september 2010, maar het duurde tot december 2010 voordat een stabiele versie op de testomgeving van JBZ was geïnstalleerd en was ingericht voor het testen, zodat pas in januari 2011 werd gestart met de eerste testronde. In februari 2011 bracht JBZ een voorlopig testrapport uit, waarin veel issues waaronder ook blocking issues werden gemeld. Alert meende dat een deel van de issues ten onrechte was gemeld, maar gaf aan dat het aantal wel terecht gemelde issues niet acceptabel was. Ondertussen had JBZ in januari 2011 voorgesteld om de start van de Go Live uit te stellen tot 1 oktober 2011, waarna zij in maart 2011 voorstelde om die start verder uit te stellen tot 1 februari
23. Alert maakte daartegen bezwaar vanwege de commerciële en financiële consequenties voor haar van een dergelijk uitstel (in de raamovereenkomst was opgenomen dat een belangrijk deel van de betalingen pas opeisbaar zou worden na de acceptatie door JBZ, die bij dit voorstel eveneens werd uitgesteld). In verband met de eerdere vertragingen in het project had JBZ in juni 2010 en november 2010 echter al voorschotten aan Alert betaald op facturen die pas later opeisbaar zouden worden, waartegenover Alert bankgaranties had verstrekt. Alert en JBZ startten onderhandelingen over de financiële voorwaarden waaronder Alert aan het door JBZ gevraagde uitstel zou willen meewerken. Die onderhandelingen werden door JBZ opgeschort nadat [bestuurder van Alert] op 30 maart 2011 aan JBZ meedeelde dat de [voormalig manager Alert] , die tot kort daarvoor manager van Alert NL was, niet meer werkzaam was voor Alert NL. Het vertrek van [voormalig manager Alert] kwam ook aan de orde tijdens een bespreking van JBZ, Bernhoven, Atrium en TSZ op 31 maart 2011 (ZANOB nam daaraan niet deel), waarin de vier ziekenhuizen besloten gezamenlijk actie te ondernemen. Alert en JBZ onderhandelden daarna nog wel over de financiële voorwaarden van Alert voor het door JBZ gevraagde uitstel, maar zij werden het niet eens. JBZ bracht op 8 juni 2011 nog een definitief testrapport over de eerste testronde uit waarin de software werd afgekeurd, maar de tweede testronde vond niet plaats in verband met de gezamenlijke actie van de ziekenhuizen, die later zal worden besproken. 2.
24. Op 21 november 2008 dan wel 11 december 2008 (de op pagina 38 vermelde datum van ondertekening) sloot Alert een raamovereenkomst met Bernhoven, haar tweede Nederlandse klant. Bernhoven exploiteerde ziekenhuizen in Veghel en Oss, die zij wilde verhuizen naar nieuwbouw in Uden, waar zij papiervrij wilde gaan werken. Die verhuizing zou aanvankelijk in 2012 plaatsvinden maar vond uiteindelijk plaats op 1 april
25. Bernhoven koos ervoor om eerst Live te gaan op alleen de SEH, en wel direct na de release van v.2.4.4 (later v.2.5), die toen was gepland op 30 april
26. De Go Live op de andere afdelingen zou dan later na andere releases gefaseerd moeten plaatsvinden en eind 2011 moeten zijn voltooid. De rechtbank begrijpt dat in v.2.5 nog niet alle functionaliteiten zouden zitten die Bernhoven voor de SEH wilde, zodat de SEH Live zou gaan met een beperkte versie van EDIS die in latere releases zou worden uitgebreid. Na vertragingen in de release van v.2.4.4/v.2.5 werd besloten de Go Live op de SEH van Bernhoven uit te stellen tot de eerste week van februari
27. Alert bracht releases uit van meerdere varianten van de module EDIS in v.2.5.0, die door Bernhoven werden getest. Naar aanleiding van die testen meldde Bernhoven issues. Niet alle door Bernhoven gemelde issues konden tijdig door Alert worden opgelost. Ook kon de datamigratie niet tijdig worden voltooid en waren nog niet de interfaces beschikbaar waarmee de module EDIS zou moeten communiceren met de software van de afdelingen Laboratorium en Radiologie. Desondanks besloot Bernhoven toch begin februari 2010 Live te gaan op de SEH met de module EDIS v.2.5.0.7.
28. Na die Go Live ontstond grote ontevredenheid op de werkvloer. Alert en Bernhoven namen een aantal maatregelen om die ontevredenheid weg te nemen. Er werd een tien punten plan opgesteld met tien issues die prioriteit zouden krijgen, waaronder de medische rapportage. Bij diverse afdelingen van Bernhoven bleef echter ontevredenheid bestaan over de medische rapportage van de SEH in Alert® PFH. Op 7 december 2010 deelde Bernhoven aan Alert mee dat zij had besloten om weer met papieren dossiers te gaan werken, maar dat zij wel beperkt in Alert® PFH zou blijven registeren in afwachting van een herstart op de SEH met v.2.6.0.5 eind maart 2011 (de rechtbank begrijpt dat Bernhoven die herstart pas wilde uitvoeren nadat extra functionaliteiten voor de SEH beschikbaar zouden komen). Bernhoven zond daarna aan Alert lijsten van issues die moesten worden opgelost om voldoende commitment voor de herstart te creëren binnen de afdeling SEH. Toen op 31 maart 2011 de bespreking van de vier ziekenhuizen over de gezamenlijke actie plaatsvond, waren nog niet al die issues opgelost, was de datamigratie nog niet voltooid en waren de interfaces met Laboratorium en Radiologie nog niet beschikbaar. Ook na de start van die gezamenlijke actie werkten Alert en Bernhoven door aan de herstart, die een aantal malen werd uitgesteld. In september 2011, toen voltooiing van de Go Live op alle afdelingen van Bernhoven vóór de verhuizing in gevaar was gekomen, spraken Alert en Bernhoven over een alternatief scenario waarbij alleen een basisversie van Alert® PFH bij Bernhoven zou worden geïnstalleerd, waarmee Bernhoven nog voor de verhuizing papiervrij zou kunnen gaan werken, en pas later de volledige versie van Alert® PFH. Dat alternatief scenario is er nooit gekomen vanwege de ontwikkelingen bij de gezamenlijke actie van de ziekenhuizen. 2.
29. Op 25 mei 2009 sloot Alert een raamovereenkomst met Atrium, haar derde Nederlandse klant. Atrium exploiteerde ziekenhuizen in Heerlen, Brunssum en Kerkrade. Ook Atrium had nieuwbouwplannen, maar die kon zij in dit stadium nog niet realiseren. Atrium had echter wel te maken met een ander soort toekomstige gebeurtenis, omdat een door haar nog gebruikte informatiesysteem vanaf 1 januari 2012 niet meer zou worden ondersteund. Volgens een planning uit mei 2010 zou Atrium Live gaan met v.2.6.0 (dat werd v.2.6.0.3 vanwege de splitsing van v.2.6.0), te beginnen met Outpatient op de poliklinieken op 20 september
30. De Go Live op de andere afdelingen zou zijn voltooid in september
31. Atrium voerde informele tests uit van v.2.6.0.1 en v.2.6.0.2, waarbij diverse issues bleken. Toen duidelijk werd dat de Go Live Outpatient op 20 september 2010 niet meer haalbaar was, werd een nieuwe planning gemaakt, waarbij deze Go Live werd uitgesteld tot 21 maart
32. Na de release van v.2.6.0.3.4 startte Atrium conform die laatste planning op 7 december 2010 met de formele contractuele eerste testronde, waarbij issues waaronder blocking issues werden geconstateerd. Alert bracht de herstelversie v.2.6.0.3.5 uit, waarna Atrium op 18 januari 2011 startte met de tweede testronde. Ook na die tweede testronde was sprake van blocking issues. De Go Live op 21 maart 2011 was daardoor niet meer haalbaar. Na de release van de herstelversie v.2.6.0.3.5.3 startte Atrium op 22 maart 2011 met de derde testronde. Die derde testronde was nog bezig toen de verhoudingen tussen Alert en Atrium verstoord raakten. Atrium had net als JBZ een voorschot aan Alert verstrekt op een factuur die pas later opeisbaar zou worden. Alert had daarvoor een bankgarantie verstrekt met uiteindelijk als einddatum 1 april
33. Eind maart 2011 onderhandelde [voormalig manager Alert] namens Alert met Atrium over een addendum op de raamovereenkomst over een nieuwe bankgarantie. Die onderhandelingen waren in een ver gevorderd stadium, toen [voormalig manager Alert] in het weekend van 26 en 27 maart 2011 ontslag nam bij Alert vanwege een conflict met [bestuurder van Alert] . De onderhandelingen werden overgenomen door [bestuurder van Alert] , die een al door [voormalig manager Alert] (mondeling) goedgekeurd concept addendum over de bankgarantie aanvankelijk afkeurde. Atrium stelde daarna voorwaarden aan Alert voor het aangaan van het addendum, onder andere betreffende door [bestuurder van Alert] te verstrekken informatie. [bestuurder van Alert] verschafte informatie aan Atrium waarmee hij meende aan de voorwaarden van Atrium te hebben voldaan, en hij accepteerde alsnog de tekst van het addendum. Atrium besloot echter het addendum niet aan te gaan en riep op 30 maart 2011 de bankgarantie in. Op 31 maart 2011, de dag waarop de vier ziekenhuizen besloten om gezamenlijk actie te ondernemen, deelde Alert aan Atrium mee dat de [de Portugese projectleider bij Atrium] (hierna: [de Portugese projectleider bij Atrium] ), de Portugese projectmanager die Alert op het project bij Atrium had ingezet, op zijn verzoek was overgeplaatst naar een ander project. Vanaf 1 april 2011 waren ook de overige leden van het on site team van Alert niet meer op locatie bij Atrium aanwezig om daar ondersteuning te verlenen bij de derde testronde. Atrium maakte daartegen bezwaar en sommeerde Alert om [de Portugese projectleider bij Atrium] en de andere leden van het on site team weer op het project van Atrium in te zetten. Atrium schortte ook de betaling op van een factuur waarop als vervaldatum 31 maart 2011 was vermeld. Op 7 april 2011 sommeerde Alert Atrium om die factuur de volgende dag te betalen, waarna Alert de vervanger van [de Portugese projectleider bij Atrium] zou voorstellen. Omdat Atrium de factuur niet betaalde, schortte Alert op 8 april 2011 haar projectwerk op en haalde zij het on site team van het project bij Atrium, zodat de medewerkers van Alert ook niet meer vanuit het kantoor van Alert NL in ’s‑Hertogenbosch voor Atrium mochten werken. [bestuurder van Alert] wilde daarna alleen nog via advocaten met Atrium communiceren. Mr. L. Ritzema, de advocate van Atrium, sommeerde Alert bij brief van 15 april 2011 om binnen drie werkdagen te verklaren dat zij haar contractuele verplichtingen zou nakomen. De advocaten van Alert en Atrium communiceerden daarna vooral over de gezamenlijke actie van de ziekenhuizen. 2.
34. Op 27 november 2009 sloot Alert een raamovereenkomst met haar vierde Nederlandse klant ZANOB over de levering onder licentie, de implementatie en het onderhoud van Alert® Pharmacy. ZANOB exploiteert apotheken in de ziekenhuizen van JBZ en Bernhoven en in andere zorginstellingen. Het hoofdkantoor van ZANOB en de apotheken van ZANOB in de ziekenhuizen van JBZ zouden mee verhuizen naar de nieuwbouwlocatie van JBZ. Alert® Pharmacy zou bij ZANOB moeten gaan communiceren met de medicatiemodule van Alert® PFH die door JBZ en Bernhoven in gebruik zou worden genomen (met behulp van die module schrijven de artsen medicatie voor; het digitale medicatievoorschrift wordt naar ZANOB doorgestuurd). Er werd een gapanalyse uitgevoerd om vast te stellen welke nieuwe functionaliteiten aan Alert® Pharmacy moesten worden toegevoegd om de software geschikt te maken voor de Nederlandse markt en welke nieuwe functionaliteiten moesten worden toegevoegd om te voldoen aan de individuele eisen en wensen van ZANOB die Alert geschikt achtte voor haar standaardproduct. Alert® Pharmacy bestond althans zou gaan bestaan uit de module Clinical (het klinisch deel waarmee medicatieopdrachten van de ziekenhuizen kunnen worden uitgevoerd en medicatiebewaking kan plaatsvinden) en uit de module Non-Clinical ofwel Supply Chain (het logistieke deel). Bij het sluiten van de raamovereenkomst tussen Alert en ZANOB was het de bedoeling dat (het grootste deel van) de module Clinical in maart 2010 en de module Supply Chain in oktober 2010 zouden zijn geleverd, getest en goedgekeurd. De implementatie van Alert® Pharmacy bij ZANOB was in deze fase nog niet gepland. Die implementatie zou worden afgestemd op de implementatie van Alert® PFH bij JBZ en Bernhoven. Later bleek de noodzakelijke aanpassing van Alert® Pharmacy toch ingewikkelder dan voorzien. Besloten werd om de modules Clinical en Supply Chain te verdelen over Pharmacy v.1.0 en v.2.
35. Op 6 september 2010 werd afgesproken dat ZANOB pas Live zou gaan met v.2.0 en wel in oktober/november 2011 wat betreft JBZ en in juli 2012 wat betreft Bernhoven. Bij die gelegenheid deelde Alert mee dat JBZ Live zou gaan met Alert® PFH v.2.6.0.3 maar dat ZANOB pas Live zou kunnen gaan nadat de medicatiemodule van Alert® PFH v.2.6.1 bij alle verpleegafdelingen van JBZ zou zijn geïnstalleerd. Alert stelde als oplossing voor om bij de Go Live van de verpleegafdelingen van JBZ zowel de module Inpatient van v.2.6.0.3 als de medicatiemodule van v.2.6.1 te installeren, hetgeen zou betekenen dat JBZ die medicatiemodule na de release van v.2.6.1 op korte termijn zou moeten testen. In de periode daarna werkten ZANOB en JBZ aan een gapanalyse voor de nieuwe functionaliteiten die in hun visie in de medicatiemodule van Alert® PFH v.2.6.1 moesten worden opgenomen. Die gapanalyse was op 29 november 2010 gereed. Daarnaast werkten Alert en ZANOB verder aan de AS IS en TO BE documenten en de Drawings voor de modules Clinical en Supply Chain van Alert® Pharmacy. In januari 2011 werd een nieuwe planning gemaakt, waarin de release van Alert® Pharmacy v.1.0 werd uitgesteld tot 30 april 2011 en de Go Live van ZANOB bij JBZ op 1 november 2011 werd gesteld. Toen de vier ziekenhuizen de bespreking van 31 maart 2011 hielden waaraan ZANOB niet deelnam, waren de AS IS en TO BE documenten en de Drawings voor de module Clinical geheel of vrijwel geheel klaar, maar waren nog niet al die documenten voor de module Supply Chain klaar althans door ZANOB goedgekeurd. ZANOB deelde op 5 april 2011 per e-mail aan Alert mee dat zij serieuze twijfels had over de voortgang van het project en ZANOB verzocht Alert om een nieuwe realistische planning te maken en duidelijkheid te verschaffen over de kwesties die in het bijgevoegde “shortcomings”-document aan de orde waren gesteld. Alert reageerde conform afspraak op 6 mei 2011 op dat document, waarbij Alert de release van Alert® Pharmacy v.1.0 uitstelde tot juni 2011 ter afstemming met Alert® PFH v.2.6.1.1, maar de release van Alert® Pharmacy v.2.0, afgestemd op v.2.6.1.2, bleef in juli 2011gepland en ook voor het overige handhaafde Alert de planning inclusief de Go Live van ZANOB bij JBZ in november
36. Alert wees ZANOB erop dat JBZ had verzocht om uitstel van de start van de Go Live tot februari 2012 en dat in dat geval de Go Live van Inpatient op de verpleegafdelingen van JBZ niet voor juni 2012 zou kunnen plaatsvinden, reden waarom Alert voorstelde om een bespreking te houden samen met JBZ en Bernhoven over een nieuwe planning. Op 23 mei 2011 reageerde ZANOB dat zij het project op 9 mei 2011 “on hold” had gezet. Op 19 juli 2011 sloot ZANOB zich aan bij de gezamenlijke actie van de ziekenhuizen waaraan Atrium niet langer deelnam. 2.
37. Op 31 december 2009 dan wel 26 januari 2010 sloot Alert een raamovereenkomst met TSZ, haar vijfde Nederlandse klant. Het voor de Go Live noodzakelijke deel van de individuele eisen en wensen van TSZ zou worden opgenomen in Alert® PFH v.2.6.2, waarvan de release op 30 september 2011 zou plaatsvinden, waarna TSZ op 31 maart 2012 op alle afdelingen tegelijk Live zou gaan. Omdat dit vonnis niet geldt ten aanzien van TSZ, zal de rechtbank hier geen details vermelden over het verloop van het project bij TSZ. TSZ nam deel aan de bespreking op 31 maart 2011 tussen de vier ziekenhuizen. Op diezelfde dag stelde TSZ een nieuwe planning aan Alert voor waarin de Go Live bij TSZ met een jaar werd uitgesteld tot maart
38. 2.
39. Na de bespreking op 31 maart 2011 waarop de vier ziekenhuizen besloten om gezamenlijk actie te ondernemen, verzochten de vier ziekenhuizen om een gezamenlijke bespreking met Alert. Op 15 april 2011 verzocht mr. L. Ritzema, de advocate van Atrium, namens de vier ziekenhuizen aan [bestuurder van Alert] om deel te nemen aan een bespreking op 21 april 2011 (prod. 16 van Alert). Die bespreking ging echter niet door. 2.
40. Op 11 mei 2011 zonden de vier ziekenhuizen ieder aan Alert een memorandum, dat was opgesteld door Deterink Advocaten en Notarissen, waaraan mr. Ritzema toen verbonden was (prod. 17 van Alert). In dat memorandum werd opgemerkt dat Alert® in principe een goed product was en dat er vooruitgang was in het geschikt maken van Alert® voor de Nederlandse markt in het licht van de eisen en wensen van de vier ziekenhuizen, maar dat er nog substantiële input en tijd van Alert nodig waren voordat Alert® op de Nederlandse markt zou kunnen worden geïmplementeerd. Eerste vereisten voor een succesvolle implementatie waren volgens dit memorandum onder meer: 1) inzet van een Nederlandse manager van Alert die bekend is met de Nederlandse ziekenhuis- en zorgsystemen en Alert zal vertegenwoordigen bij contractonderhandelingen en bij vergaderingen van de stuurgroepen voor de vier projecten; 2) een permanente roadmap voor de Nederlandse markt met duidelijke deadlines en een duidelijk implementatieplan voor de Nederlandse markt, met garanties voor elk ziekenhuis; 3) inzicht in de financiële situatie van Alert, in het bijzonder de continuïteit van de onderneming van Alert; 4) de oprichting van een User Group waaraan de Nederlandse ziekenhuizen samen met Alert deelnemen. 2.
41. Op 12 mei 2011 vond een bespreking plaats tussen Alert en JBZ, waarin Alert instemde met een op kosten van JBZ uit te voeren External Audit door Ernst & Young. Het rapport van Ernst & Young werd uitgebracht in juli 2011(prod. 84 van Alert). JBZ verschafte slechts enkele pagina’s van dat rapport aan Alert en aan de andere ziekenhuizen. Hoewel het rapport zich op JBZ toespitste, werden de bewuste pagina’s ook gebruikt bij de gezamenlijke actie van de ziekenhuizen. Op deze pagina’s is onder meer vermeld dat Alert beschikt over een kwalitatief goede ontwikkelafdeling die in staat wordt geacht op den duur een goed werkend systeem op te leveren, maar dat Ernst & Young vraagtekens zet bij de implementatiekracht van Alert. In de overgelegde pagina’s zijn verder de volgende aanbevelingen van Ernst & Young opgenomen: 1) de inschakeling van een externe implementatiepartij; 2) een samenwerking tussen de vijf Nederlandse klanten, ook na afloop van de projecten zodat het beheer vanuit één organisatie kan worden uitgevoerd; 3) het laten onderzoeken van de financiële situatie van Alert; 4) het laten onderzoeken van de productkwaliteit van de Alert®-software; 5) het onderzoeken of het mogelijk is de broncode van de Alert®-software te bemachtigen. 2.
42. JBZ zond op 13 juli 2011 een brief aan Alert, waarin JBZ eisen stelde die ruwweg vergelijkbaar waren met bovengenoemde aanbevelingen 1 t/m 4 van Ernst & Young. JBZ kondigde aan dat, indien Alert de eisen van de ziekenhuizen niet zou inwilligen, Alert in gebreke zou zijn en JBZ de twee bankgaranties zou inroepen, de overeenkomst zou ontbinden, aanspraak zou maken op schadevergoeding en het personeel, de pers en andere ziekenhuizen zou inlichten. JBZ nodigde Alert uit voor een bespreking met een delegatie van de ziekenhuizen op 19 of 20 juli
43. 2.
44. Atrium had inmiddels de derde testronde zonder ondersteuning van Alert voortgezet en op 19 mei 2011 een rapport over die derde testronde uitgebracht, waarin zij de software afkeurde. Atrium zond dat testrapport in ieder geval op 1 juni 2011 aan Alert en concludeerde dat zij niet Live kon gaan met de Outpatient module v.2.6.0.3.5.
45. Volgens Alert reageerde zij op 11 juli 2011 op dat rapport, maar Atrium betwist dat. Bij brief van mr. Ritzema van 22 juli 2011 ontbond Atrium de door haar met Alert gesloten raamovereenkomst. Aan deze ontbinding werd aandacht besteed in de media (prod. 22 van Alert). 2.
46. Atrium nam daarom niet deel aan een bespreking tussen Alert en de ziekenhuizen op 19 juli 2011 in Porto, waar ZANOB zich aansloot bij de gezamenlijke actie van de ziekenhuizen. De bespreking werd op 27 juli 2011 voortgezet in Schiphol, waarbij Bernhoven en ZANOB werden vertegenwoordigd door mr. T.H. Bosboom, destijds advocaat van JBZ, Bernhoven, ZANOB en TSZ die deze ziekenhuizen ook bij het opstellen van de raamovereenkomsten had bijgestaan. Bij die bespreking werden afspraken gemaakt, die door JBZ in een concept Letter of Intent (LOI) zouden worden vastgelegd. De LOI zou in het najaar van 2011 moeten zijn afgerond, waarna uiterlijk 31 december 2011 een overeenkomst zou moeten zijn gesloten. 2.
47. JBZ stelde het concept van de LOI op 15 augustus 2011 op (prod. 88 van Alert). In dat concept was onder meer voorzien in: 1) een financiële audit bij Alert; 2) een Product Quality Test; 3) een nieuwe implementatie strategie met behulp van een nieuwe organisatie onder de naam Alert Customizing Netherlands (ACN); 4) een nieuwe gezamenlijke roadmap voor de ontwikkeling van de software, de activiteiten van ACN en de implementatie bij de vier Nederlandse klanten, waaraan een door Alert te verbeuren boete was verbonden. 2.
48. Op 20 september 2011 stuurde Alert een aangepaste versie van het concept LOI naar de vier Nederlandse klanten (prod. 21 van Alert), waarin Alert een groot aantal wijzigingen had aangebracht. Onder meer verving Alert de financiële audit bij Alert door de overlegging door Alert van bewijsstukken dat zij een kapitaalinjectie van € 20.000.000, had gerealiseerd en nam Alert op dat partijen zouden heronderhandelen over de financiële voorwaarden uit de vier raamovereenkomsten en dat de vier Nederlandse klanten een verklaring over hun financiële situatie zouden overleggen. De Product Quality Test zou volgens Alert moeten worden uitgevoerd door de ACN, die door Alert en de vier Nederlandse klanten gezamenlijk zou worden opgericht. De aan de nieuwe roadmap verbonden boete verving Alert door wederzijdse verplichtingen. 2.
49. De vier Nederlandse klanten meenden dat Alert met haar wijzigingen was afgeweken van de afspraken die op 27 juli 2011 waren gemaakt en zij concludeerden dat dooronderhandelen geen zin meer had. Alert meent dat juist JBZ in haar concept LOI is afgeweken van de gemaakte afspraken. 2.
50. Op 3 oktober 2011 ontbond JBZ haar raamovereenkomst met Alert, waarna zij de door Alert verleende bankgaranties voor de door JBZ betaalde voorschotten inriep. Op 4 oktober 2011 bracht JBZ een persbericht uit over de ontbinding (prod. 23 van Alert). 2.
51. Bernhoven zond op 21 oktober 2011 een brief aan Alert, waarin zij Alert onder meer sommeerde om voor 4 november 2011 schriftelijk te bevestigen dat zij wilde onderhandelen over een aanvullende overeenkomst, waarin onder meer zou moeten worden voorzien in een financial audit bij Alert, een Product Quality Test en een financiële vergoeding voor Bernhoven vanwege het wegvallen van JBZ als ontwikkellocatie voor Alert® PFH. Bernhoven schortte al haar projectactiviteiten op tot het sluiten van die aanvullende overeenkomst. 2.
52. Op 2 november 2011 ontbond TSZ haar raamovereenkomst met Alert. 2.
53. Op 3 november 2011 verscheen in de media een artikel over de door Bernhoven verstuurde ingebrekestelling, waarin ook melding werd gemaakt van het opzeggen van het vertrouwen in Alert door JBZ en TSZ (prod. 25 van Alert). 2.
54. Op 4 november 2011 deelde Alert aan Bernhoven mede dat Alert wilde dooronderhandelen over de LOI en dat zij met Bernhoven wilde onderhandelen over voortzetting van het project, maar dat Bernhoven tevoren geen onvoorwaardelijke clausules kon stellen en onder meer niet kon eisen dat zij een financiële vergoeding zou krijgen vanwege het wegvallen van JBZ. Op 23 december 2011 gaf Bernhoven aan Alert de keuze tussen de optie waarbij Bernhoven de raamovereenkomst direct zou ontbinden en de optie waarbij het project bij Bernhoven met twee jaar zou worden uitgesteld tot na de verhuizing naar de nieuwbouw van Bernhoven. Op 31 januari 2012 reageerde Alert dat een uitstel met twee jaar geen optie was. Bernhoven wachtte daarna tot 8 mei 2012 voordat zij haar raamovereenkomst met Alert ontbond. 2.
55. ZANOB wachtte na de ontbinding door JBZ eerst de ontwikkelingen bij Bernhoven af. Nadat duidelijk was dat de optie van uitstel met twee jaar van het project bij Bernhoven door Alert was verworpen, ontbond ZANOB op 23 februari 2012 haar raamovereenkomst met Alert. 2.
56. JBZ en TSZ startten elk een procedure bij deze rechtbank, waarin zij samengevat - vorderden dat voor recht zou worden verklaard dat zij hun raamovereenkomsten met Alert terecht hadden ontbonden en dat Alert zou worden veroordeeld tot betaling van een schadevergoeding en terugbetaling van hetgeen JBZ en TSZ uit hoofde van die raamovereenkomst aan Alert hadden betaald. Bij vonnis van 21 augustus 2013 wees de rechtbank in de procedure onder zaak- en rolnummer C/01/243979 / HA ZA 12-216 de vordering van JBZ af. Bij vonnis van 27 november 2013 wees de rechtbank in de procedure onder zaak- en rolnummer 244606 / HA ZA 12-256 de vordering van TSZ af. JBZ en TSZ stelden hoger beroep in. 2.
57. Op 17 februari 2015 wees het gerechtshof ’s‑Hertogenbosch arrest in de procedure tussen JBZ en Alert met zaaknummer HD 200 142 296/
58. Het hof oordeelde dat JBZ haar raamovereenkomst met Alert terecht had ontbonden. De zaak werd naar de rol verwezen voor een reactie van JBZ op het verweer van Alert tegen de door JBZ gevorderde schadevergoeding. 2.
59. Op 3 november 2015 wees het gerechtshof ’s‑Hertogenbosch arrest in de procedure tussen TSZ en Alert met zaaknummer HD 200.149.803/01, waarin een deskundigenbericht werd gelast. Bij arrest van 23 februari 2016 werd in dat kader een comparitie van partijen bevolen. Op 9 mei 2016 werd een comparitie van partijen gehouden, waarna op 14 juni 2016 arrest is gewezen. Hierin werd partijen - kort gezegd - opgedragen suggesties te doen voor wat betreft de personen van de te benoemen deskundigen. 3Het geschil in conventie 3.
60. Alert vordert samengevat - om bij vonnis, voor zover mogelijk uitvoerbaar bij voorraad: I. te verklaren voor recht dat JBZ, Bernhoven, Atrium, ZANOB en/of TSZ onterecht, althans op ongerechtvaardigde gronden de overeenkomsten met ALERT buitengerechtelijk hebben ontbonden; II. te verklaren voor recht dat de overeenkomsten tussen ALERT en JBZ, Bernhoven, Atrium, ZANOB en/of TSZ als gevolg van de ongerechtvaardigde ontbindingen en de gedragingen en verklaringen van de ziekenhuizen en ZANOB feitelijk zijn geëindigd, althans dat ALERT in redelijkheid niet meer geacht kan worden die overeenkomsten na te komen; III. te verklaren voor recht dat JBZ, Bernhoven, Atrium, ZANOB en/of TSZ jegens ALERT onrechtmatig hebben gehandeld; IV. de ziekenhuizen te veroordelen tot betaling van de schade die het gevolg is geweest van de ongerechtvaardigde ontbinding, althans de onrechtmatige gedragingen, begroot op het contractsbelang van in totaal € 37.193.972,-, te vermeerderen met de wettelijke (handels)rente over de reeds verzonden facturen, per datum dagvaarding totaal € 549.873,12; V. de ziekenhuizen hoofdelijk te veroordelen, althans tot het bedrag waarvoor het betreffende ziekenhuis jegens Alert aansprakelijk is, tot betaling van de schade die het gevolg is geweest van de ongerechtvaardigde ontbinding althans de onrechtmatige gedragingen, met de wettelijke rente over die schade, welke schade ten aanzien van vier schadeposten totaal € 7.133.356,82 bedraagt; VI. de zaak te verwijzen naar een schadestaatprocedure ten aanzien van de schade die naar het oordeel van de rechtbank niet in deze procedure begroot kan worden, waaronder in ieder geval inbegrepen het verlies van opdrachten in Nederland, het verlies van/mislopen van opdrachten buiten Nederland, het terugbrengen van de Alert organisatie in Portugal, het verlies van goodwill en de beschadiging van de reputatie van Alert. VII. de ziekenhuizen te veroordelen in de proceskosten en de nakosten. 3.
61. De ziekenhuizen voeren verweer. 3.
62. Op de stellingen van partijen wordt hierna, voor zover van belang, nader ingegaan. in reconventie 3.
63. Bernhoven, Atrium en ZANOB vorderen in reconventie - kort samengevat - 1) voor recht te verklaren dat deze ziekenhuizen de door hen met Alert gesloten overeenkomsten rechtsgeldig hebben ontbonden althans hebben opgezegd; 2) Alert te veroordelen om aan deze ziekenhuizen terug te betalen hetgeen zij ter uitvoering van de overeenkomsten aan Alert hebben betaald; 3) Alert te veroordelen tot vergoeding van de schade van de ziekenhuizen. De details van deze vorderingen in reconventie zullen hierna bij de bespreking per individueel ziekenhuis worden vermeld. 3.
64. Alert voert verweer. 3.
65. Op de stellingen van partijen wordt hierna, voor zover van belang, nader ingegaan. 4Het rapport van Ernst & Young 4.
66. JBZ verschafte in 2011 alleen enkele pagina’s met conclusies uit het rapport van Ernst & Young aan Alert. Alert verzocht JBZ om inzage in het volledige rapport, maar dat weigerde JBZ. Alert deed een vergelijkbaar verzoek aan Bernhoven, Atrium en ZANOB, maar die reageerden dat JBZ ook aan hen niet het volledige rapport had verstrekt. 4.
67. In de eerder door JBZ tegen Alert ingestelde procedure met zaak- en rolnummer C/01/243979 / HA ZA 12-216 vorderde Alert in een incident ex artikel 843a Rv onder meer de afgifte van het volledige rapport van Ernst & Young. Bij incidenteel vonnis van 28 november 2012 wees de rechtbank die vordering af, onder meer omdat Alert zich ook zonder kennis te nemen van het volledige rapport kon verweren tegen de op ontbinding gebaseerde vordering van JBZ en de onderbouwing daarvan. 4.
68. Alert verzoekt in deze procedure de rechtbank te overwegen om op grond van artikel 21 Rv overlegging van het rapport van Ernst & Young te gelasten (7.21 dagv.). Op de comparitie heeft Alert ook nog een daartoe strekkende incidentele vordering tegen JBZ ingesteld, die de rechtbank in het hiernavolgende zal beoordelen. Het incident ex artikel 843a Rv (JBZ) 4.
69. Alert vordert in het tegen JBZ ingestelde incident op grond van artikel 843a Rv samengevat - dat de rechtbank: 1) JBZ veroordeelt om een afschrift van het rapport van Ernst & Young van 11 juli 2011 aan Alert te verstrekken, dan wel aan Alert inzage in dat rapport te verlenen; 2) JBZ beveelt om binnen één dag na het incidentele vonnis aan die veroordeling te voldoen, op straffe van een dwangsom; 3) bij de voortzetting van de hoofdzaak Alert de mogelijkheid biedt om het rapport te analyseren; 4) JBZ veroordeelt in de kosten van het incident. 4.
70. Alert legt aan deze incidentele vordering ten grondslag dat zij een rechtmatig belang heeft bij kennisname van het rapport van Ernst & Young, omdat JBZ haar strategie heeft bepaald op grond van informatie uit dat rapport en die informatie van cruciaal belang kan zijn voor de onderbouwing van de door Alert ingestelde vordering uit onrechtmatige daad. Alert wijst erop dat de overgelegde pagina’s van het rapport aanwijzingen bevatten dat JBZ niet voldoende en tijdig medewerkers kon vrijmaken voor het uitvoeren van de acceptatietests en dat JBZ haar medisch personeel onvoldoende bij het project betrok. 4.
71. JBZ meent dat Alert misbruik van procesrecht maakt door een incidentele vordering in te stellen die identiek is aan de incidentele vordering van Alert die in de eerdere procedure al was afgewezen. Alert wijst erop dat in deze procedure op Alert de bewijslast rust van haar vordering uit onrechtmatige daad. 4.
72. De rechtbank verwerpt dit verweer van JBZ. Een afgewezen incidentele vordering ex artikel 843a Rv kan later opnieuw worden ingesteld, indien sprake is van nieuwe feiten of omstandigheden (waaronder ook ontwikkelingen in de procedure vallen). In de eerdere procedure was het JBZ die een op ontbinding gebaseerde vordering instelde tegen Alert. In deze nieuwe procedure is het Alert die tegen JBZ vorderingen instelt die zijn gebaseerd op ongerechtvaardigde ontbinding door JBZ en op onrechtmatig handelen van JBZ. Die gewijzigde verhoudingen zijn voldoende om Alert toe te staan haar incidentele vordering in deze nieuwe procedure nogmaals aan de rechter voor te leggen. 4.
73. JBZ voert daarnaast als verweer dat Alert geen rechtmatig belang heeft bij kennisname van het rapport van Ernst & Young. JBZ wijst erop dat artikel 843a Rv een uitzondering is op de hoofdregel dat procespartijen geen inzage hoeven te bieden in de onder hen berustende bescheiden en dat het artikel geen basis biedt voor ‘fishing expeditions’, zodat de enkele interesse van Alert in het rapport van Ernst & Young onvoldoende is. JBZ stelt dat het opstellen van dat rapport een aangelegenheid van JBZ was. Zij wijst erop dat een procespartij er een gerechtvaardigd belang bij heeft om in vrijheid en beslotenheid intern en extern advies te kunnen vragen ten behoeve van het bepalen van het eigen standpunt, zodat partijrapporten niet met derden hoeven te worden gedeeld, ook niet als dat partijrapport op die derden betrekking heeft. 4.
74. Een op artikel 843a Rv gebaseerde vordering kan alleen worden toegewezen indien aan alle drie in lid 1 van dit artikel gestelde voorwaarden is voldaan: 1) de wederpartij van degene die bescheiden te zijner beschikking of onder zijn berusting heeft, moet rechtmatig belang hebben bij inzage, afschrift of uittreksel daarvan, 2) de vordering moet betrekking hebben op bepaalde bescheiden en 3) de bescheiden moeten een rechtsbetrekking betreffen waarin de wederpartij van degene die ze te zijner beschikking of onder zijn berusting heeft, partij is. Verder moet zich geen van de volgende eveneens in artikel 843a Rv opgenomen uitzonderingen voordoen: 4) hij die uit hoofde van zijn ambt, beroep of betrekking tot geheimhouding verplicht is, is niet gehouden aan de vordering te voldoen, indien de bescheiden uitsluitend uit dien hoofde te zijner beschikking staan of onder zijn berusting zijn, 5) degene die de bescheiden te zijner beschikking of onder zijn berusting heeft, is niet gehouden aan de vordering te voldoen, indien daarvoor gewichtige redenen zijn en 6) degene die de bescheiden te zijner beschikking of onder zijn berusting heeft, is niet gehouden aan de vordering te voldoen, indien redelijkerwijs aangenomen kan worden dat een behoorlijke rechtsbedeling ook zonder verschaffing van de gevraagde gegevens is gewaarborgd. 4.
75. Het door Alert opgevraagde rapport van Ernst & Young betreft een door JBZ ingewonnen advies van een zgn. partijdeskundige. JBZ heeft er een gerechtvaardigd belang bij om in vrijheid en beslotenheid intern en extern advies te kunnen vragen ten behoeve van het bepalen van het eigen standpunt (zie onder meer het arrest van het Gerechtshof Arnhem van 7 augustus 2012, ECLI:NL:GHARN:2012:BX4091). Alert heeft als wederpartij geen rechtens te respecteren belang bij kennisname van het advies dat Ernst & Young aan JBZ heeft gegeven. De omstandigheid dat in het rapport van Ernst & Young informatie zou kunnen zijn vermeld die Alert in deze procedure kan gebruiken ter onderbouwing van haar vordering, rechtvaardigt geen uitzondering op het beginsel dat een partij als JBZ in vrijheid en beslotenheid advies moet kunnen vragen. Een vordering op de voet van artikel 843a Rv is immers niet bedoeld voor ‘fishing expeditions’. 4.
76. De incidentele vordering van Alert moet daarom worden afgewezen. Alert zal als de in het ongelijk gestelde partij in de proceskosten van het incident worden veroordeeld. De bewijskracht van het rapport van Ernst & Young 4.
77. De rechtbank zal de inhoud van de overgelegde pagina’s uit het rapport van Ernst & Young niet in het nadeel van Alert meewegen bij de beoordeling van de vordering van Alert tegen JBZ. Ingevolge artikel 85 lid 1 Rv is een partij die zich op een stuk beroept, verplicht om een afschrift van dat stuk bij te voegen. JBZ heeft in strijd met die bepaling het volledige rapport van Ernst & Young ondanks verzoeken van Alert niet in het geding gebracht. De terbeschikkingstelling van slechts een aantal pagina’s van het rapport volstaat niet, omdat die pagina’s alleen betrekking hebben op de conclusies en aanbevelingen van Ernst & Young. De voor dit geding essentiële onderbouwing van die conclusies en aanbevelingen ontbreekt, zodat de waarde van de opvatting van Ernst & Young niet kan worden beoordeeld. 4.
78. Ook Bernhoven, Atrium en ZANOB zijn gebonden aan artikel 85 Rv en kunnen zich daarom niet beroepen op het oordeel van Ernst & Young, omdat zij de onderbouwing van dat oordeel niet hebben overgelegd. De omstandigheid dat deze partijen ook zelf niet over het volledige rapport van Ernst & Young beschikken, rechtvaardigt niet dat de overgelegde pagina’s in het nadeel van Alert mogen worden gebruikt. DE ZAAK TEGEN JBZ 5Nadere feiten ten aanzien van JBZ 5.
79. De eerste contacten tussen Alert en JBZ dateren uit de zomer van
80. Op 3 september 2007 sloten Alert NL (toen nog genaamd Orcinus BV) en JBZ een voorovereenkomst. Nadat JBZ definitief voor Alert® had gekozen, sloten Alert en JBZ op 16 juli 2008 een raamovereenkomst over de levering onder licentie, de implementatie en het onderhoud van Alert® PFH (prod. 58 van Alert). 5.
81. JBZ wilde haar drie ziekenhuizen in ’s‑Hertogenbosch in het eerste kwartaal van 2011 verhuizen naar nieuwbouw op één locatie in ’s‑Hertogenbosch. In die nieuwbouw waren geen archiefruimtes beschikbaar, reden waarom JBZ al voor die verhuizing op alle afdelingen van haar drie ziekenhuizen papiervrij wilde werken. JBZ hield echter wel rekening met noodscenario’s voor het geval dit niet mogelijk zou blijken. In artikel 23.8 van de raamovereenkomst werd bepaald dat JBZ de raamovereenkomst tussentijds mocht beëindigen indien Alert er niet in zou slagen de papiervrije status voor 1 januari 2012 te realiseren, en/of indien op enig moment aannemelijk zou worden dat Alert hierin niet tijdig zal slagen. 5.
82. Aanvankelijk was het de bedoeling dat Alert in het tweede kwartaal van 2008 zou starten met de ontwikkeling van de eerste van de vijf voor JBZ geplande releases. In het overzicht van bijlagen bij de raamovereenkomst werd nog verwezen naar de door Alert opgestelde roadmap v.5.0 van februari 2008 (bijlage 10, prod. 57 van Alert), waarin de vijf releasedata 10 december 2008, 6 juli 2009, 11 december 2009, 5 juli 2010 en 13 december 2010 waren vermeld. Ook werd in dat overzicht nog verwezen naar het Project Plan v.1.0 van mei 2008 (bijlage 8, niet overgelegd), waarin zgn. milestones waren opgenomen die waren afgestemd op de roadmap v.5.
83. De planning in deze bijlagen was echter op het moment van ondertekening van de raamovereenkomst al achterhaald. Alert had daags voor die ondertekening, op 15 juli 2008 de nieuwe roadmap v.6.0 opgesteld (niet overgelegd). Bij de ondertekening van de raamovereenkomst spraken Alert en JBZ af dat zij later afspraken zouden maken over de planning. 5.
84. Op 18 oktober 2008 werd het Project Plan v.1.10 opgesteld (prod. 6 van Alert), dat was afgestemd op de roadmap v.6.0 en uitging van de start van het project op 1 oktober
85. Hierin waren onder meer de volgende milestones opgenomen (pag. 4): - release 2.4.4 30 april 2009 - release 2.4.5 30 september 2009 - eerste Integrale Acceptatietest (IAT) met 2.4.4 en 2.4.5 31 maart 2010 - release 2.4.6 28 februari 2010 - deel Acceptatietest (AT) met 2.4.6 30 april 2010 - release 2.4.7 31 december 2010 - release 2.4.
86. 31 december 2010 - deel AT met 2.4.7 en 2.4.8 31 mei 2011 - tweede IAT 30 juni 2011 In dit plan (pag. 48) werd vermeld dat de Go Live op 3 mei 2010 zou starten en op 18 maart 2011 zou zijn voltooid. 5.
87. Op 28 oktober 2008 (prod. 60 van Alert) adviseerde de projectgroep aan de stuurgroep van het JBZ-project om in te stemmen met het Project Plan v.1.
88. In dit advies legde de projectgroep drie mogelijke scenario’s voor de Go Live aan de stuurgroep voor (pag. 10). Op 28 oktober 2008 stemde de stuurgroep in met het Project Plan v.1.
89. De stuurgroep koos voor het scenario waarbij JBZ op 3 mei 2010 met Alert® PFH v.2.4.6 zou starten met de Go Live, te beginnen op de SEH en aansluitend steeds andere (groepen van) afdelingen. De Go Live zou dan op 18 maart 2011 zijn voltooid, in de maand waarin toen nog de verhuizing naar de nieuwbouw werd verwacht (zie bijlage 4 van het advies). De latere versies v.2.4.7 en v.2.4.8 zouden functionaliteiten bevatten die JBZ bij de Go Live nog niet direct nodig had. 5.
90. Op 3 april 2009 bracht Alert een status report uit (prod. 7 van JBZ), waarin zij meldde dat de eerste release op 30 april 2009 beperkt zou blijven tot 81% van de in v.2.4.4 voor JBZ geplande functionaliteiten (deze versie bevatte ook nog functionaliteiten voor ziekenhuizen elders in de wereld) en dat de overige 19% later in “fixes” zouden volgen. 5.
91. Op 15 april 2009 bracht Alert een nieuw status report uit (prod. 8 van JBZ), waarin zij meldde dat v.2.4.4 in verband hiermee werd gesplitst in v.2.5.0 (release 30 april 2009), v.2.5.1 (release 22 juni 2009) en v.2.5.2 (release 20 juli 2009). De release van v.2.4.5 (nu 2.6.0) werd uitgesteld van 30 september 2009 tot 30 oktober
92. Alert kon nog niet met zekerheid zeggen wanneer de release van v.2.4.6 (nu v.3.0) zou plaatsvinden, maar wilde maatregelen nemen om vertraging te voorkomen. De laatste twee releases v.2.4.7 en v.2.4.8 werden gecombineerd tot v.3.
93. 5.
94. Op 29 april 2009 bracht Alert een status report uit (prod. 10 van JBZ), waarin zij meldde dat de eerste release v.2.5.0 nu 76% van de oorspronkelijk voor JBZ in v.2.4.4 geplande functionaliteiten zou bevatten en dat de release van v.2.6.0 (voorheen v.2.4.5) werd uitgesteld tot 31 december
95. Om de geplande Go Live bij JBZ in mei 2010 te kunnen handhaven, verplaatste Alert 75% van de derde release v.3.0 (voorheen v.2.4.6) naar de tweede release v.2.6.0, zodat JBZ al met v.2.6.0 Live zou kunnen gaan. De resterende 25% van v.3.0 werd ondergebracht in v.2.6.1 (release 31 maart 2010) en v.3.1 werd hernummerd tot v.3.0 (releasedatum nog onduidelijk). Tijdens een stuurgroepvergadering van 2 juli 2009 (prod. 11 van JBZ) stemde JBZ in met deze nieuwe opzet en gaf JBZ aan welke functionaliteiten nodig waren voor de Go Live en dus naar v.2.6.0 moesten worden verplaatst. 5.
96. De release van v.2.5.0, v.2.5.1 en v.2.5.2 (de eerste release met bijbehorende fixes) vond kennelijk plaats overeenkomstig de laatste planning daarvoor. JBZ voerde in september 2009 een informele deel AT uit met v.2.5, met positieve resultaten. 5.
97. Op 11 december 2009 bracht Alert een status report uit (prod. 13 van JBZ), waarin zij meldde dat de release van v.2.6.0, die op 31 december 2009 was gepland, moest worden uitgesteld. Alert stelde voor om op 5 februari 2010 de release te laten plaatsvinden van een v.2.6.0 die beperkt was tot ca. 70% van de functionaliteiten die eerder voor die versie voor JBZ waren gepland, en de resterende 30% te verplaatsen naar de release v.2.6.
98. Tijdens een stuurgroepvergadering op 16 december 2009 maakte JBZ daartegen bezwaar omdat zij alle voor v.2.6.0 voorziene functionaliteiten nodig had voor de Go Live. Afgesproken werd dat Alert een plan zou opstellen om het probleem op te lossen. 5.
99. Op 30 december 2009 bracht Alert het document “Release and Implementation Planning v2.6.0” uit (prod. 15 van JBZ), waarin v.2.6.0 werd gesplitst. Van de oorspronkelijk geplande functionaliteiten zou nu 61% worden opgenomen in v.2.6.0.0, waarvan de release op 5 februari 2010 zou plaatsvinden. De resterende functionaliteiten zouden worden opgenomen in de fixes v.2.6.0.1 (release op 31 maart 2010), v.2.6.0.2 (release op 30 april 2010) en v.2.6.0.3 (release op 31 mei 2010). Alert stelde voor dat JBZ de eerste IAT (die volgens het Project Plan v.1.10 zou plaatsvinden met v.2.4.5, inmiddels hernummerd tot v.2.6.0) zou splitsen. Volgens dit voorstel zou JBZ op 22 februari 2010 moeten starten met een IAT op basis van v.2.6.0.0 en dan later twee nieuwe IAT’s moeten uitvoeren op basis van v.2.6.0.2 en v.2.6.0.
100. De start van de Go Live bij JBZ op 3 mei 2010 was bij dit voorstel niet meer haalbaar, zodat die zou moeten worden uitgesteld tot 5 juli
101. Tijdens een stuurgroepvergadering op 7 januari 2010 gaf JBZ echter aan dat zij niet geloofde in de haalbaarheid van dit plan en dat zij daarom zelf een nieuw plan zou maken met een nieuwe opzet voor de planning. In de periode daarna ontstonden nieuwe vertragingen in de releases en werd gesproken over een “Change Proposal”, waarin de Go Live werd uitgesteld tot na de verhuizing naar de nieuwbouw. 5.
102. Alert en JBZ waren bij de raamovereenkomst overeengekomen dat JBZ aan Alert pas na het bereiken van de papiervrije status in 2011 een licentievergoeding voor Alert® PFH hoefde te betalen. Daarnaast zou JBZ aan Alert een vergoeding betalen voor “Services” (implementatiediensten), die uiteindelijk na verrekening met een incentiveregeling en een creditnota € 4.595.444, bedroeg. Deze vergoeding zou worden betaald in termijnen, die waren gekoppeld aan IAT’s en AT’s. In verband met de nieuwe indeling van de releases waren Alert en JBZ op 15 oktober 2009 nieuwe termijnen overeengekomen (blad 11 van prod. 26 van Alert). De eerste termijn van 60% was gekoppeld aan de eerste IAT, die met v.2.6.0 (voorheen v.2.4.5) zou plaatsvinden, en zou door JBZ op 30 april 2010 betaald worden. De vertraging in de release van v.2.6.0 en de opsplitsing van die release in fixes betekenden dat de betaling van deze eerste termijn werd uitgesteld. Op 27 juli 2010 sloten Alert en JBZ een “Addendum Framework Agreement” (hierna het eerste Addendum, prod. 22 van JBZ), waarin nog enige wijzigingen in het betalingsschema werden overeengekomen en waarin werd overeengekomen dat JBZ aan Alert een voorschot van € 1.294.357,11 exclusief BTW zou betalen (zijnde 50% van de facturen die pas na levering en acceptatie van Alert® PFH v.2.6.0.3 opeisbaar zouden worden) en dat JBZ daarnaast een bedrag van € 624,937.85 aan BTW over 100% van de facturen aan Alert zou betalen (niet bij wijze van voorschot). Alert zou als zekerheid voor het voorschot een bankgarantie geldig tot 1 maart 2011 verschaffen. Deze overeenkomst werd uitgevoerd. 5.
103. Op 21 juli 2010 werd de definitieve versie v.1.1 van het “Change Proposal” vastgesteld (prod. 62 van Alert), waarmee partijen feitelijk overeenstemming bereikten over de nieuwe planning, al is onduidelijk op welk niveau die overeenstemming bestond. Volgens dit stuk zou de release van v.2.6.0.2 en v.2.6.0.3 op 6 augustus 2010 plaatsvinden (de release van alle eerdere versies had inmiddels al plaatsgevonden) en zou JBZ Live gaan met v.2.6.0.
104. De releasedatum 6 augustus 2010 is vermeld in een overzicht van nieuwe milestones op pagina 35 van het Change Proposal. In dat overzicht is ook de milestone 28 februari 2011 vermeld voor “1st Integral Acceptancy Test” (volgens JBZ betreft dat het einde van de eerste IAT, maar Alert betwist dat). De IAT zou beginnen (pag. 15) met een Functional Acceptance Test (FAT), gevolgd door een User Acceptance Test (UAT). Volgens het Go Live scenario op pagina 19 van het Change Proposal zou de start van de Go Live op de SEH plaatsvinden op 15 april 2011, de dag waarop ook de verhuizing naar de nieuwbouw zou starten. Daarna zou de Go Live op de overige afdelingen van JBZ plaatsvinden. De Go Live zou zijn voltooid op 30 september
105. 5.
106. Na de release van v.2.6.0.3 wilde JBZ in september 2010 beginnen met testen, maar er bleken problemen te bestaan met de testomgeving. Omdat Alert er niet in slaagde een stabiele testomgeving op te leveren, werd het testen uitgesteld. In november 2010 werd verwacht dat de testomgeving in december 2010 geschikt zou zijn voor de FAT (nog niet voor de UAT) en werd groen licht gegeven voor de start van de FAT in januari
107. 5.
108. Op 18 november 2010 sloten Alert en JBZ opnieuw een “Addendum Framework Agreement” (hierna het tweede Addendum, prod. 23 van JBZ), waarin zij overeen kwamen dat JBZ een tweede voorschot van € 1.294.357,11 aan Alert zou betalen (de resterende 50% van de facturen die opeisbaar zouden worden na aanvaarding van v.2.6.0.3). Alert zou een bankgarantie geldig tot 1 juni 2011 verlenen en de bankgarantie voor het eerste voorschot tot die datum verlengen. Ook dit addendum werd uitgevoerd. 5.
109. Op 21 december 2010 ondertekenden Alert en JBZ een Addendum (hierna het derde Addendum, prod. 63 van Alert), waarin zij overeen kwamen dat bepaalde bijlagen bij de raamovereenkomst werden vervangen door nieuwe versies die in de loop van het project waren vastgesteld (zoals de roadmap v.6.0 en het Project Plan v.1.10) en dat nieuwe bijlagen aan de raamovereenkomst werden gehecht. Tot die nieuwe bijlagen behoorde het Change Proposal v.1.1, dat hiermee formeel tussen Alert en JBZ overeengekomen werd. 5.
110. Op 27 januari 2011 bracht mevrouw van [projectmanager van JBZ] , inmiddels projectmanager van JBZ, conceptversie 0.1 uit van het stuk “Status and outline Golive” (prod. 38 van JBZ), waarin zij onder meer voorstelde om vanwege de vertraging bij het testen de start van de Go Live uit te stellen van 15 april 2011 tot 1 oktober
111. De heer [projectmanager Alert] (hierna [projectmanager Alert] ), inmiddels projectmanager van Alert voor het project bij JBZ, reageerde in een e-mail van 24 februari 2011 (prod. 43 van JBZ), waarin hij instemde met het uitstel tot 1 oktober 2011 en zelf nog een aantal voorstellen deed, waaronder het voorstel dat JBZ niet met v.2.6.0.3 maar met v.2.6.0.5 Live zou gaan. 5.
112. Op 16 februari 2011 bracht JBZ een testrapport uit (prod. 67 van Alert) met voorlopige resultaten van de FAT, waarin zij meldde dat van de geteste functionaliteiten (67% van de vereiste functionaliteiten) slechts 25% was goedgekeurd, dat 16% was afgekeurd en dat 50% nog niet beschikbaar bleek (het restant van 9% betrof tegenstrijdige testresultaten). Alert maakte op 8 maart 2011 een voorlopige analyse van de 50% volgens JBZ niet beschikbare functionaliteiten (prod. 70 van Alert). Alert kwam aldus uit op een totaalscore van 39% goedgekeurd, 23% afgekeurd, 18% niet beschikbaar en 21% nog nader te analyseren. In de ogen van Alert waren ook deze aangepaste percentages onaanvaardbaar (“the corrected percentage of “Not OK” + “Not available” is between 41% and 47%; much lower than the original 66%, but still unacceptable”). Alert werkte hierna verder aan een definitieve volledige analyse. 5.
113. Bij brief van 13 maart 2011 (prod. 65 van Alert) deelde [projectmanager van JBZ] aan Alert mee dat zij inmiddels een opstelling had ontvangen van het aantal uren dat door de ICT-medewerkers van JBZ moest worden besteed aan de verhuizing en dat deze inzet een vertraging betekende voor het project Alert®. [projectmanager van JBZ] stelde daarom voor de inmiddels voor juni 2011 geplande eerste IAT niet volledig in juni 2011 uit te voeren, maar een deel daarvan pas in oktober en november 2011 uit te voeren. De Go/No-Go beslissing (een Go betekent groen licht voor de Go Live), zou dan pas na het tweede deel van de IAT worden genomen en de start van de Go Live zou moeten worden uitgesteld van 1 oktober 2011 tot 1 februari
114. 5.
115. Op 17 maart 2011 vond een stuurgroepvergadering plaats (prod. 64 van Alert), waarbij Alert werd vertegenwoordigd door [voormalig manager Alert] . [voormalig manager Alert] gaf aan dat Alert bezwaar had tegen het voorstel van JBZ om de start van de Go Live te verplaatsen van 1 oktober 2011 naar 1 februari 2012 omdat dat commerciële en financiële consequenties voor Alert had, zodat Alert alleen met dit uitstel zou instemmen indien Alert en JBZ overeenstemming zouden kunnen bereiken over de financiële voorwaarden van Alert voor dat uitstel. 5.
116. Op 30 maart 2011 deelde [bestuurder van Alert] aan JBZ mee dat [voormalig manager Alert] , die de volgende dag zou deelnemen aan een bespreking met JBZ over de financiële voorwaarden voor het uitstel, niet meer bij Alert werkzaam was. JBZ stelde daarom die bespreking uit en besprak de ontwikkelingen bij de gezamenlijke bespreking van de vier ziekenhuizen op 31 maart
117. 5.
118. Alert deelde op 4 april 2011 aan JBZ mee dat zij niet aan de stuurgroepvergadering van 7 april 2011 en latere stuurgroepvergaderingen zou deelnemen, zolang er nog geen overeenstemming bestond over de financiële gevolgen van het door JBZ gewenste uitstel van de Go Live. 5.
119. Op 6 april 2011 bracht [projectmanager van JBZ] de definitieve versie 1.1 van het stuk “Status and outline Go Live” (prod. 45 van JBZ) uit, waarin zij meldde dat aanpassing van de planning nodig was vanwege de vertraging bij het testen en omdat zowel Alert als JBZ meer tijd nodig hadden. In dit stuk handhaafde JBZ de splitsing van de eerste IAT in twee delen. Het eerste deel zou met v.2.6.0.5 plaatsvinden in oktober en november 2011, waarna JBZ op 1 december 2011 de Go/NoGo-beslissing voor het eerste deel zou nemen en bij een Go 40% van de vergoeding voor implementatiediensten voor het totale project verschuldigd zou zijn. Op 1 februari 2012 zou JBZ dan starten met de Go Live met het goedgekeurde deel van Alert® PFH, te beginnen op de SEH. Het tweede deel van de IAT met v.2.6.1 zou worden uitgevoerd in februari en maart 2012, waarna JBZ op 19 april 2012 de Go/NoGo-beslissing voor het tweede deel zou nemen en bij een Go 30% van de vergoeding voor implementatiediensten voor het totale project verschuldigd zou zijn. De Go Live voor het tweede deel zou starten op 1 juni 2012 (zie voor een en ander pag. 13, 14 en 20). De resterende 30% zou later (onder meer bij de tweede IAT) verschuldigd worden. 5.
120. Na een stroeve start begonnen Alert en JBZ onderhandelingen over de financiële voorwaarden die Alert stelde voor het door JBZ gewenste uitstel van de Go Live. Op 11 mei 2011 berichtte JBZ aan Alert dat zij had besloten om een externe audit te laten uitvoeren en verzocht zij Alert om de bankgaranties voor de twee voorschotten te verlengen. Alert stemde in met een op kosten van JBZ uit te voeren externe audit door Ernst & Young. Alert en JBZ kwamen overeen dat de bankgaranties op kosten van JBZ werden verlengd tot 1 augustus
121. 5.
122. Ondertussen was Alert® PFH v.2.6.0.5.3.2 door Alert bij JBZ geïnstalleerd en op maandag 2 mei 2011 voor testen door JBZ beschikbaar. Op dezelfde dag bracht Alert ook haar eindrapport uit over de resultaten van de FAT die in januari/februari 2011 was uitgevoerd (prod. 71 van Alert). Volgens dat rapport waren maar 209 van de 572 door JBZ gemelde issues deugdelijk. Van die 209 issues was 24% opgelost, grotendeels in v.2.6.0.5 maar een klein deel zou pas in latere versies worden opgelost. Een deel van de issues wachtte op input van JBZ. Alert kwam uit op 44% van de issues die “Not OK” of “Not available” waren, hetgeen zij nog steeds als onacceptabel aanmerkte (“The ALERT percentage of “Not OK” + “Not Available” is around 44%. Much smaller than the JBZ counting of 65%, but still unacceptable”; pag. 14). 5.
123. Op 8 juni 2011 bracht [projectmanager van JBZ] een eindrapport uit over de FAT die in januari/februari 2011 was uitgevoerd (prod. 72 van Alert). [projectmanager van JBZ] constateerde dat contractueel was bepaald dat testbevindingen binnen 30 dagen moesten zijn opgelost, maar dat Alert de afgelopen drie maanden niet goed had benut voor die oplossingen. JBZ meende onder meer dat veel issues nog niet in v.2.6.0.5 waren opgelost en dat die release nog niet klaar was om aan JBZ overhandigd te worden. [projectmanager van JBZ] adviseerde de projectgroep om dit rapport te beschouwen als het eindrapport van de FAT met als uitkomst dat JBZ het product niet accepteerde. [projectmanager van JBZ] adviseerde ook een aantal actiepunten, waarbij Alert uiterlijk 16 juni 2011 diverse acties moest uitvoeren en eind juni 2011 de testbevindingen moest hebben opgelost. 5.
124. Vanaf 13 juni 2011 verscheen Alerts projectmanager [projectmanager Alert] niet meer bij JBZ. 5.
125. In juli 2011 bracht Ernst & Young haar rapport uit, dat eerder al is besproken bij de algemene feiten. Bij brief van 13 juli 2011 (prod. 87 van Alert, door JBZ aangemerkt als ingebrekestelling) deelde JBZ aan Alert mee dat het rapport van Ernst & Young het standpunt van JBZ bevestigde en dat JBZ voorwaarden stelde voor de voortzetting van het project. Die voorwaarden kwamen neer op de eerste vier aanbevelingen van Ernst & Young (inschakeling van een externe implementatiepartij, samenwerking tussen de Nederlandse klanten, onderzoek van de financiële situatie van Alert en onderzoek van de productkwaliteit) en op het sluiten van een nieuw Addendum. Onder het kopje “Last chance” verlangde JBZ dat Alert bij wijze van eerste stap uiterlijk op 20 juli 2011 zou bevestigen dat zij aan de voorwaarden van JBZ wilde meewerken, bij gebreke waarvan Alert in verzuim zou zijn en JBZ de twee bankgaranties zou moeten inroepen, de overeenkomst zou ontbinden, aanspraak zou maken op een schadevergoeding en gedwongen zou zijn haar personeel, de pers en andere ziekenhuizen in te lichten. 5.
126. In dezelfde brief nodigde JBZ Alert uit om deel te nemen aan een bespreking met haar Nederlandse klanten. Die bespreking vond plaats tijdens de al onder de algemene feiten vermelde bijeenkomsten van 19 en 27 juli 2011, die gevolgd werden door het concept LOI en de e-mail van Alert van 20 september 2011 met de aanpassingen die Alert in dat concept wenste. 5.
127. Bij brief van 3 oktober 2011 (prod. 89 van Alert) ontbond JBZ de raamovereenkomst. Voor zoveel nodig zegde zij de raamovereenkomst op tegen 3 oktober
128. Op 4 oktober 2011 bracht JBZ een persbericht over de ontbinding uit (prod. 23 van Alert). Alert drong er bij brief van 10 oktober 2011 op aan dat JBZ de onderhandelingen zou heropenen, maar JBZ reageerde op 31 oktober 2011 dat haar besluit definitief was. 5.
129. Op 21 december 2011 dagvaardde JBZ Alert voor deze rechtbank (toen nog genaamd rechtbank ’s‑Hertogenbosch). In die procedure onder zaak- en rolnummer C/01/243979 / HA ZA 12-216 vorderde JBZ - samengevat - een verklaring voor recht dat JBZ de raamovereenkomst rechtsgeldig had ontbonden althans opgezegd en een hoofdelijke veroordeling van Alert PT en Alert NL tot terugbetaling van een bedrag van € 1.175.854,86 en tot betaling van een schadevergoeding van € 8.000.000,. 5.
130. Op 9 april 2013 bracht Alert de dagvaarding in de onderhavige zaak uit. 5.
131. Op 21 augustus 2013 wees de rechtbank eindvonnis in de eerdere procedure. In dat vonnis wees de rechtbank de meeste vorderingen van JBZ af. Naar het oordeel van de rechtbank was er geen sprake van verzuim van Alert en had JBZ daarom niet de bevoegdheid de raamovereenkomst buitengerechtelijk te ontbinden. Wel verklaarde de rechtbank voor recht dat de raamovereenkomst door JBZ rechtsgeldig was opgezegd tegen 3 oktober
132. JBZ stelde hoger beroep in tegen dat vonnis. 5.
133. Op 17 februari 2015 wees het gerechtshof ’s‑Hertogenbosch een tussenarrest in de procedure met zaaknummer HD 200.142.296/
134. Anders dan de rechtbank oordeelde het hof dat JBZ bevoegd was de raamovereenkomst buitengerechtelijk te ontbinden. Het hof verwees de zaak naar de rol opdat JBZ zou kunnen reageren op het verweer dat Alert gevoerd had tegen de door JBZ gevorderde schadevergoeding. 5.
135. Alert kondigde ter comparitie in deze zaak aan dat zij na het eindarrest van het hof cassatie tegen de arresten van het hof zal instellen. 6De beoordeling 6.
136. Alert PT is gevestigd in Portugal. Het geschil heeft derhalve internationale aspecten, zodat allereerst moet worden onderzocht of de Nederlandse rechter bevoegd is er kennis van te nemen. Dat is het geval: het geschil betreft een handelszaak als bedoeld in artikel 1 van de EEX-Verordening (hierna: EEX-Vo, de Herschikte EEX-Verordening is niet van toepassing op deze voor 10 januari 2015 aanhangig gemaakte zaak). Ingevolge artikel 23 lid 1 EEX-Vo kunnen partijen, van wie er ten minste één woonplaats heeft op het grondgebied van een EEX-staat een gerecht of de gerechten van een EEX-staat aanwijzen voor de kennisneming van geschillen die naar aanleiding van een bepaalde rechtsbetrekking zijn ontstaan of zullen ontstaan. In artikel 24.1 van de raamovereenkomst zijn Alert en JBZ overeengekomen dat geschillen over de raamovereenkomst bij uitsluiting zullen worden voorgelegd aan de daartoe bevoegde rechter in ’s-Hertogenbosch. De Nederlandse rechter heeft daarom rechtsmacht en de rechtbank Oost-Brabant is relatief bevoegd om van de vorderingen van Alert kennis te nemen. 6.
137. De vraag naar het toepasselijk recht dient te worden beantwoord aan de hand van het ten tijde van het sluiten van de overeenkomst nog van toepassing zijnde EEG-Overeenkomstenverdrag (EVO). Partijen hebben in artikel 24.2 van de raamovereenkomst uitdrukkelijk bepaald dat op hun rechtsverhouding Nederlands recht van toepassing is en daarmee een rechtskeuze gemaakt als bedoeld in artikel 3 EVO. Het arrest van het gerechtshof 's‑Hertogenbosch 6.
138. Het arrest van het gerechtshof ’s‑Hertogenbosch in de eerder door JBZ aanhangig gemaakte procedure is nog niet in kracht van gewijsde, omdat daartegen nog cassatie kan worden ingesteld. Dit arrest heeft derhalve tussen Alert en JBZ geen gezag van gewijsde in de zin van artikel 236 Rv. 6.
139. Uit de jurisprudentie zijn gevallen bekend waarin de rechter oordeelde dat de eisende partij misbruik van procesrecht maakte door na afwijzing van haar vordering in een eerste procedure precies dezelfde vordering in te stellen in een tweede procedure. Dat is in deze zaak echter niet aan de orde, omdat de eerste procedure door JBZ is ingesteld terwijl deze tweede procedure door Alert aanhangig is gemaakt. Evenmin is sprake van bijzondere omstandigheden die strijd met een goede procesorde zouden kunnen opleveren. 6.
140. De rechtbank is formeel niet gebonden aan het oordeel van het hof in het tussenarrest van 17 februari
141. De rechtbank acht het echter uit een oogpunt van rechtszekerheid niet wenselijk dat zij als lagere rechter afwijkt van het oordeel over dezelfde rechtsbetrekking van een hogere rechter, temeer nu tegen het vonnis in deze tweede procedure hoger beroep kan worden ingesteld bij hetzelfde hof dat ook het tussenarrest in de eerste procedure heeft gewezen. De rechtbank zal daarom haar oordeel afstemmen op het oordeel van het hof. De bewijslastverdeling 6.
142. Uit onder meer artikel 2.1 van de raamovereenkomst volgt dat de kernprestatie onder de raamovereenkomst diende te worden verricht door Alert NL als hoofdaannemer en Alert PT als hoofdelijk aansprakelijke onderaannemer. Alert diende immers Alert® PFH onder licentie te leveren en bij JBZ te implementeren. De complexe en grootschalige relatie tussen partijen bracht echter mee dat Alert en JBZ intensief zouden moeten samenwerken om het project tot stand te brengen. Op JBZ rustte in verband daarmee een samenwerkingsplicht zoals onder meer beschreven in artikel 3 van de raamovereenkomst. Die plicht kwam erop neer dat JBZ op de daarin omschreven wijzen Alert in staat moest stellen aan haar kernprestatie te voldoen, maar reikte niet zover dat JBZ een gedeelde verantwoordelijkheid voor de kernprestatie droeg. 6.
143. Het voorgaande betekent dat JBZ bij de onderbouwing van haar beroep op de ontbinding in beginsel kan volstaan met te stellen en zo nodig te bewijzen dat Alert één of meer van haar verplichtingen niet tijdig conform de gemaakte afspraken heeft uitgevoerd, dan wel dat ten tijde van de ontbinding aannemelijk was dat Alert er niet in zou slagen de papierloze status te realiseren voor de overeengekomen datum of dat sprake was van een andere omstandigheid op grond waarvan de raamovereenkomst ontbonden kon worden. Slaagt JBZ daarin, dan is in beginsel uitgangspunt dat JBZ gerechtigd was om de overeenkomst te ontbinden. Dit kan anders worden indien Alert op haar beurt stelt en zo nodig bewijst dat JBZ is tekortgeschoten in één of meer van de op haar rustende verplichtingen en dit de nakoming door Alert van haar verplichtingen jegens JBZ heeft verhinderd. Het beroep van JBZ op ontbinding 6.
144. JBZ baseert haar ontbinding van de overeenkomst op de volgende argumenten: 1) Alert heeft fatale termijnen geschonden door overschrijding van de milestones in het Project Plan; 2) de contractuele datum voor het papiervrije ziekenhuis op 1 januari 2012 was niet meer haalbaar; 3) JBZ moest uit mededelingen van Alert afleiden dat Alert in de nakoming tekort zou schieten; 4) er was sprake van een blijvende onmogelijkheid van Alert om aan haar contractuele verplichtingen te voldoen; 5) Alert heeft niet voldaan aan de sommatie in de e-mail van JBZ aan Alert van 11 mei 2011, die voldoet aan alle eisen voor een ingebrekestelling, althans is het beroep van Alert op het ontbreken van een geldige ingebrekestelling naar maatstaven van redelijkheid en billijkheid onaanvaardbaar. 6.
145. Alert en JBZ zijn op de comparitie in deze tweede zaak maar heel beperkt ingegaan op hun stellingen in de dagvaarding en de conclusie van antwoord over de argumenten van JBZ voor haar beroep op ontbinding, maar hebben zich geconcentreerd op het arrest van het hof, waarin is beslist op de standpunten van Alert en JBZ daarover in de eerste zaak. Daardoor ontbreken in deze tweede zaak bepaalde detailstellingen van zowel Alert als JBZ, die in de eerste zaak wel zijn aangevoerd. De rechtbank acht het niet wenselijk dat het oordeel in de twee zaken uiteen loopt als gevolg van het ontbreken van deze detailstellingen. Alert en JBZ hebben hun standpunten uit de eerste zaak bij de rechtbank immers als bekend verondersteld. Zij hebben ook het gehele procesdossier van het hoger beroep in deze procedure in het geding gebracht. De rechtbank zal daarom om proceseconomische redenen de detailstellingen uit de eerste zaak ook betrekken in haar oordeel in deze tweede zaak, voor zover die stellingen blijken uit het tussenarrest van het hof. Het beroep op fatale milestones 6.
146. In artikel 16.1 van de raamovereenkomst is bepaald dat een partij die tekort komt in de nakoming van één of meer van zijn verplichtingen uit de overeenkomst, onmiddellijk in gebreke is indien een milestone uit het Project Plan dan wel een andere expliciet door partijen als fatale termijn aangeduide termijn is overschreden. JBZ stelt dat Alert op grond van deze bepaling in gebreke is, omdat Alert de milestones uit het Project Plan v.1.10 en uit het Change Proposal niet heeft gehaald. Alert meent dat de milestones geen fataal karakter hadden. 6.
147. De rechtbank is van oordeel dat JBZ zich niet meer kan beroepen op de milestones in het Project Plan v.1.10, omdat Alert en JBZ een nieuwe planning met nieuwe milestones zijn overeengekomen die zij hebben vastgelegd in het Change Proposal. Ook fatale termijnen in dat Change Proposal hebben ingevolge artikel 16.1 van de raamovereenkomst tot gevolg dat door de enkele overschrijding van die termijnen verzuim ontstaat. Het hof heeft geoordeeld (r.o. 3.8.5.1) dat de in het Change Proposal opgenomen datum van 28 februari 2011 voor de eerste IAT tussen Alert en JBZ geldt als een fatale termijn. Daaraan doet volgens het hof niet af dat bij diverse milestones, zoals de onderhavige, in het Change Proposal is vermeld “for the time being”, nu dat er slechts op wijst dat Alert en JBZ later een nieuwe milestone kunnen overeenkomen, hetgeen niet is gebeurd. Dat bij de nieuwe Golive datum is opgemerkt “Please note: dates are only an indication” wijst er volgens het hof slechts op dat Alert en JBZ hebben onderkend dat het kunnen overgaan tot uitvoering van de fase van GoLive afhankelijk was van de stand van zaken met betrekking tot andere (eerdere te voltooien) onderdelen van het project. Ook andere citaten van Alert uit het Change Proposal deden volgens het hof niet af aan het fatale karakter van de milestones in dat stuk. De rechtbank neemt dit oordeel van het hof over. 6.
148. Alert en JBZ zijn het er niet over eens wat op 28 februari 2011 met betrekking tot de eerste IAT moest zijn gerealiseerd. JBZ meent dat de IAT op de genoemde datum moest zijn afgerond. Alert heeft in de eerdere procedure aangevoerd dat de IAT op 28 februari 2011 zou beginnen. Het hof heeft geconcludeerd (r.o. 3.8.5.3) dat de milestone van 28 februari 2011 inhield dat de drie contractueel overeengekomen testronden van de eerste IAT (voor zover er drie testronden nodig zouden blijken) op die datum moesten zijn afgerond, en niet dat de IAT uiterlijk op die datum diende te zijn aangevangen. 6.
149. In deze tweede procedure neemt Alert een nieuw standpunt in (pag. 20 e.v. spreekaantekeningen), dat zij baseert op een testplan van april 2010 (Appendix 2 bij het Change Proposal, afzonderlijk overgelegd als prod. 65 van JBZ in hoger beroep, in deze tweede zaak overgelegd als onderdeel van prod. 3 JBZ van Alert). Alert stelt dat v.2.6.0.3 volgens dit testplan zou worden getest door middel van drie IAT’s en dat die drie IAT’s in het Change Proposal zijn beperkt tot twee IAT’s, waarvan de eerste op 28 februari 2011 gereed moest zijn maar voor de tweede nog geen einddatum was vastgesteld (“pending”). 6.
150. De rechtbank verwerpt het nieuwe standpunt van Alert. Uit de raamovereenkomst en uit andere overgelegde stukken blijkt dat JBZ de vergoeding van implementatiediensten zou betalen in termijnen, die waren gekoppeld aan (I)AT’s. Anders dan Alert stelt, was het al in het oorspronkelijke Project Plan v.1.10 de bedoeling dat er (naast enkele deel AT’s) twee IAT’s zouden plaatsvinden (zie het onder 5.4 opgenomen overzicht). De eerste IAT zou plaatsvinden met v.2.4.5, later hernummerd tot v.2.6.
151. Uit het eerste Addendum volgt dat de eerste termijn verschuldigd zou worden bij acceptatie van v.2.6.0.3, derhalve na afloop van die eerste IAT. De tweede IAT zou plaatsvinden met v.2.4.8 (inmiddels samen met v.2.4.7 hernummerd tot v.3.0), waarin de functionaliteiten waren opgenomen die JBZ bij de Go Live nog niet direct nodig had. Dan ligt het voor de hand dat ook in het overzicht op pagina 34 van het Change Proposal wordt gedoeld op de twee IAT’s die voor de termijnbetalingen essentieel waren. Dat bij de tweede IAT “pending” is vermeld, wordt verklaard door de inhoud van het Change Proposal, waarin is vermeld dat Alert nog geen (definitieve) data had genoemd voor de releases v.2.6.1 en v.3.0, waarmee de tweede IAT zou moeten plaatsvinden. Het door Alert in de spreekaantekeningen geciteerde deel van de tabel in het testplan van april 2010 betreft blijkens rij 23 daarvan één “Integral Acceptance Test” die blijkens de in die rij vermelde datum loopt van 7 juni 2010 tot en met 28 februari
152. Daaronder is vermeld “IAT 1”, “IAT 2” en “IAT 3”, maar uit de daarbij opgenomen onderdelen volgt dat het hier niet gaat om drie IAT’s, maar om de drie testronden van de eerste IAT met v.2.6.0.3 en de eventuele herstelversies daarvan. Dit blijkt bovendien ook uit de layout van de tabel: de aanduidingen IAT 1 t/m 3 zijn ‘ingesprongen’ ten opzichte van de als overkoepelend bedoelde term “Integral Acceptance Test”. De rechtbank concludeert daarom evenals het hof dat de milestone van 28 februari 2011 inhield dat de drie contractueel overeengekomen testronden van de eerste IAT (voor zover er drie testronden nodig zouden blijken) op die datum moesten zijn afgerond. 6.
153. Volgens de genoemde tabel in het testplan zou de eerste IAT in juni 2010 beginnen met de FAT, die in september 2010 zou worden gevolgd door de UAT. Die planning was ten tijde van de definitieve versie van de Change Proposal al achterhaald, omdat de release van v.2.6.0.3 pas op 6 augustus 2010 zou plaatsvinden. Volgens JBZ was de FAT daarom inmiddels gepland in september
154. Het lag ook voor de hand dat die FAT zo snel mogelijk na de release van v.2.6.0.3 zou starten, omdat er anders te weinig tijd zou zijn om drie eventueel noodzakelijke testronden voor 28 februari 2011 te kunnen uitvoeren. Om de FAT mogelijk te maken, diende Alert v.2.6.0.3 op de testomgeving van JBZ te installeren, te parametriseren en met de content van JBZ te vullen. Alert bleek echter niet in staat te zijn de testomgeving bij JBZ stabiel te krijgen, zodat de FAT pas in januari 2011 kon starten. 6.
155. Toen JBZ op 16 februari 2011 haar testrapport met de voorlopige resultaten van de FAT uitbracht, werd duidelijk dat v.2.6.0.3 gebrekkig was, onder meer omdat nog veel overeengekomen functionaliteiten ontbraken. Op dat moment was al duidelijk dat de datum 28 februari 2011 niet meer zou kunnen worden gehaald. Vanaf de datum van het testrapport van 16 februari 2011 resteerden immers nog maar twaalf dagen, hetgeen onvoldoende was voor herstel van v.2.6.0.3 en het testen van de herstelversie, laat staan voor eventuele verdere herstelversies en het testen daarvan. Daarmee kon JBZ stellen dat de fatale termijn van 28 februari 2011 niet was gehaald en dus het in het Change Proposal opgenomen tijdpad niet door Alert was nagekomen. 6.
156. Toen het testrapport van 16 februari 2011 werd uitgebracht, had [projectmanager van JBZ] inmiddels op 27 januari 2011 voorgesteld om de start van de Go Live uit te stellen van 15 april 2011 tot 1 oktober 2011, hetgeen impliceerde dat er meer tijd beschikbaar zou komen voor het herstel van v.2.6.0.3 en het testen van die herstelversie. Op 13 maart 2011 stelde [projectmanager van JBZ] voor om de start van de Go Live verder uit te stellen tot 1 februari
157. 6.
158. Het hof heeft geoordeeld (r.o. 3.11.4) dat het voorstel van JBZ om de Go Live uit te stellen tot 1 februari 2012 niet tot de conclusie leidt dat JBZ daarmee afstand heeft gedaan van de datum van 1 januari 2012 voor de papiervrije status van JBZ uit artikel 23.8 van de raamovereenkomst, omdat JBZ dit voorstel heeft gedaan in een poging het project Alert® tot een goed einde te brengen en omdat partijen over de datum van 1 februari 2012 geen overeenstemming hebben bereikt. Uit dit oordeel volgt dat dit uitstelvoorstel evenmin de aanname rechtvaardigt dat JBZ afstand heeft gedaan van de milestone 28 februari
159. Het hof heeft bovendien geoordeeld (r.o. 3.9.5) dat de omstandigheid dat JBZ zich eerder niet op het niet gehaald hebben van een milestone heeft beroepen, niet tot de conclusie leidt dat JBZ zich niet (langer) op het niet halen van deze milestone zou kunnen beroepen. De rechtbank neemt deze oordelen over. 6.
160. Alert heeft op de comparitie gesteld dat over het (eerste) uitstel tot 1 oktober 2011 wel overeenstemming bestond. Uit de stukken blijkt slechts dat [projectmanager Alert] , de projectmanager van Alert, het feitelijk eens was met dit uitstel en voorstellen deed voor de uitwerking van het voorstel. Alert heeft echter niet gesteld dat de bestuurders van Alert en JBZ een overeenkomst hebben gesloten, waarbij zij de milestone 28 februari 2011 hebben vervangen door een nieuwe milestone die paste bij het uitstel van de Go Live tot 1 oktober
161. Bovendien heeft Alert aan haar stelling dat overeenstemming bestond over dat uitstel, niet de gevolgtrekking verbonden dat JBZ zich daardoor niet langer op de milestone van 28 februari 2011 mocht beroepen. 6.
162. Alert verwijt JBZ dat zij geen tweede testronde heeft willen uitvoeren met v.2.6.0.5, waarvan de release in april 2011 heeft plaatsgevonden en die op 2 mei 2011 voor testen door JBZ beschikbaar was. Alert meent dat de contractuele termijn voor herstel van eventuele gebreken door Alert pas is gaan lopen na het eindrapport van JBZ van 8 juni
163. 6.
164. Het hof heeft (r.o. 3.9.4) het verweer van Alert verworpen dat JBZ in strijd heeft gehandeld met de acceptatieregeling in artikel 9 van de raamovereenkomst, omdat de datum van 28 februari 2011 voor het afronden van de IAT het sluitstuk was van drie testronden. De rechtbank constateert dat v.2.6.0.5 door Alert pas bij JBZ is geïnstalleerd nadat de milestone van 28 februari 2011 was verstreken en zoals hof en rechtbank hebben geoordeeld - alle maximaal drie testronden al hadden moeten zijn uitgevoerd. De overschrijding van die milestone kan daarom niet worden geweten aan een eventuele weigering van JBZ om v.2.6.0.5 te testen. Dit verweer is hooguit van belang in het kader van het verweer van Alert, dat de speciale ontbindingsregeling van artikel 9.1.9 van de raamovereenkomst gaat voor de algemene ontbindingsregeling in artikel 23.1 van die overeenkomst, zodat JBZ niet het recht had om de raamovereenkomst buiten de contractuele acceptatieregeling te ontbinden. Op dat verweer heeft het hof (r.o. 3.12.2) niet beslist, omdat JBZ de raamovereenkomst ook op grond van artikel 23.8 van die overeenkomst heeft ontbonden. De rechtbank zal dit verweer eveneens in het midden laten en eerst beslissen op het beroep van JBZ op artikel 23.8 van de raamovereenkomst. Het beroep op de fatale einddatum 1 januari 2012 6.
165. JBZ beroept zich op artikel 23.8 van de raamovereenkomst, waarin is bepaald dat JBZ de raamovereenkomst tussentijds mocht beëindigen indien Alert er niet in zou slagen de papiervrije status voor 1 januari 2012 te realiseren, en/of indien op enig moment aannemelijk zou worden dat Alert hierin niet tijdig zou slagen. JBZ stelt dat op het tijdstip van de ontbinding duidelijk was dat de papiervrije status op 1 januari 2012 niet meer haalbaar was. Alert voert verweer. 6.
166. De rechtbank stelt vast dat de datum 1 januari 2012 in artikel 23.8 van de raamovereenkomst inderdaad een fatale datum betreft, omdat JBZ bij overschrijding van die datum zonder meer het recht heeft de overeenkomst te ontbinden. Volgens de (gewijzigde) planning in het Change Proposal zou de Go Live bij JBZ echter pas zijn voltooid op 30 september 2012, zodat pas negen maanden na die fatale einddatum 1 januari 2012 sprake zou zijn van een papiervrij ziekenhuis. Het hof heeft geoordeeld (r.o. 3.7.3) dat een redelijke en billijke uitleg van de raamovereenkomst en de daarvan na ondertekening van het derde Addendum deel uitmakende bijlagen meebrengt dat voor zover het nieuw overeengekomen tijdpad door aan Alert toe te rekenen oorzaken niet zou worden nagekomen, terug kon worden gevallen op de oorspronkelijk overeengekomen einddatum van 1 januari
167. De rechtbank neemt dat oordeel over. 6.
168. Het hof heeft vervolgens dat nieuw overeengekomen tijdpad onderzocht en is tot de conclusie gekomen (r.o. 3.9.5) dat JBZ, omdat de resultaten van de FAT in januari/februari 2011 onbevredigend waren, kon stellen dat de fatale termijn van 28 februari 2011 niet was gehaald en dus het in het Change Proposal opgenomen tijdpad niet door Alert was nagekomen. De rechtbank is eerder in dit vonnis tot dezelfde conclusie gekomen. 6.
169. Alert voert als verweer dat het ten tijde van de ontbinding voor partijen nog mogelijk was om de deadline van 1 januari 2012 te halen, hetgeen volgens Alert wordt bevestigd door een in haar opdracht uitgebracht rapport van de Software Improvement Group (hierna SIG) van 3 augustus 2012 (prod. 7 van Alert). De rechtbank verwerpt dit verweer. Het project bij JBZ had grotendeels stilgelegen sinds het conflict dat tussen Alert en JBZ ontstond naar aanleiding van het voorstel van JBZ om de Go Live uit te stellen tot 1 februari
170. Toen JBZ op 3 oktober 2011 de raamovereenkomst ontbond, waren er nog maar drie maanden beschikbaar tot de deadline van 1 januari
171. Ook al zou dat voldoende zijn geweest om alle gebreken in v.2.6.0.3 te herstellen, de herstelversies te testen en de laatste herstelversie te accepteren, was er hoe dan ook onvoldoende tijd om daarna ook nog voor 1 januari 2012 op alle afdelingen van JBZ Live te gaan met Alert® PFH. Voor de Go Live was immers volgens het Change Proposal een periode van ruim 5 maanden nodig (van 15 april 2012 tot 30 september 2012). Het rapport van SIG is voor dit punt niet relevant. 6.
172. Het hof heeft geoordeeld (r.o. 3.11.4) dat het voorstel van JBZ om de Go Live uit te stellen tot 1 februari 2012 niet tot de conclusie leidt dat JBZ daarmee afstand heeft gedaan van de datum van 1 januari 2012 uit artikel 23.8 van de raamovereenkomst, omdat JBZ dit voorstel heeft gedaan in een poging het project Alert® tot een goed einde te brengen en omdat partijen over de datum van 1 februari 2012 geen overeenstemming hebben bereikt. De rechtbank neemt dat oordeel over. 6.
173. Ten slotte heeft het hof (r.o. 3.13) het verweer van Alert verworpen dat JBZ met haar brief van 13 juli 2011 bij Alert het vertrouwen heeft gewekt dat zij nog een kans zou krijgen, omdat Alert die geboden laatste kans niet heeft gegrepen. De rechtbank neemt dat oordeel over. 6.
174. Het voorgaande leidt tot de conclusie dat ten tijde van de ontbinding aannemelijk was dat Alert er niet tijdig in zou slagen om te voldoen aan haar verplichting om voor de overeengekomen datum van 1 januari 2012 een papiervrij ziekenhuis van JBZ te realiseren, waarmee voldaan is aan de ontbindingsgrond van 23.
175. van de overeenkomst. In beginsel is daarom uitgangspunt dat JBZ gerechtigd was de overeenkomst te ontbinden. Is sprake van tekortkomingen van JBZ? 6.
176. Zoals aangegeven onder 6.7 kan van dat uitgangspunt worden afgeweken, indien Alert op haar beurt stelt en zo nodig bewijst dat JBZ is tekortgeschoten in één of meer van de op haar rustende verplichtingen en dit de nakoming door Alert van haar verplichtingen jegens JBZ heeft verhinderd. 6.
177. Alert heeft enkele verwijten gemaakt aan JBZ in verband met de FAT die aanvankelijk in juni 2010 en later in september 2010 zou starten, maar uiteindelijk pas in januari/februari 2011 heeft plaatsgevonden omdat Alert de testomgeving niet stabiel kreeg (zie r.o. 6.15 en 6.16). Alert heeft niet gesteld dat het niet stabiel krijgen van de testomgeving op enige wijze aan JBZ te wijten was. Wel heeft Alert gesteld dat JBZ onvoldoende testers beschikbaar had, maar dat kan hooguit vertraging hebben opgeleverd vanaf 8 december 2010, toen de testomgeving stabiel was geworden en JBZ kon beginnen met testen. De rechtbank is van oordeel dat JBZ geen rechtens relevant verwijt kan worden gemaakt van de omstandigheid dat zij in de drukke maand december onvoldoende testers beschikbaar had. Daarom is niet komen vast te staan dat het eveneens te wijten is aan een tekortkoming van JBZ dat de FAT pas in januari 2011 kon starten. Daarnaast maakt Alert verwijten aan JBZ over de wijze van testen in januari/februari
178. De rechtbank verwerpt die verwijten als niet relevant, omdat na de correctie van de testresultaten door Alert v.2.6.0.3 ook in de eigen ogen van Alert niet acceptabel was. 6.
179. Alert stelt verder dat de release van v.2.6.0.5 op 19 april 2011 heeft plaatsgevonden en dat deze (door SIG beoordeelde) versie op 2 mei 2011 ook op de testomgeving van JBZ beschikbaar was, maar dat JBZ de tweede testronde met v.2.6.0.5 niet heeft willen uitvoeren. In de eerste zaak heeft Alert aangevoerd dat, indien JBZ deze versie had getest, de einddatum 1 januari 2012 nog wel haalbaar zou zijn geweest. 6.
180. De rechtbank constateert dat Alert niet heeft gesteld dat zij v.2.6.0.5 in april/mei 2011 aan JBZ heeft gepresenteerd als de officiële herstelversie bedoeld voor de tweede testronde, laat staan dat Alert heeft aangegeven dat zij van JBZ verwachtte dat die op korte termijn met de tweede testronde zou starten. JBZ hoefde dit niet af te leiden uit het enkele feit van de ter beschikkingstelling van 2 mei 2011 van v.2.6.0.5, omdat uit het eindrapport van Alert over de resultaten van de eerste testronde van dezelfde datum blijkt dat nog maar een beperkt deel van de issues uit de eerste testronde in v.2.6.0.5 was opgelost. Het past ook niet bij het standpunt van Alert dat de contractuele hersteltermijn voor bij die eerste testronde geconstateerde gebreken pas begon te lopen na het eindrapport van JBZ over de eerste testronde van 8 juni
181. Uit dat eindrapport volgt ook dat JBZ (de op 2 mei 2011 ter beschikking gestelde variant van) v.2.6.0.5 niet beschouwde als een officiële herstelversie waarmee zij de tweede testronde zou moeten starten, maar dat zij van Alert verlangde dat die een dergelijke herstelversie uiterlijk eind juni 2011 zou hebben geleverd. Alert heeft niet gesteld dat zij op dit eindrapport van JBZ heeft gereageerd door te stellen dat JBZ toch direct moest beginnen met de tweede testronde. Alert heeft ook niet gereageerd op de overige acties die JBZ in haar eindrapport van Alert verlangde. Integendeel verscheen [projectmanager Alert] vanaf 13 juni 2011 niet meer bij JBZ, waarmee Alert de indruk wekte dat zij niet meer aan herstel van de issues wilde werken zolang er geen overeenstemming was over de financiële voorwaarden die Alert had gesteld voor het door JBZ gewenste uitstel van de Go Live tot 1 februari
182. Aan JBZ kan daarom niet worden verweten dat zij die tweede testronde niet heeft gestart. In het midden kan blijven of v.2.6.0.5 inderdaad, zoals Alert op grond van het SIG-rapport meent, alle functionaliteiten bevatte die in de roadmap voor JBZ waren opgenomen, hetgeen door JBZ wordt betwist onder verwijzing naar een rapport van PricewaterhouseCoopers Advisory N.V. (PWC) van 10 april
183. 6.
184. Alert wijst er bij haar bespreking van het SIG-rapport (10.1.40 e.v. dagv.) ook nog op dat volgens SIG sprake was van een aantal vertragingen, die vooral waren veroorzaakt omdat werkgroepen (die input moesten geven voor de ontwikkeling) later dan gepland bij elkaar kwamen, en omdat JBZ additionele functionaliteiten in de software geïncorporeerd wilde hebben die niet in de eerste roadmap waren verdisconteerd, waarmee Alert heeft ingestemd omdat zij de Nederlandse ziekenhuizen tevreden wilde houden (rechtbank: pagina 5 van het SIG-rapport). 6.
185. De rechtbank constateert dat in de tabel met een overzicht van vertragingen, die op pagina 34 van het SIG-rapport is opgenomen, geen aan JBZ te wijten vertragingen zijn vermeld die pas na het Change Proposal van juli 2010 zijn ontstaan. Nadien is er alleen nog sprake geweest van vertragingen aan de zijde van Alert. Alle vertragingen die volgens het overzicht aan JBZ te wijten zijn, dateren uit de periode van 29 maart 2009 tot 24 april
186. Zij moeten daarom al verdisconteerd zijn geweest in de planning in het Change Proposal. De vertragingen aan de zijde van JBZ kunnen daarom niet hebben veroorzaakt dat Alert de planning in dat Change Proposal niet heeft gehaald. 6.
187. Ten aanzien van het argument van de door JBZ gewenste additionele functionaliteiten is alleen op pagina 36 van het SIG-rapport een overzicht van die additionele functionaliteiten opgenomen. Alert heeft niet gesteld dat JBZ ook na het Change Proposal van juli 2010 nog extra functionaliteiten van Alert heeft verlangd, laat staan dat het die nieuwe extra functionaliteiten waren die hebben veroorzaakt dat Alert de testomgeving niet stabiel kreeg en/of dat v.2.6.0.3 gebrekkig was. 6.
188. De conclusie uit het voorgaande moet zijn dat niet is komen vast te staan dat JBZ is tekortgeschoten in één of meer van de op haar rustende verplichtingen en dat dit de nakoming door Alert van haar verplichtingen jegens JBZ heeft verhinderd. JBZ heeft zich terecht op artikel 23.8 van de raamovereenkomst beroepen en daarom is de overeenkomst rechtsgeldig ontbonden. 6.
189. Aan de overige argumenten van JBZ voor de ontbinding zoals genoemd onder 3, 4 en 5 in r.o. 6.8 en aan het subsidiaire beroep van JBZ op opzegging komt de rechtbank niet toe. De individuele onrechtmatige daad van JBZ 6.
190. Naar aanleiding van het arrest van het hof heeft Alert op de comparitie een nieuwe grondslag voor haar vorderingen tegen JBZ aangevoerd, die uitgaat van het gegeven dat JBZ de raamovereenkomst op 1 maart 2011 mocht ontbinden omdat Alert de fatale milestone van 28 februari 2011 niet had gehaald. De rechtbank stelt vast dat het arrest van het hof een dergelijk oordeel niet inhoudt, omdat het hof de ontbinding op grond van alleen artikel 23.8 van de raamovereenkomst heeft goedgekeurd. Het niet halen van de milestone 28 februari 2011 heeft echter wel indirect bijgedragen aan de ontbinding, omdat het hof heeft beslist dat een redelijke uitleg van de raamovereenkomst en het Addendum meebrengt dat, voor zover het nieuw overeengekomen tijdpad (waaronder de milestone 28 februari 2011) door aan Alert toe te rekenen oorzaken niet wordt nagekomen, terug kon worden gevallen op de oorspronkelijk overeengekomen einddatum van 1 januari
191. De rechtbank zal deze nieuwe grondslag in dat licht beoordelen. 6.
192. Alert stelt dat JBZ onrechtmatig heeft gehandeld jegens Alert door niet direct na 28 februari 2011 consequenties te verbinden aan de overschrijding van de milestone van 28 februari
193. Alert wijst erop dat de rechten en verplichtingen van contractspartijen ten opzichte van elkaar niet alleen worden bepaald door hetgeen zij uitdrukkelijk zijn overeengekomen, maar ook door de redelijkheid en billijkheid die hun rechtsverhouding beheerst (Hoge Raad 19 oktober 2007, ECLI:NL:HR:2007:BA7024). Alert meent dat JBZ deze norm heeft geschonden door niet aan Alert duidelijk te maken dat Alert direct in verzuim was, waarmee JBZ de zeer hoge belangen van Alert op onaanvaardbare wijze heeft veronachtzaamd. Alert stelt zich op het standpunt dat JBZ in redelijkheid gebruik had moeten maken van een van de volgende scenario’s: 1) JBZ had de raamovereenkomst direct na 28 februari 2011 kunnen ontbinden, waarna de gezamenlijke actie van de ziekenhuizen niet zou hebben plaatsgevonden, Alert niet aan het project verder zou hebben gewerkt en dus ook geen grote operationele kosten zou hebben gemaakt, en het beeld in de media minder destructief voor Alert zou zijn geweest omdat dan alleen zou zijn gemeld dat Alert een termijn niet had gehaald; 2) JBZ had kunnen kiezen om te vermelden dat Alert een fatale termijn had overschreden en nakoming van de overeenkomst te vorderen zonder de overeenkomst open te breken, waarna Alert en JBZ overeenstemming zouden hebben bereikt over een nieuwe fatale termijn en het project succesvol zouden hebben afgerond; 3) JBZ had voor de voortzetting van het project nadere eisen zoals die in de LOI kunnen stellen onder dreiging van ontbinding, waarna Alert in het volle besef van de consequenties had kunnen kiezen om al dan niet met die eisen in te stemmen, Alert en JBZ alsnog overeenstemming zouden hebben bereikt en het project succesvol zou zijn afgerond. 6.
194. JBZ voert verweer. 6.
195. De rechtbank is van oordeel dat JBZ niet onrechtmatig heeft gehandeld door niet te kiezen voor het eerste scenario van Alert. Het was juist in het belang van Alert als contractuele wederpartij van JBZ dat JBZ de raamovereenkomst niet direct na 28 februari 2011 ontbond, maar pogingen deed om het project vlot te trekken door voorstellen voor nieuwe planningen te doen. Indien die pogingen zouden zijn gelukt, had Alert de kans gekregen het project succesvol af te ronden en zou zij in een veel betere situatie hebben verkeerd dan bij directe ontbinding. De omstandigheid dat achteraf is gebleken dat de onderhandelingen zijn mislukt, maakt de keuze van JBZ voor onderhandelen niet alsnog onrechtmatig. 6.
196. JBZ heeft evenmin onrechtmatig gehandeld door niet te kiezen voor het tweede scenario. Dat scenario komt feitelijk neer op het standpunt dat JBZ na haar eerste voorstel van uitstel van de Go Live tot 1 oktober 2011 een overeenkomst met Alert had moeten sluiten over een daarbij passende nieuwe milestone voor het einde van de IAT, en niet meer had mogen voorstellen om de Go Live verder uit te stellen tot 1 februari
197. De rechtbank verwerpt dat standpunt. Het eerste uitstelvoorstel van JBZ tot 1 oktober 2011 was voornamelijk in het voordeel van Alert, die daarmee meer tijd zou krijgen om alsnog een versie van Alert® PFH te leveren die aan alle overeengekomen eisen voldeed. Vervolgens realiseerde JBZ zich dat haar eerste voorstel in strijd was met haar eigen belangen, omdat haar ICT-medewerkers nodig waren voor de verhuizing naar de nieuwbouw. JBZ handelde niet onrechtmatig door haar eerste uitstelvoorstel te vervangen door haar tweede uitstelvoorstel, waarin zij óók met haar eigen belangen rekening hield. Bij haar tweede uitstelvoorstel heeft JBZ niet aangegeven dat zij de overeenkomst wilde openbreken. Het was Alert zelf die dat als eerste heeft aangegeven door financiële voorwaarden te stellen. 6.
198. Ook het niet kiezen voor het derde scenario kan niet worden aangemerkt als onrechtmatig handelen van JBZ. Naar het oordeel van de rechtbank handelt een contractspartij in beginsel niet onrechtmatig, indien zij in het kader van onderhandelingen over aanpassing van een overeenkomst haar wederpartij niet informeert over haar mogelijkheid om de oorspronkelijke overeenkomst te beëindigen. Dat zou alleen anders kunnen zijn onder bijzondere omstandigheden. Van dergelijke bijzondere omstandigheden is hier geen sprake. Alert is een commerciële partij die tijdens de onderhandelingen juridische bijstand had en die de contractuele bepaling kende op grond waarvan JBZ meende het recht op ontbinding te hebben. 6.
199. De rechtbank concludeert dat de nieuwe grondslag van Alert moet worden verworpen. Conclusie 6.
200. Het voorgaande leidt tot de conclusie dat JBZ de raamovereenkomst terecht heeft ontbonden en dat JBZ niet individueel onrechtmatig jegens Alert heeft gehandeld op de door Alert ter comparitie nieuw gestelde grondslag. De vraag of er sprake is van een gezamenlijke onrechtmatige daad van de ziekenhuizen en/of een onrechtmatige daad van JBZ ter zake het verwijt over mededelingen aan de pers, zal de rechtbank later in dit vonnis bespreken. DE ZAAK TEGEN BERNHOVEN 7Nadere feiten ten aanzien van Bernhoven 7.
201. Bernhoven wilde haar oude systeem X/Care vervangen door een moderner ZIS en EPD, dat haar bovendien de mogelijkheid zou bieden om papiervrij te gaan werken. In de nieuwbouw in Uden, waarnaar zij haar ziekenhuizen in Veghel en Oss wilde verhuizen, was niet voorzien in opbergruimten voor papieren dossiers. In 2007 verkoos Bernhoven Alert als preferente leverancier. Daarna volgde een periode van onderzoek, waarin Alert diverse demonstraties aan Bernhoven gaf en Bernhoven werkbezoeken bracht in Portugal. 7.
202. Alert en Bernhoven voerden een gapanalyse uit om te onderzoeken welke door Bernhoven gewenste functionaliteiten al in Alert® PFH aanwezig waren en in welke van die gewenste functionaliteiten al was voorzien in de roadmap die Alert had opgesteld voor JBZ. Op 1 december 2008 maakte Alert versie 1 van een roadmap (prod. 96 van Alert), waarin was vermeld in welke nieuwe releases van Alert® PFH de door Bernhoven noodzakelijk geachte functionaliteiten zouden worden opgenomen. Deze roadmap vermeldde vier releasedata: 30 april 2009, 30 september 2009, 28 februari 2010 en 31 december 2010 (dezelfde releasedata die Alert bij JBZ in oktober 2008 noemde). 7.
203. Op 11 december 2008 ondertekenden Alert en Bernhoven een raamovereenkomst over de levering onder licentie, de implementatie en het onderhoud van Alert® PFH (Engelstalige versie prod. 97 van Alert en Nederlandstalige versie prod.1 van Bernhoven; ingevolge artikel 31.11 van de raamovereenkomst is de Nederlandse tekst doorslaggevend). Volgens Alert werd deze overeenkomst gesloten op 21 november 2008 (de op de eerste pagina vermelde datum van “version 0.5”), maar volgens Bernhoven gebeurde dat op 11 december 2008 (de datum van ondertekening). Bernhoven had het eerste concept voor de raamovereenkomst aangeleverd, waarna Alert en Bernhoven over de tekst hadden onderhandeld en meerdere concepten hadden uitgewisseld. 7.
204. In artikel 26.8 van de raamovereenkomst was opgenomen dat Bernhoven deze overeenkomst te allen tijde tussentijds kon beëindigen met opgave van reden aan Alert, indien Alert er niet in zou slagen om de papierloze status te realiseren conform de in het projectplan vermelde planning en/of indien op enig moment aannemelijk zou worden dat Alert hierin niet tijdig zou slagen. Deze bepaling hield verband met de wens van Bernhoven om Alert® PFH ruimschoots voor de toen nog in 2012 geplande - verhuizing naar de nieuwbouw in Uden in gebruik te nemen, zodat haar medewerkers konden wennen aan het nieuwe papiervrije systeem voordat de verhuizing zou plaatsvinden. 7.
205. Op 16 maart 2009 werd het bedoelde projectplan vastgesteld onder de naam Implementatieplan v.3.2 (prod. 2 van Bernhoven). Op pagina 11 van dit plan is een schema met een implementatiescenario opgenomen, waarboven is vermeld “Als beoogd implementatiescenario is vooralsnog vastgesteld:”. Dit scenario hield samengevat in: - start van het project: 2 februari 2009 - Go Live Interfacing Architecture: 31 juli 2009 - Go Live op de SEH met de modules EDIS en ADW: 30 oktober 2009 - Go Live op de drie afdelingen Mamma Care, Diabetes Care en Gynaecologie met de modules Inpatient, Outpatient en ADW: 20 en 27 november 2009: - Go Live op de afdeling ICU met de modules Inpatient en PDMS: 30 april 2010 - Go Live op de SEH met de module PDMS: 20 mei 2010 - Go Live op de OK/Anesthesiologie met de modules ORIS, ADW en PDMS: 25 juni 2010 - Go Live op de overige afdelingen met de modules Inpatient en Outpatient (“big bang”) en ziekenhuisbrede Go Live met de modules APS, DBC en ADW: 2 september 2011 - Go Live van een webportaal voor patiënten en huisartsen: 7 oktober 2011 - Einde project: 30 december
206. 7.
207. Deze planning was gebaseerd op de volgende releaseplanning voor Alert® PFH: - release 2.4.4: 30 april 2009 - release 2.4.5: 30 september 2009 - release 2.4.6: 26 februari 2010 - release 2.4.7 en 2.4.8: 31 december
208. (Deze releasedata zijn gelijk aan de releasedata die waren vermeld in de roadmap van 1 december 2008.) 7.
209. Bernhoven koos ervoor om al met v.2.4.4 (later hernummerd tot v.2.5) van Alert® PFH Live te gaan op de SEH, hoewel in die versie nog niet alle functionaliteiten zaten die voor die SEH nodig waren. Voor de Go Live op (een deel van) de andere afdelingen zouden latere releases worden gebruikt. Alert diende zorg te dragen voor diverse interfaces, waaronder koppelingen met de software gebruikt op de afdelingen Laboratorium en Radiologie, zodat de SEH via Alert® PFH onderzoeken kon aanvragen en de resultaten van die onderzoeken via Alert® PFH kon inzien. Daarnaast moesten de gegevens uit het oude systeem X/Care worden overgezet naar Alert® PFH. Deze datamigratie zou gefaseerd plaatsvinden. Ten slotte moest Alert zorgen voor in ieder geval een tijdelijke interface tussen Alert® PFH en X/Care, zodat er een doorlopende gegevensuitwisseling tussen de beide systemen kon plaatsvinden (synchronisatie) zolang X/Care nog door andere afdelingen van Bernhoven werd gebruikt. 7.
210. De datamigratie bestond uit het ophalen van gegevens uit de oude database van X/Care (extractie), het voor zover nodig omzetten van die gegevens in een formaat dat door Alert® PFH kan worden gebruikt (conversie) en het verplaatsen van de geconverteerde gegevens naar de database van Alert® PFH. Bij de andere ziekenhuizen werd deze datamigratie volledig uitgevoerd door de ziekenhuizen zelf met de hulp van ingehuurde externe deskundigen, maar bij Bernhoven zou de datamigratie tenminste gedeeltelijk worden uitgevoerd door Alert. Volgens Bernhoven was overeengekomen dat Alert de datamigratie volledig zou verrichten en dat Bernhoven alleen de database van X/Care en de voor de extractie noodzakelijke informatie aan Alert hoefde te verschaffen. Volgens Alert diende Bernhoven echter contractueel de extractie zelf te verrichten, maar nam Alert dat werk in de praktijk over omdat Bernhoven niet over de daarvoor noodzakelijke mankracht beschikte. Hoe dan ook werd de extractie vanaf het begin feitelijk verricht door de [consultant van Alert] , consultant van Alert. Nadat Bernhoven daartoe toestemming had gekregen van de leverancier van X/Care, zond Bernhoven in januari 2009 de database van X/Care naar [consultant van Alert] . In juli 2009 zond Bernhoven aan Alert de definitieve versie van de te migreren gegevens, voorzien van zgn. query’s (code waarmee scripts konden worden ontwikkeld, software waarmee de extractie kon worden uitgevoerd). [consultant van Alert] voerde de werkzaamheden voor de datamigratie uit in een speciale migratie-omgeving. Daarna werden de data overgezet naar een preproductie-omgeving, waar de gemigreerde data door Bernhoven konden worden getest. Na acceptatie door Bernhoven werden de voor de eerste Go Live op de SEH noodzakelijke data overgezet naar de productie-omgeving waarmee Bernhoven Live ging. 7.
211. Op een vergadering van het projectmanagementteam (bij andere ziekenhuizen werd dit de stuurgroep genoemd en ook bij Bernhoven werd in Engelstalige stukken de benaming “Steering Committee” gebruikt) van 19 mei 2009 (prod. 59-C van Bernhoven) werd besproken dat de release van v.2.5 (voorheen v.2.4.4) was uitgesteld tot juli 2009 en dat in de twee maanden daarna nog fixes met aanvullende functionaliteiten zouden volgen. Release v.2.6 (voorheen v.2.4.5) werd uitgesteld van september/oktober 2009 tot december 2009 en zou een aantal functionaliteiten bevatten die voor de volgende release waren gepland. Bernhoven, die eerder had besloten v.2.6 niet te installeren, zou die beslissing moeten heroverwegen. (De rechtbank begrijpt dat Bernhoven aanvankelijk had besloten de Go Live voor in ieder geval de big bang pas met v.2.4.6 uit te voeren, en dat Bernhoven na de verplaatsing van 75% van v.2.4.6 naar v.2.6.0 (voorheen v.2.4.5) ten behoeve van JBZ moest beslissen of zij net als JBZ al Live kon gaan met v.2.6.0, dan wel voor die Go Live toch functionaliteiten nodig had die pas in v.2.6.1 aanwezig zouden zijn.) 7.
212. In juli 2009 kwam v.2.5 voor Bernhoven beschikbaar. Bernhoven testte v.2.5, de aangekondigde latere fixes en nieuwe versies waarin Alert een deel van de door Bernhoven gemelde issues oploste. 7.
213. In september 2009 besloot Bernhoven om de Go Live op de SEH uit te stellen van de in het Implementatieplan vermelde datum 30 oktober 2009 tot begin februari 2010, omdat er stagnatie was opgetreden bij met name de datamigratie. Alert zette hierna vier extra medewerkers in voor die datamigratie (een Nederlandse medewerker en drie Portugese medewerkers). Toen de nieuwe Go Live naderde, was echter het voor de SEH noodzakelijke deel van de datamigratie nog steeds niet helemaal voltooid, waren de interfaces nog niet beschikbaar en waren ook nog niet alle issues uit de testen opgelost (volgens Bernhoven hadden alle issues bij de Go Live moeten zijn opgelost, maar volgens Alert was afgesproken dat slechts een deel van de issues hoefde te zijn opgelost en was dat ook gebeurd). Bernhoven besloot de Go Live toch door te laten gaan met een beperkt systeem, in de verwachting dat zes tot acht weken later in ieder geval de interfaces beschikbaar zouden zijn en de voor de SEH noodzakelijke datamigratie zou zijn voltooid. 7.
214. De Go Live op de SEH met (een hotfix van) v.2.5.0.7.6 startte op 2 februari 2010 in het ziekenhuis in Veghel en op 5 februari 2010 in het ziekenhuis in Oss. 7.
215. Na de ingebruikname van Alert® PFH ontstond grote ontevredenheid bij de medewerkers van de SEH. Het moeten werken met een beperkt systeem leverde extra werk voor die medewerkers op, terwijl er juist een tekort was aan SEH-verpleegkundigen. Men had moeite met het wennen aan de nieuwe werkwijze die het werken met Alert® PFH meebracht, waardoor men soms gegevens verkeerd invoerde om toch de oude werkwijze te kunnen toepassen. Ook het handmatig moeten invoeren van gegevens van de afdelingen Laboratorium en Radiologie leidde tot verkeerde invoer. De inzet van zgn. key-users (collega’s met kennis van Alert® PFH die uitleg en bijstand kunnen geven bij het werken met de nieuwe software) werd gemist, waardoor de afdeling Applicatiebeheer van Bernhoven werd overvraagd en verkeerde invoer niet werd voorkomen. Specialisten van andere afdelingen die door arts-assistenten voor een consult op de SEH werden opgeroepen, weigerden de inhoud van hun consult zelf in te voeren in Alert® PFH en vroegen de arts-assistent dat te doen, terwijl Alert® PFH dat niet aan de aanvrager van het consult toestond. Er waren ook klachten over de medische rapportage in Alert® PFH, die op basis van input van werkgroepen van Bernhoven was ontwikkeld. Een deel van de klachten over de medische rapportage werd veroorzaakt door verkeerd ingevoerde gegevens, die daardoor niet op de juiste plaats in de medische rapportage werden getoond. 7.
216. In de periode daarna probeerden Alert en Bernhoven de problemen op de SEH op te lossen. Bernhoven zette extra personeel in om de key-users alsnog vrij te maken en Alert bood extra begeleiding. Aan medisch specialisten werd tijdelijk toegestaan hun consult schriftelijk vast te leggen. Besloten werd om de klachten over de medische rapportage in twee fasen op te lossen: de eerste fase zou in maart 2010 worden uitgevoerd en de tweede fase, waarvoor twee wijzigingen in de software nodig ware