approach has been to develop these tools using as far as possible, open standards ... implemented a software monitoring and alert system, for use with the HTS.
1 of 4
A Home Health Monitoring System Including Intelligent Reporting and Alerts H. Garsden 1, Member, J. Basilakis 1, B.G. Celler 1, K. Huynh 1, N.H Lovell 2,3 Senior Member 1
2
School of Electrical Engineering, University of New South Wales, Sydney, Australia Graduate School of Biomedical Engineering, University of New South Wales, Sydney, Australia 3 NICTA, Sydney, Australia
Abstract— We describe the design and implementation of an intelligent reporting and alerts system that has been designed with a specific goal to address the needs of managing chronic and complex disease through the use of home telecare technology. Our approach has been to develop these tools using as far as possible, open standards. Clinical measurement data gathered using home telecare and stored in a relational database in XML format is extracted and converted into a Clinical Document Architecture (CDA) as defined by the Health Level 7 (HL7) organization. Data trends are presented to the clinician as simple graphs and summary statistics (means, standard deviations) over time for an individual patient. Clinicians may receive this data by display through a Web-interface or by email or faxed reports. A Ripple Down Rules (RDR) knowledge base supports more complex decision-making provided in the Alerts module. The RDR output is incorporated into the output reports as a textual statement, and/or a graphical highlighting of key parameters in the trends images and tables. Rule development and validation is part of ongoing research. Keywords— clinical measurements, home telecare, knowledge management, ripple-down rules, XML, HL7 I. INTRODUCTION Home telecare is the use of information, communications, measurement and monitoring technologies to evaluate health status and deliver healthcare from a distance to patients at remote locations [1]. Home telecare has significant potential for contributing to the management of patients with chronic disease as well as at-risk elderly people living alone at home [2]. Usability and clinical trials of home telecare technology have demonstrated wide acceptance of the technology by users [3] and enormous potential cost benefits in specific chronic disease target populations – for example, congestive heart failure (CHF) [4]. A home telecare system (HTS) has been developed at the University of New South Wales over a period of more than five years [2,3]. A clinical trial in 2001-2002 funded by the Australian Commonwealth Department of Health and Ageing demonstrated that the system was acceptable and useable by patients and clinicians alike, and provided high quality data from the home.
The database storage of longitudinal patient data introduces new ways to improve the quality and variety of information about a patient’s health status to the clinician. Measures of physiological monitoring can be translated into accurate predictors of health risk - this information is invaluable in identifying and treating problems, sometimes at an early stage. To make use of the collected patient data we have implemented a software monitoring and alert system, for use with the HTS. The system can monitor patient health data over time and produce graphical and statistical summaries that allow comprehensive monitoring of vital signs and recognition and alerting of potential patient problems. This is useful because: • It will save time • It will enable clinician’s to be presented with summary reports that aggregate large amounts of patient data • Feedback has been shown to influence clinician behavior [5]. It is envisaged that these benefits will allow clinicians to provide better care to patients. The system uses knowledgebased rules for the alerts, and statistical analysis for the trend summaries. We describe the system architecture of a knowledge management and intelligent reporting tool, customized for use with home telecare data, and based on industry standards for data representation and data exchange. II. METHODOLOGY The reporting system is depicted in Fig. 1. We focus on the Trends Path and the Alerts Path. Data is taken from the patient database, which consists of parameters extracted from the raw signals of vital signs, going back as far as the patient has been in the system. Parameters are, for example, heart rate, lung capacity, blood pressure (systolic/diastolic) and blood oximetry. The Trends Path performs statistical analyses and summarizes the results. The Alerts Path uses a rule-based system to generate clinical warnings and alerts, which are merged with the statistics and displayed in a variety of representations. The information extracted from the patient database is also converted into a Clinical Document Architecture (CDA) file [6] for exchange with other systems. The CDA format is defined by the Health Level 7 (HL7) organization representing clinical data, and is similar in many respects to an electronic health record. It can be digitally signed with
2 of 4 Future Patient Database
XML Database
CDA File
Convert to XML
XML Pip el ine
Apply Statistics Trends Path
HTS Patient Database
Apply formatting
(MS SQL)
Convert to XML
Apply Rules
PDF File
HTML report
Alerts Path
Fig. 1. Architecture of the reporting system integrated into the home telecare system.
potentially multiple embedded digital signatures (using XML Signature specifications) to indicate that a report has been viewed and authorized. Such a workflow is obviously important for demonstrating a duty of care by the clinician.
vital capacity (FVC), forced expiratory volume (FEV1), percentage of oxygen saturation in arterial blood (SaO2), diastolic and systolic blood pressure (BP), pulse rate (PR), weight, temperature and blood glucose level are provided.
A. Trends Path
B. Alerts Path
After the patient data is converted to XML format, various tools can be used to transform and summarize the content. In general we use XML/Java tools provided by the Apache Foundation. Generally an XML file is generated from relational table data and is passed through a pipeline of transformations to generate page results. Simple statistical calculations like mean and standard deviation are provided by SQL functions. The generated Web pages contain HTML display tables of data and statistics that summarize the trends of the various vital signs over time. Similarly, the Scalable Vector Graphics (SVG) format is used to generate the graphical images needed for display purposes. PDF pages identical to the Web pages can also be generated using the XSL Formatting Objects (XSL-FO) specification for emailing or faxing to clinicians. Fig. 2 shows an example of the blood pressure trend graph produced in the output pages, covering a period of three weeks. The double-sided vertical arrows indicate the systolic/diastolic blood pressure ranges while the dotted line indicates the pulse rate. The statistical summary of the same information is shown in Fig. 3, as it appears in the report. The initial aim of this system is to display simple statistics (means, standard deviations) over time for an individual patient. In future it may be possible to undertake more formal longitudinal analysis within patients and across the entire database [7]. The clinician can configure which clinical measurements are displayed in the trends. While this is normally disease specific, by default, measures of forced
The same longitudinal data that is displayed to the physicians can be analyzed to generate alerts, for example to indicate a gradual increase in weight or sudden change in blood pressure or the onset of an arrhythmia. The intention is to create an expert system that analyzes the trend data and alerts the physician to any conditions that are of interest or concern. Similarly, the same expert system will be used to generate a summary report of the data analysis to be included together with the graphs and tables that make up the trends section of the report. Ripple-Down Rules To implement the expert system we chose ripple-down rules (RDRs) [8]. RDRs are particularly suited to the development of expert systems where rules are added on an ad-hoc basis by the experts themselves with no knowledge of the underlying structure of the knowledge-engine. No knowledge-engineering or computer programming skills are required. RDRs involve a process of refinement whereby rules are never modified or deleted, but new rules are added to correct exceptions, which are cases that existing rules have not classified correctly. The rule base is a tree of rules, the branches leading from less to more refinement from the root to the leaves. The advantages for us of using RDRs are: • RDR knowledge bases were developed within the health domain and there is considerable experience within this domain. They have proven themselves to be suitable for use by health experts with little computer training [9,10].
3 of 4
Fig. 2. A patient’s blood pressure trend for three weeks. Blood pressure scaling in mmHg is shown on the left of the trend with pulse rate in bpm scaling on the right of the trend panel.
•
The consistency of the knowledge base is automatically maintained by the refinement and adding paradigm, which means that large knowledge bases (e.g. several thousands of rules) can be built, with each new rule taking less than one minute to add. • Development and maintenance of the rule-base are the same thing – an RDR system can be placed into service early and the rules added and refined over time. • The cases that caused new rules/branches to be added are retained as cornerstone cases, providing a context for further rule addition, as well as trace-back and analysis of the knowledge collected. There are disadvantages with the RDR approach which are addressed as follows: • There is the possibility of repetitious knowledge at different contexts leading to a messy knowledge store [9]. However, although this is a possibility, simulation studies show that it occurs only with a very low level of domain expertise [12]. It is not an issue in practice, and even if the knowledge store is less that optimally organised, there is no need or requirement for the expert to view the internal structure of the knowledge base. • An expert must be on hand to review the interpretations, and to make continual refinements. We have an inhouse clinician for this reason and input is also received from feedback provided by patients’ physicians. To implement the RDRs we use a system called LabWizard [11], which has a GUI-based system for entering rules, and has been used successfully in pathology laboratories, providing automated interpretations. LabWizard contains several enhancements to standard MCRDR (multiple classification RDR) required for large commercial knowledge-base systems. Alerts The initial rule set in this preliminary system was created in our laboratory by a trained clinician, but rules can also be suggested and amended by patients’ clinicians. Initially, the rules are basic. For example: BP increasing = (diastolic > ( mean(diastolic) + 2*stdev(diastolic) ) ) over 1 week Building on these are more programmatic logic-based rules, such as:
If BP decreasing and PR increasing and medication interacts with BP then suggest review medication Multiple alerts can be generated from the same set of patient data, as RDRs can make multiple classifications [12]. Rule development and validation is part of an on-going research project. The development of the knowledge base is complicated by the need to capture the co-morbidities and complexities associated with the onset and progression of chronic disease, in addition to taking into account a multitude of patient information, including medications and past medical history. To implement the Alerts Path, patient data is extracted from the database, converted to XML, and sent to LabWizard. The result of applying the ripple-down rules is incorporated into the output reports as a textual statement, and/or a graphical highlighting of some parameters in the trends images and tables (e.g. Fig. 4). III. DISCUSSION The Trends Path of the system is fully functional and use-case testing is underway with a clinical trial anticipated in the near future. The rule-base is still under development. In a sense it is always under development as rules are added and the reporting capacity enhanced. Initially the rules are simple and alert clinicians to important changes of trend data. These will over time be enhanced with more sophisticated rules, and rules that make use of more information than just vital signs – for example the patient’s diagnosed condition, their medication, and their clinical history. The rules can also be enhanced with best-practice guidelines and rules that pertain to specialty areas such as morphometric analysis of ECGs in the case of cardiology. The outputs from the monitoring could later be fed back into the HTS. This is possible as the HTS is remotely configurable (normally by the clinician manually changing the patient’s medication and measurement schedule by logon to a secure web-site). This could be used, for example, to request additional measurements, tailor questionnaires and educational links, schedule community health worker visits or recommend doctor visits. Changes to treatment regime and medications could also be suggested.
4 of 4
Fig 4. A segment of the trend in Fig 2. showing an attached alert.
a first step in developing the tools to support this environment. Our approach has been to develop these tools using as far as possible, open standard tools to ensure sustainable and extendible applications in health and to provide interconnectivity between disparate health information systems.
Fig. 3. Statistical information displayed in the report and used to produce Fig. 2
Currently the reports and alerts are generated ondemand, i.e. when the reports are requested, but this will be enhanced to run on a scheduled basis and then perhaps in real-time, so that doctors will be notified immediately by the reporting system whenever a noteworthy event is detected. As well as the current extracted parameters, which indicate vital signs such as heart rate, systolic pressure etc., more detailed parameters could be taken from the raw signals (e.g. spirometry or ECG analysis) and fed into rules for diagnoses of disease conditions. With regards the clinical document architecture, we are currently investigating the pros and cons of the relational SQL database for storage of clinical measurement data. In the future we may store all patient information in the CDA format and use it as the primary patient database, generating reports from digitally signed CDA patient files. The use of this document architecture means that the data will also be better integrated with HL7 messages and thus provides interconnectivity with other systems. The XML CDA data will be retained in an XML database (Fig. 1.), and operated upon via Web Services such as SOAP. IV. CONCLUSION While clinical decision support systems have been in use in medicine for a number of decades, there exist no systems targeted specifically for the home telecare environment in which complex and chronic disease is prevalent. The alert and trends reporting described herein, is
REFERENCES [1] B.G. Celler, N.H. Lovell, and J. Basilakis, “Using information technology to improve the management of chronic disease,” Med. J. Aust., vol. 179, no. 5, pp. 242-246, 2003. [2] B.G. Celler, N.H. Lovell, and J. Basilakis, “A Clinical Trial of a Home Telecare System for the Management of Chronic Disease,” in Proc. World Congress on Medical Physics and Biomedical Engineering, Sydney, 2003. [3] N.H. Lovell, B.G. Celler, J. Basilakis, F. Magrabi, K. Huynh, and M.J. Mathie, “Managing chronic disease with home telecare: a system architecture and case study,” in Proc. 2nd Joint EMBSBMES 2002 Conference, Houston, pp. 1896-1897, 2002. [4] A.F. Jerant, R. Azari, and T.S. Nesbitt, “Reducing the cost of frequent hospital admissions for congestive heart failure,” Medical Care, vol. 39, no. 11, pp. 1234-1245, 2001. [5] B.J. Smith and M.D. McNeely, “The Influence of an Expert System for Test Ordering and Interpretation on Laboratory Investigations,” Clinical Chemistry, vol. 45, no. 8, pp 1168-75, 1999. [6] Dolin RH, Alschuler L, Beebe C, Biron PV, Boyer SL, Essin D, Kimber E, Lincoln T, and Mattison JE, “The HL7 Clinical Document Architecture,” J. Am. Med. Informatics. Assoc., vol. 8, no. 6, pp. 552-569, 2001. [7] P. Diggle, P. Heagerty, K-Y. Liang, and S. Zeger, Analysis of Longitudinal Data, Oxford: Oxford Uni. Press, 2002. [8] P.J. Compton, and R. Jansen, “A philosophical basis for knowledge acquisition”, Knowledge Acquisition, vol. 2, pp. 241257, 1990. [9] P.J. Compton, G. Edwards, A. Srinivasan, R. Malor, P. Preston, B. Kang, and L. Lazarus, “Ripple down rules: turning knowledge acquisition into knowledge maintenance”, Artificial Intelligence in Medicine vol. 4, pp. 47-59, 1992. [10] G. Edwards, P. Compton, R. Malor,, A. Srinivasan, and L. Lazarus, “PEIRS: a pathologist maintained expert system for the interpretation of chemical pathology reports”, Pathology vol. 25, pp. 27-34, 1993. [11] LabWizard, Pacific Knowledge Systems, Available: http://www.pks.com.au/products/lab_wizard.htm [12] P. Compton, P. Preston, B. Kang, and T. Yip, “Local patching produces compact knowledge bases” in L Steels, G Schreiber & W Van de Velde, A Future for Knowledge Acquisition: Proc. EKAW'94, (Berlin, Springer Verlag), 104-117, 1994.
