The reality is when it comes to HIS, buying from one vendor does not mean that you are getting the best for each component. Think about the last time you bought a car. You may have visited multiple dealerships and test drove different models. After my car search I figured out that I wanted a Hybrid. Not the fuel saving one, I wanted a hybrid of TWO cars. I wanted the styling of one car with the technology of another. With so many different workflows within the continuum of care, and the corresponding personalities of each person managing those workflows; how can they decide on the same vendor?Organizations often have a purchasing policy around system selections. It normally involves getting three quotes and having a decision process. However, the decision process involves a committee that often will bend to what the “C” suite wants. Keep in mind that consensus is not about making unanimous decisions. But you want to avoid bending to the political winds instead of doing what’s right for the patient (first) and the employees having to use the system (second). So the RFP process has to be transparent across the Clinical Computing Committees and user groups.It all starts with a comprehensive development of requirements from the users and managers. This feeds the RFP questions and allows the committee to distill down the amount of vendors coming onsite. The demos must include a standard scorecard to be filled out by the attendees. This needs to be consistent for all demos, with consistent questions and consistent attendees. Once you have the results from the scorecards, then you can set up the reference site visits. Again, at the end of each visit there has to be a scorecard to capture everyone’s impression.Vendors will steer you to their best customer sites and some sites receive discounts of some sort to host the visit. Committees need to venture out to KLAS and other professional organizations for feedback on those vendors and on recommendations for what fits their requirements. If you find yourself giving up “requirements” just to fit a vendor’s single solution, then either it was not a real requirement or you are compromising functionality. If you make a single vendor decision for your organization, don’t be surprised when you find yourself dealing with multiple interfaces and what appears like modules that have the same name, but act like a “bolt on” feature. Many vendors purchased standalone applications and rebranded them to be part of their service offering. So just like buying that car, you pull into your driveway, raise the hood and find all the parts are made from different companies and countries. So what you’re really paying for is the convenience of dealing with one vendor, and one support. Hopefully, that was part of your requirements document.