Medical Device Link.

Originally Published MEM Fall 2003

GUI TECHNOLOGY

New technology makes GUIs a fast and cost-effective way to add features and improve on existing designs.

Jim Todd

Graphical user interface (center) provided courtesy of Amulet Technologies (Santa Clara, CA). Other products shown courtesy of Welch Allyn (Skaneateles Falls, NY); Cadex Electronics (Richmond, BC, Canada); SBS/VI Computer (Encinitas, CA); and Medconx (Mountain View, CA).

Medical device manufacturers are constantly seeking ways to improve upon market-proven designs. Incorporating a graphical user interface (GUI) is an option that deserves serious evaluation by any company seeking to breathe new life into successful product designs. Newly available technology enables medical device manufacturers to avoid additional nonrecurring engineering (NRE) costs, extra material costs, and design complexity without sacrificing time-to-market schedules.

Besides reducing costs, adding capabilities, and generally enhancing a device's appeal, GUIs can now be rapidly integrated in a fashion that can drastically slash time-to-market cycles.

A GUI with an embedded graphical operating system (OS) can elevate the participation of product marketing teams in the design phase of a medical device. Therefore, the overall marketing goals of a manufacturer can be carried through every stage of a device's design cycle, significantly enhancing the product's appeal when it reaches the market.

Using any laptop or desktop PC, a GUI can be designed with ease using an application with a hypertext markup language (HTML) editor such as Macromedia Dreamweaver or even more commonplace software such as Microsoft Front Page. Having HTML embedded in the hardware of the GUI translates to hours and days of development time saved compared with alternative methods used by other GUI development programs. In the end, a GUI can now be integrated in 90% less time than before, and a GUI drastically increases the ease-of-use factor in any device.

HTML Versus Older Methods

Previous methods required engineers to write code and create their own operating systems in Basic, C, C++, Java, or Visual Basic. Such processes required writing a voluminous amount of code, which is a tedious process. Developers tell horror stories of intertwining user-interface code and data acquisition code. This process adds complexity to the development and creates significant debugging difficulties.

The alternative to the drag-and-drop method of developing a GUI would be to acquire graphics libraries or real-time operating systems separately. These processes add considerably to the cost of the basic system, not to mention the added costs that are inexorably incurred with add-ons, plug-ins, extensions, and customized tools. Additionally, this path requires considerable processing power, which then necessitates a migration to a more powerful microprocessor.

GUIs are now developed using a graphical operating system in silicon, a dedicated microprocessor with a liquid-crystal display (LCD) controller. Configurations such as these do not require any additional memory subsystems and will work in conjunction with any microprocessor or microcontroller that is part of an existing embedded system. In fact, because none of the functions of the GUI need to be offloaded to the host, some design-phase engineers may even consider a less-powerful microcontroller as a host.

The single most important element of the integrated GUI is the embedded micro-HTML. This code is ready for operation out of the box in an application-specific GUI controller chip, which integrates a graphical operating system in silicon and a dedicated microprocessor unit with an LCD controller. Everything a developer needs is included on the chip. No third-party C-level compilers or operating systems need to be obtained, tested, and debugged. Prior to the graphical OS chip, design teams were saddled with the painstaking and time-consuming process of writing each line of code to custom-develop the GUI. Written code was necessary to draw each pixel on the LCD. Unfortunately, a design engineer could become fully absorbed in this process, diverting attention from the more important task of focusing on its application in a medical device.

Graphical Operating System

Many medical devices require large, high-resolution displays. A graphical OS chip can support VGA resolution of 640 x 480 pixels. (click to enlarge)

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 easy-to-use development process is essentially the key advantage for embedding a graphical operating system into the LCD controller that drives the display. The process of compiling a GUI in micro-HTML can give developers, whether they are design engineers or marketing managers, the ability to create or import an icon, image, or other graphical item without writing code. That item, whether it is a widget, a slider, an on-off switch, or a user-specific GIF, can be imported to the GUI with a simple drag-and-drop approach.

An embedded micro-HTML editor compiles everything. It also compresses every file imported into the GUI. 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. Designing a more intuitive GUI does not require more memory to operate, nor does it require an increase in the bill of materials. Consequently, because there is not an additional amount of memory to manage, the code executes quickly, and there is no delay in the execution of the applications.

The standard display for the GUI is a monochrome LCD. Many medical device applications require larger, higher-resolution displays. The graphical OS chip can support up to full video graphics array (VGA) resolution of 640 x 480 pixels. Starter or evaluation kits are equipped with 3.8- or 5.7-in. quarter-VGA (QVGA) graphic LCDs. Displays of various sizes can also be supported with relative ease.

The GUI can now be configured to drive displays of varying screen sizes and resolutions. GUI solutions are scalable to support varying production volumes and vary depending on available engineering resources. Applications can include just the chip, a controller board, or fully integrated modules. The graphical OS chip can support electroluminescent (EL) panels as well, and organic light-emitting diode (OLED) displays with driver configurations comparable to graphic displays.

The alternative to a fully integrated GUI requires a design team to acquire each of the separate components and expend a considerable amount of NRE trying to make them work together in conjunction with third-party software, development tools, and firmware.

Fully integrated GUIs were developed to unshackle design engineers from tasks that detract from their core competencies; however, it is becoming readily apparent that another important benefit is the marketing team's participation in GUI development. Marketing departments can now have direct input into a GUI's final appearance because they already have experience with the tools used in the user interface's development. The user interface can become an afterthought for a design engineer, allowing them to focus on driving patents for new applications and improving the performance of existing applications.

NRE expenses are lowered because the marketing personnel are steering what is essentially a market-driven piece of the overall system puzzle. Most medical device manufacturers want their engineers focused on improving the core application to improve performance, which makes a device stand out among a field of competitors. Incorporating an integrated GUI gives these engineers the operational latitude to do just that.

GUI Considerations

Medical device manufacturers may want to consider the following goals before incorporating an integrated GUI into their application:

• Improve time-to-market.
• Reduce the bill of materials.
• Incorporate intuitive controls that create ease-of-use for their customers and end-users.

An integrated GUI can be designed into a new product or an existing product. With existing products, design teams should consider the replacement of primitive user operation panels consisting of electromechanical switches and pots. If a design team is intent in preserving legacy code developed for existing applications, an integrated GUI is also an option.

The GUI development team should begin by planning the types of graphical elements it wants to use to control the application. There are line plots, bar graphs, numeric fields, and even step-by-step instruction manuals that can be easily imported to a GUI. Text can even be highlighted with links, just like a Web page. This crucial stage of the process can easily involve a marketing department. In some cases, companies developing an application with an integrated GUI can employ a graphic artist in this process to produce effective results.

Companies can also ask information technology (IT) managers to participate in the design phase if these managers have experience building and maintaining the company's Web presence. One company has leveraged the experience of its IT manager to actually design the GUI for its medical device.

Developing a GUI with an embedded graphics OS enables developers to produce content quickly and to make changes and improvements at every step of the process. A developer can demonstrate the application's operation with a new GUI and obtain client feedback while the content is still undergoing revisions. A GUI can then undergo multiple changes and corrections without jeopardizing the schedule for the final product release. This seamless prototype-to-production model slashes time to market, which is often a critical design consideration.

Case Studies

Starter kits include everything from the display to the 9-V battery. (click to enlarge)

Sleep Apnea Monitor. One device was dramatically improved after the manufacturer incorporated an integrated GUI into an existing design. The GUI was used to improve a 16-channel poly-somnograph that was widely used to monitor vital signs of patients with sleep apnea and other sleep disorders in sleeping clinics and other institutions.

The device was typically wheeled in on a cart and positioned at bedside. The instrument was originally designed with a series of knobs, pots, and switches on the front panel. The device manufacturer decided to migrate from a 16-channel device to a 32-channel device. Essential to the design team's list of objectives was shrinking the device's original form factor while managing to squeeze in more complexity and capability. Institutions had advised the manufacturer that its existing device was too large to sit at a patient's bedside in conjunction with a number of other essential medical devices.

Another objective for the design team was to consolidate functions to the device that were usually set at remote locations with other equipment. For example, the amplifier gain for each lead had to be set with two technicians, one at a patient's bedside and another elsewhere to monitor computers and strip charts. Obviously, setting up the machine became cumbersome and was not conducive to a patient's optimal comfort. This became increasingly acute in sleep clinics where a lead would fall off a patient in the middle of the night, and technicians would actually shout up and down hallways to reset the equipment.

The manufacturer of this polysomnograph developed and incorporated an integrated GUI and achieved all of its major design goals. The device was expanded for 32-channel input, and the addition of the GUI enabled the design team to shrink the form factor. Technicians now use the integrated GUI to set the gain of the amplifier directly from the patient's bedside, eliminating the need to communicate back and forth with a colleague in a remote location.

In addition, the company developed a robust GUI to resemble a complex Web site with multiple links and pages. This complexity, which did not adversely affect application performance, actually provided end-users more options for controlling and viewing data from the polysomnograph.

A microcontroller with a limited graphic library resides at the core of GUIs that are not fully integrated. For these products, developers must still write code to develop the GUI. The size and complexity of this code can be a limiting factor in the overall user experience of the device.

Pipette Puller. In another example of how an embedded GUI was incorporated into an existing design, a company was seeking a way to upgrade a machine they called a pipette puller. The machine would pull on bunches of glass tubing while under heat and create pipettes for use in the laboratory.

The unit used knobs, pots, and a light-emitting diode (LED) for display and control functions. Although it included a cryptic user's manual, little information existed on the use of the device. The company incorporated a GUI with an embedded graphical OS. The design team was able to add finer control to the machine; the new system could determine exactly how long the machine was going to pull this piece of glass. The system could also determine how long forces were going to be exerted on the glass.

The marketing department requested that the design team add more product information. They put in a user's manual, just-in-time training, product specifications, and an instructions guide. All the information generally available only in a user's manual was now embedded directly into the product.

This company increased the product's capabilities and enhanced product reliability. By reducing the number of pots and switches on the front panel, a number of electromechanical devices were eliminated, thus reducing the design complexity of the entire system. In addition to a simplified design, the overall bill of materials was slashed.

Centrifuge. One company evaluating a GUI has a significant stake in the centrifuge market. Its design teams' core competencies are motors and speed control. It does not know how to create a GUI. The company's options include developing a new product, retaining its existing host microcontroller, or incorporating an integrated GUI with an embedded graphics OS into its existing product.The GUI is something that can be added to the existing device without any impedance to the application.

The GUI allows the company to run its legacy code and applications. It also can enhance the product by going from its current character display to a graphic display. And, with the graphics display, the company will get more capability out of the product, which will make it more appealing and much easier to use.

Methodology

Without previous GUI development experience, designers often are concerned with the necessity of hiring an engineer with specific background and training in the field. In many cases, this translates to an electronics engineer with experience developing on graphical display programming tools. Considerable time is spent developing a GUI, depending on complexity and how many screens the user interface will have.

The company has seen this methodology mandate compromise, because the screens are difficult to create and they are code-intensive. As a result, design teams often fall short of creating an attractive and intuitive GUI. Because of the work and time involved in simply developing the GUI, it often lacks many components that make it a better product.

In some instances, a team without time constraints can succeed in creating a GUI that incorporates all the functionality and aesthetics on its wish list. However, this requires developing an enormous code base that necessitates increasing the memory on the board. This method exponentially increases design complexity and cost.

It is possible to hire a dedicated engineer to create a graphics-rich and feature-loaded GUI; however, the memory requirement to store that code using contemporary design and development tools would be huge. From that standpoint, this is not a practical solution.

Conclusion

It is clear that incorporating a GUI is an option that should be considered for updating a product's design and capabilities. Newly available technology enables medical device manufacturers to avoid additional costs and design complexity without sacrificing time to market. GUIs can now be rapidly integrated and are a cost-efficient way to enhance and update market-proven designs.

Photo by RONI RAMOS

Jim Todd is director of sales and marketing for Amulet Technologies (Santa Clara, CA).

Copyright ©2003 Medical Electronics Manufacturing