Documents

A Telehealth Architecture for Networked Embedded Systems-A Case Study in in Vivo Health Monitoring

Description
IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 13, NO. 3, MAY 2009 351 A Telehealth Architecture for Networked Embedded Systems: A Case Study in In Vivo Health Monitoring Foad Dabiri, Member, IEEE, Tammara Massey, Member, IEEE, Hyduke Noshadi, Hagop Hagopian, C. K. Lin, Robert Tan, Jacob Schmidt, and Majid Sarrafzadeh, Fellow, IEEE Abstract—The improvement in processor performance through continuous breakthroughs in transistor technology has resulted in the proliferation of
Categories
Published
of 9
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 13, NO. 3, MAY 2009 351 A Telehealth Architecture for Networked EmbeddedSystems: A Case Study in In Vivo Health Monitoring Foad Dabiri  , Member, IEEE  , Tammara Massey  , Member, IEEE  , Hyduke Noshadi, Hagop Hagopian, C. K. Lin,Robert Tan, Jacob Schmidt, and Majid Sarrafzadeh  , Fellow, IEEE   Abstract —The improvement in processor performance throughcontinuous breakthroughs in transistor technology has resultedin the proliferation of lightweight embedded systems. Advancesin wireless technology and embedded systems have enabled re-mote healthcare and telemedicine. While medical examinationscould previously extract only localized symptoms through snap-shots, now continuous monitoring can discretely analyze how apatient’s lifestyle affects his/her physiological conditions and if ad-ditional symptoms occur under various stimuli. We demonstratehow medical applications in particular benefit from a hierarchicalnetworking scheme that will improve the quantity and quality of ubiquitous data collection. Our Telehealth networking infrastruc-tureprovidesflexibilityintermsoffunctionalityandthetypeofap-plications that it supports. We specifically present a case study thatdemonstrates the effectiveness of our networked embedded infras-tructure in an in vivo pressure application. Experimental resultsof the in vivo system demonstrate how it can wirelessly transmitpressurereadingsmeasuringfrom0to1.5lbf/in 2 withanaccuracyof 0.02 lbf/in 2 . The challenges in biocompatible packaging, trans-ducer drift, power management, and in vivo signal transmissionare also discussed. This research brings researchers a step closerto continuous, real-time systemic monitoring that will allow one toanalyze the dynamic human physiology.  IndexTerms —Collaborativetechnologiesinhealthcaredelivery,informationscienceandtechnology,teleconsultation,telemedicine,telesurgery. I. I NTRODUCTION R ECENT advances in the electronics industry and wirelesscommunication have enabled innovative domains of ap-plications to evolve. Embedded processors and systems havebecome widely used in people’s everyday life in various ap-plications ranging from mobile communication to automotiveindustries to medical applications.There has been several studies and system developmentsfor real-time health monitoring through wireless technologies.Some examples of application-specific medical systems are Manuscript received February 9, 2008; revised May 1, 2008 and July 22,2008. First published January 23, 2009; current version published May 6, 2009.This work was supported in part by Microsoft Research. This paper was pre-sented in part at the 4th International Workshop on Body Sensor Networks inAachen, Germany, in 2007.F. Dabiri, T. Massey, H. Noshadi, H. Hagopian, and M. Sarrafzadeh arewith the Department of Computer Science, University of California, LosAngeles, CA 90095 USA (e-mail: dabiri@cs.ucla.edu; tmassey@cs.ucla.edu;hyduke@cs.ucla.edu; shaitani@gmail.com; majid@cs.ucla.edu).C. Lin, R. Tan, and J. Schmidt are with the Department of BiomedicalEngineering, University of California, Los Angeles, CA 90095 USA (e-mail:schmidt@seas.ucla.edu.Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.Digital Object Identifier 10.1109/TITB.2009.2013248 wristbandsformeasuringpulse,bodytemperature,galvanicskinreactions, and electromyography (EMG) data [1], [2]; chest andarm belts for physiologic monitoring [3], [4]; shoes for gaitanalysis [5], [6]; and photo plethysmographic ring sensors [7].The development of standards in practice, technology, andinformation processing are crucial to the success of wirelessTelehealthapplications.Well-designedstandardswillensurein-teroperability, integrity, and compliance among various medicaldevices. Assuredly, the lack of standards will lead to devicesthat are prohibitively expensive, complex, unreliable in oper-ation, and present a large educational and training burden forhealthcare providers.We have used our infrastructure in various applications. Asan illustrative instance, we present a minimally invasive im-plantable pressure sensing system that actively monitors long-term physiological changes in real time. Specifically, we inves-tigate pressure changes in the upper urinary tract per degree of obstruction.Extensive work has been done in passive pressure monitor-ing where an incoming radio signal induces the pressure mea-surement. The earliest pressure capsules were developed byJacobson and Machay [8] and Farrar et al. [9] in 1957 us-ing a passive telemetering capsule that used the motion of theiron near the coil to determine internal pressure and temper-ature. Later, an implantable passive eye transistor measuredpressure [10]. Fonseca et al. [11] investigated passive pres-sure sensors that did not contain a power supply or an activecircuitry for high-temperature environments. Passive measure-ments enable the construction of extremely miniature devices,but have a low range and must be close to an emitting radio sig-nalinorderformeasurementstobecollected.Recently,Fonseca et al. [12] developed a passive pressure sensor for acute useswith liquid crystal polymers and chronic uses using ceramicfabrication. The previous work on in vivo systems (such as [13])introduce technologies for in vivo monitoring; our contributionis to utilize these technologies and integrate it with featuressuch as reconfigurability and customization to make a gen-eralpurposeubiquitoushealthmonitoringwithminimumexpertsupervision.Compared with the aforementioned research, our Telehealthinfrastructure and in vivo active pressure monitoring system hasthe following unique features:1) the continuous, active monitoring of pressure within theupperurinarytracktodeterminehowone’slifestyleaffectsphysical symptoms;2) the aggregation of data to an online database that storesinformation for later analysis of the symptoms; 1089-7771/$25.00 © 2009 IEEE Authorized licensed use limited to: Ramabhadran Sampath. Downloaded on October 11, 2009 at 10:26 from IEEE Xplore. Restrictions apply.  352 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 13, NO. 3, MAY 2009 Fig.1. Systemcomponentsoftheactivepressuresystem:aPDAservingasanOBT, a catheter collecting sensor data, a wireless transmitter, and a lightweightmicroprocessor or Mednode. 3) the remote in viv o reconfiguration of the software;4) dynamic power and energy management.II. H EALTH M ONITORING I NFRASTRUCTURE In this section, we will go over individual parts of our pro-posed network structure for real-time health monitoring. In theproposed system,each patient has lightweight wireless modulesthat form on-body networks and utilize local on-body serversthatcommunicatewithotheron-bodysensorsorthemedicalen-terprises. Fig. 2 in Section III illustrated this general hierarchi-cal architecture. The hierarchical architecture contains sensors,Mednodes,on-bodyterminals(OBTs),andcentralserver.Fig.1illustratesthecomponentsofourarchitectureimplementedinan in vivo pressure monitoring platform. Our hierarchical architec-ture is similar to other architectures proposed [14]–[16], but ourarchitecture has reconfiguration capabilities and unique powersaving techniques for lightweight embedded medical systems.Mednodesarethemaincomponentsofourproposedwearablearchitecture. A Mednodes is a stand-alone component that con-sists of a processing unit, a sensor board, and a local power sup-ply. We have used Mica2Dots and Mica2s from CrossBow [17]asthemainprocessingunitinMednodes.Theselightweightem-bedded systems are called “motes” in general and are equippedwith Atmel ATmega 128L microprocessor with multichan-nel analog-to-digital converters (ADCs). They also use 868/ 916 MHz multichannel radio transceiver for wireless communi-cation. Various sensors are interfaced to these channels througha sensor board. The sensor board operates as an interface toboth excite a passive sensor and feed the sensed signal to anADC channel. In some scenarios, a signal conditioning circuitis embedded onto the sensor board as well. Mednodes are ca-pable of wireless communication and support two-wired com-municationprotocols:interintegratedcircuit(I2C)anduniversalasynchronous receiver/transmitter (UART). A coin cell batteryis used to supply the Mednodes with power that immediatelyraises the power consumption challenges in system design. Wedescribe these challenges and propose methodologies to over-come these challenges shortly.TheMednodescommunicatewithanOBT.TheOBTisaper-sonal server that is a programmable lightweight system, such asa cell phone or a PDA. These devices collect data from sensors,store, or process data, and transmit data to an enterprise. Weuse different off-the-shelf devices as part of our system, suchas PocketPCs, cell phones, and portable multimedia devices(e.g., iPod). In particular, we tested our system on two differentPocketPCs from HP (iPaq) that had WiFi connectivity andconnected to a local area network. Also, they support globalsystem for mobile communication (GSM) and can be used asa cell phone.In our system, the OBT acts as an intermediate connector be-tween patient and physician. The communication protocol usedby Mednodes is 802.15.4 (Zigbee compliance). On the otherhand, the OBT, which is a handheld device, does not support802.15.4. Therefore, a gateway radio connects to the OBT andcollects data from Mednodes wirelessly, and transmits it to anOBT via a serial connection (UART). The OBT opportunisti-cally transfers data to a remote server by either using WiFi orBluetooth. In more recent versions of Mednodes, we equippedthem with RN-24 Bluetooth modules [18] to enable direct com-munication between Mednodes and on-body network (OBN).The final leg in this design hierarchy is the central server. Theserver collects the data received from multiple OBTs and func-tions as a central storage unit. Moreover, extensive data analysisand processing are scheduled to be performed at the centralserver. One of the unique features of the server in our prototypeisitscapabilitytomonitorthefunctionalityofindividualpatientsand reconfigure OBTs and associated Mednodes according toreal-time needs. More details on reconfiguration techniques aredescribed in [19]. Arguably, much of the emphasis in past work on healthcare applications of wearable sensors and devices hasbeen driven by the hardware design and communication infras-tructure, and less attention has been paid to the problems of integrating such information into the medical enterprise. Thus,ideally,theserverwouldexecute severaltasksincluding:1)dataincorporation into a patient’s electronic medical record (EMR);2) additional processing and/or signal analysis given the addi-tionalcomputationalprocessingpoweravailableonservers;and3) the reconfiguration of resources on the handheld device andMednodes using interactions of healthcare providers and theEMR itself (i.e., in a feedback loop).III. H IERARCHICAL N ETWORK S TRUCTURE The structure of the entire network can be described bybreaking down the network into two layers. The lower of the two layers are the branches in the network that representthe OBN and the wireless embedded sensor network that isphysically located on the body. The remaining layer of thenetwork is the “network of OBNs” or “personal area networks”(PANs). Fig. 2 illustrates a general overview of the networkinghierarchy. It starts from individual Mednodes that form theBANs, and then leads to the PANs, and finally, the centralserver/medical enterprise. The PAN allows both the communi-cation between independent OBNs and the communication of individual OBNs to the server. The server module contains theserver gateway, which all OBNs must establish a connection tocommunicate with the server (Fig. 2). The network has also thecapability of connecting independent OBNs. These OBNs havea flexible interface that allows various sensors from variousmanufacturers to connect up to the node. For example, the Authorized licensed use limited to: Ramabhadran Sampath. Downloaded on October 11, 2009 at 10:26 from IEEE Xplore. Restrictions apply.  DABIRI et al. : TELEHEALTH ARCHITECTURE FOR NETWORKED EMBEDDED SYSTEMS: A CASE STUDY IN In Vivo HEALTH MONITORING 353 Fig. 2. High-level diagram of the proposed network. interface for sensors has a connector that can be removed whichcan handle sensors that require a different number of channels.Node i represents the i th sensor node (or Mednode) that ispart of the OBN. The OBT is the gateway node between anyNode i andtheupperlayersofthenetwork.TheOBTconnectstootherOBNsandtotheservergateway.Thehierarchicalnetwork structureproposedhereisareliable,efficient,andreconfigurabledesign that promotes stability and network expansion. By usingan OBT as a gateway between the upper layers of the network andthelower(OBN)layer,unnecessarycomplicationandpowerconsumption are minimized greatly. In this highly organizedhierarchical design, any node can connect to any OBN from theoutside and any node is able to send data to the outside. In thisinfrastructure, there is no need for an amalgamated network thatwould use a significantly larger number of resources and woulddwarf attempts of network expansion. We will elaborate moreon OBNs in the next section.  A. Expansion of the Network  As mentioned before, our hierarchical design allows expan-sion in at least two dimensions. The first dimension (from thelower layer) is the expansion of the quantity of sensor nodes byany integer k . If  n represents the number of sensor nodes in anygiven OBN, then the system should allow for a total of  n + k nodes. Our system begins with n = 0 , and then, adds one nodeat a time until any number of nodes n + k are added. The onlylimitation presented by our communication protocol providesthe upper bound n + k < 255, where 255 is the largest nonre-served integer representable as an 8-bit number. Note that thislimitation is dynamic; a simple change in protocol will allowfor a larger number of nodes to be added. The communicationprotocols does not rely on the upper limit on n ; in other words,increasing this limit is just a matter of parameter update andpacket exchanging protocols remain intact.In the OBN model, the first dimension of expansion of nodesfollows the next protocol. Node x would like to join an OBNwhere three nodes are already connected. The OBT must firstrecognize Node x ’s request to join the OBN. The OBT then for-ward the request to the server. The server has the knowledge of thepreviousjoinednodes,Nodes1through3.TheserverassignsNode x ,anidentificationnumbertodistinguishanyfuturerecon-figuration commands sent to the node and sensor data receivedfrom the node. The OBT will then relate the new ID number toNode x andconfigureittoidentifyitselfusingitsnewlyassignedID. This process can be repeated to add additional nodes to theOBN.The second dimension of expansion is the addition of a newOBN module to the network. To add a new OBN, there existsonly one new protocol. A nonhierarchical network would haveincreased the number of protocols required to add a new branchtothenetwork.However,inoursystem,theadditionoftheOBNprotocolisinherentlyparalleltotheearlierOBTcommunicationprotocol. In this layer of the architecture, a regular sensor nodemust be differentiated from an OBT. As a new OBT requires anew ID number to distinguish it from other nodes on an OBN,a new OBN also requires unique identifier. When a new OBN joins the network, it sends a request to the OBN to be added tothe network. The OBN forward this request to the server. Theserver, having kept track of the previous OBNs added, assigns auniqueOBNIDnumbertotheOBN.Oncetheserveracceptstherequest and returns a new ID, the OBN configures itself to usethat new ID number to distinguish itself from the other OBNs.IV. N ETWORK C OMMUNICATION P ROTOCOLS This section discusses the various command protocols cur-rently implemented by our network and the theory behindthe minimum number of unique command protocols requiredto have a fully functional patient sensor network. Currently,our communication protocol consists of three basic forms of communication. Two communication protocols are for uniqueidentification requests, and the third protocol is for sensor datatransfer. This is the absolute minimum number of independentcommand structures necessary to implement the network in ourdesign.  A. OBN Formation Protocols In order to appropriately identify each layer of the network (i.e.,sensornodes andOBN),wemustfirstdistinguisharequestcoming from a sensor node and a request coming from an OBNin order to assign ID numbers unique to the appropriate branch.In order to configure a node, we specify two things: a branch(i.e., OBN) and a sensor node within that branch. In order to ac-commodate these two dimensions, there are two different typesof requests in this network. The lower level aspects of a packetand protocol are described shortly. Each type of packet corre-sponds to three different basic requests: incoming data fromsensor node to server, an OBT ID request, or a sensor node IDrequest.For each packet, there is a slashed field at the beginning.This slash represents a reserved integer used as a frame markerthat “marks” the beginning of the packet. The type 1 packetis the format of incoming data from a sensor node. A type 1header contains thepacket type, patient ID(unique identifier forindividual OBNs), mote ID (unique identifier for sensor nodes),data type, and sequence number. A type 2 packet contains arequest for a new patient ID. Type 2 packets prevents relevantinformationfrombeingpassedfromanewOBT.Atype3packetis a request from a new sensor node asking to be assigned thenext available ID in its OBN. All earlier three packet types are Authorized licensed use limited to: Ramabhadran Sampath. Downloaded on October 11, 2009 at 10:26 from IEEE Xplore. Restrictions apply.  354 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 13, NO. 3, MAY 2009 Fig. 3. Ad hoc networks created by individual OBTs where each OBT repre-sents an OBN. sent from the network to the server, but two of them require aresponse.There are two responses that are sent from the OBT to thesensor node. Type 2 responses are from the OBT requestinga unique patient ID. Type 3 responses are from a sensor noderequesting a unique mote ID to the OBN. Due to the open-ended design in our communication protocol, we can readilyexpand our library of commands to almost any configuration.For example, the server can specify an OBN, a sensor node,and a new command of packet type x to change the samplingrate. This level of configurability allows real-time changes to bemade to the system.  B. Communication Between OBTs The OBTs carried by patients have the capability of com-municating by other similar devices in the environment. TheOBTs have the capability of forming an ad hoc network witheach other and transfer data when policy dictates (see Fig. 3).Each mobile OBT can join the ad hoc network by requesting anInternetprotocol(IP)addressspecifictotheadhocnetwork.Therequest will be made to a dynamic host configuration protocol(DHCP) server, which can be centralized on the local server ordistributed on the existing mobile devices. Once the request isreceived by DHCP server, a new IP address will be given to thatparticular node.The OBTs send requests to members of the network. Thismessage can be the permission to disseminate data in case of emergency. Once permission is granted, the client node willinitiate a connection with the target device and start sendingmessages. User datagram protocol (UDP) is a connectionlessprotocol. Therefore, there will be no guarantee that the mes-sage has been transferred successfully. To overcome this uncer-tainty,thereceiver OBTswillsendacknowledgment messagetothe sender with each received message containing the receivedpacketnumber.Thepacketsofdatawilleventuallygetdelivered Fig. 4. Message type for OBTl protocols. to its final destination. As an alternate method to form ad hocnetworks, our system can utilize Bluetooth to connect itself toother Bluetooth enabled authorized nodes in the network. It isdesired for applications to have the flexibility to choose theirwireless medium. Once an OBT connects with another OBT,the type of connection is determined based on variety of factors,such as intention, power, policy, and availability. C. Communication Protocols for the OBT  Each OBN is composed of two autonomous components:Mednodes and OBTs. Each Mednode sends a wireless embed-ded system that is connected to several sensors through ADCports, and they have the ability to collect sensor data and sharethemwithothernodesinthenetworkwirelessly.EachMednodeis sending two type of packets: advertise message (AdvMsg)and data packet. Initially, each Mednode must obtain a uniqueMednode ID and patient ID from the OBT. Once a Mednode isadded to a body network, it broadcasts an AdvMsg that passesthe nodes unique network address to the OBT and introducesthe sensor mote as a new Mednode on the body. To maintainreliability in the network, there is a time-out variable associatedwith each AdvMsg sent. The time out occurs when a Mednodedoes not receive a response from the OBT during the time-outinterval when the AdvMsgs are sent.TheabilitytosetthepatientIDandMednodeIDdynamicallyallows the network to be flexible so that at any time a new sen-sor can be added to an OBN. Also, Mednodes can be swappedbetween different patients by restarting them in the new envi-ronment. The Mednode starts transmitting data packets as soonas it receives a proper (nonezero) Mednode ID and patient ID.The types of messages are illustrated in Fig. 4.OBTs are composed of two different components: a wirelesssensor platform (Mica2 or Mica2dot) and a PDA. Currently, ourOBTs work with two different interfaces: 1) PDA communi-cation (Fig. 5) and 2) PC Gateway communication (Fig. 6). If the OBT is in the PC Gateway’s wireless range, the terminalwould communicate with the PC Gateway; otherwise, it wouldcommunicate with the PDA, as previously discussed. The moteon the OBT is responsible for maintaining a patient ID for theOBN, maintaining and assigning Mednode IDs for Mednodesin the OBN, and redirecting the packets from Mednodes to thePC or PDA. Same as Mednode, every OBT should request apatient ID upon start-up. Therefore, an AdvMsg would be sentto the PC Gateway at the request of a patient node.Moreover, the OBT requests a new patient ID from the PCGatewayuponthearrivalofanAdvMsgfromthenewMednode. Authorized licensed use limited to: Ramabhadran Sampath. Downloaded on October 11, 2009 at 10:26 from IEEE Xplore. Restrictions apply.
Search
Similar documents
View more...
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks