EMBEDDED SYSTEMS
Internet-Enabling Medical Electronics
By networking devices powered by 8- and 16-bit microcontrollers, medical device manufacturers can tap a wealth of previously inaccessible information, resulting in enhanced medical solutions and quality of care.
Todd Rytting
Reducing the cost of healthcare while improving quality of care is the seemingly impassable hurdle that everyone in the medical industry is facing. Engineers and medical device manufacturers must address a similar challenge. Medical electronics must be ever more sophisticated. Devices must do more to assist healthcare professionals, who are seeing more patients per hour than ever before. Devices must assume some of the burden for understaffed nursing departments and must also help the home health professionals, who are providing more acute care than ever before. In general, medical device manufacturers are being called on to provide cost-effective solutions that providers, patients, and insurers expect.
Networking Medical Devices
Networking is a tool that can help healthcare professionals do more with less. By Internet-enabling medical devices and tapping into previously inaccessible but highly valuable information within those devices, medical device manufacturers can have a dramatic impact on the future of healthcare. Building network and Internet capabilities into devices provides remote-monitoring capabilities that can improve care and communications—not to mention productivity. Remote networking of medical devices can also improve hospital and clinic inventory control, as well as other back-office administration. In fact, the increasing number of applications for device networking should provide manufacturers with many opportunities to expand device functionality.
To examine the potential of Internet-enabling medical devices, consider a blood pressure monitor and the millions of people affected by hypertension. With a blood pressure monitor that can upload timely, accurate data to a database in a doctor's office or hospital, clinicians can monitor at-risk patients and alert them when their blood pressure is approaching a dangerous level. This enables patients and clinicians to take immediate steps to treat the problem and therefore prevent a heart attack or stroke. Rather than requiring patients to make daily trips to a hospital or clinic for blood pressure checks, the same process of information sharing and diagnosis can be automated and accomplished remotely with an Internet-enabled blood pressure monitor. Clinicians can download patient data to their personal digital assistants (PDAs) or personal computers. They can also be alerted via e-mail messages to pagers or cell phones. An example of such a device is the Internet-enabled CARE monitor (Matsushita Electric Works).
Internet-Enabling Basics
Vital-signs monitors and many other medical devices use 8- or 16-bit microcontroller units (MCUs) to control their operation. Developers must therefore be highly aware of processing-power and memory constraints when writing software. Such software development differs considerably from the PC applications environment, in which software developers can write code-heavy applications because the processor and memory can handle the load. Both 8- and 16-bit MCUs have much more limited capacity, and frugality is therefore a necessity.
A device-networking infrastructure is most suitable for lightweight communications channels such as RS-232, RS-485, modem, power line, infrared, and radio frequency for 8- and 16-bit MCU designs. The heart of such an infrastructure is a standards-based software. The development environment should include the tools and support to Internet-enable existing medical devices without requiring the addition of unnecessary hardware or memory-hungry software in the device. With this infrastructure, information derived from these medical devices can be distributed to a Web browser, PDA, telephone, database, spreadsheet, or other user interface.
Figure 1. The components of a software-suite infrastructure.
The key to a distributed approach is to provide the embedded product—in this case a medical device—with communication software that has been optimized for the environment and to move complementary, higher-level networking functionality to a Windows or Linux platform. The software should be the basis for an end-to-end solution that uses Internet technologies appropriately, by not requiring the device to take on the burden of communicating with the entire Internet. A communication kernel allows connectivity with 8- and 16-bit devices and facilitates fast and efficient handling of information packets without consuming too much of the limited memory on the controller. Some technologies include device-network management software designed to run on Windows NT and Linux platforms. This software acts as a bridge between the device networks and larger networks like the Internet. The software should provide space for higher-level networking components, such as the Web server, communications stack, security and access control, and other required functions.
One obstacle to networking embedded devices is fitting an entire object server into an 8-bit microcontroller. One solution is to provide a mechanism for exporting the capabilities of the embedded device in the form of a network object that can then be integrated into network-based applications. This approach adds value to an embedded device. Because it does not have the size constraints of a hardware interface, a more intuitive interface can be created using a Web browser or a custom network application (using Visual C++, Visual Basic, etc.). Information previously confined to a device can be exported and used by network applications and user interfaces. This approach also enables the embedded application to be enhanced with information from the Internet. For example, data from the blood pressure monitor previously described could be compared with a database on the network, and statistical parameters or trending information could be reported back to the device for display to the device user.
Of course, some trade-offs should be considered before embedding a server into an 8- or 16-bit MCU. The software must sacrifice a modicum of functionality and performance in order to accomplish network-based device control on tiny controllers. These trade-offs, however, are more than compensated for by the remote-control capabilities and information access provided by network enabling.
The Fundamental Architecture
A software-based device-networking infrastructure can be made to accommodate legacy, current, and future systems. The software-suite infrastructure should consist of the following software components: a small object server that runs on the embedded device, a networking protocol that allows device communication over lightweight networks, a software bridge and management system that connects lightweight networks to wide-area networks, and a development library that allows integration of any user interface (see Figure 1).
The object server can be as small as 1 Kbyte and resides on the networked device. Once integrated into the device application, it presents embedded application variables, events, functions, and other information to the network. In this way, clients on the network can control, monitor, and collect data from the device. Because such software is designed to run on microcontrollers with limited resources, it requires minimal memory and processing power. At the same time, it provides scalability, flexibility, and functionality. For the medical electronics industry, a small object server can be a cost-effective way of enabling products to communicate with each other on a network.
The networking protocol lets devices connect to low-cost, lightweight networks. Developers can implement any supported protocols by recompiling the device application with the appropriate object server.
The software bridge connects lightweight networks to wide-area networks (WANs), in effect providing similar functionality to network hubs, switches, or routers. The bridge can run on network servers on top of Windows NT or Linux and perform high-level network communication and management processes. It passes information from the device to the WAN or Internet.
The development library enables the creation of flexible user interfaces (from Web browsers and PDAs to cellular telephones and databases) to complete the networking infrastructure. The library can include Java, ActiveX, and C/C++ services, as well as dynamic services that can be used to integrate any application into the device network. These applications and interfaces can control, monitor, and collect information from the devices across TCP/IP-based networks via the software bridge.
Benefits for the Developer
The software-based infrastructure gives designers wide latitude for selecting the most appropriate technologies to fill their specific requirements. It makes the most of a device's own technology, leveraging the money and time invested in the original design. Also, by supporting open Internet standards and defining open application programming interfaces (APIs) and protocols, the infrastructure can ensure compatibility with existing and future technologies (see Figure 2).
Figure 2. Device-networking infrastructure.
On the client side of networking, it has been suggested that the best approach is to build to the Java platform for browser-based user interfaces. Although this approach is appropriate for many solutions, it has some drawbacks. For example, in cases where networked devices need to send information to databases for analysis, a library of client tools may be more suitable. A device-networking infrastructure can accommodate these tools and many standards, including Java. In particular, a software bridge and management system can provide flexibility and technology independence. APIs allow the addition of new interfaces, network technologies, and service applications without system replacement. Moreover, as systems become large and complex, the network management need not follow suit. The device-networking infrastructure can simplify system management, because one function can be used for multiple devices. For example, blood pressure monitors and infusion pumps—even though they monitor different aspects of patient care—can use the same notification process, such as a call placed to a cellular phone or pager.
Additionally, a simple system and implementation eliminates the need for custom network operators. Instead, commercial network suppliers, such as AT&T Global Network Services, can provide the WAN infrastructure for networked devices. Using a commercial network provider to maintain the network infrastructure frees the hospital or doctor from managing large WAN issues such as security and administration.
Device manufacturers who attempt to develop systems from the ground up may find development cycles to be longer than expected, and long-term support and maintenance can present unforeseen problems. Some infrastructure elements are available virtually off-the-shelf and require no radical modifications to a device (other than the addition of an object server and the desired communication transport, if not already present). Also, many approaches, such as those that attempt to put a full TCP/IP stack in a device, require a separate—and likely 32-bit—processor just to handle the communications requirements. Forcing devices using MCUs with limited memory to use Internet protocols when simpler protocols are sufficient increases system cost and complexity, whereas a small object server typically runs in the networked device's own 8- or 16-bit microcontroller. Still other approaches use a combination of network controller and software, again requiring an added controller, which increases cost and complexity.
Optimizing Embedded Code
The end result of device communication development efforts should be an object that represents the capabilities of the device. All data to be made public is exported from the embedded application to the object server and then through the network. The exception-handling mechanism for the object provides a way to signal alarms, request services, and perform other device-initiated actions.
The goal is to identify the parts of the embedded application that should be exported, and then create a network object that represents this interface to the device. In essence, the technology acts as the control panel for other machines or user interfaces to use in accessing a device. A straightforward package utility can help device engineers through the process of deciding which functions, variables, and events should be exported. Such a utility lets engineers choose whether the device will serve up certain documents (information on the device) to the user interface. The package utility can be used to create a set of data that resides on the device and is used by the object server, the device-resident portion of the infrastructure. The utility can also be used to create an intermediate file that describes the exported application interface.
The object server can be set up to interact only with the portions of embedded applications that are explicitly exported using the utility. It is not necessary to limit or predefine the way the code is exported. It can be as simple as having the user interface perform a function similar to that of a knob on the device. It can also be powerful enough to reload the flash memory for the device application. Once the exported components are identified using the package utility, the object-server code is integrated with the application by compiling the embedded application along with the object server and the definition tables, and then placing the executable code on the MCU.
The remaining tasks include software-bridge setup and connection, followed by the creation of the user interface, which can be as simple as a template file that identifies useful information for data collection. The file is usually formatted for database compatibility and contains the variable values for the embedded application at the time it is accessed for retrieval. If more-sophisticated user interfaces are desired, a visual-interface builder can be used to design any interface. With the success of the Internet as an occupational and recreational tool, engineers worldwide have been working to ensure both access to the Internet and the integrity of the Internet infrastructure.
Using Symantec's Visual Café, the graphical user interface portion of the application can be created to communicate with an embedded object via the software bridge. At run time, the Java applet connects to the bridge, which provides access to the device as a networked object. For example, the following is a Java code excerpt that sets up an applet for communication with an embedded device via emGateway, the software bridge for emWare's device-networking infrastructure:
jri = new Xemitjri();
String device_path = "http://localhost/ RS232+COM1/0/";
emComObject device;
device = emComUtils.initTCP (device_path);
jri.connect(device);
jri.addEmbeddedVariableListener (this);
jri.subscribe("systolic");
jri.subscribe("diastolic");
jri.subscribe("pulse");
jri.subscribe("SPO2");
jri.subscribe("Alarm");
jri.addEmbeddedVariableListener(alarmLED);
alarmLED.addJriLink("Alarm", "LEDOn", 0);
resetSwitch.addEmbeddedVariableListener(jri);
resetSwitch.addJriVariable ("Alarm","ActiveEvent");
jri.updateAll();
A Boon to Long-Term Care
Network-enabling vital-signs monitors has many applications in healthcare. Other applications of device networking, however, are just now emerging that are more unusual in their approach. For example, engineers at Matsushita Electric Works are adding Internet connectivity to numerous medical electronics for remote access, management, and diagnostic capabilities. One such product designed for long-term care facilities is the CARE monitor.
Providing adequate care for the growing elderly population is one of the great challenges of the new century. Having sufficient staff in nursing homes to monitor the health of many individuals is becoming a more expensive proposition. The conventional solution—video cameras in each room and an attendant managing multiple video streams—is costly and potentially ineffective. An attendant must either view a bank of video screens or page through all the video streams on a single monitor. Either way, an attendant could easily overlook a patient in distress.
The CARE Monitor is helping facilities in Japan to solve this problem cost-effectively. This prototype product uses remote video cameras mounted in patients' rooms. As with conventional methods, the video images transmitted from the cameras are displayed on a user interface monitored by an attendant. However, because the cameras are network-enabled, they provide additional functionality. The individual cameras can generate alarms or alerts, which are displayed on a Web-browser user interface with the appropriate icon to indicate what the problem might be. For instance, if a patient's sleep is agitated, an attendant is notified. The situation can be assessed on-screen without having to leave the central control station.
The firmware embedded in the individual camera controllers includes the object-server portion of the software and in this case uses 3 Kbyte of memory in the camera. A server that hosts the software bridge and management system communicates with the individual cameras via a networking protocol running over Ethernet. On the client side, the development library enables integration of the Web browser with a custom interface built using Java Beans objects.
Retrofitting
Many medical device manufacturers have a dilemma: they see the need to move forward with a new generation of network-enabled devices, but they have a huge installed base that is still going strong and providing value for their customers. Retrofitting products that are already in the field can ensure continuity and compatibility to old and new product lines. For example, a recently built prototype of a small black box fits on the side of an infusion pump and plugs into the pump's existing serial port. Inside the black box is an inexpensive microcontroller that converts the existing manufacturer's communications protocol into a protocol that can then be networked over the Internet. In the case of the infusion pump, this added functionality can notify nurses if the tube becomes clogged or if bubbles appear in the solution. It also alerts a nurse when the fluid runs out or if the pump has been installed incorrectly. With this system, information can also be conveyed to pagers, PDAs, PCs, etc. The only requirement is that the device, in this case an infusion pump, has some kind of communication capability built into it.
Troubleshooting and Resource Management
Troubleshooting capabilities are also possible with a device-networking infrastructure. Medical devices can be programmed to record in memory an operator's keystrokes. A manufacturer can then download that information to determine a sequence of events that can help troubleshoot a problem remotely. This is an especially valuable solution for medical electronics manufacturers to deter product returns due to malfunctions caused by operator error. Remote testing and configuration are possible, too.
Lastly, much more efficient resource tracking can be accomplished in hospitals with network-enabled devices. Infusion pumps are a good example. They are often scattered throughout hospitals with no system for tracking them. But with device networking, equipment can be identified in a database and tracked at all times. Equipment condition service records can also be updated and maintained regularly.
Conclusion
No industry maintains information that is more critical than that in the healthcare industry. Whether a nurse is checking postsurgical progress, a physician is making a diagnosis, or a public-health researcher is assessing the magnitude of a disease outbreak, accurate and timely information is essential. By networking medical devices with cost-effective, embedded networking technology, the design and manufacturing community can add substantial value to their devices.
Todd Rytting is vice president of technology for emWare (Salt Lake City).
