I used to volunteer at a hospital reception desk, where walk-in patients were received.
Staff had ID cards, which would both open access-controlled doors, would log into IT systems via smart card reader. Removing your card would immediately log you out.
Clearly, some designer thought they could prevent users from accidentally leaving their computer logged in, as you couldn't move around the building without your ID card, forcing you to unplug it and hence log yourself out - right?
But the receptionists' computers had the most basic specs, and were loaded with corporate bloatware and sluggish roaming profiles. And of course the software they had to use added another layer of underperforming enterprise bloatware. It would take a good 5 minutes from inserting your smartcard to actually being able to work.
Quelle surprise, the staff never unplugged their smartcards, and instead borrowed someone else's card when they needed to move around the building.
I was also in a govt / enterprise EHR type project. Similar story, but you had a double layer of VPN that only worked with outdate explorer / java etc (AT TIME OF DEPLOYMENT - the software was "new" to the govt agency and the poor health staff).
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....
While working in a hospital as a radiographer I met an IT contractor socially who was excited to be implementing a system which sounded like the one you describe ‘to help me work more efficiently’.
It takes a special kind of person to confidently explain how a job they have never seen done is being done wrong.
The people who came up with that stuff probably never thought to weigh how much more it obstructs attackers than real workers... or even more scarily, thought treating them the same would be more secure somehow.
As the saying goes, a perfectly secure computer is one that no one can use
Ironically, this system resulted in lots of insecurity.
Password resets were so common the govt agency OUTSOURCED them - and you just had to provide your username to get it reset. Literally, you called and said I need a password reset for account X, and they gave you a temp password over the phone.
I never complained about how easy this was because this was a CRITICAL feature. Sometimes we didn't even know why a password wasn't working - so after you got done with whatever client came in you called the number and got a new one.
So it's really security theatre + the security provided by the massive annoyance of setting up old internet explorer to login and all the other silliness (which really was security, we were not alone in struggles, they kept on having to do paper backup systems when stuff went down).
I often thought that a hacker could probably make all our lives easier by figuring out a way around the double VPN.
This was a long time ago though (10+ years) and I have to believe better now.
The thing about VDI is that you can't underprovision the client, but you can underprovision the server to a resonable extent. I've seen deployments who decide that it's a great idea to give Windows 10 VMs 2GB of RAM and 1vCPU, which turns the instance into a swapping mess. However if you give the users suitably sized VMs (e.g. 8G/4vCPU) then they will have the burst capacity for faster application loads and such while the server can remain overcommitted (it's rare that all users will need to use up all their vCPUs and memory at a given time).
However for doctors there may be another option aside from VDI, which is RDS or similar where a single Windows Server instance handles multiple remote desktops. Sort of like multiple users using SSH to connect into a shared Linux server. Unlike devs they can rely on a fixed image and don't need to make global changes, making a shared instance viable. This would allow the users to make better use of the compute resources on the server.
> So long as Citrix isn't under-provisioned, which is all too common.
A common selling point of Citrix and similar solutions to the CEO is that by centralizing and sharing resources (CPU, RAM, etc.), we can save money on redundant, unused capacity - on most user workstations, the process which clocks the most CPU time is 'Idle', after all!
Nah. VDI is in many environments the biggest compute system in the datacenter. Peoples work patterns are very consistent so there typically isn’t much slack.
The top issues with VDI are memory availability and profile management. As CPU improvements stopped, apps are memory hogs. With a modern Microsoft stack, even basic users run Outlook, Teams and Chrome. Outlook is usually caching too much, so your virtual desktop with OST stored on a shitty NAS somewhere is essentially a really really awful single user Exchange server.
What is that in response to? You're saying VDI isn't slow and underresourced for many people? Perhaps that's not your experience, but does that mean it's not the experience of others? Are you saying that VDIs aren't sold that way to CEOs? I've seen it and the underresourced results multiple times.
Nah, they make you log out of your vm as well as the thin client, or cause your vm to auto log out when you're not connected for a couple of minutes. It still takes 10 - 15m to get logged back in.
As a bonus, you get to interact with a slow, remote desktop all day.
Or the real kicker - the hardware gets over provisioned because the incentive is to cut costs. You try to log in, get on a bum vm, then have to log out and try again and hope to get a good vm.
Physician scientist here: this study is a bit dated. Many of these issues have been "solved" (depending on your threat model) within the last ~7 years. Most healthcare systems have adopted Imprivata [1] for SSO, where physicians tap a badge and are connected to (usually) a VDI session of Epic.
What this study misses is the real driver of EMRs: billing. EMRs exist to facilitate billing documentation to charge for patient care. Yes, they have other benefits (like viewing lab results), but if you ever see true critical care (at the bedside, in an ER, or in an ICU) little depends on the EMR (or even labs for that matter).
A few comments here talk about patient notes: in most clinical environments, inpatient notes are useless, and a tedium required to bill. They're filled with copy-pasted jargon to meet insurance company requirements. True patient care happens in less than ~1 paragraph of text called a handoff. [2]
> A few comments here talk about patient notes: in most clinical environments, inpatient notes are useless, and a tedium required to bill. They're filled with copy-pasted jargon to meet insurance company requirements. True patient care happens in less than ~1 paragraph of text called a handoff.
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?
Patients also don't usually know what is useful or not for a Doctor to diagnose them (or any medical provider usually). That has to be picked out as part of the Doctor or other medical provider questioning them and getting their vitals.
Some of it is implicit, like 'is the person able to form cogent sentences', or 'does the patient seem to be struggling to stand'. Others are more explicit, like heart rate, BP, 'what medicines are you taking', etc.
Often the ones who need the most help are the worst at getting anything useful out.
Sure, but I've told apparently critical info to doctor A, and then doctor B didn't know it (when I've told doctor B, it has changed their conclusions).
The patient's time has zero value to most physicians. It's often faster, and more clinically useful, for them to just ask you for your complaint and medical history. This allows them to guide the conversation and quickly focus in on the exact information they need. Searching through old chart notes is often a waste of time since the systems are slow and the data is frequently incomplete or irrelevant.
> Searching through old chart notes is often a waste of time since the systems are slow and the data is frequently incomplete or irrelevant.
I believe this can change if we change the amount of patients a physician must assess and treat in a given time period. Because that would be super costly (way more physicians required on staff) Nurse Practitioners and PAs would be a more cost effective way to delve into important and relevant information that takes time to uncover.
NPs and PA time isn't exactly cheap either, and they aren't sitting around waiting for stuff to do. They can be effective at treating routine cases under supervision, however it just wouldn't make sense for physicians to delegate patients histories and chart review to them. They won't necessarily know which questions to ask, and too much relevant information can be lost.
Yes that's correct. Every year, students graduate from medical schools but are unable to enter clinical practice due to a shortage of residency slots. We need more government funding to remove that bottleneck.
The UK has no link between doctors and hospitals, for a shining example. This reason alone is why so many expats I know return and receive better care from any old HMO just because the billing system glues together the case histories essential for infrequent attendants to primary care due to travel etc.
I've shadowed clinicians in a hospital and ER setting for similar purposes (focused on overall user patterns) and I feel like this paper is a little light on content or suggestions to remediate.
First off, the authentication issue is real. It's also something that has largely been solved by badge readers and integrating them w/ SSO solutions. Everyone has a badge on anyway, and if you can make the login process fast, they won't have so many problems with using them on their rounds as they already use them for all sorts of access situations.
Clinicians are quite possibly the most mobile users I've ever dealt with. You either have them lug a client around with them (tablet etc, usually terrible for EMR use) or you have fixed stations in each room and in common areas etc. We discovered that VDI was a fantastic solution to the mobility problem: users have an open session on a system in a datacenter somewhere, and they can connect to it in a couple seconds by waving their badge in front of any terminal. By reducing the time-to-access and leveraging existing access control tokens you can usually get the user community on board with not trying to circumvent things.
Another thing that this paper notes and which I witnessed in person: clinicians making rounds tend to take notes in their head and then commit whatever they think needs to be written down in a batch at some later time. I watched a doctor engage with a dozen patients and then head to a PC to take notes. Doctors pride themselves on being smart people, but I harbor some serious doubts about the accuracy of this approach and I can't help but shake the notion that the first patient they saw might not have all of the pertinent information recorded an hour or two after the exam.
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 watched a doctor engage with a dozen patients and then head to a PC to take notes. Doctors pride themselves on being smart people, but I harbor some serious doubts about the accuracy of this approach and I can't help but shake the notion that the first patient they saw might not have all of the pertinent information recorded an hour or two after the exam.
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.
The solution my mother trained to perform: shorthand-using assistants, with further training in medical jargon and drug names and such. They'd follow the doctors around and take notes, so the doctor could focus on the parts of their job that couldn't be done by someone with a year or two of junior college training.
I don't think it's common now, but it used to be a really common type of job.
Basically all those secretarial-type jobs—which used to be quite a bit of the workforce—went away, replaced by making experts use computers themselves, to enter data into usually-shitty-and-time-wasting systems. It's my understanding that a lot of the folks who are old enough to have done both despise the new system.
Many of the doctors I have interacted with at Kaiser refuse to use the computer and ask someone else to come enter the notes and data while they examine me or my wife.
Many of the doctors I have interacted with at Kaiser refuse to use the computer and ask someone else to come enter the notes and data while they examine me or my wife.
My mom had a job like this at a big bank.
The first thing she would do each morning is print out the e-mails for one of the V.P.'s.
The last thing she would do in the afternoon is take the dictation of his replies, and then send them as e-mails.
It's one of the reasons I roll my eyes when I see people on TV and the internet pretending to be "rich" with their multi-thousand dollar cell phones and gadgets.
Really rich people, and I mean really rich people, barely use electronics. They have people to do those things for them.
The information would have to be transcribed to the EMR, but otherwise many practitioners use written notes to fill the gap until they can document in EMR. I've also worked in facilities where certain medical paperwork was only kept in paper form and never uploaded to EMR, which I thought was insane when it comes to the concerns you've mentioned.
It's my strong suspicion that the majority of computerized replacements for human and pen-n-paper predecessors are either a wash in terms of productivity, or actually make things worse, and it only looks like the computer revolution was a huge boon for productivity because it improved a few areas a ton.
Computers are great at replacing those filling cabinets, and when you need to track a single piece of information over a lot of people or a lot of time. Other uses in an office aren't as transformative.
EMT here. We still use clipboards in the field on 911 calls. I can fill out a paper patient report in real time while I talk to the patient. Transcribing it into the EMR on the computer later takes about 45 minutes.
Some of our peer services use tablets in the field. I hope we never switch over. Besides the nightmare of the horrible UI (because that's always the case with enterprise software), if the batteries die or you try to use them outdoors in bright sun, you're hosed.
> I harbor some serious doubts about the accuracy of this approach and I can't help but shake the notion that the first patient they saw might not have all of the pertinent information recorded an hour or two after the exam.
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.
The best software is developed by people who have deep knowledge about the use case and/or the ultimate customer. What proportion of PMs at health software companies have worked in a hospital? I'd wager it's vanishingly small.
My take from this paper is that a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from other vendors.
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.
This is a great point - too many companies forget to optimize for speed of UX. My theory is because speed of UX isn't a strong selling point to decision makers. JIRA sells well because it's a safe choice (recent fuckups not-withstanding) and is very full featured. Speed of UX matters for the end user, unfortunately too often the end user has no say in the software they're using.
> a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from other vendors.
The problem here is we're talking government software, or IT-as-a-cost-center software. So the buyer is looking at the cheapest bidder. They aren't getting a team like those who solved the UX trifecta in the past (looking at the iPhone team at Apple here).
> 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.
Paper isn't fast, it's cached. Parsing, archiving and indexing of paper is extremely slow (when actually done). The slowness of input in a computer system might annoy the user but the system overall is way more efficient. Now auth taking more than a second or two is just lazy programming (bet it's not exactly Google caliber engineers working on the project).
> the PM just has to say "no, this isn't acceptable", and find a team that can implement it well.
What proportion of PMs at health software companies have worked in a hospital?
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.
> 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.
This is interesting. I assume you are in some IT or software role? If so, what is it that they actually trust you to do around patients? How do the "real" healthcare workers treat you?
what is it that they actually trust you to do around patients?
It varies from year to year, but is always interacting directly with them. I've been hugged, cried on, held people's babies while they (the parents) vomited in the hallways, had people rant at me in languages I don't understand. All kinds of human activity.
How do the "real" healthcare workers treat you?
They pretty much ignore me. I expect on some level, they're happy to have someone picking up the details so they can do other things, but for the most part they seem far too busy to even notice that I'm there.
I agree. Many general practitioners in Australia use the same practice management software which was initially developed by an unsatisfied general practitioner who taught himself programming. He also kept practicing medicine which is really impressive.
I don't know the percentage, but healthcare software vendors absolutely do hire experienced clinicians as Product Managers when they can. But it's hard. There are few such employees available, they're expensive, and most don't understand the product development process. Furthermore their experience sometimes isn't even very relevant: someone who spent 10 years as an obstetrics nurse won't necessarily understand oncology workflows.
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.
I think you can hire people who know the market in their bones from hard-fought experience, but you could also contract out some user experience researchers to shadow these people and tell you everything you need to fix. I have to imagine a healthcare worker turned PM has to be rare and expensive that they cost more than contracting out research. The reason both don’t happen is probably that they are expensive to do (and expensive to execute on the information you find).
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.
This removes healthcare workers from the workforce though, and we need healthcare workers more than PMs with direct experience. They would need to be good PMs on top of being good healthcare workers and I don't think you're going to find that as often as you think.
Another common example: patients who want to share their exam results with their doctor. The proper way would be to use the document sharing feature inside the web portal, but often the simplest solution is for the patient to send their username and password to the doctor.
It has became a quite common way around platforms for sharing results etc. in Germany to give out a QR code which is actually an specific URL to the patient where the password is the birth date.
This way the patient just needs to share the URL/QR code because the doctor does already have the birth date.
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.
Healthcare organizations don't want to accept file uploads from patients due to the malware risk. If there's a zero-day exploit in your PDF viewer or something then a single shared file could wreck their entire enterprise network.
I was talking about going in the web app where you get the results and granting the doctor permission to view the file. The problem is that the doctor needs to have an account on the system, and also that the UI for sharing is hard to use ...
> Koppel et al [16] document physicians ordering medications for the wrong patient because a computer was left on and the doctors didn’t realize it was open for a different patient
When you're in an environment with high stress (many decisions with huge consequences being made in a minutes/seconds timeframe in different simultaneous contexts), spending time with authentication has consequences. Not spending, too.
In my day to day life using computers I get frustrated to the point of anger by the scarcity of systems designed and implemented holistically by talented people - I can't even imagine what it must be like using these systems while trying to do a physician's job.
We all use keycards to access buildings and secure rooms. Keycards should be (and have been) used to secure computer systems in lieu of passwords. Now with U2F and biometrics that's the best practice.
If passwords have to be used, they should not be chosen by a user, but generated by the system and given to the user once. This is how 'app passwords' work with modern secure web services that otherwise require multi-factor authorization. For memory's sake this can be a set of words.
The absence of a secured NFC or bluetooth connection can be used to automatically de-authenticate and lock sessions. I created a perl script to lock my screen-saver this way 15 years ago!
It should be dead simple to modify systems access. A set of keycards should grant admin access to different parts of the system, and those given out to different levels of staff, so each level of staff can admin the group they work with, and higher levels can provide additional override. This provides redundancy and scales workload better.
For problems with the EHR system, this stems from poor design. Monolithic systems cannot be easily worked around, but loosely-coupled systems can be. A set of filing cabinets are loosely-coupled from what they can hold, can be keyed the same or differently, can be repurposed. Information system design needs to work more like independent furniture in an office, rather than a single set of furniture that only works in one way. Systems should be decoupled from each other so that a user can manually shuffle data around between them. Data should be decoupled from systems and made portable. Data fields should allow comments the way a piece of paper allows you to write in the margins.
It's not clear in the paper, but it's a common issue in healthcare settings. Most meds are dispensed via med cabinets (Pyxis is the primary brand: https://www.bd.com/assets/images/our-products/medication-sup...) that have a variety of controls in place to prevent diversion and to track medications delivered.
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 people buying the software and adding the policies are NOT the same people who use the software or enforce the policies.
I saw this at HP. As a new hire, I had like 20 different meetings talking about the various policies of the company you had to follow. After I started working, I found my team pretty openly and blatantly violated almost all those policies because they were unworkable and we had a job to do.
Things like "shadow it" were openly mocked because hp had an absolute worthless situation (they outsourced their IT management... yeah.. really terrible decision for what you'd call a tech company). The IT requests I did make were basically ignored. Anything short of a password reset request went nowhere.
Yep very true - IT was at the root of the issue, but since the software is so bad, there are multiple different login/approval flows. They had some bastardized version of SSO trying to tie it all together but she worked for an outside firm with a non-hospital email address so the SSO didn't work.
Probably related to password sharing? Sharing your password is considered a bad practice, but if it's essential that someone else gets into a system quickly in order to save a patient, then password sharing doesn't seem so bad in comparison to a dead patient.
You either accept the password and get immediate access to life saving information, or you drag your feet and go through portals and red tape and by the time you get access after several business days or weeks your patient is dead.
The only one I found was that a locked door of emergency supplies had the combination written on the door. Nobody would deny doctors and nurses access to emergency supplies.
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.
>(such as the constantly working painters required by accreditation)
Can you speak more about this or provide some links? I am fascinated by the idea that there is a small army of painters and maintainers moving unnoticed through our planet's hospitals. Sort of a parallel world to the actual care providers.
Nah, usually just one painter or so per hospital. It could be done by a contractor but because the painting has to be kept up for accreditation, they usually have someone on staff doing a little every day.
A paper record is superior in many ways but it has to live somewhere. You come to the hospital and they don't really remember you until your file burps up from the records department. You go to a different branch of your provider group and they have to mail the record to the branch before your appointment and mail it back, or fax the relevant information back and forth, allowing inconsistency to seep in.
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.
Imo, the defining problem in healthcare and EMR security is twofold in that 1. physicians delegate tasks, often in real time, and the current identity and authN protocols themselves just don't support that delegation workflow pattern, and 2. healthcare is almost never an enterprise, it's a federation, so until we solve federated authorization in open systems, we're going to suck for the same old reasons.
Health care workers workaround was password sharing, but MFA breaks that by design. I have worked on custom delegation schemes that used obo attributes, but then it's just that - some proprietary system you have to convince EMR vendors to write an integration for.
There are a few startups doing authorization as a service, and decoupling authZ from authN, but the adoption pace in health is so slow I'd bet on that being almost a decade away from normal use. I've implemented my own delegation schemes in apps (similar to just how you invite people to a document in google docs or office), but that also presumes a document-centric application, where EMR's and a number of clinical systems instantiate a patient profile from disparate data sources using an integration facility (not unlike an SOA service bus or microservices architecture), where we're just happy to have achieved coarse grained access control, but haven't yet figured out pervasive identity for fine grained control like say, attribute level consent directives. e.g. The legacy Oracle DB or Tandem mainframe you're pulling a test result from doesn't have an integration for a XACML(hah!) or UMA2 policy definition point, and where do you put the policy enforcement points - in the app service, an integration facility, a topology manager, or said wrapper over a legacy service?
I know there are startups doing this, but as a market, healthcare is a quagmire that makes it really hard for a startup depending on traction to survive.
Delegation is solvable in a closed system or platform, but once you add federation, you need a protocol and platforms that speak it.
Personally, I don't think we need new IAM platforms (the best ones do something close to what we need), we need new protocols that support things like delegation, data tokenization, consent directives on data and other fine grained policies. Even though there are people who correctly will say, "some of these are solved problems, clearly you haven't heard of X," but I'd argue without traction with the staff in agencies who make architecture decisions about it, e.g. people whose job to know about your solution don't know about it, it's not part of the conversation.
Super interesting topic. Would love to be corrected on the current availability of something like federated delegation though.
I used to volunteer at a hospital reception desk, where walk-in patients were received.
Staff had ID cards, which would both open access-controlled doors, would log into IT systems via smart card reader. Removing your card would immediately log you out.
Clearly, some designer thought they could prevent users from accidentally leaving their computer logged in, as you couldn't move around the building without your ID card, forcing you to unplug it and hence log yourself out - right?
But the receptionists' computers had the most basic specs, and were loaded with corporate bloatware and sluggish roaming profiles. And of course the software they had to use added another layer of underperforming enterprise bloatware. It would take a good 5 minutes from inserting your smartcard to actually being able to work.
Quelle surprise, the staff never unplugged their smartcards, and instead borrowed someone else's card when they needed to move around the building.
I was also in a govt / enterprise EHR type project. Similar story, but you had a double layer of VPN that only worked with outdate explorer / java etc (AT TIME OF DEPLOYMENT - the software was "new" to the govt agency and the poor health staff).
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....
While working in a hospital as a radiographer I met an IT contractor socially who was excited to be implementing a system which sounded like the one you describe ‘to help me work more efficiently’. It takes a special kind of person to confidently explain how a job they have never seen done is being done wrong.
I had to walk away.
The people who came up with that stuff probably never thought to weigh how much more it obstructs attackers than real workers... or even more scarily, thought treating them the same would be more secure somehow.
As the saying goes, a perfectly secure computer is one that no one can use
Ironically, this system resulted in lots of insecurity.
Password resets were so common the govt agency OUTSOURCED them - and you just had to provide your username to get it reset. Literally, you called and said I need a password reset for account X, and they gave you a temp password over the phone.
I never complained about how easy this was because this was a CRITICAL feature. Sometimes we didn't even know why a password wasn't working - so after you got done with whatever client came in you called the number and got a new one.
So it's really security theatre + the security provided by the massive annoyance of setting up old internet explorer to login and all the other silliness (which really was security, we were not alone in struggles, they kept on having to do paper backup systems when stuff went down).
I often thought that a hacker could probably make all our lives easier by figuring out a way around the double VPN.
This was a long time ago though (10+ years) and I have to believe better now.
In healthcare ten years doesn't even cover the original rollout you may be complaining about...
That’s terrible. And then IT staff was unionized, too?? Well that’s just the icing on the cake, ’innit!
One of the few times a thin client with a virtual desktop (like Citrix and such) is actually useful, as you can keep working after moving.
So long as Citrix isn't under-provisioned, which is all too common.
The thing about VDI is that you can't underprovision the client, but you can underprovision the server to a resonable extent. I've seen deployments who decide that it's a great idea to give Windows 10 VMs 2GB of RAM and 1vCPU, which turns the instance into a swapping mess. However if you give the users suitably sized VMs (e.g. 8G/4vCPU) then they will have the burst capacity for faster application loads and such while the server can remain overcommitted (it's rare that all users will need to use up all their vCPUs and memory at a given time).
However for doctors there may be another option aside from VDI, which is RDS or similar where a single Windows Server instance handles multiple remote desktops. Sort of like multiple users using SSH to connect into a shared Linux server. Unlike devs they can rely on a fixed image and don't need to make global changes, making a shared instance viable. This would allow the users to make better use of the compute resources on the server.
> The thing about VDI is that you can't underprovision the client…
You are underestimating the abilities of “efficiencies”-driven I.T. management.
> So long as Citrix isn't under-provisioned, which is all too common.
A common selling point of Citrix and similar solutions to the CEO is that by centralizing and sharing resources (CPU, RAM, etc.), we can save money on redundant, unused capacity - on most user workstations, the process which clocks the most CPU time is 'Idle', after all!
You can guess the rest of that story.
Nah. VDI is in many environments the biggest compute system in the datacenter. Peoples work patterns are very consistent so there typically isn’t much slack.
The top issues with VDI are memory availability and profile management. As CPU improvements stopped, apps are memory hogs. With a modern Microsoft stack, even basic users run Outlook, Teams and Chrome. Outlook is usually caching too much, so your virtual desktop with OST stored on a shitty NAS somewhere is essentially a really really awful single user Exchange server.
> Nah.
What is that in response to? You're saying VDI isn't slow and underresourced for many people? Perhaps that's not your experience, but does that mean it's not the experience of others? Are you saying that VDIs aren't sold that way to CEOs? I've seen it and the underresourced results multiple times.
Nah, they make you log out of your vm as well as the thin client, or cause your vm to auto log out when you're not connected for a couple of minutes. It still takes 10 - 15m to get logged back in.
As a bonus, you get to interact with a slow, remote desktop all day.
Or the real kicker - the hardware gets over provisioned because the incentive is to cut costs. You try to log in, get on a bum vm, then have to log out and try again and hope to get a good vm.
Makes for a very productive workforce.
>Quelle surprise, the staff never unplugged their smartcards, and instead borrowed someone else's card when they needed to move around the building.
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
Physician scientist here: this study is a bit dated. Many of these issues have been "solved" (depending on your threat model) within the last ~7 years. Most healthcare systems have adopted Imprivata [1] for SSO, where physicians tap a badge and are connected to (usually) a VDI session of Epic.
What this study misses is the real driver of EMRs: billing. EMRs exist to facilitate billing documentation to charge for patient care. Yes, they have other benefits (like viewing lab results), but if you ever see true critical care (at the bedside, in an ER, or in an ICU) little depends on the EMR (or even labs for that matter).
A few comments here talk about patient notes: in most clinical environments, inpatient notes are useless, and a tedium required to bill. They're filled with copy-pasted jargon to meet insurance company requirements. True patient care happens in less than ~1 paragraph of text called a handoff. [2]
[1] https://www.imprivata.com/
[2] https://bmjopenquality.bmj.com/content/bmjqir/7/3/e000188/F2...
> A few comments here talk about patient notes: in most clinical environments, inpatient notes are useless, and a tedium required to bill. They're filled with copy-pasted jargon to meet insurance company requirements. True patient care happens in less than ~1 paragraph of text called a handoff.
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?
Patients also don't usually know what is useful or not for a Doctor to diagnose them (or any medical provider usually). That has to be picked out as part of the Doctor or other medical provider questioning them and getting their vitals.
Some of it is implicit, like 'is the person able to form cogent sentences', or 'does the patient seem to be struggling to stand'. Others are more explicit, like heart rate, BP, 'what medicines are you taking', etc.
Often the ones who need the most help are the worst at getting anything useful out.
Sure, but I've told apparently critical info to doctor A, and then doctor B didn't know it (when I've told doctor B, it has changed their conclusions).
The patient's time has zero value to most physicians. It's often faster, and more clinically useful, for them to just ask you for your complaint and medical history. This allows them to guide the conversation and quickly focus in on the exact information they need. Searching through old chart notes is often a waste of time since the systems are slow and the data is frequently incomplete or irrelevant.
> Searching through old chart notes is often a waste of time since the systems are slow and the data is frequently incomplete or irrelevant.
I believe this can change if we change the amount of patients a physician must assess and treat in a given time period. Because that would be super costly (way more physicians required on staff) Nurse Practitioners and PAs would be a more cost effective way to delve into important and relevant information that takes time to uncover.
NPs and PA time isn't exactly cheap either, and they aren't sitting around waiting for stuff to do. They can be effective at treating routine cases under supervision, however it just wouldn't make sense for physicians to delegate patients histories and chart review to them. They won't necessarily know which questions to ask, and too much relevant information can be lost.
> way more physicians required on staff
IIRC, as of several years ago, the supply of doctors is artificially constrained and hasn't really grown with the population.
Yes that's correct. Every year, students graduate from medical schools but are unable to enter clinical practice due to a shortage of residency slots. We need more government funding to remove that bottleneck.
https://savegme.org/
The healthcare industry has plenty of money to fund those things itself.
The UK has no link between doctors and hospitals, for a shining example. This reason alone is why so many expats I know return and receive better care from any old HMO just because the billing system glues together the case histories essential for infrequent attendants to primary care due to travel etc.
Thank you for your first-hand account! For someone attempting to innovate in healthcare from the outside, this is very valuable information.
If you get the chance, what would you say is the biggest problem/limitation/shortcoming/annoyance associated with these handoffs?
I've shadowed clinicians in a hospital and ER setting for similar purposes (focused on overall user patterns) and I feel like this paper is a little light on content or suggestions to remediate.
First off, the authentication issue is real. It's also something that has largely been solved by badge readers and integrating them w/ SSO solutions. Everyone has a badge on anyway, and if you can make the login process fast, they won't have so many problems with using them on their rounds as they already use them for all sorts of access situations.
Clinicians are quite possibly the most mobile users I've ever dealt with. You either have them lug a client around with them (tablet etc, usually terrible for EMR use) or you have fixed stations in each room and in common areas etc. We discovered that VDI was a fantastic solution to the mobility problem: users have an open session on a system in a datacenter somewhere, and they can connect to it in a couple seconds by waving their badge in front of any terminal. By reducing the time-to-access and leveraging existing access control tokens you can usually get the user community on board with not trying to circumvent things.
Another thing that this paper notes and which I witnessed in person: clinicians making rounds tend to take notes in their head and then commit whatever they think needs to be written down in a batch at some later time. I watched a doctor engage with a dozen patients and then head to a PC to take notes. Doctors pride themselves on being smart people, but I harbor some serious doubts about the accuracy of this approach and I can't help but shake the notion that the first patient they saw might not have all of the pertinent information recorded an hour or two after the exam.
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 watched a doctor engage with a dozen patients and then head to a PC to take notes. Doctors pride themselves on being smart people, but I harbor some serious doubts about the accuracy of this approach and I can't help but shake the notion that the first patient they saw might not have all of the pertinent information recorded an hour or two after the exam.
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.
The solution my mother trained to perform: shorthand-using assistants, with further training in medical jargon and drug names and such. They'd follow the doctors around and take notes, so the doctor could focus on the parts of their job that couldn't be done by someone with a year or two of junior college training.
Is that still done? I've seen one doctor do it, and the assistant was typing.
I don't think it's common now, but it used to be a really common type of job.
Basically all those secretarial-type jobs—which used to be quite a bit of the workforce—went away, replaced by making experts use computers themselves, to enter data into usually-shitty-and-time-wasting systems. It's my understanding that a lot of the folks who are old enough to have done both despise the new system.
Many of the doctors I have interacted with at Kaiser refuse to use the computer and ask someone else to come enter the notes and data while they examine me or my wife.
Many of the doctors I have interacted with at Kaiser refuse to use the computer and ask someone else to come enter the notes and data while they examine me or my wife.
My mom had a job like this at a big bank.
The first thing she would do each morning is print out the e-mails for one of the V.P.'s.
The last thing she would do in the afternoon is take the dictation of his replies, and then send them as e-mails.
It's one of the reasons I roll my eyes when I see people on TV and the internet pretending to be "rich" with their multi-thousand dollar cell phones and gadgets.
Really rich people, and I mean really rich people, barely use electronics. They have people to do those things for them.
Pretty sure Jeff Bezos, Bill Gates, and Elon Musk use a lot of electronics.
Three out of thousands.
Yes, the position is called scribe.
I thought the position was called Jonathan, but the title was scribe?
Serious question, would clipboards meet current compliance requirements? There's no authentication, no audit trail, etc.
The information would have to be transcribed to the EMR, but otherwise many practitioners use written notes to fill the gap until they can document in EMR. I've also worked in facilities where certain medical paperwork was only kept in paper form and never uploaded to EMR, which I thought was insane when it comes to the concerns you've mentioned.
That's because thanks to computers, clipboards are no longer needed.
That's because thanks to computers, clipboards are no longer needed.
But the whole point of this thread is that the computers aren't getting the job done.
So why not use something has been proven to work, rather than something that is showing that it doesn't work?
It's my strong suspicion that the majority of computerized replacements for human and pen-n-paper predecessors are either a wash in terms of productivity, or actually make things worse, and it only looks like the computer revolution was a huge boon for productivity because it improved a few areas a ton.
Computers are great at replacing those filling cabinets, and when you need to track a single piece of information over a lot of people or a lot of time. Other uses in an office aren't as transformative.
Sorry, clearly I confused you. I was being sarcastic. I should have made that obvious (e.g. with /s etc).
I’m yet to experience a long clipboard outage.
EMT here. We still use clipboards in the field on 911 calls. I can fill out a paper patient report in real time while I talk to the patient. Transcribing it into the EMR on the computer later takes about 45 minutes.
Some of our peer services use tablets in the field. I hope we never switch over. Besides the nightmare of the horrible UI (because that's always the case with enterprise software), if the batteries die or you try to use them outdoors in bright sun, you're hosed.
> I harbor some serious doubts about the accuracy of this approach and I can't help but shake the notion that the first patient they saw might not have all of the pertinent information recorded an hour or two after the exam.
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.
Some physicians dictate chart notes as they walk from one patient's room to the next.
The best software is developed by people who have deep knowledge about the use case and/or the ultimate customer. What proportion of PMs at health software companies have worked in a hospital? I'd wager it's vanishingly small.
My take from this paper is that a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from other vendors.
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.
This is a great point - too many companies forget to optimize for speed of UX. My theory is because speed of UX isn't a strong selling point to decision makers. JIRA sells well because it's a safe choice (recent fuckups not-withstanding) and is very full featured. Speed of UX matters for the end user, unfortunately too often the end user has no say in the software they're using.
> a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from other vendors.
The problem here is we're talking government software, or IT-as-a-cost-center software. So the buyer is looking at the cheapest bidder. They aren't getting a team like those who solved the UX trifecta in the past (looking at the iPhone team at Apple here).
> 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.
Paper isn't fast, it's cached. Parsing, archiving and indexing of paper is extremely slow (when actually done). The slowness of input in a computer system might annoy the user but the system overall is way more efficient. Now auth taking more than a second or two is just lazy programming (bet it's not exactly Google caliber engineers working on the project).
> the PM just has to say "no, this isn't acceptable", and find a team that can implement it well.
The problem here is he'll have to 10x the budget.
What proportion of PMs at health software companies have worked in a hospital?
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.
> 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.
This is interesting. I assume you are in some IT or software role? If so, what is it that they actually trust you to do around patients? How do the "real" healthcare workers treat you?
I assume you are in some IT or software role?
Yes.
what is it that they actually trust you to do around patients?
It varies from year to year, but is always interacting directly with them. I've been hugged, cried on, held people's babies while they (the parents) vomited in the hallways, had people rant at me in languages I don't understand. All kinds of human activity.
How do the "real" healthcare workers treat you?
They pretty much ignore me. I expect on some level, they're happy to have someone picking up the details so they can do other things, but for the most part they seem far too busy to even notice that I'm there.
I agree. Many general practitioners in Australia use the same practice management software which was initially developed by an unsatisfied general practitioner who taught himself programming. He also kept practicing medicine which is really impressive.
I don't know the percentage, but healthcare software vendors absolutely do hire experienced clinicians as Product Managers when they can. But it's hard. There are few such employees available, they're expensive, and most don't understand the product development process. Furthermore their experience sometimes isn't even very relevant: someone who spent 10 years as an obstetrics nurse won't necessarily understand oncology workflows.
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.
I think you can hire people who know the market in their bones from hard-fought experience, but you could also contract out some user experience researchers to shadow these people and tell you everything you need to fix. I have to imagine a healthcare worker turned PM has to be rare and expensive that they cost more than contracting out research. The reason both don’t happen is probably that they are expensive to do (and expensive to execute on the information you find).
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.
This removes healthcare workers from the workforce though, and we need healthcare workers more than PMs with direct experience. They would need to be good PMs on top of being good healthcare workers and I don't think you're going to find that as often as you think.
Another common example: patients who want to share their exam results with their doctor. The proper way would be to use the document sharing feature inside the web portal, but often the simplest solution is for the patient to send their username and password to the doctor.
It has became a quite common way around platforms for sharing results etc. in Germany to give out a QR code which is actually an specific URL to the patient where the password is the birth date. This way the patient just needs to share the URL/QR code because the doctor does already have the birth date.
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.
Healthcare organizations don't want to accept file uploads from patients due to the malware risk. If there's a zero-day exploit in your PDF viewer or something then a single shared file could wreck their entire enterprise network.
I was talking about going in the web app where you get the results and granting the doctor permission to view the file. The problem is that the doctor needs to have an account on the system, and also that the UI for sharing is hard to use ...
If the doctor ordered a lab test then normally the results will be delivered directly into their EHR.
> Koppel et al [16] document physicians ordering medications for the wrong patient because a computer was left on and the doctors didn’t realize it was open for a different patient
When you're in an environment with high stress (many decisions with huge consequences being made in a minutes/seconds timeframe in different simultaneous contexts), spending time with authentication has consequences. Not spending, too.
In my day to day life using computers I get frustrated to the point of anger by the scarcity of systems designed and implemented holistically by talented people - I can't even imagine what it must be like using these systems while trying to do a physician's job.
Someone once said "90% of sci-fi is crap".
Sci-fi author Theodore Sturgeon then coined Sturgeon's Law which is that 90% of EVERYTHING is crap.
I guess the moral of the story is to focus on, and try to be surrounded by, the 10%.
Good luck to those poor doctors!
That reveals a common corollary: Whoever is speaking is always in the 10%.
90% of doctors aren't so hot either.
You know what they call the person who graduated last in their class in medical school?
Doctor.
We all use keycards to access buildings and secure rooms. Keycards should be (and have been) used to secure computer systems in lieu of passwords. Now with U2F and biometrics that's the best practice.
If passwords have to be used, they should not be chosen by a user, but generated by the system and given to the user once. This is how 'app passwords' work with modern secure web services that otherwise require multi-factor authorization. For memory's sake this can be a set of words.
The absence of a secured NFC or bluetooth connection can be used to automatically de-authenticate and lock sessions. I created a perl script to lock my screen-saver this way 15 years ago!
It should be dead simple to modify systems access. A set of keycards should grant admin access to different parts of the system, and those given out to different levels of staff, so each level of staff can admin the group they work with, and higher levels can provide additional override. This provides redundancy and scales workload better.
For problems with the EHR system, this stems from poor design. Monolithic systems cannot be easily worked around, but loosely-coupled systems can be. A set of filing cabinets are loosely-coupled from what they can hold, can be keyed the same or differently, can be repurposed. Information system design needs to work more like independent furniture in an office, rather than a single set of furniture that only works in one way. Systems should be decoupled from each other so that a user can manually shuffle data around between them. Data should be decoupled from systems and made portable. Data fields should allow comments the way a piece of paper allows you to write in the margins.
What’s the dichotomy implied by the hyperbolic title? I couldn’t find any sign of it in the first few pages.
It's not clear in the paper, but it's a common issue in healthcare settings. Most meds are dispensed via med cabinets (Pyxis is the primary brand: https://www.bd.com/assets/images/our-products/medication-sup...) that have a variety of controls in place to prevent diversion and to track medications delivered.
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.
All this comes from a common place.
The people buying the software and adding the policies are NOT the same people who use the software or enforce the policies.
I saw this at HP. As a new hire, I had like 20 different meetings talking about the various policies of the company you had to follow. After I started working, I found my team pretty openly and blatantly violated almost all those policies because they were unworkable and we had a job to do.
Things like "shadow it" were openly mocked because hp had an absolute worthless situation (they outsourced their IT management... yeah.. really terrible decision for what you'd call a tech company). The IT requests I did make were basically ignored. Anything short of a password reset request went nowhere.
>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
That's likely hospital IT, not the software itself. Those departments are understaffed, underpaid, on-call, and overworked.
However, an incapable IT department combined with mediocre software makes everything much worse.
Yep very true - IT was at the root of the issue, but since the software is so bad, there are multiple different login/approval flows. They had some bastardized version of SSO trying to tie it all together but she worked for an outside firm with a non-hospital email address so the SSO didn't work.
Probably related to password sharing? Sharing your password is considered a bad practice, but if it's essential that someone else gets into a system quickly in order to save a patient, then password sharing doesn't seem so bad in comparison to a dead patient.
You either accept the password and get immediate access to life saving information, or you drag your feet and go through portals and red tape and by the time you get access after several business days or weeks your patient is dead.
I didn't see anything in the paper that matches the title. Seems to be hyperbole (that doesn't make complete sense either).
It would make more sense if you'd ever spent time in a healthcare setting. As it is, you're unqualified to make a judgment on its sensibility.
The only one I found was that a locked door of emergency supplies had the combination written on the door. Nobody would deny doctors and nurses access to emergency supplies.
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.
>(such as the constantly working painters required by accreditation)
Can you speak more about this or provide some links? I am fascinated by the idea that there is a small army of painters and maintainers moving unnoticed through our planet's hospitals. Sort of a parallel world to the actual care providers.
Nah, usually just one painter or so per hospital. It could be done by a contractor but because the painting has to be kept up for accreditation, they usually have someone on staff doing a little every day.
That was rather depressing reading. It seems that paper-based system was a superior system.
Changing it back is probably impossible though.
A paper record is superior in many ways but it has to live somewhere. You come to the hospital and they don't really remember you until your file burps up from the records department. You go to a different branch of your provider group and they have to mail the record to the branch before your appointment and mail it back, or fax the relevant information back and forth, allowing inconsistency to seep in.
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.
Could be titled:
"How computers ushered in an era of unprecedented office worker productivity gains"
Followed, of course, by the poker-face smiley:
:|
Imo, the defining problem in healthcare and EMR security is twofold in that 1. physicians delegate tasks, often in real time, and the current identity and authN protocols themselves just don't support that delegation workflow pattern, and 2. healthcare is almost never an enterprise, it's a federation, so until we solve federated authorization in open systems, we're going to suck for the same old reasons.
Health care workers workaround was password sharing, but MFA breaks that by design. I have worked on custom delegation schemes that used obo attributes, but then it's just that - some proprietary system you have to convince EMR vendors to write an integration for.
There are a few startups doing authorization as a service, and decoupling authZ from authN, but the adoption pace in health is so slow I'd bet on that being almost a decade away from normal use. I've implemented my own delegation schemes in apps (similar to just how you invite people to a document in google docs or office), but that also presumes a document-centric application, where EMR's and a number of clinical systems instantiate a patient profile from disparate data sources using an integration facility (not unlike an SOA service bus or microservices architecture), where we're just happy to have achieved coarse grained access control, but haven't yet figured out pervasive identity for fine grained control like say, attribute level consent directives. e.g. The legacy Oracle DB or Tandem mainframe you're pulling a test result from doesn't have an integration for a XACML(hah!) or UMA2 policy definition point, and where do you put the policy enforcement points - in the app service, an integration facility, a topology manager, or said wrapper over a legacy service?
I know there are startups doing this, but as a market, healthcare is a quagmire that makes it really hard for a startup depending on traction to survive. Delegation is solvable in a closed system or platform, but once you add federation, you need a protocol and platforms that speak it.
Personally, I don't think we need new IAM platforms (the best ones do something close to what we need), we need new protocols that support things like delegation, data tokenization, consent directives on data and other fine grained policies. Even though there are people who correctly will say, "some of these are solved problems, clearly you haven't heard of X," but I'd argue without traction with the staff in agencies who make architecture decisions about it, e.g. people whose job to know about your solution don't know about it, it's not part of the conversation.
Super interesting topic. Would love to be corrected on the current availability of something like federated delegation though.