Abstract
An assisted living space (ALS) is a technology-enabled environment designed to allow people with complex health or social care needs to remain, and live independently, in their own home for longer. However, many challenges remain in order to deliver usable systems acceptable to a diverse range of stakeholders, including end-users, and their families and carers, as well as health and social care services. ALSs need to support activities of daily-living while allowing end-users to maintain important social connections. They must be dynamic, flexible and adaptable living environments. In this article, we provide an overview of the technological landscape of assisted-living technology (ALT) and recent policies to promote an increased adoption of ALT in Scotland. We discuss our experiences in implementing technology-supported ALSs and emphasise key lessons. Finally, we propose an iterative and pragmatic user-centred implementation model for delivering ALSs in complex-needs scenarios. This empirical model is derived from our past ALS implementations. The proposed model allows project stakeholders to identify requirements, allocate tasks and responsibilities, and identify appropriate technological solutions for the delivery of functional ALS systems. The model is generic and makes no assumptions on needs or technology solutions, nor on the technical knowledge, skills and experience of the stakeholders involved in the ALS design process.
Introduction
Living in a familiar environment has the potential to increase the quality of life of end-users with complex health and social care needs who may otherwise require the frequent use of community-care, secondary acute services or institutional care homes. The steadily diminishing cost of technology is enabling the wider routine deployment of assisted-living technologies (ALT)—such as sensor technologies—in the home environment. Telecare describes tools and services supporting self-care or independent living at home through the use of technological systems such as sensors and alarms. 1 Basic devices include alarm systems such as panic buttons, pull-cords, pendants and smoke alarms. More sophisticated sensor technology can be used to monitor the home environment, including environmental factors (temperature, humidity) and doors and electric/electronic appliances, as well as a person’s physical status/movement, physiological measures and vital signs. The Delivering Assisted Living Lifestyles at Scale (DALLAS) programme (https://connect.innovateuk.org/web/dallas/) aims to create up to five large communities of end-users of ALT in the UK between 2012 and 2015. This initiative—among many others—signals an increasing willingness from a wide range of stakeholders to make the leap of faith from technological demonstrators 2 and localised pilot implementations to large scale roll-outs of ALT and assisted living spaces (ALSs) within the broader community.
In this article, we build upon their experiences of engaging with end-users of independent-living technologies, 3 and designing and delivering ALS4, 5 and integrated enterprise electronic health systems, 6 to provide an overview of recent policies to promote increased adoption of ALT in Scotland. We describe our own implementation experiences of technology-supported ALSs, with an emphasis on key lessons learnt. We propose an empirical and pragmatic iterative, user-centred implementation model for delivering technology-supported ALSs which will be of practical use to designers, providers and end-users of ALSs.
Technological and policy context of ALTs in Scotland
The Telecare Development Programme
In 2006, a national Telecare Development Programme (TDP) was launched in Scotland in order to support telecare as an integral part of community care services. Thirty-two local partnerships for health and social care across Scotland were eligible to apply to a £20 million development fund from 2006 to 2011. Partnership proposals were requested to address at least one of the TDP objectives: (i) to reduce avoidable emergency admissions and re-admissions to hospital; (ii) to increase the speed of discharge from hospital; (iii) to reduce the use of care homes; (iv) to improve the quality of life of telecare services users; (v) to reduce the burden of care on informal carers; (vi) to expand the range of recipients of ALT in Scotland; (vii) to support effective procurement practices, to promote the growth of telecare services or (viii) any other locally identified priorities and outcomes. 7 The Telecare Strategy (2008–2010) 8 aimed at further extending the reach of telecare services to at least another 7500 additional end-users; to increase awareness of telecare services; to improve telecare eligibility assessment processes; to improve care-staff skills in telecare services provision; to guarantee telecare services delivery to recognised standards; and to promote tele-health and telecare convergence where appropriate.
The Joint Improvement Team (JIT) was established in 2004 within the Directorate for Health and Social Care Integration of the Scottish Government to promote improved integrated services between health, local authorities and the independent sector. The JIT targets key strategic areas by providing advice and practical support, focusing on performance measurement, management, support and improvement. The JIT key targets for improvement include: housing; care for older people; care at home; rural and remote services; user and carer involvement; and telecare. The JIT also promotes the sharing of telecare technology, experience, expertise and best practice as part of its telecare action plan development.
Reported outcomes of the telecare programme
In a report on the impact of the TDP published in 2010, 9 it was reported that up to 29,000 users availed of some form of telecare services through TDP-funded initiatives between 2007 and 2010. End-users were mainly elderly people and people with long-term conditions, dementia and special needs owing to a range of physical impairments and/or learning disabilities. Over 80% of the services users over the three-year period were over 65 years old; approximately two-thirds were female. The telecare partnerships are estimated, through a self-evaluation assessment, to have produced substantial efficiency savings by reducing hospital bed-days, care home bed-days and home-checks for end-users of TDP initiatives. This self-assessment survey also suggested that a fifth of the care partnerships considered themselves in a position to scale services to a mainstream population.
In their summary of telecare services, 7 the JIT highlighted a number of areas of good practice and innovations which are listed below.
Identified challenges in the TDP
Many challenges (listed below) identified during the roll-out of telecare technologies and services during the first four years of the TDP 7 support the personal experiences of the author (Linskell).
Equipment suppliers and interoperability
A lack of system interoperability was identified by many partnerships as a barrier to innovation and a constraint to the range of services provision. While some had in-house technical capacity to support user-centric implementations, many had to rely on equipment suppliers for advice and installations. This typically resulted in limited sets of equipment being made available to end-users. Difficulties arose when partnerships attempted to meet more specific user-needs. The provision of tailor-made services to meet individual requirements required the purchase of diverse equipment from several suppliers. Several partnerships reported some issues with the ordering, delivery and installations of telecare equipment, with potential adverse knock-on effects for end-users. On occasion, installations did not operate as expected and systems were not deemed reliable. Technical support and maintenance from providers was not always adequate. Partnerships with limited in-house technical know-how felt that this restricted the development of innovative services. Equipment life-span was also raised as having important implications for costs.
Stakeholder support
Partnerships often reported a lack of senior managerial support for telecare deployment, which was not necessarily perceived as a strategic service priority. Telecare provision seemed to raise end-users’ expectations of services and contributed to diverting resources from certain services to others (e.g. from residential care to home care). These reallocations of resources were not necessarily anticipated by the partnerships. Consequently, adequate budgets had not been appropriately allocated for additional services. The additional workload for front-line staff was another concern. Formal agreements between various stakeholders (local authorities, health services, etc.) on the allocation of resources to support telecare deployment were also often lacking. Therefore, the long-term financial support of the telecare programme was deemed essential to mainstreaming pilot services.
In the following two sections, we describe the personal experiences of one of the authors (Linskell) in ALS project development. We describe some of the key lessons learnt during these projects. We then build upon these experiences to propose an empirical and pragmatic model for ALS delivery. The model will be valuable to designers, implementers and end-users of ALS interventions and systems.
ALS implementation experiences
Case study: Designing a lifetime living space for a young adult with tetraplegia
Living space design requirements
Following a road traffic accident, a young adult with high-level tetraplegia and complex care needs required the building of a new house for her family, with an adjoining bungalow as a living space for herself. The bungalow was required to be a fully adapted accommodation to cater for her needs and had to be designed for long-scale, lifetime use. The homes were to be part of a local development of new houses. The bungalow was designed to be centred on a large bedroom, with doors to a large wet-room, a living-room and a study. A tracking hoist was required throughout the bungalow. All doors to the bedroom had to be automated, as were all windows, blinds and lights. In addition, a door led directly from the bungalow bedroom to the hall of the main house for convenient access to the adjacent family house. A multi-room, multi-media system (MMS) was also to be installed. It was recognised from the outset that the user’s interaction with her environment was likely to change over time, as she was still a young adult. The environment needed to take into consideration natural changes associated with the ageing process throughout adulthood, thus the system needed to have the flexibility to address these key aspects. It was also recognised that the end-user’s family may not occupy the adjoining house at all times. Therefore, the ALS system also needed to integrate safety-monitoring features to allow the end-user to live more independently.
Additional complex care requirements
As the result of spinal cord injury, the user was susceptible to autonomic dysreflexia. The condition triggers over-activity of the autonomic nervous system as the result of a strong sensory stimulus below the level of spinal cord injury. The stimuli are blocked by the lesion at the level of injury and cause a reflex reaction leading to spasms, narrowing of blood vessels and a rise in blood pressure (hypertension). In turn, this can lead to a slowing of the heartbeat but blood pressure cannot be regulated as the stimuli cannot travel below the level of injury. The range of possible symptoms includes nausea, sweating, pounding headaches, flushing and blotching of the skin, and restlessness. These symptoms can develop suddenly and the condition can lead to a possible emergency situation, leading to seizures, stroke and even death. The condition caused some degree of anxiety to the user—being both a perceived and genuine risk—so the bungalow needed to be fitted with air conditioning units in the bedroom and the living room, to allow for immediate and rapid cooling of room temperature at times of distress.
Implementation
A full KNX i infrastructure was incorporated to provide control of automation, central management of remote functions and the potential for safety monitoring. Infra-red (IR) receivers would provide the user with control of all aspects of the property management system from anywhere in her bungalow, ensuring maximum independence for the user. IR receivers were installed in every room, allowing her to interact via an environmental control system (ECS). An ECS enables individuals to operate domestic appliances and other functions by remote control through use of a switch system. An ECS was a key aspect in reducing the round-the-clock care needs of the end-user. An ECS with a large capacity for IR codes and significant radio capability was selected. The relevant KNX codes were loaded into the system and mapped onto the corresponding functions. Codes for disabling the door automation were included to allow the user to select the option of having the doors opening automatically or on-command via the ECS. In addition, this feature could be set globally for the whole living space or on a door-by-door basis. This was intended to minimise the potential disruption resulting from automatic doors operating inappropriately. The multi-media system was not directly compatible with KNX, so an interface was implemented directly between the ECS and the MMS. Linskell developed the functional specifications of the KNX system, liaised with the installer and supervised the commissioning of the KNX installation. He also provided and configured the EC system.
Case study and usability of the ALS
The inclusion of the air conditioning units in the living space enabled the user to rapidly set the temperature of an area prior to entering that space. This feature of the environment gave the user the confidence to use the entirety of the living space. Some usability issues with the living environment were quickly identified in the short term. Firstly, there were several automated doors in close proximity, leading out from the bedroom. Both the user and carers felt that the doors’ constant reaction to movement could be irritating, so it became clear that a mechanism for door-management was required. A solution was identified (described above). However, several additional usability issues within the environment were also identified.
The infrared receivers had very small and orientation-specific reception areas. This required the standard transmitter to be pointed directly towards the receiver. This meant that although the ECS IR transmissions were of high quality, the system was not providing reliable control. The contractor had failed to take into account the fact that the physical-impairment of the end-user would prevent her from pointing a device directly at the IR receivers. Consequently, we had to convince the contractor to replace the existing IR receivers with a different, more suitable type of receivers (i.e. with a broader reception area).
Following on from the initial system delivery, the altering and adjusting the ALS system was a very slow process. While adjustments were potentially in line with conventional expectations of services delivery in a private and domestic context, the contractor seemed to not fully appreciate the end-user’s level of dependence on the ALS system and the resulting burden of delaying the required adjustments, despite stressing to the contractor at the outset of the project the need to provide an exceptionally responsive service.
The decision to include a MMS came late in the ALS design. The choice and installation of the MMS was not adequately discussed with all the stakeholders and this resulted in substantial system interoperability issues. The only interface to the MMS was a proprietary, touch-sensitive tablet-personal computer device. The end-user could not operate this device owing to her physical impairments. The MMS did not have a KNX-compatible gateway, so it could not directly be integrated in the EC system via IR codes. This technical mismatch was eventually satisfactorily resolved via the development of a special-purpose interface between the MMS and the EC system. However, this resulted in significant time and effort overheads for the ALS implementers and the MMS provider before an appropriate solution could be delivered.
There was a significant challenge associated with the large number of IR codes that the ECS controller needed to incorporate and the number of menus necessary to accommodate these. While, in this case, the end-user could use the technology with confidence, the menu system had to be designed with care in order to efficiently accommodate the control of the system via single-switch scanning. ii
Some important lessons learnt
The first two points above highlight the importance of all stakeholders having a shared understanding of the context of the use of technology and of services delivery in assisted-living scenarios. This is all the more important in situations where the end-user is a highly dependent or vulnerable individual with complex needs, as was obviously the case here. In addition, with regard to the third point, when working with the MMS supplier to develop an interfacing solution, Linskell had to guide the supplier in using a minimal compatible instruction set via the ECS control. Again, this highlights the importance of equipment suppliers understanding the use of technology in context instead of focusing on technical functionalities. To put it another way: while technology suppliers can sometimes feel confident that they are capable of delivering technological services and solutions within conventional delivery models, this can quickly unravel when faced with atypical users in atypical scenarios. These aspects clearly mirror some of the challenges highlighted by the JIT in their summary of telecare services deployment, 7 which we summarised above.
The third point also demonstrates the importance of communication and consultation with all stakeholders. The central coordination of all decisions pertaining to technology integration in an ALS is also essential, especially when non-interoperable, proprietary technologies are likely to be used in a central environment control system. Again, these aspects have also been raised by the JIT. 7
A proposed ALS design and delivery implementation model
In light of our experience of delivering technology-supported ALS, we propose a model to describe the process of designing and delivering ALSs in complex-needs scenarios (Figure 1). This empirical model follows well-recognised principles of user-centred design models, such as participatory design, 10 focusing on identifying and engaging effectively with all the stakeholders of the ALS, responding effectively to expectations and needs, maintaining a dialogue throughout the design process, and iteratively develop adequate solutions to meet all the identified requirements.
A proposed step-wise model for assisted-living space design and delivery
Design and delivery model
The ‘direct’ ALS delivery route (DDR)
When a living-space is purposely constructed for individuals with special needs, specialist adaptations are required to support their needs. A report will be drawn up by an appropriate clinical practitioner, usually an occupational therapist. This report will state the identified needs of the end-users, the associated services required and some suggestions of adequate solutions. The aim of the report is, in part, to assist in the separation of generic special needs and specific needs related to personal care. The funding for these two distinct aspects of needs is usually divided between capital and care budgets, usually referred to as ‘stage 2’ and ‘stage 3’ adaptations respectively. After review, if the commissioning team accepts the needs report, the document will be handed to a contactor. The contractor will study the documents and propose corresponding solutions which will be incorporated into the complete ALS design. This effectively translates into the contractor taking a direct route from the initial step 1 (needs requirements) of the model presented in Figure 1 straight to step 4 (technical specification). From our personal experiences, these ‘direct’ ALS delivery routes can work effectively in situations where the end-users’ needs are clearly specified and the corresponding solutions are relatively straightforward or previously known to the contractor.
However, our experiences suggest that in cases where the end-users’ needs and services are complex and the corresponding technologies are equally complex, unfamiliar or not previously known to the contractor, then the ‘direct’ ALS delivery route is often littered with pitfalls as a result of the multiple potential sources of implementation failure, thus/then misunderstandings and misinterpretations of expectations and requirements among the ALS stakeholders are all too common. Again, these points have also been identified at a macro level over the course of the Scottish TDP. The failure of technologies to map effectively to complex needs requirements can effectively negate most, or all, of the benefits that were initially expected from the ALS deployment.
We further argue that ALS implementations via the ‘direct delivery route’ can fail for any of the following reasons listed below.
The needs report is not sufficiently detailed and lacks specificity, resulting in coarse-grained and inadequate implementations.
The needs report makes erroneous assumptions on potential technological solutions, which will translate into non-optimal implementations at best or technology failure at worst.
The needs report assessor misunderstands the advice and/or the solutions suggested by the contractor (i.e. because of unfamiliarity with some of the terminology, a lack of knowledge of technology and equipment, etc.).
The needs report is not well understood by the contractor and some statements and nuances are not fully appreciated (i.e. as a result of unfamiliarity with some of the terminology, a lack of knowledge of health or social care, physical impairments and conditions, special needs, etc.).
The contractor misunderstands, or does not fully appreciate, the needs of the end-users; the contractor makes inadequate assumptions on levels of priorities during ALS implementation (i.e. resulting in lower priority implementations being completed first as they are more convenient for, or actionable by, the contractor).
While the contractor understands the end-users requirements, this knowledge is not adequately transferred to people at the operational level (e.g. suppliers, sub-contractors). There can also be some misunderstandings between the person negotiating on behalf of the contractor and his own operational, on-site managers if they were not involved in the initial discussions. Thus, the initial requirements and specifications are lost or altered when passed on to those providing the end-systems installations, as these individuals have not been involved in detailed ALS design discussions and/or inadequately briefed.
Our personal experiences echo the JIT generic observations on telecare services implementations challenges 7 and suggest that the above list of failures in the ALS delivery chain may be common. Many non-specialist contractors remain unfamiliar with the installation of ALT and, indeed, the design and the delivery of ALSs.
The ‘step-wise’ ALS delivery route
As an alternative to the direct delivery route, we propose an alternative step-wise delivery (SWD) model. In this procurement delivery route, all the processes which contribute to the systematic understanding and specification of needs and avoid the misspecification and misinterpretation of requirements are broken down into individual constituent steps, including: task analysis (step 2), functional specification (step 3) and technical specification (step 4). The transitions between each step are critical juncture-points (visually represented in Figure 1 by the breaking chains) at which potential erroneous requirements are introduced or inadequately specified. These juncture-points are critically important because they occur at the interface between the responsibilities and remit of the various stakeholders involved in the ALS development. It is therefore essential to facilitate and operate a full, complete and adequate knowledge transfer of the ALS design requirements and specifications at all of these stages.
Discussion and ALS design recommendations
To conclude this article, we discuss, in turn, each step of our proposed ALS delivery model for complex needs and summarise our empirical knowledge of implementations as a list of practical ‘Do’s’ and Don’ts’.
Step 1: End-users and carers needs analysis
This step relates to all aspects relating to the specific support required by the ALS end-users. Stakeholders should be able to engage openly in thinking aloud about support requirements, without being prejudiced by their (potentially lack of) technological knowledge. However, the discussions at this stage may be limited initially, as the full benefits potentially delivered by the technology may be unknown to the stakeholders. Therefore, this step may need to be iteratively refined as stakeholders progress though the design process.
Do:
engage stakeholders in brainstorming on the needs of the end-users;
be clear about the main needs, priorities and goals of the end-users;
identify and directly engage with as many stakeholder groups as possible, and identify and liaise with technology champions’ within these groups;
allow for, and accept, a healthy level of scepticism from doubters at this stage.
Don’t:
allow information-gathering exercises being restricted by the format of existing ‘assessment documentation’;
allow—as much as possible—overwhelming and potentially intimidating references to technology during the initial exchanges with stakeholders, particularly if there are important gaps in technological literacy levels across stakeholders (i.e. end-users vs. technology providers).
Step 2: Task analysis
This step relates to the expected support to be delivered to the stakeholders. It includes what would staff on the ground actually do, or should do; what decisions need to be reviewed at a more senior level; and what the processes in place are to facilitate and ensure sound and complete information-sharing.
Do:
identify all the potential tasks required to deliver the targeted support before breaking the tasks down into their constituent parts;
identify every single step in each task—no matter how obvious this may seem—with simulated walkthroughs if necessary;
confirm with stakeholders that the selected tasks—and their implementation methods—meet the identified care needs;
be aware of indications at this stage of the process that the preliminary user and carer needs assessment requires further refinement. This highlights the essentially iterative nature of the model and should be seized as an opportunity to further refine the initial step of the needs-analysis.
Don’t:
make any assumptions, even about seemingly obvious steps.
let this process become a focus for stakeholders’ dissatisfaction with current services or existing practices.
Step 3: Functional specification
This step relates to all aspects of end-users’ support that are amenable to technology enhancement. This is a structured statement of the previous task analysis and needs to include all the specific functions required to deliver the expected support to the end-users.
Do:
ensure that all stakeholders have a complete and agreed shared understanding of all terms and concepts used in the functional specification. This shared understanding needs to be formalised, structured and fully documented, and include perspectives from both health and social care services and technology providers;
ensure at this stage that all conflicts identified between the various tasks are resolved and their dependencies clearly documented;
ensure that the functional specification delivers a holistic solution to all the tasks identified in step 2.
Don’t:
make any assumption on the terminology used, as substantially diverging meanings may apply in a health, medical, social or technical context;
postpone conflicting priorities resolution, or terms and concepts disambiguation at this stage. Avoid making the assumption that these issues will be satisfactorily resolved further down the line during the ALS implementation. This will effectively delay identifying suitable solutions early on and is likely to lead to more difficult, ad hoc and expensive interventions to resolve all the remaining issues during system configuration.
Step 4: Technical specification
This step relates to the description of how the technologies will effectively implement all the functional specifications defined in step 3. This requires the mapping of functions to the technical solutions and devices that provide them. At this stage, the technology-provider should be asked either to demonstrate the required capabilities of the technology or to formally document how the functional specifications will be fulfilled by the technology.
Do:
ensure that that all devices and systems can individually deliver the expected functionalities;
ensure that all constituting technological components can be integrated to provide a holistic system as specified in the functional specification;
define milestones for testing and approving the progress of requirements at this stage if it is identified that a degree of equipment customisation or development will be required to meet the functional specification;
ensure that the technical specification delivers the identified functional specifications as a holistic solution;
ensure that a risk-analysis and management document is included in the system specification at this stage of the ALS design process.
be aware of situations where technology-providers use commercial or technical confidentiality claims to avoid providing advanced details of technological solutions. Unless, the technology is currently subject to a pending patent, appropriate non-disclosure agreements between the purchaser and provider of the ALT would normally suffice in these cases.
Don’t:
rely on assurances from technology providers that the technical specifications can, and will, be met. It is critical at this stage to anticipate and prevent technical improvisations that may lead to unacceptable compromises in critical aspects of the ALS design, particularly if these mean that they fundamentally impact on the quality of life of end-users, their families and carers;
Step 5: Contracting
This step relates to the process of purchasing the necessary services for the technology installation and configuration. At this stage, decisions ought to be taken by individuals who fully understand both the technical specification (step 4) and the functional specification (step 3) from which it derived—this process needs to be thoroughly documented. There needs to be a clear demarcation between equipment installation (related to step 4) and appropriate system configuration (step 3). This is critical to enable later identification of the potential causes of any system failure to deliver the functionalities and services expected.
Do:
ensure at this stage that all the contractors’ worksheets fully and adequately meet the technical specification;
ensure that all terminology used is defined and that there is a shared understanding between all stakeholders;
ensure that any deviations from the technical specification have been reviewed and approved by the planning team, and that these decisions are fully documented.
Don’t:
rely on third-party, local interpretations of the contracting or technical specification documents; implementations must be as specified in the ALS system documentation—this is absolutely critical;
rely on third-party, local interpretations of priorities in the ALS system implementation. Again, this is critical.
Conclusions
Our proposed step-wise delivery model of ALS systems for end-users with complex needs iteratively moves from high-level descriptions of needs to increasingly detailed, operational requirement specifications. Errors and communication breakdowns will occur typically at the transition points, where information and responsibilities are transferred between the various stakeholders. Our proposed model provides a template allowing stakeholders to specify their understanding of the ALS delivery chain from their respective points of view. It facilitates the identification of potential sources of misinterpretations and inadequate specifications throughout the delivery process. The proposed model allows stakeholders to identify project-specific requirements, adequately allocate tasks and responsibilities, and identify appropriate technological solutions for the delivery of functional ALS systems. The model is generic and makes no assumptions on needs or technology solutions, or, indeed, on the technical knowledge, skills and experience of the stakeholders involved in the ALS design process.
Footnotes
Funding
Dr Bouamrane’s research is funded by the Scotland Chief Scientist Office (CSO)/Scottish Health Executive through a personal training and research fellowship in Health Informatics and Health Services research (February 2010–January 2013).