Abstract
The aim of this paper is to investigate the technological feasibility of integrating e-health solutions as an aid to the health monitoring of patients in their own homes. The approach taken to this task is based on system engineering from which models are produced to indicate how home-based health care may be envisaged. The model outputs indicate that electronic health methods and its associated technologies offer a future where health care remains affordable.
I. Introduction
The UK National Health Service (NHS) is arguably one of the United Kingdom’s better achievements. Since its introduction in 1948, the health of the general population has seen some remarkable improvements: the average life expectancy for men and women has increased by 18.5% and 16.8%, respectively; the mortality rates for infants have fallen by 87%; and the average life expectancy over the age of 65 years has increased by approximately 40%. 1 These, and other unstated improvements, have been delivered despite a population increase of 38% 2 which adds to the cost burden of providing a first class, free at the point of health-care system. When investigating the population increase in finer detail, it is clear that there are additional factors to consider: not only is the population increasing, but its average age is also going up – in 2010, there were 19 million people aged 60 years or over in the United Kingdom, and by 2020, this figure is expected to rise to 22.5 million. This projected increase of 18% needs to be interpreted in conjunction with an expected increase of 0.7% (25.2–25.4 million people) of those in the 15–44 years age range over the same time period. 2 As one of the main demographics for hospital admission is the over 60s, the financial cost associated with health-care delivery needs to rise year on year to keep pace with likely demand. But as we have just seen the main tax burden to pay for this increase will fall on a smaller proportion of the population. Something has to change in this system for the NHS to keep its position as the envy of the Western world, but at the same time, the system needs to be affordable. If the NHS does not change how it operates, it is on course to need an extra £30 billion per year by 2020. 3
As a response to increasing NHS health-care costs, length of stay in hospitals (the most costly component of an acute clinical condition that requires NHS intervention) is reducing, meaning there is an increased burden on maintaining health status at home. To assist with this organisational change, a new market has opened up for health-assist devices and clinical monitoring equipment that patients themselves can use at their own home. It is the opportunities exploited by this market for novel health-care devices that is the focus of this paper; especially their requirements, architecture and design considerations.
II. Electronic Health Method Aspects
Electronic health methods (e-health) provide one technological approach to the delivery of home-based health care where, here, it is defined as an umbrella term that encompasses telehealth and telecare and all services that contribute to their operation. There is a range of bespoke devices available that have been designed for home-based health monitoring; some simple devices such as wearable wrist bands that have sensors embedded within them to measure number of steps taken, heart rate, quality of sleep and GPS data to offer information on exact location; some more integrated devices such as those offered by Docobo that offer ‘… digital health solutions that fully support integrated care, business intelligence and remote home management of patients with long-term health conditions’. 4 Soreon Research has predicted that while currently small, the medical wearable market (a sub-set of e-health solutions) will increase very quickly over the next 6 years – from US$2 billion in 2014 to US$41 billion in 2020. 5 It is clear that the e-health market is ripe for development and has an opportunity to play a major role in any re-designed NHS.
Currently, e-health methods and services provide a delivery mechanism for clinical trials associated with national and international research programmes that seek to establish home-based health care as a means to promote ‘wellness’ as well as respond to ‘illness’. An example of such work is the European Union (EU)-funded Ambient Assisted Living (AAL) programme. The AAL concept involves the following:
To extend the time people can live in their preferred environment by increasing their autonomy, self-confidence and mobility;
To support the maintenance of health and functional capability of elderly individuals;
To promote a better and healthier lifestyle for individuals at risk;
To enhance the security, to prevent social isolation and to support the maintenance of the multi-functional network around the individual;
To support carers, families and care organisations;
To increase the efficiency and productivity of user resources in the ageing societies. 6
Although not strictly related to NHS re-organisation, AAL demonstrates the wider thinking that is involved when providing e-health solutions.
III. System Approach: Requirements
System requirements define what the customer wants the system to do. When there is more than one customer (stakeholder) such as in NHS re-organisation, requirements can be complex and contradicting. Recognised stakeholders for a home-based health-care system include the NHS, the patient, the patient’s family, carers, medical practitioners, primary care trusts, technology companies, manufacturers and government.
There are different types of requirements: the operational requirement is a single statement that defines the major purpose of the system together with key constraints; functional requirements are those requirements that demonstrate what the system must do to achieve the operational requirement (note that it does not include how this function should be done); and non-functional requirements are those requirements that would add a constraint to the system. For the home-based health-care system under consideration in this paper, the operational requirement is given as A technology-led system that allows individuals with medically recognised conditions to remain in their own homes during times of health uncertainty.
This statement is valid as the main aim of the system under development is to act as an alternative to a hospital admission and respond to early hospital discharge through the judicious use of appropriate technology. The ‘health uncertainty’ phrase is designed to be as vague as possible so as to increase applicability. Note that the statement makes no mention of a solution; again this is deliberate so as to enrich the list of candidate solutions.
The functional requirements captured from the stakeholders include the following:
The system must receive data from a device and/or patient;
The system must store the data received;
The system must be able to transmit the data captured long distances;
The system must be able to display data to the patient or carer;
The system must be able to display data at remote locations to clinicians;
The system must be able to analyse the captured data on-site at a remote location;
The system must be able to send the captured data (raw and analysed) to an output device.
The non-functional requirements captured from the stakeholders include the following:
The daily cost of the service within which the system operates must be cheaper than the current NHS-based alternative;
The measurements taken must be clinically traceable to a standard and have a tolerance of ±5%;
The frequency of measurement must be appropriate for patient need (condition specific);
The transmission of data must take place in a time frame appropriate for patient need (condition specific);
The system must be able to display and store data captured over 4 weeks on-site;
The system must be intuitive to use, so that at least 90% of first-time users can use the system unaided and without additional help;
The system must adhere to relevant standards and codes of practice for device registration and signal transmission.
These requirement statements are used throughout the design process to validate (‘have we built the right system?’) and verify (‘have we built the system right?’) candidate solutions and their components.
IV. System Approach: Architecture
The next stage in the system approach is to consider the architecture of the system. The system architecture is a conceptual model that defines the structure and behaviour of the system of interest and is usually depicted by diagrams either using the Unified Modelling Language (UML) or the System Modelling Language (SysML), where the latter is an extension of the former. In this application, the architecture is depicted by UML diagrams. Table 1 shows the 13 types of UML diagram available and their inter-relationships, where it can be seen clearly that the first bifurcation delineates structure-based conceptual diagrams from their behaviour-based counterparts.
UML (v2.0) diagram types
To indicate the importance of a system architecture, think of an example from a discipline where use of an architecture is familiar – the construction industry. Builders use architectural blueprints to construct buildings; where the more complicated the architecture, the more critical the communication between architect and customer, so that the correct instructions (customer requirements) are relayed to the builder via the architect’s blueprint (diagrammatic representation of those customer requirements). Now, consider the UML diagrams as the architectural blueprints for the system engineer.
To illustrate the system architecture of the home-based health-care system, a sequence diagram will be used – see Figure 1 . As seen from Table 1 , the sequence diagram is an example of an interaction diagram and is thus dynamic in nature. The sequence diagram shows details of how operations are performed together with what messages are sent and when. Emphasis in a sequence diagram is on the order of interactions between different components of the system.
UML sequence diagram – the measurement of blood pressure
Blood pressure measurement is a core data item that would be on any health-based minimal data set. The interpretation of the UML sequence diagram is almost intuitive with actors from the system architecture Use Case (not shown) being transferred to the sequence diagram (‘Medical Practitioner’ and ‘Patient’ stick figures): this defines the two classes of user that interact with the measurement of blood pressure. The shaded rectangles (‘Blood Pressure System – local’ and ‘Blood Pressure System – remote’) indicate two variants of the same system, one located in the patient’s home and one located in the medical practitioner’s desired location – usually the general practitioner (GP) surgery. There are also two process sequences: one is a monitoring ‘loop’ which operates automatically, in this case every 60 min. Note that if the blood pressure remains within a pre-set patient-specific ‘normal’ range, there is no interaction with the medical practitioner. It is only when the measure is out of range that the second alternate loop (‘alt’) is activated, and the medical practitioner receives an ‘alert’ for an action to close the decision-making loop.
The sequence of actions are also defined in this diagram: ‘request measurement’ occurs every 60 min; ‘collect measurement’ is the process that returns the updated blood pressure measurement when a request is made; these data are then encrypted and stored locally, with encrypted data also sent to the remote server. At the remote server, the data are stored and analysed for range and trend information. If the data be out of range, an ‘alert’ is sent directly to the medical practitioner as indicated above.
Each UML diagram, there are many for each defined ‘Use Case’, is verified by testing inputs, processes and outputs against the requirements specified. At this stage, it is possible for the UML diagrams to be updated to take into consideration requirements that have not been fully accounted for in the system architecture; equally, it is also possible for the requirements to be updated as a consequence of the developing system architecture. Verification is a time-consuming and systematic activity, but well worth it in terms of maintaining a ‘live’ set of requirements and system architecture that responds to them.
V. System Approach: Design
Quality Function Deployment (QFD) is one of the methods available to transform a set of requirements into quantitative, measurable parameters that themselves can be deployed into design aspects for systems, sub-systems and component parts. A QFD tool that is often used in system design is the ‘House of Quality’ (HoQ). The HoQ comprises a number of transformations of data that commences with customer wants that are given a number between 1 and 10 to indicate relative importance. The output is a list of engineering characteristics that are also scored on a scale of 1–10 for technical difficulty and risk.
So, once the updated requirements have been deployed via the QFD analysis, the output is an ordered list of required functions that the designed system should have. The next stage is to take these functions and uncover a set of candidate solutions that can be implemented in a functional design. One method for achieving these candidate solutions is ‘Functional Means Analysis’ (FMA). This method employs group-based idea generation to establish the candidate solutions – that is, the ‘means’ of achieving an implementable solution. In the initial phase of this exercise, there are no limitations on the appropriateness of the ideas generated; the initial list generated for each of the functions in the illustrative UML sequence diagram ( Figure 1 ) is shown in Table 2 . As the content in Table 2 indicates, there are a number of ways of achieving each of the stated functions. The design team then get together to discuss each option before making a decision on which option(s) to take forward into the implementation of the system. Table 3 shows the same information as Table 2 , although this time with options chosen emboldened in a red typeface.
Functional Means Analysis (before edit)
LCD: liquid crystal display; HDD: hard disk drive.
Functional Means Analysis (after edit)
LCD: liquid crystal display; HDD: hard disk drive.
An outline indication for the choices for each function is given below.
To obtain data. The ‘sensor attached to patient’ is the main way for data to be captured automatically; it is recognised that for some data capture, the patient will need to interface with the device, either by entering quantitative data in open-loop mode or by responding to questions to capture qualitative data. The sensor inside patient was deemed to have unscalable safety issues; the video feed was likely to be too hungry for bandwidth and perhaps too intrusive, although recognising that this signal would be good to have if a specific patient is having repeated episodes of falls.
To display data locally. The liquid crystal display (LCD) screen is the main method for patient interaction with the monitoring display, to show both immediate feedback of the captured signal and any trend information available. Given that a significant proportion of anticipated users will be elderly, a human voice interaction is anticipated to aid those who have difficulty in seeing. The automated voice interaction is deemed too impersonal for the anticipated user group.
To analyse data. Both suggested methods are appropriate – perhaps pattern recognition of range data to automate the ‘alert’ messages and to perform simple trend analysis and human-enabled analysis for advanced trend analysis.
To store data. Storage via flash memory and magnetic hard disk drive (HDD) are the media suggested to store data locally and remotely; remote upload is discarded as a third storage location is unnecessary.
To transmit data. Transmission via a mobile network or Internet provides scalable solutions for this important function. Bluetooth may be a solution if the data need to be transmitted short distances (i.e. within the patient’s household), but this does not appear in any Use Case in this application. The idea of supplying a dedicated hard-line per patient is not a scalable solution.
To display data remotely. Visual display is the method chosen for investigating the data remotely; aural display was considered, but as the patient is already interacting with the device in a number of ways, it was thought that an aural display just repeated the interaction in a different form. The live video feed did not scale up and was bandwidth hungry, so it was discarded as a method to display data remotely.
With the caveat that a full description of the concerns with respect to choice of means is not possible in the space available here, a set of implementable functions can be verified once again against the requirements. This is achieved in a similar way to that already reported for verifying the system architecture. Once implementation is underway, validation of the system can be undertaken. It has been shown in a similar system to the one anticipated here, that hospital admissions can be reduced by 75%, 7 which indicates the worthiness of the system intervention.
VI. Conclusion
The purpose of this paper was to demonstrate the utility of using a system engineering approach to uncover the design considerations for a home-based health-care system. A complete description of the system intervention was out of the question due to space limitations of the paper. However, the essence of the methods can still be gained from requirements capture, through system architecture and system design to implementable functions. Verification and validation processes have necessarily been under-represented, so it is stated here that both methods remain an essential component of any system engineering methodology. The illustrative example that runs throughout the paper is indicative of the type of application that breeds a successful intervention. Work is underway to turn the design obtained into a product that provides a telling service for those who undertake care at their own homes.
Footnotes
Funding
This research received no specific grant from any funding agency in the public, commercial or not-for-profit sectors.