Advertisment

Cut Through the Hardsell...

author-image
DQI Bureau
New Update


Advertisment

“Always negotiate directly with the principal, and not his representative”

By Sunil Kapoor

When we conceived of the Hospital Information System (HIS) for Fortis Heart

Institute, a super-specialty cardiac care center, we were, for the first time in

India, aiming to set up a near paperless and ‘filmless’ hospital. The target

was to have every department and every patient record (including images and

data) electronically linked and archived, to be accessed by administrators and

doctors from anywhere in the campus or over the net.

Choosing and implementing the right server configuration was of utmost

importance and this posed quite a few challenges. The first was to have near

100% uptime, as all the medical records of the hospital would be maintained

digitally, and even the shortest downtime of the database would have serious

consequences. So, we had to make sure that there was a buffer for fault

tolerance and redundancy in data.

Advertisment

The application software was NT based, hence limiting our options. Then there

was the problem of the geographical location, as the Institute was in Mohali and

most of the major vendors did not have a large set up there. In fact, some of

the vendors did not even have direct representation, which was a real problem in

terms of initial requirement understanding, supply, installation and finally,

support.

To meet the near 100% uptime, we thrashed our the issue and finally went in

for a clustering solution. We built in redundancy on each and every point –two

identical servers working on heartbeat between them, operating systems mirrored

within each of the servers, redundancy power supplies and a network card in the

servers and an external storage unit. Redundant controller with Raid 0 and Raid

1 has been implemented on external storage for database redundancy. This

configuration gave us the first level of redundancy. Repeated discussions with

the vendors’ marketing and technical teams were held to reach a comfort level

between the operating teams on both sides with respect to the concept and

configuration.

We also took the application software to the vendors’ research and

development centers to get the clustering/application checked out and there were

learnings for all of us in the process. This helped us to ensure that the

vendors understood and appreciated the criticality of our requirement. Then,

when the concept and configuration were in place, came the issue of 24x7 direct

support from the principals.

Advertisment

The principals wanted the reseller and the application service provider to be

part of the contract. We were clear that any hop in between would result in a

time lag, which we could not afford, hence we insisted on working directly with

them. We also sat down and worked out a separate service and support contract,

as part of the main order. The learnings from this experience would probably be

valid in choosing and implementing a high-end server configuration in most

organizations.

Our learnings were three-fold:

  • Always go to the core technical team of the vendor,

    instead of relying on the company’s marketing team. This saves time and

    effort;

  • Insist that the concept (requirements, application

    response and uptime) are clearly noted on paper, apart from the bills and

    other relevant paperwork. This would put in clear perspective the vendor

    understanding as well as the material requirement; and

  • Always deal directly with the Principal and not his

    representatives while negotiating. This will avoid future confusion and cost

    or time escalation.

The author is head, Information Technology, Fortis Heart

Institute

Advertisment