Interfacing Medical Devices to the Mobile Network, Part Two
With the use of mobility technology for remote monitoring, gray areas and unknown variables are being introduced into the medical device ecosystem. Until now, the industry has worked under relatively known scenarios where evaluation and documentation of issues affecting safety, efficacy and security are more or less contained within the physician/patient/device ecosystem. The emerging connected scenario of using an extended system of communicator devices, mobile networks, and multiple data access and evaluation points could impact safety, efficacy and security.
Elements of the Solution: Device/Communicator
The medical devices and communicators that will be used in the home and mobile environments will vary significantly according to the type of patient and the medical condition being monitored and treated.
The solution could be a Class II standalone device—a handheld glucose meter, for example, that allows the patient to take immediate action, such as administering an insulin treatment. Then the data is uploaded directly to a third-party diabetes management service via a 2G/3G connection for longer-term monitoring of trends such as HbA1c data. The solution also could be a cardiovascular implant combined with a network of monitoring devices, such as blood pressure and cholesterol monitors, and a weight scale. These devices connect wirelessly to a portable communicator that sends data via the mobile network daily or weekly to a remote server for a physician to take action if the patient’s parameters are out of range.
The mobile device might operate autonomously without the patient initiating the task or interacting with the communicator device. The solution also could be a bedside electrocardiograph machine evaluating heart rate remotely or possibly providing analysis and alarms to warn a patient and remote clinician of a possible dangerous condition. Still another solution might be an implanted device that communicates to a desktop or handheld device and provides early detection of a possible epileptic seizure to both the patient and
a caregiver.
In some cases, the communicator function is combined with a controller function for programming or monitoring the implant or on-body device. Devices currently on the market include on-body continuous glucose meters and disposable insulin pumps in patch form—these factors are controlled wirelessly via a proprietary handheld remote control. It is anticipated that these controllers soon will be able to interface directly to the mobile 2G/3G network to send data to a disease management service. In each of these applications, the device communicator will be an integral part of the Class II or Class III
medically regulated system.
Some experts believe that the best long-term solution for connecting medical devices to the mobile network will be to implement the wide area network (WAN) connection directly on the front-end patient interface device (i.e., sensor, implant, scale, meter). This will eliminate the need to have multiple devices talk to each other via a short-range body area network. However, this solution is estimated to be many years away due to technical issues including the size and power requirements and frequency of operation of the WAN
solution, especially if the device is located inside the human body.
Solutions today currently use a low-power, short-range wireless connection, such as Bluetooth, near field communication, or a proprietary protocol from the front-end patient interface device to a handheld or desktop communicator device. In turn, the communicator device will send the data collected from the front-end device to a remote service via plain old telephone service or via the mobile network. Today, the majority of medical device companies develop custom, proprietary communicator/controller devices, although many tech-savvy patients who own a smart phone or tablet would prefer to be able to manage their medical condition via their own mobile devices.
Using Existing Consumer Devices in the Medical System
There are many challenges associated with using existing consumer devices such as smart phones as part of a Class II or Class III medical device solution.
First, hardware can introduce unknowns and risks. Some consumer mobile devices have not been designed to comply with the more robust requirements of International Electrotechnical Commission (IEC) 60601, and more specifically, with 60601-1-11, which documents the requirements for certification of medical electrical equipment and systems used in home care applications. In addition, devices developed for a non-medical application may lack proper regulatory compliance including documentation, verification, and validation that are critical within a medical device system.
Battery life may be an issue when using an existing device for critical medical functions. A smart phone, being a multi-function device performing voice, texting, gaming, GPS mapping and many other applications, might be allowed to dip below the required battery capacity to perform the medical function. Most consumer phones do not have the ability to warn the user via algorithms and sensors or do not automatically turn off all extraneous functions if capacity limits for carrying out critical medical tasks are reached.
Another potential hardware hazard is the fact that consumer mobile devices employ cutting-edge technology on most new models to push the innovation envelope and cool factor, which in a medical device could cause unknown reliability risks. Medical device companies are extremely careful in integrating new and possibly unproven technologies that might affect the device risk profile and thus the potential patient outcomes.
Security concerns regarding software can be a major issue. Software that is required to accurately ensure correct review of records as well as proper recording of comments or changes into an electronic record must be validated. All software needs to comply with Code of Federal Regulation Title 21 (Part 11), which covers electronic records and the associated need for electronic signature controls including passwords and audit trails. Normal e-mail functions might not have the controls and security in place to allow usage for official electronic records.
Documented methodologies for upgrading and downloading software or firmware would have to be established and controlled. Additionally, there are significant inconsistencies across different phone models on the market even when simply loading a software client. One software expert has suggested hiring a third party to assist in the development of “a single binary” that works across all devices and using an installer file that recognizes the device and installs the proper and relevant files onto the device.
The next issue in using existing mobile devices in a Class II and III system is the differing business models between consumer device companies and medical device companies. How will major mobile phone OEMs internally support lower-volume, higher-liability medical device development on their phone platforms? In addition, the lifecycle of a mobile device is a very short 12-18 months, while it can take that long just to run clinical trials and gain U.S. Food and Drug Administration (FDA) approval for a medical device. The entire value chain for a consumer mobile device is set up to support fast-moving technology, new phone models, and quickly changing consumer preferences.
In order to support a longer lifecycle medical application with an existing mobile device, there will be many issues to be worked out with warranty and inventory support across all of the components in the system.
Custom Development of the Communicator Device
Another option for certain patient populations and conditions is for the medical device OEM to develop a custom or semi-custom device to perform the wireless communication functions. The medical device OEM will have much better control over the potential hazards when using an existing mobile device. Some of the issues and challenges will still be present even when the OEM develops and interfaces its own proprietary device on the global mobile network. The cost of developing a proprietary device will be significantly greater than using an existing device. OEMs can mitigate this cost by using a third-party developer with experience in designing with existing platforms. Using a third-party design and manufacturing partner also will make it easier to keep up-to-date on the vast number of proven technologies being used on mobile devices, from displays and touch screens to wireless functionality and antenna technology to battery charging technology and even visually decorative materials.
Another reason to consider using a third-party developer is familiarity with the various issues around Internet Protocol (IP) indemnification and licensing with 3G technology, as well as managing relationships with partners that can help with configuration and validation of the device on various global networks.
Next, the decision to include voice functionality on the device will require more stringent Federal Communications Commission certifications and support for required functions, including 911, so many OEMs may opt to launch a data-only device. In addition, with both an existing device or a custom device, the issue we discussed in managing lifecycle, warranty, inventory support, and end-of-life will be ever-present in the longer life of a medical device that uses technology and components aimed originally at high-volume
consumer markets.
Finally, whether the mobile network communicator is an existing device or a custom device, it must share data with the front-end patient interface device, such as the implant, glucose sensor, or neurological detection or stimulation device. Selecting the appropriate short-range wireless connectivity, whether it is 802.11, MICS, ISM, Bluetooth, Zigbee or any other proprietary band, must be well thought out, and the technology must be tested and documented for your specific application. Performance and hazard analysis with respect to issues such as interference, coexistence, antenna placement, use environments, interoperability, power, distance and overall performance must be performed. The Continua Health Alliance is an industry coalition that is helping to define guidelines and certifications for interoperability of mobile health solutions. A market opportunity definitely exists for an independent test lab to provide resources for OEMs to evaluate and test their mobile medical devices in simulated and actual home and mobile environments.
With so many issues to consider, many medical device companies are turning to contract design and manufacturing partners to implement the wireless communicator portions of their medical device system. Global contract manufacturers with experience in both medical and consumer devices can help accelerate the learning curve by taking advantage of years of wireless development; leveraging a solid, dependable supply base and technology partnerships; and using lifecycle management tools that will help mitigate the chasm between medical and consumer business models.
The fundamental issue is and always will be focused on the intended use and labeling of the device. What function does the existing mobile device perform as part of the medical system? Is it in the critical path? If the mobile function went away, would the device still operate to its intended use? Is the device simply storing and forwarding data to a clinician? How is the device presenting data and interacting with the patient? Is the device displaying a reading or providing a graph of trends for the patient? Is the deviceproviding data for the patient to make a diagnosis or decision in their own treatment? Is the device actually diagnosing, providing warnings or alerts, or even taking action on treatments? It all goes back to clearly documenting intended use.
An industry expert I recently spoke with about this subject suggested it would be worthwhile to reread the ISO 13485 standard with a view toward the entire, extended system versus a standalone device perspective. Whether you use an existing mobile device or a custom device as your communicator function, it is part of the entire medical device system and must be treated as a vital part of the Class II or III regulated system.
On that note, the U.S. Food and Drug Administration (FDA) recently announced that it would allow physicians to view medical images on the iPhone and iPad manufactured by Apple. According to an FDA press release dated Feb. 4, “The application is the first cleared by the FDA for viewing images and making medical diagnoses based on computed tomography, magnetic resonance imaging, and nuclear medicine technology, such as positron emission tomography. It is not intended to replace full workstations and is indicated for use only when there is no access to a workstation.”
Results from demonstration studies with qualified radiologists under different lighting conditions were performed and all participants agreed that the devices were sufficient for diagnostic image interpretation under the recommended lighting conditions. Again, it all goes back to clearly understanding, evaluating and documenting intended use.
Editor’s note: This is the second installment in a series of three articles aimed at examining the issues and challenges that the medicaldevice industry faces in using the mobile
network as part of the healthcare monitoring system. The first column introduced the growing trend. The third installment will examine the remaining issues introduced by the mobile network and data management/security.
Donna Fedor has been the director of strategy for Jabil’s Healthcare & Life Sciences sector since 2009. She is responsible for developing unique strategies to build deeper knowledge and expertise in the global healthcare industry, specific conditions and disease states, and medical products and technologies. Fedor holds a bachelor’s degree in electrical engineering from Boston University.