The Capital Region of Denmark and The Administrative Region of Zealand (RH/RS) are in the process of selecting a vendor for their c. DKK 1 billion (€135M) investment in a new IT-healthcare platform.

The purpose of the tender is to ensure that the chosen IT-healthcare platform will meet the defined requirements for IT support of clinical and administrative work within the health care organization of Zealand. The healthcare platform will need to support close to 40,000 IT users. It will need the capacity to be used by up to 12,000 clinical and administrative users at 17 hospitals and 54 other healthcare institutions simultaneously.

The chosen IT-healthcare platform is expected to start a pilot operation in 2014 in the Capital Region, be commissioned in early 2015 throughout Zealand and then be rolled out towards the end of 2016 in the rest of eastern Denmark.

The pragmatic approach

In our post “Danish Healthcare Mega Investment Requires a Pragmatic Approach to Selecting New Software” we explained how RH/RS has defined themselves as mainstream type buyers. RH/RS do not consider themselves innovators or early adopters, but rather consumers of proven and tested technology. RH/RS wants to follow after other customers who have already found and repaired the bugs and inconveniences associated with “fresh” technology.

Over the last couple of months RH/RS haven been through a thorough investigation process with each of the five “long-listed” vendors (Systematic, Epic, Cerner, Cambio and Siemens).  We therefore must assume that RH/RS has an up to date picture of who can deliver what, which functionality is in the R&D pipelines and what still remains as intentions on the R&D roadmaps.

The big questions is therefore:

Which requirements should RH/RS include in the final Request for Proposal and what should they leave out and run as separate public tenders after having chosen the IT healthcare platform vendor?

The options

RH/RS has already listed the following options in the invitations for prequalification:

• Obstetric EMR
• Critical Care EMR
• Anaesthesiology EMR
• Cardiology EMR
• Oncology EMR
• Voice recognition
• Digital dictation
• Facilities for letting GPs, specialists and other provider groups use the solution for EMR and billing purposes
• Interfacing with robotic medication
• Integration
• Consulting services
• T&C for additional licenses
• Transferring solution maintenance and support to 3^rd parties
• Making commercial T&C available to the other administrative regions in Denmark

Some of these are purely commercial and it makes good sense to clarify those now. What to include in terms of functional requirements, however, should be considered very carefully. The current Request for Proposal includes close to 1,500 functional requirements, 80 use case representing another 500  functional requirements and a number of commercial/contractual requirements.

Public tenders are expensive and time consuming

The temptation to include as much as possible in the IT healthcare platform is obvious. Public tenders are expensive and time consuming. By including as much as possible now RH/RS will save taxpayers money reducing the number of public tenders required after “the big one.”

Integrated functionality

By including as much as possible now RH/RS can also secure that they get as much native functionality as possible delivered with the chosen system. Adding functionality later through third parties requiring interfacing and integration always represents a substantial risk.

Maintaining the competitive pressure

Despite the benefits listed above there is one compelling reason not to ask for more than all the three short listed vendors can provide.  And that reason is to maintain a competitive environment.

Why do we run public tenders?

There are many reasons for running public tenders. The most important is to ensure vendors a fair purchasing process and at the same time create and maintain a competitive environment for the acquisition.

Maintaining the competitive environment requires that RH/RS do not ask for more than all three vendors can deliver. By restricting the requirements making all three vendors equally good, RH/RS achieves the best negotiation position possible.  They can push for the best price/performance ratio taking advantage of the fact that software has very little marginal cost.

The marginal cost of software is close to zero

In a market characterized by perfect competition, the price of software would be very low. In a perfect market the price of any commodity will approach the marginal cost of providing the product. As the marginal price of providing software is very close to zero, the price would approach zero. Vendors would be able to charge for auxiliary services, but the software itself would be under severe competitive pressure.

The supply side of the market (the software vendors) works hard to differentiate their products, because they understand that only the differentiation will allow them to charge a premium. The demand side (the customers) should work hard resisting the differentiation as it gives the vendors a de facto monopoly. No one prefers to be served by a monopoly.

There is obviously differentiation that provides a lot of value to a customer, but – as mentioned – it always comes at a price. The question is how much RH/RS can push down the price by maintaining the competitive pressure and postpone some of the functionality to a time where such functionality is available from more than just a few suppliers and can be acquired through a new competitive process.

Return on investment

Vendors will argue that additional functionality will improve productivity and the value for users (health care staff, patients and administrators). Maybe they are right, but financial justifications are very hard to apply in the healthcare industry.

By securing a competitive situation we estimate that RH/RS may be able to obtain a three digit million benefit when playing the vendors against each other in the final negotiations. They can do so without jeopardizing project completion by applying the pressure on the price for the software. Applying pressure on auxiliary services such as analysis, customization, training, integration etc, should be done more carefully, as the vendors have a completely different cost structure on these elements.

Disclaimer

This article is primarily based on publicly available information and the interpretation and evaluation of TBK Consult. Corrections of factual information as well as challenges to our assessments are welcomed. All the statements and assessments expressed in this article are proprietary  of TBK Consult. TBK Consult is not affiliated with RH/RS and RH/RS has not been asked to comment on this article nor have they done so.

Related articles

• Danish Healthcare Mega Investment Requires a Pragmatic Approach to Selecting New Software
• Danish healthcare’s mega IT investment vendor qualification is based on Software Quality Assessment
• How Danish healthcare authorities will create the short list for final software vendor selection
• Withdraw or lose? – The challenge for 4 of the 5 vendors in Danish EMR mega project
• Breaking News: IBM, Epic and Cerner to compete for Danish €135M healthcare IT project
• Why the €135M Healthcare Platform Project Went to Epic/NNIT