Incompetence--Just Deal With It

I'm working on a big project right now, implementing Knowledge-Based Charting (KBC) within our inpatient EMR. For those not familiar, it's basically pre-fab clinical documentation for everyone but Physicians and Pharmacists. The idea is that if you don't want to spend 5 years building customized clinical documentation for stuff like Vital Signs, I&O, and Assessments yourself, you can just buy this product from the vendor (if you use EPIC and not Sunrise Clinical Manager like UPHS, you may be familiar with the product).

In concept, it's a great idea. Take the content out of the box, teach the clinicians how to use it, add any custom content necessitated by regulatory bodies or site-specific practice, and you're good to go. Implementations usually take about 2 years, with a team of approximately 6 analysts and a Project Manager to do the work.

Penn doesn't have that kind of time--we need documentation, and we need it yesterday to meet Meaningful Use. So they re-tasked me from general release cycle work (more on that in later posts) to KBC full-time, and hired a Senior Clinical Analyst with 10 years of experience in health IT to help me out, along with a Project Manager (PM). We needed to be fully implemented within a year at all facilities, and required extensive customization to meet content gaps for Inpatient Rehabilitation, Skilled Nursing, Behavioral Health, and Long-Term Acute Care within the system, on top of the usual work. To close the gap in resources, we decided to take on a raft of CPM consultants to do the design of the custom build and an Implementation Consultant (IC) from our vendor to get the whole thing going on a smooth timeline.

I've learned a lot from this project, and become a local expert in Sunrise documentation. That's great--you can't ask more from a job than to do important work and get paid for it. Unfortunately, the road there has been paved with more blood, sweat, and tears than one could possibly anticipate. Highlights:

1) CPM screwed the design specifications to hell and back, forcing us to completely rebuild the content...twice, and send their specifications back three times, only to discover that we were better off doing it ourselves anyway.

2) People working on the project have fled like rats from a sinking ship. We've lost our original Allscripts IC, our CPM Clinical Practice Director, and the partner we hired about 7 months ago to help me on the project. Hell, I tried to leave to, but she beat me to it.

3) My Team Lead and I discovered that we're the resident experts on key functionality within the product, and have ended up teaching our consultants how to do their own jobs.

The scale of the incompetence demonstrated by people we hired specifically to help us and who represented themselves as experts on the product has been staggering. I've been working 60+ hour weeks for the last month, and my partner in the project is leaving this Friday for a new job, and no relief is in sight. I'm stressed, stretched thin, and on a hair trigger.

I knew there were going to be rough times on this thing--it's hard to imagine an implementation that forces us to re-train 12,000 people going off without a hitch. I'd like to say I've handled it well, but I haven't. I snipe at our consultants constantly, tried to quit and saddle my partner with the rest of the config work, and even sparred with my management over the project's direction. I don't like being this person, and I don't think it's a good face to show to my superiors.

The fundamental problem I'm faced with is one of expectations--mine were too high. I thought most problems would be generated internally, but in fact the opposite has been the case. Our external partners have repeatedly delayed and damaged our efforts, and yet remain unaccountable as a consequence of their role. I take out my frustrations on them, but it just makes me look like an asshole, and I'm trying to stop. At the end of the day, it's my project and my health system, and I have to bring it home. If these people offer some amount of help, that's cool. If not, well, they're as temporary as the project, and I have to learn to live in this workplace post go-live, and they just move on to the next site.

If there's a point to this parallel, it's that incompetence in the workplace is something you have to learn to live with gracefully. Yes, it's ridiculous that they bill 3 times my salary to do a terrible job, deflect responsibility whenever possible and fail to deliver on any deadline set. When two people have an argument though, from far away it's impossible to tell who's right, and the aggressor always comes out as the villain. So if you're on a project and getting screwed, put the War Face away and just deal--it's only a job anyway.

Testing

UPHS is currently in midst of upgrading our EMR to a newer version, and as the new guy in town I've been principally working on the testing aspect of the upgrade. Upgrades are an interesting time, as they are essentially an entire implementation project rolled out on a shorter time table and with less impact to the user. For someone just getting to know the system, it's a perfect opportunity to see all of the pieces in action, and more so if one is testing those pieces. Upgrades also promise increased functionality, expanded features, and usually resolution of open issues between the vendor and client.

On the down side, it's necessary to freeze any work on enhancements or maintenance issues unless they are necessary to ensure patient safety. This puts the users in a tough spot, because for the period during which the freeze is maintained (in our case, it takes us through the entire summer) they get asked repeatedly to test base functionality while just having to make the best of an electronic medical record that gets more divorced from their practice and environment with each passing day. It also ends up being a colossal waste of IT resources, as the staff swing from frenzied, over-time work responsibilities to periods of absolute calm. On any given week, you could be at work until 9 PM every night...or you could spend all of your day chatting with co-workers and reading tech manuals for lack of anything better to occupy you.

The feast-or-famine is largely driven by the testing schedule, as there is a great deal of work a couple days before and after a round of testing, but then the rest of the time in between ends up as slack. You can't predict how much time is necessary to fix problems that might crop up following a given set of tests, and the penalty for not allowing enough time is that the schedule gets delayed or moved. The testing only works if you can get the end user to actually work through the scripts though, and rescheduling them at the last minute is a great way to destroy both goodwill and generate even larger slack as the project manager(s) fight to get a 4-8 hour block of time where they can all come in again.

Theoretically you should have some float staff at all times to sit in, but if there's one thing I know about health care, it's that you'll never find a more devout hive of luddites when it comes to information technology. So slack and freezing are inevitable, but you need to limit both. You can mitigate the slack, but there's really not much to do about the freeze since every new change you make adds to testing volume, but during the middle of the process so you have to start at the beginning each time. There's also the go-live date to consider, when suddenly all of these changes start to pile up and require last-minute configuration to make the cut-offs for rolling in whole sale.

What we've done at Penn is just maintain as tight a schedule as possible, and hope that the shorter the duration of the freeze, the easier it will be coming out the other side. Given the frequency with which we upgrade and implement systems, I think we ask a lot of our users, and I can only hope that they stay as engaged and helpful as they have been thus far.