[CaptSpify]

This isn't isolated to doctors sadly. You see this in any medium to large organization: schools, cities, companies, etc. The problem, the way I see it, is that management is the one really being sold to.

The actual people who do the day to day work have no real say in which software systems they use. Only management has any real say, so sales people tailor their pitch towards management. Unfortunately, managers only have a high-level overview of what the people below them actually do, and no understanding of software, so they have no idea what they need their software to do.

And situations like this are where sales people shine brightest. Sure, the new "cloud-based, totally-super-secure, widget producer 9000" won't actual be useful at anything, but it sure looks cool to management.

Look at companies like Oracle, and Microsoft for good examples: Their actual products are awful, but that doesn't matter. What matters is that their sales team can sell a shit product.

[analog31]

This was once described to me as the Law of Enterprise Sofware:

All enterprise software sucks, because it's sold to administrators, not to users.

The managers see the purpose of software as improving their own workflow (tracking, data gathering, compliance) as well as controlling the users, not (gasp) empowering them.

Compounding the problem of enterprise software is customization. A person who works at an EHR vendor told me that every clinic system wants to develop their own bespoke workflow, in search of slightly higher efficiency, and so the thing that the user actually sees is not a well engineered system, but a hodgepodge of screens and forms that were designed at the last minute. My friend said that the user experience is a lot better at sites where the customer uses the off-the-shelf implementation with little or no customization.

[logfromblammo]

I worked at Epic, and while I was there, I can confirm that a huge number of workers were fresh out of college and making crap customizations, for every single customer we had. If a salesperson ever told a customer "no, that can't be customized", they might go with another EMR vendor. So every bit of user choice added by the developers and the staff physicians was eventually taken away by customizing administrators turning optional into either mandatory or forbidden. It was completely ludicrous. One part of the company was building software to be used at theoretically any medical facility, and another part was busy turning it into many shards of software that could each only be used in one location for one customer.

And on top of this, the software used to customize the base software was esoteric and required extensive training just to change the resource strings. This was before i18n, of course, but I have no reason whatsoever to believe that made anything better.

The whole thing was--and probably still is--held together by huge gobs of money. If Epic were in any industry other than US healthcare, it would have been bankrupt a long, long time ago. My experience has led me to believe that if software developers had any significant union membership in the 80s and 90s, able to enforce minimum standards for development practices, health care costs today could have been 3/4 of what they actually are now. We are now paying for jobs that could have been completely automated by 2000, and its because Epic and Cerner and GE and all their competitors have been shoving technical debt--in the form of bullshit customizations--into every deployment for decades, at the behest of administrators who were understandably reluctant to authorize the purchase of any product that would automate them out of their own jobs.

And it just gets worse when you add billing integration, because then Medicare and the private insurers get involved...

Got out, didn't look back. Don't work in medical software if you love programming and don't want to spoil that.

[cakes]

This is very true. I'd see this in software I worked on integrating ERPs where we'd have support for like 5-10 custom fields.

The best workflows were those were the custom fields were used and just had a nice label (e.g. "Old Customer Id") and not the workflows where some consultant had created an additional UI that didn't even use the underlying fields and did something like write the data to some unrelated storage mechanism and then building reports that are trying to awkwardly mix and match these data sources.

[CaptSpify]

> Compounding the problem of enterprise software is customization.

That's kind of the same-but-opposite of my experience.

When software tries to control how it's going to be used, it fails spectacularly more often than not, ime. The best software that I've used always leans into the problem: They let me access it via a dump. Then I can manipulate it as I need, then upload it back in.

But when those that don't understand the workflow try to tell developers how to design software, it usually ends up in a big mess of workarounds just to get the basic use-case to work correctly.

[rustybelt]

This does not match my experience in healthcare. I've gone through the EHR vendor selection process at several community hospital systems and it's always been led by one or more physician leaders who have an incredible amount of influence on the final decision.

I think the bigger issue is that an EHR is not one piece of software, it's 100+ applications are bundled together under a single name. It's a registration system, a billing system, a coding system, a data warehouse, a surgical system, a physician's office system, a scheduling system . . . It's inevitable that some of these applications will be better than others, but that's the sacrifice you make for the cost savings, consistent support, and guaranteed interoperability that comes with going with a single vendor.

Not to mention that with a medical staff of hundreds to thousands of highly opinionated, highly intelligent providers, you're never going to make everyone happy.

[sillyquiet]

Ha, to torture it a bit, I think this can be even more generalized to include more than enterprise software - furniture, office spaces, office design, ALL are sold to the c-levels and their support staff and not the people who work in and with those decisions.

[Sharlin]

Yes!! I recently read about a new hospital wing or medical center or somesuch where they had – gasp – involved actual future users (ie. medical personnel and patients) already in the design phase! This was regarded as something revolutionary and almost unheard of.

I also read about a similar project, ostensibly designed using latest principles and understanding of hospital work, which unsurprisingly turned out to have a zillion papercuts and completely impractical design decisions. So, yeah.

[rustybelt]

I've been involved into several major hospital construction projects in the last ten years, including the design, construction, and move of an entirely new replacement hospital and including front-line staff in the design process is pretty standard practice. Getting humans to all like the same thing is hard.

[Scoundreller]

It could be that people are happier with something they were a part of building, even if it’s not better.

Though change can be difficult.

The very article posted that new functions in the EHR increased deaths by 0.11% per function in the first year, but then decreased by 0.21% per year.

[maxxxxx]

Very true. In my company they are planning another office redesign and the people sitting in that environment had zero involvement. Our role is only to be cheerful once the new plan is revealed.

I have made a few practical suggestions to the facility people in the past always gut shrugged off.

[gglitch]

Eh, I don't disagree with everything you said, but the essay links to a fascinating article by an anthropologist who spent 18 months with a group of physicists using and developing a modeling system called Fluidity [0] that presents a different picture. The article is thoughtful and well-balanced on the problems associated with what the author calls the "piecemeal" growth of an application as its user/developers add more and more features with insufficient "bureaucratic" regard for software engineering quality control practices.

A lot could be said about it, but in any case, it's certainly not a management layer responsible for the degradation of the system.

Edit: forgot to include the link. [0] - https://www.mitpressjournals.org/doi/abs/10.1162/POSC_a_0018...

[pimmen]

I whole heartedly agree, and if newer computer programmers don't believe that's how the sausage is made they could either start working as a consultant or ask their consultant friends about the inevitably awful software they use to log their hours. The reason it's awful is because at no point has a consultant's work flow ever been considered during development. At no point has a consultant ever been present while the software was sold. The consultant isn't the customer, or even the end user in mind, it's the financial departments who get to turn all those hours logged into nifty charts.

Imagine that's not a consultant anymore but a doctor, and he or she is not entering hours worked but medical stats. Sleep well tonight.

[threatofrain]

I feel that companies selling B2B think of high-level executives as having incentives to deliver "something that wins", but they won't be around years later when it stinks. The company structures themselves accordingly by delivering fast productivity now, but skeleton crew later.