Fun! This is centered in my wheelhouse, specifically I have been on both the patient facing and software side of healthcare. Presently in the latter and deal with Epic (along with every one of...
Exemplary
Fun! This is centered in my wheelhouse, specifically I have been on both the patient facing and software side of healthcare. Presently in the latter and deal with Epic (along with every one of their competitors) on a near daily basis. So AMA if you want after I've finished my thoughts on this piece. I like to type my replies as I'm reading the article, so I'll quote a section, make a response and move on. This can result in my own responses being addressed later in the article and if so I may or may not remove them.
Something’s gone terribly wrong. Doctors are among the most technology-avid people in society; computerization has simplified tasks in many industries. Yet somehow we’ve reached a point where people in the medical profession actively, viscerally, volubly hate their computers.
This, in my experience, is primarily because the software systems are following guidance from the wrong direction. Instead of the software being designed for patient care it was designed to comply with the HITECH Act; and as with any government requirement it was designed to meet the minimum necessary rules written by people that aren't in healthcare and know next to nothing about it. As with a lot of government initiatives, the idea (to have connected EHR systems so that each physician and hospital can connect together to coordinate care) was a good one, the execution was not. The Epic system, along with all others, evolved from a meet this bare minimum requirements to what it is now by taking suggestions from each hospital they've had sign on the dotted line because each one has their own policies and procedures of how they do things. This isn't something that scales well, so after some time Epic stopped making changes based on those suggestions unless it can be found to be financially beneficial to do so. Now they are so large that their system changes how care is performed instead of care dictating how the system should work. Prior to HITECH many hospitals had their own home brewed software that worked with how they cared for their patients. Early adopters of Epic had changes made that fit their procedures, later buyers are being pushed to follow those practices as they are already built into the Epic system even if they are different, less efficient, and do not fit their care model. So you have software being built by people with no healthcare experience, to meet regulations given by people with no healthcare experience, then being modified to suit the rigid requirements of the first hospitals to adopt it, and forced down the throats of hospitals that do things differently.
Many patient medications and instructions hadn’t transferred accurately from our old system. My hospital had to hire hundreds of moonlighting residents and pharmacists to double-check the medication list for every patient while technicians worked to fix the data-transfer problem.
This is still a common issue with Epic implementations. They're big enough that they tell previous vendors, or in this case home brewed software, to modify their systems to meet Epic's import/migration requirements and refuse to allow any changes to it regardless if the old system has that data in the format desired. The outgoing software vendor is reluctant to spend any money on a contract they're losing, the incoming vendor (Epic in this case) can just point fingers at the outgoing one saying "see, they won't work with us and is obviously why you're leaving them to come with me), and the nightmare that occurs during the transition makes executives less likely to leave Epic once the contract is up and so renews it time and again. Their competitors know this and have tailored their migration systems and have staff that have worked for Epic specifically to deal with this childish behavior when a hospital system moves on from Epic thankfully.
Questions that doctors had routinely skipped now stopped them short, with “field required” alerts. A simple request might now involve filling out a detailed form that took away precious minutes of time with patients.
This is a fair take. Physicians frequently will skip over "boring" bits of info that are either common sense to them but are required info for people further down the line (be it nurses, assistants, or billing departments). This keeps support staff from, typically physically, chasing down providers for needed info. Providers hate being told what to do, their entire careers are around figuring things out on their own. To be fair a lot of providers would fill this info in later, at the end of the day when there are no patients scheduled, but now they're being required to do so at the time of service (which has the benefit of being more accurate) and have patients scheduled from start of shift to end. The balance gets tipped back by these physicians finding creative ways around these required fields in order to stick with their previous way of doing things in attempts to actually treat their patients and having to work late to correct them.
A lot of this stems from broken promises. When the computerization of medical records began everyone, and I mean everyone from software providers to hospital administration themselves, were promising physicians that they'd all have an assistant to shadow them and do the data entry for them so that they could actually treat their patients. Then they'd review the records at the end of the day, make corrections, and sign off on it. That promise was fulfilled in a lot of places for a brief time and then the idea came about "Why are we paying someone to do data entry for a doctor instead of just making the doctor enter the info? Think of how much money would could make/save if we didn't have these "assistants!" and so the onus was placed back on providers. Profit rose, care suffered, the march of for profit healthcare continues.
With two clicks, I could look up patient results from outside institutions that use Epic, as many now do.
HITECH was written with the intent of each system communicating with all other systems, agnostic to the vendor, this of course did not happen as there is no standard for communication and just that it must happen "electronically". The standard that they use today? PDF - Yep, these systems "communicate" with those of another vendor by allowing the importing of a PDF from the competitor.
The list is intended to tell clinicians at a glance what they have to consider when seeing a patient. Sadoughi used to keep the list carefully updated—deleting problems that were no longer relevant, adding details about ones that were. But now everyone across the organization can modify the list, and, she said, “it has become utterly useless.” Three people will list the same diagnosis three different ways.
This is a two part problem. Part one is the "too many cooks in the kitchen" issue. Everyone can make changes, everyone thinks their opinion is valid, everyone had different standards for how they document that info. Part two is the physician god complex, it is both well documented and in my case directly witnessed. A vast majority of doctors think they are always right and will actively reject the diagnosis of other physicians if it is contrary to theirs. Often this is only if the other physician is in the same specialty, but it will even occur across specialties.
With computers, however, the shortcut is to paste in whole blocks of information—an entire two-page imaging report, say—rather than selecting the relevant details. The next doctor must hunt through several pages to find what really matters.
Part of this is due to corruption, fraud, and false billing practices. Every insurance company (including Medicare/Medicaid) sends tens of thousands of chart review requests per year. These involve the provider/hospital submitting the medical record for the visit to the insurance company for review so they can ensure that they aren't being billed for things that didn't occur, weren't warranted, or didn't have all of their arbitrary rules met in order to be "medically necessary". So there's automatic copying in these systems to ensure everything is there at all times, to the detriment of quick care, to cover the administration's ass during these reviews.
“Ordering a mammogram used to be one click,” she said. “Now I spend three extra clicks to put in a diagnosis. When I do a Pap smear, I have eleven clicks. It’s ‘Oh, who did it?’ Why not, by default, think that I did it?” She was almost shouting now. “I’m the one putting the order in. Why is it asking me what date, if the patient is in the office today? When do you think this actually happened? It is incredible!” The Revenge of the Ancillaries, I thought.
Poor software optimization. Click counting is something all the good hospitals are doing now to try to cut down on this and they are including it as part of the selection criteria for new software. She has every right to be angry, ancillaries aren't to blame though, but I'm guessing this is covered later based on that last sentence.
Sadoughi told me of her own struggles—including a daily battle with her Epic “In Basket,” which had become, she said, clogged to the point of dysfunction. There are messages from patients, messages containing lab and radiology results, messages from colleagues, messages from administrators, automated messages about not responding to previous messages. ... Previously, she sorted the patient records before clinic, drafted letters to patients, prepped routine prescriptions—all tasks that lightened the doctors’ load. None of this was possible anymore. ... But, she told me, “all I can do is go after the help desk thirteen times.”
These restrictions were put into place to reduce liability by administration. It's the typical one bad apple ruining the bunch sort of thing. You get someone that was changing records that they thought was a typo trying to help and now everyone that lightened the physician's load is locked out to keep that from happening. You get one bad actor that wrote a prescription for a friend or family member, maybe even forging the signature, and now every other competent and honest person is locked out. You get one idiot that lied about their abilities and misses a crucial lab result, filing it away instead of bringing it to the physician's attention and every other intelligent individual is locked out. Now physicians have to sign off on everything and only they are allowed to do so, causing more work away from patients, making them work longer hours, making them tired, making them more likely to miss something that administration was trying to avoid with all of this locking out.
Jacobs felt sad and sometimes bitter about this pattern of change: “It’s disempowering. It’s sort of like they want any cookie-cutter person to be able to walk in the door, plop down in a seat, and just do the job exactly as it is laid out.”
Yep, because those cookie cutter button pushers are cheaper. Part of the Epic sales pitch is being able to allow the hospital to save money on labor costs by hiring lower paid, less skilled workers.
“I’m the veteran of four large-scale electronic-health-records implementations,” he told me in his office, overlooking downtown Boston. Those included two software overhauls in the military and one at Dartmouth-Hitchcock Medical Center, where he’d become the chief clinical officer. He still sees patients, and he experiences the same frustrations I was hearing about. Sometimes more: he admits he’s not as tech-savvy as his younger colleagues.
Oh boy! I'm going to have fun in this section tearing this inflated ego asshat a new one. I'll admit, I was starting to get bored, but I do revel in calling textbook Dunning-Kruger examples out on their idiocy.
He's a veteran of two military software overhauls. Holy shit if you think medical software is bad, try government software contracts! The hilarity is that he thinks this is a badge of pride, I wonder if he can see the sunlight with his head that far up his ass. Military software is notoriously bad, outdated, inefficient, and needing replaced the day it is implemented. Military software purchasing is a matter of favors, bribes, and politics, not efficiency, usability, or any other purpose.
He admits that he doesn't know how this works. "Not as tech savvy" is ego-speak for "I don't know shit". He gets paid to make decisions based on what sales people tell him works, not how it actually works or how the people that have to use it work.
“But we think of this as a system for us and it’s not,” he said. “It is for the patients.” While some sixty thousand staff members use the system, almost ten times as many patients log into it to look up their lab results, remind themselves of the medications they are supposed to take, read the office notes that their doctor wrote in order to better understand what they’ve been told. Today, patients are the fastest-growing user group for electronic medical records.
Patient adoption rates for these systems are laughably low. They do not log in to do anything in that list. Know what they log in to do? Pay their bill. That HITECH act I mentioned earlier? It has minimum patient adoption quotas. That metric, as you can't force patients to do anything, is measured by the number of patients that log in to their "portal" which has their medical records in it. So how do you get them to log in to meet the metric and not get penalized? Put the bill paying portion behind the same log in. These systems have arguably lowered the standard of care, so they are most certainly not built "for the patients". They are built for the corporations that own hospitals to meet requirements to make the most money possible. Period.
Computerization also allows clinicians to help patients in ways that hadn’t been possible before. In one project, Partners is scanning records to identify people who have been on opioids for more than three months, in order to provide outreach and reduce the risk of overdose. Another effort has begun to identify patients who have been diagnosed with high-risk diseases like cancer but haven’t received prompt treatment. The ability to adjust protocols electronically has let Meyer’s team roll out changes far faster as new clinical evidence comes in. And the ability to pull up records from all hospitals that use the same software is driving real improvements in care.
This is a fair take. More data allows computers to catch things humans wouldn't be able to notice on such a scale. The implementation that requires all of the providers of that data to be on the same system is what makes it an overall failure.
Gregg Meyer is understandably delighted to have the electronic levers to influence the tens of thousands of clinicians under his purview.
How does he fit through the door with his head inflated by all that ego?
He had spent much of his career seeing his hospitals blighted by unsafe practices that, in the paper-based world, he could do little about. A cardiologist might decide to classify and treat patients with congestive heart failure differently from the way his colleagues did, and with worse results.
He was a bad leader then too. All medical professionals have to go through continuing education and are instructed to follow best practices as have been laid out by studies and their peers in journals and the like. Software has not changed that and these systems are not allowed to diagnose or tell the physicians how to treat. They can only provide links to the studies/journals for the physician to read to make treatment decisions. If a bad doctor wasn't reading them before, then they aren't going to read them now.
“Now there’s a change-control process,” Meyer said. “When everything touches everything, you have to have change-control processes.” ... Artisanship has been throttled, and so has our professional capacity to identify and solve problems through ground-level experimentation. ... What we want and don’t have, however, is a system that accommodates both mutation and selection.
Last sentence is well said. This guy likes to be in control, he doesn't adapt, he doesn't change, and he's fine with that. This guy has a routine. I bet he has his morning bowel movement scheduled to the minute. The world doesn't work that way. Medicine doesn't work that way. It can't. And yet he and these companies are trying to force it to do so.
Consider that, in recent years, one of the fastest-growing occupations in health care has been medical-scribe work, a field that hardly existed before electronic medical records. Medical scribes are trained assistants who work alongside physicians to take computer-related tasks off their hands. This fix is, admittedly, a little ridiculous. We replaced paper with computers because paper was inefficient. Now computers have become inefficient, so we’re hiring more humans. And it sort of works.
Not long ago, I spent a day following Lynden Lee as he scribed at a Massachusetts General Hospital primary-care practice.
Glad to see my broken promises line earlier come around. There's a detail here in the last sentence that makes my point. This scribe had to be found at an independently run PCP practice. This doctor is willingly reducing the amount of money his practice can make by hiring someone to do the data entry so he can do his job, treating patients. Hospital physicians don't have this luxury. The administration won't allow it. And as more and more independent practices get bought out by the "hospital groups" the same occurs there. No more help. Onus on the physician to do data entry to save a buck and care suffers because of it.
Edits made to clarify one point and fix grammatical errors.
It's interesting. I don't work in healthcare, but I do a lot of work in what seems to be fairly similar industry (software security). I wonder how much overlap there is between your experiences...
It's interesting. I don't work in healthcare, but I do a lot of work in what seems to be fairly similar industry (software security). I wonder how much overlap there is between your experiences and mine. We have been moving from a vastly more prescriptive initial implementation of a lot of these technologies to more of a user-augmented approach, where we try to be as out of the way as possible and design-flexible to the user's current needs. We have a similar userbase of overworked, strapped for time (and not always particularly technically sophisticated) users, where every minute and second counts. They have terrible technology scars from prior attempts at orchestration. They were promised that the technology (I, technically) provide would make their lives and jobs easier, often without the realization of that promise. And there are a lot of factors that drive that fraught dynamic:
The software engineer/developer is too often too distant from the needs of the user (doctors, analysts, nurses, anyone who is intended to use the thing that's supposed to make their lives easier). - Basically this means that the concerns they hear about most often come from above (administration, compliance, and the people who pay the software developer's bills) than from those downstream of their content (the user).
Most of us (software-side) are not particularly skilled project managers, and we're often tasked with doing complex project management, or given too little opportunity or room to figure out what might be a better path for user experience. This has a LOT of downwind impact, not the least of which being ...
We're often not getting a good understanding of the actual needs of users in these industries before we release product increments, and how our content can make their lives easier. This restricts buy-in, especially from people who are strapped for time and working in what is effectively a constant state of emergency time management. The user doesn't have time to test, doesn't have time to engage in feedback, and often doesn't have incentive to believe they'll be heard if they do.
The focus on "minimum viable product" often gets insufficient followup as the pressure becomes delivering "the next thing" without the time or investment in feedback. With how strapped the user usually is in the first place, this often means there is no feedback at all as to how the increment can be better, unless it actually breaks and is impossible to use (and sometimes not even then; the user will just try to work around the product rather than with it).
Programmers generally are not often good about thinking about the whole design of the product all at once (a problem fed by not being particularly good at project management). Like, the design side should more often be thinking stuff along the lines of "if my product isn't perfect, how can I give the user the tools to do their job anyway" versus "my product will be fine. It's unit tested! Does exactly what it's intended to do. What's the problem?" We don't play well with failure. A lot of us are perfectionists (myself included).
Does any of this resonate with you? It seems like Epic specifically is a toxic asshole of a company that intentionally makes product decisions in the way most suited to protect their ego, but even if they were trying to play nice I think there'd be a lot of very serious problems preventing a lot of industry buy in for these sorts of products.
Not to make your response seem trivial with a short response, but in this case there's little reason to be anything other than succinct. You hit the nail on the head with every point made.
Not to make your response seem trivial with a short response, but in this case there's little reason to be anything other than succinct.
You hit the nail on the head with every point made.
The scale of my issue is much smaller, but this one resonates with me a lot from both ends of the problem. From one end: My first job I was one of 3 employees and the sole developer on a massive...
We're often not getting a good understanding of the actual needs of users in these industries before we release product increments
The scale of my issue is much smaller, but this one resonates with me a lot from both ends of the problem.
From one end: My first job I was one of 3 employees and the sole developer on a massive program that was about 1/3 of my company's profit. The other two people were a project manager who also managed a couple of other projects related to mine, and a very nice engineer who was doing QA/Customer Support/UX design. A lot of times I would design workflows for data input and send it to our QA team or some customers who liked testing new features for us and they would send it back and tell me it was virtually useless. It took a lot of time for me to understand that the way I thought to solve a problem didn't matter if the users didn't like it or understand it.
Now I am on the other side of that. I am working on a project for a new company using <open source software>. First they pushed us to do things in a specific way ("technically you can do it in any way you want, but we strongly suggest doing it this way") and then the way they suggested is FULL of limitations that make the workflow basically unusable for us (and based on the github issues page, unusable for lots of people). Their response when people voice these issues? "We believe if this workflow is unusable for you because of these missing features, it is because you are wrong and should restructure things to work this way". Dude. I get the customer isn't always right. But if (a) a large number of customers are all saying the same thing and (b) The issue is something like "we don't support dictionaries or regexes", the way YOU are doing things is wrong. The singular customer might not always be right, but the collection of your user base is. I'm fed up with it to the point where I am about to move to a different software solution. The only thing holding me back is the sunken cost of 3 months of development time for multiple engineers.
Lolwut? For something like an MRI, fine. But for data? WTF? PDFs are terrible because you can't actually get any useful data out of them. They are literally a set of commands for drawing...
The standard that they use today? PDF
Lolwut? For something like an MRI, fine. But for data? WTF? PDFs are terrible because you can't actually get any useful data out of them. They are literally a set of commands for drawing characters on the page. A single word could be broken into different drawing commands or letters could be drawn in some order other than the order you read them or type them. They are quite possibly the worst format for exchanging data (unless the data is vector drawings).
Patient adoption rates for these systems are laughably low. They do not log in to do anything in that list.
This doesn't surprise me. In the past my wife would frequently use the patient portal to get results and communicate with her doctors. I refused because most of them were run by marketing companies that were not required to be HIPAA compliant. Also, as a software engineer, I think all software sucks (and web-based software is particularly bad).
It's unfortunate because after an ER visit, I ended up downloading my hospital's app because I was too weak to call and fight with a human on the phone about something. It turned out to be incredibly useful for some things. I now see lab results as soon as they're in the computer. I don't have to wait 3 days for my doctor to call and tell me the results.
But I totally understand the feeling most users have – for years these apps have been insecure, buggy, and crappy to use. Why would any user want to use them?
You are right on all points there, but they meet the minimum of being "electronic" and "universal" and that's all they care about. There are interfaces to communicate and they have defined fields,...
Lolwut? For something like an MRI, fine. But for data? WTF?
You are right on all points there, but they meet the minimum of being "electronic" and "universal" and that's all they care about. There are interfaces to communicate and they have defined fields, but the data within those fields can be in all kinds of formats and so one system cannot communicate with another without ample amounts of data validation and translation tables being built which is work neither side wants to put in unless there's financial benefit.
The portals have improved because they were originally built for that minimum engagement goal and over time as other areas of the software has stagnated the companies selling to the hospitals needed to come up with new revenue streams. And so they're going back to places where they have done next to nothing and it's easier to make changes. Now, like you said, they have to convince the patients that it's no longer useless.
Out of curiousity, do you have any experience working with kyruss? I only ask because a while back I was interviewing with them and reading about the issues in healthcare tech, their goals, and...
Out of curiousity, do you have any experience working with kyruss? I only ask because a while back I was interviewing with them and reading about the issues in healthcare tech, their goals, and their solutions and it all sounded really interesting and hopeful. Wondering if someone who has actual industry knowledge and experience knows of them and has any thoughts.
I do not have very much to contribute but I am finishing my last semester at university with a focus on UX Design. What you just described to me has convinced me to apply as I will be moving to...
I do not have very much to contribute but I am finishing my last semester at university with a focus on UX Design. What you just described to me has convinced me to apply as I will be moving to Wisconsin. If what you are saying is true, if I’m able to work on untangling that mess, I would be able to help doctors with burn out, speed up processes, and provide patients with a better healthcare experience. That sounds like a goal I am very much down for.
Most of the hospitals around here use Epic. As a patient, I despise it. My doctors used to come in, look me in the eye, talk with me, and take some notes. Now they come in and say "Hi," then turn...
Most of the hospitals around here use Epic. As a patient, I despise it. My doctors used to come in, look me in the eye, talk with me, and take some notes. Now they come in and say "Hi," then turn to their computer and look at the screen the entire time. It's very off-putting.
But what's worse is that they can't enter the information I give them correctly. For example, I have an allergy to almonds. But somehow it got entered as being an allergy to "almond oil." Likewise I have a medication that I inject, but the system says I'm using a trans-dermal patch. I've gotten them to correct some of it, but for some of it, they tell me they can't change it, or it's too hard to change. I'm like, this is my health and safety we're talking about. I don't want to get a bad treatment because their software was too crappy to record the correct information!
In case you were worried, Epic is widely despised by doctors and other medical professionals, as well (though most of their competition is apparently significantly worse). But really, most of the...
In case you were worried, Epic is widely despised by doctors and other medical professionals, as well (though most of their competition is apparently significantly worse). But really, most of the issues with it are a symptom of the state of healthcare in the US. Electronic medical record systems aren't a patient care tool; they're a billing tool, meant to record billable actions in a format insurance companies find acceptable, and any benefits to patient care are incidental.
They're also not popular among decent amount of people who live in the Madison area (where they're based). They're one of those companies that acts super cool and fun (and tbf the architecture of...
Epic is widely despised by doctors and other medical professionals
They're also not popular among decent amount of people who live in the Madison area (where they're based). They're one of those companies that acts super cool and fun (and tbf the architecture of their offices is incredible) but people who work there get worked to the bone and aren't treated very well outside of perks like the in-house cafeterias and stocked fridges. I wouldn't work 60+ hours a week for any amount of money.
Thanks for chiming in. One of the people (doctor+administrator) in the article claims that a significant benefit of these software systems is patients being able to look over their records, offer...
Thanks for chiming in. One of the people (doctor+administrator) in the article claims that a significant benefit of these software systems is patients being able to look over their records, offer feedback, and get explanations. How has that worked in your experience?
In principle one should be able to complain to “Epic” about this, but in practice, the process of trying to get to a person in a large corporation making enterprise software can unfortunately feel Kafka-esque.
If it bothers you enough, maybe start a thread on Tildes where other people can chip in with their experiences. Maybe collectively there might be enough ammunition that folks get energized to act on it.
It's been a mixed experience. Yes, I do have access to my records and can review them. It's not clear to me whether that's due to Epic or whether it's due to the explosion of smart phone apps in...
How has that worked in your experience?
It's been a mixed experience. Yes, I do have access to my records and can review them. It's not clear to me whether that's due to Epic or whether it's due to the explosion of smart phone apps in general, though. Doctors vary widely on how they interact with the system. I can send a message directly to several of my doctors. Some get back to me within 1 day, others take up to a week to respond. Still others never actually respond or funnel responses through a nurse that ends up misunderstanding what you're asking and misrepresenting what the doctor's response was. It's fairly inconsistent. But like I said, I've had a very difficult time correcting my records even when I do get in touch with them. Why is there no way to virtually cross something out and annotate it?
Plus, they end up wasting time asking the same questions every visit anyway. Before the doctor comes in, the nurse comes in and takes vitals, then walks over to the computer and does the, "Have there been any medication changes since last visit?" dance. You say "No," then they read each of the things in the list, several of which are wrong because of the previously mentioned issue, you re-explain the situation for the 10th time, and nothing changes. If I could go in the day before my visit, look over the list of meds and add/remove/modify them on my phone, we could skip the entire part where the nurse verifies everything. But that's not how it works, of course.
Some excerpts from the fantastic article by Atul Gawande: "... discovered that one of the strongest predictors of burnout was how much time an individual spent tied up doing computer...
Some excerpts from the fantastic article by Atul Gawande:
"... discovered that one of the strongest predictors of burnout was how much time an individual spent tied up doing computer documentation"
"the computer, by virtue of its brittle nature, seems to require that it come first [...] It’s disempowering. It’s sort of like they want any cookie-cutter person to be able to walk in the door, plop down in a seat, and just do the job exactly as it is laid out."
"Human beings do not only rebel. We also create. We force at least a certain amount of mutation, even when systems resist"
"Soon, [Dr. Neil Malhotra] and his fellow-tinkerers were removing useless functions and adding useful ones. Before long, they had built a faster, more intuitive interface, designed specifically for neurosurgery office visits. It would capture much more information that really mattered in the care of patients with brain tumors, cerebral aneurysms, or spinal problems."
It's amazing how often, the independently re-discovered solution seems to point towards convivial application of technology.
Recently finished reading Illich's book on the topic of convivial technologies, good stuff. It seems to me that the UNIX philosophy (especially its FOSS implementations) is the key to the...
Recently finished reading Illich's book on the topic of convivial technologies, good stuff. It seems to me that the UNIX philosophy (especially its FOSS implementations) is the key to the convivial application of modern computing. Building sharp, specialized tools like Malhotra & co. did is probably the only way to really make this sort of system bearable.
Fitting modern computing itself into a broader convivial framework , though, is a problem I need to spend more time thinking on.
I’m currently reading Illich’s book, and that is prompting a lot of rumination and several of my posts (recent, and upcoming). I think the Unix philosophy is double edged sword — while it provides...
I’m currently reading Illich’s book, and that is prompting a lot of rumination and several of my posts (recent, and upcoming).
I think the Unix philosophy is double edged sword — while it provides a nice collection of utilities that play well with each other, it also holds us back with their conception of unstructured text (bytestreams) as the default interface, which is often thoroughly insufficient for more structured data (eg: healthcare data).
I think conviviality is the root of the FOSS movement, but we need to think beyond GNU and Linux.
I think the Unix philosophy is double edged sword — while it provides a nice collection of utilities that play well with each other, it also holds us back with their conception of unstructured text (bytestreams) as the default interface, which is often thoroughly insufficient for more structured data (eg: healthcare data).
For all y'all wondering: the word the article should be using is "disabling", i.e. removing one's ability: one's capacity for action. "Disempowering" means "taking away the ability or the capacity...
"disempowering"
For all y'all wondering: the word the article should be using is "disabling", i.e. removing one's ability: one's capacity for action. "Disempowering" means "taking away the ability or the capacity to empower", which implies there's been empowerment there in the first place. Even then it's an odd word to pick without a strong context to justify it.
Something I can't confirm 'cause the article shuts down despite having fully loaded just a moment ago when it can't access my cookies.
Absolutely correct! I'll agree that this is the correct way, to an extent, and the way it was done in the past prior to the surge of corporate software. But the regulations in place now make doing...
I work in health tech, and by far the biggest curse on the industry is the fact that everything is so locked down. It's a huge pain to interoperate with Epic because they don't want to interoperate - they want to swallow everything!
Absolutely correct!
Open software, open protocols, and the option for in-house developers to build bespoke interfaces is the only way to ensure that the process of ossification they speak about (the "Tar Pit") doesn't occur. It's frankly ridiculous that they didn't even mention it.
I'll agree that this is the correct way, to an extent, and the way it was done in the past prior to the surge of corporate software. But the regulations in place now make doing so a difficult if not impossible proposition. When HITECH was in the legislative pipeline the physician office I ran at the time had a very open minded physician owner that was, at first glance, willing to put the software we wrote for our practice through the certification process in order to offer it to other small practices like ours, effectively, for free. It was a great idea until we actually started looking into everything required just to get certified, not including costs of developing it further so it was viable and customization for others, and it was **well into the mid six figures range. ** There simply isn't enough money in that approach unless you already have a ton on hand to risk and market to change the optics on the industry that most people don't even know exists.
Fun! This is centered in my wheelhouse, specifically I have been on both the patient facing and software side of healthcare. Presently in the latter and deal with Epic (along with every one of their competitors) on a near daily basis. So AMA if you want after I've finished my thoughts on this piece. I like to type my replies as I'm reading the article, so I'll quote a section, make a response and move on. This can result in my own responses being addressed later in the article and if so I may or may not remove them.
This, in my experience, is primarily because the software systems are following guidance from the wrong direction. Instead of the software being designed for patient care it was designed to comply with the HITECH Act; and as with any government requirement it was designed to meet the minimum necessary rules written by people that aren't in healthcare and know next to nothing about it. As with a lot of government initiatives, the idea (to have connected EHR systems so that each physician and hospital can connect together to coordinate care) was a good one, the execution was not. The Epic system, along with all others, evolved from a meet this bare minimum requirements to what it is now by taking suggestions from each hospital they've had sign on the dotted line because each one has their own policies and procedures of how they do things. This isn't something that scales well, so after some time Epic stopped making changes based on those suggestions unless it can be found to be financially beneficial to do so. Now they are so large that their system changes how care is performed instead of care dictating how the system should work. Prior to HITECH many hospitals had their own home brewed software that worked with how they cared for their patients. Early adopters of Epic had changes made that fit their procedures, later buyers are being pushed to follow those practices as they are already built into the Epic system even if they are different, less efficient, and do not fit their care model. So you have software being built by people with no healthcare experience, to meet regulations given by people with no healthcare experience, then being modified to suit the rigid requirements of the first hospitals to adopt it, and forced down the throats of hospitals that do things differently.
This is still a common issue with Epic implementations. They're big enough that they tell previous vendors, or in this case home brewed software, to modify their systems to meet Epic's import/migration requirements and refuse to allow any changes to it regardless if the old system has that data in the format desired. The outgoing software vendor is reluctant to spend any money on a contract they're losing, the incoming vendor (Epic in this case) can just point fingers at the outgoing one saying "see, they won't work with us and is obviously why you're leaving them to come with me), and the nightmare that occurs during the transition makes executives less likely to leave Epic once the contract is up and so renews it time and again. Their competitors know this and have tailored their migration systems and have staff that have worked for Epic specifically to deal with this childish behavior when a hospital system moves on from Epic thankfully.
This is a fair take. Physicians frequently will skip over "boring" bits of info that are either common sense to them but are required info for people further down the line (be it nurses, assistants, or billing departments). This keeps support staff from, typically physically, chasing down providers for needed info. Providers hate being told what to do, their entire careers are around figuring things out on their own. To be fair a lot of providers would fill this info in later, at the end of the day when there are no patients scheduled, but now they're being required to do so at the time of service (which has the benefit of being more accurate) and have patients scheduled from start of shift to end. The balance gets tipped back by these physicians finding creative ways around these required fields in order to stick with their previous way of doing things in attempts to actually treat their patients and having to work late to correct them.
A lot of this stems from broken promises. When the computerization of medical records began everyone, and I mean everyone from software providers to hospital administration themselves, were promising physicians that they'd all have an assistant to shadow them and do the data entry for them so that they could actually treat their patients. Then they'd review the records at the end of the day, make corrections, and sign off on it. That promise was fulfilled in a lot of places for a brief time and then the idea came about "Why are we paying someone to do data entry for a doctor instead of just making the doctor enter the info? Think of how much money would could make/save if we didn't have these "assistants!" and so the onus was placed back on providers. Profit rose, care suffered, the march of for profit healthcare continues.
HITECH was written with the intent of each system communicating with all other systems, agnostic to the vendor, this of course did not happen as there is no standard for communication and just that it must happen "electronically". The standard that they use today? PDF - Yep, these systems "communicate" with those of another vendor by allowing the importing of a PDF from the competitor.
This is a two part problem. Part one is the "too many cooks in the kitchen" issue. Everyone can make changes, everyone thinks their opinion is valid, everyone had different standards for how they document that info. Part two is the physician god complex, it is both well documented and in my case directly witnessed. A vast majority of doctors think they are always right and will actively reject the diagnosis of other physicians if it is contrary to theirs. Often this is only if the other physician is in the same specialty, but it will even occur across specialties.
Part of this is due to corruption, fraud, and false billing practices. Every insurance company (including Medicare/Medicaid) sends tens of thousands of chart review requests per year. These involve the provider/hospital submitting the medical record for the visit to the insurance company for review so they can ensure that they aren't being billed for things that didn't occur, weren't warranted, or didn't have all of their arbitrary rules met in order to be "medically necessary". So there's automatic copying in these systems to ensure everything is there at all times, to the detriment of quick care, to cover the administration's ass during these reviews.
Poor software optimization. Click counting is something all the good hospitals are doing now to try to cut down on this and they are including it as part of the selection criteria for new software. She has every right to be angry, ancillaries aren't to blame though, but I'm guessing this is covered later based on that last sentence.
These restrictions were put into place to reduce liability by administration. It's the typical one bad apple ruining the bunch sort of thing. You get someone that was changing records that they thought was a typo trying to help and now everyone that lightened the physician's load is locked out to keep that from happening. You get one bad actor that wrote a prescription for a friend or family member, maybe even forging the signature, and now every other competent and honest person is locked out. You get one idiot that lied about their abilities and misses a crucial lab result, filing it away instead of bringing it to the physician's attention and every other intelligent individual is locked out. Now physicians have to sign off on everything and only they are allowed to do so, causing more work away from patients, making them work longer hours, making them tired, making them more likely to miss something that administration was trying to avoid with all of this locking out.
Yep, because those cookie cutter button pushers are cheaper. Part of the Epic sales pitch is being able to allow the hospital to save money on labor costs by hiring lower paid, less skilled workers.
Oh boy! I'm going to have fun in this section tearing this inflated ego asshat a new one. I'll admit, I was starting to get bored, but I do revel in calling textbook Dunning-Kruger examples out on their idiocy.
He's a veteran of two military software overhauls. Holy shit if you think medical software is bad, try government software contracts! The hilarity is that he thinks this is a badge of pride, I wonder if he can see the sunlight with his head that far up his ass. Military software is notoriously bad, outdated, inefficient, and needing replaced the day it is implemented. Military software purchasing is a matter of favors, bribes, and politics, not efficiency, usability, or any other purpose.
He admits that he doesn't know how this works. "Not as tech savvy" is ego-speak for "I don't know shit". He gets paid to make decisions based on what sales people tell him works, not how it actually works or how the people that have to use it work.
Patient adoption rates for these systems are laughably low. They do not log in to do anything in that list. Know what they log in to do? Pay their bill. That HITECH act I mentioned earlier? It has minimum patient adoption quotas. That metric, as you can't force patients to do anything, is measured by the number of patients that log in to their "portal" which has their medical records in it. So how do you get them to log in to meet the metric and not get penalized? Put the bill paying portion behind the same log in. These systems have arguably lowered the standard of care, so they are most certainly not built "for the patients". They are built for the corporations that own hospitals to meet requirements to make the most money possible. Period.
This is a fair take. More data allows computers to catch things humans wouldn't be able to notice on such a scale. The implementation that requires all of the providers of that data to be on the same system is what makes it an overall failure.
How does he fit through the door with his head inflated by all that ego?
He was a bad leader then too. All medical professionals have to go through continuing education and are instructed to follow best practices as have been laid out by studies and their peers in journals and the like. Software has not changed that and these systems are not allowed to diagnose or tell the physicians how to treat. They can only provide links to the studies/journals for the physician to read to make treatment decisions. If a bad doctor wasn't reading them before, then they aren't going to read them now.
Last sentence is well said. This guy likes to be in control, he doesn't adapt, he doesn't change, and he's fine with that. This guy has a routine. I bet he has his morning bowel movement scheduled to the minute. The world doesn't work that way. Medicine doesn't work that way. It can't. And yet he and these companies are trying to force it to do so.
Glad to see my broken promises line earlier come around. There's a detail here in the last sentence that makes my point. This scribe had to be found at an independently run PCP practice. This doctor is willingly reducing the amount of money his practice can make by hiring someone to do the data entry so he can do his job, treating patients. Hospital physicians don't have this luxury. The administration won't allow it. And as more and more independent practices get bought out by the "hospital groups" the same occurs there. No more help. Onus on the physician to do data entry to save a buck and care suffers because of it.
Edits made to clarify one point and fix grammatical errors.
It's interesting. I don't work in healthcare, but I do a lot of work in what seems to be fairly similar industry (software security). I wonder how much overlap there is between your experiences and mine. We have been moving from a vastly more prescriptive initial implementation of a lot of these technologies to more of a user-augmented approach, where we try to be as out of the way as possible and design-flexible to the user's current needs. We have a similar userbase of overworked, strapped for time (and not always particularly technically sophisticated) users, where every minute and second counts. They have terrible technology scars from prior attempts at orchestration. They were promised that the technology (I, technically) provide would make their lives and jobs easier, often without the realization of that promise. And there are a lot of factors that drive that fraught dynamic:
Does any of this resonate with you? It seems like Epic specifically is a toxic asshole of a company that intentionally makes product decisions in the way most suited to protect their ego, but even if they were trying to play nice I think there'd be a lot of very serious problems preventing a lot of industry buy in for these sorts of products.
Not to make your response seem trivial with a short response, but in this case there's little reason to be anything other than succinct.
You hit the nail on the head with every point made.
The scale of my issue is much smaller, but this one resonates with me a lot from both ends of the problem.
From one end: My first job I was one of 3 employees and the sole developer on a massive program that was about 1/3 of my company's profit. The other two people were a project manager who also managed a couple of other projects related to mine, and a very nice engineer who was doing QA/Customer Support/UX design. A lot of times I would design workflows for data input and send it to our QA team or some customers who liked testing new features for us and they would send it back and tell me it was virtually useless. It took a lot of time for me to understand that the way I thought to solve a problem didn't matter if the users didn't like it or understand it.
Now I am on the other side of that. I am working on a project for a new company using <open source software>. First they pushed us to do things in a specific way ("technically you can do it in any way you want, but we strongly suggest doing it this way") and then the way they suggested is FULL of limitations that make the workflow basically unusable for us (and based on the github issues page, unusable for lots of people). Their response when people voice these issues? "We believe if this workflow is unusable for you because of these missing features, it is because you are wrong and should restructure things to work this way". Dude. I get the customer isn't always right. But if (a) a large number of customers are all saying the same thing and (b) The issue is something like "we don't support dictionaries or regexes", the way YOU are doing things is wrong. The singular customer might not always be right, but the collection of your user base is. I'm fed up with it to the point where I am about to move to a different software solution. The only thing holding me back is the sunken cost of 3 months of development time for multiple engineers.
Lolwut? For something like an MRI, fine. But for data? WTF? PDFs are terrible because you can't actually get any useful data out of them. They are literally a set of commands for drawing characters on the page. A single word could be broken into different drawing commands or letters could be drawn in some order other than the order you read them or type them. They are quite possibly the worst format for exchanging data (unless the data is vector drawings).
This doesn't surprise me. In the past my wife would frequently use the patient portal to get results and communicate with her doctors. I refused because most of them were run by marketing companies that were not required to be HIPAA compliant. Also, as a software engineer, I think all software sucks (and web-based software is particularly bad).
It's unfortunate because after an ER visit, I ended up downloading my hospital's app because I was too weak to call and fight with a human on the phone about something. It turned out to be incredibly useful for some things. I now see lab results as soon as they're in the computer. I don't have to wait 3 days for my doctor to call and tell me the results.
But I totally understand the feeling most users have – for years these apps have been insecure, buggy, and crappy to use. Why would any user want to use them?
You are right on all points there, but they meet the minimum of being "electronic" and "universal" and that's all they care about. There are interfaces to communicate and they have defined fields, but the data within those fields can be in all kinds of formats and so one system cannot communicate with another without ample amounts of data validation and translation tables being built which is work neither side wants to put in unless there's financial benefit.
The portals have improved because they were originally built for that minimum engagement goal and over time as other areas of the software has stagnated the companies selling to the hospitals needed to come up with new revenue streams. And so they're going back to places where they have done next to nothing and it's easier to make changes. Now, like you said, they have to convince the patients that it's no longer useless.
Thanks for the in-depth analysis! It felt to me like that's what was going on, but it's nice to have some confirmation.
Out of curiousity, do you have any experience working with kyruss? I only ask because a while back I was interviewing with them and reading about the issues in healthcare tech, their goals, and their solutions and it all sounded really interesting and hopeful. Wondering if someone who has actual industry knowledge and experience knows of them and has any thoughts.
I've heard the name in passing, but have never worked with them.
I do not have very much to contribute but I am finishing my last semester at university with a focus on UX Design. What you just described to me has convinced me to apply as I will be moving to Wisconsin. If what you are saying is true, if I’m able to work on untangling that mess, I would be able to help doctors with burn out, speed up processes, and provide patients with a better healthcare experience. That sounds like a goal I am very much down for.
Thank you so much for this write up!
Most of the hospitals around here use Epic. As a patient, I despise it. My doctors used to come in, look me in the eye, talk with me, and take some notes. Now they come in and say "Hi," then turn to their computer and look at the screen the entire time. It's very off-putting.
But what's worse is that they can't enter the information I give them correctly. For example, I have an allergy to almonds. But somehow it got entered as being an allergy to "almond oil." Likewise I have a medication that I inject, but the system says I'm using a trans-dermal patch. I've gotten them to correct some of it, but for some of it, they tell me they can't change it, or it's too hard to change. I'm like, this is my health and safety we're talking about. I don't want to get a bad treatment because their software was too crappy to record the correct information!
In case you were worried, Epic is widely despised by doctors and other medical professionals, as well (though most of their competition is apparently significantly worse). But really, most of the issues with it are a symptom of the state of healthcare in the US. Electronic medical record systems aren't a patient care tool; they're a billing tool, meant to record billable actions in a format insurance companies find acceptable, and any benefits to patient care are incidental.
They're also not popular among decent amount of people who live in the Madison area (where they're based). They're one of those companies that acts super cool and fun (and tbf the architecture of their offices is incredible) but people who work there get worked to the bone and aren't treated very well outside of perks like the in-house cafeterias and stocked fridges. I wouldn't work 60+ hours a week for any amount of money.
Thanks for chiming in. One of the people (doctor+administrator) in the article claims that a significant benefit of these software systems is patients being able to look over their records, offer feedback, and get explanations. How has that worked in your experience?
In principle one should be able to complain to “Epic” about this, but in practice, the process of trying to get to a person in a large corporation making enterprise software can unfortunately feel Kafka-esque.
If it bothers you enough, maybe start a thread on Tildes where other people can chip in with their experiences. Maybe collectively there might be enough ammunition that folks get energized to act on it.
It's been a mixed experience. Yes, I do have access to my records and can review them. It's not clear to me whether that's due to Epic or whether it's due to the explosion of smart phone apps in general, though. Doctors vary widely on how they interact with the system. I can send a message directly to several of my doctors. Some get back to me within 1 day, others take up to a week to respond. Still others never actually respond or funnel responses through a nurse that ends up misunderstanding what you're asking and misrepresenting what the doctor's response was. It's fairly inconsistent. But like I said, I've had a very difficult time correcting my records even when I do get in touch with them. Why is there no way to virtually cross something out and annotate it?
Plus, they end up wasting time asking the same questions every visit anyway. Before the doctor comes in, the nurse comes in and takes vitals, then walks over to the computer and does the, "Have there been any medication changes since last visit?" dance. You say "No," then they read each of the things in the list, several of which are wrong because of the previously mentioned issue, you re-explain the situation for the 10th time, and nothing changes. If I could go in the day before my visit, look over the list of meds and add/remove/modify them on my phone, we could skip the entire part where the nurse verifies everything. But that's not how it works, of course.
Some excerpts from the fantastic article by Atul Gawande:
"... discovered that one of the strongest predictors of burnout was how much time an individual spent tied up doing computer documentation"
"the computer, by virtue of its brittle nature, seems to require that it come first [...] It’s disempowering. It’s sort of like they want any cookie-cutter person to be able to walk in the door, plop down in a seat, and just do the job exactly as it is laid out."
"Human beings do not only rebel. We also create. We force at least a certain amount of mutation, even when systems resist"
"Soon, [Dr. Neil Malhotra] and his fellow-tinkerers were removing useless functions and adding useful ones. Before long, they had built a faster, more intuitive interface, designed specifically for neurosurgery office visits. It would capture much more information that really mattered in the care of patients with brain tumors, cerebral aneurysms, or spinal problems."
It's amazing how often, the independently re-discovered solution seems to point towards convivial application of technology.
Recently finished reading Illich's book on the topic of convivial technologies, good stuff. It seems to me that the UNIX philosophy (especially its FOSS implementations) is the key to the convivial application of modern computing. Building sharp, specialized tools like Malhotra & co. did is probably the only way to really make this sort of system bearable.
Fitting modern computing itself into a broader convivial framework , though, is a problem I need to spend more time thinking on.
I’m currently reading Illich’s book, and that is prompting a lot of rumination and several of my posts (recent, and upcoming).
I think the Unix philosophy is double edged sword — while it provides a nice collection of utilities that play well with each other, it also holds us back with their conception of unstructured text (bytestreams) as the default interface, which is often thoroughly insufficient for more structured data (eg: healthcare data).
I think conviviality is the root of the FOSS movement, but we need to think beyond GNU and Linux.
Thank you for saying that. Fully agreed!
For all y'all wondering: the word the article should be using is "disabling", i.e. removing one's ability: one's capacity for action. "Disempowering" means "taking away the ability or the capacity to empower", which implies there's been empowerment there in the first place. Even then it's an odd word to pick without a strong context to justify it.
Something I can't confirm 'cause the article shuts down despite having fully loaded just a moment ago when it can't access my cookies.
Absolutely correct!
I'll agree that this is the correct way, to an extent, and the way it was done in the past prior to the surge of corporate software. But the regulations in place now make doing so a difficult if not impossible proposition. When HITECH was in the legislative pipeline the physician office I ran at the time had a very open minded physician owner that was, at first glance, willing to put the software we wrote for our practice through the certification process in order to offer it to other small practices like ours, effectively, for free. It was a great idea until we actually started looking into everything required just to get certified, not including costs of developing it further so it was viable and customization for others, and it was **well into the mid six figures range. ** There simply isn't enough money in that approach unless you already have a ton on hand to risk and market to change the optics on the industry that most people don't even know exists.