ECLI:NL:GHSHE:2015:4428

Uitspraak

GERECHTSHOF ’s-HERTOGENBOSCH

Afdeling civiel recht

zaaknummer HD 200.149.803/01

arrest van 3 november 2015

in de zaak van

Stichting Tweesteden Ziekenhuis,

gevestigd te [vestigingsplaats 1] ,

appellante in principaal hoger beroep,

geïntimeerde in incidenteel hoger beroep,

hierna aan te duiden als TsZ,

advocaat: mr. F.A.M. Knüppe te Arnhem,

tegen

Alert Life Sciences Computing B.V.,gevestigd te [vestigingsplaats 2] ,

Alert Life Sciences Computing S.A.,gevestigd te [vestigingsplaats 3] , Portugal,

geïntimeerden in principaal hoger beroep,

appellanten in incidenteel hoger beroep,

hierna aan te duiden als Alert c.s.,

advocaat: mr. J.J. Linnemann te Amsterdam,

op het bij exploot van dagvaarding van 16 januari 2014 ingeleide hoger beroep van het vonnis van de rechtbank Oost-Brabant van 27 november 2013, ECLI:NL:RBSHE:2013:6627, gewezen tussen TsZ als eiseres en Alert c.s. als gedaagden.

1. Het geding in eerste aanleg (zaak- en rolnummer C/01/244606/HA ZA 12-256)

Voor het geding in eerste aanleg verwijst het hof naar voormeld vonnis en het tussenvonnis van 28 november 2012, ECLI:NL:RBSHE:2012:BY4266 (afwijzing vordering ex artikel 843a Rv), en het comparitievonnis van 6 februari 2013.

2. Het geding in hoger beroep

Het verloop van de procedure blijkt uit:

de dagvaarding in hoger beroep;
het exploot van anticipatie van 23 mei 2014;
de memorie van grieven, met de producties 52 tot en met 67;
de memorie van antwoord, tevens memorie van grieven in incidenteel hoger beroep, met de producties 58 tot en met 98;
de memorie van antwoord in incidenteel hoger beroep, met de producties 68 tot en met 77;
de akte van Alert c.s. d.d. 2 december 2014 houdende overlegging productie met nummer 99;
de akte van Alert c.s. d.d. 2 juli 2015 houdende overlegging aanvullende producties voor pleidooi, met de nummers 99 tot en met 102;
het pleidooi, gehouden op 2 juli 2015 waarbij partijen pleitnotities hebben overgelegd.

Het hof heeft daarna een datum voor arrest bepaald. Het hof doet recht op bovenvermelde stukken en de stukken van de eerste aanleg.

3. De beoordeling

in principaal en incidenteel hoger beroep

De rechtbank heeft in rechtsoverweging 2 van het bestreden vonnis de volgende feiten vastgesteld. Deze zijn in hoger beroep op zich zelf genomen niet betwist, maar wel wordt de uitleg en waardering van die feiten aan de orde gesteld. Het hof zal deze feiten tot uitgangspunt nemen.

2.1. TsZ is een algemeen, regionaal opleidingsziekenhuis met vestigingen in [vestigingsplaats 1] en [vestigingsplaats 4] . TsZ biedt werk aan ruim 2.000 medewerkers en 130 medisch specialisten.

2.2. Alert Portugal houdt zich bezig met het ontwikkelen, leveren en onderhouden van software ten behoeve van de gezondheidszorg. Voor ziekenhuizen biedt zij een integraal ICT-systeem waarmee alle zorgprocessen – zoals klinische documentatie, medische orders, verslaglegging, planning, rapportages en facturatie – worden gedigitaliseerd en uiteindelijk een papierloze omgeving (
‘paper free hospital’) ontstaat. De software van Alert c.s. bestaat uit verschillende, onderling koppelbare modules.

2.3. Alert Nederland is een dochtervennootschap van Alert Portugal. Zij richt zich op de implementatie van de software van Alert c.s. op de Nederlandse zorgmarkt.

2.4. In het najaar van 2007 neemt TsZ het besluit om het bestaande ICT-systeem van het ziekenhuis te gaan vervangen door een modern, ‘3e generatie’ Elektronisch Patiënten Dossier (EPD). Zij legt haar pakket van eisen en wensen aangaande het nieuw aan te schaffen EPD schriftelijk vast in een
Request for Informationvan 21 april 2008 (hierna: RFI) en een
Request for Proposalvan 15 oktober 2008 (hierna: RFP). Op basis van deze stukken, waarin TsZ uitgebreide informatie heeft opgenomen omtrent haar organisatie, haar administratieve processen, de bestaande ICT-omgeving en haar technische infrastructuur, gaat TsZ in gesprek met een aantal leveranciers, waaronder Alert c.s.

2.5. Eind oktober 2008 brengt Alert c.s. een schriftelijke offerte uit aan TsZ, waarin zij tevens antwoord geeft op de vragen uit het RFI en het RFP. Alert c.s. schrijft daarin onder meer:

(pg. 5)

“Aangezien Alert®PFH een buitenlandse productsuite is, zijn wij 9 maanden geleden gericht met een tweetal Nederlandse ziekenhuizen (1 iSoft-ziekenhuis (1.100 bedden) en 1 McKesson ziekenhuis (470 bedden); het iSoft-ziekenhuis (Jeroen Bosch Ziekenhuis) heeft inmiddels het contract getekend; met het McKesson ziekenhuis zijn wij in de eindfase van contractonderhandeling) van start gegaan in een verdiepingsslag, teneinde te komen tot een ‘gap list’ en een daaruit voortvloeiende ‘roadmap’. Deze Roadmap is inmiddels voorzien van een planning, geaccordeerd en gecommitteerd. Wij zullen de komende maanden functionaliteit opleveren c.q. productaanpassingen doen, die in lijn zijn met de eisen en wensen van de Nederlandse zorgmarkt w.o. de Nederlandse wet- & regelgeving, en die in lijn is met de projectplanning, ambities en uitdagingen van de Nederlandse ziekenhuizen die gebruik zullen gaan maken van deze functionaliteit. Voorbeelden van items uit de Roadmap zijn o.a. DBC-functionaliteit (afleiden van DBC’s), complicatie-registratie, registratie met UZI-pas, faciliteren van BSN, GBZ-eisen, NEN7510, etc.”

(pg. 15)

“Met de (mogelijke) invoering van Alert®PFH zal fasegewijs een situatie ontstaan waarbij TweeSteden Ziekenhuis een (vrijwel) volledig digitale statusvoering doet en er een papierloze/papierarme werkomgeving ontstaat.”

(pg. 28)

“De papierloze werkwijze wordt vanaf de start van GoLive gehanteerd.”

2.6. In de periode december 2009 – januari 2010 komen TsZ en Alert c.s. overeen dat Alert c.s. aan TsZ een geïntegreerd computersysteem zal leveren waarmee zij de volledige bedrijfsvoering en het primaire proces van het ziekenhuis kan reguleren (hierna: de Software). De Software bestaat uit een ziekenhuisinformatiesysteem en een 3e generatie EPD. Partijen leggen de gemaakte afspraken vast in een raamovereenkomst en een aantal bijlagen (hierna gezamenlijk: de Framework Agreement). In de Framework Agreement is onder meer het volgende bepaald:

“(…)

1.Definitions

(…)

1.5. “ALERT® Product”: shall mean the following list of products:

ALERT® PAPER FREE HOSPITAL

(…)

ALERT®PHARMACY Clinical

(…)

1.28a “Specifications” The specifications which the Software and the other products and Services to be delivered must satisfy, as recorded in (in chronological order) the RFI, the answers to the RFI, the RFP, the answers to the RFP, the proposal and the Implementation Plan. In case of inconsistencies between two documents, the most recent mutually agreed document shall prevail.

(…)

1.33.Statutory rules and Regulations

The statutory rules and regulations with which Customer must comply, as well as instructions and standards, communication protocols and classification systems given or imposed by the central (Dutch or European) government and/or provincial authorities, by national (medical) umbrella organizations, medical science societies and similar organizations (such as DICOM, HL7, NEN 7510, Burger Service Nummer, Unieke Zorgverlener Identificatie, NICTIZ, and the like), which may affect the functioning of the Software covered by this Agreement and which the Customer must follow/comply with and/or provide.

3.Terms and subject of the Agreement

3.1

This Agreement, taking effect on the date of its execution, is made for an indefinite term.

3.2

Notwithstanding any other provision in this Agreement, an Appendix or a Subsequent Agreement, this Agreement cannot be terminated on or prior to sixty (60) months as of signing this Agreement.

3.3

With due observance of Article 3.2 the Parties will be entitled to give written notice of termination of the Agreement, observing a notice period of one year for the Customer and two years for ALERT.

3.4

This Agreement pertains to the supply, making available, licensing and the Installation and Implementation of the Software by ALERT, as well as the Management and Maintenance of the Software and the supply of the Services related to the same. These activities will be carried out in accordance with the terms set out in this Agreement and the Subsequent Agreements and Appendices, including the Implementation Plan.

5.Performance of the Implementation Services

5.1.

In collaboration with Customer, ALERT will arrange for the due Implementation of the Software in the Customer’s organization. The Implementation will be effected uninterruptedly, unless in specific cases the Implementation Plan provides otherwise, with maximum commitment and deployment of the required and available ALERT and Customer’s staff, and will be completed within the terms and budget set by the Implementation Plan and attachment 1.16 (Fees). Customer shall grant the required cooperation for Implementation, meaning that it will make available machine capacity and manpower in accordance with the provisions of the Implementation Plan. ALERT agrees to provide the Services and such related services as may be agreed between the parties from time to time, however ALERT reserves the exclusive right to determine the personnel and the allocation and substitution of personnel engaged in the performance the Services hereunder, in line with the Implementation Plan. (…)

5.3.

ALERT shall at all times, upon the terms and conditions of this Agreement:

(a) perform, provide and deliver Services and Deliverables to the Customer and to develop the Software in accordance with the functional requirements set in the Implementation Plan.

(b) – (c) (…)

6.Preparatory, Implementation and On-site Services and Schedules

6.1.

Subject to the terms and conditions of the Agreement, ALERT undertakes to supply the Software and provide the Services, within a time frame agreed upon between the Parties in the Implementation Plan. (…)

6.2.

The Parties agree the outlined plan included in the Implementation Plan in Attachment 1.18 may be subject to revision during the preparation and implementation phases.

6.3.

The Parties shall jointly agree and approve the Implementation Plan, conforming to the time schedule and sequence of events necessary for the installation and for the achievement of the Paper-Free Status. The Parties shall keep the Implementation Plan updated, showing the expected and actual events and completion dates. (…)

6.4.

The Parties acknowledge that timely performance of their obligations under this Agreement is mutually dependent on the other Party’s cooperation and the ability of ALERT to develop the Customer System with the installation of the Software and each Party hereby warrants and undertakes to the other to work in good faith to resolve any delays and/or failures, to perform in a commercially reasonable manner, with the overall objective of enabling the other Party to complete its obligations set forth in this Agreement. In furtherance of such commercial objectives, ALERT shall notify the Customer Project Manager of any expected delay in any activity undertaken by ALERT pursuant to this Agreement; and ALERT shall refer, within a reasonable time, to the Customer Project Manager any matter, in ALERT’s opinion, which is likely to impede the progress of the Services and the achievement of the Paper Free Status.

6.5.

Where ALERT requires the Customer’s input or the Customer to perform its obligations in order for ALERT to be able to perform its obligations, ALERT shall:

(a) advise the Customer as to the input which ALERT requires or the obligation which ALERT requires the Customer to fulfil;

(b) indicate to the Customer when ALERT reasonably expects the Customer to respond to ALERT’s request.

6.6.

If the Customer is not able to fulfil the requirements as defined in Article 6.5 herein, ALERT is entitled to request for more time in the Implementation Plan, which will not be unreasonably denied by the Customer.

11.Software Acceptance

11.1.

ALERT and Customer shall perform System Tests and Acceptance Tests (hereinafter “AT”) to ensure that the Deliverables and Software are in compliance with the Specifications, in accordance with the Implementation Plan. The AT shall be conducted by ALERT and Customer.

(…)

11.4.

Acceptance. Within fourteen (14) days of completion of the AT pursuant to clause 11.1. the Customer shall either:

(a) acknowledge in writing to ALERT that the Deliverable thus tested has satisfied the AT and has been accepted; or

(b) where AT has not been satisfactory, provide ALERT with a list of bugs, defects and/or failures.

11.5.

Retest. When written notice has been provided for in accordance with clause 11.4, ALERT shall fix such bugs, defects and/or failures in a timely manner and in accordance with the Requirements. (…)

(…)

11.7

Third Rejection. In case Customer rejects the Software or any element thereof on account of defects found after a third Acceptance Test, Customer shall have the right to – provisionally or in part, if applicable – terminate the Agreement without judicial intervention. In that event, ALERT shall be liable for damages in accordance with article 20 hereunder.

13.Termination

13.1.

Termination for cause. Without limiting any other rights or remedies available to the Parties, at law or an equity and without prejudice to what is set forth in this Agreement, namely under Clause 6.6. and Clause 12.8., either Party has the right to terminate this Agreement giving prior written notice to the other Party (the “Defaulting Party”), if:

a)
the Defaulting Party is in breach or default of any of its material obligations under this Agreement and such breach or default continues un-rectified for sixty (60) days following the Dispute Resolution Process non Defaulting Party shall terminate this Agreement;

b)
(…)

c)
(…)

d)
Any representations or warranty contained herein shall be false or misleading in any material respect as of the date made or deemed to have been made.

e)
(…).

13.2..-13.5. (…)

19.Warranties and Undertakings

Furthermore, ALERT warrants and undertakes that:

-
The Software will be fit for normal use by the Customer and for the objects set out in the Implementation Plan, for which the Customer acquired the Software,

-
As per the Go-Live date, the Software will have the agreed properties and will satisfy the Specifications, at peak hours also;

-
(…)

-
The Software is fit to be used for proper exchange of data with third parties, as far as indicated in the Specifications or Implementation Plan;

-
(…).

19.2.- 19.4. (…)

30.General

30.2.

Precedence. The documents comprising this Agreement shall be read in the following order of precedence (a) the Clauses of this Agreement, (b) the Attachments. When any conflict occurs between the provisions contained in two or more of the documents forming this Agreement, the document lower in the order of precedence shall, when possible, be interpreted in accordance with the document higher in precedence and its whole content and meaning. (…)

30.3-30.11 (…)”

2.7.

Ten tijde van het sluiten van de Framework Agreement is de – oorspronkelijk Portugese – software van Alert c.s. nog niet gereed voor implementatie in een Nederlandse ziekenhuisorganisatie. Dit komt onder meer omdat de Nederlandse zorgmarkt, anders dan de Portugese, wordt gefinancierd via diagnosebehandelcombinaties (DBC’s). Beide partijen gaan er echter vanuit dat de uitbreidingen en aanpassingen die noodzakelijk zijn om de Software te kunnen implementeren binnen de organisatie van TsZ, zullen worden ontwikkeld door Alert c.s. volgens de ‘Roadmap’ die Alert c.s. in samenwerking met haar ‘launching customer’ en ontwikkelpartner Jeroen Bosch Ziekenhuis heeft opgesteld.

2.8.

In de periode maart-juni 2010 verrichten partijen een zogenaamde ‘scoping analyse’. Het resultaat daarvan is een document waarin per deelfunctionaliteit is vastgelegd aan welke functionele en technische eisen de te leveren Software zal moeten voldoen (Bijlage 1 bij het Implementatieplan).

De deelfunctionaliteiten in de scoping analyse zijn door Alert c.s. ingedeeld in de volgende drie categorieën:

( a) de functionaliteit wordt al ondersteund in de huidige versie van de Software

(antwoord =
‘yes’);

( b) de functionaliteit wordt nog niet ondersteund en is ook niet voorzien in latere versies

(antwoord = ‘
no’)

( c) de functionaliteit wordt nog niet ondersteund maar is wel voorzien in een latere versie

(antwoord =
‘Roadmap’).

De deelfunctionaliteiten uit de categorie
‘no’die volgens TsZ absoluut noodzakelijk zijn om met de Software te kunnen werken, zijn door partijen gelabeld als
‘Needs deel 1’(Bijlage 2 bij het Implementatieplan).

2.9.

Op 15 juli 2010 komt de Stuurgroep van het project bijeen. Uit de notulen van deze vergadering blijkt dat het implementatieplan op dat moment voor 95% gereed is, maar dat de definitieve vaststelling ervan wordt opgeschoven naar (uiterlijk) 1 augustus 2010.

2.10.

Op 22 juli 2010 wordt het ‘EPD implementatieplan’ definitief vastgesteld (Bijlage 1.18 bij de Framework Agreement, hierna: het Implementatieplan). Het Implementatieplan wordt hiermee onderdeel van het Framework Agreement. Het Implementatieplan voorziet in de aanpak en planning van het eerste gedeelte van het project: het ziekenhuisbreed vervangen van het bestaande ziekenhuisinformatiesysteem (ZIS). Deel 2 van het project, de vernieuwingsslag die TsZ met de Software wil realiseren, is in het Implementatieplan nog niet uitgewerkt.

2.11.

Project Deel 1 is in het Implementatieplan onderverdeeld in drie parallel lopende deelprojecten: Primair Proces, Techniek en Projectstandaarden. Het deelproject Primair Proces, dat is gericht op het vaststellen van de randvoorwaarden voor implementatie, is opgedeeld in drie fasen: eerst ziekenhuisbreed (fase 1), dan voor de zorgprocessen op de SEH, de OK en in de Kliniek en de Polikliniek (fase 2) en ten slotte op het niveau van de organisatorische of zorgeenheid (fase 3). De drie deelprojecten van Project Deel 1 moeten uitmonden in een gezamenlijke GoLive-fase, waarbij is afgesproken dat de Software in het gehele ziekenhuis in één keer live zal gaan (het ‘big bang-scenario’). Omtrent de omvang van het project is in het Implementatieplan het volgende bepaald:

(pag. 3)

“3. Projectscope

(…)

3.1

Functionaliteit

Om tot een eenduidige specificatie van de functionaliteit te komen, heeft een uitgebreide analyse plaatsgevonden. De functionaliteit van de huidige ziekenhuissystemen is in kaart gebracht en aangevuld met de TSz wensen voortgekomen uit eerdere fasen van het EPD-project.

Door ALERT is vervolgens aangegeven of de betreffende functionaliteit opgenomen is in ALERT:

-
In de huidige versie

-
In een toekomstige versie (roadmap)

-
Dat het ontwikkeld moet worden (needs & wishes)

-
Dat de functionaliteit niet door ALERT® wordt ondersteund.

Uit deze analyse is duidelijk geworden in welke mate ALERT® de huidige ziekenhuisfunctionaliteit afdekt. In bijlage 1 is de betreffende analyse opgenomen.

3.1.1.

Functionaliteit die wordt ondersteund door ALERT®

In onderstaande tabel is in hoofdlijnen aangegeven welke functionaliteit door Alert wordt afgedekt.

(tabel)

Bovenstaande functionaliteit wordt in een aantal gevallen gedeeltelijk afgedekt door ALERT® . Deze ontbrekende functionaliteit is door het TSz vertaald naar needs & wishes (opgenomen in bijlage 2). Met ALERT is de afspraak gemaakt dat de aangegeven needs en de roadmap items voor GoLive gerealiseerd zijn in ALERT®.

(…)

3.1.2

iSOFT functionaliteit die niet wordt afgedekt door ALERT®

Uit de analyse is duidelijk geworden dat de volgende iSOFT functionaliteit niet door ALERT® wordt afgedekt:

-
Facturatie en omzetbepaling (iSOFT module Toren)

-
Keuken.

-
Radiologie informatie Systeem (iSOFT moduele RADI).

(…)

(pag. 4)

3.1.3

Medicatie

Uit de analyse is duidelijk geworden dat ALERT® op dit moment niet de door het TSz gewenste medicatie functionaliteit kan bieden. Ten behoeve daarvan zijn een 3-tal scenario’s ontwikkeld:

1.
Medicatievoorschrijven, - toediening en -bewaking in Theriak, logistiek in Zamicom.

2.
Medicatievoorschrijven, - toediening en -bewaking in ALERT®, medicatielogistiek in Zamicom.

3.
Medicatievoorschrijven, - toediening en -bewaking en logistiek in ALERT®.

(…)

In verband met het op dit moment nog ontbreken van een logistieke module in ALERT®, is scenario 3 op middellange termijn (binnen 3 jaar) vooralsnog niet haalbaar.

Met name vanuit het oogpunt van medicatieveiligheid en de beperkte aanwezigheid van medicatiefunctionaliteit in de huidige versie van ALERT® is het raadzaam om in te steken op scenario 1 en 2. Allereerst zorgen voor de juiste koppelingen tussen ALERT® en Theriak en parallel daaraan direct starten met het zorgdragen dat ALERT® op het gebied van medicatie gaat voldoen aan de eisen die het TSz daaraan stelt. Dit advies wordt voorgelegd aan de stuurgroep.

3.2

Koppelingen

Het huidige ZIS heeft allerlei koppelingen met andere informatiesystemen, zoals Theriak en PACS. Deze koppelingen zorgen voor een automatische gegevensuitwisseling tussen de verschillende systemen. Implementatie van ALERT® betekent dat deze koppelingen overgenomen of uitgefaseerd dienen te worden. In bijlage 3 is een specificatie opgenomen van de noodzakelijke koppelingen.

(…)”

2.12.

Omtrent het tijdpad van het project is in het Implementatieplan het volgende afgesproken:

(pg. 10)

“(…)

Uitgangspunten bij de planning zijn de volgende:

-
De noodzakelijke functionaliteit voor het TSz is in de huidige versie van Alert® nog niet beschikbaar. Hiervoor zijn afspraken met ALERT gemaakt in de vorm van Roadmap, Needs & Wishes, inclusief opleverdata:

o
De opleverdatum van versie 2.6.0.4 is 15 november 2010

o
De opleverdatum van versie 2.6.1 is 31 maart 2011

o
De opleverdatum van versie 2.6.2 is 30 september 2011

-
De betreffende versies worden uiterlijk 2 weken na de opleverdatum beschikbaar gesteld aan het TSz.

-
In versie 2.6.2 van ALERT® zijn alle needs deel 1 van het TSz opgenomen.

-
De GoLive datum, ziekenhuisbreed, is vastgesteld op 31 maart 2012.

-
(…)

-
De planning betreft op dit moment de activiteiten uit Deel 1 (vervanging ZIS). Voor Deel 2 (de vernieuwing) wordt een zelfde planning op een nader te bepalen tijdstip opgesteld.”

2.13.

Eind augustus 2010 onderhandelen partijen over een nadere overeenkomst tussen Alert Portugal en TsZ over door TsZ te leveren ontwikkelinspanningen voor met name de (verdere) ontwikkeling van de module ALERT®PHARMACY, en de financiële compensatie die daar voor TsZ tegenover zou moeten staan (‘Development Agreement v2 29082010.doc’). Tot ondertekening van een ontwikkelovereenkomst komt het echter niet.

2.14.

Op 6 september 2010 gaat de implementatie van de Software binnen de organisatie van TsZ officieel van start. Tijdens de zogenaamde ‘kick-off bijeenkomst’ geeft de heer [medewerker 1 van Alert c.s.] van Alert c.s. in een presentatie aan welke versies van de Software op welk moment zullen worden opgeleverd en welke functionaliteiten die verschillende versies zullen hebben
(‘2010/11 MARKET ENABLER ROADMAP’):

Versie

Datum release

v2.6.0.1

(…)

20-apr-2010

v2.6.0.3

* Insurance verification and authorisation – Interfaces with COV (NL)

* DBC’s Integration (NL)

16-jul-2010

v2.6.0.4

(…)

* GP Portal (NL)

* PDMS (NL)

* Patient Portal (1st Stage) (NL)

15-nov-2010

v2.6.1

(…)

* ADT (NL)

* DSM IV (ALL)

* Patient Portal (NL)

* DBC Grouper (NL) (To Be Confirmed)

31-mrt-2011

> v2.6.2

(…)

* AORTA (NL)

(…)

30-sep-2011

2.15.

In de (Engelstalige) besluitenlijst van de Stuurgroepvergadering van 18 december 2010 wordt onder meer vastgelegd dat het project Primair Proces zal worden uitgebreid met drie extra werkgroepen (RIS, Keuken en Facturatie), dat de functionele analyse in de Engelse taal beschikbaar zal zijn (de
‘As-Is and To-Be documentation’) en dat Alert c.s. een tijdelijke (test)configuratie zal realiseren. Daarnaast wordt afgesproken dat de uren die TsZ investeert om het personeel van Alert c.s. meer vertrouwd te laten raken met de zorgmarkt, zullen worden uitgeruild tegen het extra werk dat Alert c.s. moet verrichten in verband met de (in het Implementatieplan niet voorziene) tijdelijke configuratie. Alert c.s. zegt toe dat zij TsZ vóór 24 december 2010 zal laten weten of fase 2 van het deelproject Primair Proces van start kan gaan.

2.16.

In een email van 5 januari 2011 schrijft TsZ aan Alert c.s.:

“(…)

I discussed your proposal.

At first I have a question:

The last meeting Planning was at 15-11-2010. The last meeting Ordering was at 21-11-2010 and the last meeting EHR was at 18-11-2010. All the input to make the As-is documents were finished by my people at that date. And now it is 5-1-2011 and nothing is finished. I can’t understand that.

Now we have to solve this delay, because we wrote in the implementation plan that fase 2 has to be finished 15-1-2011!

(…)

So the following time schedule must be achieved:


Week 1 and 2, (…) used to complete AS-IS. (…)


Week 3 the working groups describe the improvement. This will be written in the conclusion of the AS-IS document.


Week 4 the AS-IS document will be discussed by the working group and will be finished.


Week 5 we are going to start writing the TO-BE situation (…).


Completion of TO-BE situation in late February


Then restart the other working groups and start fase 2 (in-patient, out-patient, surgery and ER).

This is the only way to make up for lost time. (…)”

2.17.

In een email van 7 februari 2011 stuurt de projectleider van Alert c.s. de actiepuntenlijst rond van de vergadering van het Projectmanagement van diezelfde dag (in [plaats] ). De actiepunten zijn onder meer de volgende:

-
“ALERT Project Management at TweeSteden location;

-
Deliver until 12:00 on 09-Feb-2011 the action plan for the assessment for the Functional Work Group Phase I and Radiology;

-
Friday, 11-Feb-2011 deliver date for the plan Phase II and III (functional Work Group);

-
ALERT will start an assessment of actual DIP – Detailed Implementation Plan (functionality, deadline, milestones, methodology, plan, resources, etc.) – 25-Feb-2011;

-
Consequences on contract (new DIP);

-
Needs clarification.”

2.18.

Tijdens de vergadering van de Stuurgroep op 15 februari 2011 is één van de agendapunten het bespreken van de planning en de gevolgen daarvan voor de overeenkomst. In de (Engelstalige) notulen is hierover het volgende vastgelegd:

-
“Monday 14 february product managers of Alert [plaats] will come to get understanding about current status (As-Is and To-Be).

-
The assessment is performed by Alert [plaats] : this creates more direct involvement of [plaats] .

-
Based on this assessment a new planning and capacity will be discussed, especially for Phase II of the Primary Process. One method should be used, agreed by all. (…)”

2.19.

Op 9 februari 2011 ontvangt TsZ, zoals afgesproken, van Alert c.s. een nieuwe planning voor (de afronding van) fase 1.

2.20.

Op 22 februari 2011 stuurt Alert c.s. TsZ een nieuwe planning met bijbehorend tijdpad voor fase 2 van het project Primair Proces. Alert c.s. garandeert in de begeleidende email dat de analyse van de ‘Needs Deel 1’ eind maart 2011 zal zijn afgerond.

2.21.

Op 16 maart 2011 vindt een vergadering plaats over de tijdelijke configuratie. Bij email van 24 maart 2011 verstuurt Alert c.s. de door haar opgestelde besluiten- en actiepuntenlijst van deze vergadering naar TsZ. Alert c.s. geeft hierin aan dat de tijdelijke configuratie zal gaan draaien op Alert® versie v2.6.0.5. en dat zij zal laten weten wanneer wordt geüpgraded naar versie v2.6.1.

2.22.

Bij email van 31 maart 2011 bevestigt TsZ aan Alert c.s. dat partijen die ochtend gezamenlijk tot het inzicht zijn gekomen dat het project niet kan worden afgerond volgens het in het Implementatieplan afgesproken tijdpad. TsZ spreekt twijfels uit over de haalbaarheid van de door Alert c.s. voorgestelde nieuwe planning – die (nog altijd) uitgaat van een GoLive in maart 2012 – en doet haar een alternatief voorstel:

“(…)

The originally mutually agreed implementation plan was based upon the following assumptions:

-
the system would be developed for the Dutch market by the JBZ

-
The TsZ Alert configuration will be deployed per functionality. (…)

-
Content configuration during Phase 1, Phase 2 and Phase 3 with the emphasis on Phase 3.

This morning we confirmed that these assumptions are not realistic anymore. Based on that, you proposed a new planning with the same GoLive date of March 2012. At this moment we already have a delay of 5 months and think the proposed new planning is not feasible, also because:

- (…)

- during the implementation we shifted from a regular implementation site to your pilot site in the Netherlands. This requires more capacity and more time from both sites. This is not agreed in the contract between Alert and the TweeSteden ziekenhuis.

- (…)

Considering the above we propose the following milestones:

-
31 December 2011: Ending Phase 2 including the TOT’s and content collected during Phase 1 and 2.

-
1 January 2012 - 1 April 2012: Alert makes the system (version 2.6.2) ready for deployment based upon everything that is collected during Phase 1 and 2.

-
1 April 2012 – 1 December 2012: Phase 3

-
1 December 2012 – 1 January 2013: Acceptation Testing

-
1 January – 15 February 2013: Train end users

-
GoLive: Date planned in the end of February or March 2013.

The suggested planning above can be discussed in the Steering Group session on 18 April 2011 and more in detail in the session with [medewerker 2 van Alert c.s. 1] and [medewerker 3 van Alert c.s. 2] planned on 20 April 2011. To work out these discussions in a concept planning (based on input from both parties) we suggest a meeting on 21 April 2011 (…)”

2.23.

In een email van 15 april 2011 schrijft TsZ aan Alert c.s.:

“(…)

After an internal conversation with [medeweker 1 van TsZ] we decided that the next steering committee (18 April 2011) will be just for the Tweesteden hospital members.

This because we have to inform the internal members of the steering committee about:

1.
the issues with the planning. We asked Alert representatives to react on our proposal for a new planning and new proposed date for GoLive before 6 April 2011. Till now we received several times apologize but till now no formal reaction.

2.
the problems in the other Alert hospitals in the Netherlands.

We will inform you about the results on the steering committee on our monthly meeting on 20 April 2011. Besides that I want your confirmation that [medewerker 4 van Alert c.s.] and [medewerker 5 van Alert c.s.] will take place in the session planned on 21 April 2011 (…) to discuss the planning in more detail.

(…)”

2.24.

Op 29 april 2011 komt de Werkgroep Medicatie bijeen voor een demonstratie door Alert c.s. van de mogelijkheden van de medicatiemodule. Ter voorbereiding hiervan heeft TsZ een (Engelstalige) casus en een lijst met functionaliteiten aan Alert c.s. beschikbaar gesteld. Tijdens de bijeenkomst blijkt versie 2.6.1 van de Software onvoldoende stabiel om de mogelijkheden van de medicatiemodule te kunnen demonstreren.

2.25.

Op 13 mei 2011 komen partijen (weer) bijeen voor overleg over de nieuwe planning. TsZ zet de uitkomsten van dit overleg als volgt op een rijtje:

“(…)

1. Within 4 weeks we will make the new planning as mentioned above. This new planning is based on the current functionality as described in detail in the implementation plan, extended with the new functionality as defined during phase 1 and phase 2.

2. Instead of a standard implementation site the TweeSteden hospital is, gradually, growing into a position of the Alert software development site in the Netherlands. This is mainly due to delays in implementation process in other Dutch hospitals. As a consequence, there is need for substantially more capacity for the implementation in our organisation, compared to the contracted ‘standard’ implementation. This new situation has to be incorporated in an addendum of the contract.

(…).”

2.26.

Bij email van 19 mei 2011 reageert Alert c.s. op de email van TsZ van 13 mei 2011. Zij geeft aan bereid te zijn om – zoals TsZ voorstelt – binnen vier weken gezamenlijk een nieuwe planning te maken, mits partijen het (ook) eens worden over de volgende twee punten:

“a procedure and financial impact for all the new functionalities that could result from Functional Analysis phase 1 and 2 that the Hospital might want to include in the Product.”en

“a new(financial, toevoeging Rb.)
balance in the project”.

In haar toelichting bij deze laatste voorwaarde geeft Alert c.s. aan dat de ureninschatting die zij voorafgaand aan het ondertekenen van de Framework Agreement heeft gemaakt – en op basis waarvan zij haar prijs heeft berekend – volstrekt in onbalans is met het aantal uren dat zij tot nu toe daadwerkelijk in het project bij TsZ heeft geïnvesteerd. Alert c.s. geeft in haar email van 19 mei 2011 verder nog aan TsZ (nog altijd) niet te beschouwen als ‘
the ALERT software development site in the Netherlands’.

2.27.

In een email van 27 mei 2011 schrijft TsZ onder meer:

“I am afraid that your e-mail doesn’t bring us any further with our discussions about a new planning (…). It seems that Alert is only willing to agree with a new planning in case TweeSteden agrees with extra payment first.

(…)

Furthermore your e-mail gives us the feeling that (please correct us if we are wrong about this) that Alert is of the opinion that:

1. Some of the functionalities that TweeSteden expects to be delivered must be considered as new functionalities and require efforts from Alert that are not within the scope of the Agreement; 2. TweeSteden will not be considered as the Alert development site in the Netherlands; 3. Alert has spent considerably more time at the implementation of the software at TweeSteden than was foreseen at the signing of the Agreement, creating an imbalance between the payments made and these efforts, so that it is reasonable to ask for extra payments.

We strongly disagree with these opinions.

(…)

Furthermore we want to remark that we have made a fixed price deal with Alert regarding the costs of the implementation. This means that the fact that Alert needs more time that it has estimated is not relevant and is not a ground for extra payments. It is also important that you realize that it is not the wish of TweeSteden to get a new planning.

The new planning is simply necessary because the original planning has not been realized due to problems on the side of Alert.

(…)

The following steps are necessary:

First of all we demand that Alert meets the requests that have been drafted by mutual consent between the four Dutch Alert hospitals, as laid down in an attachment to this email. TweeSteden fully agrees with these demands.

In addition to the requests of the four hospitals, TweeSteden requests the following from Alert:

-
That Alert will accept our proposal to come to a new planning without any conditions and will cooperate to the best of it ability to reach a new planning on short notice;

-
That Alert guarantees that it is still fully committed to implement the Alert software at the Dutch market and the TweeSteden in particular and that it is still willing and able to fulfil all its obligations arising out of the Agreement with TweeSteden;

-
That Alert agrees that there is no ground for additional payments;

-
That Alert agrees to supply enough qualified people for the timely product development and timely implementation and will be available on location at the TweeSteden whenever necessary.

Please confirm us not later than June 3, 2011, that Alert agrees with the abovementioned requests. If we do not receive this confirmation in time the project will come into serious danger and we will have to consider legal and other measures to secure our position, including postponement of all payments. (…)”

2.28.

In een email van 4 juni 2011 schrijft Alert c.s. onder meer:

“Your email of May 27 is very demanding, come to us as a surprise, especially following the positive meeting we had in your hospital on May 13, and requires more time for a proper response.

We have, however, continued with all our project activities.

We have noticed that you did not send the payment for services relative to May. If this is your position, and you do not send us that payment by June 7 we may have to suspend all activities in the project until we agree on the impact caused by your request to delay the project for one year.”

2.29.

In een email van 7 juni 2011 schrijft TsZ onder meer:

“(…)

We understand that you need some more time for an adequate reaction to our e-mail of May 27, 2011. We are therefore willing to extend the deadline for a reaction to June 14, 2011. Please note that a further delay is not acceptable for us, because of the urgency of the topics that are addressed by us in our e-mail.

With respect to the suspension of payments, we will postpone our decision until we have received your reaction to our email. We take it as a positive sign however that Alert – after a period of very limited activity – has sent three employees to our hospital to work on phase 2. We have therefore decided to pay 50% of the services invoice for May 2011, showing our good intentions. This amount will be transferred today (June 7, 2011). The other 50% of the payment of May will be made in case we receive your satisfying reaction to our email not later than June 14, 2011. (…)”

2.30.

Op 7 juni 2011 komt de Stuurgroep van het project bijeen. In de notulen van deze vergadering, gedateerd 8 juni 2011, staat onder meer het volgende:

(…)

2. Meeting minutes steering committee 3 March 2011

[medewerker 4 van Alert c.s.] has the opinion that what is set out in the third sentence of the meeting minutes(in the steering committee is agreed that Alert will come with a proposal for a new planning and a new date for GoLive)
, especially the last part of that sentence about the new date for GoLive is not said during the steering committee session of 3 March. The TSz representatives and [medewerker van SQWin] (SQWin) disagree with this.

The meeting minutes of March 3, 2011 are approved with no changes but with the abovementioned remark of Alert, with which the TSz representatives disagree.

(…)

4. Status new planning and approach

[medewerker 2 van Alert c.s. 1] mentions that he is exchanging emails with [medeweker 1 van TsZ] and that he can’t give any answers until June 14th about a new planning and approach.

(…)

6. Questions

- (…)

- [medewerker 2 van Tsz] asks when version 2.6.1 will come to our hospital (in the contract is stated as March 2011). Till now we did not receive this version but also no formal letter about the delay. [medewerker 2 van Alert c.s. 1] mentions that the mail to [medeweker 1 van TsZ] (June 14th) also will answer this question.

- (…)

(…)”

2.31.

In een email van 14 juni 2011 schrijft Alert c.s. onder meer:

“(…)

i. [medeweker 1 van TsZ] , your payment suspension is unacceptable;

ii. When you said that ”ALERT is not fully aware of the seriousness of the situation and that ALERT does not acknowledge its own responsibility for the problems”, we will not comment what we think about the seriousness that you bring to our project after your unjustifiable, disrespectful and surprising decision to: 1) Suspend the payment of the invoice of March 31, 2011 (invoice number [invoice number] ); 2) The payment of 50% of such invoice (until this moment we have not received in our account this money) on June 7, 2011 and conditioning the payment of the remaining amount to a positive answer to your email dated May 27, 2011 with a deadline imposed by you to receive an answer from ALERT until June 14;

iii. I want to let you know that, ALERT does not understand from your email that you tried to pressure a positive answer from us in order to get the green light to receive the other 50% of such invoice. ALERT considers that this invoice is overdue to the services already provided to your Hospital.

(…)

(…) I ask you to please authorize until tomorrow (June 15, 2011) the total payment of the invoice number [invoice number] , and I hope to receive from you in the same day the confirmation of your payment that the Hospital will authorize this payment.

Please, I ask you to not give me more arguments to change the commitment that ALERT has to your project. (…)”

2.32.

In een email van 16 juni 2011 (verzonden om 1:01 uur) geeft Alert c.s. te kennen dat zij de Project Meeting diezelfde ochtend niet zal bijwonen indien TsZ niet vóór 9.00 uur heeft bevestigd dat zij factuur [invoice number] volledig zal voldoen.

2.33.

In een email van 23 juni 2011 laat TsZ Alert c.s. weten dat zij meer tijd nodig heeft om de email van Alert c.s. te beantwoorden, maar dat zij zo snel als mogelijk iets zal laten weten.

2.34.

In een email van 8 juli 2011 geeft Alert c.s. TsZ te kennen dat Alert c.s. met ingang van maandag 11 juli 2011 al haar werkzaamheden voor het project zal opschorten en dat de werkzaamheden pas zullen worden hervat nadat (het openstaande gedeelte van) de facturen van mei en juni 2011 zijn voldaan.

2.35.

Op 13 juli 2011 schrijven de vier Nederlandse klanten van Alert – drie ziekenhuizen, waaronder het Jeroen Bosch Ziekenhuis (hierna: JBZ) en TsZ, en een ziekenhuisapotheek – een gezamenlijke brief aan Alert c.s., waarin zij erop aandringen om op korte termijn een bespreking te plannen over de te volgen strategie voor de verdere implementatie van Alert® in Nederland, de kwaliteit van het product Alert®, de financiële situatie van Alert c.s. en aanpassing (qua planning en voorwaarden) van de bestaande overeenkomsten tussen Alert c.s. en haar Nederlandse klanten.

2.36.

Naar aanleiding van de onder 2.35. genoemde brief van 13 juli 2011 vinden op 19 en 27 juli 2011, de eerste in [plaats] en de tweede op Schiphol, besprekingen plaats tussen Alert c.s. en de vier Nederlandse klanten. Afgesproken wordt dat laatstgenoemden de tijdens die besprekingen gemaakte afspraken nader zullen uitwerken in een “Letter of Intent” (LOI), welke op korte termijn door alle partijen zal worden ondertekend.

2.37.

Bij brief van 15 augustus 2011 leggen de Nederlandse klanten de LOI in concept voor aan Alert c.s.

2.38.

Op 20 september 2011 geeft Alert c.s. uitvoerig schriftelijk commentaar op de concepttekst van de LOI.

2.39.

Op 30 september 2011 verstrijkt de in het Implementatieplan opgenomen deadline voor oplevering van versie 2.6.2 van de Software. In deze versie moeten alle ‘Needs Deel 1’ (vervanging ZIS) zijn verwerkt.

2.40.

Op 3 oktober 2011 beëindigt het JBZ per direct haar samenwerking met Alert c.s.

2.41.

Bij brief van 10 oktober 2011 schrijft TsZ onder meer aan Alert c.s.:

“(…)

Reaction Alert to LOI

We have to conclude that Alert demands a large amount of changes in the LOI, including several very substantial changes. (…)

Clearly, Alert has deviated substantially from the arrangements made at the Schiphol meeting of July 27, 2011.

(…)

Current status of the project: Alert has breached its obligations

Due to Alert’s inadequate reaction to the LOI and the termination by JBZ we are now forced to pick up our own project where we left it on July 11, 2011 when Alert withdrew all its resources from our project. Doing so, we have to conclude that Alert has failed to fulfil its obligations under our agreement of December 31, 2009 (“Agreement”) on several major accounts. Without being exhaustive, we point out the following:

1.
The software is inadequate and does not contain functionality agreed upon in the scoping analysis which is part of the implementation plan of July 22, 2010 (“the Implementation Plan”). We strongly doubt that the software can be made fit for normal use in a large Dutch hospital and in line with relevant statutory rules and regulations;

2.
Alert has not followed the Implementation Plan, including the 3 phases and the big bang approach for go-live that was agreed upon;

3.
Alert’s project organization and management is inadequate. Alert did not allocate adequate and qualified personnel and the number of personnel was insufficient to book results within the time frame agreed upon before go live date (March 31, 2012).

4.
As a result of shortcomings 1-3, the project has been delayed substantially.

Ad 1: The software is inadequate and does not contain functionality agreed upon

(…)

The last release of the software that is available to TSz is a demo version of v2.6.0.5, which in any case should include all the functionalities Alert indicated as “yes” in the scope analysis of the earlier release v2.6.0.2. This, however, is not the case. (…)

(…)

Another very serious issue is that the scope analysis has shown a severe design error in Alert’s software. Alert has a completely different understanding of “episodes”, which means that TSz cannot be compliant to Dutch statutory rules and regulations by using Alert’s software. In the Netherlands “episodes” refer to a series of activities regarding the entire treatment of a patient with a specific diagnosis. (…) Contrary to this, in Alert’s software “episodes” refer to individual steps (activities) in the healthcare process connected to a patient staying in the hospital during one specific period of time. The scoping analysis has shown that the different series of episodes (in Alert’s understanding) cannot be connected to each other. Consequently, an “episode”(in Dutch understanding) cannot be made with the software. (…)

(…)

We also have acquired medication functionality from Alert for prescribing, monitoring and administering medication. Because at the time of conclusion of the Agreement Alert did not yet have a medication software module, we have reviewed Alert’s solution on paper and investigated whether solution is in line with the relevant requirements agreed upon in the scoping analysis. This has shown that Alert’s medication solution does not comply to essential functionalities agreed upon, including requirements based on statutory rules and regulations such as those of Nictiz. (…)

(…)

Ad 2: Alert does not follow the approach agreed upon in the Implementation Plan

(…)

-
(…) Alert failed to translate the Implementation Plan into Portugese or English. (…)

-
Alert does not follow the three phases (…) agreed upon in the Implementation Plan.

-
Alert has agreed upon the approach towards go-live and the big bang go-live scenario, but later has indicated that it does not really support a big bang-go live. (…)

-
When it became clear that the initial planning possibly would not be feasible any more due to the delays in the project, Alert has not cooperated to conclude a realistic new planning, but frustrated the discussions by stating that either the original go-live date should be maintained (which is absolutely not realistic) or substantial extra payments should be made in case of a postponement of the go-live date.

(…)

Ad 4: the project is substantially delayed

As a result of the shortcomings of Alert, the implementation has been substantially delayed. We estimate that the total delay already amounts up to one year. The position of Alert regarding the new planning (see ad 2 here above) frustrates a restart of the project, meaning that the delay will grow even bigger.

With respect to software development, it seems that Alert is far behind the roadmap agreed upon. According to the Implementation Plan (par. 7.1) release v2.6.1 of the software had to be delivered on March 31, 2011. Release v2.6.2 had to be delivered on September 30, 2011. Alert has not delivered these releases to us yet. (…)

(…)

Furthermore, Alert is obligated to provide and/or develop interfaces(koppelingen)
with other systems. The interfaces are identified in Annex 3 to the Agreement. According to the planning agreed upon in the Implementation Plan all interfaces had to be delivered and implemented on different dates, the last interfaces had to be delivered on June 16, 2011. We now have to conclude that none of the interfaces have been delivered at all. (…)

(…)

Consequences of termination by JBZ and Atrium to TSz project

(…) We have already pointed out several times that during the implementation TSz was turning more and more into a development site, which was not agreed upon and which is not acceptable to us without adequate compensation. So far, Alert had always refused to provide such compensations. (…)

Conclusion

(…) TSz has addressed the aforementioned issues already on several occasions as from February 2011 and has given Alert several chances to rectify and respond, all without having any positive effect. However, we are still willing to give Alert a very last chance to get our project back on track again and to regain our confidence in its organization and products. This is only possible when the demands hereunder are fully met in time by Alert.

Demands

Taking all the above into consideration we hereby demand that Alert confirms to us – unconditionally – the following in writing ultimately onOctober 24, 2011:

1.
that Alert is willing to fully cooperate to the financial audit and the PQT in accordance with the requirements laid down in the draft LOI of August 15, 2011 (…);

2.
that Alert is willing to compensate for the unforeseeable circumstance that TSz now has turned into a development site (…);

3.
that Alert is willing to accept a new planning on the basis of the proposal that TSz had provided in march 2011 (but taking into account the extra delay as from March 2011), without claiming extra payments and strengthened with additional penalty clauses and other legal measures (…);

4.
that Alert fully accepts and will closely follow the implementation approach of TSz, including the 3 phases and the big bang scenario for the go-live, as laid down in the Implementation Plan;

5.
that for the duration of the Agreement Alert Nederland will be staffed with sufficient employees and a general manager speaking Dutch and with a good knowledge of the Dutch healthcare system and the Dutch culture;

6.
that Alert shall reinstall and present the new project organization, as described under 5 here above, no later thanDecember 9, 2011;

7.
that Alert delivers software to TSz no later thanDecember 9, 2011that:

a.
contains all the functionalities agreed upon in the scoping analysis, including “yes”, “roadmap” functionalities regarding: Patiëntregistratie, Spreekuurplanning, Opnameplanning en -registratie, Ordermanagement, OK-planning, SEH, Verrichtingen en DBC registratie, Management informatie, Dossier, Brieven, Medicatie voorschrijven en toedienen, Technische eisen;

b.
contains the “Need part I” functionalities;

c.
contains a working solution for the “episode” issue as explained above;

d.
contains all the functionalities agreed upon for medication, and;

e.
includes interfaces as listed in annex 3 to the Implementation Plan.

8.
that the software will be compliant to Dutch statutory rules and regulations in time (within the new planning that is to be confirmed by us) and that Alert will meet all other obligations under the Agreement with TSz.

If we do not receive your written and unconditional confirmation of all of the aforementioned issues on October 24, 2011, or if the activities mentioned have not been executed fully by December 9, 2011, or if the results of the financial audit and/or the PQT are not satisfactory to us, Alert will be in default and TSz will terminate the agreement and claim back the payments made and additional damages.

For the sake of clarity this letter is to be considered as a formal notice of default. (…)”

2.42.

Bij brief van 24 oktober 2011 reageert Alert c.s. op de brief van TsZ van 10 oktober 2011. Alert c.s. stelt daarin dat TsZ geen
‘pilot customer’of
‘development site’is geworden, zodat er geen aanleiding is voor een financiële compensatie van TsZ op dit punt: volgens Alert c.s. zijn de
‘Design and Development’activiteiten en de Functionele Analyse afgerond in het kader van het JBZ project. Ook uit de rest van haar reactie op de brief van TsZ blijkt dat Alert c.s. zich niet herkent in de door TsZ geformuleerde punten van kritiek en dat – wat Alert c.s. betreft – TsZ ook zelf verantwoordelijk is voor de vertraging die het project heeft opgelopen. In reactie op het zevende en achtste verzoek (
‘demand’) van TsZ schrijft Alert c.s.:

“ALERT’s Response:As explained in our proposal for the Letter of Intent, dated of September 20, 2011, ALERT was forced to decrease the number of developments performed for the Dutch market, due to suspended payments from Dutch customers and due to a joint initiative / joint roadmap that was being established. However, full activities are underway, for example, for Bernhoven’s upcoming Go Live.

It is not reasonable, and TSz knows it, to develop the functionalities that were to be worked jointly by ALERT and TSz until upcoming December 9, 2011. However, ALERT is willing to resume specific product developments for the Dutch Market. For that purpose, ALERT would like to suggest a meeting with TSz in order to agree on a plan for product delivery.”

Alert c.s. besluit haar brief van 24 oktober 2011 als volgt:

II ALERT’s conclusion:

(…) ALERT would like to invite TweeSteden ziekenhuis to participate in a meeting with the objective of finding a balanced solution for both parties that really allows for the implementation of ALERT® at your Hospital with the quality necessary to satisfy all the stakeholders.

We are confident that ALERT® is the product that best allows for TSz to face the challenges of modern healthcare and that we can jointly achieve success.

ALERT is continuously committed to its operation and would love to continue to work with TSz. (…)”

2.43.

Bij brief van 2 november 2011 schrijft TsZ aan Alert c.s.:

“(…)

Taking all things into consideration, we hereby terminate the framework agreement of December 31, 2009 with Alert, including all related agreements thereto. The termination is principally based on article 13.1a. Alternatively, in the unlikely event that this ground could not be legally invoked by TSz, the termination is based on article 13.1.d, article 6:258 of the Dutch Civil Code(“Burgerlijk Wetboek”)
and article 7:408 Dutch Civil Code and article 3.3 of the Agreement.

(…)”

3.2.

De rechtsstrijd

3.2.1.

TsZ heeft in eerste aanleg gevorderd, zoveel mogelijk uitvoerbaar bij voorraad, dat:

primair:

- voor recht wordt verklaard dat de Framework Agreement door TsZ op rechtsgeldige wijze is ontbonden bij brief van 2 november 2011, dan wel,

subsidiair:

- de Framework Agreement per datum vonnis wordt ontbonden,

zowel primair als subsidiair:

- Alert c.s. hoofdelijk worden veroordeeld tot nakoming van de uit de ontbinding voortvloeiende ongedaanmakingsverbintenissen, bestaande uit terugbetaling aan TsZ van een bedrag van € 4.620.253,97 inclusief btw, te vermeerderen met wettelijke (handels)rente vanaf 16 november 2011 tot aan de dag van algehele voldoening,

meer subsidiair:

- voor recht wordt verklaard dat TsZ de Framework Agreement bij brief van 2 november 2011 rechtsgeldig heeft opgezegd tegen 2 november 2012,

nog meer subsidiair:

- voor recht wordt verklaard dat TsZ de Framework Agreement bij brief van 2 november 2011 rechtsgeldig heeft opgezegd tegen 31 december 2014,

primair, subsidiair en (nog) meer subsidiair:

- Alert c.s. hoofdelijk worden veroordeeld tot betaling aan TsZ van een schadevergoeding ter grootte van € 4.620.253,97, te vermeerderen met wettelijke (handels)rente vanaf 16 november 2011 tot aan de dag van algehele voldoening,

- Alert c.s. hoofdelijk worden veroordeeld in de kosten van deze procedure.

3.2.2.

Na door Alert c.s. gevoerd verweer heeft de rechtbank in het vonnis waarvan beroep, onder afwijzing van het meer of anders gevorderde, voor recht verklaard dat TsZ de Framework Agreement bij brief van 2 november 2011 rechtsgeldig heeft opgezegd tegen 26 januari 2015, met veroordeling van TsZ in de proceskosten.

3.2.3.

In de rechtsoverwegingen 4.1 en 4.2 van het bestreden vonnis heeft de rechtbank de Nederlandse rechter internationaal bevoegd geoordeeld om van het geschil kennis te nemen en zij heeft voorts geoordeeld dat op de rechtsverhouding tussen partijen Nederlands recht van toepassing is. Tegen deze oordelen zijn – terecht, want zij zijn juist - geen grieven gericht.

3.2.4.

In hoger beroep vordert TsZ, onder aanvoering van 23 grieven, de vernietiging van het vonnis waarvan beroep, toewijzing van de vorderingen en veroordeling van Alert c.s. in de kosten.

3.2.5.

In hoger beroep hebben Alert c.s. gevorderd om in het principaal appel de grieven van TsZ te verwerpen en het bestreden vonnis – onder aanpassing van het oordeel van de rechtbank ten aanzien van de incidentele grief – te bekrachtigen met veroordeling van TsZ in de kosten.

3.3.

In deze zaak gaat het, kort gezegd, om een mislukt project inzake de levering en implementatie door Alert c.s. van een ziekenhuisinformatiesysteem en elektronisch patiëntendossier (EPD).

Het hof acht het gewenst vooraf op te merken dat het uit de stukken, maar ook ambtshalve, ermee bekend is dat verwante geschillen, betreffende drie andere ziekenhuizen en een ziekenhuisapotheek, aanhangig zijn gemaakt. In de zaak van de Stichting Jeroen Bosch Ziekenhuis tegen Alert c.s. heeft dit hof (in een andere samenstelling) op 17 februari 2015 een tussenarrest gewezen (ECLI:NL:GHSHE:2015:480). Het gaat hier niet om één opdracht van meerdere ziekenhuizen, noch om overeenkomsten met Alert c.s. die in samenhang met elkaar zijn aangegaan. Dit brengt mee dat de onderhavige zaak op haar eigen merites beoordeeld dient te worden.

3.4.

In
grief 1 in het principaal appelwordt door TsZ gesteld dat de rechtbank ten onrechte geen partijdebat over de tekortkomingen en de daarbij behorende relevante feiten en omstandigheden heeft toegelaten. Het vonnis zou reeds uit dien hoofde vernietigd moeten worden en het geschil zou alsnog volledig door het hof behandeld dienen te worden.

Naar het oordeel van het hof heeft TsZ geen belang bij deze grief, en faalt zij deswege, nu de grieven het materiële geschil in volle omvang aan het hof voorleggen en TsZ al haar stellingen en verweren dienaangaande heeft kunnen aanvoeren en tijdens het pleidooi heeft kunnen toelichten.

3.5.

In de
grieven 2 en 3 in het principaal appelwordt opgekomen tegen de waardering door de rechtbank van het karakter van het project en de gemaakte afspraken en over het karakter en de status van het implementatieplan en de scoping analyse.

Gesteld wordt dat geen sprake is van een overeenkomst voor de ontwikkeling van een nieuw IT-systeem (met alle risico’s van dien), maar een overeenkomst voor de levering en implementatie van een (grotendeels al) bestaand IT-systeem.

3.5.1.

Alert c.s. hebben (punt 8.3 mva/mvg) gesteld dat bij de selectie van de software van Alert als ook het sluiten van de raamovereenkomst beide partijen er nog van uitgingen dat het project een gewone levering en implementatie van (standaard)software was. Dit uitgangspunt zou ná de contractsluiting door TsZ zijn verlaten. TsZ drong aan op doorontwikkeling van 47 Needs & Wishes waardoor er sprake zou zijn geworden van een ontwikkelingscomponent.

3.5.2.

Het hof stelt voorop dat de aard en inhoud van een overeenkomst moet worden vastgesteld aan de hand van hetgeen partijen over en weer hebben verklaard en uit elkaars verklaringen en gedragingen overeenkomstig de zin die zij daaraan in de gegeven omstandigheden redelijkerwijs mochten toekennen, hebben afgeleid en van hetgeen zij te dien aanzien redelijkerwijs van elkaar mochten verwachten (Haviltex).

3.5.3.

In dit verband acht het hof van groot belang tot uitgangspunt te nemen dat Alert c.s. degene zijn die zich hebben verbonden tot levering, ontwikkeling en implementatie van door hen vervaardigde complexe software

. Zij beschikken over de benodigde kennis en ervaring om het project tot een goed einde te brengen. De verantwoordelijkheid voor het leveren van deugdelijke software ligt geheel bij Alert c.s. TsZ is een medisch ziekenhuis en beschikt niet over de benodigde kennis en ervaring, reden ook om Alert c.s. de opdracht te gunnen. Van een samenwerking ten aanzien van deze (ICT-)kerntaak van Alert c.s. kan dan ook geen sprake zijn (geweest). De ‘samenwerking’ die van TsZ kon worden verlangd spitst zich derhalve niet toe op het materiële ontwikkelingsproces, maar op de overdracht van de software en op het bruikbaar maken daarvan in het ziekenhuis. De van TsZ te verlangen ‘samenwerking’ heeft veeleer het karakter van medewerking, namelijk om Alert c.s. in staat te stellen aan haar contractuele verplichtingen te voldoen.

3.5.4.

Dat TsZ tijdens de looptijd van het proces aandringt op het uitvoeren van een Scoping Analyse, en doorontwikkeling en aanvullende software verlangt, specifiek voor TsZ, doet de kerntaak van Alert c.s. niet veranderen, noch de aard van de oorspronkelijke overeenkomst. Ook de ontwikkeling van de aanvullende software valt onder de verplichtingen van Alert c.s. De verplichting tot ontwikkeling van deugdelijke software en de toereikende implementatie daarvan rusten in eerste instantie op Alert c.s.

Het hof voegt daaraan toe dat Alert c.s. hadden moeten verwachten dat TsZ met aanvullende verzoeken tot software-aanpassingen zou komen. TsZ wilde immers een systeem dat voldeed aan de eisen van deze tijd en niet een systeem dat reeds bij invoering als verouderd had te gelden. Alert c.s. kunnen TsZ dan ook geen verwijten maken ten aanzien van de Needs & Wishes.

3.5.5.

Naar het oordeel van het hof geldt hetzelfde voor het Implementatieplan. Ook het opstellen en accorderen van dat plan neemt niet weg dat het project naar de kern genomen inhield een gewone levering en implementatie van (standaard)software onder directe verantwoordelijkheid en leiding van Alert c.s.

3.5.6.

Wel oordeelt het hof als juist, dat mede (ten dele) sprake is geweest van een ontwikkelproject. Het was TsZ immers bekend dat ten tijde van het aangaan van de Framework Agreement de software nog niet voor implementatie en gebruik gereed lag. In zoverre heeft de contractuele relatie tussen partijen mede het karakter van opdracht. Deze constatering brengt evenwel geen verandering in de kernverplichtingen van Alert c.s. Ook ten aanzien van deze opdracht berust bij hen de primaire verantwoordelijkheid en zorgplicht om een deugdelijk resultaat tot stand te brengen. Daarbij zij wel opgemerkt dat ook ten aanzien van deze opdracht door Alert c.s. samenwerking/ medewerking van TsZ verlangd kon worden, in die zin dat TsZ Alert c.s. in staat moest stellen de software te kunnen ontwikkelen (door onder meer het geven van ‘input’ aan Alert c.s.) en aan te passen voor het gebruik dat TsZ daarvan wilde maken.

3.5.7.

In aanvulling hierop wordt nog overwogen dat onder de medewerking die van TsZ verlangd kan worden mede valt, wat in de aanhef van de Raamovereenkomst wordt genoemd ‘commitment van haar organisatie’.

3.5.8.

Met een en ander is tevens gegeven dat de stelplicht en bewijslast, dat zij toereikend aan haar verplichtingen heeft voldaan, althans dat zij daaraan niet heeft voldaan vanwege omstandigheden die aan TsZ zijn toe te rekenen, in beginsel bij Alert c.s. ligt.

3.5.9.

Het hof merkt ten slotte nog op dat de kwalificatie van de rechtsverhouding tussen partijen slechts een van de omstandigheden is die bij de beoordeling van de geschillen in aanmerking wordt genomen. Bij die beoordeling dienen alle aspecten in hun onderlinge samenhang te worden betrokken. Uitgangspunt kan dan niet zijn een ‘eenvoudige’ koop- of opdrachtovereenkomst. Zo zullen bij de beoordeling van de hardheid van de gemaakte afspraken alle nadere (uitvoerings)afspraken in ogenschouw moeten worden genomen, terwijl bij de beoordeling van de uitvoering dient te worden betrokken dat partijen hebben rekening te houden met elkaars gerechtvaardigde belangen en de praktische uitvoerbaarheid.

3.6.1.

In
grief 19 in principaal appelklaagt TsZ erover dat de rechtbank alleen heeft getoetst de vraag of Alert c.s. ‘is in breach or default of any of its material obligations under this Agreement and such breach or default continues un-rectified for sixty (60) days following the Dispute Resolution Process non Defaulting Party shall terminate this Agreement’ en niet aan de andere gronden voor ontbinding. Zij wijst op de beginwoorden van artikel 13 lid 1 van de Framework Agereement: ‘Without limiting any other rights or remedies available to the Parties’.

Naar het oordeel van het hof is deze verwijzing juist en kan niet worden volstaan met een beperkte toets (of er sprake is van schending van de ‘material obligations’).

3.6.2.

Ten aanzien van de ontbindingsgrond wijst het hof op artikel 6:265 BW dat bepaalt dat iedere tekortkoming van een partij in de nakoming van haar verbintenissen aan de wederpartij de bevoegdheid geeft de overeenkomst te ontbinden, tenzij de tekortkoming, gezien haar bijzondere aard of geringe betekenis, deze ontbinding met haar gevolgen niet rechtvaardigt. Verder speelt hier een rol het beroep van TsZ op de anticipatory breach van artikel 6:80 BW, bepalende dat de gevolgen van het niet nakomen reeds intreden voordat de vordering opeisbaar is indien TsZ uit mededelingen van Alert c.s. mocht afleiden dat deze in de nakoming zal tekortschieten of indien TsZ goede gronden heeft te vrezen dat Alert c.s. in de nakoming zullen tekortschieten en deze niet voldoet aan een schriftelijke aanmaning met opgave van die gronden om zich binnen een bij de aanmaning gestelde redelijke termijn bereid te verklaren hun verplichtingen na te komen.

3.6.3.

Met inachtneming van hetgeen hiervoor (ook in rov. 3.5) werd overwogen zal het hof de vorderingen gaan beoordelen.

3.7.

De grieven 4 en 5 in principaal appelhebben betrekking op de waardering van de opgetreden vertragingen in de uitvoering van het project. Grief 4 betoogt kort gezegd dat de termijnen uit het implementatieplan wel degelijk fataal zijn en grief 5 dat het niet halen van de deadlines door Alert c.s. wel degelijk zijn aan te merken als tekortkomingen.

3.7.1.

Hiervoor is al aangegeven dat de onderhavige rechtsverhouding niet kan worden aangemerkt als een ‘eenvoudige’ koop- of opdrachtovereenkomst. In dat geval kunnen harde, fatale termijnen worden gesteld. In het onderhavige geval kan er niet aan worden voorbij gegaan dat de verlangde software ontwikkeld moet worden en dat voor die ontwikkeling de medewerking van TsZ nodig is. Inherent daaraan (en in licht van het Haviltex-criterium) is dat vertragingen kunnen ontstaan. TsZ kon en behoorde daar rekening mee te houden. Dit brengt mee dat geen sprake kan zijn van harde fatale termijnen.

Aan de tekst van de door TsZ (in 5.3.2 mvg) aangehaalde bepalingen uit de overeenkomst kan dit fatale karakter niet ontleend worden.

3.7.2.

Anderzijds geldt evenmin dat uit (alleen) de teksten van de Framework Agreement en het Implementatieplan (genoemd in rov. 4.16 van het vonnis waarvan beroep) reeds kan worden afgeleid dat het niet halen van tussentijdse opleverdata onvoldoende grond zou kunnen zijn voor de ontbinding van de overeenkomsten. Dat zou alleen het geval kunnen zijn als zou zijn overeengekomen dat de daarin voorkomende opleverdagen geheel vrijblijvend waren. Daarvan is geen sprake. De termijnen zijn opgenomen met het oog op de enige wel fatale termijn, namelijk de Go-Live op 31 maart 2012 (punt 9.5 onder a mva/mvg).

3.7.3.

Gelet op deze laatste, wel fatale termijn en op het feit dat TsZ onder omstandigheden mag vrezen dat deze termijn niet wordt gehaald als de tussentijdse termijnen niet worden gehaald, althans langdurig worden overschreden, kan het zo zijn dat het niet-halen van die termijnen, althans de duur van de overschrijding, de ontbinding van de overeenkomst wel degelijk rechtvaardigen. TsZ heeft daar dan ook een uitdrukkelijk beroep op gedaan. De gestelde termijnen zijn dan ook niet geheel vrijblijvend.

3.7.4.

TsZ mag Alert c.s. in beginsel aan de termijnen (de gefaseerde voorbereiding op de Go-Live met de nieuwe software) houden. Het is aan Alert c.s. als eerstverantwoordelijke en uitvoerder om de termijnen te bewaken en (substantiële) overschrijding te voorkomen. De stelplicht en bewijslast ten aanzien van haar stelling dat, bijvoorbeeld, de overschrijdingen hetzij gerechtvaardigd werden door de omstandigheden van het geval of dat de overschrijding van dien duur en aard was dat de Go-Live-datum niet in gevaar zou komen, berust bij Alert c.s.

3.7.5.

Het hof zal, met inachtneming van hetgeen hier werd overwogen, dat wil zeggen deze bijzondere aard van de overeengekomen termijnen, beoordelen of de ontbinding gerechtvaardigd is.

3.8.

De
grieven 6 en 7 in principaal appelhebben betrekking op het projectmanagement en bestrijden in het bijzonder rov. 4.21 van het bestreden vonnis. TsZ stelt zich op het standpunt dat Alert c.s. een slecht projectmanagement hebben gevoerd en dat het niet volgen van het implementatieplan wel degelijk een tekortkoming oplevert.

3.8.1.

Uit de toelichting op deze grieven komt naar voren dat TsZ Alert c.s. verwijt te weinig mensen te hebben ingezet en dat degenen die waren ingezet onvoldoende deskundig en ervaren waren. Ook wordt gewezen op het vertrek van de Nederlandse projectleider van Alert Nederland, de wisselingen in het management van Alert Nederland, de slechte communicatie tussen Alert Nederland en Alert Portugal en het voortdurend niet-nakomen van afspraken. Deze omstandigheden zouden hebben geleid tot forse vertragingen en het niet voldoen van de ontwikkelde software.

3.8.2.

Het hof kan zich voorstellen dat deze omstandigheden door TsZ als ergerlijk zijn ervaren en hebben bijgedragen tot de vrees voor het niet-halen van Go-Live-datum.

Daarmee is nog niet gegeven dat die omstandigheden – zoal vast te stellen – reeds op zich voldoende zijn om de ontbinding van de overeenkomsten te rechtvaardigen.

3.8.3.

Anderzijds kan het hof niet meegaan in het oordeel van de rechtbank dat TsZ niet met concrete feiten en omstandigheden heeft onderbouwd aan welke specifieke verplichtingen Alert c.s. in dit verband zouden hebben moeten voldoen. TsZ heeft uitvoerig uiteen gezet dat het in haar ogen falend projectmanagement ertoe heeft bijgedragen en de oorzaak ervan is dat partijen in een conflictsituatie terecht zijn gekomen en dat de Go-Live-datum niet meer gehaald kon worden, althans dat daarvoor ernstig gevreesd moest worden.

3.8.4.

Het hof is bovendien van oordeel dat op Alert c.s., als eerstverantwoordelijken voor het welslagen van het project en uit dien hoofde de leiding van het project had (anders dan Alert c.s. zelf meent, punt 9.34 mvg/mva), de plicht rust om alles in het werk te stellen dat nodig was om het project tot een goed einde te brengen. In het kader van deze plicht kan van Alert c.s. verlangd worden dat zij vakbekwaam personeel gebruikt en dat zij, zonodig extra personeel inzet. Of Alert c.s. aan hun verplichtingen hebben voldaan kan niet alleen worden afgemeten aan de hand van de aflevering van het project op de Go-Livedatum. Die aflevering vereist immers een ontwikkeling van software in overleg met de toekomstig gebruiker en begeleiding bij de toepassing, dat wil zeggen dat bij de gebruiker ook vertrouwen in het nieuw te ontwikkelen systeem moet worden opgebouwd.

Slecht projectmanagement kan in dit licht onder omstandigheden wel degelijk als een ontbindingsgrond dienen.

Gelet op de (leidinggevende) rol van Alert c.s. bij de ontwikkeling en implementatie van de software was het niet aan TsZ om specifieke verplichtingen met betrekking tot het projectmanagement aan te wijzen, maar kon zij volstaan met het noemen van de feiten.

3.8.5.

Het hof meent voorts dat slecht projectmanagement – van substantiële aard - er weldegelijk toe kan bijdragen dat bij TsZ de gerechtvaardigde vrees is ontstaan dat het project niet, althans ontoereikend zou aflopen.

3.8.6.

Het zal dus, bij de beoordeling van de vraag of er voor TsZ sprake is van een toereikende grond voor de ontbinding van de overeenkomst, mede dienen te letten op de wijze (aard en omvang) waarop Alert c.s. het project hebben begeleid en tenuitvoergelegd.

3.9.

De
grieven 8, 9 en 10 in principaal appelbetreffen de kwaliteit van de software, in het bijzonder het ontbreken van ‘yes’-‘, ‘DBC- ’ en medicatiefunctionaliteiten.

TsZ stelt daartoe dat de afwezigheid van de functionaliteiten in de geleverde software wel degelijk relevant is voor het verloop van het project en het vertrouwen van TsZ in de goede afloop van het project. De rechtbank heeft geoordeeld dat niet-beschikbaar zijn van de yes- en de DBC-functionaliteiten niet eerder beschikbaar hoefde te zijn dan op de Go-Livedatum.

3.9.1.

Naar het oordeel van het hof wordt met de oordelen van de rechtbank onvoldoende rekening ermee gehouden dat TsZ de overeenkomst(en) heeft opgezegd vóór de Go-livedatum, omdat zij van oordeel was, mede omdat aan de functionaliteiten niet was voldaan, dat die datum niet haalbaar was. Dit standpunt is niet reeds op de door de rechtbank genoemde grond te passeren, temeer daar Alert c.s. zelf een fasegewijze oplevering hebben geoffreerd (rov. 2.5 van de feitenvaststelling).

Voorts wordt geen rekening gehouden met de omstandigheid dat de Go-livedatum niet de opleverdatum van de software is, maar de datum waarop het systeem operationeel moest worden (de papierloze werkwijze). Op die datum moesten de gebruikers dus bekend zijn met de nieuwe software, opgeleid zijn voor gebruik en deze software kunnen toepassen. Dit vergt niet alleen een aflevering van een groot deel van de software voor de Go-live-datum in verband met de noodzakelijke gedegen voorbereiding bij de medewerkers van TsZ, die een aflevering op het laatste moment in de weg staat.

3.9.2.

Daarmee is anderzijds nog niet gezegd dat de door TsZ geconstateerde gebreken op het moment van de opzegging zodanig van aard en omvang waren, dat die gebreken, in samenhang met de andere kwesties en de tijd die nog resteerde, reeds de ontbinding zouden kunnen rechtvaardigen. Dat hangt mede af van de aard en ernst van het gebrek, dus met de mogelijkheid om tijdig toereikende software te kunnen afleveren.

3.9.3.

In grief 10 in principaal appel beklaagt TsZ zich erover dat de rechtbank het ontbreken van de medicatiefunctionaliteit niet heeft meegewogen. Alert c.s. stellen daar tegenover dat op haar niet de plicht rustte om een vernieuwde medicatiefunctionaliteit op te leveren, omdat TsZ nog geen keuze had gemaakt tussen de drie – reeds bij de projectstart gedefinieerde – scenario’s.

3.9.4.

Naar het oordeel van het hof miskennen Alert c.s. hiermee hun leidinggevende rol bij het project. Na de demonstratie van 29 april 2011 aan de medici had het op de weg van Alert c.s. gelegen om ter zake doende voorstellen te doen voor de ontwikkeling en implementatie van de benodigde software, dan wel duidelijk aan te geven dat zij ten aanzien van die functionaliteit (vooralsnog) zouden blijven bij de bestaande. Dit geldt temeer daar het Alert c.s. bekend was dat de medicatiefunctionaliteit voor TsZ cruciaal was.

3.9.5.

Het hof zal derhalve in zijn beoordeling de stand van zaken van het project op de datum van de ontbinding van de overeenkomst moeten betrekken.

3.10.

De
grieven 11, 12 en 13 in principaal appelhebben betrekking op de schending van de garanties en keren zich tegen hetgeen werd overwogen in de rov. 4.24-4.26 van het bestreden vonnis.

3.10.1.

In grief 11 wordt opgekomen tegen hetgeen de rechtbank in rov. 4.25 heeft overwogen. In die overweging slaat de rechtbank acht op de betekenis van de term ‘representations and warranties’ in het Angelsaksische recht.

3.10.2.

Naar het oordeel van het hof faalt de grief. Bij de uitleg van een in de Engelse taal gesteld beding mag acht worden geslagen op de betekenis die die term in het Angelsaksische recht heeft, temeer in het onderhavige geval waar die term in het contract of in de onderhandelingen tussen partijen geen specifieke betekenis is gegeven.

3.10.3.

Het hof voegt hieraan toe dat dit niet wegneemt dat het beding uitgelegd moet worden aan de hand van het Haviltex-criterium en dat daarbinnen het door de rechtbank genoemde aspect één van de aspecten is waarop dient te worden gelet.

3.10.4.

Ten slotte merkt het hof op dat TsZ niet stelt dat de door de rechtbank gegeven uitleg anders is dan haar eigen standpunt. De rechtbank concludeert dat schending recht geeft de overeenkomst te beëindigen hetgeen ook TsZ voorstaat.

3.10.5.

In de
grieven 12 en 13 in principaal appelstelt TsZ dat Alert c.s. bij het aangaan van de Framework Agreement een valse voorstelling van zaken hebben gegeven door te suggereren dat de software reeds grotendeels af en dat de DBC-functionaliteit al in ontwikkeling was.

Naar het oordeel van het hof is de staat van de ontwikkeling ten tijde van het aangaan van de overeenkomst niet relevant. Waar het op aankomt is te beoordelen of op het moment van het inroepen van de buitengerechtelijke ontbinding die staat ontoereikend was voor de Go-Live.

3.10.6.

Dit neemt evenwel niet weg dat de staat waarin de software bestond ten tijde van het aangaan van de overeenkomst en de wijze waarop de software verder is ontwikkeld ten tijde van de looptijd van het project kunnen bijdragen aan het oordeel dat sprake is van wanprestatie.

3.11.

Deskundigenonderzoek

3.11.1.

Uit het vorenstaande volgt dat de beoordeling van de vorderingen van TsZ een weging vergt van alle omstandigheden van het geval. Daarbij kan niet worden volstaan met een beoordeling van alleen juridische argumenten. De beoordeling vergt mede een beoordeling vanuit medisch perspectief en vanuit projectmanagement bezien. Dit geldt temeer waar partijen elkaar verwijten maken over de escalatie van het project.

Zonder deskundigenvoorlichting kan het hof de geconstateerde feiten niet goed op hun waarde wegen.

3.11.2.

Het hof is voornemens deskundigen te benoemen teneinde het hof (vanuit een onafhankelijk gezichtspunt) voor te lichten over de achtergronden van de uitvoering van het project en de waardering (weging) van de aspecten van deze zaak.

Het meent dat drie deskundigen hun oordeel moeten geven, iemand uit de medische hoek (bijvoorbeeld een directeur van een ziekenhuis die belast is geweest met de invoering van complexe computersystemen), iemand uit de softwarebranche die zijn visie kan geven over de wijze waarop het onderhavige project had behoren te worden uitgevoerd en waar het mis ging, en een projectmanager. De drie deskundigen hoeven niet noodzakelijkwijs tot een eensluidend oordeel te komen. Van hen wordt verwacht dat zij vanuit hun eigen deskundigheid rapporteren. Zij dienen wel de juridische kaders die hiervoor zijn geschetst tot uitgangspunt te nemen.

3.11.3.

De deskundigen zal worden gevraagd om, in acht nemende hetgeen hiervoor als beoordelingsmomenten werd aangestipt in ieder geval de volgende vragen te beantwoorden, althans gezichtspunten te geven omtrent deze kwesties:

- hoe beoordeelt u, vanuit uw eigen deskundigheid, het verloop van het project?

- wilt u aangeven wat voor u de cruciale momenten zijn geweest van het project en op welke van die momenten niet adequaat (genoeg) is gehandeld;

- is naar uw oordeel, met name door Alert c.s., voldoende voortvarend aan het project gewerkt en zo dit niet het geval was, op welke momenten had correctie dienen plaats te vinden?

- wat had moeten gebeuren om het project op het overeengekomen tijdstip Go-life te laten gaan en hoe beoordeelt u de kans dat die datum gehaald had kunnen worden?

- welke partij heeft op welke momenten ‘steken laten vallen’ en hoe cruciaal is dat geweest voor de voortgang van het project?

- in hoeverre schort het aan de benodigde samenwerking tussen partijen? Is de mogelijke vertraging in de uitvoering mede te wijten aan onvoldoende input aan de zijde van TsZ?

- de discussie tussen partijen lijkt te zijn geëscaleerd onder invloed van onenigheid over de financiering van het project (zie de feitenvaststelling onder 2.26 e.v.). Wat zijn volgens de deskundigen de gevolgen voor de voortgang van het project geweest?

- is een aangepaste medicatiemodule een vereiste voor een behoorlijk functioneren of kon worden volstaan met de bestaande functionaliteit?

- welke ter zake dienende opmerkingen kunt u nog maken?

3.11.4.

Partijen worden overeenkomstig het bepaalde in artikel 194 lid 2 Rv in de gelegenheid gesteld, hun visie te geven. Zij kunnen namen van te benoemen deskundigen geven (maar alleen gezamenlijk), en eventueel namen van deskundigen die niet benoemd kunnen worden. Voorts kunnen zij hun visie geven over de kosten (het voorschot).

Het hof is voornemens beide partijen, elk voor de helft met het voorschot te belasten, TsZ omdat zij eiseres is en Alert c.s. omdat zij de leiding van het project hadden en vast staat dat zij de software niet hebben opgeleverd en geïmplementeerd.

4. De uitspraak

Het hof:

op het principaal en incidenteel hoger beroep

verwijst de zaak naar de rol van 1 december 2015 voor het nemen van een akte aan de zijde van TsZ; Alert c.s. kunnen een antwoordakte nemen;

houdt iedere verdere beslissing aan.

Dit arrest is gewezen door mrs. W.H.B. den Hartog Jager, J.P. de Haan en J.H.M. van Erp en is in het openbaar uitgesproken door de rolraadsheer op 3 november 2015.

griffier rolraadsheer

Mislukte implementatie van ziekenhuisinformatiesysteem en elektronisch patiëntendossier door Alert c.s. voor Stichting Tweesteden Ziekenhuis

Uitspraak

3.Terms and subject of the Agreement

5.Performance of the Implementation Services

6.Preparatory, Implementation and On-site Services and Schedules

11.Software Acceptance

13.Termination

19.Warranties and Undertakings

30.General