I think there was a YC funded iPad EMR startup that tried to be cool / hip / provider first until they got smacked in the face by reality.
This.
Once I worked making healthcare software that would basically save costs by avoiding complications. We were bidding into a large hospital network. After the long sales cycle, we checked the most boxes, clinicians liked the feel of ours the best, they said ours was the most intuitive, helped them do their job the fastest, etc.
The clinicians weren't the ones writing the check though.
Our competitor approached the main insurance provider in the area and convinced them they could save x% in additional claims if the hospital network would adopt their software. Competitor's deal was to split the bill between the insurance company and the hospital network. To the admins writing the checks, they had the choice between two vendors that more or less did the same thing but one came in at half the cost. Clinicians' preferences didn't matter, it was a no brainer for them.
No amount of software engineering would have saved that deal.
In part I think it happens more commonly because there is so much "other peoples money" in healthcare. Everyone is spending from someone elses checkbook and so transactions seem very distant.
Also, compliance doesn't fully explain why competitors are able to convince clinicians to switch systems. Word-of-mouth means that people will know your EMR is a flaming piece of garbage, but (as you noted) companies would much rather cut up-front prices so they can milk an extended contract than improving product quality. All that said, I think there's a bit of a chicken-and-egg thing going on here. Good people don't join the space because the culture sucks and the pay is bad, but those are because those with the talent and drive all self-selected out of it. I get it, health IT is a huge drag and not at all sexy. But just look at how often folks on HN ask about "doing social good" and how many complaints there are about healthcare delivery. Trying to run a "disruptive" VC-backed startup is IMO pretty crazy, but contributing to an OSS project is far less risky and more achievable.
The problem is that the Venn diagram between the people who actually have to use or administer the EMR and the people who decide which EMR to implement is basically two entirely-disconnected circles.
That said, I don't really recall the doctors themselves using an EMR much, either; they'd usually punt that to assistants and/or nurses. Probably different in smaller practices/clinics.
I would like to see the US Digital Service continue to task technologists with improving EMR systems at CMS (Centers for Medicare and Medicaid Services), but made free to use by all practitioners and citizens (and of course, open sourcing the resulting codebase). It seems sort of inefficient we keep reinventing the wheel (Epic and the like, which are crazy expensive, or self hosted solutions, when practitioners should not be spending time maintaining EMRs), when your records should be stored for your benefit by your government over the course of your life. This is where, imho, high calibre engineers provide the most leverage (one way ratchets on public goods at scale).
[1] https://www.usds.gov/resources/USDS-Impact-Report-2020.pdf
Also, with Veterans Choice, I don't know how much there was an effort to bring this data back. Same thing with the DoD, for a while there was an agreement to send medical records for active duty to the VA, but then that got pulled for a time.
I believe there was a huge undertaking to consolidate these to fewer systems in the last few years, but Vista[0] (the VA's EMR) is pretty scary. I wouldn't wish it on anyone.
The file format itself seems like a bit tough to parse, but the concept I love.
why do you say that? From a doctor's perspective, Vista is one of the more user friendly EMRs.
EDIT: Still a win I suppose if it improves care delivery over the status quo. Nice to know there's still some progress on this front [1] [2]. Looks like I owe OpenEMR a financial contribution.
[1] https://news.ycombinator.com/item?id=25040076
[2] https://playbook.cio.gov/#play13 (Digital services playbook: Default to open)
There are just some things that “throw devs (of any quality) at it” just doesn’t work. The health care industry is one of them.
And yes things are changing at a glacial pace, but they are changing. For example, my province is developing a new patient portal [1] out in the open. AFAICT, they seem to be doing everything aboveboard: CI, code quality standards, documentation and proper testing, etc. Yet if you look at another team in the same org (ministry of health), you'll find non-existent dev practices, oodles of VBA, or (even worse) some slow+buggy third party system put in place by one of the procurement vampires (IBM, CGI, Deloitte, you know the bunch). The biggest difference? The former project has a dedicated, US Digital Service-style team of skilled and hopefully better-compensated dev(ops) people who know how to deliver good software.
These people have three things on their mind (in no particular order): 1) does this product meet this organization's requirements under our regulatory compliance policies; 2) does this product (including installation, maintenance, and training costs) fit within my budget; 3) is this product widely known and trusted by my peers at other medical practices.
Notice something? The word "software" doesn't appear in that even once. They literally don't care. The result is that companies develop products (software) on the cheap, and that results in the quality issues that exist.
Improving the quality of the code base and development practices is solving a problem the purse-holders (customers) don't have.
Some complaints/feedback I did receive from doctors and clinic admins while working for an EMR vendor:
1. Your system is buggy/unintuitive and we hate using it.
2. We're not upgrading or moving to your new system because of 1).
3. We're moving to competitor X because they have Y feature.
4. [conversely] We came from competitor X because their EMR is slow/buggy/lacks features.
5. We signed up because the docs/office assistants liked [hero feature] in the sales demo.
So yes, 0 mentions of the word "software". However, all of these are directly related to the software itself. There's a reason flashy new companies can swoop in and steal some market share (at least where I am). Even more importantly, there are many tech-related reasons why some companies start floundering and drop out of the market:
- bad foundations (most EMRs were created by doctors with limited dev experience)
- rampant tech debt driven by feature-driven development
- lack of knowledge about testing/CI
These are not theoretical problems. More than once, we incurred regulatory fines and SLA penalties in excess of the "cost of doing business" threshold. After a pretty major patient data screw-up, upper management even relented and gave the dev(ops) team time/money to clean up their act. Regulatory and bureaucratic inertia may insulate health IT companies from software engineering issues, but there's a limit to everything and they can sure as hell bleed.
Just want to add: I work with (ex-)FAANG folks on a daily basis, too. Not all of them have egos bigger than their britches. But the ones who think “this industry just needs better software, and I can write it” sure as hell do.
Epic will _happily_ interconnect with other systems for data sharing.
I mean Epic will happily _sell_ you interconnects with other systems, and will generally bill you on top a per patient, per export fee.
As with anything in the b2b healthcare space, most of these systems suffer from quite a bit of legacy and at-best-average code quality. Despite that, many doctors, clinics and even small hospitals use them because the private solutions (think Epic [1], but smaller) aren't necessarily better code-wise (don't ask me how I know). I wish more FAANG-calibre devs would look into contributing to and evangelizing these platforms rather than writing yet another note-taking/"productivity management" app. It has a direct impact on the quality of care delivery in certain parts of the world and a positive impact on tool-related clinician burnout [2].
[1] https://news.ycombinator.com/item?id=18735023 [2] https://news.ycombinator.com/item?id=24336039