Jan 16, 2008

Categorizing and narrowing down the products/vendors…….. why is this an important step?

Anyone who has worked with me knows that I strive to help my customers narrow down their product and partner/vendor options before looking at product functionality. Why is this a good first step?

  • Significantly reduces the time, and therefore cost, of your detailed feature/functionality and pricing analysis efforts.
  • Why test drive and negotiate pricing on a Volkswagen and a Mercedes (so to speak), if what you really need is the Mercedes.

    >>> I certainly don’t shop for other products that way.
    >>> Do you go to a new home Open House before you check out the neighborhood, the school district, and the pricing?

The features and functions of the product are ever changing, but the costs and partner/vendor will be with you for a long time.

I recommend that you come up with a filtering process to narrow down the field to 3 or no more than 4 “best of class” products, after you have determined what “class” you should be in.

I believe there at three clear product categories, Basic, Mid-Range, and High-end. Come up with whatever makes sense to you. How would you narrow down a car or home purchase? Use that approach, see if it works.

One way is by considering the 3-P’s……….. Partner, Price, and Product.

  1. Partner:
    Develop some criteria for the type, size, and experience of the vendor/partner you want to do business with for the next 10+ years. Then create a template to evaluate the vendors you are considering against these criteria. You can gather the information in a number of ways. Interview them, solicit responses to a Request for Information (RFI), ask around, do some research.

Some examples of important factors are:

  • Size: Revenue, # of employees
  • Financial viability: revenue track record, funding source
  • Experience: # of customers, # of users, California and/or LA/DMH customers, EDI (transactions per month) and/or ASP experience

2. Price:

Get some guidelines from your Finance Executive. Understand your agencies expense / project cost strategies and guidelines. Some questions to ask are:

  • Are you likely to finance the hardware and any other costs?
  • Do you have Microsoft non-profit pricing status?
  • Are you using a negotiated rate or cost reimbursement strategy in your contract negotiations? Is there an opportunity to cover some of the ongoing costs there?
  • How much additional monthly cost might be successfully rolled into your contracts?
  • Which fiscal year can you begin incurring these additional costs?
  • How can you handle significant up front costs? Or can you?
  • How will you handle incremental annual costs?
  • What does your grant writer / fund raiser need to solicit funds for this project?
  • What can be capitalized and what cannot? What can be financed and what cannot?

    Develop a budget model and itemize all project up front and ongoing costs. Costs will include many items not pertinent to the EHR-S vendor. For example:
  • EHR-S software costs, e.g. license fees and maintenance fees
  • 3rd party software costs, e.g. Report Writer client licenses
  • IT infrastructure hardware costs, e.g. PC’s, laptops, wireless cards, scanners, printers, servers.
  • IT infrastructure software costs, e.g. Microsoft Office, spam and virus software, operating system, email application, etc.
  • Services, e.g. EHR-S implementation, installation, report writing, forms/screens development, billing set-up, EDI set-up, etc.
  • Training, e.g. curriculum development, train-the-trainer, user training, training lab/equipment, etc.
  • Staffing, e.g. trainers, help desk, database administrator, etc.

    Now, develop a template to help you “estimate” the costs of products in several categories.

    3. Product:
    Product can be categorized into a) architecture and b) features/functionality.
    Meet with your IT or technical staff, or a consultant to create some criteria for the product platform or architecture. Make a list of key functional areas that you are interested in seeing.

    For example:
    a) architecture
  • Do you have a database preference? Do some research and ask your technical staff what they are most familiar with. Keep in mind that your agency is unlikely to ever have to develop feature and function sets for an EHR-S product, even if your vendor goes out of business. What your staff may be more likely to do, is add screens and fields to the database tables, add assessments to the workflows, and develop reports. Make sure that you don’t limit the products you are considering unnecessarily because the database is one your staff are not familiar with. Typically these products have administrator tools and utilities you will use, rather than programming in a database language.
  • Do you need a web based product or is a client-server product a better fit? Talk to someone who can give you a layman’s explanation of the pros and cons of each.
  • Do you need an ASP solution or is self-hosting the best fit? (see my BLOG on this)
  • How do you want to access the product remotely?
  • How much control do you need to have over the workflows and data elements you will capture? Do you need to make screen modifications and control which fields are mandatory etc. Or do you prefer that the vendor maintain all the change management for you?

    b) features/functionality
  • What are the key functions you “must have”. Here are some I think we should not have to live without today:
  • Electronic charts, including Notes & Assessments
  • Electronic scheduling (with compliance integration)
  • Referral tracking
  • Tiered user access controls (some by user roles, teams etc.)
  • Structured treatment planning (with libraries someday soon)
  • Medication history, tracking
  • Automated claims processing, with payor rules
  • Paperwork due date tracking (some with cycle date automation)
  • Alerts and reminders
  • An integrated, simple report writer and standard reports
  • EDI Translator capability, experience (likely custom for LACDMH)
  • LACDMH and Medi-Cal billing rules included
  • LACDMH and Medi-Cal data elements captured
  • Workflow assistance … maybe (E.g. Co-signature automatic routing)

    Now, create a key feature and key architecture template to help you categorize and filter each product you evaluate. You do not need to see a demo to get this information, you can start with an interview or RFI.

    Set a goal for your team to select no more than 3 vendors/products that are very similar in functionality, cost, and size/experience of the vendor. This goal will drive you to the right set of “best in class” products.

    Once you have your top 3, now is the time to invest in a cross-functional team to evaluate product functionality using a scripted demonstration process and specific pricing bids Good Luck!

by Keely McGeehan, Sahara Management Solutions, Inc.




No comments:

Post a Comment