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.