> That medical software (at least most of it) is run on PCs, > each of which has potentially different hardware and other > software (including operating system patch levels) > installed. > At the same time sending the users a patch via email or a > download link is easy and cheap. > > It's therefore (despite the seemingly more important > problem domain in medicine) more important economically > for the manufacturer to get that game console software > correct out of the box than that medical software (as long > as no patient dies of course, in which case the liability > claims can run into astronomical figures).
What you say is correct but I'd like to add a little to it. Medical software is broad. Focusing exclusively on the laboratory system: embedded software in the lab equipment which took the actual readings, a "collector" package that ran on a UNIX server, an HL7 message translator running on a UNIX server, a transaction server that took translated HL7 messages/transformed them per physician's rules/loaded them into the patient chart database, and the client piece running on PC's. Everything except the embedded software had the luxury of patching.
As far as testing goes, something as simple as changing the measurement unit in the patient chart system for a particular lab test, per physician request, involved a full regression test of the transaction server and client pieces. Every possible transaction was retested along with all known error conditions and the server's ability to handle them. Physicians' training can prevent data errors from being catastrophic, but physicians can't catch everything - especially not when in hour 25 of a 32 hour shift. In a hospital, information in medical systems CANNOT be wrong. The motivation for developers isn't financial (liability), it's watching life and death play out.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
353637383940414243
|
»
]
Previous Topic
