Medical Device Link.

Originally Published MEM Fall 2001

NETWORKING

Network-Enabling Technology for Medical Equipment: Build or Buy?

Manufacturers facing this decision must balance cost considerations and time-to-market requirements while appraising all the available technology options.

Tom Armbrust

Healthcare industry demand for medical device networking solutions is growing. The Health Insurance Portability and Accountability Act (HIPAA) of 1996, industry consolidations, the push toward patient management within alternate-care sites—all of these contribute to the need for equipment manufacturers to supply products with reliable networking capabilities. Fortunately, advances in networking technology and the Internet are opening the door to a network-enabled healthcare world just as healthcare providers are knocking on it. It is happening now. Medical devices, equipment, and systems are communicating with one another—over networks and the Internet—in healthcare environments as diverse as hospitals, nursing homes, outpatient care centers, and patients' homes.

The big question

The question of the moment is this: How can networking capabilities be added to medical products without spending a fortune? It is a question that ultimately comes down to whether the manufacturer should invest time and its own engineering resources in building networking capabilities into a product design, or buy ready-made technology from an outside vendor.

Chips, Boards, or Boxes?

Before deciding whether to build or buy the technology to network-enable its product, the manufacturer must decide at which level to integrate networking functionality into the device design.

An integration option that involves a minimum unit cost and the maximum investment of time and resources is the Ethernet controller integrated circuit (IC). A number of these chips are available. They come with various levels of integration, from simple media access controllers (MACs) to chips that have not only the MAC but also the physical layer interface (PHY) electronics. Higher levels of integration incorporate a processor, memory, and a number of other interfaces that allow serial, parallel, infrared, fiber, and wireless connectivity. Some of these single-chip solutions are bundled with the necessary software and tools, including a real-time operating system (RTOS), a Transmission Control Protocol/Internet Protocol (TCP/IP) stack, and related network applications, in order to significantly reduce product development time.

Board-level solutions of various sizes can be embedded into the medical electronic product for a higher—though still moderate—unit cost and with smaller demands for development time and resources. The only requirements imposed by this approach are adequate physical space for the board, an available serial port, and power, typically 5 V dc. Board-level solutions usually include all of the elements needed for device networking: a processor, an RTOS, a robust TCP/IP stack, a Web server, and a network connection to provide an Ethernet bridge to the product. Some board-level solutions are as small as a matchbook.

If time to market is important, or if the equipment requirements accommodate an accessory approach, then the product can be network-enabled through an external stand-alone box. As with the board-level approach, external boxes use an existing serial port (RS-232, RS-422/485) to add network connectivity. They have a DB9 or DB25 connector on the serial side and 10/100Base-T (RJ45) or 10Base-FL (ST) connection on the Ethernet side. This design approach generally involves the highest per-unit component expense to achieve networking capability, but it provides the quickest and easiest way to get a product to market.

In deciding which level of integration best fits the product requirements, the manufacturer should consider the importance of reliability.

Overall product reliability is influenced by the number of components in the design, the method used to mount the components to circuit boards, and the type and quality of connections between circuit boards. A manufacturer's exposure to risk from the operational failure of its equipment varies inversely with the number of components in the product's hardware. Selecting parts with a higher level of integration minimizes such issues. For example, integrating a single memory chip into a single-chip solution can eliminate more than 30 interconnections from a circuit board, resulting in improved reliability (see Figure 1).

Figure 1. A block diagram of a single-chip solution.

Reliability gains can also be realized by switching to surface-mount technology and newer chip packaging styles. Yes, even in the twenty-first century, products are still being designed and built with through-hole parts!

For these reasons, the inherently more robust design of a highly integrated embedded board solution or single-chip solution is worth considering. This option becomes compelling if the network-enabled product under develop- ment will be installed in remote, hard-to-reach, or environmentally challenging locations.

Software for Serial Tunneling

After deciding whether to build or buy the hardware required to network-enable a particular product, the manufacturer must then determine whether to develop its own software, go somewhere to buy portions of the software, or leverage ready-made solutions created by other companies.

Anyone considering using a ready-made solution should be aware of a new category of connectivity technology that provides the benefits of networking with very little investment in hardware and software. An example of this technology is the device server.

Device servers are specialized computers that contain a central processing unit (cpu), an RTOS, a TCP/IP stack, and an Ethernet connection to provide a bridge to serial devices with TTL, RS-232, RS-422, or RS-485 connections. By encapsulating serial data in network packets and transporting them over an Ethernet network, device servers enable virtual serial links to be established over extended distances. They are available as chips, boards, and boxes.

The process of transporting serial data over Ethernet is often referred to as serial tunneling and is analogous to sending a letter via the postal service. The "letter" in this case is the serial data, the "envelope" is the TCP/IP packet sent over the network, and the "postal service" is the network infrastructure. No matter what the content of the letter, the person on the receiving end can open the envelope, remove the letter, and view the information written on it. By design, serial tunneling is transparent to both applications software and the connected devices, often requiring no software or device configuration changes.

Ethernet supports multiple protocols over a common medium. This gives the equipment designer the freedom to choose the protocols to be used and the opportunity to use the same infrastructure for new protocols as they become available. Where local-area networks (LANs) or wide-area networks (WANs) are established, device servers enable equipment to use this infrastructure to form connections with remote serial devices.

In the most basic configuration, two device servers are installed back-to-back over an Ethernet network, forming a conduit for serial information to flow through in both directions. Where this technology is used to replace a direct serial connection between a personal computer (PC) and a medical device, the connection is transparent to applications software on both the PC and the connected device. Thus, no software or configuration changes are required. This concept can be expanded to extend the connections throughout a facility, among different buildings, or across a global network. The only downside with this configuration is that it still requires one dedicated serial port on the PC for each device connected (see Figure 2).

Figure 2. In the technique called serial tunneling, one remote device's serial port can be accessed over the network with the use of a device server.

But what if the device server attached to the PC could be bypassed and the PC connected directly to the Ethernet network? There is indeed software available that can emulate the function of a device server. Commonly referred to as redirector software, it allows virtual serial ports to be created on the PC that can redirect device data through an installed Ethernet adapter (see Figure 3).

Figure 3. Using redirector software that emulates the function of a device server, remote devices can be accessed over networks using existing and legacy applications. Dedicated serial ports are no longer needed.

Device servers used together with redirector software in this configuration provide an attractive means to carry serial information over Ethernet and IP networks. Configuration tools allow users to create virtual serial ports and assign them to remote device servers on the network. For example, on a PC with only two serial ports physically installed, redirector software could be used to create a virtual serial port and map it to a remote device server.

OSs and Application Protocols

A manufacturer considering developing equipment networking software in-house has to be prepared to spend a few man-months just to produce a minimal operating system (OS) and rudimentary networking support. A full TCP/IP protocol stack and application-level services like e-mail, file transfer, and a Web server will take a few more months. Most companies have invested several man-years of labor in their TCP/IP stack alone.

Might the manufacturer someday switch to a different processor platform? Such a switch will derail most in-house software efforts. But an RTOS developed by a company specializing in embedded-OS development is likely to support multiple cpu platforms while maintaining a common applications interface, thus providing a high level of portability for the device manufacturer's applications software. Such specialty companies generally support a large number of peripheral chips as well, facilitating the integration of new technology. Commercially available RTOSs are mature products. Therefore, the investment can also be thought of as buying down the manufacturer's up-front risk, long-term maintenance, and liability if standards-based certification is required in the future.

A variety of vendors offer commercial RTOSs and TCP/IP protocol stacks. The best have been in business for decades and support dozens of microprocessors. The best also provide robust Ethernet support and offer other network-related protocols from a smorgasbord of options.

If the equipment manufacturer decides to buy rather than build the OS or stack, then it is important to choose a vendor with a track record of robust, well-documented software. The software should be compliant with all of the associated standards or requests for comments (RFCs), the definitions of protocols and policies on the Internet. It should have been validated against an independent test suite, thus assuring RFC compliance and functionality. And the supplier should be keeping up with advances in technology. Does the supplier have, or is the supplier working on, Internet Protocol Version 6 (IPv6), Voice over Internet Protocol (VoIP), wireless, or other new technologies? Who are the supplier's major customers, and are they satisfied customers? Did they find integration of the vendor's product easy? These are questions the manufacturer should ask.

Several purchasing options exist, ranging from royalty-based arrangements to the outright buying of source code. Such factors as willingness to incur up-front expenses and projections of lifetime unit sales will determine which RTOS purchase option makes the most economic sense for a particular equipment manufacturer.

It is sobering to think about the amount of effort that has gone into network-enabling software. For example, a commercially produced RTOS contains nearly 10,000 lines of code and embodies more than five work-years of effort and refinement. When support is required, a simple phone call or e-mail brings it. Similarly, commercially produced TCP/IP stacks each represent more than 20,000 lines of code and take as long to develop as an RTOS. Developing such software is no piece of cake!

Conclusion

So, should the manufacturer of a medical device interested in network-enabling its product buy or build the necessary technology? Consider the following facts:

• From chips to boards to boxes, there is an inverse relationship between per-unit hardware costs and development time required to achieve networking capability.
• Single-chip hardware solutions can dramatically simplify product design while helping to improve overall product reliability.
• Serial tunneling offers a way to quickly add networking functionality to products without having to make changes to their software.
• Time spent developing an RTOS or a TCP/IP protocol stack is time not spent applying the core competencies of the company.
• Commercial RTOSs and TCP/IP protocol stacks, available separately or packaged together, can significantly reduce product development time.

In the final analysis, facts alone cannot be the basis for a decision to build or buy. Only a well-informed management team, one that understands the core competencies of the engineering staff, the project's time-to-market constraints, and its budget, can make the call. Successful decision makers will fully appreciate the many ramifications of any decision to build. They will not underestimate the long-term maintenance risks, nor overvalue the possibly only short-term financial rewards associated with attempting to build what might be bought.

Tom Armbrust is the medical marketing segment manager at Lantronix (Irvine, CA), where he is responsible for the company's focus on medical device networking. He can be reached at 949-453-3990.

Copyright © 2001 Medical Electronics Manufacturing