3 ms·
I'm super biased admittedly as I have worked on the implementation side for these big systems but... Try to ask those same friends to agree on the "correct" wo
by shigawire 2y ago
I'm super biased admittedly as I have worked on the implementation side for these big systems but...
Try to ask those same friends to agree on the "correct" workflow for some aspect of their clinical work. You won't find agreement in the same state, in the same hospital system, in the same hospital, or even in the same department.
I can't claim what is out there is great, but it's like that quote about democracy. It is a terrible system but the best available.
Making something like this open source could work, but whenever this comes up on HN it seems like people think making it open source magically makes it better. It's not technically complex, just organizationally complex to find agreement - and I think open source would make that aspect harder.
- lostlogin 2y ago> It's not technically complex, just organizationally complex to find agreement Assuming you’re talking about the EMR and its records, I think that quite a lot is technically complex as well as being organisationally complex. Without a deep domain knowledge it can be hard to tell if something is needlessly convoluted or actually complicated and healthcare conflates the two all the time.
- Taikonerd 2y ago> Try to ask those same friends to agree on the "correct" workflow for some aspect of their clinical work. Does that argue for a two-part design like: 1. APIs for scheduling, billing, lab tests, etc. These are standardized across all health systems. 2. "Workflow" code for a particular health system. This is custom.
- nradov 2y agoThere are already standard APIs defined for all of your item 1 from HL7 and ASC X12. Some of them are messaging APIs rather than HTTP/REST/JSON APIs so they can be a bit daunting to new developers. Most modern EHRs support those APIs but it can still be a huge amount of work to build interfaces to other organizations.