ECLI:NL:RBOBR:2013:6627

Uitspraak

vonnis

RECHTBANK OOST-BRABANT

Handelsrecht

Zittingsplaats 's-Hertogenbosch

zaaknummer / rolnummer: C/01/244606 / HA ZA 12-256

Vonnis van 27 november 2013

in de zaak van

de stichting

STICHTING TWEESTEDEN ZIEKENHUIS,

gevestigd te Tilburg,

eiseres,

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

tegen

1. de besloten vennootschap met beperkte aansprakelijkheid

ALERT LIFE SCIENCES COMPUTING B.V.,

gevestigd te Utrecht,

2. de rechtspersoon naar Portugees recht

ALERT LIFE SCIENCES COMPUTING S.A.,

gevestigd te Vila Nova de Gaia (Portugal),

gedaagden,

advocaat mr. F. van der Woude te Amsterdam.

Eiseres zal hierna TsZ worden genoemd. Gedaagden zullen hierna afzonderlijk worden aangeduid als Alert Nederland (gedaagde sub 1.) en Alert Portugal (gedaagde sub 2.) en gezamenlijk als Alert c.s.

1. De procedure

1.1. Het verloop van de procedure blijkt uit:

het tussenvonnis van 6 februari 2013
het proces-verbaal van comparitie van 25 april 2013.

1.2. Ten slotte is vonnis bepaald.

2. De feiten

2.1. TsZ is een algemeen, regionaal opleidingsziekenhuis met vestigingen in Tilburg en Waalwijk. 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:

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. (…)

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:

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

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

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[A] 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 Porto). 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 Porto will come to get understanding about current status (As-Is and To-Be).
The assessment is performed by Alert Porto: this creates more direct involvement of Porto.
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 [B] and [C] 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 [D] 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:

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.

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 [E] and[F] 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

[E] 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 [G] van Gunst (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

[B] mentions that he is exchanging emails with [D] and that he can’t give any answers until June 14th about a new planning and approach.

(…)

6. Questions

(…)

[H] 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. [B] mentions that the mail to [D] (June 14th) also will answer this question.

(…)

(…)”

2.31.

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

“(…)

i. [D], 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 20111006); 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 20111006, 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 20111006 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 Porto 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:

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;

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

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).

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:

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 (…);

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

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 (…);

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;

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;

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

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. Het geschil

3.1.

TsZ vordert (samengevat) dat de rechtbank bij vonnis, zoveel mogelijk uitvoerbaar bij voorraad:

primair:

 voor recht verklaart 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 ontbindt,

zowel primair als subsidiair:

 Alert c.s. hoofdelijk veroordeelt 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 verklaart dat TsZ de Framework Agreement bij brief van 2 november 2011 rechtsgeldig heeft opgezegd tegen 2 november 2012,

nog meer subsidiair:

 voor recht verklaart 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 veroordeelt 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 veroordeelt in de kosten van deze procedure.

3.2.

TsZ heeft aan haar vorderingen ten grondslag gelegd, samengevat, dat Alert c.s. ernstig tekort is geschoten in de nakoming van haar contractuele verplichtingen en verzuimd heeft deze tekortkomingen tijdig te herstellen, zodat TsZ ingevolge (1) artikel 13.1 onder a, dan wel (2) artikel 13.1 onder d van de Framework Agreement gerechtigd was (is) de overeenkomst te (doen) ontbinden. TsZ heeft de door haar gestelde bevoegdheid tot ontbinding verder gegrond op (3) artikel 6:258 BW. Door de ontbinding zijn, aldus TsZ, ongedaanmakingsverbintenissen ontstaan in de zin van artikel 6:271 BW. TsZ stelt zich in dat verband op het standpunt dat de waarde van de prestaties van Alert c.s. voor TsZ moet worden gesteld op nihil, zodat Alert c.s. (per saldo) is gehouden tot volledige terugbetaling van hetgeen TsZ gedurende het project aan haar heeft voldaan. Daarnaast stelt TsZ dat Alert c.s. is gehouden tot vergoeding van de schade die TsZ heeft geleden als gevolg van de tekortkomingen van Alert c.s. TsZ maakt in dat verband aanspraak op vergoeding van (onder meer) onnodig aangeschafte hard- en software, onnodig gemaakte kosten voor interfaces, migratie-activiteiten, projectmanagement en consultancy, personeelskosten, kosten van het voortgezet gebruik en noodzakelijke upgrades van diverse bestaande softwaresystemen en de kosten van juridische bijstand. De meer (en nog meer) subsidiair aangevoerde opzegging heeft TsZ gegrond op artikel 7:408 BW en artikel 3.3 van de Framework Agreement.

3.3.

Alert c.s. voert verweer.

3.4.

Op de stellingen van partijen wordt hierna, voor zover van belang, nader ingegaan.

4. De beoordeling

I. Bevoegdheid en toepasselijk recht

4.1.

Nu Alert Portugal in het buitenland is gevestigd, heeft deze zaak een internationaal karakter. Dat maakt dat allereerst ambtshalve moet worden beoordeeld of de Nederlandse rechter bevoegd is van de vordering kennis te nemen. Deze vraag dient te worden beantwoord aan de hand van de Verordening (EG) nr. 44/2001 betreffende de rechterlijke bevoegdheid, erkenning en de tenuitvoerlegging van beslissingen in burgerlijke en handelszaken (hierna: EEX-Vo), omdat zowel Nederland als Portugal hierbij verdragsluitende partij zijn. Partijen hebben in artikel 29.4. van de Framework Agreement de (Nederlandse) rechtbank te ’s-Hertogenbosch bevoegd verklaard in de zin van artikel 23, eerste lid, EEX-Vo. Gelet hierop acht de rechtbank Oost-Brabant – onder welke naam de rechtbank ‘s-Hertogenbosch per 1 januari 2013 is verder gegaan – zich bevoegd om van het geschil kennis te nemen.

4.2.

De vraag naar het toepasselijk recht dient te worden beantwoord aan de hand van het EEG-Overeenkomstenverdrag (EVO). Partijen hebben in artikel 30.10. (pagina 34) van de Framework Agreement uitdrukkelijk bepaald dat op hun rechtsverhouding Nederlands recht van toepassing is en daarmee een rechtskeuze gemaakt als bedoeld in artikel 3 van het EVO. De rechtbank zal de vordering van TsZ daarom beoordelen naar Nederlands recht.

II. Inhoudelijke beoordeling

4.3.

Bij de verdere beoordeling van het geschil stelt de rechtbank het volgende voorop.

Na een uitgebreid selectie- en voorbereidingstraject heeft TsZ Alert c.s. op 31 december 2009 opdracht gegeven tot het leveren en binnen haar ziekenhuisorganisatie implementeren van een ‘3e generatie’ EPD. De Software van Alert c.s. – van Portugese origine – was ten tijde van het sluiten van de Framework Agreement nog niet gereed voor implementatie in een Nederlands ziekenhuis, omdat de Nederlandse zorgmarkt anders is georganiseerd en anders wordt gefinancierd dan de Portugese zorgmarkt. TsZ heeft hierin geen belemmering gezien, omdat de aanpassingen/uitbreidingen die nodig waren voor gebruik van de Software op de Nederlandse markt (zoals de DBC-functionaliteit) op dat moment al in kaart waren gebracht in het kader van de samenwerking tussen Alert c.s. en haar
‘launching customer’en ontwikkelpartner JBZ. Het tijdpad voor de te ontwikkelen ‘Nederlandse’ functionaliteiten – inclusief tussentijdse oplevermomenten – was door Alert c.s. vastgelegd in de ‘Roadmap’, die zij in de aanloop naar de Framework Agreement en bij aanvang van het project aan TsZ heeft gepresenteerd. Naast de uitbreidingen/aanpassingen die zouden worden ontwikkeld op basis van de Roadmap, wilde TsZ ook nog kunnen beschikken over een aantal andere, specifiek voor haar te ontwikkelen, deelfunctionaliteiten. Deze deelfunctionaliteiten – 47 stuks – zijn door partijen vastgelegd in de bij het Implementatieplan behorende lijst ‘Needs deel 1’. Ten slotte moest Alert c.s. een aantal koppelingen tot stand brengen tussen haar Software en (bestaande) software van andere leveranciers van TsZ. Ook deze koppelingen zijn vastgelegd in (de bijlagen bij) het Implementatieplan. Dit alles leidt de rechtbank tot de conclusie dat ten tijde van het vaststellen van het Implementatieplan voor beide partijen duidelijk was aan welke eisen de Software uiteindelijk moest (gaan) voldoen. Tussen partijen is verder niet in geschil dat zij voor de implementatie van de Software een vaste prijs (
‘fixed-price’) zijn overeengekomen en dat deze vaste prijs in maandelijkse termijnen door TsZ moest worden voldaan.

II. Schuldeisersverzuim aan de zijde van TsZ?

4.4.

Het meest vérstrekkende verweer van Alert c.s. tegen de op ontbinding gebaseerde vorderingen van TsZ, is dat TsZ vanaf mei 2011 in schuldeisersverzuim is geraakt door haar betalingsverplichtingen uit de Framework Agreement op te schorten. Door dit schuldeisersverzuim aan de zijde van TsZ, zo stelt Alert c.s., kon vanaf dat moment geen sprake meer zijn van (het intreden van) verzuim aan de zijde van Alert c.s. en was/is TsZ niet bevoegd om de Framework Agreement te (doen) ontbinden.

4.5.

Alert c.s. heeft aangevoerd dat de stopzetting van de betalingen door TsZ er (slechts) op was gericht om haar ertoe te bewegen in te stemmen met aanvullende, nieuwe eisen en dat zij op dat moment niet tekortschoot in haar verplichtingen uit de Framework Agreement en/of (het daarbij behorende) Implementatieplan. Alert c.s. stelt verder dat, zo zij wél tekortgeschoten zou zijn in enige bestaande contractuele verplichting, TsZ haar betalingen toch niet gerechtvaardigd kon opschorten omdat zij de (gestelde) tekortkomingen in haar email van 27 mei 2011 niet heeft gespecificeerd.

4.6.

Anders dan Alert c.s. in het kader van haar beroep op schuldeisersverzuim bepleit, is voor een gegrond beroep op opschorting niet steeds vereist dat sprake is van een (al dan niet toerekenbare) tekortkoming. Artikel 6:263 BW – waarvan partijen bij het sluiten van de Framework Agreement niet zijn afgeweken – geeft de partij die verplicht is om het eerst te presteren reeds de bevoegdheid om de nakoming van haar verbintenis op te schorten, indien zij goede grond heeft te vrezen dat de wederpartij haar daartegenover staande verplichtingen niet zal nakomen. Dit artikel is in de wet opgenomen omdat de partij die als eerste moet presteren, zolang zij haar prestatie nog niet heeft verricht, geen opeisbare vordering op haar wederpartij heeft en dus ook nog geen beroep kan doen op de opschortingsbevoegdheden als bedoeld in de artikelen 6:52 en 6:262 BW. De situatie waarvoor artikel 6:263 BW een oplossing beoogt te bieden, doet zich ook voor indien de partijen gelijktijdig moeten presteren, zodat in die gevallen een analoge toepassing van dit artikel in de rede ligt.

4.7.

Bij de beoordeling van de vraag of TsZ in het onderhavige geval goede grond had te vrezen dat Alert c.s. zou (gaan) tekortschieten in de nakoming van haar contractuele verplichtingen, acht de rechtbank het volgende van belang. De voortgang van het project is sinds het sluiten van de Framework Agreement voortdurend een punt van zorg geweest. Het Implementatieplan – dat volgens het Framework Agreement uiterlijk op 1 april 2010 gereed had moeten zijn – is pas op 22 juli 2010 definitief vastgesteld. Begin 2011 loopt de totstandkoming van de
‘as is’en
‘to be’documenten vertraging op en omstreeks januari/februari 2011 komen partijen gezamenlijk tot het inzicht dat de in het Implementatieplan beschreven planning niet (langer) haalbaar is. In de maanden daarna wordt geprobeerd in overleg tot een aangepaste planning te komen, maar tot overeenstemming daarover komt het niet. Op 27 mei 2011 beschrijft TsZ in een email aan Alert c.s. dat de onderhandelingen tussen partijen over de nieuwe planning in een impasse zijn geraakt, dat inmiddels sprake is van een
‘huge delay’en dat de activiteiten binnen het project grotendeels stilliggen. TsZ geeft in deze email in niet mis te verstane bewoordingen aan dat zij overweegt haar verdere betalingen op te schorten en brengt bij Alert c.s. in herinnering dat partijen een vaste prijs zijn overeengekomen voor de implementatie van de Software. Verder geeft zij aan dat TsZ (dus) niet zal instemmen met de financiële voorwaarde die Alert c.s. blijkens haar email van 19 mei 2011 heeft verbonden aan haar instemming met de door TsZ voorgestelde nieuwe planning.

4.8.

In haar reactie op bovengenoemde email van 4 juni 2011 – TsZ heeft dan nog niet definitief tot opschorting van haar betalingsverplichtingen besloten – neemt Alert c.s. geen afstand van haar standpunt dat TsZ (substantiële) financiële concessies zal moeten doen om tot overeenstemming te kunnen komen over een nieuwe planning, en stelt haar bereidheid om verder te onderhandelen volledig afhankelijk van de bereidheid aan de zijde van TsZ om haar betalingsverplichtingen na te komen. Ook in een volgende email van 14 juni 2011 komt Alert c.s. niet inhoudelijk tegemoet aan de zorgen van TsZ, maar noemt zij de (voorgenomen) opschorting
‘unjustifiable, disrespectful and surprising’. Bezien tegen die achtergrond acht de rechtbank het gerechtvaardigd dat bij TsZ de vrees is ontstaan dat Alert c.s. haar (bestaande) contractuele verplichtingen niet tijdig zou kunnen of willen nakomen en dat TsZ hierin, mede gelet op de strekking van de verwachte tekortkoming, aanleiding heeft gezien om de onzekerheidsexceptie van artikel 6:263 BW te hanteren. Dit leidt tot de conclusie dat TsZ niet in schuldeisersverzuim is geraakt door in de eerste helft van juni 2011 haar betalingen aan Alert c.s. op te schorten. Dat betekent dat de rechtbank toekomt aan een (nadere) beoordeling van de vraag of TsZ bevoegd was de Framework Agreement op 2 november 2011 buitengerechtelijk te ontbinden.

B. Ontbinding

a. Uitleg van de artikelen 11 en 13.1. van de Framework Agreement

4.9.

TsZ heeft de door haar gestelde bevoegdheid tot ontbinding primair gebaseerd op artikel 13.1. van de Framework Agreement (‘
Termination for cause’). Alert c.s. heeft hiertegen allereerst het verweer gevoerd dat TsZ zich niet heeft gehouden aan de in artikel 11 van de Framework Agreement omschreven acceptatieprocedure en dat die omstandigheid in de weg staat aan een beroep van TsZ op de in artikel 13.1. genoemde ontbindingsgronden. TsZ betwist dat de Framework Agreement op de door Alert c.s. voorgestane wijze moet worden uitgelegd en stelt dat artikel 11.7. geen exclusieve, maar slechts een aanvullende grond voor ontbinding is, die in de overeenkomst is opgenomen ter voorkoming van discussies tussen partijen over het aantal kansen dat Alert c.s. dient te krijgen om fouten in eenmaal opgeleverde software op te lossen.

4.10.

De vraag hoe in een schriftelijk contract de verhouding van partijen is geregeld en of dit contract mogelijk een leemte laat die moet worden aangevuld, kan niet worden beantwoord op grond van alleen maar een zuiver taalkundige uitleg van de bepalingen van dat contract. Het komt bij de beantwoording van die vraag aan op de zin die partijen in de gegeven omstandigheden over en weer redelijkerwijs aan de betreffende bepaling mochten toekennen en op hetgeen zij te dien aanzien redelijkerwijs van elkaar mochten verwachten. Daarbij is mede van belang de hoedanigheid van partijen en de rechtskennis die van zodanige partijen kan worden verwacht.

4.11.

Uit hetgeen partijen ter comparitie hebben verklaard over de totstandkoming van de Framework Agreement, leidt de rechtbank af dat de redactie van en de verhouding tussen de daarin opgenomen artikelen 11 en 13.1. gedurende de onderhandelingen tussen partijen geen bijzonder onderwerp van aandacht zijn geweest. De tekst van de Framework Agreement biedt naar het oordeel van de rechtbank geen aanknopingspunten voor de door Alert c.s. bepleite uitleg van de betreffende bepalingen. De aanhef van artikel 13.1. van de Framework Agreement (
‘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’) wijst erop dat partijen de
‘rights or remedies’die hen in het geval van een achterblijvende prestatie ten dienste stonden juist niet hebben willen beperken, maar hebben willen vastleggen welke procedure de daarmee geconfronteerde partij zou moeten volgen, zoals het versturen van een
‘prior written notice’en het in acht nemen van een minimale termijn voor herstel van 60 dagen. De tekst onder (a) en (d) van artikel 13.1. bevat geen beperking in de zin dat in alle gevallen eerst de procedure van artikel 11 zou moeten worden gevolgd. Dat ligt naar het oordeel van de rechtbank ook niet in de rede: ook in de fase die voorafgaat aan de (eerste, tweede of derde) oplevering van software kan zich de situatie voordoen dat de leverancier tekortschiet in een
‘material obligation’. Er zijn bovendien velerlei tekortkomingen denkbaar die niet zien op
‘bugs, defects and/or failures’in de software, maar betrekking hebben op andere contractuele verplichtingen. In al die gevallen brengt het ‘verplicht’ moeten doorlopen van de in artikel 11 beschreven opleverings-/acceptatieprocedure partijen niet verder. Dit alles leidt ertoe dat de rechtbank de artikelen 11 en 13 van de Framework Agreement aldus zal uitleggen dat de genoemde ontbindingsgronden in zoverre naast elkaar bestaan, dat de in artikel 11 beschreven procedure alleen behoeft te worden doorlopen indien en voor zover de ontbinding is gebaseerd op gesteld tekortschieten in de vorm van
‘bugs, defects and/or failures’in
opgeleverdesoftware.

b. Schending ‘material obligation’ (artikel 13.1. aanhef en onder (a) Framework Agreement)

4.12.

TsZ heeft haar bevoegdheid tot ontbinding primair gebaseerd op artikel 13.1. aanhef en onder (a) van de Framework Agreement. Hierin is bepaald dat een partij bevoegd is om de overeenkomst te ontbinden op het moment dat de wederpartij tekortschiet
‘in any of its material obligations’. In andere woorden: zonder contractuele verplichting geen tekortkoming. Dat betekent dat de rechtbank bij de beoordeling van de door TsZ gestelde tekortkomingen van Alert c.s. steeds eerst zal moeten vaststellen waartoe Alert c.s. zich jegens TsZ heeft verplicht en op welk moment de betreffende (deel)prestatie opeisbaar is geworden. De rechtbank zal bij de bespreking van de gestelde tekortkomingen de volgorde aanhouden die TsZ in haar ingebrekestelling van 10 oktober 2011 heeft gekozen en waarop zij in de dagvaarding heeft voortgeborduurd.

(1)
de Software bevat niet de overeengekomen functionaliteiten uit de scoping analyse, kent ernstige ontwerpfouten en is ongeschikt voor de Nederlandse markt

4.13.

Het eerste verwijt dat TsZ Alert c.s. in dit verband maakt is dat veel ‘yes-functionaliteiten’ in (demo)versie 2.6.0.5. van de Software niet beschikbaar waren, terwijl Alert c.s. bij gelegenheid van de scoping analyse – gebaseerd op versie 2.6.0.2. – zelf heeft aangegeven dat deze functionaliteiten al aanwezig waren. TsZ baseert haar stelling dat een groot aantal ‘yes-functionaliteiten’ ontbrak op eigen onderzoek, uitgevoerd in juli 2011. Alert c.s. heeft zich tegen de resultaten van dit onderzoek verweerd met het ‘Software Risk Assessment Report’ van de Software Improvement Group van 3 augustus 2012 (het SIG-rapport), waaruit zou blijken dat ten minste 89% van de ‘yes-functionaliteiten’ in versie 2.6.0.5. van de Software beschikbaar was. Naar het oordeel van de rechtbank kan echter in het midden blijven of in versie 2.6.0.5 al dan niet een groot gedeelte van de ‘yes-functionaliteiten’ ontbrak. Zij overweegt daartoe als volgt.

4.14.

Het standpunt van TsZ dat (in ieder geval) in versie 2.6.0.5. van de Software de ‘yes-functionaliteiten’ aanwezig moesten zijn, is gebaseerd op de vooronderstelling dat Alert c.s., doordat zij in de scoping analyse bepaalde functionaliteiten heeft gerangschikt in de categorie/kolom
‘yes’, aan TsZ de garantie heeft gegeven dat die ‘yes-functionaliteiten’ vanaf versie 2.6.0.2. van de Software beschikbaar zouden zijn. Deze uitleg van de ‘kruisjes’ in de scoping analyse vindt naar het oordeel van de rechtbank echter geen basis in de Framework Agreement, het Implementatieplan of in de andere gedingstukken. De scoping analyse betreft een werkdocument, dat was bedoeld om gezamenlijk in kaart te brengen aan welke technische en functionele eisen de uiteindelijk op te leveren Software zou moeten voldoen en op basis waarvan partijen een inschatting hebben gemaakt van de ontwikkelstappen die nog moesten worden gezet om dat doel te bereiken. Het belangrijkste doel van de scoping analyse was dat het voor Alert c.s. duidelijk werd wat de achtergrond en het belang was van de diverse functionaliteiten die op de GoLive-datum in de Software aanwezig moesten zijn. Naar het oordeel van de rechtbank mocht TsZ aan de ‘kruisjes’ in de scoping analyse, mede gelet op het bepaalde in artikel 19.1 van de Framework Agreement, in redelijkheid niet de betekenis hechten dat de ‘yes-functionaliteiten’ eerder dan op de Go-Livedatum definitief beschikbaar zouden zijn. Dat betekent dat het (gestelde) ontbreken van (een groot deel van de) ‘yes-functionaliteiten’ in versie 2.6.0.5. van de Software niet kwalificeert als een tekortkoming in een ‘material obligation’. De rechtbank wijst er in dat verband verder nog op dat is gesteld noch gebleken dat het (gesteld) niet beschikbaar zijn van bepaalde (concrete) ‘yes-functionaliteiten’ in de tussentijds beschikbaar gestelde versies van de Software merkbaar van invloed is geweest op het verloop van het project en/of het ontstaan van de vertraging. Hierbij past dat TsZ zich ook niet eerder dan in juli 2011 heeft verdiept in de aanwezigheid van de ‘yes-functionaliteiten’ in (de reeds in het eerste kwartaal van 2011 aan haar beschikbaar gestelde) versie 2.6.0.5.

4.15.

Het tweede verwijt dat TsZ aan Alert c.s. maakt, is dat uit de scoping analyse is gebleken dat de Software een ernstige ontwerpfout bevat – erin bestaande dat de Software aan het begrip
‘episodes’een andere betekenis toekent dan op de Nederlandse zorgmarkt met haar DBC-systeem gebruikelijk is, waardoor de serie zorgactiviteiten binnen een DBC (het zorgpad) niet administratief kan worden gekoppeld – en dat Alert c.s. de afgesproken tijdelijke oplossing voor dit probleem, die behoorde tot de Needs deel I, niet op 30 september 2011 (in versie 2.6.2. van de Software) heeft opgeleverd. Hier komt de rechtbank toe aan het bespreken van de vraag of de in het Implementatieplan aangegeven tussentijdse opleverdata hebben te gelden als fatale termijnen, in die zin dat het niet-nakomen daarvan op zichzelf reeds voldoende is om te kunnen spreken van een tekortkoming in een
‘material obligation’in de zin van artikel 13.1 aanhef en onder (a) van de Framework Agreement.

4.16.

Naar het oordeel van de rechtbank is het (gesteld) overschrijden van de tussentijdse opleverdata door Alert c.s. onvoldoende grond voor ontbinding van de Framework Agreement wegens schending van een
‘material obligation’. Zij acht daarbij de volgende omstandigheden van belang:

In artikel 6.2. van de Framework Agreement is bepaald dat het Implementatieplan, eenmaal vastgesteld,
In artikel 19, waarin de door Alert c.s. verstrekte
Op pagina 10 van het Implementatieplan is aangegeven dat (onder meer) de start en eindtijden per te plannen activiteit zijn

4.17.

De door TsZ gestelde ontwerpfouten in de aan haar beschikbaar gestelde (tussentijdse) versies van de Software en/of de gestelde ongeschiktheid van die versies voor de Nederlandse markt, kunnen naar het oordeel van de rechtbank evenmin tot de conclusie leiden dat per 2 november 2011 sprake was van een tekortkoming in een
‘material obligation’in de zin van artikel 13.1. aanhef en onder (a) van de Framework Agreement: de in artikel 19.1 van de Framework Agreement door Alert c.s. geboden garanties aangaande de beschikbare functionaliteiten en de geschiktheid van de Software voor de Nederlandse markt, hebben steeds betrekking op de versie van de Software per de datum van GoLive en (dus) niet op eerdere versies.

(2)
Alert c.s. heeft het Implementatieplan en de daarin opgenomen implementatieaanpak niet gevolgd

4.18.

TsZ heeft verder aangevoerd dat Alert c.s. op grond van artikel 5.1. van de Framework Agreement verplicht is om de Software binnen de organisatie van TsZ te implementeren op basis van het Implementatieplan, maar dat zij zich niet aan die verplichting heeft gehouden. Zij heeft in dat verband gesteld dat de in het Implementatieplan neergelegde 3-fasenaanpak door Alert c.s. niet is gevolgd, dat Alert c.s. telkens bleef terugkomen op het in het Implementatieplan gekozen GoLive-scenario (
‘big bang’) en dat Alert c.s. – anders dan TsZ – de in het Implementatieplan afgesproken planning en aanpak niet volgde. Alert Portugal was, aldus TsZ, niet eens bekend met de in het Implementatieplan gemaakte afspraken, doordat het Implementatieplan niet in het Portugees of Engels was vertaald.

4.19.

Alert c.s. heeft gemotiveerd betwist dat zij het Implementatieplan en de daarin opgenomen projectaanpak niet zou hebben gevolgd. Zij heeft er in dat verband op gewezen dat zij in meerdere door haar verzonden e-mails juist heeft verwezen naar de projectfasen uit het Implementatieplan, dat TsZ niet heeft gesteld dat Alert c.s. het big-bang scenario zou hebben gesaboteerd en dat haar projectmanager op 7 september 2010 een Engelse vertaling van het Implementatieplan heeft toegestuurd aan zijn opvolger, zodat (ook) Alert Portugal van de inhoud daarvan op de hoogte was. Daarnaast heeft Alert c.s. erop gewezen dat het (gesteld) niet volgen van het Implementatieplan geen zelfstandige tekortkoming kan opleveren, omdat de tussentijdse opleverdata in het Implementatieplan niet aan acceptatiemomenten zijn gekoppeld en de Framework Agreement uitdrukkelijk voorziet in de mogelijkheid om de daarin opgenomen planning tijdens het implementatieproces aan te passen (artikel 6.2.).

4.20.

De rechtbank is van oordeel dat TsZ, mede gelet op het uitvoerige verweer dat Alert c.s. op dit punt heeft gevoerd, onvoldoende concrete feiten en omstandigheden heeft aangevoerd waaruit zou kunnen worden afgeleid dat de gestelde afwijkingen van de in het Implementatieplan opgenomen projectplan en –planning, indien deze zouden komen vast te staan, kunnen kwalificeren als een ten achter blijven in een
‘material obligation’in de zin van artikel 13.1 aanhef en onder (a) van de Framework Agreement. De rechtbank neemt daarbij in aanmerking – in aansluiting op hetgeen hiervoor onder 4.16. reeds is overwogen – dat het Implementatieplan geen ‘harde’ verplichtingen bevat en dat zowel de in dit plan opgenomen tussentijdse oplevertermijnen als de afgesproken aanpak van aanvang af vatbaar waren voor aanpassingen en/of nadere onderhandelingen. De enige harde verplichting van Alert c.s. was om (uiterlijk) op 31 maart 2012 Software op te leveren die geschikt was voor normaal gebruik binnen de organisatie van TsZ, alle overeengekomen functionaliteiten bevatte en voldeed aan de afgesproken specificaties (zie ook het bepaalde in artikel 6:39 BW). Tot oplevering van de ‘definitieve’ versie van de Software is het echter niet gekomen.

(3)
Alert c.s.’ projectorganisatie en projectmanagement is inadequaat;

4.21.

De verwijten die TsZ Alert c.s. maakt ten aanzien van (haar rol in) de projectorganisatie en het projectmanagement kunnen naar het oordeel van de rechtbank evenmin tot de conclusie leiden dat sprake is van een tekortkoming in een
‘material obligation’. De rechtbank heeft partijen in haar brief van 18 april 2013 nadrukkelijk uitgenodigd om ter comparitie – voor zover relevant in het licht van de gestelde tekortkomingen – in te gaan op de concrete verplichtingen die partijen jegens elkaar zijn aangegaan en het de raadslieden van beide partijen toegestaan om gebruik te maken van spreekaantekeningen. Dit heeft er echter niet toe geleid dat TsZ concreet heeft aangegeven welke contractuele verplichting(en) Alert c.s. op zich heeft genomen aangaande de projectorganisatie en het projectmanagement. TsZ verwijt Alert c.s. dat zij ‘te weinig’ mensen heeft ingezet, dan wel mensen heeft ingezet die ‘onvoldoende deskundig en ervaren’ waren, maar zij heeft niet met concrete feiten of omstandigheden onderbouwd aan welke specifieke verplichtingen Alert c.s. in dat verband zou hebben moeten voldoen. De omstandigheid dat er ‘talrijke’ wisselingen zouden zijn geweest in het management van Alert Nederland en dat er in de beleving van TsZ grote problemen waren in de communicatie tussen Alert Nederland en Alert Portugal, maakt nog niet dat Alert c.s. is tekortgeschoten in de nakoming van haar contractuele verplichtingen. Het had, mede in aanmerking genomen het uitvoerige verweer van Alert c.s. op dit punt, op de weg gelegen van TsZ om ter comparitie nader aan te geven welke concrete contractuele verplichtingen Alert c.s. ten aanzien van de organisatie en het management van het project op zich zou hebben genomen, hetgeen zij heeft nagelaten.

(4)
Alert c.s. heeft continue deadlines niet gehaald, waardoor het project substantieel is vertraagd

4.22.

Ten aanzien van deze tekortkoming verwijst de rechtbank naar hetgeen hiervoor onder 4.15 en 4.16 reeds is overwogen.

Tussenconclusie

4.23.

Uit hetgeen hiervoor is overwogen volgt dat de rechtbank TsZ niet volgt in haar standpunt dat ten tijde van haar ontbindingsverklaring (2 november 2011) sprake was van een tekortkoming van Alert c.s. ten aanzien van een
‘material obligation’. Dat betekent dat TsZ niet bevoegd was de Framework Agreement te ontbinden op basis van artikel 13.1. aanhef en sub (a) van de Framework Agreement.

b. Representation or warranty (artikel 13.1. aanhef en onder (d) Framework Agreement)

4.24.

TsZ heeft haar bevoegdheid tot ontbinding subsidiair gebaseerd op artikel 13.1. aanhef en onder (d) van de Framework Agreement. Hierin is bepaald dat een partij bevoegd is om de overeenkomst te ontbinden op het moment dat
‘Any representation or warranty contained herein shall be false or misleading in any material respect as of the date made or deemed to have been made’. TsZ heeft aangevoerd dat Alert c.s. een valse, althans misleidende garantie heeft afgegeven door bij het invullen van de scoping analyse aan te geven dat verschillende functionaliteiten al in de Software (versie 2.6.0.2.) aanwezig waren en dat TsZ op grond daarvan terecht de in artikel 13.1. aanhef en onder (d) van de Framework opgenomen ontbindingsgrond heeft inroepen.

4.25.

Bij de beoordeling van bovengenoemde ontbindingsgrond stelt de rechtbank voorop dat het Nederlands recht het concept van de
‘representation or warranty’niet kent, zodat de betekenis van artikel 13.1. aanhef en onder (d) door middel van uitleg moet worden vastgesteld (zie hiervoor onder r.o. 4.10.). Het Angelsaksische rechtssysteem, waarin het concept van
‘representations and warranties’van groot belang is binnen het contractenrecht, biedt de rechtbank daarbij een richtsnoer. De term
‘representation’ziet binnen dat systeem op een verklaring van één van partijen omtrent (op het moment van de
‘representation‘) bestaande feiten, terwijl een
‘warranty’in beginsel betrekking heeft op een (in de toekomst) te leveren contractuele prestatie. Het afgeven van een
‘representation’of een
‘warranty’heeft ingrijpende juridische consequenties – schending ervan geeft de wederpartij het recht de overeenkomst te vernietigen dan wel te beëindigen – zodat dergelijke verklaringen veelal expliciet in de overeenkomst worden opgenomen.

4.26.

De
‘false or misleading representation or warranty’waarop TsZ zich in de onderhavige zaak beroept (TsZ geeft niet aan om welk type verklaring het wat haar betreft zou gaan), bestaat uit het in de scoping analyse verschaffen van gesteld onjuiste informatie omtrent de aanwezigheid van bepaalde functionaliteiten in versie 2.6.0.2. van de Software (de ‘kruisjes’ in de kolom ‘yes’). Tussen partijen is niet in geschil dat de scoping analyse

– en de indeling van de verschillende functionaliteiten in de categorieën
‘yes’,
‘no’en
‘Roadmap’– pas geruime tijd ná de totstandkoming van de Framework Agreement tot stand is gekomen. Dat betekent dat ten tijde van het sluiten van de Framework Agreement geen sprake kan zijn geweest van een onjuiste voorstelling van zaken aan de zijde van TsZ ten aanzien van het al dan niet reeds aanwezig zijn van bepaalde functionaliteiten in de Software, zodat geen sprake kan zijn van een valse of misleidende
‘representation’op dat punt. Verder is gesteld noch gebleken dat Alert c.s. bij het sluiten van de Framework Agreement enige toezegging heeft gedaan aangaande de aanwezigheid van bepaalde functionaliteiten in de bestaande versie of in opvolgende tussentijdse versies van de Software. In artikel 19 van de Framework Agreement, waarin de door Alert c.s. verstrekte
‘Warranties and Undertakings’zijn opgenomen, zijn alleen
‘warranties’gegeven ten aanzien van de functionele mogelijkheden van de uiteindelijk – per datum Go-Live – op te leveren Software. Dit leidt de rechtbank tot de conclusie dat Alert c.s. geen
‘warranty’heeft afgegeven ten aanzien van de functionele mogelijkheden van eerdere versies van de Software. Dat leidt ertoe dat de indeling door Alert c.s. van bepaalde functionaliteiten in de kolom
‘yes’van de scoping analyse niet kan worden gekwalificeerd als een
‘warranty’in de zin van artikel 13.1. aanhef en onder (d) van de Framework Agreement en dat TsZ aan het (gesteld) onjuist zijn van die indeling geen ontbindingsbevoegdheid kan ontlenen.

c. Onvoorziene omstandigheden (artikel 6:258 BW)

4.27.

TsZ heeft de door haar gestelde bevoegdheid tot ontbinding verder gegrond op artikel 6:258 BW, waarin – voor zover hier van belang – is bepaald dat de rechter op verzoek van één van partijen een overeenkomst kan ontbinden op grond van onvoorziene omstandigheden welke van dien aard zijn dat de wederpartij naar maatstaven van redelijkheid en billijkheid ongewijzigde instandhouding van de overeenkomst niet mag verwachten. TsZ voert in dit verband aan dat zij ten tijde van het sluiten van de Framework Agreement niet heeft kunnen voorzien dat de aanpassing van de Software aan de Nederlandse markt – die Alert c.s. zou uitvoeren in het kader van het project bij JBZ en op de voortgang waarvan TsZ (dus) geen invloed had – zodanig moeizaam en vertraagd zou verlopen dat (onder meer) JBZ de samenwerking met Alert c.s. zou verbreken en TsZ in de positie van ‘pilot ziekenhuis’ zou komen te verkeren. Deze onvoorziene omstandigheid heeft ertoe geleid, aldus TsZ, dat zij is geconfronteerd met extra inspanningen (zowel financieel als personeel) van een zodanig omvang dat Alert c.s. naar maatstaven van redelijkheid en billijkheid niet mag verwachten dat TsZ de Framework Agreement voortzet. TsZ heeft in dit verband verder gesteld dat Alert c.s. niet bereid is gebleken om TsZ voor genoemde extra inspanningen te compenseren.

4.28.

Uit de parlementaire geschiedenis bij artikel 6:258 BW blijkt dat bij de beoordeling van de vraag of sprake is van ‘onvoorziene omstandigheden’ niet beslissend is of die omstandigheden ten tijde van het sluiten van de overeenkomst voorzienbaar waren, maar dat het erop aan komt of partijen in de mogelijkheid van het optreden van deze omstandigheden hebben willen voorzien of althans die mogelijkheid stilzwijgend in hun overeenkomst hebben verdisconteerd (TM, Parl. Gesch. 6, pg. 968; MvA II, Parl. Gesch. 6, pg. 973).

4.29.

De rechtbank is van oordeel dat het dat het beroep van TsZ op artikel 6:258 BW niet kan slagen. TsZ was ten tijde van het sluiten van de Framework Agreement bekend met het feit dat de Software nog niet geschikt was voor de Nederlandse markt, maar ging er naar eigen zeggen vanuit dat de noodzakelijke aanpassingen aan de Software zouden worden gerealiseerd in het kader van het (sinds juli 2008) lopende ontwikkeltraject bij pilotziekenhuis JBZ (de Roadmap). Dat betekent dat TsZ ten tijde van het sluiten van de Framework Agreement wist dat de (tijdige) implementatie van de Software binnen haar eigen organisatie in grote mate mede afhankelijk zou zijn van het welslagen van het ontwikkeltraject bij het JBZ. TsZ, die zelf stelt dat haar beslissing om met Alert c.s. te contracteren in doorslaggevende mate was gebaseerd op haar overtuiging dat zij ‘op een rijdende trein stapte’, heeft echter geen aanleiding gezien om een contractuele voorziening te treffen voor het geval deze trein onderweg vertraging zou oplopen of zou worden stopgezet, terwijl het een feit van algemene bekendheid is dat zich bij grote ICT-ontwikkelprojecten als de onderhavige veelvuldig – en vaak substantiële – vertragingen voordoen en ook het risico dat een dergelijk project voortijdig wordt afgebroken naar algemene ervaringsregels reëel is te noemen. Bezien tegen die achtergrond is de rechtbank van oordeel dat de omstandigheid dat het stranden van het project bij het JBZ (ook) ingrijpende gevolgen heeft gehad voor het verloop van het project bij TsZ, zo dit al zou kunnen worden gekwalificeerd als een onvoorziene omstandigheid in de zin van artikel 6:258 BW, voor eigen rekening van TsZ dient te blijven.

4.30.

Uit al het voorgaande volgt dat aan TsZ op 2 november 2011 niet de bevoegdheid toekwam om de Framework Agreement buitengerechtelijk te ontbinden.

Opzegging

4.31.

TsZ heeft zich meer en meest subsidiair op het standpunt gesteld dat zij de Framework Agreement rechtsgeldig heeft opgezegd op grond van artikel 7:408 BW, althans op grond van artikel 3.3. van de Framework Agreement.

4.32.

Allereerst stelt TsZ dat zij op grond van artikel 7:408 lid 1 BW – waarin is bepaald dat de opdrachtgever te allen tijde de overeenkomst van opdracht kan opzeggen – gerechtigd was de Framework Agreement op te zeggen, zodat haar brief van 2 november 2011 ertoe heeft geleid dat de overeenkomst op die datum is beëindigd. TsZ voert in dat verband aan dat partijen de toepasselijkheid van deze bepaling niet buiten toepassing hebben verklaard. Dit standpunt overtuigt de rechtbank niet, omdat partijen – zoals Alert c.s. ook tot haar verweer heeft aangevoerd – in artikel 3 van de Framework Agreement een van deze algemene wettelijke regeling afwijkende contractuele voorziening hebben getroffen, hetgeen hen als professionele partijen ook vrij stond.

4.33.

In artikel 3.2 van de Framework Agreement is bepaald dat deze overeenkomst niet eerder dan 60 maanden na ondertekening kan worden beëindigd. Vervolgens volgt uit artikel 3.3 dat TsZ, indien zij de overeenkomst wenst te beëindigen, dit schriftelijk dient te doen en daarbij een opzegtermijn in acht dient te nemen van één jaar. De rechtbank heeft hiervoor overwogen dat TsZ onvoldoende heeft aangegeven in welke concrete contractuele verplichtingen Alert c.s. jegens haar zou zijn tekortgeschoten. Reeds om die reden kan de stelling van TsZ dat het – gegeven onder meer de tekortkomingen van Alert c.s. – naar maatstaven van redelijkheid en billijkheid onaanvaardbaar zou zijn om TsZ aan deze contractuele opzeggingsregeling te houden, niet slagen.

4.34.

In de omstandigheid dat TsZ zich in haar opzeggingsbrief niet heeft gehouden aan de contractuele opzegtermijn, ziet de rechtbank – anders dan Alert c.s. – geen aanleiding om deze brief zonder rechtsgevolg te laten. De rechtbank zal de opzeggingsbrief van 2 november 2011 daarom aldus lezen dat TsZ daarmee heeft bedoeld de Framework Agreement op te zeggen tegen de eerst mogelijke termijn. Artikel 3.3 strekt ertoe dat Alert c.s. (minstens) één jaar voor het eindigen van de overeenkomst door TsZ op de hoogte wordt gesteld van het feit dat de overeenkomst zal (gaan) eindigen. Aan deze mededelingsplicht heeft TsZ voldaan door middel van haar brief van 2 november 2011.

4.35.

TsZ heeft gesteld dat de Framework Agreement op 31 december 2009 is ondertekend. Alert c.s. heeft er echter terecht op gewezen dat uit de gedingstukken blijkt dat partijen op 22 en 23 januari 2010 nog in onderhandeling waren over de (definitieve) tekst van de Framework Agreement en dat deze uiteindelijk pas op 26 januari 2010 door partijen is ondertekend. Gelet op de strekking van de brief van 2 november 2011 en de inhoud van het lichaam van de dagvaarding, zal de rechtbank de vordering van TsZ aldus lezen dat zij (tevens) een verklaring voor recht vordert dat de Framework Agreement rechtsgeldig is opgezegd tegen 26 januari 2015. Dit onderdeel van de vordering van TsZ ligt voor toewijzing gereed.

4.36.

Voor zover de vordering van TsZ aldus moet worden begrepen dat zij óók in het geval de Framework Agreement door opzegging is geëindigd aanspraak maakt op vergoeding van schade door Alert c.s., overweegt de rechtbank dat de Framework Agreement daarvoor geen aanknopingspunten biedt en dat TsZ ook geen (andere) feiten of omstandigheden heeft aangevoerd op basis waarvan een op Alert c.s. rustende schadevergoedingsverplichting zou moeten worden aangenomen.

Proceskosten

4.37.

TsZ zal als de in het ongelijk gestelde partij in de proceskosten worden veroordeeld. De kosten aan de zijde van Alert c.s. worden begroot op:

- explootkosten € 0,00

- griffierecht 3.621,00

- getuigenkosten 0,00

- deskundigen 0,00

- overige kosten 0,00

- salaris advocaat
6.422,00(2,0 punten × tarief € 3.211,00)

Totaal € 10.043,00

5. De beslissing

De rechtbank

5.1.

verklaart voor recht dat TsZ de Framework Agreement bij brief van 2 november 2011 rechtsgeldig heeft opgezegd tegen 26 januari 2015,

5.2.

veroordeelt TsZ in de proceskosten, aan de zijde van Alert c.s. tot op heden begroot op € 10.043,00,

5.3.

verklaart dit vonnis wat betreft de beslissing omtrent de proceskosten uitvoerbaar bij voorraad,

5.4.

wijst het meer of anders gevorderde af.

Dit vonnis is gewezen door mr. E.J.C. Adang, mr. I.L.P. Crombeen en mr. M.W. de Hoon en in het openbaar uitgesproken op 27 november 2013.

Ontbinding van de Framework Agreement tussen TweeSteden Ziekenhuis en Alert Life Sciences Computing B.V.

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