Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Slides for IWAAL

  • Be the first to comment

  • Be the first to like this


  1. 1. Communication architecture for tracking and interoperable services at hospitals: a real deployment experienceAugusto Morales, Tomás Robles, Ramón Alcarria, David AlonsoTechnical University of Madrid
  2. 2. INDEX Introduction Challenges Background Architecture From Architecture to Implementation Deployed Architecture and Workflow Lessons Learned Conclusions
  3. 3. INTRODUCTION Hospital environments  Unpredictibility of patients, medical staff, emergencies  constantantly changing environment.  Criticaly important communication system that carries important information. Issues: Advances in network architecture,  Lack of initiatives to adapt them to many protocols, services restrictive medical constraints  Weak points in QoS, self-adaptation and standardization, ubiquitous communication  Regarding interaction between the medical staff and tehnology itself. We need adapted hospital communication Real deployment architecture in order to support new medical experiences services
  4. 4. CHALLENGES Tracking of medical devices makes up an important part of the whole hospital process. In addition, it inherits the same deficiencies as manual processing is in operation. Staff tracking is particularly challenging because it involves humans. It is necessary in critical cases when emergencies occur or when patients need continuous monitoring. Another challenge is concerning patients and their vital constant monitoring. Hospitals have systems in order to monitor and send alarms to medical staff when special situations occur. Open the possibility for potential integration with existing health systems
  5. 5. BACKGROUND ARCHITECTURE Global Architecture:
  6. 6. FROM ARCHITECTURE TO IMPLEMENTATION In any real deployment, the architecture may be limited by the existing physical and technological resources of the scenario The physical element affects many technological factors In our case: the physical and technological resources available in the Hospital did not permit the deployment of the complete architecture based on different roles and servers.
  7. 7. DEPLOYED ARCHITECTURE AND WORKFLOW External Domain Bluetooth (2) 3G (3) ethernet (1) Wi-fi RouterBio (4)Sensors ethernet Central Hospital Network Domain Server
  9. 9. LESSONS LEARNED & DISCUSSION Any evolution from current to future stages in any hospital systems is difficult and risky, especially when it involves a drastic change. Some minor changes can offer major advantages. Cooperation and feedback with medical staff and patients are indispensable. Our architecture involved a human component by suggesting to medical staff to always carry a RFID tag in their pockets. Since a prototype should not affect a Hospital, its normal processes and communication systems, efficient physical deployment is a requirement Our experiences in this development, via surveys, suggests to us that tracking, which involves privacy issues, is not fully-accepted by health personnel
  10. 10. ConclusionsWe have considered many aspects such as network topology and also exposed a realistic way to apply it.The original architecture envisaged service creation from specialized developers. On the other hand, the medical staff’s surveys revealed that creating basic and simple services will be one of the best advantages for future hospitals and AAL environmentsIn addition, staff location and alarms could be integrated as key service features. Since medical staff’s tracking is still an uncompleted feature in our system, a future architecture will have to include location policy modulesOur data analysis, which will provide us with statistical results, has not been finalized yet, but we have learned lessons regarding this architecture and its capabilities