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.

Education and Careers

I just saw this article posted up on Slashdot, and it cuts to an issue I've heard come up repeatedly ever since I went to school.

Of my cohort coming out of High School, I was one of only a few to go to college. Rural Oregon is a pretty blue-collar place, and many of my friends were either joining the military, going to technical school, or launching themselves directly into the workplace. One even had started his own business and was looking to do it full time come graduation. At the time I thought they were just taking the easy way out; after all, it took good grades, test scores, and a hell of a willingness to delay gratification to go to college. In fact, it seemed like the key to success was education--the more the better. People with money are Doctors and Lawyers, people who work a McDonalds are those with GEDs.

Almost a decade later, the world looks a little different. Friedman pegged it nicely when he said what you really need for success is to be one of four things: Adaptable, Anchored, Specialized or Special. I hit specialized pretty nicely; there are only about 2 million RNs in the entire country, and only a couple thousand of those work in Informations Systems.

I actually took the slow path though, since I could probably have been exactly where I am right now about three years earlier if I'd gone to community college, picked up my RN there, and worked for two years. Two years is really the golden number when it comes to Nursing experience, because from there people assume you know the ropes. At the time I was going to school, IT at hospitals had just started picking up Nurse Informaticists, and the iron was blazing hot. You didn't even need computer skills, they hired people with no training and threw them into training programs, or just hoped that they'd pick up the skills on the job. No one anywhere was making less that 60k a year doing that work, and most were closer to 80.

My family would have made me a pariah for doing so, since the expectation was that I wasn't achieving my potential. Potential, however, seems to be related more to networking, desired field, and timing. I'm not any good at networking (social media always seems like another chore), but my desired field was a perfect fit with the way the economy is going short-term. It's striking that my decision to go on for graduate education after undergrad pretty much blew my timing to hell though, landing me fresh out of school in the worst economy since 1932.

I'm actually working in Informatics now, but I can't help but think that my friends who went to community college and picked up skills in basic engineering and CAD who now have houses (while my wife I are trying to decide whether we'll ever actually be home owners) didn't have a better plan. I liked college, and I love my graduate program, but I think I would have liked spending my weekends having fun somewhere warm rather than freezing to death in Cleveland banging out 20-page essays in APA.

Thoughts on Care

Well, my wife is pretty much recovered from her hospital stay, and we finished our last follow-up visit which went even better than expected. As I've said before, I'm not usually on the patient side of the health care environment. The experience was frightening, and I can readily admit to being an annoyance to all of the very patient people who provided for my wife through our four-day tour of Hunterdon Medical Center, despite trying to be as pleasant as possible.

My only real previous experience with the patient end of care was when I was on vacation in Gatlinberg, Tennessee and wound up in the ER at Fort Sanders Sevier Medical Center, which has the distinction of being one of the busiest ER's in the whole state. While they had a very nice EMR and seemed quite technologically enabled, I spent about 16 of the 20 total hours in that place waiting for a chance to talk to a medical professional of any variety. The staff was overworked, their triage was unable to keep up with demand and space was so limited patients were literally lined up along the halls in gurneys, with the scene reminiscent of the Crimean War imagery so often invoked during historical discussions of Nursing. Care focused on technical achievement of patient outcomes at the expense of expressive activities.

Fast-forward to Hunterdon, and this sleepy community medical center couldn't be more different. The EMR was underutilized and paper charting was the norm, and there were moments where I questioned the technical competence of the care provided. However, their expressive functions were so good, the environment so precisely engineered to promote calm and healing that the technical aspects of care seemed like a much more workable deficiency. Coming from a technologically enabled, large-scale care environment in Cleveland where two major health systems are currently engaged in fairly intense competition for patients and acquisition of hospitals, I've felt for some time that there was little difference in the quality of care delivered from one hospital to another. Indeed, barring large differences in the typical quality indicies used to compare hospitals nationally, how should a patient choose between patronizing one institution over another?

After my (albeit limited) experience on the patient side, combined with my knowledge of care delivery, I would say the greatest single factor should be the patient experience. I'll even get heretical here, and posit that the patient experience within a competitive care environment is more important than use of technology such as EMRs and novel devices. Why do I say this? Well, because if a patient's health care provider only spends about 10 minutes with them each hospital day, or if that patient waits for several hours in a glorified holding pen, they really stop caring about the information technology and high-tech devices of that institution. Those things don't let them communicate that they need more pain medication, or that the vesicant solution currently running through their IV burns so badly they burst into tears. That pump may be accurately delivering its dose, but it still can't adjust the fluid concentration to relieve suffering.

Disney is now getting into healthcare, and have several case studies on the effectiveness of improving the patient's perception of care and expressive functions over technical achievement. I watched one of their webinars, and while I wouldn't rush to call them in at $300 an hour (or whatever they charge), it did make me reconsider my role. IT is not care; it is facilitative technology. No EMR implementation is going to be successful that does--as its end result--improve the perception of care delivery by the patient. You may wow them on Day 1 with Tablets, COWs, and CPOE, but by Day 3 the patient doesn't give damn. They just want their fears to be allayed and their suffering to be relieved, and everything else just falls to the wayside.

Here I Sit

Next week--May 11th--will mark the second graduation I have failed to attend. Both were voluntary decisions; the first because my family lives in Oregon and wasn't about to fly out to Cleveland just to watch me put on a cap and gown, while the second was the result of my wife Amanda and I deciding we would rather spend time with her family in New Jersey than spend another week in our crappy one bedroom apartment.

We left on May 7th, and on May 9th Amanda was admitted to the hospital. The last few days she's been battling with a small papule that grew into full-blown preseptal cellulits, and I've been keeping vigil at her bedside to make sure that she gets the best possible care. This has turned out to be a pretty easy task, because the quality of care here is excellent, and the facility is both well-designed and contemporary.

I almost never get sick, and have never been hospitalized (exempting a couple brief ER visits as a kid), so my knowledge of the health care delivery system is a little one-sided. I think that's what made it so easy to get into the field in the first place. It seemed in school like my experience was not out of the ordinary, with most of the nursing students rarely getting ill and having experienced health care delivery vicariously, rather than principally. Hell, I didn't even have vicarious experiences to draw on--my family is also of remarkably good health.

There's no proxy for a sudden shift in perspective in regards to your work environment. I think we have all had the experience of attempting to use technology or a service, and being forced to wonder "did the person who designed this thing ever have to use it?" According to my Computer Science friends, the answer is probably "no".

So as a nurse, as a husband, and as an informaticist I'm trying to mine this experience for all its worth. I blogged before "blog" was coined by Peter Merholz, instead just writing what I thought of as short essays and posting them to a Tripod account in order to teach myself HTML. I haven't done it in a while though, because I've been busy. As most nurses can appreciate, nursing school isn't a picnic at any level, and this last year was a marathon of academic coursework and a full-time internship that left me barely enough time to get married to Amanda and still get out with my sanity.

With no school, employment, or personal obligations right now, my wife's care is all I'm focused on. That said, there are large breaks in the day (like now) where she's asleep and there's no work to do, so I've decided to blog again, and what better to blog about than the thing I know best. So the next few posts are going to dedicated to my experience on the client-side of care, and how they reflect pertinent issues within the healthcare delivery system and health information technology.