Preparing budgets for the jump to "going electronic"

I was a child of the 80s, really, so I don't remember what the hubbub was about Bob Dylan "going electric". Wikipedia has an article about the incident, including the public reaction. Apparently it caused enough of an uproar for there to be a whole article devoted to the incident.

Anyway, getting your hospital to "Go Electronic" is probably just as shocking. It's not just a "software update".

First, there are "hidden costs" to going electronic, that vendors can't really tell you about, including :

1. IT/Software Maintenance costs
2. Changing hospital managerial structure / governance
3. Updating hospital policies
4. Developing Informatics platform
5. Developing robust training platform (for doctors, nurses, pharmacists, and all clinical staff)
6. Policy / Protocol / Order set / documentation building and development

... among other things. The hard part : You should plan for these "hidden costs". (Vendors don't generally bring these up before a sale, I think because a) it might cause you to think twice, and b) they often sell consulting services to help fix this stuff later.)

Some more conspiracy-minded folks, when they figure this out, will accuse the vendors of "Not fair! You didn't mention those costs!" - But in all fairness to the vendors, these costs are a hard discussion to have.

Why? Not only are there conflicting financial interests, but vendors often can't gauge your hospital clinically. After all, they are software companies, not hospitals, and so they have trouble giving accurate opinions about your clinical operations.

What I mean is this : If you actually study those "hidden costs" in detail, you'll notice they all depend on how you run your clinical ship. Let's review some of these "hidden costs" again :

1. IT/Software maintenance costs - Depends on your clinical staff, how they use the system, how often they want things fixed/updated - Every hospital is different. Software companies can't really gauge this for you.
2. Changing hospital structure / governance - Depends on your hospital's culture, some hospitals have an easy time adjusting, others don't. Software companies can't really gauge this for you.
3. Updating hospital policies - Depends on your hospital's clinical policies - Some hospitals require only minor updates, other hospitals require heavy changes. Software companies can't really gauge this for you.
4. Developing an informatics platform - Depends on your hospital's budget and understanding of the term "informatics". Some hospitals will adapt quickly and assign these roles formally. Others will try to do this in small increments. Software companies can't really gauge this for you.
5. Developing robust training platform for all clinical staff - Depends on your hospital's pre-existing training platform. Some hospitals will require significant changes, others will only need a little help. Software companies can't really gauge this for you.
6. Policy / Protocol / Order set / documentation building and development - Depends on your hospital's already-existing policies, protocols, order sets, and documentation. Hospitals with good design will have an easier time converting them to electronic. Hospitals that mix their policies / protocols / order sets / documentation will have a harder time. Again - Software companies can't really gauge this for you.

I think one of the hardest things about preparing for the jump, is that to answer these budgeting questions accurately reqires getting an honest assessment of your clinical staff, so that you can plan a good budget.

A good CMIO can help guide these budgeting discussions and decisions before, during, and after your go-live. Most CMIOs continue to practice clinically, so they can learn your hospital and give you an honest assessment of your clinical workflows.

If you don't have this discussion before go-live, you may find yourself with unrealistic early budget decisions which eventually hamper your eventual growth electronically. It's always better to start this discussion and planning process early.

Next post, we'll talk about developing meaningful training mechanisms for both before and after your go-live.