As a Hospital IT Consultant or Healthcare CIO, I deal with IT vendors all the time. Here’s my take on working well with your IT vendors.

Two General Categories of Vendors

If the hospital follows the long-term strategy of “Build + Buy”, IT vendors often fall under two general categories:

  1. Software Development: These include companies that provide contractual employees, consultancy for in-house software development or outsourced application development. This engagement is for custom-built software such as hospital-specific clinical and research applications.
  2. Product/Service Providers: These include vendors of administrative software, e.g. financial and inventory systems, and ancillary systems, e.g. PACS and laboratory information systems. Others may provide services for hardware support and software acquisitions.

Working Relationship

When working with IT vendors, I find it best for the hospital management and/or IT department to do the following:

  • Treat them as partners. Make it easy for them to help you solve your problems.
  • Make them accountable for their product–AND their promises. Honesty, integrity and truthfulness are essential ingredients for an excellent working relationship.
  • Do not believe all their promises. Even with a good working relationship, understand that they are still in the business of selling.
  • Pay on time. Help the company thrive.
  • Make referrals. Help the company grow.
  • Give feedback of their services. Help the company get better.
  • Do not adapt their vision for your company. Come up with your own. Despite their good intentions, you know your company much better.
  • Identify success and/or acceptance criteria during development or implementation. These items should be specific and measurable. This helps everyone look at the same direction.

Choosing an IT Vendor

Document and understand your hospital and project needs before going through the process of vendor evaluation. It is easy to be distracted by ‘product or service peripherals’. Come up with a standard for evaluation and stick to it.

Beyond that, here are some qualities I look for in the company and in its people:

  • Excellent listening skills: They’re not only selling a product/service, they hear what you need and are sincere in helping you solve your problems.
  • Experience, knowledge and skills: They should know their product and their customers. They should know what they are doing.
  • Willing to learn: I admire organizations who invest in their people. They constantly strive to be better.
  • Ability to walk away from a project: I like vendors who can say ‘No’ to a project. It shows honesty, integrity and an understanding of their company’s or product’s limitations and capabilities. The opposite of this would be vendors who promise to have or do everything.
  • Accept defeat graciously: When other vendors are chosen, they still stick around and help with other projects. It reflects an organizational culture that wants to build relationships and not just a client base.

No healthcare organization is an island. Having the right IT partners can help the organization succeed in its process improvement, modernization and computerization efforts. The key is to choose wisely and maintain excellent working relationships.

These are just from my own limited experience. I’m sure there are more—and better—recommendations out there.

What’s your experience with IT vendors? Are they good or bad? How do you deal with the bad ones? What are your recommendations? Let me hear from you.

Do you have a Health IT project in mind for your hospital, department or clinic? Do you need help justifying it and getting it approved?

Here’s my quick tip: Use IRACIS.

I’ve been working in Health IT for more than 13 years and most of my experience involves working with hospitals. It can be daunting to justify a hospital IT project to management. What helped me was a concept I came across in a book–it’s called IRACIS.

IRACIS is an acronym that stands for:

  • IR: Increase Revenues
  • AC: Avoid Costs
  • IS: Improve Services

When using each item in IRACIS, be as concrete and as tangible as possible. Use actual numbers and figures, if at all possible.

Increase Revenues

Let’s accept it–all projects in the hospital should contribute to financial viability. That’s why this part of IRACIS is important. Possible areas you can look into:

  • Turn-around time: Streamlining queue-based processes and reducing waiting times help patient throughput.
  • Additional services: IT projects can introduce new hospital services, e.g. Telemedicine.
  • Value-added service: Basic services, e.g. laboratory, can be ‘converted’ to premium services once enabled by IT services.

Avoid Costs

Hospitals are pressured to manage costs. IT projects are often set in place to help avoid cost and reduce overhead in the long run. Possible ideas include:

  • Eliminate paper: IT projects can eliminate many paper-based requests and processes, e.g. logbooks, request slips.
  • Reduce manpower requirements: This may be a sensitive issue but some IT projects–not all–might eliminate several job functions.
  • Lesser redundant services: IT systems can catch redundant orders and tests. They also help manage inventory and supply chain.

Improve Services

This IRACIS component is often the most difficult to quantify. However, hospitals looking for opportunities to differentiate and expand their market cannot ignore this component. Some potential areas include:

  • Reduced waiting times and queue management: Hospitals can learn from innovative restaurants and banks about how to handle queueing, registrations and order-taking.
  • Patient engagement: Emails, SMS and Websites can increase range of patient engagement activities.
  • Customer service: Keeping databases on patient details and preferences can make the hospital visit feel more personal and tailor-fit.

The IRACIS approach is a quick-and-dirty tool but it can be extremely useful for proposing and justifying IT projects to management. When building your business case, remember to be as concrete and tangible as possible in each specific component.