Brunel Health Telematics Research Centre, School of Information Systems, Computing and Mathematics, ... Requirements are specified not only for technical.
Proceedings of the 2005 IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China, September 1-4, 2005
Towards the Design of a Generic Systems Architecture for Remote Patient Monitoring T. Bratan, M. Clarke Brunel Health Telematics Research Centre, School of Information Systems, Computing and Mathematics, Brunel University, United Kingdom Abstract— Remote patient monitoring (RPM) of vital signs offers the potential to provide high quality care to elderly and chronically ill people in their home environment, while making effective use of healthcare resources. However, among other factors, the lack of technical, clinical and organisational interoperability of RPM systems has hindered integration into mainstream healthcare. This research offers work towards defining stakeholders and their requirements for the design of a generic systems architecture that fits various types of remote patient monitoring and can be deployed in different healthcare systems. Requirements are specified not only for technical compatibility with other systems, but also for clinical and organizational compatibility with healthcare professionals’ routines and power structures. Keywords—Remote patient monitoring, requirements, stakeholders, interoperability
II. METHODOLOGY
I. INTRODUCTION Remote patient monitoring (RPM) has been receiving increasing interest for its potential to provide care to chronically ill and elderly people who require medical monitoring but wish to remain in their usual environment [1,2]. In addition, we have investigated the benefits of use in residential and nursing care facilities, where there is a large dependent population without immediate access to specialist medical care. In the context of this research, RPM is defined as the monitoring of vital signs in a setting other than a hospital, using information and communication technologies to transfer data over geographical distances. One of the driving forces for RPM is the change of demographics in many Western countries with an increasing elderly population, and the need to provide cost-effective care for this age group [1]. Such programmes have been in place for some time now, however, despite the potential of RPM, many have not been well integrated into mainstream healthcare. This is thought to be due to a mix of factors, including clinical, technical, human, organizational, financial and legal/ethical. This paper argues that RPM systems need to be technically compatible with other systems [3], clinically compatible with healthcare professionals’ routines and power structures [4], and compatible with organisational strategy. The design of system architectures is often given insufficient consideration when establishing a remote patient monitoring service, which might not only lead to poor design and difficulties in implementation; but, more importantly, result in the 0-7803-8740-6/05/$20.00 ©2005 IEEE.
development of a service that does not fulfill technical, clinical, organisational or user requirements. Therefore, requirements for a more generic RPM system are defined, that will suit various RPM scenarios and could be deployed in different healthcare systems. RPM systems, where the term ‘system’ is used to mean a collection of components software, hardware and human - that cooperate in an organised way to achieve a desired result [5], will be based on such a single, carefully designed architecture that incorporates stakeholder requirements. The generic system architecture must be designed systematically and be based on and support standards, but at the same time incorporate flexibility so that new or emerging elements may be added.
106
The aim of the research is to work towards proposing and defining a generic systems architecture. This must include identifying the stakeholders of RPM systems and their requirements for such a generic systems architecture, as one of the inputs to define the functionality of a generic system. The approach is based on requirements engineering, which is concerned with discovering and documenting the purpose of a system by identifying its stakeholders and their needs [6]. The discipline was developed to overcome the recurring problem of IT projects failing due to problems related to the identification of stakeholder requirements, which included incomplete requirements, lack of user involvement, unrealistic expectations, and changing requirements [7]. The research of this paper is based on data gathered in designing, setting up and evaluating RPM services of the European projects e-Vital and Telecare. In addition, semistructured interviews with GP’s, specialists, nurses, and IT managers were carried out to capture generic requirements. We grouped the requirements into three categories: clinical, technical and organisational. Other issues, such as legal and financial were not considered due to the scope of the research. III. RESULTS In this section, types of remote patient monitoring are identified, then we identify the stakeholders and, finally, specify the requirements for the user stakeholders.
the community, and so is likely to be based on wireless communication.
A. Types of remote patient monitoring We have identified three distinct types of remote monitoring: chronic disease management and other regular monitoring e.g. during pregnancy; acute; and ambulatory monitoring. Diagnostics, which have a different purpose and are well known, e.g. Holter ECG monitoring, will not be considered. i.) Chronic and other disease management Technically, this is the simplest form of monitoring, and currently may be viewed as basic telemetry. Data is forwarded from the device to a data store with no processing or intelligence on a periodic and regular basis, e.g. daily. The purpose is to detect a significant change in a parameter that may be an early indicator of deterioration, and would indicate that intervention in therapy may be required. The requirement in design is to define the clinical response and the intervention in the pathway of care, and, importantly, how it may fit within the existing organisational structures. Our method is to define and describe generic processes that would then be mapped to the existing organisational structure and services. The most commonly measured data include blood pressure, weight, respiration and blood glucose, and are frequently measured by the patients themselves. Chronic heart failure (CHF), chronic obstructive pulmonary disease (COPD), diabetes and asthma are diseases chronic monitoring is frequently used for. ii.) Acute In acute monitoring, the purpose is to monitor a patient in situations where there might be rapid deterioration in condition, and that must receive prompt medical intervention, e.g. in case of an acute exacerbation of a chronic disease, for infections or after operations. Data from vital signs will need to be sent on a near continuous basis, and would include ECG, SpO2, temperature and blood pressure. The requirement in design is to ensure that the clinical response is capable of rapid intervention and would include provision of professional medical personnel close to hand. iii.) Ambulatory In this form of monitoring, the goal is to identify a critical and sudden change in the vital sign in an otherwise reasonably healthy person, such as prolonged ST segment change in the ischemic that might be the early indicator of imminent myocardial infarction. This requires that the signal be monitored continuously and algorithms be used to detect an event. The system must be capable of sending an alarm, and, ideally, data representative of the event. The system should allow the patient mobility and be designed to operate within a range of environments, such as within the home or 107
Three key purposes of remote patient monitoring were identified: a) the prevention of hospital admissions through early detection of deterioration, b) prompt hospital admissions where indicated, and c) the provision of hospital-like services in the home, which might facilitate keeping patients at home and out of hospital or early discharge from hospital and the follow-up care in the home. The aim for each is to triage cases so that resources can be allocated according to need [8], and that patients receive the most appropriate form of care for their condition. Table I summarises the three types remote patient monitoring and their characteristics. TABLE I APPLICATION AREAS FOR RPM Chronic disease management
Acute monitoring
Ambulatory monitoring
Use
Patient’s own home or
Anywhere, worn by patient
Portability
Low/medium
Patient’s own home or community setting Medium
Purpose
Prevention, early hospital admission, long-term
Hospital at home, short-term
Early hospital admission, prevention, short-term
Parameters (examples)
BP, weight, resp., glucose
ECG, SpO2, temp., BP
ECG
Diseases (examples)
CHF, COPD, asthma, diabetes
Acute exacerbations of chronic diseases, infections, post OP
Ischemia, unstable angina, pacemaker patients
Measurements
Periodic
Continuous
Continuous
Telemonitor location
Fixed
Bedside
Mobile
Staff assistance
Home: no Residential: yes
Yes
No
User friendliness
Medium
Medium
High
Alarm necessary?
No
Yes
Yes
Communications medium
POTS, ADSL, ISDN
POTS, ADSL, ISDN
GSM, GPRS, satellite
Data analysis
Often remote
Local
Local
Data transmission
On request
On exceeding threshold (automated)
On exceeding threshold, on request
Power
Mains
Mains
Battery
High
Chronic disease management and acute monitoring are home based forms of monitoring, which take place either in a patient’s own home or in a community care setting. In the latter, the telemonitor is typically shared among several people, which demands for increased portability of the equipment. As mentioned above, ambulatory monitoring is mobile monitoring and uses small, highly portable equipment. The purpose of chronic monitoring is prevention of hospitalisations, and early responses such as admission to hospital or changes in medication. Acute monitoring serves the purpose of providing hospital-style monitoring at home, with the associated prompt emergency intervention. In ambulatory monitoring, the aim is to detect and respond to an emergency situation quickly. The location of the telemonitor is normally relatively fixed in chronic disease management, and for acute monitoring it is usually placed by the bedside. For ambulatory monitoring it is worn by the patient. Since the patient does not have any assistance in using the equipment, it needs to have a high degree of user friendliness. When staff are available, such as in a care home, lower user friendliness is tolerated for the benefits of added functionality. In patients’ own homes, data transmission via the telephone line (POTS) is currently probably the best option because of its wide availability. In a community care setting ADSL or ISDN are preferable because of higher bandwidths and the number of users. Since acute and ambulatory monitoring have the purpose of enabling prompt emergency responses, data needs to be evaluated locally, and is sent on exceeding pre-defined thresholds. This is not necessary for chronic monitoring, where data transmission is usually initiated by the patient. B. Stakeholders The stakeholders in RPM systems are identified below. Several will exist in almost any healthcare system and are therefore generic. We define ‘stakeholder’ as ‘any group or individual that can affect or can be affected by the achievement of the system’s objectives’ [9]. i)
Healthcare providers (medical centres, hospitals, specialist and teaching hospitals, both public and private) ii) Insurance companies iii) Healthcare professionals (GPs, nurses, specialists, also other healthcare staff) iv) Systems managers v) Patients and their families vi) Formal and informal carers vii) Care homes and assisted living facilities viii)Commercial companies (especially medical devices manufacturers) ix) Government institutions x) Social services 108
xi) Emergency services xii) Telecommunications providers xiii)Researchers C. Requirements The generic user requirements were broken down into three categories: clinical, technical and organisational. Each of the stakeholders has their own objectives, goals and perspectives, and so the requirements are likely to be diverse. For purposes of simplicity, only the requirements of user stakeholders will be considered (here healthcare professionals and systems managers). Patients could not be consulted for ethical reasons. i.) Clinical Clinical usefulness was identified as the most important requirement of the monitoring service. For healthcare professionals to have a positive attitude towards a new system, they must perceive it as beneficial for their patients and making their working day more efficient. Therefore, most healthcare professionals asked for vital signs data to be analysed by the system, so that only significant data was forwarded to the server for human analysis. What constitutes significant data needs to be defined for each patient, and parameters need to be able to be changed remotely. Data should be presented in a format familiar to healthcare professionals. For acute and ambulatory monitoring, a 24-hour response centre is required. Compatibility with existing clinical practices is desirable, although some changes to work practices and work flow will be inevitable for effective monitoring, e.g. increased collaboration between GP’s and nurses. Clinical protocols will need to be defined and integrated into the system to minimise clinical risk and to maximise effectiveness. ii.) Technical Reliability and performance of the technology are key to increasing its usage. Therefore, systems should be robust, i.e. each component should have capabilities for self-testing, and generally be fault tolerant and require little technical assistance. Tried and tested technologies should be given preference over new technologies (e.g. GPRS over UMTS), as patient safety is of uppermost importance for the success of RPM systems. Integration with existing systems would be advantageous because it allowed sharing of data. In acute monitoring, mains powered systems also need to be battery powered in case of a power failure. Wireless data transmission is often preferable to wires, both in terms of mobility and implementation; however, there are other issues such as security and range. Systems should be intelligent and do the bulk of data analysis. The patient unit needs to have some data storage capabilities; however, in general, data should be stored on a server. It is also important that the complexity of the system is hidden from
the users, and that the system can be upgraded easily as requirements change or new technologies become available. iii.) Organisational Support from management is essential for the uptake of new ways of working, especially in a safety-critical field such as healthcare. However, it was suggested that the combination of management support (top-down), i.e. the importance for organizational strategy, together with perceived usefulness by users (bottom-up) creates the ideal climate for change. In addition, it is important that responsibility for the RPM system resides with one key member of staff. IV. DISCUSSION The large number of stakeholders and the diversity of their requirements; lack of standards and protocols; and uncertainty about other issues such as clinical benefits and technical reliability, all contribute to the complexity in designing and implementing RPM services [7]. However, in order to integrate these services into mainstream healthcare, so that its potential can be maximised, RPM systems need to be technically, clinically and organisationally compatible with other systems, with healthcare professionals’ ways of working and with organisational structures. This research has categorised RPM services into three types and defined them. The systems have sufficient commonalities to be based on a shared, generic systems architecture, which supports various RPM scenarios such as chronic, acute and ambulatory monitoring in different settings, e.g. in the home or in a community environment. When systems are designed based on such an architecture, the required architectural components will be selected, ensuring technical compatibility with other RPM systems, and depending on further work, integration with other health information systems. Building certain common technical, clinical and organisational requirements into a generic systems architecture will also lead to greater clinical and organisational compatibility. In this paper, we have identified a number of generic requirements that would need to be incorporated into such a generic architecture. V. CONCLUSION This paper has proposed work towards categorizing remote patient monitoring, identifying generic stakeholders and their requirements for a generic systems architecture. In fact, for industry-wide interoperability, which should be the ultimate aim of these efforts, a generic systems
109
architecture for the whole healthcare sector should be the aim. This becomes easily apparent when considering that data gathered through remote patient monitoring needs to be available not only to the healthcare professional evaluating the data, but may be required at a later stage by another surgery, a hospital, or may be made available through an ehealth website for patient self-management. Additionally, electronic patient records need to be accessible across the whole healthcare sector. Therefore, it is argued that the healthcare industry is unlikely to mature without the development of standards and generic architectures. ACKNOWLEDGMENT The authors thank the staff at Hospital Clinic, Barcelona, Chorleywood Health Centre, Chorleywood, New Road Surgery, Croxley Green, and the partners from e-Vital and Telecare. REFERENCES [1] V. Rialle, F. Duchene, N. Noury, L. Bajolle, J. Demongoet. (2002). Health Smart Home: Information Technology for Patients at Home. Telemedicine Journal and e-Health [Online]. 8 (4), pp. 395-409 Available: http://www.liebertpub.com/publication.aspx?pub_id=54 [2] B.G. Celler, N.H. Lovell and D.K.Y. Chan, (1999). The potential impact of home telecare on clinical practice, [Online]. Available: http://www.mja.com.au/public/issues/171_10_151199/celler/ celler.html#fig1 [3] K. Lunn, A. Sixsmith, A. Lindsay, M. Vaarama. Modelling Telecare services requirements for older people using the Unified Modelling Language. [Online] Available: scom.hud.ac.uk/scomkl2/prism/Papers/TelecareModelingShort.do c [4] P. Lehoux, C. Sicotte, J.-L. Denis, M. Berg, A. Lacroix. (2002). The theory of use behind telemedicine: how compatible with physicians’ clinical routines? Social Science & Medicine [online] 54, pp. 889-904. Available: http://www.elsevier.com/locate/socsimed [5] M. E. C. Hull, K. Jackson and A. J. J. Dick, 2002, Requirements Engineering. Springer, London, p 5. [6] B. Nuseibeh, S. Easterbrook, “Requirements Engineering: A roadmap” in Proceedings of the Conference on The Future of Software Engineering, 2000, Limerick, Ireland, pp.35-46 [7] M. E. C. Hull, K. Jackson and A. J. J. Dick, 2002,Requirements Engineering. Springer, London, 2002, p.3 [8] G. Williams, K. Doughty, D. Bradley. (1998, March). A Systems Approach to Achieving CarerNet – An Integrated and Intelligent Telecare System. IEEE Transactions on Information Technology in Biomedicine. [Online]. 2(1). Available: http://ieeexplore.ieee.org [9] adapted from R.E. Freeman, 1984, Strategic management: A stakeholder approach. Cambridge, Mass., Ballinger Publishing Co., p. 46
