The process of selection of software to assist in the management of a Hospital is not something to be undertaken lightly or without expert help if there is not strong internal expertise available. The following series of suggestions are gleaned from rather more experience of difficulties and complexities than I would be all that keen to admit. They are passed on in the hope that some of the mistakes I have seen, or worse still may have been involved in, are not repeated by my readers. If they do repeat them they will not be able to claim they weren’t warned!.
Firstly it is vital to recognise software is an enabler of improved and streamlined clinical processes. It is not an end in itself and this needs to be clearly realised right up front. The implication of this is that there is a large amount of pre-work even before a selection process is begun. In an ideal world the selection of software would be preceded by the development of a strategic plan for hospital operations and then a plan of the priorities for the deployment of information technology to support the hospital’s desired way forward.
This plan needs to be quite future orientated and to recognise that organisations change and evolve over time. There is not much point automating five year old business practices or business practices that are about the be re-engineered. If there is organisational clarity on the hospital’s current situation and future direction then is the time for the development of the Health IT Strategy, Implementation Plan, Business Case and Benefits Realisation Plan to suit that direction.
A few important things to remember here include the critical need to ensure quality genuine clinical (medical, nursing and ancillary) involvement in the planning process and the early identification of the sponsors and champions who will be needed to contribute to the work of implementation and to assist in the change management involved. If the plan is not genuinely owned by those who will be impacted it will fail. Education of and communication with the hospital staff in general as to why and what is crucial at this point.
Also, before selection processes can begin, it is important to be clear just what is being sought. True greenfields sites are rare so consideration of how the new and old will interact and be phased in and out will be important. It seems typical these days for Hospitals and Health Systems to decide to acquire a total system in two, three or more lumps. These most usually are a Financial Suite (+/- Billing) and a Clinical / Patient Management Suite. (Frequently Human Resources etc are a third chunk). It makes very good sense to only be undertaking one of these projects as a time to avoid overwork of support staff etc.
For the purposes of this short discussion I will now focus on the selection of a Hospital Clinical Information System of the sort that has within scope Patient Management, Order Entry / Results Management, Nursing, Clinical Services (Labs, Radiology, Pharmacy etc) as well as the necessary scheduling and reporting tools to make the system useful.
At this point two decisions are typically required. First will the system be home-grown or purchased and second will the purchase be of best of breed components and system integration services or a fully integrated clinical suite covering all the applications that are needed. These days it seems the most common approach is the purchase of integrated systems, and this is now largely the norm, so I will focus on this approach.
The approach I suggest, once the decision has been made to go with an integrated clinical suite, is as follows.
Step 1. Conduct a market scan of possible providers who have some credibility in Australia or are major players internationally. If compliance issues are a key concern a public Expression of Interest (EOI) requesting the information below be provided is reasonable and can be quickly and simply done. These approaches will identify your possible long list of providers and next we ask each of them for the following:
1. A list of at least five satisfied customers who have operational and fully integrated what you are planning to install. The key words here are “have operational and fully integrated” and “what you are planning to install”. This will exclude those who are still inventing their system (such as iSoft) or those who have a mish-mash of legacy systems which are partially integrated and which will never be fully and seamlessly integrated (It makes no sense to buy a non-integrated suite. If you do that you might as well buy a best-of breed solution.).
2. Phone contact details and calls to confirm details of implementation status, responsiveness to problems and satisfaction and a half day demonstration to a sensible number of key staff of the overall look and feel of the system will quickly obtain a reasonably short list of realistic prospects.
3. Development Plans and Timetables and what their history on on-time development and successful deployment is.
4. Financial Situation including the level of R&D spend as a fraction of revenue as well as profitability and balance sheet over the last 3-5 years. Software development companies have the possibility of being very profitable and it is a bad sign if they don’t have a reasonable ongoing profit margin.
It is also a good idea to make it clear in the EOI or request for information that any vendor “smoke and mirrors” in the answers will lead to instant disqualification from the ongoing process.
Consideration of the responses from those on the long list should allow the development of a short list of four or five reasonable possibilities. This sets the stage for the next step.
Step 2. The next step is to develop a Request for Tender which is given to each of the short list which covers business, technical operational and functional requirements. This should be designed to form the basis of an implementation contract and be designed for structured evaluation. The scale of the work involved in doing this quickly and successfully – with the right amount of user consultation on their expectations – may mean some consulting and expert legal help could be useful at this stage. (It is important the process not drag out as the momentum for change can be lost.).
On the basis of the tender responses the two top providers should be selected to undertake scripted evaluation of their product. (Lower ranked vendors can be brought back into the process if one of the top two falls out for some reason.) The scripts should be developed by the users of the various aspects of the system and intended to exercise the key functionality that is to be provided – as well as the intangibles such as the quality of the user interface, the skills of the demonstrating staff etc.
The provider should be asked to configure a system to look like a hospital similar to the purchasing organisation and to be loaded with a small test data set which can be exercised in real time to confirm the reality, functionality and integration of the candidate system.
The aim is to see the system actually do what is needed by users in a reasonable way. It must, however, be realised that the major advanced systems (Cerner, Epic, IBA etc) are very flexible and are designed to be built / configured individually for each organisation to maximise the quality of the functional fit to the organisation’s needs. These systems are not package software (like Microsoft Word) and fixed in what they can do – complex though that may be. This means the script demonstration process needs to be interactive and flexible and they point out the number of different ways the seemingly same thing can be done.
The system which has a significant number of satisfied user clients – of the software that is being purchased – and which best passes a scripted evaluation (which is not disclosed until the day of testing) has to be a very safe candidate for purchase (assuming all the technical issues (availability, response time etc) and the contractual issues can be worked through).
If Steps 1 and 2 are negotiated successfully – and the feeling among script evaluators and the technical staff is that the best system is appropriate, is real, works and is a good fit it is pretty safe to proceed. If not, great care is warranted.
David.
No comments:
Post a Comment