Archive for July, 2006
I bet all of you got emails from non-IT people this week letting you know that H.R. 4157 was passed by Congress. Did you politely thank them, or, did you say “hey, I am on the same email lists as you”?
Anyway, I think the most substantial impact of this bill would be the fact that hospitals would be able to provide physicians with EHRs without being in violation of Stark. This will clearly benefit the largest providers and those with the most advanced technology. If you are a free-standing community hospital the pressure is getting greater to align with a larger system (as if it weren’t already unbearable).
I received two emails before H.R. 4157 went to the floor. One from CHIME encouraging me to let my congressman know we needed him to support the bill. The other was from AHIP (I am also the CIO for our HMO) encouraging me to tell my congressman to vote against the bill. I may have too many lobbying groups working on my behalf.
I think AHIP got it right. This bill originally called for interoperability standards. Theoretically it wouldn’t matter if a doctor used a particular hospital’s EHR because the interoperability standards would allow them to practice at the competing hospital and still have access to those patient’s information. As passed, HR 4157 gives large health systems ways to lock in physicians. If you are a doctor and all of your patient’s information was in one system, it would be too inconvenient to admit them where you don’t have easy access to that patient data.
AHIP is also concerned about the deadlines for the ICD-10 coding systems. That will be a lot of work.
For those of you with a fiscal year that starts 1/1 you are probably ramping up your planning and budgeting efforts. When trying to determine which IT projects you will add to next year’s plan there are two constraints that one must consider: staff time and money.
Of the two of these, I find the human constraint to be the most limiting. You could double our capital budget, and we still couldn’t accomplish significantly more.
Even though we are acutely aware of this contraint, we still manage to commit to more projects than we can complete.
At the planning stage it is extremely difficult to estimate how much staff time a project will require. There isn’t enough time before budgets are due to develop detailed project plans. Universally people always underestimate the amount of effort a project will take. Even seasoned veterans make this mistake over and over. I guess we always assume that things will go to plan. the fact is, that they never do.
Vendors are little help. The time estimates they provide for projects are not based in reality in any way. One of our HIS vendors states that their eMAR and medication scanning product can be implemented in 3 – 4 months. Our experience is more like 15 months., and we have our A-team working on that project. You can’t even get your medications unit-dosed and bar-coded in 4 months.
I was discussing this tendency to underestimate effort with one of my colleagues. He suggested that we should start multiplying our best guesses by 3. I was thinking 4. We are both probably underestimating.
MEDITECH has a terrific customer web site. They were one of my first vendors to log all of the service issues using a web tool that was shared by the customer and the vendor. They do a great job of documenting everything related to an issue, even the phone calls. It is great to be able to read the complete history of a problem.
Because of this system, I can tell you that Affinity has 204 open issues. While that may seem like a lot, it really isn’t when you consider the breadth of applications and the size of the organization. I can tell you that none of them are significant (you don’t have to turn off your mobile phone, Priscilla).
It amazes me the number of vendors that still don’t have an online system for tracking service issues (Amicas comes to mind). Some use Excel spreadsheets to track issues. When you are going through a major implementation and issues are by the minute, it doesn’t work to have a tool that only one person can update. We use our own tools (QuickBase or SharePoint) when our vendor doesn’t have one.
Update: Amicas now has a great web-based service tracking tool.
Some issue tracking systems could be better. Our health plan uses products from QCSI to manage that line of business. They have an online issue tracking system. But it could be better. In our service agreement we went through painstaking efforts to define levels of issues and acceptable response times to each level. However, their issue tracking tool does not allow us, or them, to specify which level issue is being reported. Consequently, they have no basis to provide us the promised support and we have no basis for knowing if we are getting the promised level of support.
In our selection processes we always ask new vendors how they manage service issues. This is an important consideration to me.
Back to the MEDITECH customer web site – I am not going to let them totally off the hook. They have had a greyed out link to a “CIO Portal” for a number of months with a little icon claiming that is is coming soon. I guess “soon” is a relative term.
Look for my next post soon.