Defining the problem
Clients generally do a pretty good assessment of need. There is either a problem or an operational deficit that needs to be addressed. They also believe there is an IT solution to this problem or need.
To be clear, after 20 years in the Laboratory and Information Technology field, I have no doubt that clients recognize the need, but the search for a solution is much more nebulous. When searching for a vendor, sales staff tend to show products to staff of the departments that want the solution. While evaluating products, often new problems are identified that were never thought of before. For example, you may want a Pathology system, but during a demo of a product voice recognition was demonstrated and this would be a very good solution as well for your department. One may see a product for a laboratory solution, but another vendor will give away their laboratory solution to get a Hospital Information System contract.
Based on the need or problem, one has to ask what the preferred solution for the entire organization is.
Defining the Solution
An IT solution is at its core an application that solves an operational need or problem. This is a combination of software and hardware. I have found that often the two are addressed independently, but nothing is further from reality. Applications do not live independent of hardware. Hardware exists to support applications.
A teacher of mine once described the difference between hardware and software by describing the difference between the brain and the mind. You can search a brain with the most powerful microscopes, one can never see the mind. The same goes for computer systems. While software engineers will often talk about a bit and the concept of a switch being either on or off, thus the binary system is used for things like bytes and hexadecimal programming. For the vast majority of the public, this is no more an academic conversation piece.
The take home is that an IT Solution comprises the hardware AND software of a product.
The Philosophy of an Organization: Best of Breed versus Single Source Solution
I am often asked “what is the better way to go when selecting a Healthcare Solution, Best of Breed or Single Source solutions?” Both have merits and drawbacks. Usually the answer is not purely Best of Breed or Single Source, but somewhere in between.
(Note the use of Single Source versus Sole Source. Sole Source implies there is only one vendor to supply a solution)
Single Vendor Solutions provide the greatest standardization for an organization. If a client is looking at HIS vendors, often the vendor will also have ancillary application products as well such as Laboratory, Pharmacy, Radiology, Physician Practice, etc.
The advantage for Single Vendor Solution is usually cost savings, but it also saves on maintenance overhead, and resolution turn around times. Vendors in this space generally have a solution that requires few interfaces to exchange data between the ancillary products. Support is simplified because there is only one vendor to call if there are issues. For example, if there is an issue with the Medication Administration Report, the help desk of an organization only has one vendor to call, not one for the HIS and one for the PHIS. Same is true with lab results posting on a patient’s chart. Again, deciding if it is an HIS issue or an LIS issue is not relevant when the client is Single Source as there is only one vendor to call. It also reduces IT application resources to a certain extent, mostly in the interfacing realm. However, there still needs to be adequate resources to support those Ancillary departments and often Single Source vendors overstate FTE savings. The true savings is in SLA and TID savings.
The downside of Single Source is usually a lost in functionality. The list of vendors that can compete in the Single Source space is very limited in the case of HIS. Their focus is generally HIS, not necessarily PHIS, RIS, or LIS. This is not to say the ancillary products are not good products. It is to say that they may not meet the preferred needs of the ancillary departments. Understanding this is critical because the needs of the ancillary departments are important to the organization and should not be taken for granted. However, balancing the needs of the departments versus the cost and support overhead savings is a critical discussion to have prior to vendor selection.
On the other end of the spectrum is the Best of Breed Philosophy. This philosophy or approach allows for the greatest amount of functionality diversity. This usually creates better satisfied departments as they select the optimal solutions for their needs and produces a sense of ownership.
This is not without its costs. There is additional costs in TID, hardware, time to implement, competing priorities, and overhead in support. However, the investment in this diversity generally makes the organization a much better competitor in the Healthcare market. The complexity of negotiating contracts also increases as each Ancillary system is its own mini IS department.
USIT Healthcare Consulting has years negotiating these contracts and helping sites develop a comprehensive strategy for making the best philosophic decision. Keep in mind that few sites can achieve a pure Best of Breed or Single Source solution. However, deciding on the best Philosophy to meet organizational goals.
Scoping and Budgets for the Project
Scoping the project should now begin. It is time to put limits on the project for the purposes of putting the project to bid. If you are scoping a project for multiple facilities, remember to include this for budgeting purposes.
Budget constraints should generally be kept for the vendor quoting process. Let the vendors show products and the Team evaluate functionality. However, raising capital for a project almost always requires a budget cycle, so ensure that timing for the project is correct based on the time for vendor selection. Smaller solutions, this may be a few months. For larger projects, this may be up to two years.
The Request for Proposals
While working in sales, on multiple occasions, bids have come in with comments “Can your system perform a function like vendor X”. This is totally inappropriate for an RFP. First, competing vendors are not obligated to know product functionality beyond their own. Second, it signals to the sale department that Vendor X is already your Vendor of Choice (VOC) and they will likely not dedicate a lot of time trying to meet the RFP need. Third, this signals to Vendor X that they are VOC and they might not be motivated enough to get the best deal. Finally, the RFP process is designed to have vendors fairly compete based on your client’s needs, not on feature functionality of a specific product. This is totally unprofessional.
And RFP should represent your organizational goals based on your current gaps. The RFP should be compiled while in the Defining the Problem phase. As vendors present solutions, it is totally appropriate to modify the RFP as systems are reviewed. This will make you bettered prepared later in the buying cycle to present a comprehensive RFP.
Review the RFP constantly as more information is obtained. When the field of vendors has dwindled to a few vendors and are ready for finalizing the selection, you will have a comprehensive and complete RFP.
One final note on RFP’s. Do not assume functionality. Be very careful of comment terms that may be only common within your organization. Terms like “Integrated system” can be to general. Integrated could mean systems that interface cleanly or it could mean shared dictionaries. The same is true of preconceptions of what standard functionality is, which is always subjective and can cause true conflict between client and vendor alike.
To not hesitate to ask for clarification on things returned on the RFP that you do not understand, are ambiguous, or just an answer that contains words with not substance. The fact that you sent an RFP to the vendor means the vendor is still in play for a sale. They are not doing you any favors by returning the RFP and they are doing themselves no favors by not replying to follow questions.
The Bidding Process
Once we have scope and proposed philosophy for a solution, it is time to put the contract out to bid. Most organizations have a set protocol for soliciting bids from vendors. In order to comply, one should know if an RFP is required before or after the bid process begins. Often an RFP is done after, but that should not stop your site from starting the RFP process. Do not wait on this. The single biggest mistake I have seen is that the RFP process is started after the bidding process begins.
During the vendor presentation, it is critical that the correct team be assembled to review the functionality of the system. Generally a point person or team is appointed to the vendor selection process. They should have functionality questions ready for the vendor while the presentation is going on from the RFP. New questions will come up and the answers well documented. These MUST be submitted to the vendor as minutes so there is documentation on promises made. Follow up questions should also be documented and answers added when they come back.
When modifications are made to a quote, ensure the necessary decision makers know what the changes are and why they were changed. Once during a technical review section of the presentation, I requested that servers be removed from the bid as we would be virtualizing them. The vendor complied. However, a competing vendor did not get the client the revised quote in time for signature. The consequence was that the competing vendors quote was higher by almost $100.000, plus annual SLA costs. Given this, the decision was made to go with the first vendor even though the preferred lab vendor was the competing vendor. Two lessons regarding the vendor selection can be gleaned from this. One, the purchasing vendor should have questioned the change and the reduction before he signed the contract. Second, the vendor should have sent the revised quote in immediately knowing how close the deal was to being signed. I suspect that the competing vendor felt his company was VOC and the deal was in the bag. Bad move on his part!
When going on site visits, always insure that the site is using the current version of software you are there to see. If there version is so new that you cannot see the current version, than you are looking at a beta version and you contract should represent this.
Who Wins the Bid?
In the end, everyone involved in the sales process has a favorite vendor. However, I have never been as at site that had a unanimous decision. Everyone on the team are individuals and will have reasons for buying one system over another. The important thing is that all voices were heard, including the dissenting ones. In general, the best vendor will win as long as they all play on a common footing.
One more note. Decisions for vendors are often made based on many factors. One factor not mentioned is budget constraints. If a vendor is being selected soling on the bottom line, a lot of functionality can be lost. However, the Team should know up front how much the budget is and heavily budget constraints play into the bidding process. Being up front about this will make it easier for the team to accept the final solution choice.
Abbreviations:
HIS: Hospital Information System
PHIS: Pharmacy Information System
LIS: Laboratory Information Systems
RIS: Radiology Information Systems
SLA: Service Level Agreements
TIS: Training Installation and Documentation
RFP: Request for Proposals
VOC: Vendor of Choice
FTE: Full Time Employee