[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.