Email this Page
Print this Page

PORTABILITY

Furthering the Evolution of Networked Portable Devices

Advances in embedded technologies for mobile and home-care devices include the commodification of power and communications subsystems.

Lawrence Ricci

With the number of U.S. senior citizens projected to double between 2000 and 2030, technology is advancing to meet the need for new medical devices to provide better, more-cost-effective healthcare for this expanding potential patient population. Developing these new medical devices often requires the application of technology originally developed for such consumer electronic devices as personal digital assistants (PDAs) and cell phones. This electronic communications technology is fundamentally different from the electronics used in the last generation of medical devices, and it consequently presents challenges. To meet these challenges, new design and engineering techniques—including partnerships that span the supply chain—are emerging.

Today’s effective medical device design requirements are, first and foremost, prescriptive compliance with regulations, an extended product life cycle, a short product development cycle, and, of course, product safety. The new challenge—with the advent of connected portable medical equipment—is to meet these goals and also design in modern communications, high device reliability, and, sometimes, battery-power or power-management systems. New designs that achieve these ends not only will mean improved devices available for use in clinics and medical centers, but also will facilitate the migration of sophisticated monitoring and therapeutic devices from the healthcare facility to patients’ homes.

Communications Now Fundamental

Ten years ago, medical monitoring typically was performed using individual devices that were not interconnected. If data were linked at all, it was through the writing of notes on a clipboard. Now, however, to both reduce costs and improve access to data, most devices used in the hospital or the home—whether diagnostic or therapeutic—must be networked. Networking answers the imperatives to reduce errors and accelerate data exchange. This need to network medical devices is occurring at the same time as rapid advances in digital radio technology are expanding the realm of what is possible. Also, rapidly maturing Federal Communications Commission (FCC) guidelines are leading to regulations to control the safety of interconnected medical technology.

For a time, in addition to wired Ethernet, in-hospital devices used electromagnetic spectrum shared with local land mobile radio and television stations but not protected from them.1 Since 1997, with FCC assigning more bandwidth for high-definition TV, some devices in hospitals have been reset to use channels still left unoccupied.2 This is only a small change in the landscape, however, affecting mostly legacy devices and their one-for-one replacements. The most popular new communications technology is 802.11 and its variants published by the Institute of Electrical and Electronics Engineers (IEEE).3

Here is where the interface between FDA regulations, FCC regulations, and Federal Information Protection and Security (FIPS) regulations becomes complicated by the reality of fast-moving, high-technology consumer hardware and software. Keeping abreast of these issues, FDA recently published a draft guidance that invites discussion of the evolution of the various device design guidelines in Title 21 of the Code of Federal Regulations (21 CFR).4

Wi-Fi: The Standard

The 802.11a/b/g networking specifications define only the most basic level of device compatibility. Workable interoperability typically demands additional conformance to the Wi-Fi Alliance specifications and to a suite of extensible authentication protocols (EAPs) and other features, sometimes identified as the Cisco Compatible Extensions (CCX). The CCX protocols are now at Revision 4.5 Additionally, a variety of application extensions are currently necessary to make it practical and simple to do things like log on securely and transfer from one access point to another.

Figure 1. (click to enlarge) A simplified outline of 802.11x/EAP authentication. Source: Summit Data Communications Inc. (Akron, OH).
The mechanics of managing a portion of the EAP of a Wi-Fi network can be outlined simply (see Figure 1), but, in practice, multiple 802.11 devices adhering to different access protocols will contend for the same airspace and spectrum. All of these—including invited and uninvited guests in the area carrying PDAs in their pockets—need to be administered.

Diligent third-party testing and application-focused implementation tend to mask all this complexity so that the device user is unaware of it. The designer of a laptop knows that such a computer typically is operated from a desktop. Thus, its connection to an access point should be, in the jargon, sticky. The designer of a PDA, on the other hand, knows that the user of that device will be on the move from one access point to another, needing to reconnect frequently (slippery connection). Medical device engineers need to design these properties in; for some devices, properties like stickiness are mandated by regulation. Getting this aspect of the device design right is not as simple as selecting the right communication function card. The problem is that standards change quickly. A communications chip selected in January for an application may be an end-of-life component by fall, and approval cycles may consume much of the time in between. Careful coordination between the manufacturer’s design team and supply chain management is needed to apply technologies such as 802.11 in medical devices effectively.

MedRadio to Follow MICS

Many other forms of communication also are being used in medical devices, or being planned for them. All of them are regulated and protected by FCC, and all of them entail certain design and testing standards. Most critical are the recently proposed FCC standards for medical device radiocommunication service: MedRadio.6 This term relates to expanded bandwidth for implanted and body-worn medical radiocommunication devices. The older rules for the Medical Implant Communications Service (MICS) are still largely in place, including the rules for low-frequency, inductively coupled sensors.7

The promise of MedRadio is great. Patients can wear various vital-signs monitors, and even therapeutic devices such as insulin pumps, yet still have reasonable mobility within the healthcare facility and at home. The hope is that, as new wearable and implantable devices are developed, more of the chronic-care burden can be moved out of the hospital or expensive nursing home and into lower-cost assisted living and home care.

These networks require additional testing: for susceptibility, for emission, and for certain protocol behaviors—for example, to check for a frequency before using it. This testing would be well advised, because the clock frequency of modern PDA and cell-phone components is in the range of MedRadio, and the frequency of the low-frequency, inductively coupled MICS devices is in the range of the switched-mode power supplies that power this class of device. The specifications for susceptibility and emissivity can be tight, so design features may have to be adjusted to meet them.

Metropolitan-Area Networks

Healthcare professionals can be scarce in rural areas of the United States. Therefore, as an experiment, FCC established a pilot program in September 2006 that will assist in developing and deploying regionwide broadband networks dedicated to the provision of healthcare services to underserved consumers.8

This pilot program is an exciting development. Intel WiMax and other third- and fourth-generation wireless network technologies will provide broadband speed and easy connection across wide areas. Some pre-WiMax networks have already been deployed over multicounty areas to support specific functions in the area of homeland security.

The use of such a metropolitan-area network will solve the so-called last-mile problem for connection to the house, and in fact could solve the last-yard problem for connection to the device. Many of the target households for such healthcare devices are not broadband equipped. They would probably benefit from a device being as easy to connect to the network as a cell phone. The challenge, of course, will be for manufacturers to design and build those devices.

Forward-thinking device manufacturers are looking at broadband capability as a way for physicians to reach out to patients via a sort of teleconference. Equipping devices with this capability would provide the healthcare professional with a remote overview of the patient’s state and his or her general demeanor. Perhaps the doctor could also examine wounds, bandage applications, and so forth. At the same time, the patient would have, to some degree, the psychological reinforcement that comes from the bedside manner, as it were, of the healthcare provider.

These functional requirements demand much of the design of the medical device. Not only must it establish a network connection like a leading-edge cell phone, but it must do so within the power budget and design constraints of various applicable medical device regulations. Finally, the design must be consistent with the documentation and test standards for medical devices.

The HIPAA Factor

Regulations based on the Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandate confidential transfer of patient information.9 To date, proper applications of commercial Wi-Fi protocols have satisfied this requirement. But prevailing rules may soon mandate moving past the IEEE 802.11i and 802.11x security package (an overlay to 802.11a/b/g). The logical next step would be to move to FIPS-140 Revision 2, maintained by the National Institute of Standards and Technology, which defines a series of robust encryption, identification, and authentication techniques. This basket of technologies is sometimes referred to as Suite B.10 These techniques are, in general, network-independent, and they could essentially span Wi-Fi and other networks as well.

At such time as Suite B fulfills its expectation, medical device design will come to the edge of the envelope of available silicon technology. The various Suite B cryptography protocols and key-exchange protocols are much more computation intensive than those in current use; they may require special-purpose chips, which will need to be integrated with the operating system’s cryptography application programming interface. If the data acquired via teleconference also are mandated to have enhanced cryptographic security, the computational load might be heavy indeed.

These technologies are all now available, have been proven in Department of Defense systems, are declassified for civilian use, are, depending on the end use, royalty-free or reasonably priced, and can be applied in any OEM device design. Development and product costs are inside the envelope established for medical devices, so perhaps the shift to more-secure data handling will be made by OEMs looking for a first-mover or regulatory advantage.

Reliability Issues

From the designer’s point of view, it may seem that the Hippocratic pledge to do no harm governs 90% of medical device design. The other 10% would involve documenting compliance with respect to that 90%. Device safety considerations typically focus on power-supply design, software design, and failure mode and effects analysis (FMEA).

Power-supply safety is for the most part regulated by IEC 60601-1.11 Designing to this specification provides, among other things, good assurance that high or unsafe voltage will never reach the patient. IEC 60601 additionally spells out proper device performance in the face of power interruptions and surge wave interference. The guidelines for radio-frequency emissions and immunity also can be found inside this standard, along with other related IEC standards. The net effect of these regulations is to increase significantly the size and cost of the power-supply elements in a device.

Device cost and size are both reduced if less power is consumed. A good way to minimize size and cost is to incorporate power-thrifty RISC (reduced-instruction-set computing) processors into the device design.

Software reliability also is an area of concern. Quickly evolving regulations include rules for the software in Class I, II, and III medical devices, with Class III devices being the most critical as they provide life-sustaining services. Class III devices are subject to an extensive premarket approval process.

Figure 2. (click to enlarge) Process for hazard mitigation. Source: “Off-the-Shelf Software Use in Medical Devices” (Rockville, MD: Food and Drug Administration, Center for Devices and Radiological Health, Office of Device Evaluation, September 9, 1999); available online at www.fda.gov/cdrh/ode/
guidance/585.html
.

The design of complex devices may encompass split functionality. Although certain more-critical tasks are performed by 100% hardware subsystems, other functions are handled by low-level assembly-coded microcontrollers. Finally, some higher-level functions, such as the operator interface and network communications, are managed by a full-function commercial off-the-shelf (COTS) operating system—for example, Microsoft Windows CE or Linux. Use of COTS is possible for most medical devices, provided hazards are mitigated via an FDA-regulated process (see Figure 2).

Table I. (click to enlarge) Portion of an FMEA summary report for an actual single-board PDA-style computer used in a medical application. The complete document is 33 pages long.

Although design details might change, the important thing to remember here is that, once the software is approved, changes to it are generally not allowed. If they are allowed, they must be carefully documented. Since the RISC central processing units (cpus) under consideration for many of these programs change often, this mandates a specially controlled bill of materials and excellent supplier relationships.

Reliability is not just a mean-time-before-failure calculation. The performance of the device should be analyzed for each conceivable specific failure, and the failures ranked by probability and consequence. This is FMEA, which is itself a regulated process. Detailing each failure mode, its causes, its effects, the frequency of its occurrence, the severity of the failure, and the actions necessary to mitigate its effects, this analysis can be performed on individual components or on the medical device’s embedded computer as a unitized subsystem (see Table I). The component analysis then becomes an element of the FMEA for the full device. (Eventually, an FMEA process is adapted to analyze the entire health-management process in a care facility.)

By regulation, the design must be documented, and any change to the bill of materials may be a regulatory event. This can make use of COTS devices problematic, as they often change when component suppliers alter prices or end the market life of items. The medical device OEM must update the device master record in accordance with the regulation.12

Sensor Integration and Signal Analysis

Medical device design is often centered on the integration of some novel sensor and the application of the data it acquires. Ultimately, this requires the measurement of a voltage, which commonly must be taken at high frequency to enable spectrum analysis. Although these requirements are usual for almost any measurement device, the design of these sensor electronics within the general electrical requirements for medical devices can demand specialized techniques.

To achieve objectives with a small device suggests a considered design in which the sensor electronics and computer electronics are balanced carefully. Modern cell phones and PDAs have excellent signal analysis capability owing to their built-in digital signal processors (DSPs) and DSP-like general cpu instructions. These features, developed by silicon suppliers at great cost to support telecommunication functions, can be applied by medical device designers to solve signal analysis and signal processing challenges for medical sensors. For example, very-high-resolution analog-to-digital convertors can be useful—in fact, necessary—for resolving the tiny signals at ECG electrodes from the potentially high common-mode voltage exclusion mandated by patient isolation. This must be done within the regulatory parameters for medical devices.

Getting to Core Value

As exciting as the new size, power, and communication options for medical electronic devices may be, they are all essentially commodity specifications. The real core value of a medical device resides in its sensors and proper application of those sensors within established guidelines.

This is not to say the difficulty in meeting various communication and power-supply design specifications is any less. That task can be difficult and require experienced engineers, test facilities, and so forth. Any one of these subsystems can take man-months to engineer and to test to compliance. But in the end, all of these specifications—802.11, IEC 60601-1, 21 CFR 820 compliance, and so on—are simple commodities, for the most part tested to establish their commodity nature by third-party laboratories. The dichotomy between the core value of a medical device and the effort required to commodify elements of its design is causing companies to reconsider their engineering and development models.

In the past, the controls on medical device manufacturing meant that most device companies kept engineering, design, and production in-house. Now, however, with the demand for including in products more of these low-power and communication-oriented commodity features, the same firms are looking at design and build models that involve shared responsibility. They are not completely outsourcing or private-labeling their devices, but these companies are seeking business models wherein the commodity portion of the device can be released turnkey to a supplier who can build it to specification and manage the supply chain.

Conclusion

Medical device design is advancing on two fronts. New proprietary technology encompassing better sensors, finer measurements, and improved analytical techniques is coming to market. And emerging commodity specifications for connectability and portability are allowing these devices to better integrate with a broader healthcare network. Getting the best devices to market in the future will require the establishment of new partnerships and the development of new supply chains.


References

1. Code of Federal Regulations, 47 CFR 15.90.

2. Federal Communications Commission, ET Docket No. 95-177, October 20, 1997; available from Internet: www.fcc.gov/Bureaus/Engineering_Technology/Orders/1997/fcc97379.txt.

3. IEEE 802.11, “IEEE Standard for Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11: Wireless Local-Area Network (LAN) Medium-Access Control (MAC) and Physical Layer (PHY) Specifications; Amendment 7:2004” (Piscataway, NJ: Institute of Electrical and Electronics Engineers, 2004).

4. “Draft Guidance for Industry and Food and Drug Administration Staff. Radio-Frequency Wireless Technology in Medical Devices,” Federal Register, 72 FR:137, January 3, 2007.

5. Cisco Systems Inc., “Cisco Compatible Extensions Program for Wireless LAN (WLAN) Client Devices” (San Jose: Cisco Systems [cited 5 March 2007]); available from Internet: www.cisco.com/web/partners/pr46/pr147/partners_pgm_concept_home.html.

6. Federal Communications Commission, “Amendment of Parts 2 and 95 of the Commission’s Rules to Establish a Medical Implant Communications Service in the 402–405 MHz Band,” Report and Order, WT Docket No. 99-66, 14 FCC Rcd 21040 (1999), corrected by Errata, 15 FCC Rcd 12387 (2000) (MICS Report and Order).

7. Code of Federal Regulations, 47 CFR 95.601–673, Subpart E.

8. Federal Communications Commission, “FCC Adopts Pilot Program under Rural Health Care Mechanism” [press release], (Washington, DC: FCC, September 26, 2006); available from Internet: http://hraunfoss.fcc.gov/edocs_public/attachmatch/ DOC-267605A1.pdf.

9. Code of Federal Regulations, 45 CFR Parts 160 and 164, as amended May 31, 2002; August 14, 2002; February 20, 2003; and April 17, 2003.

10. FIPS-140, Revision 2, “Security Requirements for Cryptography Modules” (Gaithersburg, MD: National Institute of Standards and Technology, Computer Security Div., 2002).

11. IEC 60601-1:2004, “Medical Electrical Equipment—Part 1: General Requirements for Safety” (Geneva: International Electrotechnical Commission, 2004).

12. Code of Federal Regulations, 21 CFR 820.181.

Lawrence Ricci is director of business development at Applied Data Systems ( Columbia , MD ). He can be contacted at lricci@applieddata.net.

Copyright ©2007 Medical Electronics Manufacturing