project requirements definitionubimon.doc.ic.ac.uk/saphe/public/saphe_requirements... · web...

Top Level Requirements

SAPHEIssue: DRAFT 1.0 Document Reference: Milestone 1Date: 17/06/2006

SAPHE Top Level Requirements

1. Introduction 3

1.1 Project Description & Objectives 3

1.2 Scope 4

2. Overall Description 6

2.1 Design Goals 6

2.1.1 Trust, Security and Privacy...............................................................6

2.1.2 Service User Involvement.................................................................9

2.1.3 Wider Applicability............................................................................11

2.1.4 Other Stakeholder Involvement......................................................15

2.2 Assumptions 15

2.3 Constraints 16

3. Condition Related Requirements 17

3.1 Section Overview 17

3.2 Requirements relating to all conditions 18

3.3 Requirements relating to Chronic Heart Failure 20

Sensing Requirements.................................................................................... 21

Condition management................................................................................... 24

3.4 Requirements relating to diabetes 25


Condition management................................................................................... 26

3.5 Requirements relating to asthma/COPD 27


Condition Management................................................................................... 29

3.6 Requirements relating to dementia 30

3.7 Requirements relating to homecare of the elderly 32

4. Interface Related Requirements 34


4.2 Requirements relating to service user interfaces 34

4.3 Requirements relating to professional carer interfaces 37

4.1 Requirements relating to informal carers 42

5. System Related Requirements 44


Milestone 1 Issue: Draft 0.2 1


5.2 Requirements relating to application interoperability 45

5.3 Requirements relating to common node 48

5.4 Sensor related requirements 53

5.4.1 Requirements relating to the home gateway and LPU................53

5.4.2 Requirements relating to body sensing.........................................54

5.4.3 Requirements relating to environmental sensing.........................57

5.5 Requirements relating to service deployment 62

Context of operation........................................................................................ 62

Technical Design............................................................................................. 65

Installation........................................................................................................ 66

Training............................................................................................................. 68

Integration with existing services...................................................................69

Supply and management of equipment........................................................70

Alert handling................................................................................................... 71

Telecare Service.............................................................................................. 73

6. Requirements relating to data analysis 75

7. Good Practice Related Requirements 86

7.1 Requirements relating to legal 86

7.2 Requirements relating to ethics 87

7.3 Requirements relating to health and safety 90

7.4 Requirements relating to trial design 92

8. Appendix 96

8.1 Issues and concerns 96

8.2 Hardware design considerations 104

8.3 Software design considerations 105

8.4 Material pulled from service user interface section 109

9 Reference documents 115

10 Glossary 118

11 Document History 120



1. Introduction

1.1 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 chages 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.



1.2 Scope

This document is the first milestone for the SAPHE project and pulls together the

top level project requirements submitted by the project partners. The scope for

the document has been broad to encourage the flow of ideas and content from

the project partners. This document is the first step towards the detailed

requirements which will be published as SAPHE deliverable D02 “Service and

End User requirements”. It is anticipated that the bulk of the content included

here will be in D02 but as the project progresses the requirements will be refined

and evolved into clear and specific requirements.

As the first milestone in the project this document has also had a role to play in

uncovering issues and concerns of the different partners. From the perspective

of openness and transparency the main issues raised have been included in this

document (currently some remain in the main document but once contemplated

all issues will all be condensed and moved to the appendix).

Conditions for Monitoring

Agreement on a set of target conditions for monitoring was reached through

discussion with the SAPHE trial collaborators, Central Liverpool PCT. It was

agreed that the system developed under SAPHE should be capable of

monitoring the following priority conditions:

Chronic Heart Failure

Asthma/COPD

Diabetes

Dementia

Homecare of the elderly



These conditions provide a necessary focus but still cover a broad range of

potential service users. The condition “Homecare of the elderly” is a particularly

broad category which may need to be further qualified as the project progresses.

Trial Scope

Within the SAPHE project it is planned to undertake a field trial with a limited

number of service users. The use of a small number of users presents the

opportunity to further restrict the scope of the requirements. For example: it is

unlikely that the provision of real-time alarms for instances requiring immediate

assistance will occur as part of the trial; or that the service will cater for a broad

range of language requirements. These possibilities should be acknowledge in

this document however as the document aims to explore the top level

possibilities for a SAPHE-type architecture rather than to define the specification

of the trial system.

Development Level

The SAPHE project aims to develop a system suitable for a field trial, this will not

be a commercial system but a prototype designed to act as proof of concept for

the approaches developed in the project.



2. Overall Description

2.1 Design GoalsThis section contains the top level design goals which span the subsequent

requirement areas and are intended to act as guiding principles throughout the

project. The design goals highlight general areas for consideration and discuss

the issues associated with these.

2.1.1 Trust, Security and Privacy

Sensitive and emotive issues may be encountered within SAPHE and it is

important that the areas of trust, security and privacy are embedded in the

project requirements. This section discusses design goals in these areas.

Improve Level of Care

From the perspective of fostering trust from the service user it is important that

the primary function of the SAPHE system is to improve the level of care

available to them. It is possible that service users could view such a monitoring

system as existing to gather evidence to act against their wishes, for example to

move them into a nursing home from their own home. It is therefore important

that the service user is assured that the system exists to provide an enhanced

level of care for themselves rather than to benefit of the service provider.

Management of Stakeholder Expectations

Whilst, the system must inspire trust from the clients and carers alike, all

concerned should also be made aware of the limitations of the system. The

responsible management of stakeholder expectations is required to ensure that

too much faith is not placed in the system. This concern has been raised in the

literature [Miller et al. 2002] which has discussed that the worst of all the



possible outcomes is for the deployment of a system which claims more

responsibility than it can reliably provide. This may lead users to place an

inappropriate level of faith in its capabilities and could potentially lead to

catastrophic outcomes.

Related requirements: Training requirements (R5.53)

Minimise False AlarmsThe system must be reliable, accurate and adopt a clear and consistent

approach to alarm or alert generation. When referring to community alarm

systems, Haigh et al. noted [Haigh et al, 2005] that :

"...Emergency personnel told us that panic buttons result in many

false alarms. For instance, an older client may wear a panic button

to bed and trigger it while turning in bed. Research has shown that

false alarms cause responders to discount the urgency of the

alarm over time. Therefore, any alerting device should be reliable

and accurate, and minimize false alarms..."

Which is similar to other stories e.g. Tunstall installations.

Experience from the Liverpool Pilot has suggested that, within the Pilot, there

was some value in false alarms as they can provide an element of reassurance

to the service users. Confirming that the system is working and that “someone is

watching over me”. Counter to this Liverpool pilot also saw one service user who

objected to any false alarms whatsoever. As a design goal we should aim to

reduce any false alarms as the ‘role’ of false alarms in providing reassurance

could be better handled through some other mechanism. For example,

scheduled carer contact, the push of education material, reminders etc., or

simply a periodic ‘Are you ok?’ IVR telephone call.

When setting alarm sensitivity a balance will always exist between the probability

of false negatives and the risk of false positives and for reasons of openness

and transparency this should be formalised using a loss function.



Issue: Need reference to “other stories” if the reference to Tunstall is to remain

in the document. Dundee please supply.

Respect User PrivacyHealth and social care monitoring may involve confidential information and it is

paramount that user privacy is ensured at all times. Within SAPHE a policy

needs to be developed around the five broad areas of information processing:

how information is Held, Obtained, Recorded, Used and Shared (HORUS).

The sharing of information through data visualisation and reporting techniques is

a particular concern as it needs to be ensured that only trusted people have

access, and then only in a secure manner, for example using encrypted

channels. There will also be different users will require different levels of access

and this also needs to be taken account of by the system. The medical field has

strict controls (e.g. Caldicott guardians) for managing patient data and within

SAPHE it will be necessary to understand these controls and how they map to

social care. Relevant documents for identifying the necessary safeguards will

include the “NHS confidentiality code of practice” and the “Social Care

Information Governance Project”.

Related requirements: Data analysis (R7.1, R7.3), common node (R5.17),

legal, standards (R7.13), trial design, interfaces

Service User Passive

The system should be designed such that the service user may be passive. To

ensure the system developed under SAPHE is as widely applicable as is

feasible there should a minimum level of functionality which can be provided

without placing any demands on the service user. It has been discussed

elsewhere, for example with regard to hip protectors [Parker et al. 2006], that

technology will be ineffective if it requires a level of compliance which the user

does not or can not attire to.

Designing a system which is service user passive should not be at the expense

of missing the opportunity to involve a service user in the management of their



own health. The SAPHE system should be open to, and encourage, involvement

of the service user if they are receptive to the concept. This is discussed in

section 2.1.2.

2.1.2 Service User Involvement

Throughout the SAPHE project the needs of the service users should be

paramount. This aspiration is reflected in the following design goals.

Appropriate Guidance

A crucial aim of the SAPHE project is to create a service which meets genuine

needs within the health and social care domain. One method of ensuring the

SAPHE project creates a service which meets the service user needs may be

through consultation with organisations which represent individuals with certain

conditions. For example, the British Lung Foundation represents everyone

effected by lung disease. The design goal is for the SAPHE partners to seek

appropriate guidance when possible to ensure alignment between the project

and the needs of real service users and carers.

Respect for Service User PreferencesThe service user should feel in control of the system and any preferences

expressed by them should be respected. This is particularly relevant to false

alarms: Studies [??? (can't remember which it is just now)] have reported

instances where the telecare service user was concerned about the raising of

alarms. This was due to them knowing that they they fell a few times a day, but

these were mostly minor, and they did not want all these instances to be

reported to their relatives for fear of being moved from their home. In this

instance the user only wanted the serious falls to be raised as alarms. Thus, the

guidance for SAPHE is that the system needs to be able to make intelligence

decisions based on service user preferences.



Caution does need to be exercised here though as the suggestion could be seen

as withholding ‘evidence’ from the care providers, which could reduce trust in the

system. The Liverpool Telecare Pilot made use of interactive voice response

(IVR) calls to the service users to allow them to cancel alarm situations if they

did not require assistance. Thereby, preserving the service user’s control of the

system but without failing to flag situations of concern.

ISSUE: Missing reference. Dundee please supply

Flexible Service ProvisionThe monitoring service provided needs not only to be appropriate to an

individual in general but also appropriate to the needs of an individual at a

specific point in time. The care provider should have the ability to set the

sensitivity of the system for an individual – for instance periods of ‘close

supervision’ may be needed post-operative. Overall the system must be fair and

equitable and any sensitivity adjustment must be via a managed process (e.g.

through utility value setting) rather than via human ‘tweaks’.

Avoid stigmatisingIn the findings of the ILSA project [Haigh et al. 2005] it was noted that:

"...one older participant reported not using a walker outside her

home because for her, it was a sign of disability and made others

aware of her frailty. More recently, [Gallagher et al] has shown that

feelings that assistive devices are stigmatizing are not uncommon.

Thus, if possible, any device should not be conspicuous enough to

suggest a handicap..."

The design goal within SAPHE is to create technology which is as unintrusive as

is realistic. In this way the dignity of the service user can be maintained and

stigmatisation avoided. An example might be to design environmental sensors

which avoid ‘blinking lights’ when in operating mode, as these may act as a

constant reminder that to the service user that they are being monitored. This



should, of course, match with the preferences of the service user who may

prefer such a reminder.

Related requirements: Environmental and body sensor design, LPU design.

Promote Education and Lifestyle Change

Rather than simply providing a basic monitoring system where possible the

service should aim to maximise the involvement of the service user in the

management of their condition. This may be aided by the provision of

educational content with context related selection, download and display of

educational information relevant to the condition. For the conditions under

consideration in SAPHE education and lifestyle change are likely to be important

aspects in condition management.

Issue: I (Dundee) think this is a really important requirement particularly for

people with chronic conditions, but more needs to be written down. Also who is

going to generate the education material. Is this realistic within the project

scope? Who would supply content? Ensure it is accurate? Cardionetics please comment.

2.1.3 Wider Applicability

This section describes design goals related to the ambition of the SAPHE

partners to develop a system which has the potential to go beyond a research

project and towards a commercially viable proposition.

Cost Functionality Balance

One factor contributing to the commercial exploitation potential of the system

developed under SAPHE will be the cost of the system. In the literature Miller et

al. [Miller et al. 2002] commented:



“Designing an affordable system. Previous IDS (Interaction Design

Systems) developments have relied on industry or military funding.

Home-based, elder support systems may have to rely on individual

homeowners or caregivers. To realize their full social and

economic benefits, such systems must leverage existing structures

and appliances of older, possibly antiquated homes. This

challenge requires developing unique reasoning components that

can analyze situations based on the inputs of a variety of low cost,

off-the-shelf sensors—not expensive, specialized hardware.

Furthermore, the developed system must enable an inexpensive,

easy, and quick installation of hardware, software and knowledge

based components, and also must include methods for ongoing

adaptation of those components to the changing needs and

situations of the client.”

In general hardware costs within SAPHE should be minimised to make the

system attractive to the cost sensitive care market. This does not mean ruling

out expensive devices, but considering the value which can be provided by a

particular sensor. Hence, a balance is required between cost, the overall

reliability of the data generated and the functionality of the system.

Issue: At what point are we going to tackle the issue of cost? – setting a target

cost or upper limit? Hannah/Oliver Wells please comment. (Thoughts: This

may not be the right train of thought for a research project - as setting a target

cost implies the cost of our in home kit equals that of a commercial proposition

and although the two are related this constitutes more of an exploitation issue

than a research issue. Although I do agree it would be nice to have an indicative

cost at the end of the project)

Flexible Functionality

The system must be designed to allow different functionality to be provided to

different service users. Different individuals may have different monitoring



requirements, for example different comorbidities, and the system should be

sufficiently flexible to be able to cater for this. The ideal approach would be a low

cost basic platform and modular functionality which can be added at additional

expense to create a system meeting the specific needs of an individual.

It is essential that the various stand alone applications developed within SAPHE

can become sub-sections or objects running within the major systems. For

example, specialist intelligent agents and applications developed by partners to

produce various medical visualisation user interfaces should be able to run

within larger system environments. This would enable, for example, specialist

ECG analysis and display routines to be viewed by users when looking at

cardiac issues for a patient.

ISSUE: As stated this is an architectural issue. Maybe the requirement means

“System Architecture that allows third part to integrate their own applications”? –

open architecture?

Response: It is an architectural issue but I think it was intended to refer to being

able to offer different levels of service, eg COPD monitoring or COPD +

Asthma…. I’ve reworded to try to reflect this but open to suggestions.

Philips/Imperial please review

Sensor Selection

Within SAPHE there is a design goal to develop the best system possible, given

the constraints of the project. To meet this goal best of breed sensors should be

used which requires that the sensors chosen for use have been carefully

selected based upon a number of criteria. These criteria will include: what we

want to observe; the type of data we want to collect; the position of the sensors

and the accuracy of the sensors.

The “Care in the Community” (CiC) project considered numerous environmental

sensors and demonstrated that it is practical and useful to monitor the following:

a. General activity patterns

b. Sleeping at night in bed



c. Leaving/returning home

d. Visitors

In order to monitor these activities the following sensors were required:

PIR in every room

A reliable front door contact switch sensor

Bed contact switch sensor

Bed vibration sensor

The types of sensors used in CiC are consistent with those utilised in other

projects, e.g. Ohta et al. [Ohta et al 2002]. The study by Ohta is particularly

interesting as they were able to detect an individual's patterns of movements

between rooms, and thus deviations from normal, by using solely PIRs. The

PIRs they used were bespoke, but the fact that they had success using a single

sensor type is noteworthy. Features of the PIRs used by Ohta et al. are

documented in their paper, for example: they are on when heat source in view,

and switch to off when source out of view or when 10 s has passed.

The Ubimon and Ubisense projects have also considered environment and body

sensors. The gap analysis work package within SAPHE will need to look at the

output from these and also other sensors suggested by the literature, for

example: medication adherence/reminders [Mynatt et al. 2000; Soderlund, 2004

(refs 32-41)]; communication/video conferencing [Mynatt et al. 2000; Soderlund,

2004 (refs 42)]; asthma / breathing difficulties via phone [Kondo 1992]; health

physiological symptoms [Inada 1992; Soderlund 2004 (refs 43-48)]

Issues: This section is basically a list of questions at the moment! Could Steve Brown please comment on sensornet output and could Imperial Please

comment on Ubimon, Ubisense output.

Response: comments from Steve added. Imperial please comment on your

projects.



2.1.4 Other Stakeholder Involvement

Stakeholder InvolvementWithin the project there are a number of different stakeholders and user groups,

all of which need to be identified and engaged with. The range of possible users,

includes: the service users, their carers (professional & informal), call centres,

GP/nurses, pharmacists, researchers. Whilst documented here, as one of the

design goals of the project, an exhaustive list is beyond the scope of the current

SAPHE work package. The exploration of the different stakeholders, together

with their demands and needs, will be addressed within the SAPHE work

package WP4 “Gap Analysis”.

Related requirements: User interfaces, service deployment.

CollaborationThe SPAHE system should encourage and support collaboration. The need to

support multi-disiplinary teams (MDTs) was a requirement which emerged from

the requirements capture workshops held with the PCT in Liverpool. Information

sharing across specialisms was identified as necessary to avoid the problems

associated with stove-piped condition centric care.

Within SAPHE the telecare solution developed will straddle both Health and

Social care. This is aligned with the political agenda for integrated care and

requires consideration of the practical implications of this.

2.2 AssumptionsThe assumptions that are fundamental to the success of the Project and are outside the control of the Project manager and the team must be stated. Avoid listing `everyday' problems that have to be managed. Assumptions should be revisited at the end of each phase to check they are still current and to reassess the Project if there have been changes.

Examples of assumptions:

the annual rate of inflation will not exceed 8%



no government restrictions will be imposed no change in organisation of PCT and Social Services structures no change in personnel on the project

ISSUE: I Still need to complete this section. Andrew Reeves to review. Hannah/Oliver if you have any thoughts for the project plan please feel free to contribute

2.3 ConstraintsA constraint is a significant factor imposed on the Project team or specification and it is a mandatory condition within which the Project has to be managed.

Examples:

external regulations and standards maintenance of existing services without disruption use of proprietary hardware from specific suppliers fixed timescales. Fixed resources? Recruiting a co-operative patient cohort? Attaining statistically significant patient populations in each disease class?

Defined within the level 2 project plan.

ISSUE: I Still need to complete this section. Andrew Reeves to review. Hannah/Oliver if you have any thoughts for the project plan please feel free to contribute



3.Condition Related Requirements

3.1 Section Overview

The condition related requirements has been sub-divided into:

- Requirements relating to all conditions

Several of the condition related requirements may be applicable to all the

different conditions. In this section these broad ranging requirements are

described.

- Requirements Relating to chronic heart failure

This section contains requirements related to the detection and early warning

of cardiovascular changes, to understand what levels of data can be

provided and how this might be used to develop protocols for timely

intervention. There is also a requirement to better understand issues

surrounding patient compliance and the link to successful outcomes

- Requirements relating to diabetes

On of the key challenges faced when managing diabetes is that, as the

condition has few obvious symptoms, motivating self-management can be

difficult. This section focuses on the sensing and condition management

requirements but it should be acknowledge that the need for “affective”

service user interfaces is also high for this condition.

- Requirements relating to COPD/Asthma

Managing COPD/Asthma presents unique challenges particularly in the area

of medication. As service users can administer medication when they feel the

need to alleviate symptoms, medication usage is a key metric for monitoring.

This section describes the COPD/asthma specific requirements.

- Requirements relating to dementia



- Requirements relating to homecare of the elderly

This section contains requirements related to the health and well-being

monitoring of elderly people, this is not specific to any condition, but covers

general issues such as activities of daily living and falls. Whilst, some of

these are referred to in the general requirements section, it is likely that more

detail would be required if this was the main condition for monitoring. Hence,

this section has been included to provide that detail.

3.2 Requirements relating to all conditions

R3.1 Statement:We need mechanism to support appointment reminders.

When managing all of the conditions under consideration in SAPHE

appointments with health care professional will occur. To be of most benefit to

an individual a telecare system should be able to support the appointment

schedule through the issuing of reminders.

For example a service user with diabetes should have their feet regularly

checked and at least once a year looked at carefully by a trained healthcare

professional. Further to this their eyes will need annual retinal photography and

the SAPHE system should have a reminder mechanism to ensure such multiple

checks are made.

R3.2 Statement:The system shall provide medication reminders to the service

users through an appropriate interface.

Medication reminders should be programmed by the care providers and may be

issued to the service user through mechanisms such as; an IVR telephone call,

SMS, in-home device etc. Ideally such reminders should only be issued if a

medication has been missed, see R3.3.



R3.3 Statement:The system may be able to monitor medication compliance.

This is a higher level requirement than the previous (R3.2) and is to monitor

medication compliance. If implemented then it could be part of the integrated

approach describe above. To monitor medication compliance an instrumented

pill dispenser may be necessary.

R3.4 Statement:The system may provide information relating to changes

required in medication regime.

This is linked with the other medication compliance requirements but highlights

that the care provider will make changes to medication regimes and this needs

to be captured within the system.

R3.5 Statement:The system may be able to detect side effects to medication

changes.

This also relates to an aspect of data analysis and the need to fuse medication

related information with medical and behavioural changes.

R3.6 Statement:The system may maintain a record of all care events.

Ideally the system should have, or be able to access, a record of all care events.

This may be realised through integration with existing care provider systems.

Issue: Needs development. What forms are we thinking of? All please comment.

Response: Requirement more fully explained.

R3.7 Statement:The system may monitor general activity levels.

A number of studies have indicated that general activity levels, for example

simply PIR sensor events, can be a useful parameter for monitoring.

ISSUE: References needed. Andrew Reeves to gather



R3.8 Statement:The system may monitor compliance with a specific exercise

regime.

Monitored exercise could be used as part of a lifestyle change, and once- or

twice-weekly controlled activity might generate useful data. For example,

treadmill tests may be used for the assessment of cardiac function.

Issue: What is the clinical need – is it desired or needed? Cardionetics comment pleaseResponse: Note this has been rephrased and split into two - The monitoring of

general activity levels is one requirement and a second (optional?) requirement

may be to monitor compliance with specific exercise regimes.

R3.9 Statement:The system may encourage education

Educational notes and advice is required to encourage people to take their

condition seriously. Diet advice and quiz questions (for example) needed to draw

patients into using the system.

ISSUE: We are trying to do too much here and we need to scope the project

more realistically. Designing quizzes is clearly out of scope! Hannah/Oliver Wells please confirm.

R3.10 Statement: The system may be able to monitor changes in well-being or

quality of life.

Looking at issues such as mobility, ability to cook, depression, anxiety

ISSUE: This can be more fully discussed. Steve Brown/Andrew Reeves please

review.

3.3 Requirements relating to Chronic Heart FailureHeart failure is a general term for degeneration of the heart function where

insufficient blood is pumped around the body, and excess fluids begin to build



up. Symptoms are usually shortness of breath, a feeling of tiredness and one of

the signs is swelling at the ankles.

There is no specific diagnostic test for heart failure, but three tests can be

performed:

ECG tests, checking for rhythm disturbances or other causes of

inadequate activity

Echocardiogram or X-ray examination of the lungs to confirm fluid build-

up and eliminate lung disease as the cause of the symptoms

Possibly a blood test, for the presence of hormones that indicate heart

failure.

Of these tests, within SAPHE, ambulatory or in-context monitoring is restricted to

ECG, because of the availability of portable equipment for this test.

Sensing Requirements

R3.11 Statement: The system must be able to carry out ECG monitoring.

The requirement is for periods of up to 24 hours of continuous ECG monitoring

with analysis capable of detecting and reporting abnormal beats and disturbed

rhythms. Abnormal beats includes ventricular beats and premature atrial beats,

and rhythm disturbances includes tachycardia and bradycardia, atrial fibrillation

and pauses or loss of rhythm.

When managing such a condition monitoring ECG might be a two-weekly,

monthly or 3-monthly assessment, unless patients had a known disease state

that required more frequent monitoring.

ISSUE: Need to remember trust issues highlighted at the Liverpool workshops

regarding ECG monitoring equipment accuracy. Needs further explanation from someone who attended the workshop.



R3.12 Statement: The system must provide a method for monitoring blood

pressure.

- There is an additional requirement for monitoring blood pressure

simultaneously with ECG. Short-term rises in blood pressure associated with

the onset of exercise can be significant, and in the period after exercise,

whilst the heart rate returns to normal, monitoring can often reveal rhythm

abnormalities. There is an implied requirement here for monitoring exercise.

- BP could be monitored regularly, but this presents problems of variability, so

it may be better to take a number of readings and average them, or to closely

specify the conditions under which they are taken. Both hypertension (high

blood pressure) and hypotension (low blood pressure) can indicate a change

in disease state, so should be monitored. Again, a daily or weekly regime

could prove useful.

- During the SAPHE trial it may be sufficient to analyse data post-event, but if

real-time monitoring and analysis is required, wireless interfacing to the ECG

monitor could be considered as an additional feature.

R3.13 Statement: The system may be able to identify additional symptoms and

signs

Clinically, the presentation of symptoms, or the observation of signs are both

useful in identifying disease and monitoring its progress. Within SAPHE, the

emphasis is on observable signs, although the capability of user-generated data

in response to symptoms could be included. Signs of disease that can usefully

be monitored are:

- Oedema (fluid retention due to lack of heart function)

Both on-patient and remote sensors can be used, for example any

constriction on a limb, such as an elastic bracelet, or ring, will be

capable of detecting swelling caused by fluid retention.



Alternatively, weighing the person accurately can be used. You could

even simply ask whether the users’ shoes still fit, or are a bit tight!

Accurate weighing would require measurement without clothes, which

may be impractical. However, it might be possible to incorporate the

measurement into a daily washing regime.

Factors such as bodyweight could usefully be monitored daily, always

ensuring that this is carried out at the same time each day to avoid

diurnal influences. Sudden increases in weight could indicate onset of

oedema (fluid retention). Hence, sudden increases and decreases in

weight should be investigated.

- Cyanosis (blue skin discolouration due to a lack of oxygen in the blood)

Blood oxygen levels can be monitored using SpO2 techniques, but

non-contact techniques detecting blueness of the extremities are

possible.

Oxygen saturation levels could be monitored daily. Most SpO2

monitors are for continuous use in life-critical settings, whereas in the

home, a 30-minute reading every day would allow for long-term trends

to be established.

- Fatigue

Fatigue monitoring implies some form of monitored exercise

programme, so that longitudinal data can show overall trends.

- Possibly diaphoresis (profuse sweating). Note that diaphoresis does occur

during a heart attack, but can also be caused by other things, e.g. the

menopausal night sweats.

ISSUE: Are these self-monitoring devices suitable for use by elderly people?

Cardionetics please comment.



ISSUE: If a medication reminder system is going to be used to ensure

compliance, could we be enforcing a very regimented lifestyle?! Cardionetics please comment.

Condition management

R3.14 Statement: The system should be capable, even if not implemented, of

real-time monitoring ECG.

Real-time monitoring may be beyond the scope of the trial but one benefit of

real-time monitoring is crisis anticipation or detection. This is particularly relevant

in preventing falls in the elderly. Studies have shown that a major factor leading

to falls in the elderly is syncope and near-syncope (fainting and light-

headedness), often as a result of a lack of blood flow to the brain.

Temporary lack of blood flow occurs when the heart beats abnormally, and this

type of arrhythmia can be detected by ECG monitoring. In terms of disease

progression, it is possible to detect ‘silent’ arrhythmia, i.e. arrhythmia that as yet

do not cause symptoms, because they are not severe enough, but which over

time will degenerate and lead to symptoms such as dizziness. Detecting silent

arrhythmia early allows appropriate treatment, which can assist in fall

prevention.

Related requirements: Falls related to homecare of elderly

ISSUE: Falls are relevant to elderly section.Response: Inclusion in related requirements.

Regulatory requirements

Issue: Regulatory and standards material should be in appropriate section.

Response: Content moved



ISSUE: Could we have more for this section? Cardionetics please comment.

3.4 Requirements relating to diabetes

The key challenge with daily monitoring for Type 2 diabetes is that patients

typically do not have many obvious symptoms until it is too late. This means that

they do not see the need for daily monitoring. Even when compliance is initially

high, it drops off very quickly, as people are not motivated to make regular space

within their busy lifestyles for monitoring. It is only once the complications

caused by diabetes have set in that people find themselves more motivated to

seek advice and help.

Once diagnosis of diabetes has been confirmed there is a tendency towards

depression and lifestyle changes are always required. Some intensive short term

(3–6 months) monitoring is used alongside an education programme, both of

which usually take place under the care of the Acute Diabetes consultants and

the diabetes departments. The need for Telecare provision is higher during this

time period.

Type 1 diabetics are different, but as they have to manage their insulin levels on

a day by day basis, they learn to be very much in control of their condition, and

as such do not need additional management.

National standards on the treatment of diabetes were introduced through the

National Service Framework (NSF) for Diabetes: Delivery Strategy [Doh, 2003].

More recently a Department of Health report [DoH, 2006] has been produced

discussing the progress made in the treatment of diabetes since the NSF was

introduced. It comments that technology (including remote monitoring)

willincreasingly play a key role in enabling and promoting self care. A number of

commercial chronic disease management (CDM) platforms are avaibale to

assist with the management of Diabetes and the SAPHE partner BT is also

planning the commerical launch a CDM platform.

ISSUE: - Don't think usability is the right term in para 1

- Should be compliance or a word to that effect.



- Para 2 should start "Confirmed diagnosis…."

- There is no mention of the NSF on Diabetes

- Should there be some reference to the planned BT CDM tool

here?

Response: Have reworded this section, taking account of the above issues, could Docobo please review.


R3.15 Statement: The system must be able to interface to a range of 3rd party

monitors.

Monitoring for Diabetes includes

- Daily Blood Glucose (often multiple times per day)

- Either HbA1c percentage or the blood glucose level in mmol/L

- Blood pressure

- Weight

- Cholesterol – This is not yet a home measurement option, but we

need to make sure the system can capture the data

ISSUE: This needs further description, what possible monitors? What standards

do they operate to? Docobo please comment.

Issue: Medicaiton compliance is a general issue.

Response: Moved

Issue: Further explanation/development required. Docobo please comment

Condition management



R3.16 Statement: Support dietary management for diabetes.

- Patients need to discuss diet with a registered dietician. Dietary advice, and

appropriate literature, will be given to service users as part of their care plan

and the SAPHE service may have a role to play in reinforcing this.

- Need to record alcohol and cigarette intake

Issue: Are there any existing good electronic/interactive systems? Docobo please comment.

Issue: Further explanation required. Docobo please comment

ISSUE: Self-reporting would be subject to substantial Social Desirability Bias. Docobo please comment

ISSUE: Could we detect metabolites of alcohol and nicotine? For example,

cotinine for nicotine. Docobo please comment

ISSUE: Re appointment reminders - There are several features useful across

multiple conditions.

Response: Appointment reminders moved to general conditions section.

3.5 Requirements relating to asthma/COPD

One reference document it is necessary to consider is the COPD GOLD

standard, which has attempted to define how COPD and asthma are diagnosed

and managed. Additionally, the Secretary of State for Health announced in June

2006 that a new National Service Framework (NSF) would be developed to

assist with improving standards of care and increasing choice for patients with

Chronic Obstructive Pulmonary Disease (COPD).

ISSUE: Unclear what the GOLD standard is. Docobo please provide reference.



ISSUE: Should mention COPD NSF

Response: Included mention of COPD NSF. Docobo please review.


R3.17 Statement: The system must capture COPD relevant physiological

readings

Across the medical profession there are differing views on the data that needs to

be captured to be able to manage patients with COPD at home. In addition, it

has to be accepted that many clinicians trust certain makes and models of

physiological monitoring devices, such as blood pressure machines that have

been validated by the BP validation team at St Thomas’. It is therefore essential

that the system is able to interface to a range of physiological monitors from

various third parties. A recently formed consortium has been started with the aim

of standardising the data interfacing between various medical equipment.

Required physiological monitoring includes:

- Oximetery (SpO2)

- Spirometry (FEV1, FVC, and PEF)

- Weight

- Blood Pressure

ISSUE: “Across the medical profession there are differing views on the data that

needs to be captured to be able to manage patients with COPD at home”. What

are these views, could we have references or comment. Docobo please comment

ISSUE: Comment – Philips is a founding promoter of the Continua Alliance

Response: Philips membership of Continua Alliance referenced elsewhere

R3.18 Statement: Monitor other symptoms



The following lists the various symptoms that may need to be monitored

- Breathlessness. (Peak Flow may be useful here, as it is difficult to

self-report with any degree of accuracy)

- Wheezing.

- Coughing

- Sputum production and colour

- Changes in daily activities

The majority of this would have to be self-reporting given the project constraints.

For example, developing a stethoscope fro wheezing which could be used in the

home and sent a sound file to clinician might be possible, but it would consume

more resources than the project could provide.

Condition Management

R3.19 Statement: The system may monitor for changes in medication usage

made by the service user.

This differs from the generic requirement of monitoring for compliant to a normal

treatment regime. This requirement is to consider if the service user is changing

their normal medication usage. The following need to be considered:

- Has preventative medication been taken?

- Has extra medication been taken? (salbutamol/combivent)

- Were any side effects experienced?

R3.20 Statement: The service should be align with the philosophies of the

British Lung Foundation.



The British Lung Foundation represents everyone effected by lung disease, and

should be requested to comment and advise during the user needs analysis

studies, and also during the implementation of the trial work

ISSUE: Standards should be moved to appropriate section

Response: moved.

3.6 Requirements relating to dementia

Issue: This section is a first draft and needs development. Andrew Sixsmith to

continue development.

Table 1 is a simple matrix linking the target groups with key quality of life domains. This represents a high level “area map” of well-being:

Conceptual framework: The dimensions of the matrix represent the overall conceptual framework. target groups and well-being domains

Populating matrix. An intial attempt to populate the cells.

Prioritisation- it is unlikely that we will be able to do this in a quantitative way.

Issues related to old age in general are also relevant to people with dementia and need to be evaluated



Table 1. SAPHE well-being matrix

“Target” groups

General old age Dementia

Domain Sub-domain Example problems/needs Health and fitness Active lifestyle

Sleep

Illness Symptoms of specific illnesses in later life Diagnostic information supporting assessment process Monitoring the progress of the dementia over time Determining whether it is dementia (as opposed to depression or non-neurological conditions Determining sort of dementia- e.g. alzheimer’s, vascular type Distinguishing “stage” of dementia – general cog ageing, mild cog impairment, dementia (various stages)

Functional Limitations Stamina Balance Mobility etc

Cognitive functioning Conditions associated with dementia- Disorien-tation Forgetfulness Communication See classifications e.g. DSM-4 ICF

Depressive/ anxiety symptoms

Mood Restlessness Anxiety Paranoia Depressive symptoms Agitation

Person

Personal attributes Motivation Home Fire smoke flood

Temperature Security

Neighbourhood Threats from outsider the home- security Social network Isolation Social support Lack of help and support

Availability when needed

Services Services geared to user lifestyle

Context

Information Availability and use of information ADLs Feeding dressing etc Feeding dressing etc Lifestyle Healthy lifestyle Maintaining normal lifestyle – daily pattern “Positive” activities Hobbies Leisure

Meaningful activities

Negative activities Incontinence Boredom

Inappropriate behaviour- Aggression, disinhibition, properly dressed etc.

Risky activities Wandering Leaving house Leaving on gas etc. Self-harm

Social interaction Face to face Telephone e-mail

Activities

Health activities Exercise Experience

Not applicable- focus is on subjective experience and personal meaning However, this could be linked to ongoing researc

Well-being Positive emotional state Negative emotional state Pain Life satisfaction Self esteem

Participation

Outcome

Health

Difficult to instrument as focus is on subjective experience It may be possible to infer some of these from observable behaviour- e.g. dementia mapping However- this could be linked to ongoing research



3.7 Requirements relating to homecare of the elderly

R3.21 Statement: The system shall monitor the “well-being” of the elderly client

and report this information to the range of carers, and to the user.

The aims of well-being monitoring in the CiC (Care in Community) project were

to prevent acute problems, to inform the dialogue of care, contribute to improved

quality of life, and to detect long term patterns & deviations from them. The CiC

project developed the well-being conceptual model, which considers well-being

in relation to experience, activities, personal factors, contextual factors, and

outcomes [Brown et al, 2004; Hine et al, 2005]. Self-care is becoming a more

and more important political agenda and as such the monitoring data collated

should be reported to carers and the users themselves, particularly for patients

with chronic conditions. These philosophies and models should continue into the

SAPHE project and be evolved.

Within SAPHE if well-being indicators are presented to service users the

opportunity may exist to allow the service users to challenge the indicators

themselves which could provide valuable research data.

Self-care is becoming a more and more important political agenda and as such

the monitoring data collected should be reported not just to carers but to the

service users themselves. This is particularly important for patients with chronic

conditions.

R3.22 Statement: The system should monitor for changes in ability to perform

activities of daily living (ADLs).

ADL detection based on Katz index [Katz et al, 1963] covers transferring,

bathing, dressing, feeding, toilet, continence; also there is IADL (instrumental) -

seems to have been introduced by Lawton [Lawton & Brody, 1969], it covers

telephone, shopping, cooking, domestic work, laundry, use of transport,

medicine-taking, bills. These measures are used for judging whether the client is

capable of living independently.



The Domain Specific Modelling (DSM) part of the CiC project explored in detail

which of the numerous possible ADLs should be monitored in order to give an

indication of well-being. Six activities were identified as key indicators: leaving

and returning home, receiving visitors, preparing and eating food, sleeping,

personal appearance and leisure activities. These were then broken down to

consider the data capture, analysis, issues, sensor requirements [DSM

deliverables 2.1/3.1].

Issues: IT would be useful to get an indication of how widely used the ADLs,

IADLs are in the UK and are there any issues associated with them. Andew Sixsmith please comment.

ISSUE: Within SAPHE there is a reluctance to go over which specific ADLs

should be monitored for general well-being. This was explored in detail by the

CiC DSM project and this output should feed into SAPHE.

Response: Reworded to reflect significant work undertaken in DSM. Could Dundee please review.

ISSUE: re sensing requirements – this is not specific to elderly.

Response: Moved content to appropriate section under design goals and cost

considerations.

R3.23 Statement: The system should have the capacity to detect falls.

Falls is a major issue for the elderly and, whilst real-time alerting may not occur

in the SAPHE trial, the system architecture should be designed such that the

detection of falls could be integrated if needed.

ISSUE: Could do with digging out some more supporting references. Andrew Reeves to look at.



4. Interface Related Requirements


The interface related requirements are divided into:

- Service user interface requirements

This section contains requirements related to the design of interfaces

between the system and the service user. This section covers the

usability issues of interfaces reporting data to the service users.

- Professional carer interface requirements

This section contains requirements related to the design of interfaces

between the system and professional carers. The section covers issues

to ensure the timely and effective communication of relevant information

both to and from the service user in a secure form which is appropriate to

them.

- Informal carer interface requirements

Service users are often supported by a care network which, in addition to

professional carers, also includes informal carers. Typically these may be

friends, relatives or neighbours who have an interest in the users care.

Whilst SAPHE has a primary focus on professional carers there may be

benefits to providing informal carers with information. The requirements

relating to interfaces between these informal carers and the SAPHE

system are detailed in this section.

4.2 Requirements relating to service user interfaces



For the purpose of this document the “service user” is defined as the individual

being monitored, see glossary for further comment. This section contains the

requirements for interfaces with these individuals and subsequent sections

contain the interface requirements for all other users, termed carers.

The requirements given are relate to the potential target user groups but the

service users may also have unique age-related nuisances e.g.:

- Chronic Heart Failure

- Type II Diabetes

These conditions may impact upon the interface requirements.

ISSUE: re use of term service user - Although this is accurate, I think this way of

describing the clients and what telecare does could lead to upset, we need a

softer/nicer way of describing the service user.

Response: We should adopt the appropriate term used in the health and social

care domain. See glossary for definition.

R4.1 Statement: The usability and accessibility of the interface shall be

considered throughout the design process.

These considerations should enter the process as early as possible to avoid the

risk of increased costs due to retrofitting of the interface at a later stage.

Additionally, the design team are obligated under the Disability Discrimination

Act to take reasonable steps to ensure that any products and services do not

discriminate against an individual on account of a disability. Furthermore, these

considerations should be enshrined in the formal specifications to reflect the

commitment of project partners towards ensuring accessibility and usability.

Considerations include: Physical, Sensory, Cognitive and Attitudinal factors.

These can be discussed in more depth (and with reference to the system itself

as the design for this develops) in a Usability Requirements Document.



ISSUE: Did Dundee mean to pull the other material from this section? Dundee please comment.

ISSUE: If a usability requirements document is to exist clarification is needed as

the where this fits in the project plan. Hannah/Oliver Wells please comment.

R4.2 Statement: The interface and facilities of the service should operate in

support of and be consistent with any existing behavioural change programmes.

R4.3 Statement: The system should be able to provide the service user access

to services in a variety of settings e.g. home, office, mobile.

From the SAPHE trial perspective this may be limited to the settings used by the

trial participants. However, interface development should be with a multi-modal

philosophy in mind.

ISSUE: If it’s the client user, then it’s just likely to be home or mobile

Response: Re-worded to reflect comment.

R4.4 Statement: A process for issuing reminders (e.g. medication,

appointment, self-test, maintenance) to the service users could be implemented.

The general condition requirements covered the need for the system to maintain

appointment reminders. In this section it must be acknowledge that an

appropriate interface, or interfaces, will be needed. The interface may support

an escalation process which only flags missed reminders, or alerts, to carers.

This is aligns with the design goals which considered the need for service users

to be able to can cancel any alerts which they did not wish to be escalated. In

addition to condition management reminders the interface should also

automatically generate maintenance alarms/reminders (e.g. battery

changes/sensor failure).

ISSUE: Maintenance alarms/reminders should be automatically generated by

the system (i.e. battery changes/sensor failure)



Response: Section reworded to include maintenance alerts

ISSUE: re - Ability to disable alarms. Is this the right place for this?

Response: Moved to professional carers interface section.

See also sections in appendix.

4.3 Requirements relating to professional carer interfaces

ISSUE: This seems to only suggest professional carers. It should be important

to consider non professional carers separately as their needs are going to be

different.

Response: Additional section for informal carer interfaces added.

ISSUE: One that I can’t see here that I feel is needed, is a requirement for

interoperability with the various systems used by carers.

Response: This is reflected in the interoperability requirements section

R4.5 Statement: The relevant stakeholders must be identified and their specific

requirements considered.

The specific information access requirements must be considered for all of the

relevant stakeholders. These may include:

Users based in primary care

Community health staff

Residential and nursing home staff

Staff working in specialist units (e.g. cardiology)

Pharmacists

Once the relevant stakeholders have been identified the information

requirements of each stakeholder should be determined through engagement



with them. This includes consideration of the sufficiency of the data provided (i.e.

too much/too little) as relevant to the needs of each individual stakeholder.

ISSUE: This sounds as if we’ve decided what information there is from which

they can choose, rather than finding out what information they actually want –

though this knowledge should be within this requirements doc, but I imagine its

more likely to come via the gap analysis… for now I fear we’ll end up dictating

what data can be provided based on what we can monitor etc

Response: Section reworded to reflect concerns and specific issues highlighted

below.

ISSUE: Will identifying stakeholders form part of the gap analysis? Nigel Barnes please confirm.

Response: NB - Needs to be done – cuts across both requirements and gap

analysis. – now highlighted in appendix section on general issues/concerns.

ISSUE: This only covers professional carers

Response:Informal carers interface requirements section added

ISSUE: Consideration must be given to the sufficiency of data generated (too

much/too little) as relevant to the needs of each stakeholder.

Response: Reworded to include comment

R4.6 Statement: The interface should be accessible in a variety of different

settings and through a variety of modalities.

The carer may require information access in a variety of settings e.g. home,

office, mobile and through different information delivery vehicles. The method of

data retrieval may also vary between carers, for example, some carers may

want to be able to retrieve information by search, query, automated updates,

etc.

ISSUE: The modalities is needed to cover the notion of different vehicles for

information delivery; might also be worth explaining how some carers will want

to retrieve data in different ways – by search, by query, by automated

updates…,



Response: Incorporated into text.

R4.7 Statement: Usability should be integral to interface design.

Carer software should provide fast and easy access to relevant information.

Interfaces should be suitable for the intended audience and tailored to match

their requirements. This requires consultation with carers as early in the

development lifecycle as is feasible.

ISSUE: True, but see earlier comment that it really should be done at this stage.

Response: Included reference to as earlier a consultation as possible.

R4.8 Statement: The interface should make available the appropriate tools to

assist with the interpretation of data.

If large amounts of information are available then an intelligent searching

mechanism, together with summaries of the information, may also need to be

provided.

ISSUE: Needs clarifying

Response: More content added.

R4.9 Statement: The interface may be able to accept carer supplied content.

It may be necessary for content to be entered by carers for storage by the

system. Carers may also need access to modify information stored by the

system, e.g. carer contact details, or to annotate data to assist information flow.

Further to this it may be necessary to maintain an access log showing who has

accessed the data. Workshops with Central Liverpool PCT indicated that

ownership and responsibility of patient data was important when it passed from

department to department.

ISSUE: Yes, good. Also – should data that has been 'viewed' by a carer be

flagged as such? – This was discussed at Liverpool workshops i.e. ownership or

responsibility over patient data as they are passed from dept to dept. would be

useful if data could be annotated by a care professional who has viewed it. Might

be useful for future care professionals. This one really needs thrashed out



further as it could be critical. Hannah/Oliver Wells – could you identify where

this will occur in the project.

R4.10 Statement: Where appropriate validity checking of entries should be

employed.

Any data entries inputted by the carer, or indeed anyone else, should be

checked for validity before they are accepted. At the very least to ensure the

data is of the correct format and within normal boundaries. It may also be

necessary to use a formal sign-off process with a professional carer, particularly

in the instance of altering alert thresholds which may need confirmation by a

clinician.

R4.11 Statement: The service must have appropriate service availability.

The service availability should meet the carer or service user availability needs.

For example: an alerts service may need to be available 24/7 and monitoring

information may need to accessible 24/7. Under the constraints of the SAPHE

trial real-time alerting will probably not occur. However, the end service may be

designed to handle this.

ISSUE: Anywhere anytime – do carers want this? Does there need to be an

agreement with emergency services in order for this to work within response

remit?

Response: Nigel Barnes commented and as it is a key issue it has been

opened up to wider discussion. This is noted in the issues section of the

appendix.

R4.12 Statement: Information access should be secure and controlled.

Different levels of access may be appropriate for different stakeholders. For

example, in relation to data access agreements adhered to by clinical staff,

compared with social care staff. This requires user authentication procedures to

be in place for any access to information. Any unauthorised attempts to access



the information should be blocked by the system, and reported to the service

provider.

ISSUE: For example, in relation to data access agreements adhered to by

clinical staff, compared with social care staff. User authentication procedures

should be in place for access to any requests for information. Any unauthorised

attempts to access information should be blocked by the service provider

firewall, and reported to the service provider.

Response: Re-worded to reflect example

R4.13 Statement: Communicate abnormal events

The identification of abnormal events is a data analysis requirement, see Section

6, however there is also an interface requirement that the interface must be able

to draw a carer’s attention to these events through the use of an appropriate

method.

ISSUE: It’s not ‘may be’… otherwise why are doing it

Response: Language tightened up.

R4.14 Statement: Ability to disable alarms

If an alarm process is in place then alarms need to be able to be disabled in a

flexible manner:

- If a user is referred to hospital, need to be able to disable the alerts for

that period and re-enable them quickly when they return home.

- Need to be able to specify non-occupancy periods when alerts should

not be generated (although some security alerts may still be appropriate

in these periods).

- Need to be able to restrict monitoring at user’s request, except for pre-

defined triggers. All requests would need to be assessed before

agreement



- There may be a requirement to take into account individual occupancy

of the user’s home, e.g. temporarily disable telecare during periods of

multiple occupancy of the home, by time of day (e.g. evening).

R4.15 Statement: Multiple alarms may need to be prioritised.

If the service identifies simultaneous abnormal events for a number of different

service users it may be need to indicate the degree of abnormality to allow a

service provider to examining those requiring priority and non-priority

interventions.

ISSUE: if multiple alarms are going off, then what is the need to prioritise? Go

see the person.

Response: Statement probably referred to priority/non-priority alarms and

different users. Section reworded.

4.1 Requirements relating to informal carers

ISSUE: We need to spend some time on this section. BT to review

R4.16 Statement: The system should be able to generate (user customisable)

daily profiles.

If appropriate data manipulation may be required to turn data into the form

required for daily emails. The daily emailing of information of interest was

highlighted as a benefit of the original Liverpool Telecare Pilot. This could be

further developed to allow the user to manually select the information of most

relevance to them.

Comment from ISLA:

, and to our surprise showed a general disinterest in reminders. In

particular, caregivers rarely set up reminders for clients, and did

not use them as designed. We believe several factors contributed



to this inattention within our test group: no immediate health crisis

(they were not taking care of their parent on a daily basis), too

busy, ineffective web design “hid” the features from plain view. In

general, family caregivers want succinct reports, including details

about today, charted history of important indicators, and links to

further details. Our design gave them too little at a time. Most

systems on the market today provide little or no reporting to family

caregivers. Some caregivers did use I.L.S.A. to improve their

peace-of-mind by accessing up to-the-minute reports on their

client’s wellbeing. While I.L.S.A.’s caregiver interface proved to be

off-the-mark in terms of presentation, making more information

available to family members could make even simple personal

emergency systems more valuable as a long-term care tool."



5. System Related Requirements


This section contains the following system related requirement areas:

- Application interoperability

This section contains related to creating a system which integrates with

existing systems and future systems. For example, use of NHS IT

standards.

- Common Node

This section describes the requirement of the SAPHE common node. This

will consist of a processor, some memory and a wireless link to process

and relay data from a sensor to the home hub or mobile device. The node

will be a configurable generic node that may be used with both

environmental and body sensors. The requirements specified aim to

guarantee the node can perform within parameters derived from the

sensors and ultimately the patient conditions that are monitored.

- Home gateway and LPU

The home gateway and local processing unit (LPU) are required take take

data communicated by the common nodes and forward the relevant

information over wired/wireless links.

- Body Sensing

Environmental sensors are those fixed in the dwelling of the service user.

Typically this means attached to appliances or the building infrastructure.

The requirements given describe aspects such as functional lifetime,

required performance, aesthetics etc.

- Body and physiological sensing



This section contains requirements related to the on-body and

physiological data sensors in the SAPHE system architecture. Issues

affecting the selection and incorporation of on-body sensors, and the

treatment of data generated by those sensors for security and context-

awareness, are also discussed below.

- Service deployment

The previous requirements provide the technological basis for the service.

However, additional requirements exist in order to create a deployed

service. This section covers aspects from the installation to the de-

installation of the system including managing the day to day operation of

the service.

5.2 Requirements relating to application interoperability

R5.1 Statement:The SAPHE system should integrate with already existing

systems.

Consideration should be given to integration with electronic care records, GP

systems etc. even if implementation is beyond the scope of the current project.

There is evidence that seamless integration across health and social care is a

government focus and failure to consider integration with existing systems could

lead to negative evaluation at the conclusion of the SAPHE project. If a system

is unable to demonstrate how it could integrate into existing routines it is likely to

be viewed as more of a hassle than a simplification. Even if implementing any

integration is beyond the scope of SAPHE it is necessary to start what systems

are currently in use and understand where the challenges lie.

ISSUE: There is plenty of evidence in DoH / gov papers about the importance

of this, I don’t think it’s reflected in this requirement. Its going to be a serious

influence on any evaluation… ie. If it doesn’t integrate into their routine systems /

process we’re going to create more hassle rather than simplify things… this



should be priority, yes without doubt implementing it will be a dog, but we should

at least starting to understand where are the challenges, what the various

systems are, and what is needed… if not implemented, this should form part of

the gap analysis. Needs a balance, maybe mock up integrations… but it could

have a negative influence on trials if not done

Response: Reworded to reflect comments and issue highlighted to WP leader.

Nigel Barnes: At first thought the awareness of existing systems and their

capabilities will form part of the gap analysis. How we potentially integrate with

them will be part of the Service Deployemnt WP.

R5.2 Statement: The SAPHE system should be interoperable with NHS IT

standards.

- Clinical data must be coded using the SNOMED coding standards

- Clinical data must be encapsulated within HL7 messaging formats for

transfer to national IT system (Connecting for Health, etc)

- also consider the alternative EN standard (number not known) for health data

formatting

ISSUE: What about social care? Needs an explanation of why this is necessary?

Docobo please comment.

R5.3 Statement:The SAPHE system should comply with the national COPD

specific standards

When monitoring for COPD the system must enable care pathways to be

followed in accordance with the NICE COPD Guidelines [NICE], the GPIAG

guidelines (www.gpiag.org), and the guidelines developed by the British

Thoracic Society (www.brit-thoracic.org.uk)

R5.4 Statement:The SAPHE system should have interoperability with 3rd party

health monitoring devices.


http://www.brit-thoracic.org.uk/


- Interfacing with existing monitors – this will involve inclusion of serial, USB

and wireless interfaces

- Need to consider low power wireless options for connectivity to wearable

Body Sensors

- Future devices – interfacing to a range of standards. Need to observe the

output from a newly formed Industry consortium called “Continua Health

Alliance” of which the SAPHE partners Philips are founding members.

ISSUE: Needs an explanation of why this is necessary. Docobo please comment

R5.5 Statement:To integrate with other systems the SAPHE system should be

assessed with the same safety standards in mind.

Whole system safety issues need to be considered in accordance with

EN61508, and incorporate risk assessment in accordance with EN/ISO14971

(risk management standard). This will involve risk assessment of component

parts, sub systems and integrated whole systems solutions, including the care

pathways and clinical protocols

R5.6 Statement:The SAPHE system should comply with the Medical Device

Standards.

All products produced that relate to the collection and transfer of medical data

must comply with the relevant Medical Device Directive. This includes both

hardware and software components. Ethics committees and PCTs will insist on

the relevant standards being met before patients are given devices that the PCT

staff are liable for. This area has been overlooked by the regulatory authorities

to date, but more attention is being placed on this area by the MHRA as the

market beings to take shape.



5.3 Requirements relating to common node

Philips have review this section – all comments and issues have been moved to the appendix.

This section describes the requirement of the SAPHE common node. This will

consist of a processor, some memory and a wireless link to process and relay

data from a sensor to the home hub or mobile device. The node will be a

configurable generic node that may be used with both environmental and body

sensors. The requirements specified aim to guarantee the node can perform

within parameters derived from the sensors and ultimately the patient conditions

that are monitored.

A defined interface to a sensor will be provided. The node will use an

appropriate radio technology to send sensor data to a home hub or mobile

device. A common node data protocol will be employed to ensure

standardisation and interoperability.

Development

R5.7 Statement:The common node must have a minimal functional lifetime of

12 months.

Given that the trial duration is 6 months and nodes will have to go through a

verification stage before that, a 12-month lifetime seems an acceptable minimum

requirement.

R5.8 Statement: The common node should be unobtrusive.

This is mainly a requirement that the sensors can be worn with regular clothing,

thereby allowing users to live as normal as possible. It should result in a small,

light packaging.



R5.9 Statement:The common node must be safe.

The nodes need to be designed in such a way that they do not cause any harm

or danger to the user. This affects mainly limiting the emitted energy from the

radio, shielding electrical components and preventing interference with other

equipment.

CE-certification and FCC approval are normally required for commercial radio

devices, other or additional requirements might apply for a trial.

Production

Deployment

R5.10 Statement: The common node should provide self-configuration and a

good out of the box experience.

End users should be able to wear the system without having to set-up or

configure things. This means that sensor nodes need to set-up or join a network

automatically upon switching on a node. When the system is installed, the setup

time should be minimal, e.g. a good out of the box experience. The Continua

Health Alliance might be a useful resource for this.

Operation

R5.11 Statement: The common node must be able to provide its service to

both environment and body sensors.

For the common node it shall not matter what type of sensor is attached, body or

environment.



R5.12 Statement: The common node must provide sufficient bandwidth to

send the sensor data to a backend.

A high data rate ECG monitor can sample between 100 Hz (ambulatory) to 10

kHz (pacemaker spike detection) with a dynamic range between 12-24 bits for 3-

12 channels. This results in uncompressed bandwidths between 3.6 kbit/s and

2880 kbit/s.

R5.13 Statement: The common node data link should have a low latency.

For certain types of monitoring a low latency data link is desired, e.g. alarms.

R5.14 Statement: The common node should be able to provide service

anywhere in the service user’s house.

Both sensor nodes (body/environment) need to forward data to the service

provider. The body network might use the environment infrastructure as gateway

throughout the whole home.

R5.15 Statement: The common node should be able to provide service outside

of the service user’s house.

Users likely won’t stay at home during the whole trial, therefore being able to

monitor away from home might be needed. Data can be recorded during the

away period or transmitted directly over a GPRS/3G network or can be recorded

during the away period for later assessment.

R5.16 Statement: The common node’s battery life must support the required

node duty cycle.



The nodes duty cycle needs to be determined and depends greatly on the

careplan. Ideally the node’s battery works the whole operational lifetime, such

that the service user does not need to replace any batteries.

R5.17 Statement: The common node should provide data security.

Privacy protection

End users must be protected against interception (eavesdropping) of the data on

the node network or when sent over the Internet (e.g. use of encryption).

Backup and disaster recovery

In case the link to the backend service breaks the node might need a backup

mechanism that can temporarily store data while the problem is addressed.

Data validity

Clinicians must be able to rely on data being recorded is not changed by

networking problems. This is normally done with error checking and data

correction.

Support

R5.18 Statement: The common node must report relevant status information.

Notification that the deployed system is working correctly

After providing a system to a user, the service provider might need a

confirmation that everything is working correctly, such as sensors not having a

bias, nodes able to connect, etc. There might be a need to check this during the

operational lifetime as well. Service users might also want a confirmation that

the system if fully functional.

Notification of loss of connection to backend service for one or more sensors



For instance when there is no internet connection or 3G link

Notification of battery status

When the user is required to replace batteries, they should receive low battery

warnings or an estimate when to replace batteries. There might also be a need

for notification of how long the batteries have been operational.

Notification of sensor damage or incorrect wearing

When sensors are damaged or incorrectly worn, the data they measure can be

faulty (e.g. a bias). This might need to be reported.

Report quality of network and connections

If data is missing due to network problems (e.g. battery low), this should be

reported.

R5.19 Statement: The service provider may be able to change the data

collection settings.

Different patients might cause different data collection strategies. A clinician

might want to specify that data is only collected at a certain time during the day

(e.g. only at wake-up) or at a specified interval (every minute). This mainly

depends on the careplan and care must be taken not to have conflicting

requests (e.g. one clinician wanting a different setting from another).

R5.20 Statement: The common nodes may be easily replaceable.

When for some reason a node dies or runs low on its battery it may be possible

to simply replace the wireless part of the node on the sensor with (a) a new (b)

recharged or (c) other currently worn one. When a vital sensor like the ECG

sensor runs low on battery, it can simply replace it with the wireless node of

another less important sensor, for example the temperature sensor which may

still have plenty of energy. This allows important/vital sensors to keep working as

long as possible.



Disposal

Training

Verification

5.4 Sensor related requirements

5.4.1 Requirements relating to the home gateway and LPU

R5.21 Statement: An appropriate home gateway must be provided.

The home gateway requirements will include:

Ability to remotely capture patient metrics from home monitoring medical

devices and provide tools to allow users to collect personal healthcare

data from devices.

Network connectivity - Ability to transmit data to central platform.

Back-up facilities - Fall-over mechanisms should be put in place and data

should be backed up where possible. Service must continue in the event

of loss on network connectivity.

Remote maintenance - It should be possible to remotely upgrade

software without significant service downtime.

R5.22 Statement: An appropriate LPU should be developed which provides

multi-sensory data fusion capabilities.

Since several types of sensors will be used, it would be necessary to summarise

information from these sensors by using techniques of data reduction and

feature selection. For on-body sensors, initial fusion of sensor data takes place

at the LPU. For feature selection, the Bayesian framework developed at Imperial

College would be a good choice as it can deal with a large number of features

efficiently. Other methods of sensor fusion will be researched as part of the



project, leading to optimal use of sensor data. In addition to summarising

correlated data, this also means separating useful data from noise. - see also

R13.5 Trend analysis

5.4.2 Requirements relating to body sensing

R5.23 Statement: All body sensors should be biocompatible.

On-body sensors should be manufactured with materials that do not cause

irritation/tissue damage, and are biocompatible to the subject being monitored.

Similarly, precautions should also be taken that other materials required for

applying the sensors (such as surgical tape) are suitable for use by patients with

skin conditions which may react to adhesives.

ISSUE: H&S requirement better placed in H&S section

Response: Moved to H&S section

R5.24 Statement: All body sensors should have low power consumption.

On-body sensors should be selected for their optimum use of power, in order to

prolong the battery life of the SAPHE system.

R5.25 Statement: All sensors should be durable and robust.

Sensors that are manufactured to high quality standards will be selected for the

SAPHE system. The sensors must be durable, and robust enough for wearing

on a daily basis and for the duration of the trial.

ISSUE: General sensor requirement. MOVE

R5.26 Statement: Particular attention must be made to ensuring all body

sensors are comfortable to wear, in addition to being unobtrusive.



Package design for on-body sensors should not inhibit the user when being

worn, with maximum consideration for comfort and discretion.

ISSUE: Identify related requirements. This applies across the whole document.

AR

R5.27 Statement: All body sensors should be user passive.

SAPHE system on-body sensors should require minimal interaction and/or

maintenance from the users – both the patient and other stakeholders. The

sensors should be self-configuring with the SAPHE architecture, and require little

more than an on/off switch.

R5.28 Statement: All body sensors should be easy to operate.

Package design for on-body sensors should also be considerate of the fact that

users are likely to suffer from conditions such as arthritis and reduced visibility.

Any sensor switches, controls, dials, etc. should be visible, tactile and easy to

operate - see R7.1, R7.2, R7.6.

R5.29 Statement: All body sensors should report the relevant information

(specific to the individual and their condition).

The specific set of sensors deployed should be selected based on the

requirements of the patient and their condition. The minimum number of sensors

which can provide sufficient, relevant information should be used. Examples

may include:

- ECG

- SpO2 (Oxygen saturation)

- Respiratory

- Motion sensors



- Temperature

- Gyroscope

- PGR

- Blood Pressure

The data generated by other devices which cannot be worn on-body (such as

Blood Glucose Level and Weight) should be able to be used in context with the

data generated by the SAPHE system.

R5.30 Statement: All body sensors should be compatibility with other

sensors/equipment.

Sensor interfaces with surrounding media/medical sensors already in place.

Sensor performance must not be adversely affected by other equipment used in

the home (e.g. mobile phone/hearing aids) – see R10.18

R5.31 Statement: All body sensors must be capable of interfacing with

wireless data connection (BSN Node) nodes.

All on-body sensors used for the SAPHE system will be suitable for integration

with the wireless BSN node. Initial sensor signal processing takes place at the

BSN node, which then transmits data to an LPU (e.g. a PDA or a mobile phone).

Low power signal conditioning is a feature of the BSN node, prolonging the

overall battery life of the SAPHE system.

ISSUE: Secure data transmission – refers to common node

Response: Moved to common node section



R5.32 Statement: The body sensors should provide context-awareness

sensing.

Vital signs monitors will be used to generate an overall interpretation of

physiological conditions. The range on-body sensors used will vary for each

individual, however, the spectrum of sensors used will generate various levels of

contextual data (such as a Taxonomy of States: if a user is running, walking,

sitting, swaying, falling, etc). – see also R13.5 Trend analysis

R5.33 Statement: The body sensors should be capable of real-time data

monitoring.

Data will be transmitted in real-time from the on-body sensors to the BSN node,

and from the BSN node to the LPU. Further data compression and encryption

will take place before data is transmitted from the LPU to the security and

management layer, and then stored in the secure server database for historical

reference. Data enquiries can be authorised at the management layer, enabling

real-time physiological data extraction/monitoring by users and clinicians. - see

13.3 Physiological alerting

R5.34 Statement: The SAPHE system should provide a degree of resilience to

the body sensor data.

On-body sensors used for the SAPHE system must be capable, to some degree,

of self-checking, self-optimisation and self healing to enable the system to

deployed reliably and securely

ISSUE: Low cost requirement is a design goal.

Response: Moved to design goal section

5.4.3 Requirements relating to environmental sensing



ISSUE: I didn't see any mention of pets - does this need to be specified in some

way, as well as potential multi-occupancy?

Need to provide a defined course of action if sensors are subjected to conditions

outside their specified operating range. Need to monitor sensors to check if they

are functioning. Frequency of monitoring (e.g. every second), needs to be

assessed as part of the hazards being monitored.

R5.35 Statement: Environmental sensors must be unobtrusive and unintrusive.

Sensors should be packaged in a manner which avoids making them

aesthetically unacceptable. The sensors should also be able to be located in a

manner which has minimal impact on a service user’s normal interaction within

their homes.

ISSUE: In some cases, the sensors should avoid ‘blinking lights’ when in

operating mode, which remind the user that they’re being monitored. However,

in the case of dementia patients, blinking lights can be useful reminders for the

performance of ADLs. – OW/HW

Response: Incorporated in design goals. Add more

R5.36 Statement: The environmental sensors should have a minimum of a 6

month battery life.

The power requirements of all sensors should be such that a battery change is

not required during the trial (6 months) period and ideally a target battery life of

>12 months should be achieved.

Issue: This conflicts with common node battery life

Response: Let’s stick with 12 months as a minimum.

R5.37 Statement: Environmental sensors must be easy to Install.



A significant proportion of the costs associated with system deployment are

likely to be incurred during the installation phase. Environmental sensors should

be designed to minimize the complexity of installation.

R5.38 Statement: The environmental sensors should be auto-configuring where

possible and should not need significant calibration in the home.

Sensors should be usable “out of the box” without significant calibration required

in the home. Ideally an automated approach based on intelligent data analysis

should be adapted to calibration.

ISSUE: a separate requirement of auto-configuration?

Response: Added.

R5.39 Statement: The environmental sensors should be designed to be able to

have a minimal impact on the behaviour of the service user, unless intended to.

Environmental sensors should be designed such that they have minimal impact

on the service user, unless they are specifically intended to assist with lifestyle

change. In general, environmental sensors should not require the user to

change the way they use a particular item or require the replacement of their

existing items to accommodate the new sensor infrastructure.

ISSUE: minimal impact – we may want them to change their lifestyle

Response: Reworded

R5.40 Statement: The environmental sensors should be reliable and robust

Statement: As far as possible sensors should tested prior to installation to

ensure they operate in a reliable manner and are robust enough to last the

duration of the trial when exposed to a normal home environment.

ISSUE: Do we need a target mttf? This is not my area of expertise, but isn’t

Mean Time To Failure something that’s fairly easy to specify for hardware but

very hard to specify for software? BT please reply.



Response: Possibly outside the project scope – more of a productisation / cost

issue.

R5.41 Statement: The environmental sensors should report faults and errors to

the common node.

Sensors should report failure or provide periodic “heartbeats” to allow the

system to identify faults.

R5.42 Statement: The environmental sensors must report the user’s location

within their home.

The location of the user within the dwelling is one of the most basic and useful

pieces of information. The user location can either be sensed directly, for

example through video-based sensor, PIR usage, etc, or indirectly by using

other location specific sensors, for example a bed sensor.

In the instance of multiple occupancy either the sensors themselves should be

able to distinguish single occupancy from multiple occupancy or a data analysis

approach may be used. The sensors must also be immune to pets.

Issue: What about multiple occupancy? Do you need to identify someone or anyone.

Response: reworded.

ISSUE: Do we need to go to the level of determining who is who? For discussion

included in general issues in appendix. BT to review

ISSUE: Include video-based sensors as example.Response: reworded.

R5.43 Statement: Environmental sensors should report necessary information.



The specific set of sensors deployed should be guided by the requirements of

the conditions for monitoring. The minimum number of sensors which can

provide sufficient information should be used. Examples may include:

- Door usage

- Cooker usage

- White goods usage

- Chair occupancy

- Bed occupancy

- Medication usage

- Specific hazards (e.g. gas, water)

- Video-based monitoring (from Imperial UbiSense project)*

This requirement reflects the design goal of a balance between cost and

functionality.

* This sensor uses a camera and onboard processing hardware to capture the

silhouette (outline) of a person in a room without recording the appearance

information to ensure privacy and its general use within a home environment.

Each “blob sensor node” consists of a camera, battery power source and an on-

board processing unit, which processes the video data locally into a blob

signature. It is important to re-emphasise that this sensor does not act like a

camera as it is not possible to recover any original picture data, particularly the

appearance of the person from the node itself. The “blob” data is then further

processed on the node into a series of numbers (called feature vectors) which

reflect the subject’s position and trajectory. These numbers are wirelessly

scrambled and transmitted to a central node (or a computer) located in the

patient’s home. This node collects information for the gait and posture analysis.

This will ultimately be linked via the internet to an “early warning system” alerting

the relevant healthcare professional about a patient’s worsening condition.



5.5 Requirements relating to service deployment

ISSUE: Need an introduction mentioning ETSI work and welsh assembly work.

Steve Brown please review.Response: Steve Brown Ok I’ll work on this…

Context of operation

R5.44 Statement: The service should integrate within the context in which it

operates.

For example, care providers often make use of ‘care pathways’ established for

people who have common conditions such as bronchitis or early stage

dementia. Care pathways can help ensure that care strategies for acute,

chronic, long term care and sometimes social care are based on guidelines and

evidence which outline optimal sequencing and timing of interventions. New

elements such as telecare must be designed to work in conjunction with these

existing care methods and demonstrate clear benefits.

Community alarms, telecare and telehealth are part of a range of care options

and the leading organisations will be commissioning and planning these together

as part of services for older people, people with learning disabilities etc.

Increasingly you would expect to see references to telecare and telehealth in

local committee and board reports covering extra care housing, NSF for older

people, Supporting People and long term condition management. This will

include important links to service user health, housing and social care records.

An integrated approach is important. It will make little sense to a service user to

have a community alarm, a telecare installation and vital signs monitoring

without proper coordination of equipment and service response.

The political agenda is also important. Justification for telecare has largely come

from the National Service Framework report [ref], but other reports that should

also be considered are the Wanless report [ref] which is about patient

engagement in the own care (self-care), the Kerr report [ref] which discusses…

and the Scottish Executive’s range and capacity review of community care



services for older people in Scotland reports [ref] which discuss the Scottish

political perspective on self-care and telecare, as well as providing demographic

data. One recommendation that comes from these reports which should be a

requirement for SAPHE is the interoperability of the system with both social

services and health care services.

ISSUE: Summary of Kerr report needed. BT please review

R5.45 Statement: The service should match local priorities.

Telecare services can help many different groups achieve a greater level of

independence and quality of life. The latter include people who are at risk of

falling and people with long-term illnesses and complex needs who regularly

need in-patient treatment. The needs of each group are different. There is,

therefore, no single solution whether or not involving telecare.

Within the SAPHE project Central Liverpool PCT will be engage with to

understand their specific local priorities. Through an understanding of the merits

of their current service frameworks and care pathways the service can be

developed in a systematic way in support of local priorities. It should of course

be acknowledged than may of the priority issues associated with the trial site will

be more broadly applicable.

R5.46 Statement: The time-scale for offering a full service should be calculated.

A full implementation plan requires identification of the resources, priorities and

personnel needed for service provision and an appropriate timetable for service

development. Whilst the SAPHE project has time constraints there should be

sufficient flexibility to enable the service to be implemented according to best fit

with local, or possibly regional or national, strategies. The plan may require

potential barriers or hurdles to be overcome through managerial or political

interventions. This should include consideration of the role of telecare in extra

care housing and residential care.

For full-scale service provision telecare will also need to be addressed in Health,

Social Care and Well-being strategies and noted within Local Housing



Strategies, Wanless Action Plans, Older Person’s Strategies, Supporting People

Operational Plans and Community Safety Strategies. Although this may not be

fesible within SAPHE it is important to be aware of the wide spread impact which

telecare type technologies will bring.

ISSUE: “Map existing services” is not a requirement but activity.

R5.47 Statement: The service should meet the needs of the service users and

their carers.

Before framing any plan for telecare implementation it is necessary to

understand the context of existing services together with the manner in which

they operate and are funded. Understanding the context means seeing how

these services ‘fit’ with the new approach that is necessary. It means engaging

with people who use the services (and their representative organisations), older

people’s forums, policy makers and service managers. By this means, basic

information will be gathered by which existing services will be able to be

reviewed and, where appropriate, changed in order to accommodate telecare

and better meet people’s care and support needs.

R5.48 Statement: Senior stakeholders must be involvement in the project.

Senior level involvement and commitment from all stakeholder organisations

needs to be sustained. Successful implementation needs champions, both

inside and outside local authorities and health boards. Inclusion and involvement

of statutory, voluntary and private sector agencies involved in health, housing

and social care provision will be essential if a high quality and robust service is

to be developed.

R5.49 Statement: A formal service delivery model must be created.



The basic requirements of a telecare service are an assessment leading to a

prescription and installation of equipment and the putting in place of procedures

for monitoring and response. The latter must, of course, include the adoption of

appropriate response protocols in relation to emergency or other needs. There

are several ways in which telecare services might be delivered at a local level

and these should be considered within SAPHE. The options include integrated

partnerships, private services and hybrid models. All need to be considered and

compared on the basis of service ethos, cost, response times and coverage.

Twenty-four hour response services may be beyond the scope of the SAPHE

trial however an awareness of how such a service could be offered should be

developed. This may be fessible in urban centres, but may not be possible for

some rural areas. Particular arrangements involving local community networks,

important in both urban and rural contexts, will need to be considered for the

latter.

Technical Design

R5.50 Statement: The SAPHE system should co-exist with any existing

services.

The system should co-exist with any existing community alarm systems. Details

of any pre-installed systems need to be captured on the site survey. (e.g. old

hard-wired systems, Tunstall systems). For the Liverpool Telecare Pilot second

telephone lines were installed, if the houses had Tunstall alarms.

R5.51 Statement: The service deployment should, where possible, align to the

technical design requirements for a full-scale service.

It wil aid potential commercial exploitation of some, or all, of the technologies

developed within SAPHE if the design requirements for a full-scale service have

been considered. These incude:



- Future-proofing: The service provider should consider how the service will fit

with longer-term developments for telecare and telehealth systems.

- Scalability: Consideration should be given to the scalability of service

components. E.g. self-install software or use of standard web-browser for

software.

- Longevity: In the long-term it is expected that applications will adopt a

Service Orientated Architecture and expose business functionality as web

services.

- Consider language requirements: Need to consider the first language of all

users, if it is not English this could include impact training packs, IVR, service

user visits, contact centres, service user and carer communication.

- Database: Carefully consider choice of database the scalability and

availability of Oracle makes it the preferred choice for commercial

applications although as many applications in the healthcare marketplace

support SQL this may also be an appropriate choice.

Installation

R5.52 Statement: An installation plan needs to be created.

This will address the following issues:

- A single point of contact needs to be provided to initiate

i. changes to service provision (e.g. disable sensors) or

ii. to advise short term changes such as deactivate during holiday periods

or hospital admission, or

iii. to report faults, or changes to client state of health e.g. leading to need

to change sensor positions, or



iv. management of decommissioning.

- There is a requirement to communicate to the carers the need to inform

changes to the single point of contact.

- Assessment process: There is a requirement for formal review of clients, and

creation of a review plan for each client as part of the initial assessment.

Special arrangements will need to be made for service users without carers,

to be identified during initial referral.

- There is a need for a single assessment process to be initiated for telecare

service users.

- Floor plans are likely to be necessary for the environmental data analysis

algorithms.

- Need to test end to end with dummy alerting/dry runs with service user

closing alerts (forms part of service user training).

- A facility will be needed to notify all key parties that the service has gone live

(only parties with a need to know). An aspect of this is ensuring notifications

are going to the correct people and also that all carers, service users and

referral agencies remain informed.

R5.53 Statement: A de-installation plan needs to be created.

This will address the following issues:

- Need to agree making-good requirements for when equipment is de-installed

(the Liverpool Telecare Pilot filled holes but did not re-decorate).

- There is a requirement to confirm consent with the service user for

decommissioning.

- There is a requirement to initiate assessment of new care package where the

existing system is to be decommissioned. The impact of decommissioning



the existing Telecare package should be understood with sufficient time

available in put in place an new care package.

- There is a requirement to manage the disclosure and disposal of service user

records at decommissioning (e.g. send to GP, compliance with data

protection act). Agencies in Social Services and Health may require

information. If information is to be kept for research purposes it needs to be

established how the information will be stored and controlled. Additional

consent, and input may be required from the carers or service users about

the usage of the information. Data confidentiality, data protection and the

freedom of information act need to be analysed.

- There is a need to consider family sensitivity in decommissioning for a

deceased client, including speed of sensor removal and communication.

ISSUE: re consent to decommissioning - This seems very odd. Why should an

SU consent to removal of something that provides a benefit to them, however

small? Why should they have an absolute right to have the indefinite use of

equipment that they do not own? Why should a resource-limited care providing

agency have to take a risk that equipment, once installed, may never be

recoverable, even if the SU no longer needs it and others do? Andrew Reeves to clarify.

Training

R5.54 Statement: Appropriate carer and service user training must be given.

- Training material should be developed for the different types of individuals

who might be involved in the delivery or receipt of the service (e.g.

beneficiaries, family, carers and care managers). The training material

should provide different levels of information depending upon the needs of

the individual. For example a volunteer visitor may only require an

awareness that the system is in operation, whereas care workers and

beneficiaries may require a more in-depth understanding.



- Service users and their visitors should be aware that the effectiveness of the

equipment will be compromised if moved or tampered with; or if power

sources are switched off.

- The nature of the training should positively encourage people to use the

functionality offered by the SAPHE equipment wherever appropriate.

- The role of a demonstration site should be explored together with the

possibility of producing a video or DVD that may be used to inform both staff

and users about the service available.

- Implemention of a robust training approach: Senior managers, assessors,

care managers and others need to feel confident about the use of the system

and to understand its place within the broader framework of care and support

services. Training will, therefore, be needed to ensure that staff develop the

necessary understanding and knowledge; and adopt a service ethos that is in

tune with the new approach to health and social care.

- Telcare is still a relatively novel service and the training requirements will

involve raising awareness of the application and benefits of telecare together

with positioning SAPHE with respect to commercially available services.

Those providing the information and advice should be aware that there may

need to deal with emotive issues such as closing of care homes, reducing

social contact.

- All training should be appropriate in terms of timing, quality and format.

Integration with existing services

R5.55 Statement: Integration with existing services

Telecare will be most powerful when used in conjunction with existing

community-based services including floating support, mobile wardens, home

care and meals services. Existing infrastructure, such as community alarm



services, that can act as a platform for new telecare services should also be

considered. Bringing these together can facilitate more effective provision and

help progress towards that elusive goal of ‘seamless’ services. Within SAPHE it

needs to be considered how the service could operate as an integral part of the

support or care plan agreed with individuals.

Some leading organisations may have linked their referral and assessment

arrangements in with existing systems. Telecare and telehealth are part of a

range of service options available to health, housing and social care to meet the

needs of users. Organisations should avoid developing new paperwork and

systems where existing arrangements are perfectly adequate. Remember,

where there is an assessment, it is important to synchronise and link record

systems so that the monitoring and response are clearly part of an agreed care

plan and review arrangements. Records of falls, medication compliance, vital

signs etc need to be available to clinicians and others responsible for a care

plan. A service responder that does not have a full set of relevant information

agreed by the user may not be able to provide an effective service.

Supply and management of equipment

R5.56 Statement: The supply and management of equipment issues should be

understood.

To develop the buisnees case for commercial exploitation of some or all of the

service elements developed within SAHPE an understanding will be needed of

the supply and management issues involved in commissioning such a service.

- As a general principle, local authorities should follow procurement best

practice. They should seek economies of scale in procurement and lower unit

costs for equipment.

- The development of partnering arrangements with technology suppliers can

be beneficial, rather than supply, fit and maintain.



- There are several options for the supply and ownership of telecare

equipment. These include: direct purchase and ownership; leasing;

Rent/Managed Service; and Self Purchase.

- Service providers should consider the best way to commission, procure and

manage a wide range of assistive technology? For example does the

organisation run separate or integrated inventory and stock control systems?

Does it have a complex arrangement of pooled and non-pooled funds which

are confusing to practitioners? Is there a single record that shows all of the

assistive technology provided for one person that links to an existing care

plan that is available to all relevant practitioners with the consent of the user?

Alert handling

R5.57 Statement: A formal process must exist for alert handling.

Alert handling is a critical element of a telecare service and should have a

consistency of response. This means creating a formal alert handelling process

which addresses the following issues:

- The supply of relevant 24-hour/seven day contact services; and the supply of

24-hour/seven day care response services should be considered.

- The response protocol should be agreed with the service user (or their

advocate or carer where informed consent is not possible). For example, in

some cases, individuals may not wish their carer or family member to provide

the response or to be informed of the alarm trigger, or they may not want

social services to be informed.

- All conversations between the monitoring and response centre and the

person’s home should be recorded.



- Alert handling should be tailored to the individual’s care profile e.g. the

referral needs to identify if the individual is able to self-cancel alarms, and to

identify associated equipment requirements.

- All service users should have a complete chain of alert handling with fallback

to emergency services. This should be reviewed periodically for each service

user.

- There may be a need to prioritise alerts so that the call centre can respond to

the most critical alerts first. This will require profiling of client groups, and for

decisions to be taken on the type of Telecare service to be delivered to each

group.

- Different models of how an alert should be handled by a call centre need to

be considered. These models should take into account the expertise and

knowledge of the call centre operatives, as well as the availability of the first

point of contact. A national model may include a first call centre that does the

logging, and follow pathways to pass onto the right professional in a second

contact centre who will perform an assessment and decision on next steps.

- Contact centre staff would need to be trained in alert handling and

escalation.

- Contact centre scripts to indicate appropriate response in different

circumstances should be considered.

- A central repository should be considered to capture all information on alerts

(their whole lifecycle including outcome) and audit trail.

- Service level agreements for the whole service e.g. response time,

installation of kit, need to be specified and observed.

- Resource requirements to handle the telecare alerts should be considered.

This is dependent on identifying the client groups, types of Telecare service

and the impact on the structure required (contact centre, carers,

professionals, out of hours response teams, and emergency services).



Although real-time alerting may be outside of the remit of the SAPHE trial these

considerations are required for developing potential service models.

ISSUE: Should we not simply adhere to the TSA code of practice? - it must at

least be referenced. Andrew Reeves please add reference

Document from fisk and doughty welsh assembly? AR will add reference.

Telecare Service

R5.58 Statement: Telecare service level agreements must to be drawn up and

agreed with the relevant stakeholders.

The service level agreements (SLAs) should include:

- Ownership of the kit

- Abreakages policy

- A maintenance routine

- An assignment of lliability for failures of kit or service, and accidents

(Health & Safety).

Additionally all Local Authorities within the UK will have protocols for protecting

vulnerable adults from abuse (adult protection guidance) and as the SAPHE

system will be aimed at caring for these service users account of these protocols

should be reflected in the SLAs.

It should be noted that the SLA could form form part of the informed conset

process, see section in this document on ethics.

R5.59 Statement: The end-to-end service should be resilient with high

availability.

Where possible measures should be used to make the technology resilient to

failures e.g. power failure. In disaster scenarios which could affect the system



service user and carer information needs to remain accessible so that

individuals can still be contacted.

The level of service, including what would be required in the event of service

failures (e.g. impact of power cut for dementia patient), needs to be investigated

as part of a profiling exercise to establish the user needs prior to service

provision. Different service users could have different needs.

R5.60 Statement: There must be an equipment maintenance policy.

Most items of equipment are probably going to be battery operated. Batteries will

need to be replaced either periodically, for example every 6 months, or when a

battery-low warning is transmitted. It is sensible to ensure that at the same time

as replacing batteries, equipment is tested and confirmed to be functioning as

intended.

R5.61 Statement: There must be a service provision and equipment review

schedule.

The acceptability of the equipment to the person for whom it is installed must be

confirmed on a regular basis. Initially, a review should be performed within 2

weeks of installation to ensure that all equipment is calibrated and functioning

properly, the service user understands it, and it is doing what was intended.

Regular reviews will enable problems to be identified and quickly resolved and

minimisie the risk of people’s confidence in telecare will be undermined.

The need to regularly review telecare services is a broader issue beyond

SAPHE. Technologies will develop quickly as manufacturers and suppliers

appreciate more fully the way that telecare services can assist in empowering

people and helping in relation to their care and support needs. Such changes

and the growth in service configurations mean that it will be necessary during

the initial years of telecare roll out to keep services under constant review.



6. Requirements relating to data analysis Response: This section was subject to a significant number of comments and

issues. I have revised the section but it is worth all partners checking they are

happy with the revision. All please review this whole section.

ISSUE: One of the purposes of SAPHE is to link physiological/metabolic

parameters and lifestyle patterns for improved well-being monitoring and early

detection of changes in disease state. The fusion of the different data sources is

not adequately reflected in this section.

Response: Reworded section and raised as general issue in appendix. Imperial please review.

ISSUE: Should there not be a reference to the Living Independently system?

Response: Reworded section. Imperial please review.

Commercially available systems, for example Living Independently’s QuietCare

system or Tunstall’s Midas II, are beginning to make use of remotely collected

sensor data to infer aspects of a service user’s lifestyle. One of the primary

research challenges within SAPHE is to go beyond this and create a system

which not only intelligently monitors lifestyle patterns but also synergetically links

these patterns to physiological/metabolic parameters. It is anticipated that the

use of data fusion techniques will create an improved well-being monitoring

system which is capable of early detection of changes in disease state. This

section is concerned with the data anlaysis requirements required to realise the

maximum benefit from the different data channels.

It should be noted that there are also data processing requirements related to

other speficifc individual system, or servivce, components and these are

included in the appropriate section for that component.

ISSUE: These all depend upon what we want to analyse monitor. Would it not be better to have the high level requirements:

Collect data

Store data



Analyse data – trend, decision theory,, ...

Raise alerts

Produce reports (data mining)

Otherwise you will need to have a definitive list of all types of alert ... medication not taken.

Response: Section restructured. Please review.

ISSUE: Missing requirements?ISSUE: From the Liverpool workshop, it is clear that for the PCTs the system

needs to make their service provision more efficient / cost effective etc… there

will likely be measures we can use from their infrastructures to see if the

interfaces (and thus telecare) is actually of benefit to them in terms of care

provision.

ISSUE: Would be good to look to validate these claims, their trials were small,

the ui was basic if not poor (I very much doubt there was any user engagement,

as it seems to be honeywells’ pre-existing solution)… anyway they make some

strong (and important) points, but there is certainly scope to challenge / validate

some of their claims…. Problem is though, we’ll also have just a few clients

R6.1 Statement: Data from a variety of different data sources will be collected

automatically by the SAPHE system in a reliable, robust and secure manner.

There are a number of different data types which will be supplied for centralised

processing. There should be no need for a user to initiate any data transfer from

sensors. The exception may be in the pragmatic use of existing measurement

devices.

R6.2 Statement: All data must be timestamped.

All sensor events should be timestamped to allow their chronological ordering for

data analysis. The use of sequence numbering of transmissions may additionally

be appropriate and can provide indication of missed transmissions in the case of

one-way transmission protocols. Satisfying this requirement will require the time

synchronisation across the system to allow different data streams to be

correlated appropriately and to manage time sensitive alarm and reporting.



This will be particularly important when real-time data transfer is not available

and the facility to locally store sensor data is used. This applies to both the home

gateway which should store data when a WAN connection is unavailable; and to

worn devices where the LPU will store data.

R6.3 Statement: The system must supply an appropriate data storage facility.

Over the course of the trial a large amount of sensor data will be collected. This

data must be stored as it represents one of the assets of the project and will be

used for a number of purposes. The method of storage must be able to supply

secure access to a number of different users who may require simultaneous

access to the data in as timely a manner as possible. Data protection and

security measures must be enforced to ensure potentially sensitive data is only

accessible by those trusted individuals who need access.

Issue: should all raw sensor data captured be stored within the trials? Or will we

allow filtering and preprocesing to remove some data? Possibly need to review

on a case by case basis. Should expect the trial to store more data than will

ultimately be needed. Imperial please comment

R6.4 Statement: The data analysis techniques used by the system must be

driven by the information requirements of the service users, professional carers

and informal carers.

A wide range of data analysis techniques could be applied to the data including

techniques such as OLAP, ADL inferencing, time and sequential pattern

clustering, rule based analysis, etc. The techniques chosen should reflect those

best aligned with the needs of the users but this is difficult to establish as so few

projects have ever presented information to the various users. Perhaps the basic

theory of “if they keep using it, it must be useful” applies. The ISLA findings

[Haigh et al] commented that:



"...while caregivers were less interested in the data than we

anticipated.", "Caregivers rarely looked past the initial status

overview. They almost never looked for the trend graphs of ADL

history..”

The use of OLAP in the CiC project has shown promise for providing interactive

data reports but this needs validating. Ohta’s [Ohta et al, 2002] modelling work is

also interesting in that they use just PIRs, and they’re interested in general well-

being - they model the data in terms of transitions and durations of stay. The

well-being index measure they used was the correlation coefficient of a day’s

data against the monthly average. They also found (like the equal project) that

weather influenced the activity. ADL inference has been widely explored by

different groups, largely because care services uses ADL capability to judge

whether the client is able to maintain independent living.

The SAPHE project will probably include workshops with health professionals

and care givers dealing with the illnesses we are covering in this project, to

discuss with them how they would like the data reported. Data can be reported

at different levels to the service user (making it very simple) and the health care

professionals (including vital information that the doctors need to see).

ISSUE: Is this requirement too vague? Originally it was to look at the data

analysis from two perspectives – “indication of general well-being using data

mining techniques such as OLAP, ADL inferencing, time / sequential pattern

clustering, and rule based analysis”. But this was unclear and received

comments:

“I’m unclear about the point being made here. My interpretation is that a

distinction is being drawn between fully automated analyses on the one hand

and OLAP interactive analysis on the other. I would put ADL inference and

sequential pattern recognition in the automated analysis class, though.



OLAP (On-Line Analytical Processing) means that a data analyst user is going to

analyse the data using an interactive tool such as Business Objects. Who is this

data analyst user and what are they trying to achieve? What are their skills?”

ISSUE: We shouldn’t be thinking in terms of techniques the requirement should

be around use of the most appropriate data analysis techniques to provide

service users and carers with the information they require.

Response: Re-worded to account for issue. Please review.

ISSUE: Could we get reference for OLAP paper awaiting publication – we can

update once exact reference is known. Dundee please advise.

R6.5 Statement: The system should be able to inference activities of daily

living (ADLs) for sensor data.

Inferring high level activities from raw sensor data may be required. ADLs

indicate the ability of an individual to live independently. The CiC project

identified and targeted six key ADLs:

Leaving and returning home

Sleeping

Visitors

Preparing food and eating

Personal appearance

Leisure activities

These were seen as useful for the elderly in general, irrespective of the specific

conditions they had.



The reliable detection of visitors is a particularly useful ADL as in addition to

monitoring social interaction it can be used for care audits and to flag periods of

multi-occupancy to avoid corruption of activity data or threshold setting data.

ISSUE: Not sure where this is a comment from us / not…. But the ADL inference

is and was part of CiC project as they seen as useful for monitoring the

wellbeing of the elderly in general, irrespective of specific conditions

Response: Re-worded to account for issue - Imperial please review.

ISSUE: Need to add evidence on ADL inference methods, what about the

findings from IDA. Steve Brown – can you add them into this section as Dundee

are not sure they have the IDA final reports. Steve Brown please add content

Response: Blaise Egan is currently looking into the IDA methods. Andrew Reeves to talk to get comment from Blaise.

R6.6 Statement: The system should be able to identify causes for concern

from the sensor data.

Alerting algorithms must be used which learn a user’s normal pattern of activity

and flags derivations from this.

Machine learning techniques exist which can be used to identify irregularities in

activity. Within the CiC project an IDA approach was used to detect derivations

[ref needed] and within the original Liverpool telecare pilot a key benefit of the

pilot was the rigorous decision theory approach used for generating real-time

personalised adaptive thresholds for generating alarms [Barnes et al., 2006]. It is

not intended to use real time alerting within the SAPHE trail. However, an

approach to threshold setting based on rigorous decision theory may be

appropriate for identifying unusual behaviour in post collection data analysis.

Within, SAPHE a number of different parameters are likely to be monitored for

unusual behaviour, including both physiological and lifestyle parameters, and

possibly falls and sudden posture changes. It will be crucial to match the

parameters monitored to those which the carers wish to know about and to

investigate the appropriate technique for identifying abnormalities.



ISSUE: “Decision theory”. Where has this term come from ? We were doing

decision support, or preferably using telecare to support a dialogue of care.

Response: The reference is not related to the CiC project but the decision

theory approach utilised for setting real term alert thresholds as part of the BT

Liverpool Pilot. I’ve re-worded and add references. Imperial please review

ISSUE: It was certainly one of the aims of the CiC project, but I doubt we are

able to say it was of benefit… I’ve not see anything in terms of results from the

evaluations to back up that claim… maybe Steve can comment. Steve Brown please comment. Response: Reworded so it is clearer that the comment refers to a benefit

identified from the original pilot not the CiC project.

ISSUE: Include reference to machine learning and that we can investigate the

decision theory approach as well as others, depending on the questions we’re

asking.

Response: Reworded so it is clearer that the comment refers to a benefit

identified from the original pilot not the CiC project.

ISSUE: This also applied to detecting falls, or sudden changes in posture.

Response: Examples included.

ISSUE: Confirm reporting out of home location and visitor detection - are still

requirements.

Response: all specific items for monitoring have been dropped so that the

section presents a truly top level view at this stage.

ISSUE: Disabling alarms - This should not be part of data analysis as it doesn’t

really involve any ‘analysis’. It should probably be in the sensor design.

Response: Moved.

R6.7 Statement: The system must perform trend analysis.

The real world data produced by the system is likely to be noisy and trend

analysis will be required to help users interpret the available information and

differentiate between genuine trends and noise in the data. The results of this



analysis should be presented in the form most appropriate to the service user or

carer.

ISSUE: Graphs will be provided showing the variations of parameters over time,

this might help carers realise certain behavioural patters.

Response: Graphs and other visualisation techniques may be appropriate

depending on carer’s wishes.

ISSUE: Would have expected to see more here / above in the adl section based

on the work from IDA in the CiC project… Steve brown should be able to provide

material. Steve Brown please comment.

Response: From SB - OK will do. Issue left in for now

R6.8 Statement: The system must be able to automatically verify system

integrity.

There is a need to determine loss of monitoring e.g. because of power failure, or

malfunctioning, or a service user mistakenly unplugging a device. This

compliments any fault reporting by sensors and introduces additional robustness

into the system. Useful to identify unreliability in installations as well as for

informing data analysis. If such an approach is adopted then the system could

also possess a fall back plan. This would be implemented failure of an individual

sensor was identified.

The system should able to cope with missing data and continue to provide

reports etc. for the data it does. It may be possible in some analysis to give a

reduced level of granuality or confidence in the results due to missing data. For

instance if a bed sensor fails we may know the person went upto their bedroom

at night but wouldn’t know if they made it into bed – we could suggest it was

likely but they would be an element of doubt.

ISSUE: Originally suggested system should infer a range for the missing data.

This statement goes too far. This implies some degree of redundancy of

components plus built-in intelligence to detect failure and respond appropriately.

It can be done, it but adds substantially to cost, complexity and project risk



Response: Reworded

R6.9 Statement: The system should be able to summarise management

information.

There is a requirement for management information to be produced by the

system. Examples include the system automatically tracking the total number of

alerts per user or the duration of system up time. Such data is also of use in

identifying users who experience frequent technical, or other, problems.

R6.10 Statement: Produce reports

R6.11 Statement: The system should be capable of both online and offline data

analysis.

Within SAPHE both online and offline data analysis are needed. Online data

analysis can provide users with relevant information relating to the current

activity. This includes a possible ‘index’ that shows higher or lower activity levels,

as well as the ability to detect falls and changes of posture. Offline data analysis

will be needed to be able to to perform trend analysis over large amounts of

data, and provide summary reports on activity levels, as well as important events

that happened during a certain period, such as falling down or being awake for

long hours.

The potential need for online data analysis means that data should be

transferred from sensors to a central database in as close to real-time as is

practically possible. For mobile (out-of-house) transfer from worn devices data

transfer may always be on a store and forward basis to the reduce cost and

complexity of the wireless connection and in home the same approach may be

appropriate if a non-broadband approach is adopted.



R6.12 Statement: The system must seamlessly integrate data from on-body and

environmental sensors.

On-body and environmental, or ambient sensors, provide different types of data

relating to activity. If fused, or if knowledge from both types of sensors is

combined, this would provide a higher certainty of the type of activity that is

taking place . Position data from ambient sensing, for example, could allow the

inference of certain activities given the body sensor data. Several techniques will

be investigated for the seamless integration of data from different sensor types.

Probabilistic graphical models might provide a good approach for data fusion but

they are a pretty complex approach to data fusion. There may be much simpler

approaches that do the job adequately.

ISSUE: Dealing with missing data

The system should have an ability to deal with missing data from one or more

sensors. If the missing data affects the system, the system should report this

error. However, the system would be able to use data from other sensors to infer

a range for the missing data.

Response: worked into appropriate requirement

Issue: Could we introduce a reference to compliance issues? Eg hip protectors

paper?

Response: Hip protector example included.

ISSUE: Goes back to ‘trust’ in the system, certainly the system shouldn’t be

ignoring things, but clients also shouldn’t be worried about being put in a nursing

home at every alarm. Thus the requirement is probably more about making sure

the user feels respected, that the information isn’t being used to get them in a

home, but to help provide better care… it could be dropped as a specific

requirement and instead integrated within one of the trust ones. This issue

should be explored with stakeholders.

Response: Section reworded to better reflect comments.



ISSUE: re- collaboration. Needs to be developed further… video conferencing?

A SAPHE telecare web portal where users can interact (a)synchronously? Any takers???... please.Response: Taker found and section improved.



7. Good Practice Related Requirements

7.1 Requirements relating to legal

Telecare services will also have to meet the requirements of the new audit and

inspection bodies being established for health and social care, which are likely to

reflect those currently being applied by the Commission for Health Improvement

(CHI). CHI’s reviews of clinical governance set out to answer three questions:

What is it like to be a patient/service user?

How good are the systems for safeguarding and improving quality of care?

What is the capacity in the organisation for improving the patient/service

user’s experience?

It is one of CHI’s statutory functions to monitor and review the implementation of

standards set out in National Service Frameworks. The full text of CHI’s reviews

of different services can be found on its website (www.chi.nhs.uk).

There is an emerging literature about the legal aspects of telecare. A series of

articles in the Journal of Telemedicine and Telecare in 1997 and 1998 covered

such issues as confidentiality and the patient’s rights of access, data protection

and malpractice (Stanberry, 1997, 1998a, 1998b, 2006). Information on the

application of the Data Protection Act in and across health and social services is

on the Department of Health website (www.doh.gov.uk). Broadly, issues in this

area relate to ownership of the data and data protection and security.

R7.1 Statement:The appropriate steps must be identified and taken to protect

the SAPHE partners from legal action resulting from the research project.

A telecare service can involve a complex supply chain. Each organisation

involved will deliver its component of the service but the service will be judged

on its overall performance. In the event of a failure to deliver there will be a



liability but where this liability lies will be difficult to determine unless the issue of

joint liability is addressed before a mainstream service is made available.

ISSUE: I think we are talking about different issues – we are referring to legal

implications relating to a telecare system, rather than issues around this

particular research project. This line is therefore not relevant in this context.

Response: Requirement out of place has been re-ordered but a project

requirement to protect from liability (eg through SLAs) should remain. Could

move to service provision but this would seem to be likely place to look for such

a requirement as well as the legal aspects of telecare in general.

R7.2 Statement: The project may comply with the Disability Discrimination Act.

ISSUE: This section discusses some published work, but does not state what

the conclusions were - we don't want the reader to have to go and figure it out

for themselves. BEIC please review

7.2 Requirements relating to ethics

ISSUE: Further content from Andrew Sixsmith needs to be incorporated. Andrew Reeves will do.

ISSUE: This seems to be focused on ethics of the trial rather than the ethics of

the system.

Response: Don’t think this is any longer the case.

Telecare can potentially be intrusive. While every care intervention is potentially

intrusive and requires consent from the individual concerned, the situation is

made particularly difficult in the case of telecare as it is delivered outside an

institutional setting and gives a picture of an individual’s behaviour not previously

available. Additionally many of the beneficiaries of telecare are likely to have

mental frailty and collecting consent from them may be difficult. This section

provides requirements related to ethical considerations for the SAPHE project.

R7.3 Statement:The telecare system must be integrated into a care plan.



Pilot projects have shown that, if used correctly, telecare technology is accepted

by users and carers and connotations of ‘Big Brother’ can be overcome [Gillies,

2001]. A common theme which emerges from the pilot projects and the literature

is that it is not the form of technology which determines the ethics of its use, but

how it is used in an individual case. There is wide agreement, for example, that

telecare should be used within the context of an overall care plan to support

independence rather than to control ‘problem’ behaviour.

R7.4 Statement:The presence of telecare monitoring should not impact upon

traditional care contact.

The presence of a telecare system should not lead to increased isolation or

unacceptable reductions in staffing support.

R7.5 Statement:A professional approach must be adopted when visiting service

user homes.

There is a need to gain permission and/or supervision for visits (throughout the

service lifecycle: installation, maintenance visits, training and testing) to user’s

homes. Any individual from a supplier who might have contact with users must

be CRB approved beforehand

R7.6 Statement:There must be clear ownership of operating costs.

There is a need to establish who pays any up front bills related to the service,

examples may include: new telephone handsets, second lines, line upgrade to

broadband, new power sockets. There will also be extra operating costs incurred

by the service user and it needs to be clear who is responsible for their payment.

For example: increased electricity bills.

ISSUE: wording seems to imply that BB will always be required.

Response: Re-worded.

R7.7 Statement: Any telecare system deployed must be the minimum

consistent with meeting the assessed needs of the individual.

R7.8 Statement: Informed consent must be obtained wherever possible



Lifestyle monitoring raises difficult ethical and legal issues over what constitutes

public and private space, for example, how will behaviour that is publicly

observable anyway be treated? Care must be taken to explain to service users,

(or their advocate or carer where informed consent is not possible), the type of

information about themselves which will be available and to whom it will be

available. It is essential that consent to participate must be informed.

The question of informed consent has important implications especially for those

with cognitive impairment, as well raising more general questions such as how

often consent should be sought (e.g. should it be every time a service is

changed?) and who should be asked to provide consent. This applies not just to

service users but informal carers may need to consent also who, for example,

need to be aware of their additional responsibilities. It should be remembered

that there is a requirement to gain consent from any other adult in the service

users home also, for example an individual who visits in the evenings only.

R7.9 Statement:Service users must have the right to refuse participation.

A fundamental question that may arise from the widespread introduction of

telecare services is over the right to refuse to participate. One issue is whether a

two tier service emerges, one for those who had agreed to use telecare and an

inferior one for those who do not wish to participate. In general, implications of

not accepting a telecare service delivery option should be explained but refusal

should not debar an individual from receiving other services.

Further InformationThe Astrid Guide (Marshall, 2000) provides a useful introduction to ethical issues

in the implementation of telecare and assistive technology. While the guide’s

main focus is on dementia care, its principles are applicable elsewhere. It points

out that similar ethical issues, such as the balance between risk and safety,

arise in the provision of other forms of care where technology is not involved. It

suggests how to develop ethical protocols and how to deal with the issue of

informed consent. Voluntary organisations and professional bodies have also

contributed to the debate on the ethical use of technology.



ISSUE: re Gillies reference - we (Dundee) should be able to get in touch with

her she’s in social work.

Response: highlighted as part of reference section.

7.3 Requirements relating to health and safety

All devices associated with service user monitoring must be designed for safe

operation in line with the relevant health and safety guidelines. This section

describes the relevant industry health and safety standards, Medical Device

Directives and regulatory requirements.

R7.10 Statement: There should be conformity with to appropriate standards

physiological signals.

The digital interchange of physiological signals should take into consideration

applicable sections of relevant standards such as CEN/ISO IEEE (BS EN ISO)

11073 “Health Informatics”.

R7.11 Statement: There should be compliance with relevant industry

standards and Medical device directives for sensors.

All the sensors to be used in the SAPHE system and the trial should be

commercially available and licensed for clinical use. The systems compliances

should be covered by the Medical Device Directorate, and the relevant sections

of applicable standards such as BS EN 60601 “Medical Electrical Equipment

Requirements for Safety”.

R7.12 Statement: There should be compliance with the relevant standards from

the Telecare NSF.

The following standards may be relevant (taken from the latest ITT for Telecare

National Framework services):



The furniture and furnishings (fire) (safety) regulations 1988 as

amended by SI 2358 1989. Goods shall be labelled in the manner set

out in schedule 7 part 11 of the regulations.

The consumer protection act 1987, as amended. (quality of product,

what happens if customer trips over the sensor/negligence)

The control of substances hazardous to health regulations 1988, as

amended.(client becomes ill because of equipment).

Decontamination of equipment prior to inspection, service and repair

HSG (93) 26.

European Council Directive 93/42/EEC of 14 June 1993 concerning

medical devices.

The medical device regulation 2002 SI 618.

Safety notice MDA SN 01 January (issued annually each reporting

adverse incident relating to medical devices).

Medical device and equipment management for hospital and

community based organisations MDA DB 9801.

Information security ISO 17799:2000, BS 7799-2:1999

R7.13 Statement: In addition to compliance with the relevant standards the

equipment must be safe in use, installation and maintenance.

Particular attention must be paid to any danger which could arise from

potentially cognitive impaired users handling equipment in ways different from

the way it was intended (e.g. taking equipment into the bath).

Equipment must be installed such that the equipment or any wiring/power leads

etc. do not cause trip hazards. Installed equipment must be easily accessible for

maintenance (and operation if required) especially if users are required to



operate it in any way. Risk assessments will need to be carried out before

installations.

7.4 Requirements relating to trial design

ISSUE: This entire section needs reviewing and additional content added. Andrew Sixsmith + BEIC please review.

The objectives of the trial need to be clearly stated. This may take the form of

research questions to be answered, hypotheses to be tested or effects to be

estimated. The objectives should neither too vague nor too ambitious given the

resources available. It may be useful to have major objectives and minor

objectives, since there may be a need to prioritise the allocation of resources

and this should be considered at the outset.

The trial should aim to cast light on a limited number of pre-specified research

hypotheses. Failure to adhere to this principle will expose us to the problems of

multiple comparisons () and possible accusations of ‘data dredging’ ().

A control cohort of service users similar (as far as reasonably practical) to the

trial cohort must be chosen contemporaneously with the trial cohort. (Failure to

assign a control group will eliminate any possibility of assigning a convincing

benefit to telecare.) Ideally, triallists would be matched by age, sex, disease and

severity of disease.

The choice of the cohort of trial service users must be consistent with the stated

trial objectives. That is, an entry protocol shall be devised.

The sample size and duration shall be such that one or more pre-specified

benefit outcomes will be measurable with high probability. This will be verified

prior to the start of the trial by fully documented statistical power calculations.

The telecare process which is being applied to the trial cohort should be defined

in detail. This will include:

- what measurements shall be taken



- with what frequency

- in what units they are expressed

- how they are communicated and to whom

Resources consumed by both the trial group and the control group shall be

recorded to form part of the trial evaluation. This shall include

Resources consumed in response to crisis events

Hospital stays (duration to be recorded)

Routine visits by health or social care professionals

Deaths of triallists in both the telecare and control arms of the study shall be

recorded, as will new (i.e. post-trial entry) morbidities

All data derived from the trial will have an assigned Data Owner who is

responsible for it and all subsequent issues (security, audit trails etc.). It will be

clear from the trial documentation who is the data owner for what.

When the trial is over it shall be evaluated according to certain criteria. These

criteria shall be stated at the outset, before any data is collected

The form of analysis applied to the trial data in order to determine benefits shall

be stated at the outset, to eliminate the possibility of ‘cherry-picking’ of outcome

results.

Suggestion: A user description (including care package) should be captured

prior to involvement in the trial.

To perform a satisfactory analysis of the trial it is essential to understand the

type of users involved. This should include the level of care which they are

receiving. If this changes during the trial period this must also be recorded.



Suggestion: Service user floor plans should be created and documented

Floor plans are required for the data analysis purposes.

Suggestion: The language requirements of the service users should match

those of the prototype SAPHE system.

If service users were not fluent in English it could impact upon training packs,

IVR, service user visits, contact centres and carer/user interfaces etc. Rather

than tackle this within the research project the single language will be used.

ISSUE: For trail purposes we could assume (require) English as a first

language. Clearly this system has to be designed to include multiple language

support. Should this be incorporated in a requirement around criteria for trial

entry? Blaise Egan please comment.

Response: reworded to reflect comment from Blaise.

Suggestion: There should be a process to aid trial management.

- There is a requirement for a central repository to capture all information on

alerts (their whole lifecycle) and audit trail.

- There is a requirement for a facility to capture the outcomes of telecare alerts

and an audit trail of who was contacted. What outcome information is

required needs to be defined in detail - for example that the user had fallen,

broken hip and gone to hospital. Some of the outcome data would be useful

in feeding into the algorithm software, and setting of behaviour thresholds

Statement: We should define the resource allocation for the trial.



If the SAPHE system will likely impact upon the work load of professional carers

involved. This impact needs to be assessed and it must be verified that the

necessary resource has be allocated.

Statement: End outcome capture for abnormal events.

There is a requirement to capture the ‘end’ outcome (and need to define the

boundary). This will be of use for understanding the impact on the service users.

Statement: The trial must have an ethical policy and ethics committee approval.



8. Appendix

8.1 Issues and concernsThis section contains issues and concerns which are not specific requirements

but have a bearing on the requirements and need to be discussed and resolved

as early as possible in the project. To aid with transparency and openness within

the project the intention is to move all important comments and issues to the

appendix. This which will exist as a documented record of the issues and

concerns raised.

8.1.1 General Issues and ConcernsQuestion: What are the goals of the system? Is there agreement and clear

objectives for the system?

Response: This is now covered in the introduction to this document.

Question: Is it the intention to provide a system that aims to support

independent living for as long as possible at all costs?

Response: Clearly this is not feasible and cost considerations are now

discussed in the design goals section of this document. The service deployment

section also contains material on this related to an exit strategy.

Question: Does the system have the twin goals of supporting independent living

as far as is reasonable but at the same time maintaining an 'incident' threshold

beyond which the client should be considered incapable of living independently?

If the latter, what is this threshold?

Response: The system will facilitate continuous evidence based assessment of

the service user occupant to the carer(s) to support their decision making

processes.



Question: Who decides what is reasonable in relation to a person’s ability to live

independently?

Response: This part of the assessment process. We can provide useful

information to the assessment process but we should not try to redefine it. It’s

not our call.

Question: Is the system merely there to provide carers with the data necessary

to make a judgement on this for themselves?

Response 1: Support for assessment is one of the functions of the system but

not the only one.

Response 2: but it is the key objective… not sure what others they are, but

would have thought they were all working towards the information provision.

Response 3: Steve Brown may have some comment on this. I believe the CiC

project’s view was that judgements should always be made by the carer rather

than the system.

Response 4: From SB - Yes, definitely

Question: If so, are we confident that the data and analysis is reliable enough to

allow the carer to make this call?

Response: Assessments are currently being made on less information. Unless

the information we provide is actually grossly misleading we will be assisting the

process.

Question: If the data and the analysis is not reliable enough, will the system

make this clear to these carers?

Response: See above reply and also the design goal on managing stakeholder

expectations.

Question: If the data and analysis is considered reliable enough, how do we

'sell it' to clients whose independence is threatened if the system reports that

they are experiencing difficulties?

Response: By pointing out that it will prolong their stay at home as long as

possible. Also see the design goal on improving care.



ISSUE: Need to get a consist style for the requirements, e.g. just a title and

short description / justification. There is a lot of inter-related / repeated

requirements – might need an overview set of requirements, with just the

specific features extracted for each condition… e.g. medication adherence. Also,

think it might be good to have a priority flag / indicate whether its key for SAPHE

to do this, or if its something that the bigger picture of telecare should consider –

low priority for us (because of time etc) but in reality it should be considered /

implemented… could then be explored if time in something like the gap analysis

component.

Response: Document has been restructured to reflect the structure proposed

by Philips. Adoption of the standard language suggested by Philips should meet

the priority flags you request. Unfortunately, due to the limited time to prepare

draft 0.3 the language has not yet been tightened up. If priority indicators are still

required they can be included in the next update of this document or in

deliverable D02.

ISSUE: Data reliability also involves dealing with multiple occupancy, and

understanding the impact in terms of ability to analysis the generated data

successfully.

Response: This is mentioned in the main document with requirements around

either sensors or data analysis techniques being used to determine multiple

occupancy.

ISSUE: Definition of the solution space. We need to start making decisions

about what is ‘possibly in’ the system and what is categorically out e.g. video

cameras. This output is needed by the WP A2 and WP.

ISSUE: Should we be including requirements for a home gateway and LPU?? –

done but needs developing.

ISSUE: Need to start identifying specific stakeholders as is cuts across

requirements WP and gap analysis WP.



ISSUE: RE real time alerting - This needs some wider discussion. Under the

constraints of the trial we probably want to avoid real-time alerting. However an

end service may need to handle this. The issue primarily relates to performing

clinical diagnosis.

ISSUE: Need to state purpose of trial.

8.1.2 Section Specific Issues and Concerns

Design Goals

Issue: Should the system offer degrees of sensitivity? – does this approach

have any precedent in existing telecare deployment?

Response: Additional goal of flexible sensitivity added under service user

involvement.

Issue: Is there an equivalent to Coldicott guardians in social care?

Response: Within social care there are briefings of Information Governance in

Social Care which are wider than just Caldicott principles, and addresses five

broad aspects of Information processing - how information is Held, Obtained,

Recorded, Used and Shared (HORUS). Revised the section to reflect this.

Issue: re data security and health/social care: Do we need to look at a new

model for telecare...is the ETSI work covering this [Steve Brown???]

Response: The ETSI document will contain guidelines relating to trust which

covers aspects of prevention, detection and recovery. These guidelines will be

incorporated when available. Not sure what is meant by the question ‘do we need a new model for telecare’?

Common Node



Response: Philips have reviewed the issues below and are happy that they are now covered in the section.

ISSUE: What is a common node could we have a description.

ISSUE: Here’s a list of requirements from other sections which relate to this

section can Philips ensure they are happy that it’s all covered.

- Resilient data transmission

Assuming wireless - sensor transmissions may be subject to interference from

other sensors (simultaneous firings) or from 3rd-party devices (e.g. phones,

wireless LAN). The devices and protocol should be selected/developed to

promote reliable transmission even in the presence of interference.

- Secure data transmission

Data from the BSN nodes will be encrypted before transmission to the LPU. A

security and management layer (at the LPU and server level) responsible for

secure data transmission, user-authentication and resource allocation will be

employed to protect data generated by the SAPHE on-body sensors. The LPU

could be set to a secure ‘record’ mode when the user is away from the secure

home environment network, to prevent on-body sensor data ‘eavesdropping’ by

wireless equipments not belonging to the user.

- Possible to determine if/when data is missingMissing sensor firings may make it look like an activity x has not taken place.

Sequence numbering of sensor data at time of observation (i.e. on the sensor,

before transmission) makes it clear if any data has been lost during

transmission.

- Possible to determine if sensor configuration changes

Alteration to the location, orientation, ambient temperature, etc. of a sensor may

change the sensing characteristics and alter the apparent activity profile of the



user (e.g. PIR sensor receives a knock, creating a dead-zone). Sensors should

provide notification of any such relevant events.

ISSUE: Design of casing, etc. must be taken into consideration (Philips design?)

and built into the work plan. (Imperial)

ISSUE: This is an ideal that although I (Dundee) totally agree with, is rarely

achieved… thus it would be very useful to have evidence, recommendations

here as to how to make it a reality (if not in the technical specs).

ISSUE: We (Imperial) need to check this in terms of delays vs. synchronisation.

ISSUE: worth separating this into full system spec? where i think we'd want

'away data' monitored in real time (no?) and trial data where perhaps recording

for later assessment is sufficient.

ISSUE: How feasible is this option? Will we be able to use GPRS information?

ISSUE: re 1 day battery life - Surely this is not enough… we can hardly expect

the (elderly) users / carers to change batteries across lots of sensors/nodes

every days. This needs to be more in the range of months. It would be worth

checking how both SensorNet and the UbiSense projects got on with battery life,

it was certainly a critical requirement for SensorNet.

ISSUE: Where possible, sensor data should be subject to some level of

encryption before transmission to secure central server database.

ISSUE: Its not just clinicians

ISSUE: Consideration of data synchronisation and consideration of data

ownership (Imperial)

ISSUE: This is quite an interesting idea, but one concern is that one clinician

might want one thing but another would want a totally different dataset for

different purposes… there is an earlier requirement and communication between

carer’s etc that has relevance to this.

ISSUE: Is expecting users to do the replacing is a bit much, maybe we need to

outline a mechanism for it by either technicians / or carers / procurement teams

etc.

Homecare of the Elderly



ISSUE: The idea of a well-being index was brought up in CiC but not

implemented. The closest we (Dundee) came was the OLAP presentation of

sensor fires – which gave a general notion of busyness. Do we need to revisit

the well-being index idea?

Response: The idea of a well-being index presupposes that well-being is a 1-

dimensional concept. We are moving away from that thinking, towards capturing

3 or more dimensions of well-being. I don’t think it is possible to create a well-

being index that would allow different clients to be compared in terms of their

well-being. The goal of the wellbeing project was to create a system that would

detect significant positive and negative changes in key activities which we

believe affect well-being.

The well-being concept model could be used in it’s current for to describe what

we are trying to achieve in SAPHE. However, I have developed a modified

version of this concept model which makes the monitoring of Chronic disease

more obvious. This modified model has been sent to Andrew Sixsmith for his

comment.

ISSUE: If we are presenting well-being to the user can they challenge its

findings?

Response: Idea worked into document.

Trial design

Trial design issues?

Sample size or power calculations, i.e. how many people do we need to monitor

and for how long to measure a clinically meaningful change in some

performance measure? Alternatively, if we have decided on the sample size and

duration what is the power (i.e. the probability of detecting a clinically meaningful

change in our chosen outcome measure)?



ISSUE: Are we expecting CLINICALLLY meaningful measures? I suggest remove the word clinically

Response: I (?) put that word in, so let me explain what I meant. We want our

chosen measures to be things that are considered relevant by professionals in

the field. I was thinking of medical professionals and so I used the word ‘clinical’.

(Of course, social work professionals are also relevant professionals but there

isn’t an analogous adjective.) We would want our trial to be capable of detecting

a change that a relevant professional would consider to be worth having, i.e. not

so small as to be effectively no change in their health/well-being status. This needs to be worked into document.

How are the service users to be recruited to the trial? What entry

criteria will we apply?

Will we have a control group or some other comparator? (If we don’t,

at the end of the trial how will we be able to say that telecare has

delivered a benefit?)

Will we be recording the costs and interventions associated with all the

trial service users and the control group? Who is responsible for

collecting this data?

At the end of the trial who will perform the benefits analysis? Will there

be any interim analyses (bearing in mind these could affect the

statistical significance of the final analysis)?

ISSUE: I think a major issue at this point is, what is the question… I feel from the

Liverpool workshop this should be along the lines of does telecare improve care

provision (and if so is it cost effective).

ISSUE: Another point, is what data is collected… not sure on the answer, but

one thing we would need is data on how the user & carer interfaces are used ,

ie. Detailed interaction logs, - to see if its being used, for how long, & what in

particular…etc



8.2 Hardware design considerationsISSUE: Not had sufficient time to integrate into main document yet. Andrew Reeves please review

In this section we present requirements relating to the characteristics of system

hardware which the carers and service users will interact with. At this early

stage, these ought to act as 'guiding principles' of interface design. When we

have consulted target users and consequently have a clearer idea of what the

system is aiming to achieve, then a more specific set of requirements can be

produced.

Many of these suggestions come from IBM's Developer guidelines for hardware

accessibility, at:

http://www3.ibm.com/able/guidelines/hardware/accesshardware.html

Delivery Devices

How will feedback be delivered to the client, via PC/PDA/TV/custom device, via

(formal/informal) carer (via one of the above), via printed summary (output),

questionnaires (input)?

Tactile Feedback

Any buttons, switches knobs etc should provide tactile feedback upon operation,

e.g. A clear click to indicate change of state.

Key repeat

Where an interface is accepting input in the form of a sequence of key presses,

consideration must be given to the delay for key repeats. e.g. When the key is

held down, there ought to be an appropriate delay before it is interpreted as a

repeat key press. This supports those with limited manual dexterity who may


http://www-3.ibm.com/able/guidelines/hardware/accesshardware.html


require longer to press each key. More specific requirements on this will be

possible when the functionality of the interface becomes clear.

Size of buttons

Where we have a say in device selection, consideration should be given to the

size of controls, such that they may be operated by those with limited manual

dexterity.

Avoid combination key presses wherever possible – i.e. a sequence of individual

key presses would be preferable to holding down three keys simultaneously.

Any screen-based devices shall provide sufficient screen lighting to ensure high

contrast between foreground and background colours on the interface.

Colour should be used as an enhancement rather than as the only means of

conveying information, e.g. Press the 'red' button.

8.3 Software design considerations

ISSUE: Not had sufficient time to integrate into main document yet. Andrew Reeves please review

As with the hardware, these requirements relating to the characteristics of the

software interface should be treated as 'guiding principles', rather than concrete

requirements until we have consulted with target users on what is needed from

the system.

Time-delays

The interface should avoid placing time limits on interaction tasks where this can

be avoided, instead allow them to complete a task at their own pace. Exceptions



include where a critical task has been left incomplete for a significant length of

time, whereupon appropriate prompts and cues could be used.

Recognition rather than recall

the user should not be expected to memorise interaction sequences, instead, at

every stage, clear options or instructions should be given to enable them to

'recognise' the right path.

simple steps in an interaction task: make choices as simple as possible, rather

than extensive lists of options.

Progress Status

Make it clear to the user where they are in the interface, i.e. if they are midway

through a sequence of interaction, where possible, make it clear how they got

there.

Provide a means of abandoning current task

– for users who become lost or confused in the interface, an escape mechanism

should be available.

Seek confirmation of choices for important tasks

Adaptive to inferred information

Highly speculative - Could the interface be responsive to the data analysis, e.g.

If the data analysis is suggesting a reduction in activity that might hint towards

an onset of depression, could the system act more in accordance with design

guidelines for people with depression. Similarly for other recognisable trends.

Comment: Could it? Possibly. Should it? Definitely No. Any attempt to usurp the



role of trained professionals in, say, diagnosis, is likely to be very risky for

patients and to alienate medical professionals.

Language and terminology

“The use of language in an interactive system should be given careful

consideration and the syntax and vocabulary should be kept as straightforward

and ‘everyday’ as the context allows. This is particularly pertinent for any form of

instruction. If the requirements of a particular stage of an interaction cannot be

captured in a few simple concrete statements, then serious consideration should

be given to redesigning the interaction itself. Similarly any on-screen display

should be kept as uncluttered as practicable and wherever possible should

present the user with only a single issue (menu, subject, decision etc.) at any

particular point in time. Similarly, but at a larger scale, progression through an

interaction should be kept, again wherever practicable, as linear as possible.

That is, the user should only need to consider one ‘thing’ at a time. Any

requirement to deal with different ‘things’ in parallel will markedly increase the

possibility of errors and general user dissatisfaction (Detterman et al., 2000;

Salthouse, 1985).” Newell, Carmichael etc

“Among the limitations in verbal ability is the diminution of vocabulary. Particular

difficulties have also been found in the comprehension of abstract and

metaphorical phrases, with the tendency being to take them literally. Such

conditions can develop into more ‘global’ aphasia (e.g. Broca’s aphasia, related

to the production of speech and Wernicke’s aphasia, related to comprehension).

There is also a likelihood that the general difficulty with recall of proper nouns,

found in ‘normal’ aging, can develop into more profound anomia. The depth of

such problems may not be apparent to an outside observer as the ability to read

aloud may be well preserved, regardless of the extent to which the content is

properly understood and/or subsequently remembered. ” Newell, Carmichael etc

Error correction

“Even with the best design efforts, however, such problems are likely to make

users with cognitive impairment relatively error prone. It is thus very important to



ensure the interactive system allows for error correction in an easy to use form.

Also, to ensure that the user spots such errors, the system should provide

feedback regarding user actions and where appropriate elicit active confirmation

from them.” Newell, Carmichael etc



8.4 Material pulled from service user interface sectionPhysical limitations

A1.1 Statement: The interface shall be operable by users with limited manual

dexterity. Design considerations must include size of interaction components,

time-delays of input sequences (i.e. before system prompts for completion of

input), tactile feedback.

There are a number of factors which may lead to an individual having limited

manual dexterity, the most obvious example being arthritis. However, limited

manual dexterity can also be circumstantial, e.g. Upon returning home on a cold

day, trying to operate interface whilst holding another object in the hand.

Related requirements: Partial Paralysis, size of interaction components, time-

delays of input sequences, tactile feedback.

A1.2 Statement: The interface shall be operable by users with partial paralysis,

e.g. of one side of the body or of lower part of the body (see R7.3 Mobility). Use

of the interface should not require two-handed control (e.g. holding a device with

one hand while operating it with the other) where this may be avoided. Design

considerations include the impact of using a television-based interface requiring

use of a remote control.

Users may have suffered a stroke, or a series of strokes, resulting in partial

paralysis.

Related requirements: Reach, Mobility.

A1.3 Statement: The interface shall not require users to reach too high/low, i.e.

to operate wall mounted controls.

Unnecessary over-reaching, high or low, could lead to falls. Where possible, wall

mounted controls should be placed at an acceptable height for each user.

Related requirements: Partial Paralysis, Mobility.



A1.4 Statement: The design of the interface should be sensitive to the range of

mobility likely to be experienced by the target population. Examples include the

use of a wheelchair, walking frame or walking stick.

Related requirements: Partial Paralysis, Reach.

Sensory Limitations

ISSUE: need to identify what are core features

A1.5 Statement: The core features of the interface should be accessible to a

blind user, e.g. through an audio interface.

Although a blind person may have specific care/telecare needs, there is no

reason in principle why this system (designed to 'monitor activity in the home' or

to 'detect change in activity trends') could not be used in the home of a person

who has been blind for much of their life but has now developed other health

problems which threaten their independence and require monitoring. As for use

of the interface, it is clear that advanced features such as data visualisation are

inherently 'visual', however, summary reports of these features are likely to be

preferable for some users anyway, regardless of visual impairment. Thus, these

summaries should be made accessible to blind/partially sighted users.

Related requirements: Visual Impairment, Audio Output.

A1.6 Statement: The interface should be accessible by visually impaired users,

including partially sighted and colour-blind users.

Within the context of the trial such requirements may be relaxed and instead

form part of subsequent productisation.

Age-related decline in visual acuity means that small text can be difficult to make

out. Poor colour contrast also presents a problem, for colour-blind people of any



age, but in particular age-related decline in vision can affect a persons ability to

distinguish between different shades of the same colour, e.g. Light blue on dark

blue.

Related requirements: Blindness, Audio Output, Colour Contrast, Size of Text.

A1.7 Statement: The core features of the interface should be accessible to a

deaf user, e.g. through visual alternatives to any audio cues or prompts.

Like blind users, deaf people may have specific care/telecare needs, but there is

no reason in principle why this system could not be used in the home of a deaf

person who has grown old (or for that matter, a person who has become deaf in

their old age) to monitor activity in order to assist their independence. As for use

of the interface, any use of audio, e.g. To act as a reminder to perform a task at

a set time, should be complemented by a visual cue such as a flashing bulb.

Related requirements: Hearing Impairment.

A1.8 Statement: The interface should be accessible by hearing impaired users.

It is highly likely that a significant proportion of the target users of this system will

have experienced some age-related decline in hearing. As for those users who

are deaf, visual cues should be used to complement any audio used in the

interface to the system.

Related requirements: Deafness.

Cognitive DeclineNote: Dementia is explicitly covered elsewhere.



A1.9 Statement: The interface should be accessible by users who have

experience a decline in short-term and/or working memory.

ISSUE: Use of reminiscent techniques may be useful. Sounds good—what does

it mean?

At the age of 60 years, about 1% of the population is diagnosed with dementia.

This then doubles for every subsequent 5 year age band, e.g. 4% at 70, 16% at

80. As such, it is imperative that the design of the interface takes this

characteristic into consideration. [Newell, Carmichael, Gregor & Alm.]

Related requirements: Recognition rather than recall, keep options concise,

one task at a time, provide cues for input.


experienced a decline in speed of cognition.

Task performance by older users tends to be adversely affected when time

constraints (real or imagined) are imposed. As such, users should be able to

complete tasks at their own pace wherever possible. Importantly, a greater

proportion of the extra time needed by older people for task completion is due to

age related declines in sensory systems, such as hearing and vision, rather than

cognitive impairment per se. Therefore, designing the interface to be accessible

to users with limited hearing and vision will reduce overall interaction time.

Ultimately though, decline in speed of cognition will cause some users to require

more time for interaction tasks, so the interface should be designed to allowed

for this.

Related requirements: Visual Impairment, Hearing Impairment, Recognition

rather than recall, keep options concise, one task at a time, provide cues for

input.




experienced a decline in selective attention.

Selective attention allows us to focus on the important aspect of a given task,

while ignoring irrelevant parts. “The efficiency of selective attention is markedly

diminished in most forms of cognitive impairment”. Design considerations

include making sure that interaction tasks are free of distractions or interface

'clutter'. Also, more critical tasks as well as prompts and reminders must be

designed to grab and hold the users attention where they might otherwise

become distracted. [Newell et al. 2002]

CommunicationIn this section we present requirements relating to the communication

characteristics of the target users.

AttitudinalIn this section we present requirements relating to the attitudinal characteristics

of the target users.

A1.12 Statement: The system should be designed such that it may be

considered successful even if user engagement is low or nil.

While it is likely that many users will wish to interact with the system proactively,

this should not be critical to the 'success' of the system, i.e. the goal of

monitoring activity and reporting issues of concern to a carer ought to be

attainable without active user engagement. [Haigh]

Related requirements: R7.13 Allow for High User Engagement.



A1.13 Statement: The system should be designed such that the user can

become proactively involved in the monitoring of their activities and lifestyle.

Although it should not be critical to the success of the system, user involvement

should be possible when desired by the user. More consideration must be given

to the extent of this engagement, i.e. whether the user is able to self-report

aspects of their state of health and well-being, or whether user engagement is

limited to interactive reporting of data from sensors etc. [Haigh.]

Related requirements: R7.12 Design for Low User Engagement.



9 Reference documentsThis section contains full details for documents and electronic source materials

referred to in this document.

References1. Department of Health. National service framework for older people. London:

DoH (2001).

2. Wanless D. Securing good care for older people: taking a long-term view.

London: King’s Fund (2006).

3. Kerr A. A National Framework for Service Change in the NHS in Scotland.

Scottish Executive 2005)

4. Scottish Executive Range and Capacity Review Group: Second Report: The

Future Care of Older People in Scotland. Scottish Executive (2006).

5. Miller, C., Haigh, K. and Dewing, W. “First, Cause No Harm; Issues in

Building Safe, Reliable and Trustworthy Elder Care Systems.” In Working

Notes of the AAAI 2002 Workshop on Elder Care. (2002)

6. Haigh K Z, Kiff L M, Ho G, “The Independent LifeStyle AssistantTM (I.L.S.A.):

Lessons Learned”, Assistive Technology, 18, 87-106 (2006).

7. Gallagher, E. et al. Final report: Laying the groundwork for improved

knowledge and use of assistive devices among Canadian veterans and

seniors. Report to Health Canada (2002)

8. Brown S, Hine N, Sixsmith A and Garner P. “Care in the community”. BT

Technology Journal, 22/3 (2004)

9. Hine N A, Judson A, Ashraf S, Arnott J L, Sixsmith A, Brown S, Garner P:

“Modelling the Behaviour of Elderly People as a Means of Monitoring Well

Being”. User Modelling, 241-250 (2005)



10.Newell A, Carmichael A, Gregor P and Alm N. “Information Technology for

Cognitive Support (pdf)” The Human-Computer Interaction Handbook 2. 464-

481 (2002)

11.Stanberry, B. (1997) The legal and ethical aspects of telemedicine. 1:

Confidentiality and the patient’s right of access. Journal of Telemedicine and

Telecare, 3: 179-187.

12.Stanberry, B.. (1998a) The legal and ethical aspects of telemedicine. 2: Data

protection, security and European law. Journal of Telemedicine and

Telecare, 4: 18-24.

13.Stanberry, B. (1998b) The legal and ethical aspects of telemedicine. 3:

Telemedicine and malpractice. Journal of Telemedicine and Telecare, 4: 72-

79.

14.Stanberry, B. (2006) Legal and ethical aspects of telemedicine. J Telemed

Telecare 12(4): 166-175.

15.Barnes et al. “Case-studies from the Liverpool Telecare Pilot”. Proceedings

of HC2006 (2006)

16.BT CDM/WellBeing Requirements Report (2006) (Internal confidential

document)

17.LDL Telecare Requirements Capture Workshop (Internal confidential

document)

18.Department of Health. “Confidentiality Code of Practice”

http://www.dh.gov.uk/PolicyAndGuidance/InformationPolicy/PatientConfidenti

alityAndCaldicottGuardians/AccessHealthRecordsArticle/fs/en?

CONTENT_ID=4100550&chk=1w6ljh. London: DoH (2003)

19.“Social Care Information Governance Project”

http://www.dh.gov.uk/PolicyAndGuidance/InformationPolicy/InformationForSo

cialCare/CaldicottArticle/fs/en?CONTENT_ID=4075306&chk=dvqjYH


http://www.dh.gov.uk/PolicyAndGuidance/InformationPolicy/InformationForSocialCare/CaldicottArticle/fs/en?CONTENT_ID=4075306&chk=dvqjYH

http://www.dh.gov.uk/PolicyAndGuidance/InformationPolicy/InformationForSocialCare/CaldicottArticle/fs/en?CONTENT_ID=4075306&chk=dvqjYH

http://www.dh.gov.uk/PolicyAndGuidance/InformationPolicy/PatientConfidentialityAndCaldicottGuardians/AccessHealthRecordsArticle/fs/en?CONTENT_ID=4100550&chk=1w6ljh




20. National Institute of Clinical Evidence (NICE), “CG12 Chronic obstructive

pulmonary disease: NICE guidelines”. NICE 2004. Available at:

http://www.nice.org.uk/

21.General Practice Airways Group (GPAG). “Diagnosis and Management of

CG12 Chronic obstructive pulmonary disease in Primary Care”. GPAG

(2005). Available at: http://www.gpiag.org/news/copd_guide/guidelinev14.pdf

22.British Thoracic Society guidelines available at www.brit-thoracic.org.uk

23.Marshall, M. “ASTRID: A social and technological response to meeting the

needs of individuals with dementia and their carers. A guide to using

technology within dementia care”. Hawker Publications Ltd. (2000)

24.Gillies, B. “Smart support at home: an evaluation of smart technology in

dispersed housing”. University of Dundee (2001) (Note: SPAHE partners

Dundee are aware of the author and can engage with her if required)


http://www.brit-thoracic.org.uk/

http://www.gpiag.org/news/copd_guide/guidelinev14.pdf

http://www.nice.org.uk/


10 GlossaryThis section contains terms referred to in the main document.

Caldicott Guardians – provide leadership on the quality standards for the

management of confidentiality and access to personal information (this applies

to NHS and councils with social services responsibilities (CSSRs))

Care in the Community (CiC) – Collaborative DTI funded research centre

which was established in 2002 to study and demonstrate the benefits of

telecare, where ambient intelligence devices are used to continuously monitor

clients’ health and social well-being in the home. The projects within the centre

were Domain Specific Modelling (DSM), Sensor Networks (SensorNet),

Intelligent data analysis (IDA) and the well-being demonstrator (demonstrator).

The project partners were: BT (lead) and Bristol, Dundee, Liverpool and

Loughborough Universities. Further information is available from

http://www.dticareinthecommunity.com/

ISSUE: Steve Brown can you check this please.

Service user – The term is used for an individual being monitored by the

SAPHE system. This allows for the use of a single term rather than the

cumbersome interchanging of patient, client, resident etc. In general service

user refers to “an individual receiving health and/or social care services”

(definition from the glossary of Single Assessment Process produced by the

Centre for policy on Aging (http://www.cpa.org.uk/sap/glossary/glossary.html)

Liverpool Telecare Pilot – The Liverpool Telecare Pilot was a telecare service

offered to around 20 service users in the Liverpool area. The service was

provided by BT in collaboration of Liverpool Direct Limited and was primarily

concerned with using environmental sensors to assist with raising real-time

alarms when situations of concern were identified in the homes of the elderly

service users.


http://www.cpa.org.uk/sap/glossary/glossary.html

http://www.dticareinthecommunity.com/


Independent LifeStyle Assistant (ILSA) – ILSA was a Honeywell Laboratories

3-year research project jointly funded by Honeywell and the Advanced

Technology Program (ATP) of the National Institute of Standards and

Technology (NIST). It ran from October 2000 to July 2003 and aimed to develop

technologies to transform the home into an intelligent, supportive environment.

More information can be found at http://www.htc.honeywell.com/projects/ilsa/.

Commission for Health Improvement (CHI) –

Criminal records Bureau (CRB) –

Psychogalvanic reflex (PGR) – Is a method of is a method of measuring the

electrical resistance of the skin, the SI unit is the Siemens (S). It is also referred

to as skin conductance response (SCR), Galvanic skin response (GSR)

electrodermal response (EDR) or electrodermal activity (EDA).


http://www.htc.honeywell.com/projects/ilsa/


11 Document History

Issue Date Prime author(s)

Comments

Draft 0.1 08/06/06 Steve Brown

Andrew Reeves

First draft for circulation to all SAPHE partners. Compiled from various sources by BT including input from Philips and University of Dundee.

Draft 0.1v4 Content added from BEIC, BT, Cardionetics, Docobo, Dundee, Philips.

Draft 0.2 29/06/06 Andrew Reeves Second draft circulated to all SAPHE partners.

Draft 1.0 17/07/06 Andrew Reeves Now including content from all SAPHE partners.

Document has remaining issues highlighted and assigned to owners.

Circulated to all SAPHE partners to resolve issues.

End Of Document


project requirements definitionubimon.doc.ic.ac.uk/saphe/public/saphe_requirements... · web...

Documents