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.
Hulu used to do this, but they'd give a free month. All I had to do was remember to find the cancellation flow once a month and I got it for free for almost a year.
Actually, the author's use of the colon is correct, and your interpretation doesn't accord with the usual rules of grammar for colon usage.
What I assume you're thinking of is the journalistic use of a colon as shorthand for attribution, normally used in headlines. In that case, the colon and person/organization fall at the end of the sentence. So you'll see things like, "We'll never pass upcoming bill: Rep Smith".
But that's not what the author of the blog post wrote. Instead, he placed "Google" at the beginning of the sentence, writing "Google: Please Stop...". As such, he used the colon in accordance with one of its most common usages--as a means of address in correspondence, similar to common letter opening "Dear Mr. Smith: Please find enclosed...".
Actually, putting the attribution at the beginning is how transcripts are usually done. You can see it in articles that are mainly the transcript of an interview[1], or even in court transcripts[2].
> similar to common letter opening "Dear Mr. Smith: Please find enclosed...".
It's been some time since I've written a letter, but I remember that the typical format uses a comma and not a colon. For example:
Yes, but this is clearly a headline, not a transcript.
And using a colon in a salutation is recommended for business usage according to most style manuals. Traditionally, style manuals discourage letter writers from using a comma unless they are friendly with the recipient.
Also, the pronoun "me" is generally used to refer to a person, not a corporation. So there doesn't seem to be any ambiguity about the meaning of the title.
Interestingly, this [fn:1] video just explained how emotion-triggering content, in particular anger, will spread the fastest. Clearly, clever marketing/propaganda people have used this technique well.
In the future, "pilots" may be those who controls drones in a remote underground military base, rather than sitting in an airplane manipulating controllers. If this is the case, elite video gamers may have an edge.
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?