[zelphirkalt]

The problems are aversion to technology in places, unwillingness to adopt new (human) protocol/processes, entrenched proprietary technology, that does not adhere to standardized formats.

Say you want to save a report for a patient for the next shift. That report needs to enter a computer system. If there is a system for that, it will most likely be a very expensive overpriced proprietary solution with expensive support contract, instead of something that has an open and intelligent format, that could be read by simply any software. The companies behind the tools will paint themselves as "specialists" for medical technology and do everything to dig a moat, at the cost of lives and they will avoid standards, as that will make their overpriced solution replaceable.

[cmiles74]

I have to disagree on the "aversion to technology" point. It's something I've heard ever since I started working in software development, this isn't isolated to healthcare.

For sure, there is always some resistance to the extra work of learning something new. In my experience over many years, it's easy to overcome this resistance by showing clear improvement achieved by the new process, whatever it might be (change in order of process steps, new paper from, new software, etc.)

After working in healthcare (mid sized hospital), there is a big problem with pressure from administration that often makes little to no sense to those whose work is changing. I think a lot of this comes from weird incentives that maybe make sense in terms of short term business gain but, perhaps, are not worth the disruption to so many people's day-to-day work.

Lastly, in the field of enterprise software and healthcare in particular, I agree that many of the technical solutions are not great. There's a lot of resistance to changing software tools simply because people have changed so often and the tools are so poor. Often these tools do not come close to the promised improvement.

[AllegedAlec]

https://xkcd.com/1831/

[Zenzero]

> The problems are aversion to technology in places, unwillingness to adopt new (human) protocol/processes, entrenched proprietary technology, that does not adhere to standardized formats.

It is not. This is a classic example of assuming the problem exists within the realm of your current understanding.

The stereotype of people in medical roles not wanting/liking/understanding technology is wrong. What we don't like is the god awful technology we are handed because the work hasn't been done to understand how we work. THAT technology is not worth learning or caring about.

As someone who has rounded patients over many times, the problem is the extensive amount of information that is ingested into establishing a cohesive clinical picture of a patient, then continually adjusting the degree of confidence in numerous facets and levels of the case. Then it all gets dumped into the heads of the next group of people.

So people in tech develop these programs to help track the information. Yet they fail to grasp that there are many situations where the conclusions are based on a web of contingencies that operate on disparate time series, are affected by a wide net of things not directly reflected in empirical data, and it is completely impractical for me to continuously update the intermediate changes to my conclusions just so your software can know what's going on. The more that people try to construct a UI that captures the complexity of what can be noted in a case, the less usable it becomes. Even then, they still undershoot the level of depth needed to reflect what doctors are tracking in their heads. You may think it's enough to have someone input the hematologic data as the results and their ranges. You fail to track that my interpretation of those results is contextualized by the fact that nurse Martha was on the floor and likely dropped the ball on how promptly the ABG was run, and that certain staffing dynamics affected how much weight I give certain subjective criteria. In rounds, a simple eyebrow raise can be enough to convey to the next shift a mutually known dynamic that affects how information should be interpreted. Asking us to spell all of that out in your "new technology solution" won't happen. It is a waste of everyone's time and social dynamics will prohibit it.

I could go on and on with a variety of other examples, but I don't have the time or desire to do so. My point is that the tech hubris is wasted effort. While you sit there thinking you need to teach the "tech illiterate doctors" how to follow matters of process, we see you as someone that has been asked to develop a more effective tool, and you hand us a fisher-price screwdriver and insult us for not finding it useful.

Like the other comment said, https://xkcd.com/1831/

[yoyonamite]

If you don't mind me asking: Do you see a solution, technical or otherwise, to this problem?

My guess is there are limits to knowledge transfer that's difficult, if not impossible, to overcome.

[Zenzero]

You are correct that the problem is an information bandwidth issue.

The number of variables that must be considered for any given case are extensive and multi-layered. I don't have the time to get much in depth on this but off the top of my head: - There can be errors in our lab tests - The errors are test-dependent in degree and significance - Less than ideal handling or sampling affects different analytes differently - Errors in one analyte can affect others - The absence of deviations from normal in some tests can itself be an abnormal finding - Sometimes abnormal findings can be due to error or genuine in an unknowable way - The confidence of what constitutes "normal limits" is dependent on the underlying epidemiology of what is being tested for - There is no realistic way to have a unified data model for everything we assess - Much of what is interpeted/assessed gets reported as paragraphs of text - Missing data can either be untested or unavailable and it is not always clear which it is - What is communicated to you may be dishonest (such as drug seeking behavior) - As much as we have tried to standardize fundamentally subjective assessments (such as murmurs) they are still subjective - The MO is to push providers to the limit of what is safe in terms of number of cases and aggregate complexity - Putting humans in the loop of anything opens up to emotional/social factors that can influence interpretations/trust in various factors

I could go on, but the point is that as a result of all of this, the most efficient route by far is passing information directly from one caregiver to the next since they are often operating on a platform of context (much from their training) that is difficult to replicate in software.

The solution in my mind is lifting providers off of the low level data and activities. If we can close the loops on automating decisions in a generally agreed upon and reliable manner, it removes the need to discuss or think on the information fed into that system. Clearly that is a big task, but the realistic path forward in my mind. Harping on matters of process at the same level of detail is a waste of time and effort.

[zelphirkalt]

I happen to know someone who works in a hospital, in a lab, looking at blood samples. The stories I often have to hear about how little technical knowledge people working in the hospital have, or at least apply to what they are doing on their job are ... not very encouraging, to say the least. So I am not actually as clueless about how hospitals run, as you might assume.

It is not all doctors, but also other personell at hospitals. But also doctors. Some are known to take too little blood from patients to run proper tests. Or too little urine. Or use the wrong containers for the samples. All very avoidable, if people did not refuse to learn abour their own job's processes. People can be, and are often very learning resistant, especially non-technical people, when it comes to learning technical processes, new software, or new workflow processes.

What is more is, that hospitals run on lots and lots of proprietary machines. But they do not always run them correctly. No, even when being told, that the machine must not be in a room warmer than X degree Celsius, they run them above that temperature anyway. Sometimes without better option, because they do not have the appropriate rooms for running them according to how they should be run. Don't get me started on proprietary protocols and file formats, probably wheel-reinvented by an intern or an evil genius, who was told to make interoperability with machines and programs of any other manufacturer impossible.

Yes, you may be a well-oiled team running the place at work, but some of what you write makes me think, that you are part of the problem, refusing to put things into written form. In software engineering many (but not enough yet) have long learned, that what you do not document properly will eventually get lost and might need to be rediscovered. If you cannot write down your thoughts regarding a patient, what happens, if the next day you have an accident and cannot tell anyone your custom interpretation of measurements? What if your coworker or fellow doctor, who understands all your subtle signaling like some raised eyebrow, cannot make it to work tomorrow? And do you really want to handle patients based on whether your coworkers eyebrows behaved, when you were talking to them on shift change/handover? I hope not.

Basically what you describe sounds like a very person dependend process and leaves lots of room for mistakes, when things are not explicitly spoken or written. It may be, that inputting everything into some IT system takes a lot of time. Maybe you need better methods of inputting things. It is a valid concern. But your kind of attitude "tech will never be able to capture our work" is not helping anyone. A good solution will naturally involve countless hours of observation of processes in the hospital. That is what business process modelling is all about. Of course the process needs to be captured and analyzed. That however, is a 2-way street:

Sharing all the little signals and what they mean with some observer of processes is essential. They needed you to tell them these things. If you think the tool is "fisher-price", then why haven't you told the people, who came up with the solution? Did you sit there silently, saying nothing? If so, then who is wasting other people's time? Or did no one actually observe the processes and came asking about your work and how you do things? If so, then that is a really bad process of trying to improve things and I am sorry you were treated badly and not not surprised by the result.

Who thinks that they can solve all the problems without observation will fail, especially in a hospital. But that is not the matter I was getting at. I don't know where you are a doctor or so, but at least from the stories I get to hear from the hospital, I know that hospital staff has lots to learn in terms of following processes and saving time by knowing a little bit about the work of other departments, like the lab.

[Zenzero]

Imagine telling a doctor how to be a doctor because they "happen to know someone who works in a hospital". Oh how I would love to have you shadow me on the floor for a week.

> If you think the tool is "fisher-price", then why haven't you told the people, who came up with the solution?

Because they react just like you did.

You perfectly demonstrated why I moved over to the software side. The doctors I work with are sick of the hubris from people who don't understand medicine, so we decided that it will take doctors who are willing to learn software development to actually solve our problems. It turns out it's much easier for doctors to learn how to develop software than it is to teach devs how to be doctors.

[zelphirkalt]

Now you make yourself look like a bitter person, since according to you all the software developers in the world will react a certain way and nothing can be done, except you, the holy doctors, showing the devs how to do their job, by becoming developers yourselves!

Meanwhile talking about hubris ...

All the while you could not be bothered to document things and not telling someone who tries to help, where their solution falls down, so that maybe they could improve, but at the same time keeping complaining about "fisher-price". No way they could have any new ideas. You did not have them, so how could they ever have a good idea for improving status quo. How I would have just loved to onboard you onto my engineering team! I am sure you would be great to work with, since sharing information seems to be your strong suit.

It seems very clear to me now, that you did not want things to change as a doctor. Did not want improvement, since nothing these engineer plebs could do would be good enough anyway. And that kind of attitude is exactly what made you part of the problem.

[Zenzero]

It is clear that what what I just said is being distorted for preserving ego. That does not lead to productive conversation. If this is an active area of interest of yours I would advise you to listen to subject matter experts instead of attempting to lecture them.