I created the ClearHealth/HealthCloud open source (GPL) EMR which to my knowledge is the only open source one to receive full federal certification. Operations (not surgery) are so incredibly bad / incompetent in most healthcare settings that software frequently gets the blame for much deeper problems. This article is a doctors perspective on how software did not fix a completely broken workflow. I don't begrudge him that but there is no software in the world that can ever address those types of problems. In my experience doctors are a tremendous barrier to resolving problems in healthcare operations, they are chasing their own incentives that are in some ways opposed from those of the patient just like the insurers are. It is very tortured process to institute proper operations in a medical setting, I spent most of my career doing it, no one complains about the software when operations make sense to begin with. In-N-Out instead of McDonalds, is something that should be incredibly aspirational to healthcare as an industry but doctors tend to despise the comparison.
"Operations (not surgery) are so incredibly bad / incompetent in most healthcare settings that software frequently gets the blame for much deeper problems."
"In my experience doctors are a tremendous barrier to resolving problems in healthcare operations,"
I'm a hospital-based physician that works in a system with great operations and results. The physicians, nurses and other staff work amicably together. Management is reasonable/nice. The EMR, though is universally despised. No one likes it. It is a major factor in burnout. The UI/UX is inconsistent. There are slowdowns and outages daily. There is a well known lag in the appearance of text in text boxes after typing that seems to be variable. I've caught the EMR cancelling orders I placed on critically ill patients in the ICU more times than I can count. We have to actively protect the patients from the EMR. Healthcare workers aren't perfect but they are trying to do their best for very ill people in a high-risk setting and the EMR is well-known blocker. I long for the days of paper records because this is worse. Paper charts didn't go offline, have slowdowns, didn't lose orders, were easily located, and easy to enter data into.
As someone who worked at a fortune 500 company making such EMR software:
There's no incentive to make the UI or workflows better. They don't pay the bills. Software is sold to the suits during dinners and baseball games, not doctors or nurses.
Besides, a great portion of the development is outsourced chasing lower costs. The code reviews were so bad that a coworker used to joke that "we'd get more stuff done if we just fired the overseas team".
The biggest and most well funded dev team was the one that worked on Revenue Cycle.
I worked on EMRs for 20 years. I recently quit that sector completely, and I wish I would have done it sooner.
Almost all of the features/fixes customers are actually begging for (the most popular categories being speed, reliability, reduced cognitive load and UI/UX streamlining) get dumped into the bottom of the backlog to languish. All the board and leadership care about is RCM, stupid ancillary services that patients do not give a shit about but look good in a sales brochure and have a high margin, chasing incentives from insurance and pharmaceuticals, cost cutting, and last minute, bare minimum regulatory/interop work necessary to not lose our ONC certification or violate HIPAA. Patient care and staff happiness just don’t rate that high. EMRs and the people who buy them are purely profit motivated.
It was humiliating watching how angry our customers rightfully have been and knowing there was nothing I could do about it. Now that almost all of our founders, product owners, and SMEs are gone and they just fired all but 7 engineers so they could offshore development to a company we haven’t worked with before and who has no experience with healthcare, our customers are going to be in absolute hell. The sad part is we don’t seem to be an exceptionally incompetent outlier but fairly typical of the industry.
I agree. I also worked on EHR software and what people don’t realize is that the “customer” isn’t the doctor. Not to be disparaging, but the doctor is “just” an employee.
The purchaser of the software is the administrator. And because of harsh regulations and legal liabilities in their industry, they need software that is compliant with regulations and limits legal liability on the institution. Full stop. If they can get that with a good UI/UX, then great! But in the end, this is just another case of “No one ever got fired for buying IBM”. It is all about incentives.
Companies like Epic could make their UX better, but that costs money. And what drives sales is being regulations compliant, and that is hard. It takes a ton of time. There is little time left over to make something work well considering no other software is challenging them on that front. It really is a situation of regulatory capture.
EHRs almost universally suffer from usability problems. people actually love having their medical records available. They hate the UX they have to go through to see them.
The source of the problem is that the people deciding which EHR to use are almost never the people using it. it’s ultimately the CFO or CEO who’s ultimately going to make the call, and they do it based on metrics like price tag or how many accreditation checkboxes it fills, not on user satisfaction scores. Until those user satisfaction numbers make it into CMS guidelines for reimbursement, the situation’s never going to change.
"The source of the problem is that the people deciding which EHR to use are almost never the people using it. "
Yes, this. We are a Cerner (now Oracle, yaaaaa) site, not Epic. The Cerner folks I've met in smallish meetings are nice/great on the front lines. However, the deal that our CEO/CFO/COO/CMIO made with Cerner was years ago and, per rumor, involved large financial penalties for early cancellation. Subsequent people in those roles have chosen to uphold the contract. The local management and healthcare teams in my particular facility are great but I take a dim view of our c-suite as do the majority of the work force. Things are reasonable locally for most people, I think, except for the EHR.
So, I would plead with leadership teams of EMRs, EHRs, healthcare systems, and shareholders of these entities to do the right thing and give healthcare workers working in high-risk settings the proper tools they need. You are currently failing us. No one wants unreliable, difficult software installed in critical settings such as ICUs.
I've submitted tickets, emailed leadership and had conversations with the CMIO. If there is improvement it is so slow that I cannot discern it.
In anecdotal conversations over the years I've observed that the vast majority of healthcare workers hate all EMRs but give Epic the nod because it is the least worst, and for some, reasonable. I have met a few Epic users that are enthusiastic about the software but that is after they arrived at our Cerner site and were in shock.
@duffpkg - my original comment was under yours and I wasn't intending to malign your project. I'm not familiar with it but do like that it is open source.
Respect to the developers that work on EHRs. I recognize you are held down by management.
I'm perplexed by UX/UI problems in EMRs. This must cost more to fix than I suspect. It seems to be the easiest of the issues from my layperson/healthcareworker/tech-enthusiast viewpoint.
One more thing to add: an effect of bad EHR is healthcare worker burnout. Bad EHR is a known contributor. Burned out healthcare workers are at increased risk to make medical errors. Bad EHR -> burnout -> errors -> adverse outcomes. This is a well known flow to us in the clinical setting that we attempt to mitigate. The executive teams of orgs that produce or purchase EHRs are never held accountable for bad outcomes even though, to my view, they share responsibility.
Edit: government regulators (CMS, etc) also share in the blame for bad EHR and outcomes.
This is a much easier fix in Cerner. I would guess based on the limited information at hand there is something wrong in the setup of the order release rules. IT should hire a Cerner specialist and the problem should be able to be resolved in days/weeks.
As someone with a similar working background, I agree, in fact, I wanted to share this same exact sentiment. The software is shit, and everyone knows it how it's shit, and the reason is that the incentive is not there to make it not-shit. The main users, and the people who they record, are not the main concern in these systems. That is why everyone feels bad while using the software. It's not about them, it's not for them. It's not even against them - it just doesn't care. And this really radiates from the UX.
This is so broken and depressing. I had a tour of the EMR system being used in my jurisdiction and it was shocking how bad the UI/UX was. The scenario you describe is exactly what I imagined.
As a software developer I feel so motivated to fix it, I know a small team could do a better job. But I don't even know where to begin to try to enter that industry.
It's not just EMR, it's just capitalism in general. Everything is about squeezing the most value out of the least budget.
If there was a way to factor in costs due to downtime, poor usability, anything like that, might be able to push back and bake some of that in to begin with... but even that is a can they'd kick.
I totally disagree except to the degree the provider is broke, close to broke in which case capitalism can yet help. When you're worried about money one may manage for money the exclusion of all else. It's a distortion only not a counter argument for capitalism.
The issue, ultimately, is crappy management. The need for, the good outcomes that could be achieved profitably, are insane in possibilities. Many country's demographics now include a lot of retiring people.
I continue to think basic TQM (which has gone out of vouge unfortunately) would help a lot.
Look at psychology in the US: a lot of providers will not even get involved in the insurance side of the equation. Patients pay cash. The patient is stuck with the insurance and re-imbursement, if they can figure it out.
The supplier side --- medicine and insurance and to some degree politicians --- made the paperwork system extremely bad. Simplification and elimination have got to be on the table.
Part of the problem is the patient is dis-intermediated The supplier deals with insurance directly --- hospitals in the main:
* the supplier can bill the patient's insurance wrong, for the wrong procedure, for stupid high amounts, and so on. The patient is not empowered to push back on that because the patient doesn't hold the checkbook
* hospitals and outpatient stuff like MRIs etc. don't publish a price list for the patient. Granted this is changing slowly. But why has that taken so long? Because the patient doesn't have the checkbook so why bother? Payment is done out of sight between the supplier and insurance company. It doesn't matter what the customer thinks.
The stuff where capitalism works better is when the customer knows the price, the supplier has no choice but to be upfront about it, and the customer will fire the supplier, refuse payment, or dispute payment for crappy supplier quality. The supplier can't get payment no matter what if the customer isn't going to provide it. Conversely, the supplier can refuse service for bad customers. This way both parties are encouraged to act smartly.
If I could wave my magic want I'd like to see a scenario in which,
* Customers pay insurance premiums to insurance companies in return for a bounded amount of access to a cash account.
* The customer must deal with out-of-pocket and co-insurance to eschew abusing the insurance company, fraud, and feckless spending. There must be bounded access to cash so the customer prioritizes what needs work and what doesn't.
* The supplier presents the customer with an itemized bill
* The customer --- and only the customer --- pays the bill electronically to the supplier through the insurance company's B2B payment system.
* Patients must get involved in, and start owning up the fact they can't refuse to take a zero on the dollars and cents of the care they're getting.
>biggest and most well funded dev team was the one that worked on Revenue Cycle
> no incentive to...
I am working hard to not build and fuel a fully loaded Boeing 787 into high-earth orbit and crash land it on the not-my-problem, told'ya, it's all corrupt-all-the-time, MONEY! money-is-the-measurement-of-all-things, it's bad-here-so-I-left city center fecklessness of it all.
Toyota at its peek performance (say late 1980s) was making king-kong sized money top and bottom line. No manager would ever say their only incentive or even primary care is cash. "Our only incentive is walk around with cash. Cash in the hand, cash in the brief-case, cash in the pocket, cash on the boss' desk. Show me the cash." has never spoken in companies knowing about TQM.
Instead there were aware of the numerous cross-cutting factors that, in net, determine what kind the money the company can make
Maybe medicine cares about cash so much, because it's broke or close to broke all the time. Hmmmm.
There are ton's of great incentives for the docs, the nurses, the customers, and the company's top/bottom-line to name just a few.
Somehow, someway, one day, one time management will have to get sick and tired of the on-going mediocracy. And until then I guess medicine doesn't suck hard enough. Eventually, like in Voltaire's Candide, they'll have to get into lockup, when the lady in the other cell says (paraphrasing): "You think that's bad? Big deal. I only have one ass-cheek" and goes on to tell a serious tale of woe. We're not sure yet if medicine is the one-cheeked lady, our Candide and his charges in the other cell. Only time will tell!
My extended family:
* runs several hospitals in the US
* owned a radiology business w/ multiple branches for a while
* worked at major city trauma care university hospitals that eventually went bust and had to stop operating
A few things I can tell you about them when we spoke about how the US does 16% of GDP on medicine with its high costs, and sometimes poor outcomes in what should be routine stuff,
- On the people: doctors, and nurses love to help and can be counted on same. Wonderful people.
- They did not tolerate quitters
- Good incentives (carrots) and incentives for dumb (sticks) are not per-se key, but rank in the top 10 with several other things to right the ship.
- Crummy hospitals run by crummy people (esp admin, senior staff, and management) that can't even break even can't help patients, because the unit has to close. There was serious contempt for anything contributing to that eventuality
- They tried in some cases to focus on process improvement, and process simplification instead of more automation for crummy processes.
- They were at times despondent about the sectionalism and the fact that software is too compartmentalized by discipline because the IT stuff often came from vendors that could have some integration but certainly not enterprise integration.
One of the biggest scandals in Norwegian health care at the moment is a botched transition to Epic in one of the biggest university hospitals. Doctor dissatisfaction has gone to the roof at the point where 50% of the doctors are considering quitting.
Maybe they are different versions, or I'm an outlier, but I love epic - I used a relatively new build of the software last year for a new months, just the ability to message other staff in the context of a patient's chart saved huge amounts of time and interruptions. They also had this super low friction way of addending to the chart, so you could, say, review a (paper) ECG and start recording your interpretation straight into the correct chart within a second or two, and be done in around 10 seconds (with dicatation software which is usually from a different company but integrated)
I'm assuming the hospitals in Norway & Finland used some form of a public tender where the cheapest solution wins. I don't think you need malice or corruption to explain it, just good intentions.
There's malice on the sell side. If they can't integrate a trial period then its not worth attempting. Its dumb terminal work not like its actually expensive just very very lucrative because its run like a mafia.
Exactly, when selling a big software system like this to the government, the contractor will very deliberately ensure that it follows the requirements exactly (because requirements are never specific enough) so that the government will then have to go back to them for fixes and upgrades forever. If they see a poorly worded requirement that they can implement as-is knowing it will cause a problem, they celebrate because its a future revenue source.
The only way I can see to avoid this is for a government to have its own dedicated software developers who make these types of applications and maintain them. Preferably open-source so that other governments can use them as well. The incentives change and they'd probably save a ton of money.
If they don’t implement that poorly worded requirement, they are entering a world of pain of having to justify the deviation through 10 layers of project managers and qa, all from different organisations (either customer or other contractors). And at the end they’ll be the troublemakers who delayed the milestone
This is also true I don't doubt, but I've heard directly from contractors that they look for requirement holes so they can monetize them to the maximum extent possible.
Having a dedicated developer team who work directly for government whose sole job it is to make and maintain software like this for the long term, still seems like the most cost-effective and durable solution.
Given the nature of EHR systems, it's just not realistic to have trial periods, because everything in a hospital is interdependent. Even the relatively small system I worked on did everything from billing, accounting, insurance, HR, inventory management, scheduling, integrations with medical equipment & third parties (e.g. national health systems) with per-speciality workflows and other automation. Most of it isn't even strictly health-related.
Migrating one way is already a multi-year process, making it potentially two-way with low-latency data consistency for the duration of the trial sounds impossible.
In an ideal world, the system would be modular and you could evaluate it piecemeal, but none of the big players are incentivized to make it possible. The standards that do exist are also very lax and legacy systems don't even support those. Something like a goverment intervention is probably required to break this stalemate.
> none of the big players are incentivized to make it possible
Yea this is the problem. When well meaning startups attempt to make change they get acquired by a piece of shit sales behemoth. If somehow one could resist the acquisition and just eat everybodies lunch we'd all be better off.
The only way change will come is if some actually independent hospital develops open-source in-house software (under the strongest possible non-cooption license available, likely GPL3) over literal decades until it becomes a standard.
It’ll be fought every step by the entire healthcare industry.
I don't think there is such a thing as an actually independent hospital anywhere. In most countries, the medical system seems to be a government monopoly. In America, it is an oligopoly that egregiously violates the anti-trust laws and whose real customers are the government and the health insurance companies.
The entire industry seems like a politically connected bureaucratic nightmare of one kind or another in every country on earth. Solving that problem would require some way to allow doctors to become genuinely independent again[0] and to ensure that patients could choose their doctor. If doctors were genuinely independent, they would choose the best medical records software and that software would be able to open up files from competitors[1].
[0]: The main American blocker to this would be something called malpractice insurance which is extremely unaffordable and necessary to protect doctors from being bankrupted by lawsuits whenever they make a mistake. Hospitals can afford that insurance much more easily than independent doctors so they can basically buy up all the doctors. I suspect that an affordable public option for this insurance would help restore a competitive free market in medicine.
[1]: I've heard first-hand from family members that the file formats for the different medical records software are incompatible. They convert medical records by actually typing the information from the other hospital's system into their system.
Interestingly your [1] citation may no longer be the case. The 21st Century Cures Act was signed 8 years ago (but compliance was only required as of 2023). It states that Healthcare Institutions (& EHR developers) must provide a mechanism for patients to access their health records electronically in a standardized format (FHIR).
It's what allowed my open-source startup Fasten Health to even exist. I was diagnosed with a chronic condition, and wanted a way to store my health records privately on my own devices. A bit of luck and a POC later, I was able to confirm that patients can access their own records with little-to-no barriers.
Medical malpractice insurance has only limited economies of scale. It's still possible for solo practitioners or small partnerships to afford in most cases. This isn't the biggest factor in driving provider market consolidation.
The real factors driving consolidation are IT costs, negotiating power, and practitioner preferences. Even with modern SaaS products it's expensive for a small organization to operate an EHR and other IT infrastructure. Payer organizations have consolidated through M&A activity and are constantly trying to drive down prices so providers also consolidate to force payers to keep them in network regardless of prices. And many doctors just don't want to manage a small business; they would prefer to focus on treating patients and collect a steady paycheck.
Your family members are wrong. There are standard file formats for sharing medical records across different software. The most common format is HL7 Continuity of Care Document (CCD) which can accommodate an entire patient chart in a single XML file. Every major EHR has supported CCD export and import for years under federal government certification criteria. If your family members had to do manual data entry then either their software wasn't configured correctly or they didn't know how to use it.
In my experience with FHIR, two documents from different sources can both be compliant while still semantically incompatible. The protocols are made flexible enough where human ingenuity lets you represent the same thing in so many similar, yet different ways.
That's why most interoperability requirements are written based on Implementation Guides rather than baseline standards. The base HL7 standards (V2 Messaging, CDA, FHIR) are intended to do pretty much everything everywhere in the world. As such, they're loose on specifics such as required data elements and coding systems. Then IG authors take those baseline standards and constrain them for specific use cases in particular countries (realms).
CCD is very well specified, although you might still find some EHRs that fail to comply with the standard in some minor ways. There is a project underway to migrate that data model to FHIR encoding but it's not finished yet; that will make document construction and parsing a bit easier but won't necessarily address compatibility issues.
In the US malpractice insurance is mostly orthogonal to the costs of health care. I hate having to write the check every year (my wife- a pharmacist- needs this insurance just like doctors do, though it doesn't cost as much because suits aren't as common) but it's really just an annoying drop in the bucket. You can tell this because some states (most prominently, Texas) have put caps on malpractice pain-and-suffering payouts, and they don't have lower medical costs, in fact parts of Texas are some of the most expensive in the country. So if malpractice isn't driving it, what is?
As far as I can tell, the real reason for the costs are consolidation. In my wife's world, independent pharmacies are being killed by PBM's(1) which literally set reimbursement rates for the small guys at below the wholesale cost of the medicine. The user experience here is you go to an independent pharmacy, you hand them your script, and they run the script through their computer systems, then say "Sorry, I can't fill this for you, because it cost me more than the insurance will pay me" and then you have to go to one of the big three which have enough market power to negotiate with their PBM's for higher rates (and even here PBM's routinely end up at least temporarily dropping one of the big boys as part of their hardball negotiations with each other).
There are basically three PBM's for the whole country, they have enormous, basically monopoly power (80% of the insurance market), and if you are a small shop your rates are crap. So the small pharmacies close/sell out and the big three drug stores get bigger. And that is happening in medicine as well, as I understand it, though I haven't seen it from the inside.
The core idea behind the ACA ("Obamacare") was that clear competition from insurance companies (and medical providers) through the exchanges would lower the total costs of health care, and it doesn't seem to have panned out, because there hasn't actually been much competition, instead there has been massive consolidation. Most counties in the US don't actually have much competition on their ACA Exchange(2), and most counties don't have much competition from medical providers either- they've all consolidated to get better rates from the insurance company- so you have monopoly insurance and monopoly providers competing with each other to see who gets more rents, not trying to compete on lowering costs.(3)
3: This is why many Democratic health care wonks are looking more seriously at single-payer over the past decade. If we in practice have unchecked monopolies dominating health care, let's at least have them be government run and therefore responsive to something, even if it's just politics it's still better than the alternative.
"Healthcare" is such a big term that covers so many things that really should be broken out separately so that it can be seen what's what.
Most people really only care about the amount of the insurance deduction, co-pays, and care availability; they don't know or care about the "behind the scenes" details.
The consolidation has been absolutely phenomenal in the last twenty years, and digging into exactly why each town could have an independent hospital and staff 20/30 years ago and why they're all being consolidated now.
So government intervention didn't do what it claimed, in fact the opposite, and the solution (per "Democratic health care wonks") is to...have more government intervention? The leaches didn't work to help your diabetes, so we should apply more leaches?
Things are far better than they were before the government intervention. The consolidation had started happening before the ACA was passed (e.g. Bill Frist and Rick Scott both became rich enough to be senators thanks to hospital consolidation in the 1980's and 1990's), and now that there are regulations the individual insurance market is passable rather than the continuous death spiral that it was in before.
And of course as I didn't say in that message but is obviously true, the ACA has led to far more people carrying health coverage than before. It's just that instead of the exchanges, it's the Medicaid expansion that has led to this. Even with Robert's unprincipled last minute rewrite and the 10 states that are still allowing their rural hospital system to be utterly gutted rather than giving Democrats the win, a higher percentage of people have health coverage than at any point in American history before the ACA, and that is entirely because of Obamacare. So that is why reinforcing the successful part (government insurance) and abandoning the failed part ("market reform") is so attractive.
The problem is that the health care market isn't a truly free market. Uwe Reinhardt, Princeton economist, wrote a lot about how it was a broken market, which is why every other developed country (including fairly libertarian states like Singapore and Chile) has significantly more government intervention than the US does- since it's not really much like a free market, unless you are willing to accept many, many more deaths for people like my mother, which I am not.
You can't just build your own EMR and call it a day, unless you are very selective of your patients.
Accepting Medicaid and, if memory serves, Medicare requires using a certified EHR/EMR system, and getting that certification is both time consuming and expensive.
You aren't just fighting the healthcare industry, but also well-intentioned government regulations.
And yet the system is aimed at getting the cheapest possible bid? Perhaps the intentions are good, but the execution is horrible. So maybe not malice or corruption, but incompetence.
In Finland the tender was between Cerner and Epic. Because our largest hospital district wanted to buy American eletronic medical record system. I guess the biggest influencer was Kaiser Permanante (=they are world class and are using Epic, so it has to be best system in the world)
I know that devs that work on EMRs might read this thread. I'm pleading with you to take the EMR to the next level when it comes to UI/UX and reliability.
I've managed large enterprise health organizations across multiple sites that use Epic. We built an adjunct system that is still used by some of them that papered over serious problems that doctors using them never knew wasn't only Epic. We defined, documented and tested real world workflows before we subjected patients to them. There are a lot of other ways to address those issues operationally. You have management, IT and operations problems, not software EMR vendor problems. No software is perfect, Epic less perfect than most. Your facility chose that system and decided how it was implemented in a way that is dangerous or potentially dangerous to patients. No software vendor can fix that. That's really the heart of my rants in response to this article.
I built that EMR, it was/is called ClearHealth/WebVista/HealthCloud. Your facility would never have bought it because incompetent management will only buy Epic. We solved the problem by buying organizations and replacing the incompetent management.
Webvista and HealthCloud are still utilized by some facilities and maintained as an internal system. EMR as a standalone line was <10% of ClearHealth's business when it was acquired in 2017, I remained involved in some capacity until 2019. ClearHealth's main business was as medical/hospital management company.
That, my friend, sounds a lot like The Cat Ate My Source Code [The Pragmatic Programmer]
Price, lead time, quality, (and scope) — pick any two. When the stakes are high, don't rely on your manager to pick quality — that is your responsibility.
And if you can't convince your "boss" to give you enough time to deliver something that meets your bar, quit.
> if you can't convince your "boss" to give you enough time to deliver something that meets your bar, quit.
I did this and while it solved my moral dilemma it made things worse for our users.
Many years ago I started my career working for a startup that got bought by a big government contractor. The most incredible people I've ever worked with tried harder than you can imagine to deliver reliable, usable software for the American taxpayer that met the very high bar we set for ourselves.
Because the incentives weren't aligned, most of the good people eventually quit to work at places where they could deliver something that met their bar and were replaced with junior devs and senior clock-watchers.
Every good person who left made that problem slightly harder for those of us who stayed because there was one less person fighting for quality and usability, but the contracts were as big as ever and the new people were less likely to rock the boat so management didn't care that product quality was dropping off a cliff.
In the end it was primarily our users who suffered.
> [--------] didn't care that product quality was dropping off a cliff.
fill in the blanks! it's not management, it's the customer. if the customer doesn't care management doesn't care.
it's a tragedy, but it's what it is. citizens as users need to demand better. it's just politics. in the end revealed preferences show that users don't care that much. they learn the shitty system to do their thing, and then they go home to their family/dog/MMORPG/life.
and users don't care on the meta level either, to have better procurement processes.
You're right, management was simply the messenger relaying customer priorities.
I will point out that enough consumers are willing to pay for a quality products that many niche companies exist to serve them. Many citizens choose to move to countries/states with better services even if they have to pay higher taxes. There are employees who reject higher-paying jobs that require interacting with poor-quality software or processes. (I work for a niche company that makes and uses high-quality products in a high-tax / high service state so I know many people like this!)
> citizens as users need to demand better.
I get what you mean, but as you point out many people's revealed preferences show that they don't actually want quality in which case they already do "demand better" -- it's just that for them "better" means cheap, fast, and convenient.
> [..] were replaced with junior devs and senior clock-watchers.
That is a sad story indeed.
I guess the silver lining is that you didn't waste your talent contributing to a mismanaged project. Hopefully, given a free market, the service will eventually be replaced by something better.
I don't regret the decision but I do feel a little guilt for what I left behind.
I have friends who moved out of struggling towns and states who describe similar feelings about being part of the "brain drain" death spiral that is hollowing out the place they grew up.
> Hopefully, given a free market, the service will eventually be replaced by something better.
I too believed that something like that would happen eventually but their business is still booming. In the decades since I've learned that the "fitness function" of companies that serve governments or large enterprises do not reward product quality (at least not commensurate with the cost of quality) so companies or teams that insist on wasting effort making quality products do not survive. It's not malice or incompetence, it's just a survival response to misaligned incentives.
Felt the same when saying goodbye to my colleagues, stranded in a golden cage, when the startup we worked for was acquired by Oracle after 8 years. Our beloved product was eventually killed (years after I resigned), but Oracle — despite its obvious mediocre halo — is still alive and kicking.
This is a fair point. If the only agency you have is the choice between following marching orders without questions, or unemployment — don't quit.
But I would be surprised if this is the way all EMR software is built. Software development being a creative process, there should always be a feedback loop where managers ask open questions. There lies the agency to recommend spending more time and money, reduce scope in order to guarantee a level you feel comfortable with. You may not get what you bargain for, but it's up to you to decide if it's enough.
Taking the money in return for doing the work is a way of telling your boss you're on the same page. Given your medical context, that may not mean you fully agree, but it evidently means you accepted it.
And then we have about 90% of working sw devs quit tomorrow - it sounds great but people are not going to leave when they know the next place is basically the exact same.
I beg to disagree. Although I've only worked for European and US companies, my experience is that even bossy bosses appreciate quality design and understand that lack of time, pressure and exploitation cause products to degrade. But pressure can only exist if there is an equally opposing force — you, me, us.
If my recommendation to bluntly quit sounded harsh, I'm happy to tone that down. There is value in compromise, but just make sure your voice is heard, say no if you cannot / will not do it in such little time to the extent that you feel is required. Fighting for the time to do our job well is our struggle. Sometimes it's easy, more frequently it's hard, but when it's simply impossible — have your boss find someone else.
Quality — at least internal quality — is primarily the responsibility of the software developer, not her/his boss or some QA department.
I don't think it sounds harsh, and I have worked with dozens of tech companies and directly for a dozen or so - the only one that wasn't obsessed with cheating out on quality to make a buck was bilking his customers so much that he didn't care.
At every phase of the conversation is management saying they have this hard deadline and
I have been fired multiple times for being too vocal about the failures of process or technology, though mostly I just get ghosted for pushing back when things are unreasonable, at this point I exclusively go for visualizations, gantt charts, etc - to communicate that the timelines are not possible with the current investment in the team/tech/whatever.
I just got laid off for (as far as I can tell) being the person who kept asking the question about why we were doing a thing that provided no technical or business value for a year, and in most of these cases some exec thinks they know best because they read some magazine equivalent that tells them this is the new hype revolution.
Basically if you can find some highly skilled or highly profitable company that's concerned about losing their edge you might be able to do this, but your next boss might change the entire equation.
If you quit, they'll just hire someone who's willing to do the crappy stuff. As a bonus, they'll probably pay less for that person. Or they'll spread the burden over the remaining staff. Or they'll outsource the whole team to some remote hell. Quality is not a bottom-up thing, everybody has to be in on it.
Most management will exchange quality for quick gain whenever they can because they're there to make money and don't plan for long term. Because they can also leave the ship when the sum of their mistakes starts to sink it.
> Quality is not a bottom-up thing, everybody has to be in on it.
I like it. But I've seen at least one place (a start up) where (to some extent) quality was a bottom up thing. Eventually it became a share value, but it was rooted in developers saying: No, we need more time.
On the other hand, I don't know of examples where quality was forced top-down — places where a senior developer would say: I'm done/I don't care/this is good enough and their manager telling them to spend more time on a feature or teaching them about software design.
Ah yes, rogue quality enforcement, I've done it too. It's all fun and games until some nosey manager questions the overeager developer who naively lets them in on the scheme and thus exposes the whole team for the bunch of non productive rebels that they are and then it's back to square zero.
Quality conscious management doesn't impose strict rules themselves but rather maintain a climate of mutual trust between business and technical where constraints and problems can be surfaced, discussed and addressed openly. Respect for technology is sorely missing from the business class curriculum, yet so much depends on it.
This is the underlying issue for anything where software isn’t the primary goal. Nobody wants to change their workflow that they’ve trained over years, no matter how absolutely broken and absurd it might be.
This sounds a lot like Epic. Respectfully I don't understand how your facility can face those issues with a system like that and also be considered to have great operations and results. With Epic it is possible to workaround a lot of notorious problems but management has to understand and have in place the operational capacity to do it. If a system is allowed to persist in an organization that may have or actually did result in patient deaths in the ICU and it was up to me I would see the facility shuttered until that got sorted out.
I also want to be clear that doctors are not by any means the only obstacle to resolving workflow problems. You being put in a position to protect patients from a business process of the facility that may accidentally result in their death is the literal definition of incredibly bad / incompetent operations. That software didn't magically appear and become responsible for ICU ordering magically on it's own. In this instance whatever insane people have been given responsibility for that implementation are responsible.
After consideration, this comment from a doctor, in a nutshell encapsulates so much of what is wrong. A doctor on the front lines alluding to staff burnout, thinking that people almost or actually dieing because orders are being cancelled inappropriately in the ICU is somehow "a software problem", while simulatenously praising the management, operations and results of their institution. Welcome to healthcare.
Are you saying that the cancelled orders are due to a management decision/policy, and not a software bug? Or that EMR wasn't intended for managing orders and the decision to use it in such a way was wrong? Asking as someone who's mostly unfamiliar with this.
Edit - I'm trying to make sense of this thread, and it seems like this might be a reasonable summary: There's good and bad software (epic). The fact that management chooses epic instead of good software makes it a management problem.
@hyponatremia121 says that EMR software (epic) is terrible, which doesn't contradict the above. @hyponatremia121 pleading for EMR devs to focus on UX might be misplaced since their only experience is epic and not better EMR software.
@duffpkg saying that epic shouldn't be blamed here seems overreaching. If epic were good/hard to misuse this conversation wouldn't happen in the first place. But there's always well marketed terrible software, and I agree organizations that aren't able to avoid this do have organizational problems.
I am lacking all the information as to whether we are even talking about Epic but Epic is a lousy tool. It is still just a tool though. For the unititiated Epic is not some tiny little software program to manage an ICU, it's a city scale platform to run most of a hospital city. You can do a lot of good things with it and a lot of stupid things with it. If in fact orders are being randomly cancelled in the ICU that's a problem that should have never reached a live rollout to an ICU without some sort of consideration for how to resolve it, that isn't a software vendor problem, that's a management problem. This is nicking an artery and blaming the scalpel. Maybe if it happens once but if it happens consistently the problem isn't the scalpel. The problem is with how the scalpel is being used. Epic dates some of it's underlying pieces to the 1980's at least, it has some well known problems and bugs. Better managed facilities develop workflows that successfully route around those problems.
In-N-Out does not as I understand it develop it's own Point of Sale system, they work with a vendor. What do you think would happen if In-N-Out had a location that was consistently failing to ring up orders or lose them randomly? Would the cashier blame the POS vendor and store management stand by and do nothing while the problem persisted? Would the system be rolled out without definition and documentation of workflow, reliability testing and proper training of the cashiers? Can we not operate our hospitals at least as well as we operate a burger stand?
In and out can fire their vendor and walk away, this is nearly impossible for an public institution to do once the procurement contract is awarded, so those systems end up "too big to fail" no matter how bad or unfixable the situation is.
It just takes management with a spine. I work in the public sector, it absolutely can be done.
My guess, it's partially the softwares fault and partially the organization for trying to force a particularly bad workflow on bad software. It's probably fixable without throwing the baby out with the bathwater, but it takes someone willing to go dig in and figure it out. Those people can be hard to find in any organization, and doubly so in public sector organizations.
> this is nearly impossible for an public institution to do once the procurement contract is awarded
I think a big part of why these big projects fail is that a procurement contract is absolutely the worst way to decide which vendor to go with. Especially since most of the time, price is a big factor in who wins, and actual price is by far the hardest to pin down for projects of any non-trivial size.
Another big reason is that a lot of people at the top of the organizations on the customer side have little to no actual IT experience, and are too far removed from actual operations.
The best outcomes I've seen in large projects that we have been involved in has been when the customer didn't care too much about the sticker price, had decent IT knowledge up top or knew when to defer, and included people close to operations early on and throughout.
I have tried a lot of tools. Epic is terrible. capital T terrible. And its still better than just about every other thing out there.
Epic suffers from "it has to be all things for all people". so it is nothing for anyone. It is bloated, big, overly customizable, yet doesn't fit. Steep learning curve, bad UI/UX, expensive, just all around terrible.
And yet it is still better than everything else i have ever seen, except native single-hospital EMRs like Beth Isreal hospital, Boston, EMR.
Part of the problem is that every provider organization wants to have their own unique forms and workflow; there is a lot of "not invented here" syndrome and everyone falsely believes that their institution is special. This forces a lot of customization in the EHRs and actually makes the UX worse. If providers nationwide could get together and agree on standardized forms and workflow (at least within practice specialties) then it would become a lot easier to build good EHR software.
I've started joining design meetings for a new streamlined way for nurses to do their tasks in the EHR. Multiple times now we've got stuck in a little back and forth about how to do something, and someone suggests a setting to allow either option. And each time I try to interject "no settings!". It's a pain for support and code maintenance, increases potential bugs, and means that some organizations could get left behind on new features that aren't compatible with niche settings that they refuse to change.
I am a patient at UTSW in Dallas for over a decade. They seem to have implemented Epic successfully? I even like their mobile app. I can contact all my doctors in UTSW (over a dozen), see my lab results, and ask for refills through the app. Billing is still a bit of a mystery but I believe that is due to balance billing.
Yep I’m happy as a patient. My doctor is very in tune and uses it for everything effectively so prescriptions are easily handled, she comments on lab results, answers messages etc. it’s amazing for someone like me.
> Are you saying that the cancelled orders are due to a management decision/policy, and not a software bug?
The first time the order gets cancelled unintentionally, it's a software bug. Shit happens. When a bug happens, management makes a choice how to respond to that.
When the bug is permitted to persist and result in cancelled orders again and again and again, that's no longer a software bug, that's a management decision to continue to let broken software run rampant and affect their operations.
Think of it as the software equivalent of fool me once, shame on you; fool me twice, shame on me.
Clearly it’s both mismanagement and a software issue. I can’t believe the people here trying to ensure the software platform and provider never looks like the bad guy by defining “bad” in the most convenient way. (Again, management is bad. I’m not denying that. But two things can be bad.)
Competent management would atcept the report of this and scream about it. That means lawyers taking whoever is at fault to court. That means invoking the contract line to to pay (which they would have put there). That means of course a way to report things like this that any busy doctor can figure out.
Are you running Epic? As a patient it has been amazing to use and have everything available. My doctor uses it effectively and it’s quite cool she can do all prescription management etc through it. Now even virtual meetings.
I think you made a throwaway account for this reply, but I would really appreciate continuing this conversation with you. My email is available under my profile.
I'm not seeing substantial investment back in the EHR, wherever the money is going it's not being spent on improving the product. Epic remains a thick desktop app served over Citrix sessions, their web-based workflows still haven't materialized.
I worked for a couple of years in a company that both developed EMR software and ran clinics -- we employed care providers directly. I assumed going in that this would present amazing opportunities for applying modern technology to improve efficiency, outcomes and both patient and provider experience. Of course that didn't work out the way I expected. I'm not sure if doctors were the problem because to be honest I didn't get to interact with doctors much. The medical providers I did talk to were very interested in using software to improve things, and also extremely smart -- much brighter than the average s/w engineer to be honest. What I did see however was that the need to make (more) money began to dominate, and nothing that we were doing to improve our EMR really had much of an impact on that, at least not a direct or profound one.
Hey Duff, you're right, healthcare is broken in so many places, and insurers are probably the worst in this morass. They selectively follow Milligan care guidelines, build tools that actively discourage anyone from understanding and/or fighting for fair care and bills, and basically pretend they're doing you a favor but making you pay for your services, then showing a marked down EoB that pretend like they saved you money but knocking off 80% of a bill that was prenegotiated, and you're the one footing the bill. Insurers have no incentive to make healthcare better, and though hospitals are disjointed they still make so much money, it doesn't matter how badly they are run.
But aside from the insurance companies, the first large scale emr systems (Cerner, McKesson, and even Epic) were built as operational tools to essentially give accounting access to Crystal reports. Sure, electronic charts should make the patient's life better, and assist trained medical staff in tracking, however they ultimately are used to figure out how the CBO can game the insurer financial incentive system. CPT + ICD +modifiers (oh, and 85% of those cpt codes are under copyright by the corrupt AMA - yup i have a different bone to pick with them).
I agree that operational dysfunction is the biggest problem in these behemoths, and there's so much ineptitude in administrative staffing that it's a nightmare. Doctors like to believe they're the bees knees and everyone should kowtow to them, but they usually can't run a business to save their lives. It's easy for them to simply blame an EMR than to acknowledge the truth of a dysfunctional system they are a part of.
Glad to see you're still kicking ass, better than sameday.
Most patients who are unhappy about how much they have to pay should complain to their employer, not their nominal health insurer. The majority of US consumers reading this obtain their medical coverage from self-insured employers who use "insurance" companies mostly for network management and claims administration. It's the employer who ultimately pays for treatments. An insurance company will be happy to put together a custom plan for an employer under which plan members get as much care as they want for $0 out of pocket. This will be extremely expensive for the employer.
(We can argue about whether health plans should be tied to employers at all but that's a separate issue.)
A lot of facilities run on a McDonalds type thinking when they should be looking at how In-N-Out is able to deliver a very similar product that is both dramatically better and either the same price or even cheaper. In-N-Out staff is well compensated, customers rate the institution as one of the most beloved in american life. McDonalds achieves neither of those things. What makes In-N-Out different? The difference is competence in operations. A lot of healthcare today delivers an inferior product at an inferior price, it doesn't have to be that way. A lot of people think that quality is only possible at an increased "price". A change in thinking is what is needed to achieve a change in quality (result/price).
Responding to the request below for a specific example. Hand washing, you wash your hands when medically appropriate to prevent facility acquired infections. If you don't you are progressively warned ultimately leading to termination and/or loss of license. If instituted nationally this alone would save at least 5,000 lives a year. Good luck getting it instituted at most facilities.
A different example, diesel fuel and generator maintenance is a meaningful part of medical facility physical plant. A shocking number of facilities place procurement responsibility and oversight of this in the hands of a doctor who also has medical responsibilities. The results are as financially and operationally disasterous as you would expect. Data centers have similar requirements. Who do you think pays more and operates better?
Formularies are a sort of default medication lookup table. Most organizations have one that was created decades ago by people who aren't with the organization anymore. Review and revise them with someone who understands both the medical/pharmacological aspects of the drugs involved as well as their costs. Win for doctors, win for patients, win for insurers, almost no one does this. They have some clueless administrator carry forward last years formulary with minor changes or alternatively have a medical professional with absolutely no idea what costs are involved do it.
That diesel maintenance example gets even more interesting when read through the lense of the ongoing Boeing threads: there, consensus is that the root problem is authority erosion for the core discipline: in old Boeing, engineering was a requirement for responsibility, but that is gone. In hospitals, the core discipline still holds on, but the blanket implicitness (or is it already a struggle? "we can't give up the diesel!"?) leads to terrible outcomes as well. Extremes rarely end well.
"Responding to the request below for a specific example. Hand washing, you wash your hands when medically appropriate to prevent facility acquired infections. If you don't you are progressively warned ultimately leading to termination and/or loss of license. If instituted nationally this alone would save at least 5,000 lives a year. Good luck getting it instituted at most facilities."
Sad thing is most staff in hospital doesnt wash hands. Reality is it would cost so much time. Handwashing is like a minute and staff has to go in an out of rooms where hand washing is needed so many times an hour it would slow everything down. And then trying to fire staff about this is not real because this would kick out half of it and it isnt replaceble. The problem is more why has staff to get in and out of stations so frequently. And multiresitence bacteria.
I'm always terrified to see surgical caps and such on doctors in a hospital cafeteria. Also a nurse or surgeon wearing scrubs on public transit. Whether they're coming into work and carrying unknown filth into the facility, or leaving with deadly resistant hospital pathogens on high density transport... they're both terrible. Unless you're outpatient, don't wear scrubs to/from work. Don't be Dr Oz wearing your status on your shirt sleave for giggles while risking patients and public.
Specifically with handwashing which is a problem I have been very successful at solving, time is not the main factor. It is wear and tear on the hands and this comes down to the soap used and water quality, really. If you get those too things right people mostly find it no problem to wash their hands when appropriate. Also for non-medical people this is not washing your hands before surgery washing, this is routine washing between patients, bathrooms, and duties.
Regarding gloves, gloves don't solve disease transmission from dirty hands. You need both hand washing and gloves.
> Handwashing is like a minute and staff has to go in an out of rooms where hand washing is needed so many times an hour it would slow everything down.
Sounds like the workflow is poorly designed then. Use gloves instead of hand washing.
McDonald’s menu is enormous, much larger than In n Out. If you’ve ever worked in the quick service food industry (it sounds like you haven’t), you’d know this considerably affects how every facet of the restaurant functions.
I also completely disagree that In n Out is “dramatically better” and I’d be very surprised if that was the resounding opinion across Americans. It is fine, but again, it serves a different purpose, so making such broad apples-to-apples comparisons seems a little short sighted.
“Competence in operations” is a nice sound bite but without some real examples related to restaurant management I’m just not convinced. I ensure you that it has indeed come up in a McDonald’s boardroom that raising their wages would result in more competitive hiring, that is not a novel observation. I did three years at McDonald’s and another several at other restaurants; admittedly it doesn’t sound like this comment was made from a place of experience, more a place of convenient idealism.
Also don’t forget scale—-in/out might have ‘dozens’ of restaurants but McDonald’s has ‘thousands’.
They also have software that was developed entirely in house that is unbelievably optimized. Weird, but usable. They are a company that fully understands the problem space they operate in. Hospitals should be doing everything they can to run like them but no one likes to hear that.
I don’t understand the people who rave about it. There’s very little difference other than the fact that they have a “secret” menu with their own coded language.
I’ve been to both good and bad McDonalds. Burgers and fries from well-run ones can taste very good. In-n-Out has better consistency, and it’s on par with the quality of well-run McDonalds. It’s probably due to the fact that In-n-out has fewer items? I don’t know.
Huh. I like the slightly toasted bun and the generous amount of veggies they put in the Inn n Out burger. I’m not aware of a similar looking or tasting burger on the McDonald’s menu.
> customers rate the institution as one of the most beloved in american life.
That's a bit overstated, the majority of Americans haven't been to an In-and-Out, ever, because they are a mostly-California chain. They're only available in a very small handful of states.
In-and-Out can probably run so efficiently because their menu is extremely tiny.
Respectfully, I’m not sure what you are asking for. In-N-Out is only in a small fraction of the US so most people from the US wouldn’t know much about it either. I believe that’s why the GP comment provided a little more context which was more or less sufficient for me to understand the comparison.
Initially the In-N-Out example was made without explaining what it is, and even with the added context i think it doesn't really explain how In-N-Out differs from McDonalds. Their operations are better, what does that mean, how does that impact customers, how does that impact cost, etc.
I wouldn't say Rolls-Royce, more like Lexus. Fuddruckers would be closer to Rolls quality as they actually allow for something other than well-done, preformed, meat pucks.
In-n-Out has saturated the southwestern coast, which is a pretty significant fraction of the United States.
The key is they have an absolute ton of employees in the restaurant (a busy McDonald’s might have four or five, In-n-out can have double or triple that. I’ve seen other fast food with two employees, never an In-n-Out) and they work exceptionally hard on specific tasks.
They also only deploy in areas where they’ve determined they’ll be able to keep the store busy enough.
Am too from Europe, and never heard about it until last year when visiting my colleagues in LA and was taken to a In-n-out. It was packed and I agree that it’s tastier than Mcdonald’s. My colleagues were very surprised that I didn’t hear about that company because “everyone knows it”.
What they don’t understand (until explained) is that what we get in a European countries are just a small selection of big franchises (McDonald’s, Burger King, Starbucks etc) and maybe a handful of other ones. In America there are dozens and dozens of restaurant franchises where you can eat for weeks each time in a different fast food restaurant in the same city without going to the same place twice. This is what always amazes me as a European, that huge amount of choice of everything you can have there.
Even a ton of Americans wouldn't know In-n-Out. They only really recently started expanding a lot. Until a few years ago its was pretty much a Southern California only thing. There are no locations east of Texas, and even then there are only locations in the core triangle of Texas. If you're in El Paso or Corpus Christi or Amarillo or Lubbock or McAllen or Brownsville you're several hundred miles from the closest location despite there being many locations in Texas. There are zero in New Mexico, Oklahoma, Kansas, or Washington. All of New England is about a thousand miles from a location.
These people acting like "everone knows it" essentially have the same world view that the entire world that matters is Southern California.
Some of these suggestions seem like non-trivial management problems, though, I think?
Diesel fuel and generator maintenance: how do you hire for that? Does that position require experience? In what? Where do you post that job ad to get qualified candidates? If you hire wrong, it seems like the results could be worse than foisting the task on a doctor, no?
Revising formularies: how many doctors at a hospital have the right expertise for that? Who cares for their patients while the formulary work is happening? Can you hire someone temporary to come do it so it doesn’t disrupt operations, and how expensive is that person and how good is the result?
I’m a software person, not a doctor, but I _can_ see how these choices would be made if the alternative seemed riskier to someone inexperienced at hiring for hospitals.
>Diesel fuel and generator maintenance: how do you hire for that?
This is typically part of the job of a facilities manager, someone who is in charge of maintaining the physical structure and amenities of a building or complex of buildings. You hire for it the same way you hire for everything else; you find someone in the category that you want, who has apparent success doing something similar to what you're doing.
Many of the most painful technical problems are actually three business problems in a trenchcoat.
Sometimes too many people are too invested in the crazed/idiosyncratic way of doing things... and unless the humans can be convinced to fundamentally change their process, adding software will only give you... well, craziness with a computer.
you know, sometimes those idiosyncratic ways have a reason for existing because they solve actual problems.
Technical people have a really bad habit of solving for theory rather than practice and they develop this attitude that those who are seemingly entering into odd behavior are just not as good or smart as them.
> you know, sometimes those idiosyncratic ways have a reason for existing because they solve actual problems.
True, but "actual" is a rather low bar. I once worked at a company where a big internal enterprise app controlled a lot of operations, and saw that many of the layers of cruft in the app were because it became the preferred battleground of corporate dysfunction.
One example is that the sales team kept closing deals ('cuz commissions) which were difficult to fulfill, unprofitable, or cannibalized from other assets and activity.
This lead to repeated and increasingly obtuse layers of code for estimating gross-margins, showing values at different interfaces and steps and warning styles, managing and modeling gross-margin reporter/reportee connections and automated alerts and permissions systems where they system would block certain people while e-mailing other people for clicking approval boxes, etc.
HN is (probably) read by mostly software development (-adjacent) people, and this thread is basically software developers blaming users for using their software wrong. Maybe that's true, but I think it's at least worth pointing out before someone mistakenly thinks this isn't an echo chamber.
> this thread is basically software developers blaming users for using their software wrong
I wouldn't say that, most devs who've worked with product requirements and users have seen issues with users wanting something inefficient or illogical, basically because they don't like change and/or don't understand why they are doing something.
In my opinion, this is less about the field (health care, real estate, etc.) and more about automating someone's core role. Many people have learned to do a particular job a particular way: some things they have picked up through trial and error, others were handed down from a more senior co-worker. There are other steps that are taken because something else (regulatory requirements, etc.) require it or don't and have been misunderstood.
When we try to automate part of a person's work, we have to encourage the person to take a look at themselves and the way they do their work. This is not easy for people! A lot of times we're asking someone to admit that they don't actually know why something is done a particular way. Or we point out that they are doing the work of another person in another department. And, all the time, this person is worried that at the end they will be replaced by software and lose their job.
I think it's really hard to get to a place where everyone is comfortable enough to be frank about what they do, what the software might be able to do, and what makes sense.
Idk this reads like apologetics for the software industry, which I know people will be more sympathetic to here. But. I know doctors that tell me their EMR log them out after a minute of inactivity and take 3 minutes to login. This can happen multiple times during a patient visit and are totally disruptive. I've heard that it's even begun to affect the throughput of the hospital. So I wouldn't be so dismissive of doctors complaints.
I very much doubt it’s the software vendor who has chosen to implement the automatic logout after a minute. Most probably someone wrote that down in a requirement because that’s how the previous system worked or that’s what they saw on the internet, and once that’s done it’s set in stone
Again, that's not an EHR problem. All modern EHRs support fast SSO and OS security integration. If it takes more than a few seconds to log back in then the fault lies with the customer. They have either configured the system incorrectly or are running on inadequate hardware.
This is entirely a data security issue. Depending on the environment, without a logout this is seriously risking a HIPAA violation. Say you're in the hospital and your doctor pulls up your record on a computer in the hallway after they've done rounds on you to put in their observations and notes. However just as he's finishing, his pager goes off, he's off to an emergency, and he forgets to log off.
How many minutes are you okay with your medical record being open for inspection by anyone that walks by? Other medical staff, admin staff, janitorial staff, other patients getting steps in, other patient's families?
It's one of many instances where there's a valid reason for the technology to be implemented as such but since doctors usually aren't thinking about the technology or security aspects they just perceive it as annoying.
> It's one of many instances where there's a valid reason for the technology to be implemented as such but since doctors usually aren't thinking about the technology or security aspects they just perceive it as annoying.
No, there is never a good reason to prevent a professional from doing his job. If the user finds it annoying, it is annoying: that's it!
Learn to work for the user rather than against the user, and you'll become a better developer.
That's simply not true. The user is not the only stakeholder. The example I gave opens up the hospital to fines from the government and in the worst case scenario a massive legal judgement from the patient who's data was breached by a physician leaving his workstation with a patient record opened and it was compromised by a malicious actor.
edit: in any case this is very likely a security configuration by the hospital infosec team, not the developer of the EMR.
The specific example isn't a developer decision. It's a combination of vendor risk management teams, hospital InfoSec/security/compliance, legal teams, laws, and location of computers. Nevermind that setting is just as often a workstation GPO to lock the screen and not even the choice of the software.
(Work for a PACS vendor, subject to the same stuff).
At ClearHealth/CLH we defined thousands of core business processes in a typical over 100 bed acute care institution. These are complicated animals. A hospital of any size is pretty much a city unto itself. There isn't one thing, there are a lot, a lot of things from how items and equipment are procured which is very complex to simple things like making sure that people wash their hands when they should. How laundry and trash are handled. HVAC and plumbing are insanely complex in a hospital setting. It is absolutely absurd how viscious the fights get between staff and management over parking assignments. It requires virtually a threat of termination to make a lot of doctors follow even a 3 to 8 step evidentially developed checklist for certain situations.
ACHC, joint commission, CLSI for laboratory, are groups that outline some very basic frameworks of how facilities should be operated. Less than half of facilities can meet even these extremely low bar standards for operations. It is difficult for me to see how many patients have been harmed by ransomware impacting hospital opertions, this is entirely preventable and no one on the hospital side has been meaningfully held accountable so very little will change.
A counter example is the pricing transparency regulations. Failure to meet those is resulting in multi-million dollar a year fines which is resulting in change. It is happening slower than people like or had really conceived of but it is causing some real meaningful change.
99,000 americans a year die from hospital acquired infections that are entirely preventable using procedures and operations (not surgeries) that are known and evidentially proven. It's just really hard to get all of the parts of the orchestra to play the same tune so those people die needlessly.
Is there some way a non expert can assess a particular hospital by these measures? What I'm getting is that most hospitals introduce more risk than they should, but if I find myself needing one I have zero idea how to not make picking one feel like flipping a coin.
"99,000 americans a year die from hospital acquired infections that are entirely preventable using procedures and operations (not surgeries) that are known and evidentially proven. It's just really hard to get all of the parts of the orchestra to play the same tune so those people die needlessly."
??? I dont get this. The problem are Antibiotic resistant bacteria. You go to a Hospital (ER) and have a open wound.. chances are you die of an infection. How is this preventable??? This is a big problem atm and there is no good solution. you cant test people if they come in bleeding like hell for Resistant bacteria.
I mean you can but ...
I would like to hear the solution to that problem. Thank you.
I once spoke with a nurse who said they have the walls scrubbed on a regular basis. I can't recall if it was daily or weekly, I think weekly.
They're not paying the nurses to do that, the people who are doing it probably consider it shitty work and I wouldn't be surprised if things get missed due to the sheer crappiness of the work.
I think there's probably a reality there that can't reasonable worked around. Sure, in theory a perfect scrub will solve the problem but how do you regulate that into effectiveness?
The best you can do is to design tools to make it less shitty but you'll never make it non-shitty.
In germany we have this allready but it doesnt work. It reduce the problem. But the real problem is ER. In a life death situation it doesnt work. ER are very hard to keep clean. But yes you are absolutly right
EDIT:// I am no doctor but did work in Hospitals. Doctor friends working in ER are telling me about those dangers. And also bigger Hospitals have less control about it.
220nm light is under investigation since it's germicidal but so far appears far less harmful to humans than other UV ranges. If those findings are validated we might see some permanent narrow-band, low-power UV lights in hospitals.
For one, the payment setup in the US is a massive burden to proper care. For every screen and procedure that gets logged into an EMR system, there is some resulting billing setup that is complex, overburdensome and user hostile. The billing setup is so bad in the US that there are whole armies of companies who's job is literally to just collect revenue for unpaid bills (RCM - Revenue Cycle Management), many of which are the result of a confusing billing and invoicing system.
Source - I've done diligence on at least 75+ EMRs/EHRs.
Make a less divisive or controversial analogy then. If people are getting hung up on the analogy and not focusing on the point you’re making, you’re making a bad analogy.
I wrote a thesis on EHR's 7 years ago. They really haven't seemed to improve much. I personally think a big part of the issue is actually scope, these systems are expected to do everything - medical notes, script ordering, appointment management, billing of course, and 3000 other things. This weirdly leads to a distribution problem, you can't be a serious competitor in just one area, you have to do everything. Only the monolith can shift the monolith. Then combined with the risk (or perceived risk) of working with medical data, and you're left with something that just never improves.
This is very true. There several reasons why most EHRs are so bad:
1) The people who pay generally do not use the system. This is true for enterprise software in general and leads to vendors prioritizing having all features organizations ask for (regardless if they are a good idea or not) and also prioritizing features management deems important over fundamental workflow, UX and polish in general.
2) EHRs are very large and complex and can almost always gain more customers by gaining even more features and replacing smaller more specialized systems. A typical EHR will have features for ordering tests and viewing results (for clinical chmistry, microbiology, radiology and more special stuff like physiology etc), appointments and resource planning (rooms, equipment, personnel, staffing), clinical notes including computing scores and values based on other values, medication (ordering, administering, sending prescriptions electronically) and administration (admissions, discharge, payment, waiting lists). That is a lot of different stuff!
3) Once a vendor wins a contract and installs their EHR, very little can be gained by improving the lives of users. Contracts and sales cycles are very long, and the vendor gains very little financially by improving the system. So many vendors are focused on charging money for customer specific features or adding new features to win new tenders.
I'm not sure what the solution is, public alternatives have failed spectacularly since they are typically run by public administrators who have even less of a clue how to develop software and what users want than the vendors.
> So many vendors are focused on charging money for customer specific features or adding new features to win new tenders.
In turn, this enterprisey anti-pattern creates unfocused products which can be configured to sort-of-solve every niche customer requirement that might block the sale.
The result is a massive ball of muddy configurations and feature-flags, so that learning isn't very portable and backend integrations are very painful.
I would add the point that these dynamics are also present for any large IT system. Just search for people having issues migrating to SAP or Amadeus or whatever
Ironically, it's also a somewhat of a circular problem, given the inherent complexity of medical processes, every organization has organically formed their processes over decades. When choosing software solutions, they pick software that caters to their specific needs, rather than change processes to fit existing software. This results in vendors building endlessly configurable products that add even more complexity. As a potential new entrant, this means you'd need to not only support N processes, but something like (number of clients) * N processes.
There are some initiatives towards EHR interop (e.g. FHIR), but from what I've seen so far, they suffer from similar problems. As in the standard is made so flexible to cover all situations that you can make things that are 100% compliant, but completely incompatible.
Yeah, I've seen the term "sociotechnical" used to describe this relationship between software and process. A process is built in part for a system, and therefore the system in part needs to support the process. Changing the setup isn't just a technical challenge, it's a challenge in creating sociotechnical change. I think it's a very easy thing to underestimate.
>I personally think a big part of the issue is actually scope, these systems are expected to do everything
If I were to guess, the goals of admin and workers might not match because the primary goal of the admins deciding and implementing the EHR is to avoid liability for the organization in the event of an error, but errors are inevitable. And if liability for individual errors are so costly (as they are in the US for healthcare stuff), then the primary goal for the workers also becomes avoiding liability.
In this situation, I can envision something like a crew of people working in the hospital that do good, quick, but undocumented work 99% of the time, are now being slowed down by documentation or other cover their ass needs. Obviously, it is possible that the new documentation needs are also uncovering malpractice that went unnoticed before. The question is are the tradeoffs worth it, which does not have a simple, objective answer.
In Swedens capital region they failed with this too. It's dominated by a system that is largely quite well polished but has some scaling issues that has lead to down times. The region decided to develop their own in cooperation with other regions, but instead of just hiring two-three developers and putting them in a room inside some small hospital, they decided to make a Grand Political Project out of it.
Billions of Swedish crowns later, having written ZERO lines of code, they quietly cancelled the entire thing. This enormous boondoggle didn't even make the news because the waste was all man-hours and consultancy, and not a building or something the media found sexy.
I think a big problem is that politicians need Grand Political Projects to get reelected, but that's not how you build software. Or make meaningful small incremental improvements to science, infrastructure, schools, etc. The incentives are wrong...
The UK government tried this, wasted 12.4 billion pounds over 10 years, and ultimately wrote most the project off. The dream of an EHR is just deceptively tricky, so many smart, well-funded, well-connected teams have tried and failed.
I have a friend that has worked on this project for over a very long time and the issue is not that the UK tried to implement EHR records from scratch but rather that GPs (General Practitioner, think local doctors surgeries) had mostly all implemented EHR systems already. The issue is that these systems are created by several (6-8 if memory serves) different private companies and the UK Government can't force the GP to change or adopt a standard system.
The different GP EHR systems record patient information in their own ways. Think of a database entry for chemo medication, one EHR provider having a db column labeled "Drug X" with the patient entry listed as "Yes" with separate columns for dosage, frequency etc. Another will list the drug, dosage and frequency in the same field. Even if they have the same column e.g. frequency, different EHR's may list "5d" or "5 Days". There are also spelling errors, doctor's personal shorthand abbreviations etc.
The problem is that the UK interoperability system has is to implement a safe translation layer that will allow records to be transmitted between these systems that doesn't kill anyone. The astonishing amount of different types of information that are used and all the oversight needed to ensure that information is accurately transferred has made this project way more costly and time consuming that originally thought.
There is, of course, waste and profiteering, both internally to the Government project (huge contract salaries) and also with the private EHR companies (overruns and re-builds are all handsomely paid for).
> The issue is that these systems are created by several (6-8 if memory serves) different private companies and the UK Government can't force the GP to change or adopt a standard system.
Yeah, the UK healthcare system is only mostly nationalized.
I do think these IT issues could be fixed, but only if there was someone at Cabinet level who knew what operations management was, which we're unlikely to get in the forseeable future.
Following the sources listed there, "wrote most of the project off" seems like an overstatement.
> The MPA found that there have been substantial achievements which are now firmly established, such as the Spine, N3 Network, NHSmail, Choose and Book, Secondary Uses Service and Picture Archiving and Communications Service. Their delivery accounts for around two thirds of the £6.4bn money spent so far and they will continue to provide vital support to the NHS. However, the review reported the National Programme for IT has not and cannot deliver to its original intent.
Of the rest of the £12.4bn,
£3.4bn is "expenditure by local NHS
organisations, for example on local IT and
training and ensuring compliance of local
systems with Programme delivered systems", which probably isn't entirely wasted either.
This is a joke. We want to have this but its like everything in germany if its about something digital. Its a fucking mess. Everyone can read it. Most doctors dont use it and even many insurance dont use it... its a fucking mess
Ok, but it’s digitalized, I didn’t say it was good. You can now directly go to an Apotheke with your insurance card and get your medication, even the prescription is digitalized.
Again, this can't be worse than private industry—that profit margin will guarantee this. I guarantee there is some other disease to blame for the waste—probably politicians of some sort invested in industry.
Of course, this does demand citizens give a shit, which seems hopeless at this point.
There is (or was) a public competitor. VistA was largely developed by the federal government. Some organizations still use it and it's available for free, but independent reviews have generally rated it as worse than the private industry products.
I have to wonder how independent those reviews are when medical staff consistently rate it higher than commercial products, the system has won multiple awards, and when the VA tried to implement a commercial replacement it failed.
Vista is public domain, so there’s no money in it and no-one to take management out for expensive lunches.
Interestingly the linked article seems to be singing praises of VistA, though it's unclear whether the author has actually used the system themselves. They link to an unsourced article with that claims it tops reviews, but clicking through to the various related articles seems to have a consistent theme of people not liking VistA all that much.
Again, I don't see how a private industry per se could even possibly be worse given the demand for a profit margin. Your beef is with some other aspect of this process.
the same higher-level forces shape the public project's fate into certain doom that led to hospitals buying the absolutely shittiest tech.
because there's no clear signal (in the private sector there's some drive for sales, market share, profit), only made-up hyperpoliticized bullshit requirements and maybe some barely coherent vision.
as long as there's not a clear technocratic organization with sufficient independence and competence these projects are rudderless yellow duckies on the sea of tragisocial medicine mismanagement madness.
no party involved really has enough resources to deliver something nice. it's like high speed rail in the UK or the US. as a public project it's already stillborn, because it's too expensive to do it right (or if it would get the right amount of funding it immediately attracts unlimited scope creep, and the usual vultures show up, it becomes a typical everything bagel project, solve EMR but also education and childcare and whatnot), and to do it efficiently it would require draconian standardization and heroic amount of data migration work.
and on top it gets over promised and under staffed and so on
I believe the Estonian government has long had at least a basic EHR that they use across their public and private medical facilities that is part of their larger e-government system
Private industry is already worse than the older system of keeping notes with pen and paper. (Source: my mother operated her own medical practice and applied for a government subsidy to switch over to electronic medical records, then complained about how it reduced the functioning of her practice.)
Is it? There's trade-offs of course with everything. There's certainly many aspects in which a medical practice only using pen and paper is worse. How about transferring records to other institutions? Or taking your work home with you? Do you want to lug boxes of records home which may get lost (HIPAA breach) so that you can finish up your notes at home? What about making copies for a patients right to access? What about auditing changes or access to the record to enforce data security, integrity, and compliance?
What's the timeline of evaluation of reducing the functioning of her practice? If it was just a recent change then I would expect growing pains. I have many close personal relationships with healthcare workers and when their electronic health record system is down, having to use pen and paper leads to drastically worse functioning within their job. So the same claim but in the opposite direction. The reality is doing something you're not used to is harder.
In what sense is that an answer to "why were they doing that?" The entirety of the answer does nothing but give a name to the policy. "Why" would usually be understood as a question about the reasons behind the policy.
"The government was subsidizing the abandonment of paper medical records because they had a program in place to do that" is something you knew before you asked the question.
I mean, all industries? The profit margin guarantees this. Anyone who has worked in private industry will verify its utter incompetence in the long term.
Can we talk about particular examples? I know for a fact that in my area private train ticket booking app is vastly better than government one. So at least there is an exception.
Yea. But in that time there has been an absolute revolution in what can be done with that data. FHIR specifically has completely changed the landscape.
Yes. FHIR was pretty well established when I was writing the thesis, but I am very pleased to see it get more and more usage since then. Apart from interoperability the opportunities to do much better data mining from free-text medical notes with AI, are huge now. Back when patient prescription lists ot structured, so many new drug interactions were found, now there's the chance to do similar stuff from open medical records.
Patient-accessible medical systems are more common now too, which is great. EHealth got way more common. At the end of the day though, what your doctor is clicking on still sucks, which is the sad part.
Popping up here to mention OpenMRS, a healthy open-source EMR used by hundreds if not thousands of facilities across the world, mostly in Africa and Asia. An old version is packaged/integrated with some other apps into Bahmni, which is a full-blown hospital management system.
Honestly, people complain about software all the time and all software sucks to some extent, some more than others of course. Complaining about all EMR just because the USA bodged a national rollout in their uniquely messed up healthcare situation is a bit myopic.
I would not dismiss his complaints as broad brush IT disparagement. Despite the title, I think the author is referring to the EHR (Electronic Health Record), specifically of Epic which is unique in that it is essentially a "benevolent tech dictatorship" imposed upon 90% of hospitals through owner/lead programmer Judith Faulkner at Epic (no medical background) lured initially by federal incentives then married to it in perpetuity. That's not really anything like operating system software you can uninstall today (e.g. Microsoft, Linux, Apple). With the onerous hospital system transformation contracts and non-disclosure agreements - Epic exec customers are more like cult followers than standard software consumers.
I suppose that's technically true although wikipedia states that she cofounded Epic with a medical doctor and is married to a medical doctor. As a software developer, I rely on subject matter experts frequently. I'm not an expert in radiology, chemical engineering, or any of the other businesses that I support.
Very true, people complain about software, but my recent experience in a Gulf country, was stellar, all my medical records, were entered properly including procedures, it takes approximately 12 minutes to get medicine from the pharmacy and can view the records online. The patient interface could be improved a bit but did its job perfectly. The article was stellar, as it summarized the state of the art and the issues well.
I believe this article is only about this specific system. The problem is that the name of the system is "Electronic Medical Record", which makes the article sound like all such systems are hated.
I don't think that's the case. AFAIK there's no such system. The article specifically reference Epic, which is one of the biggest (_the_ biggest?) EHR software company in the US. My wife used it as a nurse and I've watched my own providers struggle with it. It sucks.
Indeed. The biggest hospital where I live (Trondheim, Norway) is still running at reduced capacity and over budget a year after moving to an Epic derivative. Doctors and nurses are burning out, many talking about moving elsewhere. Being recently retired, I am concerned that this may not be a safe place to grow old, if the hospital (by all accounts an excellent one) is dragged down by this horror of a system.
Saying “it sucks” is like saying “SAP sucks”. Whatever system you get out of one of these projects is 99% dependent on the project team (on both sides), and 1% on the product base, which is invariably “meh”
Disclaimer - I work for a health service that isn't in the USA and has a very extensive EMR.
I don't disagree. I started my career dealing with paper folders of records that were fastidiously organised by a team that made sense of them. Now everything is electronic and fucking _everywhere_. The work didn't go away - but giving everyone a computer made it everyone's problem and nobody's job.
A really good EMR (or other records project) makes the 'work doers' jobs easier and is intuitive. We often severely miss that mark or only do half the job required.
This is everywhere. We made everyone their own secretary but gave them crappy tools and no training. Also they’re never gonna be doing it more than very part-time, so will always tend to be bad at it and find it a distraction from the work they’re actually good at.
I’m skeptical computerization has even been a net benefit for productivity for most jobs, for that and other reasons. I think it’s been such a huge boost in a few areas that it looks productive overall, but actually it’s been a step back in most jobs. The high of eliminating positions and of centralized command-economy-style technocratic visibility into everything keeps management hooked on it anyway.
> We made everyone their own secretary but gave them crappy tools and no training. Also they’re never gonna be doing it more than very part-time, so will always tend to be bad at it and find it a distraction from the work they’re actually good at.
This is, 100% exactly it. Then we have to design systems for the absolute lowest common denominator to get any semblance of sense from it and anyone with the slightest bit of clever just has to deal with it.
The problem with the computerization brings benefit lines is that it was demonstratively true back in the mainframe days but became less and less so once the big beast with dedicated attendants and handlers got replaced by "not quite foolproof enough" wintel desktops managed by nobody.
This is also why so few PC centric modernization process are truly successfull.
the successful part is usually when the whole thing gets swept away with something completely digital-based. the bad part is that usually there's a long transition period, the new thing sucks balls for anything except the basic functions, there's no human to talk to, etc.
From the other side of the table, as patients that were very regularly ill and bouncing between medical professionals, EMR were a godsend.
For instance in vacation at the other end of the country, we lost an Anapen with a luggage mishanded at the station, though we had a spare but we actually didn't (was in the same bag...). We went to the closest doctor, showed the insurance card and they got access to the allergologist's diagnosis and original prescription, gave us a new one with a memo in the file, and done.
Same way having two generalists looking at us, one near my work and another near home wasn't an issue. At no point did we have to bring folders full of papers to explain long treatment histories etc. (it still helps to have the key files, in particular scans)
I moved away and everything is back in small silos at each doctor/clinic, and it's a real PITA.
I'm truely sad it's such a pain on the care giving side, because there's so much potential and I think it merits investing a lot to get something decent. It's such an important part of our forseable future.
The problem is that in the US, many EMR's don't automatically connect to each other.
If you're going from a hospital owned by one chain (say, Hospital Corporation of America) to another hospital owned by the same corporation, then yes, it works like you said and doctors have access to your historical data. But God forbid that you should ever end up at a hospital owned by a different corporation, because then you have to call the Medical Records department to release the data, which often takes a couple business days to go through. The system doesn't work if it isn't open, and unfortunately, our patient privacy law (HIPAA) is often used by corporations as an excuse to silo their data away and prevent others from accessing it.
The 21st Century Cures Act was signed 8 years ago (but compliance was only required as of 2023). It states that Healthcare Institutions (& EHR developers) must provide a mechanism for patients to access their health records electronically in a standardized format (FHIR).
It's what allowed my open-source startup Fasten Health to even exist. I was diagnosed with a chronic condition, and wanted a way to store my health records privately on my own devices. A bit of luck and a POC later, I was able to confirm that patients can access their own records with little-to-no barriers.
It doesn't matter that I've had 6 different insurance companies over my career, or that I've visited more than 2 dozen different healthcare institutions, as a Patient we have the unique ability to collate and generate our own longitudinal health record.
Cool, does your product fall into the category that they call "patient passports"?
Also, I looked into your website, and it looks like you have the https://www.fastenhealth.com, but you forgot to register the subdomain without the www. I remember having to configure that the last time I deployed on Netlify. Also, I was gonna try the Careers link on the website but it looks like it's a dummy link, which is fine if it's intentional.
is there any good research or information on various clinic's organizational style? I feel like there are plenty of places where digitalization took its time to get there.
I feel like in general there's gotta be a lot of good sociological research on how stuff is kept straight. I only see stuff regarding DX work, but organizing was a problem even before computers, right?
EHR’s have all the problems of enterprise software, plus some. At the end of the day, the software is made for the people who pay for it. This isn’t the patients, or the providers. It’s the admin, billing, and bureaucracy layer who get to make all the decisions. It’s not surprising that these people don’t prioritize good software.
EMR’s need to do more, but the root of the problem is systemic.
Agreed, you see the same issue with other enterprise software that tries to everything: SAP (including more specialized parts like Concur), Workday, and many others. They’re trying to do everything, then are often badly configured, mostly by following internal (financial) procedures, without considering end user experience.
There’s a whole industry of tools to help you build better interfaces on top of these big systems of records to improve the user experience. So much so that Gartner has even describes it as a desired way of designing system: used to be Pace Layer model, now it’s called Composable Enterprise.
I think they need to do less. Part of the problem is they are trying to be everything for everyone. A hospital is an aggregation of what is really several different businesses into one - and they all have to use the same monolithic application. Each medical speciality has their own unique data and technology needs, as does each specific unit (ie different ICUs for surgery, burns, etc), then add pharmacy, labs, admin, etc.
If the priority is billing, then focus on aggregating and correlating billing data, expose an API for consumption with other systems being used that may or may not be from the same EMR company.
I do agree that there is an issue with stakeholder bias towards admin. Every pet project from admin results in a bolt-on fix to the EMR configuration bloating clinical processes. They are the ones that make the rules and decisions and are often disconnected from both technology and clinical expertise which is perhaps the worst combination for health care technology decisions.
Also, even if Epic offered its platform free of charge, it’s incredibly expensive to setup and train staff. Just that initial expense of plugging everything in is a huge risk that many hospitals on a tight budget likely can’t afford to take.
My first job out of college was working at Epic Systems as a mostly Windows sysadmin. It was a fascinating (and great!) experience. I've never seen such an advanced Windows sysadmin setup before.
I only briefly touched upon EMRs and the MUMPS/Cache stuff they did there. However, I also learned PowerShell to a much deeper level than probably 99% of Linux folks ever do. We did TDD, code review, CI/CD pipelines for fucking PowerShell. It was painful right up until the point where I internalized the Tao of PoSH, and then I realized that PowerShell actually rules for readability and maintainability when you have people who know what they're doing.
HNers by and large don't understand the economics of PowerShell. There is a very low supply of competent PoSh devs on the market, and even fewer interested in credibly signaling their proficiency, but a very high demand for them, because a lot of places still run everything on Windows, and guess what's installed on virtually all of them? I've even been able to take on a few consulting gigs that boil down to "take our 100,000 line un-version-controlled PowerShell monstrosity hacked together over the last 13 years and turn it into something we can actually understand, please".
> PowerShell actually rules for readability and maintainability when you have people who know what they're doing.
Isn't that true for all programming languages ever devised by mankind?
> HNers by and large don't understand the economics of PowerShell. There is a very low supply of competent PoSh devs on the market, and even fewer interested in credibly signaling their proficiency, but a very high demand for them, because a lot of places still run everything on Windows, and guess what's installed on virtually all of them?
I don't see what point you're trying to make.
The fact that Microsoft decided to push PowerShell on virtually all versions of windows it ships only reflects a Product decision by Microsoft to push a Microsoft-only tool. It also shows Microsoft's decision to not offer the same level of support for any other alternative.
Where's the economics in that?
I also don't understand your broader comment on economics. Are you depicting it as a good or bad thing?
That article is true but hardly fair. MUMPS has the "blessing" of early success dating back to the bygone era of punchcards. We all point and laugh at the single letter keywords now because a candle [0] now has more RAM than a database server did at the time. Would Crockford have been around to write "MUMPS, The Good Parts" in the middle 1970's we might all be using a general purpose programing language with built-in persistence to a no-SQL document store.
Re/ the economics: It's okay, many people don't get a formal course in this stuff. First look at the graph with two lines on https://en.wikipedia.org/wiki/Supply_and_demand. Notice that the y-axis is P for Price.
Now imagine first off what happens to Price when you shift the downward sloping curve forward. That is what economists call the demand curve. Does Price go up or down?
Finally, imagine what happens to Price when you shift the upward sloping curve backward. That is what economists call the supply curve. Does Price go up or down?
One would hope, but alas! Perl was notorious for being write-only back in the day.
PoSh is closer to read-only for most devs. If someone makes sure to write things out the long way (or uses a linter to do this) it's very easy to grok. Actually learning to write it is the tricky bit.
> One would hope, but alas! Perl was notorious for being write-only back in the day.
I don't agree that's a valid rebuttal, as the operative word is the weasel copout "know what they are doing".
> PoSh is closer to read-only for most devs.
A read-only language is a language with a serious expressiveness problem. In contrast with, say, Python, which you need to go way out of your way to write code that's hard to understand.
Let's try a precise quality comparison, more for fun than anything. We have established someone knowing what they're doing makes any comparisons meaningless. I imagine you would agree with me that someone who "only kind of knows what they are doing" is even less helpful (what do they know? what do they not know?). So our last option is someone who does not know what they're doing, at all - they've never programmed before in their lives.
How many minutes of study would it take for them to decipher what a PowerShell program taken at random from the world of all programs written and used by human beings is actually doing? How about a Python script? How about a Perl program?
Most complete programs are short. Most complete programs do not use complicated data structures or algorithms. And most complete programs do something relatively simple, but useful to the writer. So one would expect T(PoSh) < T(Python) < T(Perl). I sympathize if that makes you groan.
Now, how many minutes of study would it take for them to write and use a PowerShell program, versus a Python program, versus a Perl program? Our hypothetical knows-nothing person is statistically probably running Windows, to start. That cuts down on the time needed to fiddle with installation - PowerShell is right there, whereas someone totally new to this could easily lose a week just trying to get either of the other two installed and running for the first time. That's probably going to swamp the calculation.
After they've got it installed, they will likely spend a lot of time Googling or GPT-ing around for code that already does what they want. This is likely to be straightforward no matter which of the 3 we're working with. But they will almost certainly need to tweak it somewhat to get it to perform exactly what they want to do. This is going to be tough in any of the above languages. The readability of PowerShell would probably let this person figure out how to tinker with it relatively quickly.
After they've written a few useful programs already, sure, they might want to switch to something else - but probably not; most people have better things to do with their time than rewrite something that already works. More importantly that moves them from "doesn't know anything" to "kind of knows what they're doing", which is not a category of people we can reason about in general - although, if we were to reason about this person in particular, it seems reasonable to suspect that whatever tool they started with would be the tool they would stick with, especially now that they've paid the one time cost of actually getting it installed and working on their computer.
> most people have better things to do with their time than rewrite something that already works
These people just went from "never programmed before" to "knowing how to program" - I doubt people that made an investment like this would "stop to the first tool" because "it works". Sure, they might not rewrite something that works, but they would wonder "is there a better tool to do the job?"
You can of course target "what is the minimum I can do on this and then be able to focus on my job" and never worry about other issues (could I have done more? could I have done better? is it extendable? is it maintainable? etc.) but that is more about how you view "your job". If you are a doctor and your job is "heal patients" then learning another programming language is not your job. If you are someone maintaining some tool written in a specific language, then learning another programming language is not your job. If you are a software engineer that can solve multiple problems, wondering if you should know another programming language is part of your job.
>HNers by and large don't understand the economics of PowerShell.
That's not true ...
PowerShell is the "lingua franca" for Windows system administration, I think everyone understands that. Much of the power of Powershell isn't the syntax (which is unnecessarily cumbersome), but rather that most core windows system services have PowerShell bindings.
Powershell isn't a tool you would use for Linux scripting and administration, because it isn't ubiquitous the way bash is.
So what exactly is your point? That Linux administrators adopt PowerShell? Or are you arguing a strawman that HNers advocate for using bash in Windows?
The reason why we use Bash on Linux is because it’s ubiquitous. Even though my terminal is ZSH, all my scripts will be Bash because I can trust it to run on any system.
Same goes for Windows, I want to make sure those scripts can be run without having to install anything. Powershell is there, and it’s powerful.
Python is better for anything complicated. Even though Bash is ubiquitous, it's kind of a pain in the ass, and it's actually not that portable since there is no real "standard library", and everything basically depends on system tools being installed and/or configured in a particular way.
python is also extremely fragile compared to something compiled
just setting up the python env to run the "script" requires a ton of bash (or simpler python)
of course it's true in all cases that if you know what's your supported/required/target environment is, then just a few lines of bash/python is enough. but the wider the spectrum of complexity one must handle the more it pays off to front load said managing, and distribute a compact and powerful program with few dependencies and as minimal complicated bootstrap steps as possible.
Amusingly for projects of medium complexity, Powershell is probably comparable or better than Python, on Windows, especially for sysadmin type stuff.
Powershell actually had optional typing from day 1 but unlike mypy & co, it's actually checked. As in, types were optional, you didn't have to write the down in the code, but if you did add them, using the wrong types would error out.
Powershell also has great integration with .NET so almost every .NET library is available if you need it and the deployment story is ok - Powershell needs to be installed and you can bundle everything else you need.
> Patient R was in a hurry. I signed into my computer—or tried to. Recently, IT had us update to a new 14-digit password. Once in, I signed (different password) into the electronic medical record
That's IT infrastructure incompetence, not an EMR issue.
At the two healthcare systems I go to, both utilize RFID badge readers plus PIN. In the ER and urgent care, nurses need only tap their badge and enter a quick pin and they're in. It's taken them seconds to pull up my records and I've never noticed a delay in care.
In the PCP's network, everyone seems to get smooth and quick access often while we're conversing, and I can see all my visits, lab results, and so on. The major annoyance is that I get emails notifying me I have a "message", instead of even offering me the option of receiving an email with the actual message.
I don't think people understand how expensive and time consuming the non-electronic stuff was. I remember my mother spending considerable amounts of time trying to get records from labs and doctors and having to shelp a lot of it by hand.
> That's IT infrastructure incompetence, not an EMR issue.
The two cannot be unlinked so easily when I have never met someone so doesn't have the same story of hospital IT. Even the IT workers hate hospital IT. The deployment of an EMR has to take into account the regulatory and security requirements imposed on all digital systems.
> I get emails notifying me I have a "message", instead of even offering me the option of receiving an email with the actual message.
Not gonna say it's not a bitch and a half to implement but you can send sensitive data directly via email. And if you're the SaaS provider you're part of DT that's a huge value add for your offerings.
The email thing is probably a privacy requirement. Email isn't encrypted meaning your email provider (and the EMR's) can fully read the contents of said email.
I think people want to waive that privacy concern. My email provider has access to tons of my private data including lots of health data. Given the option, I suspect many would prefer to just get an email.
No, it's absolutely is not a HIPAA violation if the patient requests email communication. But it's a common myth.
A patient can consent to receive protected health information over email or other unsecured channels as long as they are informed of the risks and consent anyways. Patients are allowed to communicate about their own health to whoever they want to in whatever manner they want.
Myth 3: HIPAA prohibits email communication with patients about clinical matters.
Fact: You can send protected health information by email, but you must implement safeguards under the security rule to ensure the information is secure, accessed only by authorized individuals, and not altered, edited, or deleted. The best way to do this is to encrypt your emails; however, patients have the right to request access to their own information via unencrypted email. You may send patient information by unencrypted email if you have advised the patient of the risks and the patient still prefers unencrypted email.
It's definitely not. As a patient, I can do whatever I want with my medical records. I can copy them right out of MyChart and put it on my blog if I want to. I feel like I should have the right to sign a form saying they can email me.
Agreed, I often email results to my spouse so they can review as well. I don't think many health care systems permit spousal access to results (although I can see my young kids' data).
My comment was implied aspirationally. US legal issues may (or may not, see sibling comments) prevent a provider from sending health info via email. If it was/is allowed, I think many would like to opt in (but never the default).
As I understand HIPAA (I'm not a lawyer), the patient can send info to the provider via email. In fact, since my last comment I emailed a test result of mine to my doctor (in the US).
Outside the US, email is sometimes used. I've had a couple non-US doctors send me my health data via email. I don't know which foreign laws applied, but I assume they were permitted to do so.
Yeah, as a patient I don't have any problem with EMRs. When I visit a specialist I can fill out all the forms and pay the copay online. The app notifies the office when you arrive, so you just sit down and get called in. I used to go to NYU Langone but switched to Mt. Sinai and all my records came over fine.
I'm a "visit the doctor once every 0.9 years" kind of a person, so I guess my needs are not incredibly complicated, but I've found the experience to be pretty fine overall. Good, I'd say, honestly.
I could see that badge system easily costing a million+ dollars, fyi. RFID identity management is an entire platform in itself and is extremely expensive.
Door access and stuff like that is orders of magnitude cheaper. Integrating identity with all the proprietary systems is crazy expensive, I specced it out for about 100 users and it was 10's of thousands of dollars just for the hardware and thousands a month for the software.
Note that Scotland got electronic medical records much more correct than England by making the whole thing a Clinician lead process rather than the English technocratic approach.
Finally it's very difficult to do "proper" scientific research on electronic health records, as control matched research is not achievable. Therefore you have to reach for things like single case study
Final brag - when I submitted my PhD it was politically quite sensitive so we had to find the right external assessors. One expert, one person whose judgement we trusted. The expert returned their report saying what a great piece of work it was and it should receive high commendation. The other person said it was solid and thorough but ultimately pretty obvious. Therefore I conclude that I received better than a high commendation for my work :D
Best outcome is when the people using these systems are the same people as those buying/specifying the systems. And best introduced with limited and constrained scope so you end up meeting the users actual needs. Pretty simple really and a tale as long as enterprise software itself.
I was looking to get Ozempic through a different medical provider. They were offering a discount at the end of 2023 before rates go up in 2024. So in a rush before the end of 2023 I was able to log into One Medical and get a copy of my lab work and medical records from them within 10 minutes. Sign into my account and export the records and lab work and send them to my new provider.
I was impressed I didn’t have to jump through a ton of hoops to get the info I need to get the medicine.
I used to work at an EHR software company. All of this is true.
The most interesting thing I think on the horizon is gluing the ever-increasing intelligence of AI bots with voice assistants. The company that can reliably take a HCP's dictation, store and retrieve that information accurately is going to transform the industry by drastically reducing the administrative overhead, and letting doctors treat more patients.
When my Israeli health care provider switched to electronic records in the mid-late 1990s, a typical medical appointment had two parts, roughly similar in length.
During the first part, the doctor would complain about how the system crashes, how hard is it to type with two fingers, and how computers are pointless. In the second part, I’d complain about my flu/cold symptoms.
The real reason EMRs are frustrating is that they attempt to provide structure around a chaotic underlay of insurance reporting schemes.
The way clinicians get paid for service is to report everything they do, in obscure and highly-specific codes. Practices on average have to consider arrangements with 25 or so payer entities, and must consider the varying requirements with each.
EMRs are still playing catch up, but there is hope. One of the best applications of AI is translation, something EMRs desperately need.
Healthcare CIO here, there are more major issues and much bigger ones in the EMR space than insurance.
One is cost, the compliance cost is so high that it's a huge barrier to entry, and makes new competition difficult. The limited sales channel means you need to charge each of your small customer base more to pay the bills.
Another is interoperability. They're all garbage in one way or another so all the vendors work very hard to secure client lock in.
Another is medical regulations. We have a whole mess of buttons and check boxes providers need to fill out for regulatory reasons.
Yet another is needing to create a complicated system to do complicated things, but the people operating it generally get little to no training on an EMR, so the learning curve is STEEP, and breeds problems.
I could go on all day. I kind of wish I could lead a startup to create a new EMR from the ground up. With what I've learned over the years I really think it's possible, but would need real investment up front.
I spent two hours this morning helping my elderly mother fill in a hospital admission form online. The session timed out just before submission, but we logged in again and everything was saved. I'm grateful that it was online, so I could help her remotely via screen sharing and not have to travel to fill in forms (I'll visit when she goes in, just don't want to have to travel repeatedly for paperwork.)
Entering medical history and current medications was a pain in the arse though, and is something we have done many, many times over the last few years. FFS just implement an standard text format that we can upload or link to.
Standards and protocols would go a long way in solving many of the issues in public IT infra. Force the big players to speak them. Enable the small shops to outcompete them (and each other) by sucking less in one area.
> Entering medical history and current medications was a pain in the arse though, and is something we have done many, many times over the last few years.
Isn't this something what electronic records should have solved? I know doctors always ask the patient but they all have access to that data here (not us). Especially the pharmacy looks at it to check for cross interactions (or a note waiving them).
The idea that patients take the prescribed medications is one that many people believe.
Another problem is that people believe the patient’s reply when they are asked what medication they take.
Having worked in medical software for a long time now, it's not surprising.
Medical software is purchased by upper management based on features. Usability is rarely considered, and hard to evaluate anyway since it depends on integration.
Hospitals themselves create this incentive because they will rarely if ever change their processes to fit more smoothly into a different workflow. The core purpose of an EMR is to integrate different parts of the hospital, though, so the only possible solution is a huge do-everything piece of software like Epic.
I spent years on a project to try to standardize exams between a major research hospital and its satellites. The ended up quitting about half-way through because they realized there just wasn't going to be enough political power at the main campus to convince the doctors at the satellites to follow their lead.
You'll even see this at smaller regional hospitals. We'll bring software and workflows developed in tandem with the top hospitals in the world, and they'll tell us that they don't care and they want to keep doing things the way they've always done them.
Everyone may hate EMR, but hospitals seem to be getting exactly the EMR they're asking for.
Related, I recommend watching Bill Gurley's talk [1] on regulatory capture from 4 months ago. It basically covers why the path to solving this is a difficult if not impossible one.
While I haven't worked with EMR systems directly, I have some experience working with care giver organisations, from the perspective of trying to use their digital records for analysis and prediction. My impression was that this is something nobody has time for, and therefore nobody is doing it, or even really interested in it. It would seem quite wasteful to have this big expensive machinery for producing data that nobody has time to look at. After all it's one of the big reasons to make it digital in the first place; being able to "crunch the numbers".
On the other hand, as soon as you get those numbers someone will turn them into "performance indicators" and use them for optimization, and we all know where that tends to lead... I can understand the feeling of being forced to work with a system designed to get rid of you.
I thought this was an excellent, excellent read. This post, about how well-meaning legislation to increase EMR usage had some strong negative unintended consequences, dovetailed with thoughts I've had a lot recently about the concept of "bullshit jobs" (a popular discussion topic on HN). I've wondered what the true source is for these bullshit jobs. After all, corporations voraciously want to increase profits, which should be a strong incentive to eliminate unnecessary jobs.
The conclusion I've come to is that the side effects of government laws and regulations lead to a negative "codependent relationship" between government and companies that exist to implement the complexity required by the regulations. There is no incentive on either side to reduce complexity. To be clear, I am not blanket "anti regulation", and I've seen the benefits of strong (usually simple) regulations - for example, I live in Texas (usually famously anti-regulation), and there is good evidence that old laws restricting home equity loans, due to an old animosity of Texas farmers against bankers, helped uniquely limit the damage of the Great Recession in Texas: https://www.aeaweb.org/research/charts/texas-home-equity-lim....
However, I've also seen the damage and useless work created by well-meaning regulations that create a lot of complexity, and then companies spring up to "tame that complexity". For example, most people in the US are familiar with FSAs, flexible spending accounts. There is a HUGE amount of work that goes into managing FSAs. The rules around what is a qualified expense are complex, and lots of companies have sprung up trying to work around those rules (e.g. companies that will churn out a "medical letter of necessity" for any massage you want). And all FSAs do is let you save taxes on medical expenses. But since FSA money is "use it or lose it", it turns out that 23% of the funds go unused every year! So all this complexity was created to save consumers money, but at the end of the day it ends up being (in aggregate) basically a total wash! All we've gotten is tons of administrators and companies that are paid to manage that total wash.
I don't have a great solution, as again, I don't see incentives on either side to reduce complexity. But more and more "tear down the whole f'ing system" is the only answer I see.
i design an EMR for a veterinary company based in LA. can confirm our care team gets quite upset with the software at times. it is incredibly difficult to build a great user experience for all the different positions and use cases that occur throughout the day. with that said, it has been a fun and rewarding experience over the last 4 years. we are hard at work bringing AI into the EMR right now.
> we are hard at work bringing AI into the EMR right now
I’m sure there are benefits so be had from AI in an EMR at some point, but many would see it as a vast upgrade just to have a system that responds to clicks, doesn’t lag and kind of does what it says it will.
I implement EMR’s and related software. They slow down the process of providing healthcare to the point that medical scribes - personal note takers / assistants - are basically necessary to keep things rolling smoothly.
I can say this has its flaws too... I was recently trying to pick up a prescription but the first pharmacy i visited did not have it in stock, they gave me my card back and i went to another pharmacy who could not find a prescription on the card. Turned out the first pharmacy forgot to "release" the prescription back after they told me they don't have it in stock.
Had to go back to the first pharmacy, have them unlock it, go back to the second pharmacy, only to be told after they could read the prescription that they do not have it in stock either.
The problem here is not the digitalization itself but the tangibility of the implementation. how could i possibly tell that i was wasting my time on my way to the second pharmacy?
With paper i would see that someone forgot to hand me back my prescription and i would not have left the first pharmacy prematurely.
There was a documentary around here (not-US) a couple years ago about the main EMR provider in the country. Because it's so onerous to install and set up a replacement (just a lot of demands and requirements), the market gravitates towards only a few "established" providers, one of which are overseas/US software that are infamous for their issues (Epic is the one that jumps to mind), but the focus was on the local provider.
The local one apparently is insanely expensive, doesn't have intranet support (because it started as some ancient Windows version as a surgeon-for-hires (the CEO of the company was one) payment record), meaning that hospitals have to move computers on wheeled desks around, lacks a lot of views for medical staff and the operator rolls in "service fees" for things that aren't fees and demands constant cash for upgrades that don't seem to change or fix anything. If a hospital indicates they're planning to replace any component, the CEO apparently just starts screaming and threatening to cut off the hospital out of their stuff entirely (which means that hospitals are unable to invest in startups that might provide the components they need).
It's pretty awful, considering the software is supposedly rather glitchy and has already resulted in numerous patient deaths due to inaccurate medicine prescriptions being loaded in (something which the company denies, but there's ~20 or so reported cases of this at different hospitals). I've heard doctors keep a second physical copy of any patient records, just because that system could screw it up and cause issues down the line, completely nullifying the use for it.
The one group who doesn't hate it: Australian patients.
New test result appears in your my health record app, the GP you are seeing has some crippled practiceware, you just show them your phone.
Telehealth appointment to renew a script because my GP isn't available? $20 and done in 15 minutes with an eprescription.
This won't solve the hospital space issues, but at this rate I can see "tap to check-in with your hl7 2.3 adt a08" as a semi practical workflow
Except that specialists (in particular) hate uploading results into the government EHR. They want to review test results and then communicate with the patient, and the only way to do that is to not upload the results.
I had to talk to the pathology supplier, then get a letter from the specialist approving it, before they were allowed to upload the test results that were bulk billed on Medicare.
There's no incentive to get specialists to change their record keeping.
I've also spoken to several friends that are leading specialists, they had a long list of reasons why it was a bad idea medically, but changes in workflow would solve most of them.
You may jest but I wouldn't mind this model. i.e. Records are under a digital lock to which I hold the key, and can grant access to a medical professional service provider for a period of time with set access expiry.
Written records at least provided some physical locality that made me feel less at risk, and it was also easy for me to ask for a photocopy for my own records (I'm surprised how many people just entrust this to their institutions).
the issue arises when you are unconcious and there are certain risks to treating you the staff needs to know about. Maybe your throat closes for benedryl but you're showing obvious signs of an allergy? Maybe you have a pre-existing condition which gives you symptoms that signal a stroke? the risk is always going to be there
They don't need my full medical history for that. Just a highlights or "in case of emergency" summary.
Humans dealt with these issues just fine before records were centralized. And still do e.g. when I travel to another jurisdiction. Being an engaged and proactive actor in my recordkeeping actually improves my posture.
I deal with the same issues when it comes to estate planning (e.g. what happens if I become unable to make decisions for myself). There are tactics and contingencies available (like trusted individuals, powers of attorney, etc) and I don't need my full financial background to be openly available to thousands of participants in the system to accommodate. Society and the concept of trust did not evolve over millions of years to end up becoming nothing more than an individual and a computer somewhere in the cloud.
My doctor was target of bitcoin extortionists. Now her system is so locked down and doesn’t interface with any other system. To transfer information to another system she prints it out and scans it into the new system
Overall, while we as developers often prefer to focus on complex software engineering challenges, it looks like here the core problem is the user experience of complex data entry/administrative applications.
Designing for so many different types of users, different (customizable) processes/operations, different organizations using the software, is equally difficult to any engineering problem.
Unfortunately, the area of user experience is still very much undervalued for enterprise software, especially by the financial buyers. And without buyers valuing these aspects, vendors will not focus on these aspects.
This article (and many like it) often mention how intuitive and speedy the Dept. of Veterans Affair EMR is. I can guarantee not a single one of these authors has ever used it. CPRS (the VA's EMR) is easily one of the biggest reasons physicians don't want to work at the VA, and most facilities have fewer patients per team (compared to academic or community hospitals) because of how much extra effort is required to use it. It is just startlingly bad.
Is it that EMR is bad or is it market capture. About the only company I hear about doing EMR/EHR is EPIC. My wife is a nurse, and in all the places she has worked it is EPIC. Every doctors office I've been to, its EPIC. It seems like EPIC pretty much owns most of the market, so there isn't any competition to really encourage EPIC to be better and there is no will for medical systems most of the time to choose an alternative to EPIC.
Sounds like people in a specific country, dislike a specific implementation. Clickbait.
In my country, we have and love EMRs. They enable me to change health authorities at will, as I move cities. They enable me to carry nothing, anywhere - including prescriptions. My phone can serve as my booking tool, and I have instant access to results (such as a blood test) at the same time as a doctor. EMRs enable activities - business and government decisions might limit them.
Centralization of data for me, in a socialist health care system, delivered by capitalist competition is ideal. It's allowed me to be a consumer, having my daughter's eye operation occur at a hospital far away, but her doctor, literally around the corner have access to all results, without my intervention. This is one of the best parts (by far) of living here.
I have worked for a company developing HMS/EHR and a hospital implementing/integrating these systems.
Before you think "my startup can do better" understand the core problem: legal and actual processes. Medical is heavily regulated, not only at the point of care, but likewise on the administrative side.
In the event of an adverse effect the hospital and medical team(s) involved must be able to provide clear track record of following the protocols. The administrative team must have the data to provide all the required metrics.
Suppose a simple bloodwork protocol: nurse draws blood, delivers to lab, lab does analysis, results are funky, lab releases invalid report indicating rejected sample, doctor issues redoing of bloodwork, nurse draws blood again and so on. Sample rejection is recorded somewhere, distorts statistics for admin, costs time. In practice, in the event of suspected badly drawn sample nurse is internally informed of that to redeliver the sample, lab releases clean report, sample vial is recorded as discarded by nurse, business goes on.
Medical is FULL of these tiny optimizations around protocols. However, any HMS must follow the protocol, implement safeguards against divergence from protocol, yet to be user friendly it must accommodate all those deviations while still providing "correct" track record with eventually consistent timestamps and so on.
Timings can be very important. For example at ER priority levels dictate not only queue ordering, but also time to care. With HMS implemented it becomes crucial to record times correctly (both from CYOA and metrics standpoints), therefore from the perspective of user, the HMS becomes first priority over caring for patient. Users inevitably complain :)
In certain protocols timings also play a huge role in determining care type. Discharge a patient in x hours and it is outpatient care, fail to discharge patient in x hours and the case promotes to inpatient care, with all the associated complexities of care and documentation. Patient returns in x hours - it's the same case. Fail to provide care in x hours - different treatment protocol.
Readers may think "just provide sane defaults for common case and let staff explicitly record uncommon cases". That simply does not work. Defaults are defaults and users submit defaults. Having insane defaults actually prevents hospital admin/it/legal from being overwhelmed with correcting submitted data. Users complain.
It's ugly. You have to juggle between good care, actual processes, legally required processes, metrics and what not to make the system usable and correct where every user is adversary.
EDIT to add:
On top of all that, every hospital has unique implementation of processes and structures. The differences may not necessarily be major, but there are differences.
Any HMS that intends to become a commodity instead of custom project for a single hospital or department must be highly customizable. first, high customizability typically misses optimization (especially workflow optimization) opportunities. Second, implementing HMS is akin to implementing SAP: the end result is amalgamation between core product developed by a vendor and implementation by hospital admin/legal/it. Many here have either first-hand experience or close knowledge why implementing ERPs (HMS is an ERP) typically lead to barely usable monstrosities. The stakeholders at organization typically have neither working understanding of underlying processes and policies and how they tie together nor will to implement processes and policies more suitable to be managed via ERP.
Apple Health does a great job of integrating with EMR providers. I can see notes from every doctors visits, my blood test results, Covid tests, and so on all integrated into one app. I can see my sodium levels have gone down since 2019 in a plot chart, or when was the last time I got sick.
The thing that most people don't realize is that the legally enforced HIPAA protections they take for granted no longer apply when they request their medical data from a healthcare institution and store it in a third party app -- like Apple Health.
The only thing protecting your medical records from being data-mined and monetized is Apple Health's privacy policy and (current) technical architecture. You've seen examples of it in the news with women's period tracking apps, but it'll become even more common as apps start leveraging APIs opened by the 21st Century Cure's Act.
I'm not a tin-foil hat wearing engineer, but I can forsee a day when Apple's reputation of being "Privacy-conscious" might not be worth as much money as the medical data they've collected from their customers.
It's one of the reasons why I decided to build my own open-source PHR, so that the incentives between the software and me as an individual are kept in alignment.
Like other comments here I also went down the road of making an EHR system a number of times. It's not worth it. Competing with the hell scape that is Epic (not Epic Games, but another EMR software) is seemingly futile.
This is what the so called Free Market brings when combined with anything medical. It's a mess of systems that are incompatible with every other system, creates more work for everyone.
Wow, this is all over the place, not worth reading. Also it fails to point out a critical and very confusing distinction: EHR stands for "electronic healthcare record," as in an individual record / file / document, but in healthcare tech "EHR" usually refers to "Electronic Healthcare Record System" - a product like Epic / Athenahealth / etc. Also surprisingly no mention of the semi-garbag-y healthcare data interchange format FHIR.
The author seems confused - confusing issues with EHR system UX and data entry and data fidelity and interoperability itself.
When I watch people use them, the UIs look like information overload and cumbersome for the user. It's just old corporate database development: Develop the database, then dump all the fields into a UI. Add some section headers. I would resent using that so often every day.
> There is an illusion that technology automates work—instead it only changes it.
That seems like an odd statement. For example, some technology is automating delivering this text to HN servers, and then to you. HN wouldn't exist without that technology.
There's actually a "Patient-contributed data" initiative being run by the standards body (HL7) that's gaining traction.
In an ideal world it would allow patients to "push" their electronic records to a new practitioner, meaning that intake forms could be much simpler. In practice I think the implementation is going to start with Observations/Lab Results first though.
I hope to eventually support it with my open source personal health record (PHR) Fasten Health. IMO this would be a "killer app" for PHRs.
> There is an illusion that technology automates work—instead it only changes it.
And a number of follow-up attacks on technology totally in the spirit of Jacques Ellul.
My wife is a physician, and through her and some of my personal experience of working with hospitals, this is how I understand the problem:
* Programmers who write EMR systems critically lack the knowledge of how hospitals or physicians operate. There are multiple causes to this: the process of writing such software isn't a grass-root movement. It's heavy design-first of large, well, huge systems before they are implemented by grunts who never have any idea about how the whole of the system is intended to operate or even how the tiny slice of it they work on is supposed to be used. I should know this, since I was one of those.
* Doctors despise programmers. Doctors also don't want to be programmers. To a typical doctor, a hospital's staff programmer is similar to a medical secretary: a hoop they need to jump to get their work done rather than an actual aid. Being a programmer, try advising a doctor to do something differently, even if that's about how they use their computer, and be exposed to an hour-long lecture on how they studied for N long years, and how their education was so much more intense than yours, and how they had to endure and so on. Of course, doctors see doing programming work as being beneath them.
So, what happens is that instead of interfaces that could enable doctors to be productive at using their computers, they get absolute garbage that's impossible to automate and requires arduous manual labor. I.e. if doctors wanted to learn how to use SQL to access their hospital database, and, let's say, were able to write some short scripts that automated patient processing, communication with other departments and so on, they'd be spending way less time in front of their systems. But they don't.
Instead they get MS-Windows-styled GUI garbage. Impossible to automate, with the source locked away from them, written by someone they couldn't bother to meet and chat with for an hour because their paycheck likely has an extra digit.
My wife being in radiology department reported that, eg. most times patients are sent to them, even inside the hospital for some imaging, they don't get their forms properly filled by the sending doctor. Not only the sending doctors don't know how to fill those forms correctly, they don't want to know. An incorrectly filled form will result in the radiologist calling them back, and they'll be able to communicate what they want done to the patient in this way. It's both because the forms are too inflexible, because there's no trust in the system, and, especially that even if the form is filled correctly the receiving end might not know how to process it correctly.
And this doesn't depend on the country. Countries with mostly uniform, long-standing healthcare systems suffer the same fate.
----
To me, it's clear that the change that needs to happen is that doctors need to become more like programmers. It's unfortunate that they need to spend so much time learning their trade, and it seems like on top of that they need to study something far divorced from the rest of their main subject, but I don't see any other way.
It's not about technology failing doctors, it's the doctors who don't want to embrace technology.
My time to shine. I work in the healthcare industry as an analyst and deal with all types of EMRs, Databases, and Molecular profiles. Before working in the healthcare industry, I would have assumed that the data quality in healthcare would be higher because you know, data quality errors can negatively effect patient outcomes. This is not the case.
A lot of these issue lie (lay?) with the UI of these systems. They are just not intuitive. This causes data to be entered incorrectly as honest mistakes. There are also fields which are free text, which should not be. I can't count how many times, I received data from a free text field for drugs, for example, and instead of information about drugs it said "The patient's pet passed away and they were sad today".
Furthermore, a lot of the data comes in separated value files, mostly CSVS (though I try to have them use TSVs if they can modify it). For such a ubiquitous format, at the volumes of data we receive, we get issues with the CSVs all the time. Lots of fields have strings that are improperly quoted, newlines in the strings, variable amount of fields per line, the usual.
That's on top of encoding issues. Randomly we will get files that aren't utf-8 and our parsers will blow up, and then we have to go back to the vendor and ask them to regenerate the data. Also trying to harmonize data across a bunch of proprietary file formats, and software is terrible
Also physicians and nurses are generally pretty skeptical when it comes to new technology even if you have a good product, and for good reason. They have been BURNED many times but companies coming in and promising the world, and delivering a half baked product. Anyone can get an MVP together quickly that kind of does what they need done, but to really support end users requires a lot more investment. I'm talking on-site trainings, software engineers actually watching the faculty USING THE TOOL, and taking notes when they struggle, being proactive about the wants and needs of the staff instead of adding features that seem useful. This almost never happens
Then there are factors outside of just EMRS and the user experience that just make the patient experience much more difficult, even when everyone involved is following standard practices. Data is king in this space, and companies are reticent to share it without lots of money and an books worth of clauses and agreements. You can win in this space just by having more data, or rare data. Lots of patient populations for obscure diseases require large sample sizes before you will have enough patients to perform a study. Pharma companies will approach you with prospective studies and the more data you have the more feasibility work you do that end up leading to studies where you get paid, and your name on paper. This HURTS patients and does nothing but help to keep competitive advantages.
On the bright side, since the U.S healthcare system is so capitalistic, we can usually find what we need coded in the billing data, because patients are nickle and dimed for everything that happens at a medical facility.
I have about twenty more pages of things I could talk about. This whole system is terrible and it doesn't have to be. On a more positive note, I love being able to track patient outcomes and see them improving, and I really enjoy working with huge datasets.
Disclaimer: The electronic health record system in the united states is a mess. A monolithic monstrosity lacking interoperability, touching the most sensitive data, and leading to the worst possible outcomes if errors occur.
That being said, as someone that works in healthcare technology, has done clinical shadowing of physicians, worked the admin side of healthcare providers, worked technology for payers and providers, and has multiple close relationships with front line healthcare workers: I think this article missed the mark in several places. I've interacted enough with nurses and doctors to recognize rants about electronic health records and how they come from a valid place but use many poor examples.
1. Theres a weird implicit assumption throughout the entire essay that EHR implementations are uniquely bad in introducing friction and errors to the medical system. Take the example of his electronic orders to the lab and lamenting how in the old days that would be a simple note to lab on paper and that was somehow inherently better. As if errors around misreading notes or misplacing them didn't occur beforehand.
2. "There's an illusion that technology automates work - instead it only changes it". This is a faulty premise. There is a lot of work that has been completely automated away within healthcare not just changed. EHR enabled patient monitoring comes to mind. You can remotely capture and store vital signs for patients instead of rounding to each room and writing them down. With staffing shortages for all jobs in healthcare we would probably be in a much worse place if we were still relying on paper.
3. "There is also more clinical work. Increasing corporatization of medicine and staff shortages have increased the volume of patient care for each healthcare worker, accelerated since the pandemic". There is definitely blame on admin for some of this but there is also artificial limiting of the number of new doctors each year by the AMA and it's lobbying. If there were more medical professionals I suspect that much of the "burnout from EHR's" would decrease. Add in the authors vitriol for a profit maximization even though profit of a health system allows them to hire more and pay more to compete with other industries for workers.
4. The author does not understand why the technology is implemented in a specific way. He is one stakeholder - the doctor and while an important one is not the only one that needs the data generated by a clinical interaction. Example: his complaint for there being multiple lab types for HIV in a drop down for ordering. This is specifically to reduce ambiguity and resulting medical errors, allows for more precise audit and reviewing of a patient's history, and carries a different cost for billing. He also blames EHR's for issues with different implementations of UI and workflows between hospitals even though most times hospitals are to blame for adding their own customizations.
While the author brings up good points he has an explicit bias against the current system even when it doesn't deserve the treatment he gives it. Most of the piece is generated more from a hatred of capitalism and a desire to refute the libertarian paternalism that he talks about rather than a fair and even treatment of the problem with the electronic health record system in the United States.
The seventh paragraph, "While medieval Islamic hospitals operated in the contemporary sense..." is pure meanspirited propaganda and renders the article repugnant.
