Your SlideShare is downloading. ×

iwaal2011

121
views

Published on

Slides for IWAAL

Slides for IWAAL


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

  • Be the first to like this

No Downloads
Views
Total Views
121
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

Transcript

  • 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. INDEX Introduction Challenges Background Architecture From Architecture to Implementation Deployed Architecture and Workflow Lessons Learned Conclusions
  • 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. 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. BACKGROUND ARCHITECTURE Global Architecture:
  • 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. DEPLOYED ARCHITECTURE AND WORKFLOW External Domain Bluetooth (2) 3G (3) ethernet (1) Wi-fi RouterBio (4)Sensors ethernet Central Hospital Network Domain Server
  • 8. DEPLOYED ARCHITECTURE AND WORKFLOW HEALTH STATION RFID TAGSRFID ANTENNAS
  • 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. 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

×