Comment by alxlaz

I used to work on stuff that doctors use (and I miss it a great deal), so I've seen a lot of this first-hand.

In my experience, a lot of the problems that medical software and devices have stem from a lack of understanding on the "other" side of the fence. Committees of people who don't really do much medicine anymore meet committees of people who don't write much software anymore and come up with specifications that are almost, but not quite, entirely unlike what the doctors really need.

And then the implementation is outsourced to a team comprised of people who have to churn out software with minimal understanding about how it will be used. These folks will try to understand it at first, but there are so many project managers and customer satisfaction managers and NDAs between them and the people who need the system (and, of course, there's no documentation because that's the first thing that gets slashed out of the itemized billing when the customers see the price) that it takes weeks to get a straightforward answer to even the most trivial question.

Not that it's easy to do things differently. When I was working on devices for the medical industry, I had not looked through an anatomy textbook since my teenage years; understanding the jargon alone was hard, let alone make meaningful design decisions.

I was super fortunate to work for a company that had long learned these lessons and did things correctly. But doing things correctly and profitably takes a long time; most companies don't have that kind of patience so they don't really bother with it. People who possess substantial knowledge of both programming and medicine are extraordinarily rare and not too easy to keep on payroll, so these companies rarely manage to develop the kind of technical leadership required to successfully mentor new people and drive projects over a long time.