SAPHE Final Architecture
SAPHE Issue : 1.0 Document Reference: D12
Main Author: D Walker Date: 15 January 2009 Based on D04: Common Node Architecture Additional contributions from: D Polling, R Ali, R Blake, T Mizutani, N Barnes, B Lo
SAPHE
Contents 1
Introduction ................................................................................................................ 3
2
Project Description & Objectives ............................................................................... 4
3
SAPHE Architecture................................................................................................... 5
4
Home Devices............................................................................................................. 6 4.1
Overview ............................................................................................................ 6
4.2
Devices ............................................................................................................... 7
4.2.1
Set Top Box & Display .................................................................................. 7
4.2.2
Home Gateway ............................................................................................... 8
4.2.3
Secondary Display Device .............................................................................. 8
4.2.4
Computer or Home PC ................................................................................... 8
4.2.5
Blob Sensor .................................................................................................... 8
4.2.6
Weighing Scales ............................................................................................. 9
4.2.7
PIR Sensors..................................................................................................... 9
4.2.8
Door Sensors ................................................................................................ 11
4.2.9
Bed Sensor .................................................................................................... 11
4.2.10 4.3
5
Connectivity...................................................................................................... 12
4.3.1
Security ......................................................................................................... 12
4.3.2
Bluetooth ...................................................................................................... 13
4.3.3
WLAN .......................................................................................................... 13
4.3.4
ZigBee & 802.15.4 ....................................................................................... 13
Body Worn Devices.................................................................................................. 14 5.1
Overview .......................................................................................................... 14
5.2
Devices ............................................................................................................. 15
5.2.1
Mobile Hub ................................................................................................... 15
5.2.2
Sensors .......................................................................................................... 16
5.3
6
Other Sensors............................................................................................ 12
Connectivity...................................................................................................... 16
5.3.1
Bluetooth ...................................................................................................... 17
5.3.2
(Ultra) Low Power Radio ............................................................................. 17
Common Software .................................................................................................... 18 6.1
Common Sensor Protocol ................................................................................. 18
Author: DP Walker
Issue 1.0
1
SAPHE
7
Back End System ...................................................................................................... 20
8
Continua Alliance ..................................................................................................... 22
9
Reference Document Appendix................................................................................ 23
10
Document History..................................................................................................... 24
Author: DP Walker
Issue 1.0
2
SAPHE
1 Introduction This document describes the final SAPHE architecture that was implemented in the technology trial of systems installed in homes of 20 elderly patients in Liverpool. The trial started in December 2008 although the first systems were installed in January 2009. The document is based closely on the deliverable D04 Common Node Architecture but includes all changes made to the system during the course of the development phase of the end to end system. Sections of D04 are kept here, for completeness, so the document may read as a whole. This document effectively replaces D04 but also includes a chapter on the back end system.
Author: DP Walker
Issue 1.0
3
SAPHE
2 Project Description & Objectives The purpose of SAPHE is to develop a novel architecture for unobtrusive pervasive sensing to link physiological/metabolic parameters and lifestyle patterns for improved well-being monitoring and early detection of changes in disease state. The project addresses both the design of telecare service strategies and the development of innovative technologies to deliver them. In the final stages, a complete system will be integrated and trialled with a Health Authority. Using the results of these trials, the value of this technology to sensing under normal physiological conditions combined with intelligent trend analysis will be demonstrated. This should open up new opportunities for the UK ICT and healthcare sectors in meeting the challenges of the demographic changes associated with the aging population. The stated project objectives are: •
To provide a pervasive health and social care model that is optimised for the aging population and patients with long-term conditions.
•
To develop new sensing and inferencing technology that permits early detection of frailty or changes in disease, and responsive changes to care plans.
•
To analyse detailed service needs and developments, including initial field trials in collaboration with primary health and social care providers.
To assess pervasive technology deployment strategies and services, and their potential commercial and economic impacts. Due to time constraints, the scope of the project aims to provide an evolutionary prototype rather than a model for commercial development.
Author: DP Walker
Issue 1.0
4
SAPHE
3 SAPHE Architecture
The common architecture from deliverable B1 describes the basic architecture for the home and mobile components of SAPHE. The central device, or home hub, is a mini ITX set-top box that supports several wired and wireless standards to allow connectivity to sensors, output devices and also to the Home Gateway that provides connectivity onto the internet and into the back end system. The mobile system is based around a mobile hub. This will be a small, simple, rechargeable connectivity device that is able to communicate with both body worn sensors and the home hub. These systems are presented in more detail in the following sections.
Author: DP Walker
Issue 1.0
5
SAPHE
4 Home Devices The home network looks like this:
4.1 Overview The centre of the home system is the set top box. This is a unit that includes connectivity to receive data from home sensors and the mobile hub, process the data, if required, and forward the data to the Home Gateway and onto the internet. The set top box is connected to a TV for display of information to the patient or to a visiting Community Matron. The Home Gateway is the key connection point from the home to the outside world. This may also provide home broadband and may supply a connection to a patient’s home PC, should he have one. The patient’s home PC is not considered part of the SAPHE system and will not be used as part of the trial. A broadband connection will be provided for the SAPHE trial. We will not piggy back on an existing connection. Patients will not be allowed to use the SAPHE broadband connection for personal use. The set top box receives sensor data from environmental sensors. These include ambient sensors such as PIR sensors, bed sensor, and weighing scales. The set top box will also communicate with other health sensors such as blood pressure cuff and the body worn sensors. Author: DP Walker
Issue 1.0
6
SAPHE
The concept of other permanent display devices such as an electronic photo frame were not included in the SAPHE trial.
4.2 Devices 4.2.1 Set Top Box & Display The set top box is generally referred to as the SAPHE Home Hub. It collects data from environmental or ambient sensors and body worn sensors (via the mobile hub) and uploads this data to the SAPHE central server via an OpenMQ Java Message Service broker and a secure VPN connection to the backend Cisco VPN server. The set top box may also have to do some sensor data processing although mostly it will simply upload the data via the Home Gateway. The motherboard currently used is EPIA CN 10000G (http://www.miniitx.com/store/?c=2#p1643). Spec summary: 1.0GHz Fanless C7 CPU; CN700 chipset; Supports up to 1GB on 240-pin DDR2 400/533 DIMM socket; 6 channel audio; Integrated Unichrome Pro graphics with MPEG-2 decoder acceleration and DuoView+ (simultaneous VGA and TV outputs). Rear Panel Connectors: PS2 Mouse & Keyboard; Serial; VGA; 4x USB 2.0; 10/100 LAN; S-Video; RCA S/PDIF or Composite Video (switchable output); 3x 3.5mm Audio (Line-out, Line-in and Mic-in, can be configured as 5.1 outputs). Board connectors: 2x IDE 66/100/133; 2x SATA with RAID 0/1; 1x 26 pin LPT connector (EPP/ECP); 20 pin ATX power; 1x DDR2 400/533 DIMM socket; 4x additional USB 2.0 connectors on single 15 pin header; F_AUDIO; F_PANEL; 1x PCI slot. The STB has a customized version of Ubuntu Linux 8.04 installed (http://www.ubuntu.com/) that boots from a read-only SD card, size 2GB. Only certain settings such as device addresses and usernames are stored permanently on the card so that they are not lost after a system restart. The STB will have a USB Bluetooth dongle. This is a class 1 device to allow connection to distant bluetooth sensors such as weight scales that might be located in the bathroom (scales also have class 1 Bluetooth). The dongle used is a LM-Technologies EDR Bluetooth adapter LM056, this particular model was chosen because if its extensive range compared to other class 1 Bluetooth dongles. The STB has WiFi, provided by a Belkin Wireless PCI 802.11G F5D7001UK card. The STB will have a ZigBee coordinator from Jennic connected to a USB port to communicate with the environmental sensors. The interaction with applications on the set top box will be via a IR remote control. The MiniITX casing being used (Silverstone ML-02) has a built-in infrared receiver and comes with a Windows Media Centre remote.
Author: DP Walker
Issue 1.0
7
SAPHE
The display used is the same TV that is already present in the patient’s home. It is expected that the TV will be a widescreen TV with SCART connections. The STB will connect via a composite to SCART to RCA adapter cable. If there is no available SCART socket on the TV we can either provide: •
SCART switch box – not preferred solution as STB is always on, manual switch is therefore required
•
DSUB-9 (standard computer monitor) cable between STB and TV, only if TV supports this input and accepts PAL (720x576) resolution on this input.
•
Provide additional widescreen TV, preferred solution. A 19” Philips TV can be provided (19PFL3403D)
The set top box will be always on and consumes around 15W. If the power connection is lost due to a power cut, the system will automatically start up and reconnect to the VPN when power is restored. A daemon on the set top box manages the VPN connection and will automatically reconnect whenever the VPN connection is dropped. To prevent data loss, sensor data is queued up in the local OpenMQ broker running on the set top box during the period when there is no VPN connection.
4.2.2 Home Gateway This will be provided by BT and provide an ADSL broadband connection to the internet. Access speeds are dependent on distance from telephone exchange. SAPHE will not require high data rates though, so this should not be a problem.
4.2.3 Secondary Display Device The SAPHE home system could have a secondary display device such as a digital photo frame or possibly a small LCD display with a Bluetooth SCART dongle. This was not included in the final system and is therefore not discussed further here.
4.2.4 Computer or Home PC The patient may have a computer in their home already. In theory this can be used by the patient to view their sensor data but the Patient User Interface was designed to run on the STB and be viewable on a TV, with a TV-type remote control.
4.2.5 Blob Sensor The blob sensor is an is a vision based sensor which is capable of extracting the image blobs or shape of the subject. From our previous study, it has been shown that the posture, gait and activity of the subject can be inferred from the blob, and the behaviour pattern can be derived accordingly. Through modelling the behaviour of the subject, abnormality in daily activity can be Author: DP Walker
Issue 1.0
8
SAPHE
detected and which can also be used as an indication of the well-being of the subject. The blob sensor is an integrated sensor which comprises of a stereo camera, an ARM based processor, and a wireless link. As extensive computations are required to process the visual information, a relatively powerful processor is required to process the images and inferring the behaviour patterns. To interface with the SAPHE system, a ZigBee wireless connection was foreseen in the blob sensor for sending the blob and inferred results to the set-top box. This component is not included in the SAPHE trial as the processing is too power hungry to be implemented as a small battery powered sensor for use in the trial.
4.2.6 Weighing Scales Bluetooth weighing scales are used in the trial. The scales might be located at a significant distance from the set top box to which the data is being sent. The Bluetooth is therefore class 1 and has a typical range of 20 to 30 meters in a building. Range can be improved by using a USB extension lead and positioning the Bluetooth dongle away from the back of the MiniITX computer. Power drain should not be an issue as readings are typically only taken once a day or week. The scales used are provided by Philips and are the same ones used in Motiva systems. They measure weight in pounds or kilograms and have a range of available languages for spoken instructions. The scales automatically connect to the STB after a reading is taken and upload the measurement (and any older queued measurements) in an XML message.
4.2.7 PIR Sensors PIR (Passive Infra-Red) sensors provide a reliable and low-cost means to monitor the general activity level (movement) within the monitored home environment. They are restricted in that they are unable to differentiate between different people (e.g. patient or carer) but provide a simple real-time indication of where movement is occurring within the home. PIRs are planned to be deployed within each main room/location within the home (one per room/location); this will enable patterns and changes in patient behaviour to be determined through appropriate analysis and/or visual representation especially within single occupant households. Typically six PIRs will be deployed covering: hall, living room, kitchen, landing, bedroom, and bathroom. The PIR sensors used are modified Visonic Discovery W and K-980W devices. Both units have similar specifications, the K-980W adding pet-immunity for animals weighing up to 36 kg. Further details can be found at http://www.visonic.com/VisonicHomePage.nsf/webW12BDetTable?OpenView For integration with the SAPHE system, the standard 433MHz radio is replaced with a Jennic JN5139-Z01-M00 ZigBee module with integrated ceramic antenna, powered by a 3.6V 2/3A lithium cell. The ZigBee module embeds a 32-bit RISC CPU which can execute 3rd-party code as well as the Jennic ZigBee stack. It also include a temperature sensor with a rated accuracy of +/-10 degrees C.
Author: DP Walker
Issue 1.0
9
SAPHE
The Discovery W and K-980W output three events: firing, tamper (i.e. case opened) and low battery, all of which are decoded on the ZigBee module.
Discovery W (ref Discovery W Installation Manual) and Jennic ZigBee modules.
The detector hardware is unchanged from the standard sensor and the field of view is shown in the diagram below. The distance of coverage can be configured to suit room sizes of anywhere between 3 and 15 metres long, and the sensitivity can be adjusted by setting the sensor to fire when either 1, 2, 3 or 5 horizontal detection segments are crossed. For the trial we configure all PIRs for room lengths of 3-8 metres and use the standard sensitivity setting of 3 segment crossings.
Author: DP Walker
Issue 1.0
10
SAPHE
Discovery W coverage pattern (ref Discovery W Installation Manual)
4.2.8 Door Sensors Door sensors provide a means for monitoring door openings and closings, which in turn are used to determine the potential entry and exit of a person from the monitored home. Door sensors are hence fitted to each entry/exit door within the home (typically two; front and back doors). A further door sensor will typically be fitted to the fridge to provide added information that may relate to the patient’s wellbeing. The door sensors use a standard SPNO magnetic reed switch of the type commonly found in domestic alarm systems. As with the PIR sensors, a Jennic JN5139-Z01-M00 module is connected to, and housed with, the switch unit. The magnet unit is mounted separately with an operating gap of < 8mm.
4.2.9 Bed Sensor Bed occupancy sensors from Tactex Controls (http://www.tactex.com) are used within the SAPHE system. These are a very sensitive fibre optic based device will an array of ‘Taxels’ (pressure sensors). The bed sensors take the form of a thin mat measuring 90cm x 25cm x 0.5cm (thick – 2cm thick at one end) which is non-invasively placed between the bed mattress and bed base (divan).The sensors provide an indication of bed occupancy as well as information on the movement (changing pressure patterns) of the occupant which is for quality of sleep analysis. The bed sensor continually monitors the pressure across the mattress and outputs a measurement sample message of 18 bytes every 30s plus a further similar message at every change of the determined occupancy status (bed entry/exit event). Communication of the sensor output is via Bluetooth (utilising a Tactex Bluetooth interface unit) to the STB. The interface unit is mains powered and in turn powers the sensor at 5 Vdc. The sensor data is analysed on the Network Platform using Tactex quality of sleep algorithms to provide the following sleep measurements: •
Sleep efficiency
Author: DP Walker
Issue 1.0
11
SAPHE
• • • • •
4.2.10
Sleep Latency Total sleep time Number of awakenings Wake after sleep-onset, and Bed exits
Other Sensors
These can include water sensors, electricity sensors etc. Due to the small amount of data (events) they send, they would connect via ZigBee to the STB. These sensors will not be deployed in the SAPHE trial.
4.3 Connectivity Home connectivity essentially is wireless wherever possible to facilitate neat and easy installation of devices. The cost is that wireless is more susceptible to interference problems, coexistence problems and also to snooping. Limiting the number of different types of wireless connectivity will help greatly with coexistence and interference. Bluetooth, WLAN and ZigBee all work at similar frequencies. They should all work together but may suffer degraded service. During testing of the SAPHE system, interference issues where noticed between Bluetooth and WiFi: the WiFi connection would stall whenever a Bluetooth device enquiry was performed. Adjustments were made to the software on the STB to prevent this from happening during the trial. There may be interference from other sources such as DECT cordless phones and GSM mobile phones, although they generally operate at different frequencies than any of the wireless technologies used within SAPHE system. If time allows this will be tested before the trial starts.
4.3.1 Security No system is 100% secure. Everything can be broken into, the only question is how much effort would it take to break in. The appropriate level of security has been implemented for SAPHE, to meet requirements for Caldicott Principles as defined in D10: SAPHE Trial Preparations and Approvals. Simple steps have been be taken to ensure that it is not easy to extract patient data. The SAPHE data does not contain any reference to a patient name or identity, all data is linked to a unique patient ID and only the professional carers are able to resolve this to a patient name. Patient confidence must be maintained. It is not the remit of SAPHE to explore new ways of implementing secure wireless communication systems in the home; this is being done in other projects. Bluetooth standard encryption is used, also for ZigBee. The Low Power Radio currently has no encryption capability, but the data is considered safe as the transmit range is so Author: DP Walker
Issue 1.0
12
SAPHE
short that someone would have to be very close to snoop the signal. Also the sensor data format is proprietary which also makes it more difficult for a malicious party to decode or interpret, even if they manage to snoop packets of data.
4.3.2 Bluetooth Bluetooth provides the main connectivity between the set top box and the mobile hub. The mobile hub employs a store-and-forward methodology and collects data from body worn sensors and periodically uploads the data to the set top box whenever the patient is within range (10 m). The Bluetooth on the set top box is also used to connect to Bluetooth enabled sensors such as weighing scales and blood pressure cuff. The Bluetooth radio on the STB is a class 1 (100 m) device which will allow connectivity throughout the home. The position of the Bluetooth dongle on the back of the STB severely degrades the stated performance (100-250 m): typically 20-30 m range is achieved inside buildings. Alternatively class 2 (10 m) devices may be used but this will limit where devices are placed.
4.3.3 WLAN WLAN is used to connect the Home Hub (STB) to the Home Gateway.
4.3.4 ZigBee & 802.15.4 The IEEE802.15.4 standard is a well adopted protocol standard for wireless sensor research. With its low power design, built-in data encryption, and support for different network topologies, it has been applied in wide range of wireless sensing applications. Compared to Bluetooth, 802.15.4 has a lower power and larger coverage due its ability to work with multi hop networks. It has a much shorter wake up time which is crucial for health monitoring devices. However, the 802.15.4 only defines the lower 2 layers of the protocol stack, application developers will require to implement the other layers to set up a sensor network for their applications. Based on the 802.15.4 standard, the ZigBee protocol is a newly emerging industrial standard for wireless sensing. Like the Bluetooth protocol, it defines all the protocol layers in the network stack, and application developers will only need to implement the interface to the ZigBee chipset to set up the network. However, ZigBee is a closed standard which is available only to its alliance members. As ZigBee only launched recently, there is only a very limited number of chipsets available with ZigBee built-in. In addition, the ZigBee is designed for general wireless sensing, although it has a provision for medical applications, the applicability of the standard to healthcare application is still uncertain. For the PIR and door contact switches used in the SAPHE trial system, ZigBee modules are used from Jennic (http://www.jennic.com/).
Author: DP Walker
Issue 1.0
13
SAPHE
5 Body Worn Devices The mobile network looks like this:
5.1 Overview The user may wish to leave the house and will therefore be out of range of environmental sensors. The patient therefore needs body worn, mobile sensors and some method for getting sensor data into the SAPHE system. The data collection device is the Mobile Hub which operates a store and forward data management system. It collects data from sensors which is stored locally and uploaded into the Home Hub when the patient comes in range (10 m) of the set top box. The patient may have several different sensors on his body depending on the condition(s) that the patient suffers from. These are connected to the Mobile Hub by the Philips Low Power Radio (LPR). There is also a use case that states that the Mobile Hub could connect to a patient’s cell phone over Bluetooth and from there establish a mobile link to the internet. This could be used as a data path for alarms. However as alarms are out of scope for SAPHE, this addition will not be made.
Author: DP Walker
Issue 1.0
14
SAPHE
5.2 Devices 5.2.1 Mobile Hub The SAPHE “Mobile Hub” is a body worn device that acts as a central storage repository for data received from the body worn sensors. The sensors do not transmit their data directly to the home infrastructure, but rather transfer it first to the mobile hub which aggregates the data and transmits it to the SAPHE network. This has multiple advantages:
•
Power saving: Each sensor only needs to transmit and receive data from around the body. This means that simpler lower power radio technologies such as the Philips Low Power Radio (LPR) can be used.
•
Mobility: Using a central storage unit on the body allows the patient to move freely around whilst still being monitored both inside and outside the home. This means that a shopping trip is no longer a data blackspot. When the user returns to the home the stored data is synchronised to the network via the Home Hub.
•
Pre-processing: The mobile hub is a more powerful platform and could perform some processing on the raw data received from the sensors. Also data from different sources can be combined to increase the accuracy of the reading.
The mobile hub consists of a microprocessor controlling two wireless transceivers, one for the local body area network (LPR) and one for synchronising to the infrastructure (Bluetooth). Additionally micro SD storage is included, allowing many months worth of data to be stored on the device. Finally a real time clock (RTC) is integrated into the hub, allowing the incoming data to be accurately recorded and later correlated with data from the other sensors. The circuit design also includes a charging circuit which allows recharging via a mini USB connection. The battery used is Li-Ion battery, 3.7v, 1230 mAh, and was chosen for its relatively small form factor and yet having a reasonable capacity. In practice the battery lasts 2-3 days. The whole package is enclosed in a standard black case from Hammond Manufacturing.
Author: DP Walker
Issue 1.0
15
SAPHE
Specifications: Microprocessor: Texas Instruments MSP430F1611 Real time clock: NXP PCF8563 Storage: Kingston 1GB Micro SD Bluetooth: Bluegiga WT12 module BAN: Philips LPR (see 5.3.2) Battery: Varta LIP 653450 UC 1230 mAh 3.7V Case: Hammond 1551K
5.2.2 Sensors 5.2.2.1
e-AR Sensor
e-AR stands for ear-worn Activity Recognition sensor. Through mimicking the function of human’s vestibular system by positioning a MEMS based accelerometer on the subject’s ear, the e-AR sensor can capture the detailed posture, gait and activity of the subject. In addition, apart from the accelerometer, an SpO2 sensor is also integrated in the e-AR sensor, which enables the sampling of the heart rate and the blood oxygen saturation of the subject meanwhile capturing the activities. Where SPO2 and heart rate are not required, an e-AR sensor with no SPO2 is provided. In tests battery life is about 7-8 hours. The specification of the e-AR sensor is as follows: -
Processor: TI MSP 430
-
Wireless transceiver: CC2420 [although this is replaced by the Philips low power radio solution in the trial]
-
Memory: 512K EEPROM
Sensors: SpO2, 3D accelerometer Batteries: 2xUnion Fortune 041528 Li-Polymer Batteries 5.2.2.2
ECG
The ECG is provided by Cardionetics and will be modified to include the Philips radio solution.
5.3 Connectivity Author: DP Walker
Issue 1.0
16
SAPHE
As the Philips LPR works at 868MHz, this will minimize interference with the Bluetooth, WiFi or ZigBee radio communication.
5.3.1 Bluetooth Ideally the Bluetooth radio would be class 1 to give extra range. This would allow the mobile hub to be connected whilst anywhere in the house. The Gumstix has a Class 2 Bluetooth module which has a range of 10m. The link from the Mobile Hub to the Home Hub should employ the Bluetooth Medical Profile which allows medical data to be transferred in a secure manner.
5.3.2 (Ultra) Low Power Radio For SAPHE, Philips is developing two low power radio solutions. The first is a single chip ultra low power radio (ULPR). There is significant risk that this can be developed in time and therefore for use in the trial a low power radio solution based around a Chipcon CC1000 was developed. This is known as the Lego Brick Radio (LBR) as it is roughly the size of a lego brick and has a power consumption of around 8mW. Both radios are designed specifically with low power in mind. For the trial the LBR is mostly used with ULPR being demonstrated in the lab as proof of technology. The wearable sensors will all contain LBR that send data to the centre of the star network in the Mobile Hub. LBR Specification (approx figures): •
Freq: 868MHz
•
Bandwidth: 19 kbps
•
20mW peak power
•
8mW average power consumption
•
Range: 8 m
•
Star network
•
Protocol: proprietary
Author: DP Walker
Issue 1.0
17
SAPHE
6 Common Software This section describes the parts of the SAPHE software that are common to all nodes. This will allow sensor interoperability and allow any SAPHE sensor to be used in any SAPHE system. SAPHE consists of a multitude of sensors each sending different kinds of sensor data over different radio links to a central point, the Home Hub. From here the data will be uploaded over a secure path on the internet to the central server. Some sensors will require higher bandwidth links, some will send data once a day and others may stream data in real time. Data may be stored on intermediate devices (Mobile Hub) and uploaded all in one go, or in multiple shorter bursts. This represents a complex environment. A common protocol is therefore needed to support the encapsulation of sensor data into packets for transmission to the Home Hub and beyond. The software that bundles data into packets and attaches the appropriate labels should be common, where possible, to all SAPHE nodes.
6.1 Common Sensor Protocol A common data protocol was adapted for all sensors, so that a back end system may receive and correctly interpret data from current SAPHE sensors and any as yet unknown sensors to come. The SAPHE common protocol is based around 2 components: SAPHE binary data in XML and the SAPHE transmission protocol as seen in the figure below:
SAPHE binary data in XML is based on the BinX protocol (www.edikt.org/binx) while the SAPHE transmission protocol is based on SCTP chunks. BinX is a way of describing binary data in XML. This allows each sensor to transmit its data in a binary – and efficient – format but still allows access to XML like data on the backend. In order to do this, for each sensor the SAPHE backend database contains a set of descriptors. These are BinX based XML descriptions of the data format in which each Author: DP Walker
Issue 1.0
18
SAPHE
sensor sends its data. An example descriptor for the Mobile Hub that forwards e-AR data on port 1 is listed below:
Sensors can have multiple unique ports to transmit their data on, e.g. port 0 can be used for debugging messages and port 3 for data. A process on the backend server will parse the XML descriptors and transform the binary data stored in the database into the required output, e.g. into XML or human readable database values. The advantage of this way of storing the data is that the binary data can be efficiently transmitted and stored, while the BinX descriptors allow anyone at a later date to understand the data format of each sensor, even when new sensors are added or data formats are changed. The binary payload messages from each sensors are encapsulated in SCTP based ‘chunks’. Chunking allows each sensor to transmit payloads that exceed their maximum packet size. The SAPHE transmission protocol assumes that the underlying network connection is configured and packets have the following format:
Where user data is the BinX based binary sensor data. The sensor addresses is inserted on the STB in the SAPHE trial system. Sensors such as scales, blood pressure cuff and mobile hub will transmit their data with a relative timestamp, that is converted to an absolute timestamp on the STB. To ensure accurate timestamps, the STB runs a Network Time Protocol (NTP) client. Author: DP Walker
Issue 1.0
19
SAPHE
7 Back End System
The backend system is hosted within a testbed facility at BT Adastral Park. An IPsec VPN secures communications with the set-top boxes, and is also used for connectivity between partners and system administration purposes. The Community Matrons’ website is available over HTTPS. The platform is secured behind a CISCO ASA 5510 Security Plus Appliance (ASA5510SEC-BUN-K9) which provides a firewall and manages the VPN. Replicated master and slave MySQL Server 5 instances host the trial database. The database contains raw sensor data, analysed data, system configurations, and user accounts and privileges. The database is remotely replicated over the VPN by both Philips and Imperial College. Each sensor logging application on the set-top box is a JMS client. Within the trial, Sun Java System MQ 4.1 is used as the JMS provider, and broker instances are deployed on the backend platform and each set-top box. The software provides persistence, allowing for network or VPN outages. At the backend, GlassFish Application Server hosts an application which logs from the local MQ broker into the MySQL master database, providing distributed transaction management across both resources. The Community Matrons’ website is hosted on IIS. Its pages can be divided into two categories: those which decode and display the raw (BinX) sensor data directly, and those which rely on the data having been preprocessed. The raw sensor data is essentially real-time, while the preprocessing algorithms run as an overnight batch job and insert their output into dedicated (and algorithm-specific) tables in the database.
Author: DP Walker
Issue 1.0
20
SAPHE
The Community Matron website has been scripted using ASP.net and utilises Dundas Chart.net to provide data graphs. To comply with ethical and Caldicott Guardian approvals regarding patient and user data confidentiality all data within the SAPHE system is anonymous with no patient or user (i.e. Community Matron) identifiable information nor any personal information held.
Author: DP Walker
Issue 1.0
21
SAPHE
8 Continua Alliance http://www.continuaalliance.org/ It is important the SAPHE adheres to existing standards. There are many standards in TeleCare and deciding which to adopt is an important decision. For a Health Institution to adopt any system, especially a new system, it needs to have confidence that the system will behave as promised. And also that the provider will be still around in 5 years time. One way of ensuring this and also providing interoperability, is to comply with existing standards. But which ones? The Continua Alliance exists to help solve this problem. It does not define standards but ratifies existing standards for Health and Wellness, Elderly Monitoring and Disease Management. Philips and BT are both members. Bluetooth and Bluetooth Medical Profile are being adopted by Continua. Proprietary radios such as the Philips low power solutions are not ratified and will not be as they are not official standards. However if the link between this network and the home hub is via a Bluetooth Medical Profile then that is supported within Continua. And this is the case with SAPHE in that body worn sensor data is sent to the Home Hub over a Bluetooth link.
Author: DP Walker
Issue 1.0
22
SAPHE
9 Reference Document Appendix Saphe D07: System Technical Specification, Issue 2.0 Saphe D04: Common Node Architecture DiscoveryW_English_Installation_Instructions.pdf http://www.visonic.com
Author: DP Walker
Issue 1.0
23
SAPHE
10 Document History Issue
Date
Author
Comments
Draft 0.1
17/12/08
DP Walker
first draft for release for comments
Draft 0.2
19/12/08
DP Walker
Input from dennis, rob, tom, nigel, raza, benny
Release 1.0
15/01/2009
DP Walker
First release version
End Of Document
Author: DP Walker
Issue 1.0
24
