|
|
World Medical Centers |
 coming soon
|
|
|
|
|
|
MobiHealth Service Platform |
MobiHealth Service Platform
The MobiHealth service platform enables remote monitoring of patients using 2.5/3G public wireless infrastructures. Patient data is collected using a Body Area Network (BAN). A healthcare practitioner can view and analyse the patient data from a remote location. In this setting, the BAN acts as a provider of patient data and the healthcare practitioner acts as a user of that data.
This section presents the BAN, the service platform and identifies the technical challenges that have been addressed during its development.
Body Area Network
The healthcare BAN consists of sensors, actuators, communication and processing facilities. Depending on what type of patient data must be collected, different medical sensors can be integrated into the BAN. For example, to measure pulse rate and oxygen saturation, an oximeter sensor is attached to the patients’ finger. In the case of an ECG measurement, electrodes are attached on the patient’s arms and chest.
Communication between entities within a BAN is called intra-BAN communication. Our current prototype uses Bluetooth for intra-BAN communication. To use the BAN for remote monitoring external communication is required which is
BANip: enabling remote healthcare monitoring with Body Area Networks
called extra-BAN communication. The gateway that facilitates extra-BAN communication is called the Mobile Base Unit (MBU). Our current prototype employs an HP iPAQ H3870, that runs Familiar Linux and a J2ME compliant Java virtual machine, as an MBU. Other mobile devices, such as a SmartPhone or a J2ME enabled PDA could also act as an MBU.
• How to deal with the limitation of the resources of BANs used for monitoring services?
In the MobiHealth service platform, the supplier of data for remote monitoring is the BAN, which should be wireless and wearable. Traditionally, providers of data (such as web servers) are deployed on a computing infrastructure with sufficient network and processing capacity. Consumers of data (such as web browsers) assume that providers are available most of the time (except for maintenance) and with sufficient bandwidth to serve a reasonable amount of consumers. For the service platform, the producer and consumer roles are inverted because the provider of data is deployed on a mobile device (i.e. the MBU) while the consumer of data is deployed on a fixed host with sufficient processing and communication capacity. It is a technical challenge to deal with this inverted-producer-consumer problem in the design of the platform.
• How to provide reliable and secure end-to-end healthcare services in multi healthcare delivery stakeholders domains?
It is generally required that for privacy reasons medical data of patients has to be transferred in a secure way. The transfer of the data needs also to be reliable to enable correct interpretation by healthcare practitioners. It is a technical challenge to develop an architecture and the associated mechanisms for an m-health service platform involving multi healthcare delivery stakeholders that highlight the added value of the involved stakeholders. For example, the MobiHealth call centre which addresses the reliability and security issues of m-health delivery in such a way that it releases other stakeholders from the burden of addressing these issues in their full complexity themselves. The scarce bandwidth resources of GPRS offered today by the operators and their policy to prioritize voice above data complicate the data transfer mechanisms further. Application protocols designed for use in local area networks, such as RMI and IIOP, are in this context not applicable for the GPRS links.
• How to provide a scalable end-to-end m-health service?
The Mobihealth service platform must support a many-to-many relation between the BAN and the MobiHealth secondary care centre. Potentially more than 100.000 simultaneously operating BANs should be supported. The medical data produced by those BANs could be of interest to various healthcare practitioners. Therefore the BAN must be able to produce medical data from as many locations as possible (thus supporting full patient mobility) and the medical data must be accessible from as many as healthcare centres. In summary:
- the service platform must scale to a size that it can support 100.000+ BANs (numerical scalability)
- the platform must support multiple (secondary) healthcare centres (i.e. multiple organizational domains) (organizational scalability)
- the platform must scale to a large geographical area (i.e. European or world scale) (geographical scalability).
The platform will be deployed in nine healthcare field trials in four European countries to evaluate its functionality and to assess the feasibility of 2.5/3G wireless technologies in combination with Java and Internet technologies for m-health service delivery.
By Nikolay Dokovsky,
Aart van Halteren, Ing Widya
University of Twente, The Netherlands
|
|
Last Updated ( Saturday, 24 November 2007 )
|
|
|
|
|
|
|
Who's Online |
You are: 0093278
At the moment:
37 guests online |
|
B.O.H.M.Content Calendar (News) |
| « | July 2009 | | | Mo | Tu | We | Th | Fr | Sa | Su | | | | 1 | 2 | 3 | 4 | 5 |
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | |
|
|
|
B.O.H.M.Content Calendar (PMMD) |
| « | Augustus 2008 | | | Mo | Tu | We | Th | Fr | Sa | Su | | | | | | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|
|
Pacemaker Monitoring Systems |
Pacemaker View
|
ADVERTISING AREA
ADVERTISING AREA
Your Text
Your Text
ADVERTISING AREA
Your Text
ADVERTISING AREA
«« Show your advertising text, banner, link, pool... here »»
Order:
***
|
«-»»
|
|
Publishing House Tempis, Ltd
