GumPack: A Personal Health Assistant with Reconfigurable Surface Components

Wearable and everyday-carry medical devices can improve quality of life for individuals that need frequent health monitoring. Such tools can supplement ubiquitous home care environments populated with medical sensors, extending the reach of these environments and increasing the freedom of their occupants. This paper presents the concept design for an everyday-carry medical device called a 'GumPack': a small cuboid-shaped device that offers wireless connectivity and plug-and-play surface components, where a component can be a biomedical sensor or a wireless network coordinator that manages a body area network. This geometrical layout optimizes access to surface-based medical hardware mounted on a small form factor. The device offers substantive computing power, supports local component reconfigurability, and promotes interoperability with medical device coordination environments. The GumPack is envisioned to be a personal health assistant carried in a pocket or handbag that can operate alone or interface to, e.g., a cell phone.


INTRODUCTION
Wearable and everyday-carry devices that integrate with healthcare information networks promise to increase the quality of care rendered to individuals that desire mobility yet require frequent or continuous health monitoring [1][2][3][4]. The maturation of interoperability standards such as IEEE 11073 -Personal Health Data (11073 PHD) [5], coupled with the proliferation of wireless communication standards, plug-and-play wired technologies, small medical sensors, and low-power computation and visualization tools (that are in large part driven by the smart phone industry), offers promise for the creation of small, effective portable medical devices that can be customized to meet the needs of the individual user. Sensor-laden devices that a) offer the connectivity of a cell phone (or interface with a cell phone) and b) are small enough to attach to a keychain or be carried in a purse like lipstick, an inhaler, or a pocket knife, are especially attractive, as such items would be culturally acceptable, inconspicuous, and minimize the effects of the medical monitoring process on day-to-day existence.
Personal health assistants (PHAs) as physical device embodiments will move the medical device arena forward since they will 1) serve as hubs for on-board or nearby miniaturized medical components, 2) maintain local health data records, such as personal health records (PHRs), and 3) support a variety of health-related utilities/apps. PHRs will hold raw data received directly from medical devices as well as a diverse range of data related to wellness tracking, ailment history, allergies, and immunization records. As an example, smart phones have been pervasively integrated into daily life, and their abilities to play healthcare delivery roles make them early reflections of the PHA concept. The application of these devices (and the client devices that they support) to mobile health is already driving a significant innovation wave.
Future PHA apps will map conceptually to current smart phone apps but will address a broader collection of healthcare categories that relate to health/disease information, patient/physician communication, and PHR management. Further, these PHAs will exhibit form factors and functionality that, in many cases, will deviate significantly from the current cell phone model, where a phone serves as a connection hub for "dumb" medical devices whose role is to deliver, but not to process or to interpret, medical data. That processing and interpretation role is currently reserved for cell phone apps and the clinical platforms that receive and aggregate those data.
One concurrent trend in ambulatory medical system design is to form a wireless body area network (WBAN) with wearable sensors that connect to a data logger or receiver [6], [7]. The physical components in a WBAN normally fall into two categories depending on their roles in the network: sensor (transmitter) and coordinator/hub/basestation (receiver). Note that in many applications, sensor nodes also receive data (e.g., commands) from coordinator nodes. This basic structure implies two fundamental roles of a WBAN: an integrated sensor collection and a health gateway (coordinator).
Various sensor configurations can constitute a WBAN. Motion sensors are used in a WBAN in [8] for computer-assisted physical rehabilitation. An 8-channel EEG system based on a WBAN is described in [9]. Two wearable sensors (a pulse oximeter and a blood pressure monitor) and a GPS module are employed in a wireless system for subjects in a disaster scene in [10]. A wireless body sensor network that provides a finger photoplethysmogram (PPG), an electrocardiogram (ECG), and a continuous, cuffless blood pressure waveform via a 3D accelerometer patch is presented in [11]. A WBAN in [12] contains two accelerometers, an ECG sensor, a blood pressure sensor, and a pulse oximeter; it detects context change and determines the state of each sensor (e.g., data rate). A smart jacket is designed for newborn infants in [13] integrating textile electrodes, a reflectance pulse oximeter wireless module, and a temperature sensor.
In these WBAN applications, the gateway's role is primarily to coordinate sensor activities and stream data to a computer for storage, analysis, and display. These data 146 GumPack: A Personal Health Assistant with Reconfigurable Surface Components could also be forwarded to an external network such as a Medical Device Coordination Framework (MDCF) [14]. In practice, the Internet would be a reasonable candidate for the 'external network.' Recently, eDevice announced the HealthGO platform which utilizes Freescale's Home Health Hub reference platform [15]. HealthGO was reported as the first fully customizable data aggregation platform in industry, supporting remote patient monitoring. Its key tasks include universal connectivity for patients/devices and data delivery for remote device management through global communication network services (e.g., cellular and Ethernet). A similar technology from Qualcomm Life -2net platform -provides a wireless health network that connects medical devices and a cloud-based system through a 2net Hub [16]. While current phone-to-sensor and WBAN topologies show promise to improve the quality of personalized care, this arena can benefit from a continued move toward wearable and everyday-carry device collections that are even more capable and "collectively" intelligent: ad-hoc device groupings that display greater flexibility and ubiquity in mobile patient care environments. Resources should be sensibly focused on natively-designed, secure PHAs that can operate (i.e., acquire and process data) either in a stand-alone mode or as part of a local collection of similar, highly capable devices that interface to cell phones and other nearby hubs only when needed.
This paper addresses a medical data collection, processing, and communication platform that can help to move this PHA design space forward. The platform, referred to as a "GumPack," can fulfill sensing and gateway roles embodied in current cellphone and WBAN systems while at the same time offering on-board computation similar to what can be found in processing apps on high-end smart phones and computers attached to external networks. The following sections provide an overview of this platform, an initial set of medical devices that demonstrate its utility, and some representative calculations that illustrate the effectiveness of its on-board data analysis tools.

TECHNOLOGY OVERVIEW 2.1. GumPack Layout and Functionality
A GumPack is a new type of everyday-carry, multi-sensor medical monitoring platform whose layout and functionality offer the potential to complement, and in some ways move beyond, the design space specified by mobile phones connected to dumb medical devices. This platform embodies the PHA concept and reflects characteristics of traditional medical devices, smart-phone-connected devices, WBANs, and commercial health gateways. A rectangular cuboid prototype for the platform, called a "GumPack" in reference to the Gumstix processing board used in its initial instantiation, is depicted in Figure 1. The unit incorporates snap-on medical sensors, data storage, processing capabilities, USB-rechargeable power, and multiple means for wireless connectivity to external hubs and local WBANs. As the GumPack is rotated each quarter turn, the user is presented with a different face of the cuboid, where a new device resides, resulting in an optimally compact arrangement for multiple medical devices. These surface elements can be switched out in a plug-and-play manner to match a user's specific care needs.
The everyday-carry platform is intended to serve a dedicated role as a biomedical data monitor/processor that can also be a body area network (BAN) hub to support additional wearable or nearby devices (Chiclets, described in section 3.6). It is designed to be one component that operates within a ubiquitous home infrastructure yet also offers patient mobility outside of the home. The unit will supply continuous or processed data in real time or in store-and-forward mode. On-board storage will allow a PHR to travel with the user, and advanced computation capabilities will promote onboard signal processing operations such as filtering, parameter extraction, and spectral analysis.
From a connectivity viewpoint, the base platform will offer cell phone, Wi-Fi, and lower-power wireless (e.g., Bluetooth and ZigBee) support, depending on whether it communicates with a remote system or a local BAN. USB serial communication and rechargeability are important features, as is Web interface support, which will allow nearby devices such as smartphones and tablets to view these sensor data, e.g., when a display component is absent on the GumPack.
At present, the GumPack does not provide a visual cell-phone-like user interface (e.g., touchscreen). However, a user can alternatively utilize a phone, a tablet, an Internet-enabled TV, or any device that supports Wi-Fi and Web browsing as an indirect access interface. While the data depicted on the iPad interface in Figure 1 are real measurement results collected from the GumPack and a network of Chiclet sub-sensors, they currently do not update in real time, and the graphical interface itself is not needed for device operation. This demonstrative GumPack Web interface also provides early implementations of a health & wellness tracker, a device configuration panel, and file checkout using a registered GumPack account.

148
GumPack: A Personal Health Assistant with Reconfigurable Surface Components

Figure 1.
A prototype GumPack design and demonstrative Web interface (closest surface: single-lead electrocardiograph).
Note that this design's resource collection makes it a sensible base platform for algorithms that address context/situation awareness, physiological models that assess patient health given multi-sensory inputs, intelligent agents, and on-board analyses for local decision making (including the ability to maximize battery life through onboard processing, minimizing the need for telemetry). Role-based operation and device-level security (e.g., user identification, device authentication, and secure data access) are also sensible targets for this design, which seeks to optimize the low-power versus highperformance tradeoff relevant to all mobile embedded systems.

Advantages of the Current Approach
Advantages of the current approach are substantive compared with approaches that seek to solely employ smart phones connected to relatively incapable devices. A smart phone is not natively designed to be a professional platform for medical applications. The physical interface to a phone is limited by its wired/wireless connections, each of which adds an additional communication layer and requires extra electronic parts, affecting the device cost, power consumption, and form factor. Further, standardization at the hardware level can be difficult because manufacturers define different interfaces for each embedded element. This inaccessibility to embedded hardware resources within a smart phone further extends to its firmware, whose development is constrained to the software development kits (SDKs) provided by the respective manufacturers. In aggregate, a phone-based platform and its supporting development kit are far from an open embedded environment that can provide the freedom to design an optimized consumer medical device. Moreover, the integration of a reliable and efficient information framework, within the context of current operating systems, that facilitates device reconfigurability and interoperability will be impossible without strong technical support from phone manufacturers.
Regulation of cell-phone-to-device systems is another important issue. The rapid rollout interval of six months for new cell phone models does not synchronize well with rollout intervals for FDA-approved medical devices. Since the processing apps that would purport to run on these cell phones would also be regulated as medical device components, their performance and reliability would be difficult to verify given their quickly changing host platforms. Therefore, it is more sensible to run such processing apps on a regulated platform (e.g., a future version of a GumPack), primarily using tools like smartphones and tablets as intermediary communication devices.

Usage Scenarios
The GumPack platform, when carried in a purse, handbag, or pocket, will be a general tool that can be effective in many data monitoring and processing contexts. Broad categories include the occasional or continuous acquisition of the following: • wellness-tracking parameters like heart rate and blood oxygen saturation, • stream data -waveforms such as ECGs or PPGs from which multiple health parameters can be derived, • images or movies via a camera located on one end of the GumPack cuboid, and/or • a combination of these data, where sensing configurations may employ WBAN elements.
Sensors and actuators that interact with a GumPack unit might reside on a GumPack surface component, be worn on an individual, or be near an individual (e.g., a weight scale). Data processing operations performed on the unit would include filtering (e.g., simple smoothing, traditional band-limited filters, or more complex adaptive filters), spectral calculations (e.g., fast-Fourier transforms for filtering or time-frequency analyses), parameter extractions from time-or frequency-domain data, data aggregations/reductions prior to wireless transmission, and trend analyses.
The following paragraphs present a simple set of representative application scenarios, where features of the GumPack platform are progressively added to illustrate the flexibility of the toolset. Technical details of the physical GumPack prototype, including an early set of surface components built to demonstrate the approach, are addressed in ensuing sections. Note that the goal of this work is not to demonstrate the exclusivity of the GumPack approach relative to a cell-phone-based setup, but rather to demonstrate the flexibility that this kind of PHA adds to the mobile care toolset available to patients and providers. Further, the assumption of FDA regulation is applied to the GumPack platform and its associated surface components but not to, e.g., the cell phones, tablets, and Wi-Fi hubs with which the GumPack would interact.
Consider, for example, an individual believed to be in the early stages of congestive heart failure. He/she is asked by a physician to carry a GumPack unit and to occasionally utilize two of its snapped-on components: a single-lead ECG and a reflectance pulse oximeter. From these measurements, the GumPack processor provides a filtered ECG and determines resting heart rate, blood oxygen saturation (SpO 2 ), and respiration rate (acquired from ECG and/or PPG signal baselines). Twice a day, the user is instructed to acquire these measurements while standing on a weight scale that communicates wirelessly with the GumPack. The GumPack beeps as a reminder for the patient to acquire his/her data so as to provide some regularity to these measurements. After each session, the GumPack unit compresses and encrypts these data, then uploads a short report to the patient's remote electronic record by way of his/her cell phone or a nearby Wi-Fi hub. Trend reports are supplemented with these point data.
After a change in medication, the physician requests the same SpO 2 and weight measurements but a higher-fidelity ECG. The patient is then asked to apply the electrodes for a simple three-lead ECG and wear them for several days while the effects of the medication are quantified. This electrode set offers a low-power ZigBee wireless transmitter that communicates with a wireless surface component on the GumPack, effectively replicating the functionality of a Holter monitor but with more flexible communication options. On-board algorithms remove 60 Hz artifacts and baseline variations in these ECGs, and time/frequency analyses of these data are applied as a means to quantify changes in heart activity.
At this point, the user has been acquiring data through the GumPack platform for several weeks. After receiving an indication of an arrhythmia that had not been previously noticed, the physician's support staff set up a telemedicine consultation with the patient, where the patient uses their tablet PC and camera as the teleconsultation interface. Given instruction from a remote staff member, the patient switches out the three-lead ECG surface component on the GumPack for a six-lead surface component with connectors for wired leads. Using a placement template provided by their physician's office, the user attaches the six leads to their chest and to the GumPack, using the GumPack camera and feedback from the remote staff member to confirm correct placement. The GumPack then acquires and forwards the signals from the six precordial, unipolar chest leads to the physician in real time. These data are displayed on the patient tablet as they are transmitted. While this scenario is clearly contrived, it is intended to present a situation where the merging of GumPack capabilities (as a PHA) with current consumer technologies results in more effective care delivery. Two early data acquisition and processing examples are also illustrated in section 4.

DESIGN METHODOLOGY 3.1. Conceptual Model
The physical implementation in Figure 1 is based on the cuboid medical device model illustrated in Figure 2. It consists of 1) up to four switchable surface components (SCs) at a time, 2) four surface substrates (SSs), 3) a camera and a microphone, 4) wired connectors, and 5) a battery. Each SC/SS pair is connected by two 70-pin connectors, and interconnections also exist between the four SS/SC pairs. In the current GumPack rendering, a Gumstix Overo board [17] is a required SC that supports core computing/control, component coordination, power management, and basic communication, while the configuration of the other surface components is flexible. An SC can be one of many sensor types, such as a two-thumb electrocardiograph, an accelerometer/gyroscope-based motion sensor, or a reflectance pulse oximeter that generates PPGs. It can also be a sensor conditioning board, an expansion board, or even another Overo board. One type of expansion board -a ZigBee coordinator -can manage a local low-power, WBAN of Chiclets: small wearable or nearby low-power wireless sensors.   Figure 3(a) displays the SS prototype -the board size is 84.4 mm by 32.8 mm. A "Surface Component Place Here" region is marked on the SS in between two mounted 70-pin connectors (the receptacle). The interconnection interface region is also denoted in Figure 3(a). It consists of two rows of 44 vias: metal-lined through holes that can receive wires from nearby boards. The first row receives connections from the previous SS, and the second row offers connections to the next SS.

Surface Substrate and Interconnection Interface
A standard SS board with only the 70-pin connectors populated is used for a regular SC such as a biomedical sensor board. For an SC with a core processor, e.g., a Gumstix Overo board, a fully populated version is required as in Figure 3 (USB or battery) and supply, USB connection to other devices (e.g., a personal computer), and a GumPack reset. The interconnection interface is a subset of the 140 pins (2 × 70 pins) plus several power supply lines. Each row of 44 vias addresses these features: power supply (3.3 V, 1.8 V, and ground), general purpose input/output, 1-wire bus, I 2 C bus, serial peripheral interface bus, universal asynchronous receiver/ transmitter, pulse width modulation, and analog-to-digital converter.

Surface Components
One way to expand GumPack functionality is to add parts to an SS, such as including an HDMI controller and connector to support video streaming. However, not all users need video support. A more flexible and innovative approach is to only plug in SCs that support the functionality a user really needs. This snap-on reconfigurability is one major benefit of the GumPack design. Several existing instantiations of GumPack SCs are described below; more are under development. Note that the SCs in this paper are technology demonstrators whose purpose is to validate the GumPack idea. They are not designed to meet performance, usability, and security standards needed for clinical applications.

Processor SC
The Processor SC hosts a processor and other resources such as memory and a network interface. The processor SC is a required GumPack element, whereas the other SCs are optional and depend on patient needs. A processor SC plugged into an SS forms a minimum system. At present, this SC is an Overo board from Gumstix (see Figure 3(b)). The board utilizes a Texas Instruments OMAP3530 high-performance applications processor: a low-power processor originally designed for use with smart phones. This SC provides more signals than are defined on the 44-pin interconnection interface (e.g., camera signals), many of which are derived from the OMAP3530 processor. Future use of these signals will depend on the care scenarios supported. Other notable features of the Overo board include a Wi-Fi/Bluetooth module, which supports most GumPack wireless applications, and a Micro SD card module, which enables a fast switchover of the entire software system. Current consumption is approximately 250 mA (500 mA with Wi-Fi active). Actual power consumption will depend on the GumPack configuration and system resource usage (e.g., CPU usage, Wi-Fi active time, etc.).

Motion Sensor SC
Motion sensors are widely used in consumer electronics, since they provide useful information about device attitude and user activity. Applications based on motion sensors, especially accelerometers, include screen auto rotation, game controllers, and system auto wakeup (using an inertial interrupt function). In the biomedical domain, motion sensors can be used to monitor subjects' daily physical activity [18] or to provide a reference signal to reduce motion artifact in, e.g., ECGs [19] or PPGs [20]. In this context, the GumPack design can be viewed as both a consumer electronics platform and a collection of medical devices (sensors).
The first natively designed GumPack-ready SC is the motion sensor board in Figure 3(b). Two types of motion sensors are mounted on this SC board: one 3-axis accelerometer and two gyroscopes. The accelerometer employs an STMicroelectronics LIS33DE ultra compact, low-power (< 1 mW) three-axis linear module. It sends measured accelerations within the range of ± 8 g through the I 2 C serial interface. The gyroscopes are STMicroelectronics low-power LY510ALH (z-axis) and LPR410AL (x-, y-axis) units. Each provides angular rate data within the range of ± 100 dps (degrees per second) through an analog output, which is connected to analog-to-digital converter (DAC) pins on the processor SC. The relative x, y, and z directions are printed on the board (see the lower left corner).
A profile memory chip comes with all SCs (except for the processor SC) and plays an important role in the GumPack Component Connection Framework (GCCF) described in section 3.5. Analogous to a SIM card, this memory chip (e.g., a Microchip 24AA01 low-power (< 1 mA) EEPROM on the motion sensor SC) serves as a registry that contains the specifications of a given SC. This feature allows an SC to be immediately identified and authenticated when it is plugged into a system.

Electrocardiograph SC
An electrocardiograph (ECG) is a standard clinical device that is also useful in mobile care environments. It transduces tissue biopotential differences into millivolt-level electrical signals using differential electrode pairs, where each electrode pair yields one ECG lead. While multiple-lead configurations are often employed in a clinical context, a single lead ECG [21] can help to minimize device size and power consumption in a mobile or wearable context. An ECG SC is a single-lead ECG board natively designed for the GumPack, as in Figure 3(b) and seen earlier in Figure 1. The signal amplifier circuit utilizes a Texas Instruments INA321 instrumentation amplifier and a Texas Instruments OPA2336 operational amplifier, with current consumptions of 40 µA and 20 µA, respectively. Two electrodes are integrated into the top side of the board in the form of conductive solder pads. During the measurement, two digits (e.g., thumbs) need to be placed on the two on-board electrodes without touching other electronic parts. A single-lead ECG lacks a reference signal from a third electrode, which makes it different to manage than a regular 3-lead ECG because of the inability to differentially reject common-mode signal artifact. However, a reference signal (REF) could be output by a DAC from an Analog Devices AD5315 chip, with the particular value of REF set through an I 2 C serial interface on the processor SC. Given access to REF, digital baseline control could lead to a full digital ECG circuit without a third electrode or an analog filter. In a case like this, the signal processing capability presented by the processor SC can be important to the usefulness of the resulting data.

ZigBee Coordinator SC
A GumPack can host up to three SC-based, plug-and-play biomedical devices at a time. A ZigBee coordinator SC was designed (see Figure 3(b)) to extend a GumPack's hosting capacity for applications such as body area networks, where additional 154 GumPack: A Personal Health Assistant with Reconfigurable Surface Components low-power wireless components are desired. In this SC, a Jennic JN5139 microcontroller is used as in an earlier custom wireless pulse oximeter [22] (also refer to the Chiclets in Figure 7). The wireless link requires the most current/power consumption of all of the optional SCs, with a transmitter current draw of 38 mA and a receiver current draw of 37 mA. The CPU consumes 7.75 mA at full speed, and the current required by the peripherals (ADC, DAC, UART, Timer, etc.) is less than 1 mA in aggregate. However, when compared to the 250 mA current consumption of the Wi-Fi/Bluetooth module on the processor SC, the ZigBee coordinator SC demonstrates its low-power advantage. Table 1 concludes and compares the technical specifications of the current set of SCs.

Software Architecture
This section explores the GumPack design from a software perspective. The GumPack, through the OMAP3530 processor, can support several operating systems, including Android, Linux, and Windows CE. To accelerate software development, Angstrom, a commonly used Linux distribution for a variety of embedded devices, is employed as the software platform for the GumPack. Figure 4 shows the software architecture built upon the GumPack hardware. It is by convention divided into a kernel space and a user space.
The kernel space consists of a normal Linux system structure. A shell is a command line interpreter that is frequently used in the GumPack. It links the kernel and user space for typical tasks such as system configuration (e.g., to set up the network interface), package installation (e.g., to install a Java Virtual Machine (JVM)), or implementation of all kinds of system commands and user applications.
The user space has a three-layer architecture, from bottom to top as shown in Figure 4: Service, Framework, and Application (User Interface). The Service layer provides three basic services: 1) The Database Management System (DBMS) service records and manages incoming user data, such as aggregated sensor data. Data can be organized in the file system within hierarchical folders or maintained by commercial DBMS software like MySQL. 2) The JVM service provides a platform for Java applications. 3) The Communication service controls wireless network access (as a client) or creation (as a host). An example would be the creation of an ad-hoc network for other handheld devices to locally access a GumPack Web server. The layers above the Service layer are platform-agnostic; the implementation does not depend on the lower-level operating system. Currently, Java is used to develop all elements above the Service layer. The Framework layer supports interconnection and interoperability standards for surface components and the GumPack itself in a large medical device cooperation environment (see section 3.5). The Application layer is user-oriented and divided into two categories: 1) A medical device app represents a surface component like a motion sensor SC and provides control and data access, visualization, and analysis. 2) A utility app can be developed to manage a PHR or make a call to a hospital.

GumPack Component Connection Framework
The GumPack design allows one to integrate biomedical components in an efficient and flexible way. New device functionality is added to a GumPack by plugging in or switching in the corresponding surface component. This method to design medical devices may attract developers' attention, resulting in a large collection of SCs available  GumPack software architecture.
to GumPack users. This implies the need to regulate these third-party components and call functions or Java classes from the corresponding libraries without user intervention. The GCCF is a software interconnection protocol based on the hardware interconnection interface on each surface substrate. Its primary functions are 1) SC authentication and 2) app installation automation, both realized by the GCCF and a profile chip on an SC. The profile chip contents include its identification information (for the first function) and interface and data format information (for the second function). Figure 5 illustrates the GCCF finite state machine (FSM). The starting state is Bus Scan. The GCCF periodically checks the I 2 C interface, which is designated for profile chip communication, from address 0×03 to 0×77. If there is no response for a particular address, it moves to the next address. A successful acknowledgement (ACK) triggers the GCCF to read the SC ID via the bus. An authentication process is implemented based on the 128-bit ID. If a negative result occurs, the FSM goes back to the Bus Scan state. If a positive result occurs, the GCCF reads interface information by accessing the same I 2 C address. The interface data are interpreted to check required resources (e.g., a bus driver), install the necessary app from the app library, and eventually run the app. If any error is encountered during the state Read Interface up to the state App Serving, the GCCF returns the FSM to the Idle state. Potential errors include 1) a resource request fail, e.g., a required GPIO is used by another app, 2) an interpretation error, e.g., a data format is undefined, 3) a profile chip communication error, and 4) a data communication error.

Chiclet Network and Device Interoperability Standards
Chiclets are important GumPack supplements for applications that involve wearable or nearby devices/sensors. They are 'off-board surface components' that wirelessly connect to the GumPack rather than relying on the onboard 70-pin connectors. The communication protocol could be Bluetooth, ZigBee, or other short-distance and low-power solutions such as Ant. For instance, ZigBee functionality is enabled by attaching the ZigBee coordinator SC to a GumPack. A Chiclet network is formed between one or more Chiclets and a GumPack. It is like a private local network rather than a public network in the context of interoperability between conventional medical devices. This relationship is illustrated in Figure 6. The lower left area depicts a Chiclet network based on a standard ZigBee star topology. In the broader context of a medical device network ( Figure 6, right side), a GumPack can be seen as a single terminal on an enterprise service bus (ESB), though its role is not fixed (it may be, e.g., a vital signs monitor or a patient communicator), which makes the GumPack a good candidate for Kansas State University's MDCF project [14], [23]. MDCF work is informed by related efforts pursued by the Medical Device "Plug-and-Play" Interoperability Program (MDPnP) [24], which develops standards and prototypes for systems of cooperating devices. The GumPack is the first native MDCFready medical device that can successfully run the whole MDCF client on itself with JVM service support (see Figure 4). This MDCF scenario is an example of integrating the GumPack into a cooperative medical device network. Other interoperability frameworks such as MDPnP will be evaluated in the future. ISO/IEEE 11073 standards are also to be assessed for Chiclet network and GCCF operation. Figure 7 shows the first version of the assembled GumPack prototype surrounded by three Chiclets. The size of this prototype is 84.4 mm × 32.8 mm × 32.8 mm. The four mounted surface components are the aforementioned processor SC, a motion sensor SC, an ECG SC, and a ZigBee coordinator SC that coordinates the three Chiclets  Figure 6. GumPack Chiclet network and medical device interoperability.

RESULTS AND DISCUSSION
(reflectance pulse oximeters [22]). The processor SC utilizes a 2 GB Micro SD card that provides 200 MB for the operating system, 100 MB for component frameworks, and 10 MB for each app (see section 3.4). A Wi-Fi antenna and a lithium-ion rechargeable battery (UltraFire 18650; 3.7 V; 3600 mAh) are placed inside the cuboid structure. These items fix the minimum volume of the current GumPack embodiment. In this configuration, the GumPack can operate up to 6 hours on a single battery charge when transmitting device data continuously over a Wi-Fi connection. While this paper is intended to focus on the GumPack idea as opposed to the acquisition of specific sensor signals, the concept of obtaining an 'unfiltered signal' is worth briefly noting. Unfiltered PPGs are obtained by the reflectance pulse oximeter Chiclets that employ digital baseline control [22]; Figure 8 (a) shows a digitally filtered, single-lead ECG obtained with careful baseline and amplification control. † Comparable raw ECGs are usually accompanied by different levels of 60 Hz grid noise (in the U.S.) and appear to be low quality. However, they represent raw data with all signal details (e.g., frequency components) unaltered and exposed. These data are therefore extremely useful for education, environmental assessments, and signal processing comparison studies. Figure 8  which is likely the respiration rate. The 60 Hz noise component has a large magnitude, though it is not shown here. Signal quality (e.g., signal-to-noise ratio) is immediately improved by digital post-processing as illustrated in Figure 8 (a), which can be efficiently realized in the GumPack; such signals can be further enhanced by exploiting the digital signal processor core. One demonstrative Chiclet network (or WBAN) application is the precise calculation of pulse wave velocity (PWV) based upon a direct approach: dividing the distance by the wave transit time between two PPG sensor nodes at the wrist and the fingertip [25]. Analogous to sound wave propagation, PWV depends on the properties of the propagation media, such as blood and arterial wall tissue. One objective of this experiment is to estimate PWV values at different stages of a cardiac cycle. An expected result is that three PWVs measured at the foot, inflection point, and peak of the systolic interval will monotonically increase given the respective increases in blood pressure. High sampling frequencies for the upstream and downstream PPGs are critical due to the much faster PWVs relative to their corresponding blood flow rates as well as the need for high synchronization accuracy between the PPGs.  A GumPack with a ZigBee coordinator SC and two wireless reflectance pulse oximeter Chiclets (sensors) form a network similar to the one shown in Figure 7. The PWV application, which relies on the GumPack's processing capability, requires high-resolution raw data (sampled at up to 480 Hz), real-time operation, and time synchronization of intrasensor data and inter-sensor waveforms. Figure 9 depicts two discrete PPG waveforms received from two Chiclets placed at the wrist (blue diamonds) and the corresponding fingertip (red crosses). PWVs are calculated from the time differences between corresponding features in these PPGs using the following sequence [26]: Synchronize the signals using statistical information about relative delays.
All of the signal processing can be implemented on the GumPack platform, including the delay calculation for a given frame relative to a reference frame.  Two unprocessed PPG data streams received from Chiclet 1 located at the wrist and Chiclet 2 at the fingertip. The data points at the bottom with negative values represent the lost frames.
illustrates two polynomial curves obtained for the upstream and downstream sensors, respectively, after statistical synchronization, where linear regression methods determine their relative spacing. To calculate PWV, corresponding features on the rising slopes of the two waveforms can be identified, where the time-difference extraction approach involves taking derivatives of the PPGs. In this example, three PWV values are estimated as 5.12 m/s at the waveform foot, 5.51 m/s at the inflection point, and 9.47 m/s at the peak.

CONCLUSION
This paper describes the concept design for a "GumPack": a new type of everydaycarry, multi-sensor medical monitoring device that offers computer-grade processing, the ability to host multiple biomedical sensors that can be reconfigured in a plug-andplay manner based upon patient need, the means to serve as a host for wearable/nearby medical components, and the opportunity for integration into hospital-level medical device connectivity and coordination frameworks. GumPack keynotes are highlighted below. The physical form factor is an innovative 3D hardware layout that does not stack circuit boards in layers like some 'adaptable' tools. Rather, its cuboid form factor provides a housing for multiple customizable surface components while still maintaining a small everyday carriable size. In its current structure, a GumPack supports four reconfigurable surfaces, where GCCF-compatible SCs can be easily added or removed.
More than a sensor-laden device, a GumPack provides the computational capability and connectivity of a contemporary smart phone. It will enable a local PHR service to  Figure 10. Statistically synchronized, continuous PPG pair created on the GumPack.
accept data from particular medical devices, where these data can be uploaded or synchronized with other PHRs, e.g., Microsoft HealthVault or a hospital EHR server. Interoperability is considered and tested for the GumPack as a single conventional medical device. Since it is also a collection of local SCs and/or Chiclets as an independent system, the GCCF offers component identification, authentication, interface interpretation, and app automation.
The GumPack concept moves beyond, in some ways, cell-phone-centered medical sensor systems that employ dumb devices and are targeted for ambulatory or wearable applications, including those intended for ubiquitous home care environments. The design not only provides a new topology between a sensor and a hub (e.g., for data aggregation, processing, and communicaton), but offers a fully open development platform for hardware and software developers.
GumPack development can proceed along one of the following three paths: 1) Based on the current GumPack configuration, large-scale tests or pilots can be conducted to assess and enhance the original concept. 2) A new collection of surface components can be designed to evaluate the capability to host a variety of medical components, such as the control circuitry for an infusion pump. 3) Other medical device connectivity teams can partner to fulfill the interconnection framework inside the GumPack.