I feel the other comments are really first-world problems.
As a doctor from a developed country, the worst piece of software would be my hospital's clinical portal. Not only it is painful to use, I believe the inefficiency it causes actually is detrimental to patient's care and the health economy in general.
I happen to know some web development, so here's a few observations from top of my head:
- Slow speed. Simple page changes takes at least 1 seconds, others such as viewing lab results or clinical letter takes around 3-5 seconds, but often needing repeated clicks to actually work.
- No form autosave & inconsistent saving behaviour. I have had to re-write discharge summaries several times because of save failure. This taught me to write on notepad/Word first and then transfer onto the portal.
- Many buttons are deeply nested in a navbar. Sometimes the nested buttons fail to show up at all on very small or large monitors. We have to resize the window size to find the dropdown button.
- Front-end CSS framework is based on YUI (discontinued since 2014). It supports IE quite well, but breaks on current Edge, Firefox and Chrome.
- The app tries to stop clinicians from opening more than one instance of it, but this often results in us unable to open any instance of the web app at all. Fixed with incognito mode.
- From the occasional server crashes, I can tell from the debug callbacks the backend is written in Java. The point here is that the debug trails are shown rather than a 500 error, which is unsettling for a sensitive data platform.
- Fragmented ecosystem, every part of the portal is an iframe from a different provider. Lots of inconsistencies and crashes. Even the sidebar is an iframe.
- Printing is a nightmare. Whatever sent to the printer often doesn't show up, but that's a story for another day.
I'm sure there are bigger ones I've missed. Unfortunately, the system we have is not the worst in comparison (in one rural hospital I worked at shut the web server for 3 days for a database upgrade). This makes using Outlook, Teams and other stuff a breeze in comparison - they are actually snappy and stable.
Do we have anyone in the community that can enlighten me on the root case?
> Do we have anyone in the community that can enlighten me on the root case?
The technical root causes are pretty boring really. The root cause is the way that software purchasing happens in sectors like healthcare, education, government.
Your portal software undoubtedly cost an eye-watering amount of money, almost all of which went to middlemen while the actual software was built by an outsourcing company probably in a market with very cheap low-skill programming labour, who have probably developed a specialty in taking advantage of unclear requirements to get paid even while delivering a turd.
The middlemen have great LinkedIn profiles and many contacts in the healthcare industry, and the software works (the only people complaining about it are the people who actually have to use it, but thankfully none of the people responsible for buying this software actually have to use it!) so the work keeps rolling in.
Sounds like a mess. If each piece is from a different provider, who put it together?
I've seen what my doctor uses and know from relatives and friends what a pain it was to implement. And this is one of, if not the leader in clinical software. It was an "epic" disaster but now it seems ok-ish. Very user unfriendly still, but I'm sure it gives the hospital administrators the ability to spy, err I mean generate reports.
I happen to know some web development, so here's a few observations from top of my head:
- Slow speed. Simple page changes takes at least 1 seconds, others such as viewing lab results or clinical letter takes around 3-5 seconds, but often needing repeated clicks to actually work.
- No form autosave & inconsistent saving behaviour. I have had to re-write discharge summaries several times because of save failure. This taught me to write on notepad/Word first and then transfer onto the portal.
- Many buttons are deeply nested in a navbar. Sometimes the nested buttons fail to show up at all on very small or large monitors. We have to resize the window size to find the dropdown button.
- Front-end CSS framework is based on YUI (discontinued since 2014). It supports IE quite well, but breaks on current Edge, Firefox and Chrome.
- The app tries to stop clinicians from opening more than one instance of it, but this often results in us unable to open any instance of the web app at all. Fixed with incognito mode.
- From the occasional server crashes, I can tell from the debug callbacks the backend is written in Java. The point here is that the debug trails are shown rather than a 500 error, which is unsettling for a sensitive data platform.
- Fragmented ecosystem, every part of the portal is an iframe from a different provider. Lots of inconsistencies and crashes. Even the sidebar is an iframe.
- Printing is a nightmare. Whatever sent to the printer often doesn't show up, but that's a story for another day.
I'm sure there are bigger ones I've missed. Unfortunately, the system we have is not the worst in comparison (in one rural hospital I worked at shut the web server for 3 days for a database upgrade). This makes using Outlook, Teams and other stuff a breeze in comparison - they are actually snappy and stable.
Do we have anyone in the community that can enlighten me on the root case?