Medical Device Link.

Originally Published IVD Technology July/August 2001

Connectivity of diagnostic systems: A better future is in sight

Ray Jones

Existing technologies and forthcoming global standards promise to link POC devices, laboratory automation systems, and medical information systems via the Web.

Ray Jones is program director for medical information systems at Colorado MEDtech/RELA (Boulder, CO).

A central issue for point-of-care (POC) diagnostic devices in recent years has been the connectivity of individual devices to other diagnostic systems or information systems. Each individual vendor has generally implemented a connectivity solution specific to its own product. In certain cases, the vendor provides other data management products specific to the same clinical application—however, only with the same use-limited connection modality as the particular POC device. The effect of this rampant vendor specificity has been a quagmire of independent products, independent systems, and disparate interface approaches, which have restricted clinical or business value to the end-user.

The impact of this situation on the healthcare environment is huge, both in terms of high costs to end-users and lack of opportunity for vendors to formulate new products based on the integration of data that can provide better clinical value. The magnitude of the issue is indicated by the recent formation of the Point-of-Care Connectivity Industry Consortium (CIC), consisting of 27 member organizations. It is highly unusual for a new standards organization of this size to emerge in a very short time. Even more unusual is the group's aggressive charter to define appropriate standards particular to connectivity for POC diagnostic devices and to actually produce a final standard within one year. Also noteworthy is the fact that the organization will cease to exist when its standards-setting efforts are completed. The final standards generated will be integrated into the work of other ongoing standards organizations such as HL7. Nothing about this trajectory is typical. It is as if vendors threw up their hands in despair at the incompatibility quagmire and decided to do something about it themselves quickly and effectively.

Figure 1. Relationships between primary types of POC device interface. Source: Connectivity Industry Consortium.

Table I. Nomenclature for global connectivity of POC devices. Source: Connectivity Industry Consortium, "Universal Connectivity Standard for Point-of-Care," draft technical specifications (2001), http://www.poccic.org/documents.shtml.

A variety of technology options are available to implement the functionality described in the CIC standard. They fall into two broad categories—PC-based systems and embedded systems. POC device issues identified in the CIC standard are, in certain cases, similar to those involving larger diagnostic systems. Both PC-based and embedded systems are offered in multiple vendor options, and each category includes systems that can both support a POC diagnostic device and be scaled to support a diagnostic system and interface it optimally with a laboratory information system (LIS).

PC-Based Systems

One approach consists of placing a local PC into the clinical environment. The PC supports integration of data from multiple devices or systems via either a multiport serial interface card or, as the CIC standard delineates, an Infrared Data Association (IrDA) interface. The PC may, if necessary, be operated from a medical isolation terminal in order to satisfy regulatory constraints. Software preloaded on the PC provides support for multiple device or system interfaces. In addition, HL7 interface software can be installed directly on the individual PC. A networked interface is supported by the PC; via Web server software loaded onto the computer, appropriate clinical and service applications can be configured either locally on the PC or remotely via the Web.

It should be noted that more than 60% of commercial Web servers use Apache Web server software running on Linux-based PCs or servers. The PC in such a configuration can run on either a Microsoft operating system (Windows NT) or a Linux-based PC solution. Linux systems are widely available from several vendors. Some vendors have recently introduced low-cost, small-footprint PCs that are especially well suited for the space-restricted applications in clinical environments.

Many diagnostic instrument systems are PC-based, allowing software components to be added to a core PC system that is part of the diagnostic instrument. In such cases, ensuring that the instrument design has adequate throughput and capacity to support the added functionality of the connectivity solutions becomes a critical issue. When those conditions are met, the PC approach is very economical. Plus, it offers the user the possibility of a software upgrade to an existing hardware platform without the need for major system upgrades. However, if the existing PC system is already constrained in supporting the overall diagnostic system, then the addition of new functionality can create problems for base-system performance. To resolve this particular issue, some vendors offer plug-in cards with their own internal processor in order to ensure that performance of the host system is compromised as little as possible.

Regulatory issues are also critical for PC-based systems. Often it is important to isolate the connectivity arrangements and information-system functions from the base diagnostic system, so that FDA approval of the two components with different regulatory requirements can proceed independently. If such isolation is viable, then use of the base PC in the diagnostic instrument is a good solution. However, to retrospectively add functionality in an isolated manner may prove difficult, in which case more-isolated system designs are called for. The PC-based approach has advantages and disadvantages (see Table II).

Table II. The trade-off of advantages and disadvantages with a PC-based diagnostic instrument system.

Embedded Device Systems

Another approach to connectivity takes the form of a small, low-cost device embedded in the diagnostic instrument. This approach architecturally isolates connectivity from both medical device or system performance and the clinical user. Conceptually, the device supports multiple serial ports, with an Ethernet interface. Data-standardization software is downloaded over the Web and provides both a specific type of device interface software and a customized HL7 messaging engine configuration. A Web server is also provided to enable both clinical applications and service applications to reside either locally on the device or remotely on a browser accessing data gathered by the device. The embedded device functions as a generic platform, allowing the clinical user to upgrade the software over time in order to accommodate various device interface protocols, HL7 messaging-engine configurations, clinical applications, and service applications.

Recent advances in technology have brought technical and economic feasibility to the embedded-device approach. Just as the PC domain evolved in the 1990s from a stand-alone environment into a network-enabled, Web-based environment, so now the technology exists to support a similar trend with embedded systems. In the commercial market, the need for connectivity of RS-232-based devices has resulted in industries devoted to a networked-appliance concept. That is, any device or system with a serial port is enabled to provide connectivity over a network and has the potential to convert each device in a system into its own Web site. This trend has also reached healthcare, but with critical distinctions in use and regulatory requirements and in connectivity standards.

Like PC-based systems, embedded-device solutions to connectivity entail both appealing qualities and drawbacks (see Table III).

Table III. The trade-off of advantages and disadvantages with an embedded-device approach to connectivity.

PC-Based and Embedded-Device Systems Compared

Specific vendor product examples will illustrate existing technology options in the areas of PC-based and embedded-device solutions (see Tables IV and V). The systems presented in the tables are measured against the functional requirements of a connectivity solution. All three embedded-device vendor options support the concept of a network-based connectivity solution. With embedded-device systems, there are more types of business and technical models in place than with PC-based systems.

Table IV. PC-based connectivity products from two vendors compared with reference to functional requirements.

No single technology option is appropriate for all solutions. As the examples in the tables suggest, a given application or particular business need may drive a customer toward either a PC-based approach or an embedded-device approach. Additional factors to consider in selecting connectivity approaches for POC diagnostic devices include the following.

PC-based systems offer the flexibility to choose a full-featured Web server; however, the user then becomes responsible for configuring the Web server and its associated application. Embedded devices offer Web server capability at less cost than PC-based systems, for both software and hardware (i.e., memory and disk requirements). So, for a Web application that is relatively small, an embedded device is a good choice. If the Web application is large, then a PC-based approach will probably be better.

HL7/ASTM solutions are typically offered only in a PC-based mode. Only one embedded-device system offers this capability.

From an overall cost perspective, the least expensive solution depends upon the application. It is important that "least expensive" be defined over the long term as well as in immediate reference. Just as with a POC device or diagnostic system itself, the capability of a connectivity product to be upgraded to enhance functionality should be considered at the time of initial product selection.

Future Market Drivers

In the light of existing product options, it is useful to refer to the original set of functional requirements for POC diagnostic device connectivity solutions and determine what factors will drive this market over the next several years. By assessing these driving forces, both users and vendors can make better technology decisions so that a solution appropriate for particular short-term needs will, even more importantly, remain viable over a long term of application.

Adaptability to Changing Interface Standards. The rapid launch of the CIC reflects the dynamic nature of standards. The search for a healthcare plug-and-play standard continues, with the rise of new standards bodies such as CIC being set against the current reality of many HL7 interfaces. The sardonic saying, "When you've seen one HL7 interface, you've seen one," illustrates the diversity of interfaces in use today. Given that the healthcare world has yet to see a truly plug-and-play solution, it is reasonable to assume that standards will continue to change. This assumption drives selection of the technology platform in the direction of one that is flexible and adaptable to changes in standards.

Support for Local Applications. Connectivity solutions hold promise for providing localized application software specific to the product and its clinical domain, as well as connectivity. The ability to analyze data locally at the device or system and then, following logic contained in the application, to move to a variety of decision support modes offers enormous new potential for healthcare. To be able to dynamically update this local software application in accordance with changing needs is exciting. Selection of a particular technology option thus should involve consideration of the software development environment offered on the connectivity solution. Is it expandable? Can an existing software application be ported to the connectivity solution? Does it follow programming standards? These are all critical questions that must drive vendor selection.

Support for Operation in Connected, versus Disconnected, Mode. In an ideal world there would be a network connection near each device, and that network connection would be fully operational all the time. But in healthcare environments, network accessibility is not always readily available, and it is important for the connectivity system to operate in an isolated mode. The system's ability to reconnect in a seamless manner and to transmit data over the network to the enterprise once the network connection has been restored becomes critical.

Support for Hardware Connectivity Options. In many cases, a network connection is the optimal interface point for connectivity solutions. Yet, in a POC environment with a potential home-healthcare setting, the availability of modem support is also crucial. Other types of wireless interfaces such as IrDA, 802.11, and Bluetooth offer prospective benefits in different product areas as well. Thus, the adaptability of the solution to different connectivity options is important.

Regulatory Constraints. Generic network appliance technology may not work well in a healthcare environment. The appropriate solution is often driven by regulatory issues related either to adding to an existing product or by incorporation into a new system design. Specific requirements for healthcare may be unique. Selection of an appropriate technology can depend upon access to expertise covering the medical and regulatory issues surrounding implementation of a connectivity system for a particular product or application.

Conclusion

The market forces just discussed indicate a need for a generic, expandable, POC-device connectivity solution. Providing a system that works today for one specific application area is not good enough. A more beneficial approach is to supply a Web-enabling platform that can support future connectivity needs, service applications, and clinical data systems.

Whether the connectivity system is PC based or an embedded device, the net result of the technology is a versatile platform for POC diagnostic devices that can be used in conjunction with an existing large-scale diagnostic system. The consistency of the technology base then allows vendors to quickly adopt a solution that applies to all of their products, whether for POC devices or large laboratory automation systems. Devices such as those portrayed in this article, when developed under standards as defined by POCCIC, represent a substantive response to the dismaying current state of device connectivity.

Copyright ©2001 IVD Technology