[HN Gopher] Workarounds to computer access in healthcare organiz...
___________________________________________________________________
Workarounds to computer access in healthcare organizations (2015)
[pdf]
Author : mooreds
Score : 94 points
Date : 2022-05-20 14:33 UTC (8 hours ago)
(HTM) web link (www.cs.dartmouth.edu)
(TXT) w3m dump (www.cs.dartmouth.edu)
| YeGoblynQueenne wrote:
| Could be titled:
|
| "How computers ushered in an era of unprecedented office worker
| productivity gains"
|
| Followed, of course, by the poker-face smiley:
|
| :|
| motohagiography wrote:
| 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.
| luma wrote:
| 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.
| reaperducer wrote:
| _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.
| corrral wrote:
| 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.
| wolverine876 wrote:
| Is that still done? I've seen one doctor do it, and the
| assistant was typing.
| lfpeb8b45ez wrote:
| Yes, the position is called scribe.
| Cerium wrote:
| 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.
| corrral wrote:
| 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.
| YeGoblynQueenne wrote:
| That's because thanks to computers, clipboards are no longer
| needed.
| lostlogin wrote:
| I'm yet to experience a long clipboard outage.
| reaperducer wrote:
| _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?
| corrral wrote:
| 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_.
| YeGoblynQueenne wrote:
| Sorry, clearly I confused you. I was being sarcastic. I
| should have made that obvious (e.g. with /s etc).
| lionsdan wrote:
| Serious question, would clipboards meet current compliance
| requirements? There's no authentication, no audit trail, etc.
| calvano915 wrote:
| 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.
| 908B64B197 wrote:
| > 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.
| nradov wrote:
| Some physicians dictate chart notes as they walk from one
| patient's room to the next.
| ufo wrote:
| 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.
| Krasnol wrote:
| 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.
| nradov wrote:
| 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.
| semenko wrote:
| 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...
| abrichr wrote:
| 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?
| wolverine876 wrote:
| > 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?
| nradov wrote:
| 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.
| calvano915 wrote:
| > 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.
| wolverine876 wrote:
| > 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.
| lazide wrote:
| 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.
| wolverine876 wrote:
| 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).
| michaelt wrote:
| 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.
| tempnow987 wrote:
| 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....
| lostlogin wrote:
| 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.
| userbinator wrote:
| 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
| markus92 wrote:
| 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.
| ebiester wrote:
| So long as Citrix isn't under-provisioned, which is all too
| common.
| wolverine876 wrote:
| > 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.
| Spooky23 wrote:
| 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.
| wolverine876 wrote:
| > 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.
| digitallyfree wrote:
| 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.
| Terretta wrote:
| > _The thing about VDI is that you can 't underprovision
| the client..._
|
| You are underestimating the abilities of
| "efficiencies"-driven I.T. management.
| mnau wrote:
| That was rather depressing reading. It seems that paper-based
| system was a superior system.
|
| Changing it back is probably impossible though.
| projektfu wrote:
| 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.
| axg11 wrote:
| 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.
| reaperducer wrote:
| _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.
| ElevenLathe wrote:
| > 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?
| mattnewton wrote:
| 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.
| vsareto wrote:
| 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.
| YPPH wrote:
| 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.
| jrockway wrote:
| 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.
| axg11 wrote:
| 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.
| 908B64B197 wrote:
| > 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.
| woliveirajr wrote:
| > 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.
| happytoexplain wrote:
| 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.
| FredPret wrote:
| 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!
| wolverine876 wrote:
| That reveals a common corollary: Whoever is speaking is
| always in the 10%.
|
| 90% of doctors aren't so hot either.
| raldi wrote:
| What's the dichotomy implied by the hyperbolic title? I couldn't
| find any sign of it in the first few pages.
| xwdv wrote:
| 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.
| goda90 wrote:
| 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.
| mikeyouse wrote:
| 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.
| vsareto wrote:
| >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.
| mikeyouse wrote:
| 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.
| cogman10 wrote:
| 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.
| projektfu wrote:
| 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.
| aftbit wrote:
| >(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.
| projektfu wrote:
| 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.
| nisegami wrote:
| I didn't see anything in the paper that matches the title.
| Seems to be hyperbole (that doesn't make complete sense
| either).
| noSyncCloud wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-20 23:01 UTC)