So, it surprised me when I was listening to a CIO discuss Meaningful Use on one of the hscio.com podcasts. He stated that Meaningful Use was an underfunded mandate. That is far from our early experience at Ministry.

I don’t think either of us are incorrect. We just appeared to be starting from different positions and we took different paths to attest for Stage 1.

In our pursuit of the EHR incentives provided under the stimulus bill we piloted one hospital to create a standard approach for the remaining 14. Our pilot site was our most technically sophisticated hospital, so the work to be done was less than typical. In fact, this hospital (Ministry Saint Clare’s Hospital in Weston, Wi) is an all digital hospital that has had virtually all orders entered by physicians since 2006. We have invested over $100M in IT at this hospital, it is rewarding to know that we made decisions that positioned us well to achieve Meaningful Use. This incentive money offsets a small portion of that investment.

I believe that the effort to get this hospital positioned to attest for Stage 1 was as close to minimal as any hospital in the country. In my mind this is a best case for return on investment. Our remaining hospitals will be closer to break-even.

One thing that is not significantly different between my experience and the CIO on the podcast is the software. We both use GE Centricity Enterprise as our core HIS system. However, we did self-certify Centricity (and a collection of other EHR technologies) rather than upgrade to GE’s certified version. This also saved us money and allowed us to move quickly.

We have learned a couple of things about fighting fires, that is, addressing customer impacting service interuptions. We have learned that best way to respond to service interruptions is counter-intuitive and kind of complicated. So, we have done what we usually do when we want to improve something. We created written guidance on how to respond to IT Service Interruptions and we are constantly improving that written guidance.

The primary way we address an IT Service interruption is through the use of a Critical Response Team. The Critical Response Team has two primary goals:

• Cure the service interruption as quickly and completely
• Communicate to our impacted customers in a timely manner that satisfies the information they desire

Prior to developing our Critical Response Team methodology we seemed to fall into the trap that we should not bother the technical resources so they can fix the problem as quickly as possible. This is a huge mistake. Even if the duration of a critical application outage is extended by a great deal of time, it is critical to communicate the relevant facts about the outage to the customer. Time and time again we see that when we handle the communication well, the customers empathize with out plight and thank us for our efforts. If we go dark, we receive a lot of criticism, even if the efforts to resolve the problem were heroic. In essence, we buy ourselves time when we are good communicators.

When we form a Critical Response Team the meetings have three primary agenda items:

1. Define the problem.
2. Develop an action plan, with clearly defined assignments, to research the problem or resolve it.
3. Develop the communications including the message and the audience.

By nature people want to get off the call after number 2 and assume someone else will handle the communication. But we find that the communication must be written during that call while the technical experts are still on the call. This is the only way we get it right and it reinforces the importance of communications.

There are some keys to communicating with customers regarding outages:

• Communication coming from a named individual is critical in how the customer perceives the authenticity of the message. Critical Response Team messages should come from a person, not a generic mailbox.
• Tell the customers that addressing the interruption is our top priority and our team is dropping everything.
• Tell the customers that we know that this is impacting their ability to be efficient and effective and that we feel their pain.
• Tell them everything we know about the effects of the problem on them. Avoid the technical details, write the message from their perspective.
• Let them know that we are sharing everything we know, but things may change as we learn more.
• Provide an estimate about the duration of the outage. IT generally doesn’t like to do this because they think they will be held responsible for estimates given with incomplete information. But the customers need this because this will determine if they go to downtime procedures, if they should arrange overtime or if they should plan to bring in additional staff.

Let me know if you would like a copy of our Critical Response Team approach. As with everything, it is a work in progress. Just like our Root Cause Analysis changes the way we operate in IT, we perform Root Cause Analysis on our response to service interruptions and improve our Critical Response Team approach.

1. Happy Customers
2. A bored Project Manager
3. A tech released to work on IT Operations because no hardware is breaking and everything was executed to plan

I wish I would have come up with that. Simple, memorable, powerful.

With the increase in the number of applications in the portfolio comes complexity. In addition our infrastructure is becoming much more complicated including a more sophisticated network; changing virtualization technologies; and complex storage.

So, our IT Operations philosophy is to perform a Root Cause Analysis on every critical service interruption. Our Root Cause Analysis asks three things:

• How can we prevent this type of outage in the future?
• How can we detect this type of outage in the future?
• How can we respond to this type of outage more quickly?

The second two questions are important. Even if the cause of the service interruption is s simple fix, sooner or later stuff is going to hit the fan. We want our IT folks to see when it does and already be communicating to our customers how we are fixing the problem before they call us.

Furthermore, the consulting firms take very little accountability for the consultants they place. But, how can they when their experience is so varied and there is no standard for good service?

When I hire a consultant, part of what I am looking for is a well defined way of doing various types of work. I want the consulting group reviewing each engagement and revising their approach to work based on the lessons learned from each engagement. If I am going to hire a project manager, I want that person trained in the firm’s project management approach. If I hire someone to assist with a selection, I want that firm to have a clear written means to conduct IT selections. I don’t want someone that might have participated in one of these activities a while back and will try to mimic one the way a child mimics an adult.

Of course that means a large investment in people that develop these methodologies and take the time to train permanent staff. That seems to have gone the way of the dodo bird. Nobody has staff, they have home-based employee people working the phones looking for talent to place.

Update: In re-reading this post I recognize that it is too general. There are a lot of consulting groups that bring intellectual capital to the table. When I am introduced to a new consulting group the first thing I do is categorize them as a traditional firm with an investment in their staff, or a recruiter of free agents with no connection to the people they place.

Update 2: Too frequently someone claiming to represent a consulting firm, is really with a staff augmentation firm. There is a big difference between the two and I wish the staff augmentation firms understood this.

Firstly, he said “testing or piloting.” What is the number of hospitals that are actually buying and deploying iPads to use with their core clinical applications? I bet that number is less than 1%.

What exactly defines a “top hospital in the US?” Are those the ones that answered Apple’s calls? I have an Apple sales executive (Rachelle, who is a super nice woman) that periodically calls on me to keep track of what we are doing. When she last called I toled her we had a pilot taking place to test connecting employee owned devices (including iPads) to our Exchange Server so our employees can get email and appointments.

That’s it, just a pilot. No roll-out. No committment. Furthermore, it is just for Exchange connectivity. Still, I presume this means that our 15 hospitals are in that 80%.

But, the picture behind Cook is two men, with lab coats and stethescopes, staring into an iPad. This might give the world the impression that 80% of the hospitals have doctors and nurses accessing electronic patient records on an iPad.

Not yet.

My organization is not going to deploy the current generation of Windows client applications on iPads, just because they are cool. When core vendors produce native iPad apps (or properly formatted web apps) that will be the right time to look at radical device changes. And don’t talk to me about Citrix. Citrix on the iPad’s relatively tiny screen is a terrible user experience and not worth the cost to make a radical change to our device support model.

There was a play in the top of the 9th inning that drives me crazy. The Diamondbacks had runners at the corners with 2 outs.  The Brewers Betancourt scooped up a slow bouncer and raced to 2nd base, ariving a split second before a sliding Justin Upton.

Why does Upton slide into second base? I would argue that sliding slowed Upton down enough to allow him to be forced out. What if instead, he were to run through 2nd base to avoid the force? Sure he would be tagged out before he could reach 3rd base. But the runner at third would have already crossed the plate before he could be tagged. I am gad that didn’t happen because that run would have likely eliminated the Brewers.

If a runner is forced out for the final out another runner crossing the plate will not score, even if the runner crosses home before the force out. If the runner is tagged out after reaching the base, then it becomes a matter of what happened first – the final out or the runner touching home plate. Because the runner at third usually has a bigger lead, they typically can cross home plate at the same time the force out occurs. Even if Upton were immediately tagged after running through second, the Diamondabacks would have scored the winning run.

Maybe someone will post a comment telling me why I am wrong. Maybe there is a rule that requires the runner to slide. But I think Upton slid because, for over 100 years, every player in the same situation has slid.

Is there something in your IT operation that you do because it has always been done that way? Is there a simple but unconventional change that you can make to get a better results?

Maybe this post wasn’t off topic after all.

These people radically changed the lives of every American alive in their lifetime. It was awesome for me.

It is probably no mistake that the company cited in the article is Citrix Systems. I am sure that they have had a corporate IT purchasing policy for years that restricted purchased applications to those that work well in their Citrix environment. I think an environment where are applications are served via Citrix is a key requirement for a BYOD policy. All that is required is the IT to make sure that the Citrix client is running on the employee’s device. This leads me to…

Reason #1 that BYOD doesn’t work in a typical healthcare environment: Most applications don’t run well on a Citrix.

At Ministry Health Care and Affinity Health System we have literally hundreds of apps that we cannot deliver on Citrix. In fact so many, that we don’t try to deliver apps via thin client technologies unless there is a specific need to do so. Because most of our client applications run locally on the employee’s PC, we need to tightly control that environment to avoid conflicts and other things that keep people from doing their job.

It is probably reasonable to assume that the employees at Citrix Systems are more technologically savvy than the average employee base. Consequently the IT department at Citrix Systems doesn’t have to worry about the devices being in a usable state. That is not the case for our employee base, while we have many IT savvy employees many others, especially our caregivers, spend more time thinking patient care than computers. Many need a lot of help with basic PC support.

Reason #2 that BYOD doesn’t work in a typical healthcare environment: Many of our users require a lot of support from IT just to make sure their computers are in a working condition. IT cannot efficiently support hundreds of different device models.

I have seen it all, from browsers with a dozen installed toolbars to deleted system files. I would love to allow users to install their own software and customize their computers, but history has proven that there are far too many disruptions to the work environment when a liberal desktop management approach is used.

The story also quotes that Citrix Systems has reduced its device cost by 20%. But I am sure that doesn’t include the multi-year investment in Citrix software and servers required to deliver the applications to the desktops. That is hundreds of thousands of dollars and a significant new support requirement for organizations like ours.

In the future we might be able to offer such a policy to a certain group of users (managers and analysts). But there would be a lot of work in developing a plan to move that model and right now there this does not arise to the level of the most strategically important issue for Ministry to tackle. Needs like improved clinical information systems come first.