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."
How long before we get the first micro pop up ad?
If you get an error, type "OVERRIDE" or "SECURITY OVERRIDE" and then try the optimize command again.
I doubt that's Windows
Makes you wonder if any of it is true.
> 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.
'Almost half a magaBIT' - that would be less than 64Kb if my calculations are correct. And they managed to reduce this to 66Kb, amazing.
From "almost half a megabit" to 66kb?
500,000 bits is 62,500 bytes.
I hope they meant 0.5 megabytes.
Ceci n'est pas une signature
gynecology?
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.
You'd actually be suprised how many systems run Winnt or 98 as their OS. A good example are the Siemens Allegra series ultrasound systems (mid range, specializes in General Imaging, not cardio). They run WINNT as a backend with a custom app handling HW interaction. (Which is causing an interesting political battle with their Semi-Recent aquisition, and my old employer, Acuson. All of our systems ran a custom build of Linx OS as the OS with UI in X11.
Most of the MRI, CT, and PACS systems are built on industrial grade Unix OSs, but you'll still see a ton of MS around on the lower end devices.
The evil monkey commands you to dance.
How robust is this? I hope they are using QNX or VxWorks. I do think that a GUI could eliminate some errors and make training easier.
an application:Centrifuge. One company evaluating a GUI has a significant stake in the centrifuge market. Its design teams' core competencies are motors and speed control.
As the centrifuge spins too fast and destroys the samples. Maybe destrying DNA evidence and getting a death row inmate killed.
Newly available technology enables medical device manufacturers to avoid additional costs and design complexity without sacrificing time to market
Are they more worried about medical safety or time-to market?
Sig (appended to the end of comments you post, 120 chars)
I could see how something like this could be useful, particularly when building devices which will be used primarily by children: acute asthma sufferers, for example, are told to take daily spirometer readings. The problem with this is that many children will either forget or refuse to take the readings.
Much of the time, children will visit their asthma doctor having "forgotten" to take their daily readings. To make up for it, they take a dozen or so readings right before the appointment: the data is flawed and as a result, treatment suffers. With cutesy GUIs like this integrated into the spirometer, children can look at their daily readings as more of a game than a chore.
""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.""
So does that "imply" that present day GUI's are too fat? Maybe a better way to design and build our GUIs?
.
Lameness filter encountered. Post aborted!
Reason: You can type more than that for your comment.
The linux hacker
A graphical OS chip eliminates the need for a marketing manager to possess a certification in C++ or other programming languages to develop the GUI. Rather, all that is needed is a PC, a commonplace text editor, and perhaps even the most basic and widely available graphics programs, such as Microsoft Paint.
WoW! no longer will bad design be limited to the web. Now i can enjoy poor quality MSfingerpaint on my critical life support devices
--
What is the sound of this sentence?
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.
"How long before we get the first micro pop up ad?" ...and it will be a "penis enlargement" ad.
Imagine being able to take a half a megabit and reduce it to only 66K. Why, compressed, that data is only 2K larger than the uncompressed version. Eureka!
(1024 * 512) = 524288 bits, or 65536 bytes, or 64K.
Cheers
-b
If I wanted a sig I would have filled in that stupid box.
There was a company in Bellevue who did this for Windows CE. They replaced the standard CE shell with an adapted IE browser interface.
It was really cool, supported java, flash, scripting, and a set of other custom web controls like mail and chat.
It's been a while, and I totally forgot the name of the company.
Very similar to what is being talked about here.
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?
--
I wonder how this could be utilized in specialized fields? Could different departments have specialized interfaces? So that their most used functions are close at hand. Could this even be adjusted on a per patient basis? This could really save lives if a doctor/nurse wants to have critical information displayed quickly without digging through a mountain of menus. I know dialysis machines already have GUI's, but I doubt they have this level of ease of design.
Hmm..
Did somebody say "a compact, fast, extensible GUI with an incredibly small memory footprint?"
*grin*..
Pogo 3.0 might be what you're looking for. Doesn't depend on gtk, Qt, or anything. Just Imlib1.
Bowie J. Poag
Or will I need Opera at 1076 by 768 in order to use all features? Do I need cookies enabled?
dr_pepr_> ls .. hmo_files .. new_drug_test_subjects
dr_pepr_> .
dr_pepr_> cd hmo_files
dr_pepr_> ls
dr_pepr_> .
dr_pepr_> rm -rf new*
dr_pepr_> uname
dr_pepr_> unknown i586 gentoo 2.4.17custom
dr_pepr_> uptime
dr_pepr_> 8:08 am up 3 days load average: 0.0, 0.0, 0.0
dr_pepr_> lynx www.slashdot.org
Connection timed out
dr_pepr_> lynx www.slashdot.org
Connection timed out
dr_pepr_> ipconfig
There are a huge number of yeast infections in this county. Probably because we're downriver from the bread factory.
"Some complain about using Win98? Well, *I* have had it fire Laser beams at my eyes :)"
Was it blue?
Keep in mind that in many outfits, Lifepak doubles as an EMT's AED; thus, the standard "on, analyze, shock" buttons are there. It's kind of serving double duty, but all really important functions are pretty easy to get to fast, with only a little bit of practice.
and yeah, there are actually 2 button defibrillators -- on, and analyze/shock. However, they're definetly not as powerful as Lifepak, and are designed for use by your average civilian, not an EMT or a medic.
at least you're using LP12 -- on half our fleet we have LP10, which is more than a little outdated.
filter: +3. Hey, look! all the trolls went away!
You just need a standard PC and an HTML authoring tool to develop your GUI.
I hope they mean a text editor. I would hate to entrust my life to a piece of machinery with a GUI 'authored' in FrontPage : )
Vino, gyno, and techno -Bruce Sterling
I suggest you revise your notion of a realtime operating system.
it seems like we have people coming into our shop every few months showing us a black box network appliance that serves apps, helps us design apps, is accessed like a browser, etc.
then we say : "show us the source" and they pack up and leave.
buh-bye. we've completely given up on anyone who doesn't give us the source...and anything we currently license that does not have source is slowly being canned and replaced with open source replacements.
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.
+25 Funnay. Shouldn't you have mentioned that you did all that on a freelance-gig?
Which thermometer would you rather have up your a**? The one on the picture or the old low-tech one?
I think I found a new profession: /> />
<html>
<head>
<title>Life Support System</title>
</head>
<body>
<input type="button" value="Live" onclick="live();"
<input type="button" value="Die" onclick="die();"
</body>
</html>
not just computer jockeys, but computer jockeys who enjoy pretending to be EMTs and lawyers.
-I like my women like I like my tea: green-
Please keep Microsoft away from this!!!
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.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
blue scream of death
This looks like a re-intrepetation of what Allen-Bradley did with Panelview controllers. Note that panelview came out in the EARLY 90's [possibly earlier] before HTML interfaces were common. But the procedure they discribed is very much the same for creating the cool touch-screen machine controls popular with most assembly lines nowdays.
I feel the medical GUI proposed by Seth M. Powsner and Edward R. Tufte in the articles "Graphical Summary of Patient Status" [The Lancet 344 (August 6, 1994), 386-389] and "Summarizing Clinical Psychiatric Data" [Psychiatric Services 48 (November 1997), 1458-1461] represent the best working model to quantify and observe a patients vital statistics. This simple and efficient grapical format can benefit patients by contextualizing the entirety of a patient's vital data rather than requiring an medical interpretation of the "normalcy" of each vital reading.
p ://www.edwardtufte.com/tufte/psysvcs_p2
http://www.edwardtufte.com/tufte/lancet_p2
htt
Tom.
Oh arse
OK, so the definitive book on the topic of Embedded TCP/IP is almost certainly TCP Lean, by Jeremy Bentham. Any book that explains Ethernet with an O-scope trace is alright by me :-) Anyway, Jeremy documented one of the coolest TCP hacks ever. Check it out:
So, HTML is really quite useful for embedded devices -- GUI toolkits are quite heavy, and HTML nicely and consistently exports that weight to the client. Now, that'd be the end of the story, except...we're not talking about devices that can't render a GUI, we're talking about devices without enough operating RAM to store a single packet. Ethernet, IP, TCP, HTTP, HTML...each field of each protocol needs to be written, one by one, in order, into the network card's send buffer. And once it's in -- no getting it back out, at least not quickly.
You'd think this wouldn't pose a problem...just calculate the values as needed and spit them out on the fly. But what about checksums? It's one thing to insert an IP address or a TCP source port, but checksums aren't independent, i.e. they depend on the IP addresses, the source ports, and all the other fields in the packet, including the payload itself! They (both IP and TCP have one) are "summary" values that seemingly require passing over each byte in the entire packet, running a transform given all that data, and outputting a two byte value.
What to do?
Short answer: Do it backwards...or more accurately, do it later. If you can't make the checksum match the payload...make the payload match the checksum! Watch:
The particular checksum used by IP and TCP is almost literally a checksum -- all the bytes are added, and there's your sum. This has the convenient property of being easily reversable: If one byte is +10, another byte can be -10 and the sum will add up the same. So, you basically calculate the checksum given some "prototype values", and when you actually find the real values, you measure the offset between them and the prototype and take note of it.
Finally, when your normal payload is done, you add just a little more...you add additional data that forces the payload to adapt to the prototypical checksum. And where, might you ask, would you add this data?
HTML comment. We were talking about web pages, after all.
Uber. Bentham rocks.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Doesnt this sound just like WAP that is more advanced with graphics and all?
During my medical training when I was doing time at the neonatology unit at one of the hospitals. I was suprised/shocked to see that one of the ventilators was running a version of windows. Ok, I figured must be a specially designed cut down, more stable version, but then I looked carefully.. and beside the start button was the quick launch tool bar with an icon for internet explorer and media player - that is just plain scarry! would you trust MS with your neonates life?
Thankfully, for the few weeks i was there I never came across anyone complaining bout it. I cant seem to find it on the web, I might have to go back and see what the model and brand was...
How about a XML/XSL viewer in uHTML, so new UIs can connect these old tools to both humans AND other machines? Just add a USB port on that ribbon cable to the display.
--
make install -not war
I have one of the units. The developers kit comes with a touch sensitive lcd screen. The "html" you write just makes buttons and things on the lcd for you to interact with.
...
When you "click" a button on the touch screen, a string of several bytes representing one of up to 255 commands is sent to whatever device you connect the amulet unit to. All the amulet does is convert a touch on the lcd screen to a number and send it out serially.
While it's certainly a nifty thing, and I actually have a use for it (custom control of some A/V gear), I think the whole thing is a little over hyped, not that we aren't used to that
ps - it's not just for medical devices. You can control your garbage disposal with it if you're so inclined.
OK, alot of people really aren't understanding why this is very cool and very, very important.
You really, really don't want UI code interfering with important things, like not killing people. Ideally, there's as wide a gap between the two functions as possible.
Realistically, the C/ASM coders have had to implement things like keypad pollers and shape routines in the same codebase as they do important, non-patient-killing things. This very much meant a failure in one killed the other.
Offloading the entire UI onto a separate chip, that happens to be very easily programmable by people who have nothing to do with life critical code, does something very important:
It creates a completely new execution environment that, if it crashes, doesn't kill anyone.
For decades, computer security was about mainframes, with complex and ultimately buggy rules about memory classifications and data transfer. Oh, how they toiled to prevent users from leaking data between eachother.
Then the Internet came along...and gave one computer to one user...and another computer to the other. That's one way to segment RAM.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
i should have used preview.
But if it is, I'd sure to hate to have a pacemaker with it. It'd suck to suffer from a literal version of BSOD.
Imagine a beowulf... oh nevermind
"With the graphical OS chip, GUI development can shift to the marketing team, allowing engineers to concentrate more on their core competencies. Marketing teams that have a closer relationship to a medical device manufacturer's customers--and herefore their end-users--have a clear understanding of how a device is used in the field. In that way, they are closer to the process of developing a GUI that is the most intuitive to the user." "A graphical OS chip eliminates the need for a marketing manager to possess a certification in C++ or other programming languages to develop the GUI. Rather, all that is needed is a PC, a commonplace text editor, and perhaps even the most basic and widely available graphics programs, such as Microsoft Paint." This is fucking hilareous. 1) There are people that understand that GUI design is about ease of use, not about making the GUI as pretty as possible. These people are not marketing managers. 2) Gathing customer requirements != Design != Implementation. The marketeer's job is to gather requirements from the customer, not design a solution. Once you start to mix those two, the marketeer is going to start pushing solutions on the customer. 3) What the fuck is a marketing manager doing designing the GUI? Is this so that the device LOOKS like it contains every single feature under the sun? "Well, the button is there. Why won't the device image?" 4) How many marketing managers do you know that have mastered HTML, let alone understand how to use MSPaint, well enough to create a GUI? Typically engineers are much more familiar with both the tools and the concepts required to create anything on a computer. 5) Yeah... we wouldn't want one of them Human Factors enineers to design the GUI or anything. They have no compentency when it comes to designing Human Computer Interfaces. Let's leave it up to the marketing manager. 6) Um, we're talking about a medical device here, aren't we? What the fuck is a marketing manager doing designing, let alone implementing, *anything*? 7) A C++ certification? As far as I know, most medical design/manufacturing companies don't offer development jobs to someone that has *only* a C++ certification. Most likely, if you're a marketing manager, you haven't been designing software for the past 10 years. 8) Last I checked, the engineering manager was in charge of choosing design tools and was responsible for how well the finished software works. Why would any engineering manager make the decision to hand off GUI design to marketing? Ah salespeople... they just don't quite understand a little thing I like to call reality. "However, this requires developing an enormous code base that necessitates increasing the memory on the board. This method exponentially increases design complexity and cost." I'm not even going to go into the amount of misinformation that is presented in this statement.
So when I'm 50 or so and I need a colonoscopic exam am I going to have to lie there for an extra 30 minutes with the scope inside me while they reboot "Windows-BM"?
"Guys! Stop playing solitaire and get this thing outta me!"
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
How many of these GUIs are going to be W3C compliant?
http://mediagoblin.org/
The Captain's Log!
It's not a lie, if you believe it.
You can use the software to make a thermometer GUI, but it will probably come out looking like ass.
Ergonomica Auctorita Illico!
"compiled into micro-HTML" - I'm pretty familiar with the HTML standards from the W3C (http://www.w3.org/MarkUp/), and I haven't found the spec yet for "micro-HTML". Perhaps this is the marketing buzzword description for zip compression of the HTML file? Am I missing an explanation, or is this just a freely flung buzzword in an otherwise interesting article?
What?!?! The "KB" vs "Kb" difference is extremely ambiguous...only a factor of 8 involved, when we often really want/need to know which it is.
But it turns out humans are really good at interpreting things in context, and would never think that "2m" on a street sign meant "2 meters"...obviously you wouldn't even need a sign if it were that close; that's the same thing as "you are here". So what are you, a bot? :-)
As a more minor matter, meter is SI/metric, mile is Imperial, and they are separate systems, not one unified system, so letting this annoy is about as meaningful as being annoyed that e.g. "hell" is a word in both English and in German but means sharply different things.
If you want a pet peeve, how about words in English that mean their own opposite, like "cleave" (means both to join and to separate) or "prove" (means both to demonstrate beyond reasonable doubt and also merely to test something of unknown status).
But the smallest touch of a Zen attitude might allow one to realize that it's pointless to rail against things being the way they are. Gravity exists, no point in getting upset at it.
Professional Wild-Eyed Visionary
This is nothing new. Art & Logic has been doing HTML-based GUI's for almost a decade now. Check out their HTML-based applications page.
so I'm not sure how the regulations may have changed...
Ohhhh they're ever so much more intrusive than ever before. If you think software management in a regular commercial enterprise can be difficult, the medical world is way worse. The FDA can inspect down to the code when they drop in for a little visit and if you can't point every bit of code back to some top level end user/device requirement (along with all the changes, the reasons for the changes, the risk analysis you did for each of the changes, all the sign-offs, all the definitions of who's allowed to sign off, all the changes to the list and why they were made and who approved them and....), you will probably be written up and that ain't good.
This level of FDA oversite include not just the software on the devices but also any data collection/analysis systems used by manufacturing or QA - including things like spreadsheets.
Using COTS (Commercial Off The Shelf Software)? No pass. You may not have to validate the COTS but you do have to validate it's use in your application or system.
But hey, I love saving lives. Code on!
Dogu
I was wondering if anyone has thought of the fact that although this may or may not work for medical devices, it can definitely work for other applications.
I'm making a small, portable mini-itx (or maybe the Nano-ITX board when it shows up) computer as a server, and was initially going to code my own interface for a serial LCD with keypad in PERL or C, because I couldn't lug around a huge LCD panel when I wanted to connect it to a network and set IP addresses. Then I saw this and realized it would be infinitely easier to do things like change IP addresses with an amulet display than use something with a serial LCD. Yes, its more expensive (about $350), but it was either that or a tiny, cramped display.
Computer Language Magazine, January 1994 for the original "Rovira Diagrams" article and
Medical Device & Diagnostic Industry 1994 "Using Rovira Diagrams to Specify the User Interface, Ken Niehoff (MDDI, Jan 1994, p. 198). Keyword: Development."
It worked then and is scalable (has scaled successfully,) from 327x displays to web-enabled devices.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
If the software does not control, in a closed loop fashion, a medical device (as defined in Title 21), they do not regulate this.
There is considerable consternation on both the part of the FDA and the medical software industry on how to assure patient safety with unregulated software.
Stay tuned
Sorry to be contrary, but all parties here are missing the same boat that left with 99.995% of programmers (C, C++, Visual Basic, Java, Cold Fusion, whatever).
/s/Just some poor emergency medicine pogue
User interface design is *not* about being pretty, its *not* about having buttons instead of keyboard entry, its all about anticipating the end user's need and mind set, and recognizing that end users come in all sizes, shapes, flavors.
Careful evaluation and consideration of how users acquire, process and implement takes a concerted and usually skipped effort. Witness the legion of GUI "improvements" inflicted by XP which slows down a good deal of power users (e.g. the new and "improved" search function).
Some users do fine with, and prefer, command lines. I have entered prescriptions for my patients from a prompt for years, and it is efficient. It also has a menu function (again running on a VT320 you can only hope for so much) and pick lists for people unwilling to learn cryptic codes for various drugs. While the UI is butt ugly (apparently there are a paucity of graphic designers/programmers in the MUMPS realm) it is efficient and closely parallels the usual work process.
The standard today for medical interfaces must be to involve prospective studies on information needs, work flow and decision making across a range of users. This is sure in incur the rancor of hard-core C programmers who are convinced that their mental model is THE way for non-programmers to manage information that is foreign to the programmers and orders of magnitude more complex than anything they deal with.
To any and all CS/CE types I would encourage some study in cognitive psychology and the emerging (although somewhat abusive) schools of thought on GUI design in the interface design/engineering realm.
You can be brilliant at information and knowledge management in a complex domain, such as medicine, and not know a damn thing about computers. Or care. Please remember that these are the people your products need to help.
True the apple interface would be simple, but as you suggested, how the hell would I overdrive pace someone?!?
Lifepak 10 was far better designed than the 12. Could be worse, took me 20 minutes to find the damn menu that contained the "sync" button on the Zoll-M! But boy, does it have a pretty GUI.
A few years ago, a friend of mine (Werner Sharp) created a tool like this. It allowed the user to create a rich graphic application in Director with alpha channeled graphics, multi channel sound, object code, and export the entire project to C++ for use on Win CE.
m
I used it on one of my projects with custom coded async animation, control registries & messaging and the results were just amazing. It's free too.
http://www.sharp-software.com/products/index.ht
- Zav - Imagine a Beowulf cluster of insensitive clods...
Well specified, straightforward, easy to get right, user interfaces for medical devices might be a better idea.
Does anyone else think they just used frontpage to create the docs and got their compression by stripping all the MS cruft from the final HTML
What if we GUIfied text on printed paper allowing for easy connection to digital content on a TV/DVD or PC/DVD/CD?
http://www.discovertek.com/SPNstream.mov
http://www.discovertek.com/WhitePaper.pdf