Medical Device Link.

Medical Electronics Manufacturing Fall 1999

EMBEDDED SYSTEMS

Designing Monitoring Devices That Connect to Ethernet and Internet

John C. Harris and William Peisel

The list of medical devices that can be connected is endless. By using the existing networking infrastructure in hospitals and medical facilities, manufacturers can develop products that reduce the cost of connecting and managing medical devices.

The advent of a Web server on a chip and thin clients makes this type of connectivity cost-effective and relatively easy to implement. These products combine the Internet protocols of hypertext transfer protocol (HTTP), file transfer protocol (FTP), and POP3/e-mail into a single component. They also streamline the purchasing, support, and maintenance functions.

Background

Many of today's medical devices were not designed to communicate remotely, or they require additional proprietary equipment to do so. This forced medical institutions and doctors offices to either purchase a single-manufacturer solution or to integrate the different devices together.

Figure 1. Technology architecture for networking devices.

Another factor that has contributed to the lack of networking capabilities was the cost of connectivity: until 18 months ago, the cost of Ethernet was prohibitive. Adding a PC for Ethernet access would cost an additional $1000, whereas some devices themselves cost only $150–$200. With the introduction of Internet-enabled systems-on-silicon (hardware and software packaged together), local area network (LAN) administrators can now use existing networking infrastructures in hospitals and in other medical settings.

Connectivity Implementation

All monitoring equipment must support similar connectivity-related tasks, including:

• Installation and setup.
• Configuration and reconfiguration.
• Status monitoring.
• Data transfer.
• Issuing alerts (errors or failure conditions).
• Debug, upgrade, and/or maintenance tasks.

The tasks are the same regardless of the implementation required of the monitoring device. Internet protocols can address many of these required tasks, which alleviates the need for device designers to develop proprietary solutions. Furthermore, Internet protocols have the benefit of years of real-world testing on a wide variety of computers, operating systems, and network topologies.

Installation and Setup. For example, before a monitoring device such as a cardiograph can talk on a network, it needs to be assigned a unique address. For Internet protocols, that address is called an IP address. Well-defined utilities exist to obtain a unique address and to translate user-friendly domain names into numeric IP addresses. IP addressing utilities include Boot, DHCP, and domain name service (DNS).

Interface software is typically needed to complete the installation, setup, and configuration of a monitoring device. The setup interface is ideally intuitive, using a graphical user interface (GUI) with a familiar look and feel. A significant issue affecting device installation and configuration is the ability to configure it remotely, perhaps even from the manufacturer's site, as well as locally.

The old way—using proprietary software—resulted in vendor-specific configuration tools, each one different and usually only capable of being run locally. LAN administrators might need to wheel a setup cart to the monitoring device they were installing. Besides the limitations of this approach, device manufacturers had to make major investments in developing setup and configuration tools.

Marginally better is Simple Network Management Protocol (SNMP). Users have found SNMP to be anything but simple. Typically, SNMP requires high-end UNIX capabilities, and the GUI is far from intuitive. In short, SNMP was and remains a tool for information services specialists.

The adoption of HTTP, in effect giving each monitoring device its own Web server, eliminates a number of shortcomings. For starters, HTTP is platform independent both on the driving and receiving end. Almost everyone has access to a browser, which provides a standardized platform for applications. HTTP supports local and remote accessibility and can be served and accessed wherever the Internet is available.

Data Transfer. Monitoring devices typically require data transfer either in or out, such as downloading a program to save into electrically erasable programmable read-only memory (EEPROM) that can be subsequently executed. Designer concerns include not only the reliability of the connection to such devices, but error detection and data correction themselves. Internet protocols can solve such problems. FTP, which is a very well-known data-transfer protocol, guarantees data delivery and integrity. In addition to the simple file transfers most PC users are familiar with, FTP can read and write files, concatenate data onto existing files, and even read and write individual records. Most platforms support FTP, meaning data-transfer solutions are no longer platform specific, nor are they likely to cause problems when transferred to a newer computer—including future cpu designs. Rather than requiring development of proprietary solutions, using FTP also enables designers to use off-the-shelf programs that link Web pages to common databases such as Oracle, Filemaker, and Access.

Alerts and Warnings. The Internet offers monitoring device designers the POP3/e-mail protocol. Typically, monitors must issue asynchronous alerts. A monitoring device attached to an oxygen and pulse monitor must get a care provider's attention 24 hours a day. Designers need a fairly simple way to instruct the device whom to notify for what kind of alert. In other words, the alerting system must support different classes of users, from equipment managers to emergency contacts.

In addition to platform independence and familiarity, POP3/e-mail protocols for sending proprietary alert notifications support sending as many messages as desired. Messages can contain any data and can be sent to multiple lists of recipients. Messages aren't limited to two-digit hex error codes shown on a light-emitting diode (LED) display and can contain data leading up to the alert-triggering event. The recipient can be anywhere; perhaps even an expert who is thousands of miles away can advise local medical personnel. Most importantly, e-mail programs currently available can trigger a program to intelligently dial a pager, and if the message is not responded to in a predetermined amount of time, the program can escalate the notification.

Status Monitoring. For status-monitoring tasks, HTTP push technology can update a supervisory program; for example, it can calibrate data to maintain certain levels. A device could be designed to upload a Java applet to a browser for even more advanced monitoring functions. Lastly, hypertext markup language (HTML) combined with Java source code supplied to doctors and technicians can provide upgradeability. Just as user-programmable spreadsheets and macros revolutionized office computing, user-programmable HTML monitoring and control screens could revolutionize patient care.

Debug and Maintenance. Debugging and maintaining devices highlight the potential benefits of IP protocols even further. One of the most pressing problems is the increased complexity of devices, and the correspondingly greater amount of expertise needed to debug and repair them. With fewer experts capable of troubleshooting complex systems, how can a manufacturer get these experts on-site to so many medical facilities?

Manufacturers currently must use field-service personnel to perform even the most mundane tasks of calibrating a medical device such as a high-density CRT monitor. If a manufacturer had access to the CRT via the Internet, such a task could be performed remotely.

The solution, however, is not to get field personnel on-site, but rather to allow them to remotely view, diagnose, and repair complex systems. HTTP protocols could allow manufacturers to not only read and write memory locations, but to set and reset devices remotely. HTTP or Telnet could allow them to peer into supervisory servers supporting remote devices. Remote devices could have URLs for confidential use, secured by the use of secure sockets layer (SSL) or other encryption technologies, including firewalls and passwords. Manufacturers could regularly interrogate on-site devices, and, if necessary, download software patches or other upgrades to them from anywhere in the world.

Conclusion

Given all of the advantages of using TCP/IP protocols for setup, control, and monitoring of medical devices, why does it appear not to be happening? It is being implemented, albeit at a slow rate. The addition of software to support Internet protocols to a monitoring device isn't a trivial task. Until recently, it typically required adding a PC merely to support all of the network programming required, which might add $1000 to the cost of a device. In addition, a real-time operating system (RTOS) equipped with proper protocols such as an HTTP server was also required. Another reason for the delay is the cautious reaction from LAN administrators to adding another mission-critical device to their network infrastructures. They are concerned that a switch or hub that controls a critical care monitor could be shut down accidentally.

System-on-silicon solutions change the situation significantly (Figure 1). Such software enables designers to include a Web server on a chip with existing monitoring devices. The chips incorporate their own cpu, network interfaces, hardware interfaces, and software drivers for each Internet protocol. Based on a 32-bit processor, the chips support an RTOS that controls networking tasks. Designers can use the leftover power for the device's other tasks. This enables other chips or processors to be removed.

Such technology significantly reduces the development cycle of products incorporating network connectivity. Patient monitoring is only one area where embedded networking is expected to take hold. By significantly reducing the expertise level needed to add network connectivity to these types of products, IP-based networking is expected to increase dramatically.

John C. Harris is president of Paragon Innovations Inc. (Richardson, TX), and William Peisel is vice president of engineering for NETsilicon Inc. (Waltham, MA).

Back to the Fall 99 Table of Contents