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.

Watching the Watchmen

Securing information is a big deal right now, but it's nothing new to health care. Protected Health Information (PHI) is the buzzword we always hear, but it turns out that the there are so many ways that information can leak, it's just one of those things where you try your best.

It seems like the latest rash of concerns are stemming from the administrative side rather than the care provider side. At first, everyone was worried to death that health care professionals or random passers-by were diving into their electronic records and gathering deeply personal information like their STI test results or what surgery they were getting last week. When I was coming up in school, that was all we talked about, and the fallout was rashes of students and medical staff that were fired or penalized for information indiscretions.

All this time, no attention was paid to the larger risk, which was IT staff themselves. While less personal, breaches by IT staff are much larger in scale, and certainly contain more potential for harm in the form of mass identity theft, or breaches that are almost impossible to track. It's the latter issue that I'd like to talk about.

Most systems have a method of logging when any particular user views a patient chart. So if I dive into your medical record looking to see if you're pregnant, the system logs not only who I am and when I accessed the chart, but in many cases what sections of it I looked at. For care providers, it's very obvious whose charts they should be viewing because they are working with patients in a certain location or possessing a certain diagnosis/problem. If they start looking at charts for a patient in another hospital unit or specialty, hijinks may ensue.

With IT staff though, we have to go into patient charts all the time, most of which have no apparent relationship to us or to each other. At UPHS, the members of the team all do tech support for several hours a day on top of our projects, and will also occasionally look at an individual chart to try and analyze workflow. This happens many times a day, and only about half the time is there any sort of recorded reason for the access. If asked why we looked at a particular patient's chart a week or more in the past, I know I would probably give something between a vacant stare or quizzical look as a response. Consequently, as long as there is no apparent relationship between the IT staffer and the chart accessed, the benefit of the doubt is usually given.

It's further complicated by the existence of temporary copies of the production database (the version of the EMR where everything used clinically lives). In order to prevent catastrophic failure in the event of a disaster, at Penn we create a backup of the entire system every 24 hours. It serves multiple purposes--in addition to acting as a backup, we often test changes we're planning to make to the production EMR in that environment. If something goes wrong or doesn't work, we can roll it back with no disruption to patient care... or just leave it there. We can do that because the entire copy is wiped out and replaced by the current production version every night. The dark side is that we can also potentially view patient data in that environment, and any traces that we were there are cleared out in 24 hours, most of the time in even less time. So if a malicious actor were to simply wait a day for some information to come into this copy environment, they could gather anything they wanted and then just wait for any traces that they were there to disappear. All that would be logged is that they accessed the environment, and as long as that occurred during normal business hours, there's nothing to prove because you can't tie it to a medical record.

There are other examples, plenty enough for many more posts--but it needs to be said that information security is not quite what it should be. And I say that working at an institution where I believe security is taken seriously. Balancing the need to safeguard PHI isn't going away though, and the work is never done.

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.