The rapidly growing interest of industry in home and remote patient monitoring has led to a mindset of getting medical devices connected and making medical data accessible. Medical devices have advanced from being unconnected, to wired, to wireless.
Today's wireless1 has multiple connotations: short range such as BluetoothTM, ZigbeeTM, ANT+TM, Wireless Fidelity (Wi-FiTM), or cellular Wireless Wide-Area Network (WWAN). This is a convergence play between the realms of medical devices, healthcare, and wireless.
The versatility afforded by wireless technology adds a direct promise of value, known as value proposition, to medical devices; with near instantaneous access to biometric healthcare data2 (distinct from physical biometric data) that can potentially translate into revenue generation for information and managed healthcare services.
However, in order to achieve this, there are a number of technical, business, legal, and regulatory challenges that need to be met. For Qualcomm Life, Inc.,3 a wholly-owned subsidiary of Qualcomm Incorporated, the enabling of device-to-cloud connectivity solutions has become a need to be fulfilled at the industry level. This article aims to give an overview of the process of creating and using some mHealth solutions.
Several challenges were dealt with in order to launch Qualcomm's 2netTM wireless hub and mHealth cloud service platform.
Enabling medical devices to work with multiple radio technologies and software
Determining the optimum cellular carrier and cellular technology
Managing lengthy product life cycles in healthcare vs. short product life cycles in wireless, while designing for regulatory compliance and process
Harnessing the cloud
Realizing the user experience
1. Enabling Medical Devices to Work With Multiple Radio Technologies And Software
The last decade has seen a rapid growth and adoption of mobile computing devices such as smartphones and tablets, which are very noticeable in the healthcare industry. Healthcare providers, clinicians, and medical device manufacturers are trying to find new and innovative ways to use these powerful platforms to improve the quality of patient care and to lower healthcare costs.
A major area where this is directly impacting the patient consumer is remote health monitoring (RHM). The Continua Health Alliance4 defines RHM as a technology that facilitates the monitoring, evaluation, and management of an individual patient through a remote interface that collects clinical data from the patient, such as vital signs and blood pressure, and then transmits the data to a remote healthcare provider for clinical review, care management, and patient education.
Recent research indicates that in-home, remote-monitoring health systems will grow to meet 44% of the overall patient monitoring system demand, reaching a total cost of $14.9 billion by 2014. Hospital patient monitoring system demand is projected to reach 33%, and outpatient facilities 13% of the whole by 2014. It is estimated that in 2014, approximately 81.3 million wireless health devices will supply the United States alone.5
Several factors make this trend for RHM all the more interesting:
It helps to avoid unnecessary hospital readmissions and is therefore in accordance with the Affordable Care Act of 2010, a legislation and healthcare reform which claims that a patient's readmission to hospital within 30 days of being released results in doctors and institutions not getting reimbursed— thus saving money for insurance companies and healthcare providers.
Wireless technologies allow various RHM possibilities.
It helps alleviate a shortage of healthcare professionals among the health insured population, a major problem in the U.S.
The catalyst is the enabling paradigm shift to wireless that surrounds us and permeates our modern lives. Combining wireless and healthcare in the rapidly accelerating wireless healthcare industry is radically changing the way a patient consumer's healthcare is managed.
Figure 1 illustrates a typical use-case scenario for RHM: A patient consumer uses a wireless-assisted medical device to take a reading. The data is then sent to an mHealth gateway device, which then in turn wirelessly sends it over the cellular network to the healthcare provider.
The mHealth Gateway—Converging Medical Devices and Wireless
According to the West Wireless Health Institute (WWHI) glossary,2 mHealth is defined as the delivery of healthcare services through mobile communication devices such as cellphones. Another extrapolation of wireless health is the use of wireless technologies for personal health management and healthcare delivery.
Putting these two definitions together, we see that healthcare is enhanced by powerful gateways such as smartphones, tablets, hubs, and embedded devices allowing for biometric healthcare data2 to be collected by a sensor and run through an algorithm or data mining program, which can then be monitored by a clinician for diagnostic and/or therapeutic purposes.
Given that users will be familiar with smartphones and tablets, in this section we will focus on the hub, which is a device that acts as a gateway, providing wireless connectivity between one or more medical devices and the Internet. In the mHealth space, the hub improves RHM by wirelessly connecting medical devices without cellular capabilities for an already existing large market of devices without wireless capabilities.
The catalyst is the enabling paradigm shift to wireless that surrounds us and permeates our modern lives.
Hub Features
The key efficiency enhancer in the device-to-cloud mHealth solution is the hub device, which can be used in a home or office setting. Figure 2 shows archetypal features of a universal hub, illustrating the broad cross-section of spheres involved.
Challenges in Universal Hub Development
End-to-End Standardization
A key common feature of the hub is its ability to communicate with multiple devices, such as glucose meters, blood-pressure monitors, and pulse-oximeters, in some concurrent fashion. To add to this complexity, these devices may use the same short-range radio (e.g., Bluetooth), or different short-range radios (e.g., Bluetooth, ANT+, Zigbee).
A key common feature of the hub is its ability to communicate with multiple devices, such as glucose meters, blood-pressure monitors, and pulse-oximeters, in some concurrent fashion.
Security is important, and the hub should not communicate with any other device until it is authorized to do so by the platform so as to ensure data is protected. Initial meetings during the development process with several medical device companies evidenced a wide gap in competencies between the cellphone centric experts and medical device experts for hub-to-medical- device interaction.
There are several possible reasons for this:
The legacy nature of several medical devices that were initially unconnected, and then migrated to wired (e.g. plain old telephone service, or POTS, and serial connectivity), and finally to wireless (e.g. Wi-Fi in enterprises and hospitals, and Bluetooth in medical devices for the home).
Difference in technological cycles for the industries—medical devices have a longer life cycle (approximately five to ten years), versus wireless devices (one to two years).
At times, gating regulatory constraints.
Initial meetings during the development process with several medical device companies evidenced a wide gap in competencies between the cellphone centric experts and medical device experts for hub-to-medical-device interaction.
This results in customized work that needs to be undertaken so as to integrate the devices with the hub.
Hub Software
Given the multiple functions a hub has to fulfill, including its “universal” support for multiple radios, among other requirements, hub software needs to coordinate numerous hardware components, communicate with various devices, coordinate with the carrier's network, perform administrative tasks, and manage memory and data.
As a result, the selection of the hub's operating system is important so as to be able to manage and provide the necessary functionality. This may vary in range from a very low-level embedded model, such as Linux or Windows CE, to the latest full-featured version of a mobile operating system such as AndroidTM.
Software upgrade/update capabilities are a key factor and an essential feature for devices that are out in the field (e.g. hubs plugged in various homes). Usually, Over-the-Air (OTA) software download capabilities will be automatically managed by the cloud platform. OTA is a standard approach used in the wireless transmission and reception of application-related information.
2. Choosing an Optimum Cellular Carrier and Technology
In the United States and other countries, the cellular network carriers provide communication between hub/gateway-type devices and the cloud platform. Some examples of cellular carriers are AT&T, Verizon, Telus, Orange, and Vodafone. Some key considerations for selecting a single technology/carrier are:
Enables target launch geo-market(s) and cellular technologies
Wider availability and lower cost of the wireless module
Increased coverage
Flexibility and availability of data plan costs
The selection of target geo-markets is tightly linked with the selection of the wireless module. Wireless cellular module manufacturers have defined their product offerings to obtain the lowest cost by grouping the supported bands into combinations to suit different markets. The cellular technologies covering the world today are second generation (2G), third generation (3G), and fourth generation (4G).6
Ultimately, to run a service offering, there must be a competitive data plan that is affordable on a recurring basis (e.g. monthly or yearly), for which a customer is willing to pay.
3. Managing Product Life Cycle Duration And Designing for Compliance
Product development cycles in healthcare are regulated by lengthy test and certification cycles, while continuous innovation and the obsolescence it brings about drives short product cycles that react to the wireless consumer product market. These different development cycles and associated device life cycles also lead to different choices in component selection and business models, which need to be considered when choosing wireless implementation.
Product certification and testing are an integral part of any product development process. There are technical and regulatory challenges (designing for compliance) in getting medical devices assisted by wireless technology. For the medical and wireless fronts, the common areas of certification can be broadly classified into regulatory, industry, and carrier categories, each with further sub-classifications.
Product certification is also important for a carrier's managers, who want to see that the device performs within anticipated bounds and parameters, and does not cause any network issues. If the product is to be used globally, it would need to be certified by carriers on a global basis.
Certification requirements vary by carrier, but there is a marked preference for products that incorporate a pre-certified wireless module that saves time, effort, and cost. Early development and carrier discussions are key factors in wireless aspects such as antenna placement and performance.7
Product development cycles in healthcare are regulated by lengthy test and certification cycles, while continuous innovation and the obsolescence it brings about drives short product cycles that react to the wireless consumer product market.
A major focus area in designing new healthcare products and services is Food and Drug Administration (FDA) classification and associated certification. For hub gateway devices, the FDA Medical Device Data Systems (MDDS) classification8 is of key interest. As gateway devices are usually combined with another FDA-listed medical device, a company jointly packaging the products may need to demonstrate that proper quality processes were used in the development of each component of the system.
For example, the ISO 13485 standard9 2003 represents the requirements of a comprehensive management system for the design and manufacture of medical devices, and needs to be followed at the onset of the project to demonstrate proper compliance.
The cloud platform is designed to interoperate with different medical devices and applications, effecting end-to-end wireless connectivity while allowing providers and their systems access to the data.
Certifications also vary depending on the country or region of operation of the device. For example, the Federal Communications Commission's (FCC)10 equivalent is the European Union (EU) regulatory body for radio equipment, which has its own Product Safety Conformité Européenne (CE) regulation, as well as additional bodies such as Restriction of Hazardous Substances (RoHS),11 and Waste Electrical and Electronic Equipment (WEEE)12 for appropriate disposal of the product.
Similarly, the FDA Quality System Regulations (QSRs) are equivalent to the EU Medical Device Directives (MDD).13 A proper quality process needs to be adhered to throughout product development.
4. Harnessing the Cloud
Cloud platforms encompass servers/infrastructure, databases/repositories, information technology (IT), and other services, systems, environments, tools, security, privacy, and capabilities. The cloud platform is designed to interoperate with different medical devices, mHealth gateways, and applications, effecting end-to-end wireless connectivity while allowing providers and their systems access to the data.
Platform Capabilities
Some of the broad capabilities the platform is intended to provide are:
Managed services for mHealth gateways
Two-way communication
Secure private cellular link to the cloud
Managing the wireless access
Secure data centers, such as compliance with payment card industry (PCI)
Security and privacy controls on transfer and storage safeguards of medical device data
Device management, including activation and provisioning
OTA software updates
Active network monitoring
Tiers two and three customer support
Traffic overage management and carrier billing reconciliation
Web-services application interfaces for gateway management.
End-to-End and Quality of Service
For any mHealth system, end-to-end (E2E) communication refers to information relay from the medical device to the customer/partner's cloud or servers. Quality of service (QoS) is important whenever something has to be acted upon within a specific time frame in a reliable fashion.
An example is the safe delivery of data collected from the device to the customer's cloud/servers, bound by certain time-to-deliver requirements, which can vary from a few seconds to a few minutes, or even hours or days for longer term trending data. The complexity grows when you factor in multiple devices that communicate simultaneously. This needs to be managed between the mHealth gateway and the cloud within the cellular bandwidth.
Data Traffic Management
For common wirelessly assisted medical devices such as glucose meters and weight scales, a biometric reading is in the order of a few bytes to a few kilobytes (kb). While such bandwidths are not an issue on the carrier's cellular data plan, other factors can drive up data bandwidth and traffic usage. Examples include chatty devices, devices that transmit new readings as well as historical ones, and end users who take readings multiple times a day to secure transport overhead.
Data traffic modeling should be carried out during the initial system development, not only for traffic over the carrier's network, but also for data that reaches the platform, is stored in databases, or is outbound, for example. The latter items directly impact the server's infrastructure selection criteria.
5. Realizing the User Experience
In an RHM solution, the user's interactions are primarily with the medical device, the mHealth gateway, the provider, the website, and the dashboard or system where readings and progress can be monitored. User experience is a very subjective and qualitative challenge. Figure 3 shows the broad array of user experience aspects, a few of which are discussed in more detail below.
Manageable User Interface and Experience
Simplicity is key. A small form factor with minimal but intuitive display items makes for a good user experience. For example, the user is only interested if the gateway has good cellular connectivity (green) or not (red), and not all wireless signal strength values.
Ease of Use
The mHealth system should be simple and easy to use. Gateways such as the hub should be plug-and-play, automatically detecting and connecting to medical devices without user intervention.
Faster Access
Mobile computing devices allow fast and easy access to data, resulting in better patient care. When a clinician can gain access to laboratory results while quickly viewing results on his or her mobile computing device, and then react and advise other providers based on those results, the impact of mobility on patient care can be easily seen. As clinicians becoming less dependent on desktops and laptops, they will be more able to provide patient care in any environment.
Data traffic modeling should be carried out during the initial system development, not only for traffic over the carrier's network, but also for data that reaches the platform, is stored in databases, or is outbound, for example.
Gateway Connectivity Options
Based on the various mHealth gateway options, Figure 4 shows three options to connect to the Internet, and Table 1 discusses the advantages and disadvantages of each approach.
Security and Privacy
Security of the system and privacy of patient data are of utmost importance and value to the patient consumer. Some key examples to ensure privacy and security, which may impact patient safety, are:
Encryption, such as Advanced Encryption System (AES),14 of medical-device reading data received on the hub from the medical device.
Secure transport on a private carrier's network using hypertext Transfer Protocol Secure (https), or Secure Sockets Layer (SSL).15
Once the patient data is received by the cloud platform, it will typically be housed in data centers on servers. The data centers should have, at a minimum, high availability (HA) replication of systems, HIPAA16 Security Rule Compliance Checklist requirements for health information privacy, and data backup capabilities.
Secure delivery of data from the cloud platform to the customer's/partner's systems using https or SSL.
Quality assurance and verification to ensure data integrity throughout.
Conclusion
This article briefly summarizes the process, some pitfalls to avoid, and options available in bringing one wireless mHealth solution to market. The design and development of such mHealth gateway solutions, within the bounds of product development, process, and regulation across the healthcare and wireless industries, is indeed an exciting and challenging journey.