Integrating A GUI Into An Existing Medical Device

Roland Piquepaille writes "As I'm not quite familiar with medical devices, I was fascinated by this long article from Medical Electronics Manufacturing. It tells us that "new technology makes graphical user interfaces (GUIs) a fast and cost-effective way to add features and improve on existing designs" of these medical devices. And it really looks simple to use. You just need a standard PC and an HTML authoring tool to develop your GUI. It is then compiled in micro-HTML and embedded in silicon, leading to a graphical OS chip which doesn't need to be powerful or have tons of memory. "The GUI shipped with the Amulet Technologies starter kit, for example, contains almost half a megabit of information in HTML. When all of the gifs, widgets, and other files are imported and compiled into micro-HTML, the file size is reduced to a mere 66 Kb of memory." This overview contains more details and a photograph of such a GUI at work."

Comments

Who wrote this?

[JoshuaDFranklin]

Jim Todd is director of sales and marketing for Amulet Technologies

Makes you wonder if any of it is true.

Slight problem with the compression

[heironymouscoward]

From "almost half a megabit" to 66kb?

500,000 bits is 62,500 bytes.

I hope they meant 0.5 megabytes.

Cannot avoid thinking of Therac

[EggSausageBaconAndSp]

I cannot read such an article without thinking of the Therac-25 catastrophe (several people being killed or severely injured because of a poorly designed X-ray device).

My 2 cents: When developing a medical device, don't focus on a nice'n'cool UI, but on safety.

Re:Cannot avoid thinking of Therac

[nickd]

Safety does also include making it easy and intuitive for people to use it so that they can operate it safely..

Re:Cannot avoid thinking of Therac

[mongbot]

I was just at a lecture about the Therac disaster. The fact that it had a bad, uninformative UI was a factor in the disaster. In no way was it "nice'n'cool".

It was text-based, and you basically pressed particular keys to get it to do things (for example 'e' put it in electron mode, 'p' performed a pulse, I think.) The problem happened when the technician kept pressing a key, thinking that an error had occurred and that nothing was happening. Meanwhile the patient was getting painfully zapped by the Therac. (Incidentally the video and audio link to the patient was broken.)

A GUI would have been able to show the internal state of the device and the concurrency problems would have been more obvious.

I KNOW this is slashdot, and I KNOW that most people here probably think a UNIX command line is better than a proper GUI, but for non-programmers, such as medical technicians, a GUI is far better way to interact with complex devices. I'd much sooner that my doctors were using devices with GUIs rather than cryptic key sequences or commands.

standardised medical embedded gui

[joshwa]

ok, why is this special? it's a standardised embedded gui for medical systems. you know, like the ones offered by half a dozen other companies (symbian, qnx, etc)

I guess it's because you get to code in html instead of C. Great, so now you can hire a TOTAL idiot html jockey to design your life-and-death medical interface instead of a (slightly-) better-trained C programmer?

Whoop tee doo.

Re:Fantasic size reduction

[dekashizl]

Well they claimed to compress it down to 66Kb, which would seem to be 500000 -> 66000. That's 500:66 ration = 7.6:1, which isn't so bad.

Re:Code blue (screeen of death)

[niko9]

This could give a whole new meaning to the blue screen of death. I sure hope they're not using Winbloze on a critical piece of life support.

I don't think the OS is the major issue. Poor GUI designs in all types of devices are rampant.

From my experience, the Lifepak 12 Defibrillator leaves alot to be desired as far as the user interface is concerned. It's nice to have fancy GUI (oohh shiny things!), but if it's clunky in it's excecution and you have to spend 30 seconds to do simple things like synchronized cardioversion then....

I would love to see and Apple desgined defibrillator. It would probably only have 4 buttons and you could work any function in less than 5 seconds.

Medics can dream, can't they?

--

Re:Code blue (screeen of death)

[nathanh]

This is why I like Slashdot. Not just one, but two medics are posting comments on this thread. I also regularly read comments from lawyers, doctors, engineers, accountants, physicists, chemists, professors, firefighters, etc. Communities are more valuable when there is strong representation by many groups. Slashdot seems to be dominated by computer-jockeys, but it's great that it's not just computer-jockeys.

There'll likely be regulation to contend with...

[Empiric]

Back in the day, I worked for a software company working on a project called "iVision" with Eli Lilly. This was in the pre-widespread-web days, and so the idea was to make the status of medical devices viewable via a LAN, presenting to the medical staff at the "nursing station" a consolidated graphical view of all the devices on a given hospital floor.

One thing that I would expect developers to still have to contend with when using embedded web servers, is the very extensive approval process for medical devices. At some point of integration, functionality added to a medical device via software becomes considered part of the medical device, and as such subject to a very long regulatory approval process. This required us to make fairly counter-intuitive limitations to our prototype system, including the notion that though we could show information about the device (alarms, infusion time remaining, etc.), we could not change what the device was doing via our software (e.g. turn off an alarm on an infusion pump in another room once it was acknowledged).

It's been several years, so I'm not sure how the regulations may have changed, but I'd suggest if you're using embedded HTTP on medical devices don't assume you can just upgrade/tweak/patch on the fly like it was a public web server--you probably can't.