Your SlideShare is downloading. ×
4.3 - Experiences with an End-To-End Wireless Clinical Monitoring System
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

4.3 - Experiences with an End-To-End Wireless Clinical Monitoring System

230

Published on

Wednesday, October 24, 2012 …

Wednesday, October 24, 2012
Technical Session #4

Rahav Dor (Washington University in St. Louis, US), Chenyang Lu (Washington University in St. Louis, US), Gregory Hackmann (Washington University in St. Louis, US)

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
230
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • This is rarely done (most thus far were insolated small deployments, and NOT integrated)We had good experience with a single unit, so we decided to do moreThis was great – we found plenty of lessonsOn the talk todayReportexperiences and lessons learned fromReal life, real hospital, clinical trial, ofMultiple WSN, integrated with EMR
  • Eachcloud = sensor network in and of itselfSensors form mesh networksBased on low power 802.15.420mA vs 200mA for 802.11 in ideal modeResources to (re)connect after 1 minute of sleepAP needs Ethernet and range of 30 m
  • I am going to ignore 14th floor, it was done before, and our results shows that previous studies are correct.Routing via floorsRouting outside the buildingPlaces several relays between units for redundancyDid not need to deploy relays in the 10th floor
  • When moving deployments from a testbed to an enterprise setting, it is important to work closely with IT to understand how these policies may affect the deploymentIf the data the app carries does not contain patient identifying info, then there is no need for disk level encryption
  • Previous studies have discussed network density in the context of relaysOur experiences emphasize the importance of leveraging multiple base station to enhance reliability(a) The addition of a unit in the floor above(b) BS2 (52) was turned OFFOnly 4 relays connected. BS being off effect more than ward 2 relays(c) BS2 mote was disconnected(d) Critical relays disappeared again. Many contact isolation rooms
  • Also BS labelingCaseAttached motePower cable
  • We claimed that there is a high correlation between the network direct measurement and telemetrySo we measured it directlyBefore the July 29th (event (a))Four instances with quality < 70%
  • Telemetry analyzed by infrastructure HeartbeatComplete view over every area of the network, over the system life timeIndividual patient analysisEarly warning? Better care?We take advantage of the relays’ fixed power source to collect diagnostic coverage and routingHeartbeat 1 pulse/minuteDefinePDR > 90%AxesPurpleShaded = events (a) … (d)
  • Laptop with a USB attached TelosBTelosB is an interface between the 802.15.4 network and the BSCustom BS manager we authored is orchestrating everything that goes on (Python & Java)System calls (attached mote status, OS resources, …) Nightly reports (hospital security SMTP was the only way out)Log to local file time stamped extraordinary eventsHL7 (Health Level 7) is an international standard – using the HAPI libraryPostgreSQLMQ provides reliable transport (here IBM’s Web Sphere MQ)Also:SSH serverRun as a service (Tanuki for Windows and Linux daemons)Python   Java object exchange by JythonJava ODBC driver
  • System with many functions…But many of the challenges were not integration points or technology in generalWhat can we do to make academic projects better than industryThe paper has more points and more details on DOs and DON’Ts
  • * Hey, lets update our Facebook status
  • Dr. ChamberlainOur software on the mote manages power and frequency of vitalsUses a 1-hop protocol to account for mobility (Dynamic Relay Association Protocol – DRAP)
  • Explain axesFuture: patterns? And correlation to hospital daily activities? Time patterns?Some relays choose interesting paths: 115 does not go through the corridor to BS2 (BS52), rather to 188 via ceiling, 150, 174, 152, BS2 via floorBS1 (BS50) handled ~15%
  • RSSI = Received Signal Strength Indicator = The power present in a received radio signal
  • Thanks you and credits
  • Transcript

    • 1. Experiences with an End-to-EndWireless Clinical Monitoring System Rahav Dor, Gregory Hackmann, Zhicheng Yang, Chenyang Lu, Yixin Chen Department of Computer Science & Engineering, School of Engineering Marin Kollef, Thomas Bailey Department of Medicine, School of Medicine
    • 2. Motivation Clinical deterioration in hospitalized patients  4-17% suffer from adverse events such as cardiac arrest  Up to 70% of such events could have been prevented Early detection of clinical deterioration based on vital signs  Clinical deterioration is often preceded by change in vitals Real-time patient monitoring is required  Wired patient monitoring equipment in Intensive Care units  Most general hospital units collect vitals manually  Enabling patients to be ambulatory is advantageous Earlier trialQuestion: Do sensor nets, at scale, [SenSys’10] of a single unit, stand alone system integrated with hospital systems and rhythm, work? 2
    • 3. Overview of our study End-to-End clinical monitoring system  Wireless Sensor Networks (WSN)  Multiple departmental servers  Integrate into hospital Electronic Medical Records (EMR) Clinical trial  Deploy in a general hospital for 14 months  Monitor patients in 4 hospital floors, and 7 wards  Enrolled 97 hospitalized patients  Infectious diseases units Lessons learned and Recommendations for End-to-End sensor nets in general hospitals 3
    • 4. System components Base station • Connected wirelessly to WSN on one end; and • Hospital’s wired network on the other • Data processing software Relays • Plugged into “non-medical” wall power outlets • Redundant deployment • Form mesh networks based on IEEE 802.15.4 • Collection Tree Protocol on TinyOS Portable wireless pulse oximeter • Battery operated • Relay association protocol on TinyOS 4
    • 5. Relays network infrastructure 5
    • 6. Snapshot of the relays topology 12th floor 11th floor 6
    • 7. PERFORMANCE• Key lessons learned 7
    • 8. Impact of IT procedures Integration with IT infrastructure and policies  Full disk data encryption  Mandatory, almost daily, patches  User-level backups Recommendations  Use server-class machines  Sanitize data by the sensors and the application  Work with IT (server-level backups, patch cycles) 8
    • 9. Multiple base stations Multiple base stations can enhance reliability Unit Too many critical added on Base station 22 Base station Recommendations the turned disconnected floor above relays OFF relay disappeared  Use redundant base stations  Location is important  Allow 3D networks to form  Use “multi-destination” protocols 9
    • 10. Human factors Mote disappearing Base stations disconnects Web surfing Use of power outlets No control over your own equipment Recommendations  Equipment should look “medical grade”  Installed in appropriate places  Label everything 10
    • 11. SUMMARY 11
    • 12. Key lessons It is not just a Wireless Sensor Network  Consider IT procedures and test in the hospital  Need to be resilient to the hospital environment  Use medical grade equipment and have it look like one Multiple base stations – challenge and blessing  Use multiple base stations to enhance the data paths  Define subnets such that they can mesh together  Allow 3D networks to form Human factors Answer: Sensor nets, at scale,  Install your equipment in appropriate places integrated with hospital systems and rhythm,  Label everything be sufficiently reliable. can 12
    • 13. EXTRA 13
    • 14. Reliability of vitals signs delivery (VSD) Network reliability per patient 1 0.9 (a) (b) (c) (d) 0.8 BS2 0.7 OFF%Sensing received 0.6 Relays 0.5 BS2 disappearanc mote e period 0.4 0.3 0.2 0.1 0 Apr 01 2011 Jul 01 2011 Oct 01 2011 Jan 01 2012 Apr 01 2012 Date åVitalPackets (valid or invalid) VSD = BS ParticipationTime 14
    • 15. Network connectivity #Deployed relays Units 1-3 (excludes unit 4 on the isolated 14th floor) Network heartbeat are carried over the same Infrastructure as patient vital signs  Direct relationship to vitals reliability Packet Delivery Ratio (PDR): å HeartBeats PDR = BS 24 * 60 15
    • 16. Base station architecture 16
    • 17. Summary Accomplishments  End-to-end, real-time, telemetry system  Integrated to hospital system and rhythm  Large scale (#relays, multiple servers, spatial span)  Year long clinical trial Key DOs an DON’Ts  It is not just WSN. Plan to accommodate IT.  It is not just a system. Plan to accommodate hospital procedures.  Multiple base stations are not only a challenge, it can be a blessing.  Deal with the human factors. Many before the trial starts. 17
    • 18. State of the art Systems  Code Blue (Harvard)  AlarmNet (UVA)  MEDiSN (Johns Hopkins)  Step-Down at BJH (WU) Stand alone, not integrated, small empirical trials Our contributions  End-to-end, real time, telemetry system  Integrated to hospital infrastructure and rhythm  Large scale (~70 relays, 4 servers, 3 hospital floors)  Randomized and longitudinal study 18
    • 19. CHALLENGES AND LESSONS LEARNED 19
    • 20. Equipment and Technical design Use equipment appropriate for its task  Root password  Mandatory backups  PGP (data encryption, Pretty Good Privacy)  Force patch policy Radio access to individual motes Open source 20
    • 21. Real-time network monitoring Both real-time visualization, automatic alerts, and statistical (over a time-window) is needed 21
    • 22. High level components 22
    • 23. Wireless patient device Built for previous deployments Based on TelosB motes, TinyOS 23
    • 24. ; "<=#>?3! " ##$%&@ ?#3 ( %! #&) *, - . /012*1341+ 335 , 6 + & + + + 415 33+ 7( 5D @ 1FFD! 93 Nightly reportA,9B 3 8) #! + $/: ; + - : .$ 9$) <! ) ; =>?/@ ; =A " %#$0! &% ?! B @&?&<&$#)$-I # 443D6 J +#F)>",$9,$ 4773 .) ?) CB .A " %#$0! &% &: B@#C->#); ?&?"$ K#?L 9,M ?&?"$ );@#C->#)D E)9:), #& @ %-F8$ D F?#,:&>#)K&B # 6 *7 D 5 K L M , + O: .@+ ! $" : .P/; =+ ; $.: 0! .+ Q) @ $+ ?! &%0 .+ /; /- : .$ 335 285 5 FI R43B 42DB NM ; !K 7: 0 E+ P! 9@ ! 6 1G5 8J D75 FFB 433D $?," >?",#); ?& $F:,& ?" 59L #,); ?&?"$6 9?#)D @ G $?)<#& & >9F 5&?H43D 1341E32E1F+ GH5 I 21HHH 43D 1F5 13B ACLineStatusText S; 0 ! /;44G 1341E32E1F+ GH5 2G4HHH 44G*4J 2*43D 1F5 12B + + BatteryFlagText T /=?U $?! + $$! . + ) - ) @ + ) $+ .! + ; + - ! .@; $ V) @ /$ /#+ W: $?) DD+ ! BatteryLifePercent H44G3 1341E32E1F+ GH5 B HHHH 4G3*43D 1F5 FJ 1J + BatteryLifeTime %; P; : " ;4J 3 1341E32E1F+ GI 5 HDJ HHH 4J 3*43D 1F5 FHB + BatteryFullLifeTime %; P; : " ;4J 2 1341E32E1F+ GI 5 14J HHH 4J 2*43D 1F5 2GB +4I I 1341E32E1F+ GI 5 J 4J HHH 4I I 1F5 GFB@ ?& $#); ?& & <& ?"$5D @ 1FFD@ ?& $#)$-I # 443D6 & <&J +#F)>",$9,$ 4K #?L 9,M ?& $ ); ?" D F?#,:&>#)K & # B 6 *7 D 5 24K L M , + O: .@+ ! $" : .P/; =+ ; $. : 0! .+ Q) @ $+ ?! &%0 . + /; /- : .$ 335 285 5 FI NM ; !K 7: 0 E+ P! 9@ ! 6 1G5 8J D75 R43B 42DB FFB 433
    • 25. Multiple base stations Percent of time each relay was connected to each basestation 1 BS50 Relays are dividing BS52 0.9 BS60 0.8 their time between Percent conected 0.7 base stations 0.6 Least favored BS1 in 0.5 0.4 physicians 0.3 consultation room 0.2 0.1 0 100 120 140 160 180 200 220 Relay# 25
    • 26. Patient participation Number of hours each patient wore the device 80 70 60 50Hours 40 30 20 10 0 0 10 20 30 40 50 60 Patient# (ordered by time) 26
    • 27. Dynamic Relay Association Protocol (DRAP) Link quality by measuring  Measure RSSI (physical layer)  Measure #transmissions (link layer) Counter: consecutive relay invalidation  + when relay is invalidated (node is too far to send to, no ACK)  0 when data successfully delivered to a relay Rediscover neighbors table when counter > threshold 27
    • 28. Acknowledgements CPS lab – Body sensors group  Dr. Gregory Hackmann  Zhicheng Yang  Dr. Chenyang Lu Washington University Medical School  Dr. Marin Kollef  Dr. Tom Bailey Data mining  Yi Mao  Dr. Yixin Chen Study nurses – Pam Kemp and Emily Kuo Nurses at Barnes and Jewish Hospital Funding  NIH National Center For Research Resources  Barnes-Jewish Hospital Foundation  NSF NeTS-NOSS, CRI, and CPS grants 28
    • 29. References 1: The Joint Commission. 2008 national patient safety goals [Internet]; 2007. Available fromhttp://www.jointcommission.org/PatientSafety/Natio nalPatientSafetyGoals/08hapnpsgs.htm 2: O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis. Collection tree protocol. In SenSys, 2009. 3: O. Chipara, C. Brooks, S. Bhattacharya, C. Lu, R. D. Chamberlain, G.-C. Roman, and T. C. Bailey. Reliable real- time clinical monitoring using sensor network technology. In AMIA, 2009. 29

    ×