SAPHE Service and End User Requirements
Service and End User RequirementsSAPHE
Issue: REL1.0
Document Reference: WPA1/D02
Date: 24/08/2006
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 Privacy, Security and Trust 6
2.1.2 Service User Involvement 9
2.1.3 Wider Applicability 12
2.1.4 Other Stakeholder Involvement 16
2.2 Assumptions 17
2.3 Constraints 18
3. Condition Related Requirements 19
3.1 Section Overview 19
3.2 Requirements relating to all conditions 20
3.3 Requirements relating to chronic heart failure 23
Sensing Requirements 24
Condition management 26
3.4 Requirements relating to diabetes 26
Sensing Requirements 27
Condition management 28
3.5 Requirements relating to asthma/COPD 28
Sensing Requirements 28
Condition Management 30
3.6 Requirements relating to dementia 30
3.7 Requirements relating to homecare of the elderly 33
4. Interface Related Requirements 35
4.1 Section Overview 35
4.2 Requirements relating to service user interfaces 36
4.3 Requirements relating to professional carer interfaces 38
4.1 Requirements relating to informal carers 41
5. System Related Requirements 44
5.1 Section Overview 44
5.2 Requirements relating to application interoperability 45
5.3 Requirements relating to common node 47
5.4 Sensor related requirements 52
5.4.1 Requirements relating to the home gateway and LPU 52
5.4.2 Requirements relating to body sensing 53
5.4.3 Requirements relating to environmental sensing 56
5.5 Requirements relating to service deployment 58
Context of operation 59
Technical Design 62
Installation 63
Training 65
Integration with existing services 66
Supply and management of equipment 67
Alert handling 68
Telecare Service 69
6. Requirements relating to data analysis 72
7. Good practice related requirements 78
7.1 Requirements relating to legal 78
7.2 Requirements relating to ethics 79
7.3 Requirements relating to health and safety 82
7.4 Requirements relating to trial design 84
9 Reference documents 87
10 Glossary 93
11 Document History 97
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
The primary objective when compiling this document was to draw upon the experience and knowledge of the project partners to create a unified view on the service and end user requirements. This document supersedes SAPHE milestone M1 which was a draft document providing a consideration of the top level project requirements. The current document was created early in the project lifecycle, prior to the completion of the other work packages, and as such represents a level of understanding prior to any new research being undertaken. It is anticipated that as the project progresses further engagement activities will occur with the different target users and stakeholders and this will lead to the requirements becoming more clearly defined. Consequently, there may be further issues of this document and technical appendices may be added to cover specific requirement areas in greater depth.
Conditions for Monitoring
To ensure a realistic project scope the number of conditions for monitoring must be limited to a small number of specific conditions. Through discussion with the proposed SAPHE trial collaborators, a Liverpool based PCT, five conditions were confirmed as both priority conditions for the PCT and as suitable for monitoring. It was agreed that the system developed under SAPHE should be capable of monitoring:
· Chronic Heart Failure (CHF)
· Chronic Obstructive Pulmonary Disease (COPD)/Asthma/
· Diabetes
· Dementia
· Homecare of the elderly
These conditions provide a necessary focus but still cover a broad range of potential service users. For example, the condition “Homecare of the elderly” is a particularly broad category and could include a variety of different aspects. It may therefore be necessary to further qualify the conditions for monitoring as the project progresses.
Trial Scope
The SAPHE project plans to undertake a field trial with a limited (~20) number of service users. The small number of users presents the opportunity to further restrict the project scope through the use of expedient trial entry criteria. An example is the use of a single language rather than meeting the broad language requirements which wider deployment might require.
The trial will also have a different scope to that of the full SAPHE system; it will limit functionality to a sub-set of the full system functionality. This is to reduce the implementation complexity compared with attempting a full service with such a limited number of users. For example, the provision of real-time alarms for instances requiring immediate assistance will not occur as part of the trial. Such functionality is included in this document however as the document relates to the requirements for the entire SAPHE system rather than just the system used for the trial. This distinction between trial functionality and full system functionality is recognised in Section 7.4 on trial design.
Development Level
The SAPHE project intends to produce a prototype system which is suitable for use in a small field trial and for demonstrating proof of concept. A common criticism for telecare research projects is that they fail to consider how telecare systems could integrate into existing organisational infrastructures [Health Select Committee, 2005]. Whilst SAPHE is limited to developing a prototype system, the project scope does include considering how the SAPHE system could integrate with existing systems, even if such integration is not carried out knowing how it could be achieved is important.
2. Overall Description
2.1 Design Goals
This 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 which are considered fundamental to the project requirements; this section discusses the issues associated with these.
2.1.1 Privacy, Security and Trust
SAPHE aims to develop new technologies and approaches which deliver benefit to the area of health and social care. However, the introduction of new technologies also introduces new risks. The Department of Health have highlighted that, when considering the adoption of new technologies, issues around confidentiality and privacy are key in the decision making process [Health Select Committee, 2005]. Along with privacy, the areas of security and trust are also of paramount importance in the design of new technologies [Dewsbury et al, 2002] and this section reflects the project design goals in these areas.
Improve Level of Care
The primary function of the SAPHE system is to benefit the service users by improving the level of care available to them. From the perspective of fostering trust from service users it is important that this primary function is clearly articulated to them. It is conceivable that service users could view such a monitoring system as existing to gather evidence to act against their wishes, for example to move them from their own home to a nursing home. It is therefore essential that service users are assured that the system exists to provide an enhanced level of care for themselves rather than for the benefit of the service provider.
Main related requirements: Training
Management of Stakeholder Expectations
The system should be designed to inspire trust from service users and carers; however, all concerned should also be made aware of the limitations of the system. The responsible management of stakeholder expectations is required to ensure that the risk of too much faith being placed in the system is avoided. This design goal reflects concern raised in the literature [Miller et al. 2002] that the worst of all the possible outcomes is for the deployment of a system which claims more responsibility than it can reliably provide. In this instance users might place an inappropriate level of faith in the systems capabilities and could potentially lead to catastrophic outcomes.
Main related requirements: Training, ethical
Minimise False Alarms
The system must be reliable, accurate and adopt a clear and consistent approach for generating alerts or alarms. When referring to community alarm systems, Haigh et al. [Haigh et al, 2006] noted 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..."
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 for the service users. Helping to confirm that the system is working and that “someone is watching over me”. However, counter to this the Liverpool pilot also saw one service user who objected to any false alarms whatsoever. Learning for the literature and the Pilot, the design goal within SAPHE is to minimise any false alarms as the ‘reassurance role’ of false alarms can be better handled through some other mechanism. For example, through scheduled carer contact, the push of education material, the issuing of reminders etc., or by a direct and simple periodic “Are you ok?” interactive voice response (IVR) telephone call.
When setting the sensitivity of an alarm a balance will always exist between the probability of false negatives and the risk of false positives and within SAPHE, for reasons of openness and transparency, wherever possible the goal should be to formalise this using a loss function.
Main related requirements: Data analysis, service user interface requirements.
Respect User Privacy
Health and social care monitoring may involve confidential information and it is paramount that user privacy is ensured at all times. Within SAPHE a data privacy policy, or data privacy statement, needs to be developed around the five broad areas of information processing: how information is Held, Obtained, Recorded, Used and Shared (HORUS). This will be based on safeguards already in use, for example those described in the documents: the “NHS confidentiality code of practice” and the “Social Care Information Governance Project”.
The multi-user nature of the SAPHE system means that the sharing of information through data visualisation and reporting techniques is of particular concern. Different levels of data access will be required by the different categories of users and the system needs to ensure that not only do only trusted individuals have access to data but that their access is limited to the data to which they are entitled to. The system will need to carry out authentication and use secure transfer methods, for example encrypted channels, to achieve this. 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.
Main related requirements: Data analysis, common node, legal, standards, trial design, interfaces
Service User Passive
To ensure the system developed under SAPHE is as widely applicable as possible the system should be designed such that the service user may be passive. It should be possible to provide a minimum level of functionality without placing any demands on the service user. It has been discussed in the literature, for example with regard to hip protectors [Parker et al., 2006], that any new 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 can be 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 the involvement of the service user if they are receptive to the concept. This further discussed below in Section 2.1.2.
2.1.2 Service User Involvement
The SAPHE project aims to develop a system which closely aligns to the real needs of service users. The need for this alignment has been highlighted in the literature, for example by Brownsell et al. [Brownsell et al., 1999] and Doughty et al. [Doughty et al, 1996], as one of the critical factors governing the success of telecare systems. This section describes the project design goals in this area:
Appropriate Guidance
The SAPHE project aims to create a service which meets genuine needs within the health and social care domain. It is therefore critical to the project to be able to define these needs as early as possible in the project lifecycle. Achieving this requires engagement with service users as early as possible to avoid divergence between the outputs of the project and the needs of the service users. Many of the subsequent requirement areas described in this document refer to the need for input from service users in order to further clarify the specific requirements. Engagement with service users may be through the use of focus groups, to bring together small numbers of representative individuals, or through consultation with organisations which represent individuals with certain conditions, for example the British Lung Foundation, which represents everyone affected by lung disease. Obtaining such guidance is paramount to creating an effective system within SAPHE.