3 ms·
Speaking from a US perspective: I'll just add onto the point about EHR/EMRs being generally pretty bad. It's like medical IT is about 20 years behind in terms o
by lofatdairy 4y ago
Speaking from a US perspective: I'll just add onto the point about EHR/EMRs being generally pretty bad. It's like medical IT is about 20 years behind in terms of tech, so I'm not surprised to see that it's contributing to an overall inefficiency in the medical space. On one hand, you have Epic's EMR, which is easily the best in the industry, and reasonably feature-rich and appears appreciated by doctors in my experience. On the other hand, you have almost everyone else, down to utter dogshit like eClinicalWorks (apologies if any employees frequent this forum unless you work in UI/UX, in which case kindly consider a career change), which essentially exists to allow less well-funded operations to meet regulatory requirements (despite the fact that they're literally being sued for failing to meet this bare minimum [^1]).
I'll just quickly add on that if you want to write software to connect your EMR/EHR you're in for a bit of a pain to say the least. There's essentially a whole middleman industry for various data solutions like APIs or on-prem SQL databases[^2] that somehow managed to get vendor status with one or several EMR companies or managed to find the obscure way of actually accessing the hospitals' own data. I'll note here too that 1. sometimes the data is stored on site, so you should be able to read it off your own server, but I imagine a decent number of places treat it as SaaS which makes the task more difficult and 2. that I think EHRs should follow the FHIR spec but whether you can openly communicate with the software along this is another problem. I haven't tried to work with Epic, so maybe they're kinder.
I know this isn't really the point of the article, but the tech infrastructure around medicine really is shockingly poor. There's a lot of problems with inconvenience (handwriting really is often _that_ much faster than typing stuff into software especially when the software is so un-ergonomic), double-entry (since a lot of operations weren't designed with technology in mind), and lack of inter-operability. Combine this with outdated software infrastructures (I've seen Drs still use windows 7 on hospital laptops since that's the only thing their sw runs on, I've also seen a weird OS that looks like a 98 clone with less features and far slower on modern hardware), annoying problems like shitty WiFi in hospitals, really high stakes since it's patient data, and regulatory pressure - you end up with a system with little new competition, which means no innovations except in extorting hospitals.
Apologies for a long rant, but there really is a need for talented developers to work on these sorts of problems, because the current situation is like being forced to either have mountains of paper charts (I visited a small clinic that does exactly 1 operation and they had an entire basement filled with shelves of charts) or use some terrible software and likely have your data locked into it.
[^1]: https://www.fiercehealthcare.com/ehr/eclinicalworks-ehr-class-action-lawsuit-onc-certification-inaccurate-medical-records https://www.fiercehealthcare.com/ehr/eclinicalworks-ehr-clas... and https://www.healthcareitnews.com/news/eclinicalworks-sued-nearly-1-billion-inaccurate-medical-records https://www.healthcareitnews.com/news/eclinicalworks-sued-ne...
[^2]: Admittedly it's not always clear _what_ they're selling. One rather dubiously named "datasheet" lists "designed to be flexible to support definition changes in an AGILE fashion rather than via a prolonged software development and release cycle" as a feature despite the product being just a MS SQL server with data cloned from the EHR