Workarounds to computer access in healthcare organizations (2015) [pdf]

To skip all the sillyness - you basically had to password share, keep systems logged in etc etc to get anything done. Yes, security is important, but if it's 30 minutes to do anything, and then they did something like 30 day double password resets (on both layers of VPN) it's just chaos. Every password had to be written down, because when a patient showed up an clinician couldn't login it was a disaster. The millions they spent without every talking to anyone using this crap was mind blowing. We had in the end separate computers with locked down ancient IE and java to do some stuff on this system (auto or user updates to Java - which would pop up scary warnings given how old things were - would blow the fragile system up).

Then the one person who could create new accounts through a ridiculous process would go on some kind of 2 month union break at a time, and....

And now that the staff is used to lending out their cards an attacker pretending to be a new hire can bypass both access controls

That's very interesting, and explains many somewhat baffling experiences. So most of what I tell or give a doctor is effectively lost? That's the perspective from this patient, who finds it very frustrating to repeat myself, that the doctors are ill-informed and often perform that way.

But being open-minded: Is it that why I tell (or what most patients tell) the doctor isn't really useful to them? What is useful? Or is it just a consequence of time pressure?

If you get the chance, what would you say is the biggest problem/limitation/shortcoming/annoyance associated with these handoffs?

We used to have a solution to this: Clipboards. But I can't remember the last time I saw a doctor in my org carrying a clipboard.

You would be correct.

> Finally, as an overall generalization, doctors don't like being told what to do or how to do it, and that goes double for computers. They don't care about your needs to maintain a secure IT platform and will do anything in their power to circumvent anything that they don't personal feel is necessary. Better to engage them early in the process, figure out their patterns, and learn how to work with them because going up against them is likely to be a losing battle.

I'll give the opposite advice: engage with the buyer. At the end of the contract, he's the one paying and deciding whether or not the software is worth something. Sadly, the objectives of the buyer might not completely align with the provider, but that's an internal issue: as a consultant and an external contractor there's very little you can do. Also, never work for a healthcare organization as an FTE.

I don’t have any knowledge of the healthcare software market, but my guess is that being easier to use for the rank and file probably isn’t as big a differentiator to the administrators purchasing the software as costs are. This is pretty common when you have software that is purchased by administrators for others, especially highly regulated software.

These are all obviously very hard to do, and you have to really want them yourself or they won't happen. I'm surprised how controversial speedy UIs are, for example. JIRA is the most popular issue tracking system, and it's just SLOW compared to newer things like Linear. I see JIRA and would immediately disqualify it for use because the UI is so slow; it takes a minute to enter a bug, or a three-screen process to move a bug from one team to another, etc. But it has every feature people are looking for on its little checklist, so it gets chosen over systems that are speedy and productive.

If you're doing electronic medical records, you need to implement all those long-tail features, and you need to make it fast. Paper is fast. You can't make logins take 1 minute, they need to happen in milliseconds. You can't discard peoples progress when they move to a different workstation. Things like that; the PM just has to say "no, this isn't acceptable", and find a team that can implement it well.

I guess this doesn't happen, and look at the mess that it created.

Probably very few. But it really depends on the company.

The healthcare company I work for requires everyone from the CEO down to low-grade button pushers like myself to work with actual patients a few days a year.

It's not a lot, in terms of hours, but the exposure changes the way you think and do your work for the rest of the year. I know that each year after I've done my three days, I come back to the computer with a whole list of web site improvements in my head.

More on topic, even though we're in an "information age," it's important for healthcare organizations to work harder and harder to accommodate the fewer and fewer people without access to technology, simply because those are almost always the people who are poorer and in bad health, who need us the most.

Right now, there are 50,000,000 Americans without internet access of any sort. Not at home, not at work, not on a phone.

Often a better option is to hire several practicing clinicians across different specialties as part time consultants on an advisory council. That way you can gather ideas and get rapid feedback on product concepts without involving them directly in the development process.

It's terrible but this seems to have become the way to go here...at least until it backfires spectacularly.

The actual idea was to make this patient -> doctor way unnecessary by giving the doctor an account and automatically uploading his patients data to the doctors space on the platform. Unfortunately you can already see doctors giving up because they have too many accounts for too many platforms.

It's a hard problem because in the normal flow of the world, the provider will login to the machine, select the correct patient, be given an option for the drugs that are prescribed to that patient, choose the correct one, and then administer the drug when the correct drawer opens up. The software checks for med allergies, appropriate frequency between doses, etc. etc.

But what happens when the employee's login doesn't work and they need a drug emergently? What happens when the IT mandate to change passwords shows up during a crash? What happens when the patient is crashing and there are no orders for the correct medication? What happens when the mechanical drawers stick and won't release the drug?

It's largely solved with old school "crash carts" that have a standard inventory with all of the emergency drugs that could be required, which are then reconciled to derive what was taken out/used. But then you need to track whether the narcotics that were taken were actually given and not just diverted to someone's pocket.. and not every drug is stable for long periods in these carts...

Separately is just the overall shitshow that is medical software -- my spouse worked for a hospital for three months before she was finally granted access to all of the systems she needed to perform her job safely. Basically just borrowed other peoples' access where she could and took extensive handwritten notes that will likely never be entered into the EMR.

The article is missing a few things about the environment and its pressures. For example, you have physical access restrictions on many aspects of a hospital. Pharmacy, controlled drug dispensaries, materiel storage, biowaste, nurse's stations, isolation, certain patient rooms, OR, etc. These all have their own rules and many of them have access badges to enter, or combination locks, or software processes to gain access.

There is HIPAA (or other patient data control restrictions in other jurisdictions). HIPAA has internal and external controls. Some of it is actually required by law, some by regulation, some as part of accreditation, some is recommended by consultants, and a lot is dreamed up by people apparently out of nowhere. HIPAA internal controls require shielding of patient data from spying eyes. HIPAA external controls require restricting egress of data except as authorized by the patient or permitted by law and regulation. With paper records, you use file folders and clipboards that can cover the data and you try to not leave it unattended. It can be shared internally in the hospital with the people who need it and you can generally trust the providers to do the right thing. With electronic data it can be easier to lock it down but harder to provide access. Hospital IT is incentivized to not have a big data exfiltration embarrassment so they will probably set policy on a strict level and require complaints before they make it easier to access.

In most hospitals, the workforce is quite fluid. There are many temporary employees at all levels, and providers join and leave various provider groups that are connect to, but not part of, the hospital. There are many contractors walking around. Some people low on the payscale have access to almost the whole hospital (such as the constantly working painters required by accreditation). Some people high up are not always given access permission to areas they are not typically working but may need to access one day. The same is true electronically, the doctor may not be able to access some information that the IT temp can access.

In addition, the integration of systems is a constant headache. Every little system is built with its own patient management system and usually has its own usernames and passwords. Many hospitals are eventually able to harmonize these systems but not all of them can be done cost-effectively.

Finally, as the article mentions, there is the fact that a clipboard can be moved with the patient but an EMR may not have a terminal convenient to where data needs to be entered.

All of these things (and more, I'm sure) provide a lot of friction to using the standard means of access control, and workarounds abound.

It is also somewhat less likely in a well-managed EMR that you will have notes ending up in the wrong record.

Invoicing is also much simpler with an EMR. Good EMRs are able to keep track of charges as the medical record is updated with treatments and procedures.

Finally, EMRs enable very useful patient portals.

There are some aspects of EMRs that are particularly frustrating. They can be good at hiding useful information while displaying lots of unnecessary information. They seem to be developed by non-providers who are not really able to grok the way things work on the hospital floor. We spend a lot of money on upgrading computers and other devices, and yet they are not easily placed into a slot on the bed so that they can flow with the patient. Their validation rules often do not make sense, as mentioned in the article.

On net, I think that the EMRs are enabling better health care, but they have a long way to come.