SAPHIRE D7.1.1 - Requirements Specification of the Homecare

  • 313 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
313
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. IST- 27074 SAPHIRE “Intelligent Healthcare Monitoring based on a Semantic Interoperability Platform” SPECIFIC TARGETED RESEARCH PROJECT PRIORITY 2.4.13 Strengthening the Integration of the ICT research effort in an Enlarged Europe Focus: eHealth SAPHIRE – Deliverable 7.1.1 Requirement Specification for Home Pilot Application Due Date: April 28, 2006 Actual Submission date: May 04, 2006 Project Dates: Project Start Date : January 01, 2006 Project End Date : June 30, 2008 Project Duration : 30 months Leading Contractor Organization: SSK Page 1 of 27
  • 2. Saphire Consortium Contacts: Organization Name Phone Fax E-Mail METU-SRDC Asuman Dogac +90-312-2105598 +90(312)2101004 asuman@srdc.metu.edu.tr CYBERFAB Michael Setton +33-476-081-957 +33-672-995-202 setton@cyberfab.net OFFIS Marco Eichelberg +49-441-9722-147 +49-441-9722-102 eichelberg@offis.de ALTEC Adamantios +30 2310 595646 +30 2310 565630 akou@altec.gr Koumpis IPA SA Gabriel Spiridon +40 21 230 25 12 +40 21 230 70 63 spiridon@ipa.ro SCUB Maria Dorobantu +4021 3170108 +4021 3170108 mdorobantu@cmb.ro SSK Michael +49 5424641565 +49 5424641202 mboeckelmann@schuechtermann Böckelmann -klinik.de TEPE Bulent Kunac +90-312-2919100 +90-312-2662998 bkunac@tepeteknoloji.com.tr Document History: Version Date Changes From Review 0.1 February 20, First draft of template SSK Internal 2006 0.2 February 27, Public draft SSK All Partners 2006 0.3 March 14, Document structure adapted to prevent OFFIS All Partners 2006 redundancies 0.4 April 7, Second Release SSK/OFFIS All Partners 2006 0.5 April 25, Included concepts for patient GUI OFFIS/SSK All Partners 2006 Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006) Dissemination Level PU Public X PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services)
  • 3. LIST OF CONTENTS 1 INTRODUCTION...................................................................................................................................................................4 1.1 PURPOSE AND SCOPE............................................................................................................................................4 1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS .......................................................................................4 1.3 OVERVIEW...............................................................................................................................................................5 2 GENERAL DESCRIPTION...................................................................................................................................................5 2.1 HOMEPA OVERALL DESCRIPTION.....................................................................................................................................5 2.2 HOMEPA SENSORS NETWORK..........................................................................................................................................8 2.2.1 Electrocardiograph (ECG).......................................................................................................................................8 2.2.2 Blood pressure (BP).................................................................................................................................................8 2.2.3 Oximeter..................................................................................................................................................................8 2.2.4 Scale.........................................................................................................................................................................8 2.2.5 Ergometer (Exercise bicycle)...................................................................................................................................8 2.3 HOMEPA INTEROPERABILITY PLATFORM............................................................................................................................9 2.4 HOMEPA CLINICAL DECISION SUPPORT SYSTEM (MULTI-AGENT)........................................................................................9 2.4.1 SPECIAL SYSTEM REQUIREMENTS...............................................................................................................16 2.5 HOMEPA CLINICAL GUIDELINES MODEL.........................................................................................................................16 2.6 HOMEPA GUI FOR AGENT BEHAVIOR CONFIGURATION....................................................................................................18 2.7 HOMEPA SUPPORT INTERFACE FOR PHYSICIANS................................................................................................................19 2.8 HOMEPA GUI FOR PATIENTS........................................................................................................................................19 ...................................................................................................................................................................................................19 3 OPERATIONAL SCENARIOS...........................................................................................................................................25 3.1 REHABILITATION OF THE INPATIENT..................................................................................................................................25 3.2 SECONDARY PREVENTION OF THE OUTPATIENT....................................................................................................................26 4 MEDICAL ETHICS, SECURITY AND CONFIDENTIALITY REQUIREMENTS.....................................................26 5 REFERENCES.......................................................................................................................................................................27 Page 3 of 27
  • 4. 1 INTRODUCTION 1.1 PURPOSE AND SCOPE This document contains a template structure for the Home Pilot application (HomePA) system requirement specification, with contributions from the end-user (patient), to be updated with the specific requirements after input from the other partners. The home pilot application will be one of the two practical demonstrations of the SAPHIRE system. Purpose of the HomePA is to test the intelligent intermittent home monitoring of patients through wireless sensors and to integrate the data from the sensors with the data from the electronic healthcare records in the system interoperability platform in order to generate alerts and recommendations via an intelligent Decision Support System based on a clinical guideline model. Patients suffering from ischemic heart disease followed by a revascularization therapy will be included into the project. The main objective of the HomePA will be to provide guideline-based and specific recommendations to the patient for optimised out-patient rehabilitation. The HomePA will serve as a model for a home based rehabilitation program optimising medical education in secondary prevention, reducing workload of practitioners and reducing health care costs with improving effectiveness. 1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS Home Pilot Application = Out of hospital pilot demonstration for the SAPHIRE system Schuechtermann-Schillersche Klinik Bad Rothenfelde (SSK) and Institute for Heart and Circulation Research at the University of Witten/Herdecke (IHKF) = partners responsible for HomePA development acute coronary syndrome (ACS) = Patient with continuous or intermittent chest pain due to an partly or completely occluded coronary artery heart failure (HF) = heart failure is a pathophysiological state in which an abnormality of cardiac function is responsible for the failure of the heart to pump blood at a rate commensurate with the requirements of the metabolizing tissues. (European Heart Journal 2001; 22: 1527-1560) major adverse cardiac events (MACE) = in cardiovascular studies routinely used to describe cardiac death, new acute coronary syndrome or new onset of symptoms which enforce readmission to the hospital after primarily successful coronary intervention. angina pectoris (AP) = often percepted as a thoracical constriction due to myocardial ischemia. It may appear as a constant chest pain indicating an ACS or intermittent at rest indicating an unstable angina, which counts as a pre infarct syndrome. Stable angina is the appearance of thoracical symptoms due to physiological activities, which disappear at rest. SaO2 = the hemoglobin oxygen saturation in arterial blood is indicated by the percentage of all the available heme binding sites saturated with oxygen. SpO2 = the hemoglobin oxygen saturation in arterial blood measured non-invasively with a pulse oximeter ECG = Electrocardiogram; a representation of the electrical voltage in the heart in the form of a continuous strip graph. Primarily used in cardiac electrophysiology for the screening and diagnosis of cardiovascular diseases. HIS = Hospital Information System; integrated information system designed to manage the administrative and clinical aspects of a hospital Page 4 of 27
  • 5. CIS = Cardiology Information System; information system specifically tailored to the needs of a cardiology department 1.3 OVERVIEW In Section 2 a general description of the HomePA is given, starting with an overall description followed by a detailed discussion of every component of the system with regard to function and relationships with other system parts. 2 GENERAL DESCRIPTION 2.1 HomePA Overall Description The purpose of the home pilot application is to demonstrate that the SAPHIRE system after development would be able to provide homecare intelligent monitoring in a wireless fashion. Furthermore it is planned to provide patient-specific computer-generated clinical proposals for clinical decision in accordance to the latest European Cardiology Guidelines. During SAPHIRE development it is intended to investigate the application with respect to safety and accuracy of the sensor data, the Alerts System, the accuracy of the history data from the electronic healthcare records and the recommendations generated by the system by correct interpretation and implementation of the guidelines. In contrast to the hospital monitoring system the home pilot system is designed to perform an intermittent monitoring of vital parameters with online validation by a physician. The second aim of this project is to develop a home monitoring system that is able to provide a patient-specific and guideline-oriented feedback to the physicians, to facilitate and ensure an optimized medical care due to European standards. These system features may not only reduce the workload for out-patient departments and for practitioners but may also lead to a reduction of medical costs by cutting down rehospitalisation procedures in future. DESIGN OF THE HOME PILOT APPLICATION For the design of the Home Pilot Application (HomePA), according to the equipment described in SAPHIRE DoW, four (4) exercise-sensor-alert stations will be available, for simultaneous monitoring of four patients: For the design of the HomePA four complete exercise-sensor-alert stations including a visual control unit (optional), a programmable exercise-bicycle, sensors monitoring the vital parameters such as a 3-lead ESC (12- lead ECG optional), breathing frequency, saturation of Oxygen, and blood pressure, and the control unit for the patient will be available. Data from the sensors will be collected in wireless fashion, processed by a local control and alert system. The data is also transmitted to the central control and alert system at SSK. Optional a direct visual control may be available using a videoconference system, with which the patients training should be supervised. ECG and respiratory rate monitoring will be provided using 3-lead ECG (12-lead ECG optional), BP monitoring will be done by automatic oscillometric method using arm pressure cuff. The patients will be monitored once a day for 1 hour (or any other duration recommended by the physician). During the hospital stay exercise testing should only be conducted under supervision of well-trained personnel with a sufficient knowledge of exercise physiology. Only nurses and physicians familiar with normal and abnormal responses during exercise can recognize or prevent adverse events. Equipment, medications, and personnel trained to provide advanced cardiopulmonary resuscitation (CPR) must be readily available. Page 5 of 27
  • 6. Patients’ homes Patient 1 Patient 2 Patient 3 Patient 4 Sensors Sensors Sensors Sensors MSHCP MSHCP MSHCP MSHCP Internet SSK MSHCP CIS Data Visualization Alert System Figure 1.Schematic representation for the design of the HomePA For the home training an Alert System specific for the sensors will be developed. Data will be sent to the physician via mobile phone or internet to generate reaction. The data will then be integrated with the data from the EHR. The optional video conference system will allow continuous supervision of the patient during exercise training with direct contact to the physician. Additionally a guideline model will be assigned to the specific patient. This guideline model will integrate all data and will generate a report containing alerts and recommendations for the patient based on the guidelines. Recommendations can be diagnostic/investigational or therapeutic and will be validated by the responsible physician before being “delivered” to the patient. SPECIAL ISSUES IN MONITORING OF THE CARDIOVASCULAR OUTPATIENT After discharge of a patient subsequent to a successful intervention of an acute coronary syndrome continuous monitoring and supervision will end. The patient is advised to visit his practitioner every three months. After discharge, the reappearing of new symptoms is recorded as “major adverse cardiac event” (MACE) defined routinely as cardiac death, acute coronary syndrome or new onset of angina correlated to the underlying coronary artery disease which enforces the readmission to the hospital. The special issues in monitoring the cardiovascular outpatient have to be referred to MACE: Page 6 of 27
  • 7. death: The fatal event of a (sudden) cardiac death could unfortunately not precisely be predicted. But there are some factors influencing the risk of cardiac death such as age and gender, contractile function of the left ventricle, heart rate, brunch bundle block, heart rhythm, and some serological markers such as troponins and natriuretic peptides which are used for risk stratification after acute coronary syndrome. The parameters that are easy to apply for the home pilot application o refer indirectly to the cardiac function: body weight measured by scales and the SaO2-sensor o refer to the electrophysiological status of the heart: measured by ECG. A 3-lead ECG is sufficient to assess heart rate and heart rhythm. new acute coronary syndrome: In most cases, the patients´ behaviour represents the best indicator for the appearance of a new ACS. Continuous chest pain at rest can indicate an acute coronary symptom, which enforces an emergent readmission of the patient to a hospital. Having an ACS during exercise is a very rare condition, but if it appears it is life threatening. Therefore an alert system directly driven by the patient is indispensable. The first clinical signs of an ACS are ST-elevations in more than two leads of a 12-lead ECG. Because of the optional availability of a 12-lead ECG the patients discomfort may remain the only sign of a new ACS. new onset of angina Patients after successful therapy of an ACS will develop in about 30% a restenosis within a period of 6 months with an incidence of about 30%. Therefore the appearance of new onset of symptoms can be expected in about every fourth patient. In this case the alert system must also be driven by the patient himself. In contrast to a new ACS with subsequent emergent need for a readmission to a coronary care unit, the patient with new onset of stable angina, without any symptoms at rest, may consult his physician urgent but not emergent. All parameters chosen for the HomePA will allow the supervision of the patients´ rehabilitation program at home. Alerts may serve as indicators of an impending cardiac event such as MACE. POPULATIONS OF PATIENTS TO BE ENROLLED IN THE HomePA Based on the most frequent demission diagnoses in the SSK rehabilitation department we have chosen a specific patient population to participate to the HomePA: patients with acute coronary syndromes after successful interventional revascularization and retained left ventricular function. The Home Pilot Application will be composed of two phases: Inpatient phase: Patients who are planned to start the rehabilitation program after successful revascularisation procedure will be asked to take part in the investigation on the HomePA (Informed Consent). During this phase patients will be introduced and instructed to the HomePA. Additionally to the use of the HomePA exercise training will routinely be performed under the supervision of a physician who is appropriately trained to administer exercise tests and resuscitation. The physician will supervise the data acquisition and will review the standard 12-lead ECG performed immediately before, during and after testing. The physician should interpret data derived from testing and suggest further evaluation or therapy. Page 7 of 27
  • 8. Outpatient phase: The supervision and training in home based exercise training of the patients will take 3 weeks (in house rehabilitation). Main focus of the training for the patient is how to use the exercise equipment and to learn sings for terminating exercise training. After rehabilitation-discharge patients will continue exercise training according to the physician´s instructions and HomePA for three months. 2.2 HomePA Sensors Network The HomePA sensors network serves the vital data from the patient that is needed for the diagnostics done by the physician and as input for the Alert Agent. Each sensor has its own data transfer protocol, which has to be implemented by the HomePA interoperability platform (Multi-Services HealthCare Platform, MSHCP). In the HomePA scenario five (5) kinds of sensors are necessary. All sensors must provide a well defined data transfer protocol for the communication with the MSHCP over Bluetooth. For the ergometer and the weight scale it is possible to have a wired data connection as an alternative option, but a Bluetooth will be preferred. All sensors that are connected via Bluetooth should have an internal storage for data storage during problems with the Bluetooth connection. The minimum requirement is a temporal storage time for 5 minutes. During the project lifetime, the consortium will determine whether the system is a medical device as defined in the European Medical Device Directive 93/42/EC. The following section shows the necessary functions of the sensors. 2.2.1 Electrocardiograph (ECG) For the HomePA the minimum are three leads, better are 12 leads with an easy way to hook up the electrodes. Here is a good way to use clothes which integrate all necessary electrodes. But it is also possible to use vacuum electrodes or glue electrodes. In addition to the raw data of the ECG it is also needed to provide pre analyzed signals. (For this scenario the heart rate, breathing rate and the sinus rhythm are required.) Since ECG analysis is too complex to be within the scope of the project, it is recommended to buy commercial well established solutions like the HES (Hannover ECG System) software. 2.2.2 Blood pressure (BP) The BP measurement has to be done in pre defined intervals. The start of the data acquisition will be done by the MSHCP. The communication between MSHCP and the BP will be realized via Bluetooth. The BP sensor provides the systolic, diastolic, and means arterial pressure data. 2.2.3 Oximeter To get the SpO2 value in the HomePA the oximeter will be used for continuous measurement. It should be noted that in combination with a blood pressure cuff, there could be problems if the pulse oximeter uses a sensor that is clipped to the finger on the same arm. This is why ear clips are preferred. 2.2.4 Scale To get information about the weight changes of the patient a scale is needed. Optional the measuring of the percentage of body fat and water could be interesting. For this to values the scale should an option to measure these values. If there problems by getting one or more of this three values, this has to be communicated by the scale. 2.2.5 Ergometer (Exercise bicycle) For the exercise a bicycle (ergo meter) is planned. This bicycle must be controllable by the MSHCP. During the exercise the power should change. E.g. if a yellow alert is given the resistance must go down. Also it is necessary Page 8 of 27
  • 9. to know how many rounds per minutes the patient does. If it is too high the heart rate increases beyond the threshold deemed beneficial to the patient’s rehabilitation. In case the resistance can’t be lowered, a specific way has to be established to communicate this fact to the patient (together with a suggested solution). 2.3 HomePA Interoperability Platform The HomePA Interoperability platform (Multi-Services HealthCare Platform, MSHCP) serves as glue between the sensor network and the rest of the SAPHIRE system. With technology that is identical to the Interoperability Platform deployed in the Homecare Scenario, the main task of the Interoperability Platform is the integration and semantic marking of sensor data. After semantic marking, the data is ready for consumption by the Guideline Agents, the Alert Agents and the agents responsible for importing sensor data into the EHR based on rules defined by the clinician. Also, the platform serves as an abstraction layer for the sensor network. With such a layer, it will be easier to replace sensors with state-of-the-art technology. A more detailed description of the platform, as well as a description of its requirements is given in D3.2.1 “Requirements Specification of the SAPHIRE system”. 2.4 HomePA Clinical Decision Support System (Multi-Agent) The multi-agent aspect of the decision support and alert system is described in section 2.4 of Deliverable D8.1.1 (“Requirements Specification of the Hospital Pilot Application”) and in Deliverable D3.2.1 (“Requirements Specification of the SAPHIRE System”). The demands on the HomePA Clinical Decision Support System differ to the demands on the HPA Clinical Decision Support System: In the HomePA the decision is first given to the patient, in contrast to the HPA, in which the decision is given to the clinician. DEFINITION OF MEDICAL ALERTS Medical alerts are electronic signals (audio/video/written signals) that inform the patient about a present abnormal and potentially dangerous condition. Usually medical alerts are related only to the monitoring of vital signs such as heart rhythm, blood pressure, respiration rate or pulse oxymetry, but they can also be related to thoracical symptoms (marked by the patient as “events”, usually by pressing a button). A medical alert should be real-time generated and first be transmitted to the patient. The patient and his spouse or partner must be trained extensively in deciding the procedure after an alert during exercise training. If no life threatening condition enforces admission to a hospital, every alert should also de assigned and interpreted by the SSK. After every alert the cause must be discussed with the patient. Electronic alerts should deliver a very simple message in a way that prevents physicians from bypassing them in daily practice(2). For this reason, such decision support should be limited to selected high-risk events for which key decisions are required. Usually, electronic alerts can be graded in three categories: Green alerts: they indicate that all parameters are within the threshold, no danger condition. Yellow alerts: these are alerts indicating the appropriate parameter´s range is out of normal, but do not require emergent action. If a yellow alert is given at rest, the patient will not begin with exercise training and is advised to contact his clinician at SSK. If a yellow alert is given during exercise training, the performance of the exercise bicycle will be reduced automatically. If the yellow alert does not disappear within 5 minutes it will change to the red alert and the exercise training will be stopped immediately and automatically. Red alerts: these are given if conditions such as to high or to low blood pressure, new onset of supraventricular or ventricular arrhythmias, SpO2<95% at rest or under exercise lead to an Page 9 of 27
  • 10. interruption of the performance on the exercise bicycle and the patient will be advised to stop immediately. In addition, if the patient suffers from continuous chest pain, dizziness or other discomfort he will be advised to get admitted to an coronary care unit. TYPES OF ALERTS FOR SAPHIRE In the SAPHIRE System, there will be at least two types of alerts to be generated by the system: 1. Local alert system: Alerts coming from the sensors and alert the patient using a decition support system; 2. Central alert system: Alerts coming from the Home Pilot Applications and alert the SSK for further decision making. These 2 types of alerts will be different in terms of required medical action they could generate. To be noted that alerts coming from the sensors will be considered important input for the guidelines model tool and, apart from generating immediate/urgent action by the patient/clinician, will also be used by the intelligent clinical decision support system to generate recommendations. Both categories will be graded in green sign and “yellow” or “red” alerts and could be used as actors in use-cases to generate a system response. 1. Alerts coming from the sensors could be the following: - ECG alerts: o HR alerts:  Bradycardia  Tachycardia  HR change  Irregular HR  Asystole  Artefact o Arrhythmia alerts:  Supraventricular and ventricular arrhythmias - Blood pressure (BP) alerts: o High BP o Low BP o Non-detectable BP o Artefact - Pulse oximeter alerts: o Low oxygen saturation (SpO2). - Alerts from the exercise bicycle o After identification of the patient = ready to start o End of exercise o Speed too low/to high o Yellow alert = slow down o Red alert = stop immediately (resistance will be switched off) - Event alerts coming from the patient: o Chest pain alert Page 10 of 27
  • 11. o Dyspnoea alert (“shortness of breath”) o Palpitations alert The alarms/alerts coming from the sensors are depend to a large degree on the type of sensors to be used by the SAPHIRE system. For example, there are ECG sensors with available an arrhythmia algorithm, that can “read” and alert for various types of cardiac rhythms. For the optional 12-lead ECG system diagnostic of ischemic events and location algorithm based on ECG leads could also be available and therefore some new alerts could be defined like “acute ST-depression or elevation.. For the “event” alerts, only one button should be available for the patient and he/she should press it once/twice/three times according to the type of symptoms. If more symptoms are present in the same time, a grading should be explained to the patient (like “if you have chest pain and dyspnoea, chest pain is the more severe symptom and you should press to mark this”). 2. Alerts coming from the Intelligent Decision Support System These alerts will require definition according to the implemented guidelines and will be more complex. They will be part of the flowcharts and algorithms developed from the guidelines by the medical team and will generate actions in terms of recommendations visiting a general practitioner or a hospital for further evaluation a therapy using the decision support system. They will also be graded into “yellow” and “red” alerts and will be stratified according to the patient profile from the electronic healthcare record (EHR). ALERTS THRESHOLDS Alert thresholds are defined according to alert type and detection parameters. They should be predefined, but the finally used thresholds are oriented individually on the state of health and state of exercise. User thresholds could be defined also in concordance to some user profiles like high-risk profile, risk factors present, to generate a preliminary diagnosis that will be taken into account by the alert system (see figure 2). Comparison/correlation of signals could therefore generate the alerts. Alert detection parameters could be then adjusted based on additional input from the patient’s EHR, making the system more patient-dedicated System Thresholds Individual Thresholds Algorithm Preliminary Diagnosis Alert Decision . Page 11 of 27
  • 12. Figure 2. Generation of alerts in the SAPHIRE system The alert types and their thresholds based on detection parameters proposed for the SAPHIRE System are defined in Table 1. Page 12 of 27
  • 13. Alert Type Detection Alert Alert Grade Observations Parameter Threshold Y= yellow R= red ECG alerts HR Bradycardia at rest HR (bpm) <60 Y Tachycardia at rest HR (bpm) >100 Y HR under exercise HR (bpm) <100 bpm Y > 220 minus age R Irregular HR HR (bpm) - Y Asystole HR (bpm) Isoelectric line R Arrhythmia SVT at rest HR (bpm) >120 Y JT at rest HR (bpm), P >100, no P Y waves waves AFl at rest HR (bpm), P Arrhythmia Y waves algorithm New onset R AF at rest HR (bpm), P Arrhythmia Y waves algorithm New onset R VT QRS complex, Arrhythmia R HR (bpm) algorithm VF QRS complex Arrhythmia R algorithm SVEs RR interval, P Arrhythmia Y waves algorithm VEs RR interval, Arrhythmia Y QRS complex algorithm Bradycardia at rest HR (bpm) < 40 Y < 30 R Asystole/Cardiac HR (bpm) Arrhythmia R arrest algorithm BP alerts Low BP at rest BP (mmHg) < 90mmHg Y < 80mmHg R High BP at rest BP (mmHg) >160mmHg Y > 200mmHg R Page 13 of 27
  • 14. Non-detectable BP BP (mmHg) Not detected R Pulse-oximeter alerts Bradypnea ? Respiratory rate <12/min Y (RR) <8/min R No respirations per minute Tachypnea? Respiratory rate >18/min Y (RR) >24/min R No respirations per minute Abnormal curve? Respiratory Algorithm Y curve Low SpO2 SpO2 (%) <95% Y <90% R “Event” alerts Chest pain at rest Event mark Presence R Under exercise Event mark Occurance R Dyspnea at rest Event mark Presence R Under exercise Event mark Occurance R Dizziness at rest Event mark Presence R Under exercise Event mark Occurance R Borg Scale after 14-16 RPE Y exercise training > 16 R Table 1. Alert thresholds for SAPHIRE (bpm= beats per minute; SpO2 = oxygen saturation measured by pulse oximeter) The values presented in the table are only meant for orientation and cannot be transferred directly into the alarm component, as they need to be individualized for each patient. Given the patient’s status, the thresholds will be defined a lot more conservatively. In addition to an objective evaluation of the patient’s state of health based on the data generated during individually adapted exercise training the subjective patient’s state of exhaustion shall be documented by a “rating of perceived exertion (RPE). There are a number of RPE scales but the most common is the Borg’s 15 point scale (6-20), illustrated below. Borg’s Rating of Perceived Exertion (RPE) is based on a subjective feeling of exertion and fatigue during exercise. The patient will give a numerical value on a scale from 6 to 20, representing a verbal expression of effort during exercise [Bo70]. This method is a widespread and reliable one for regulating exercise in physical rehabilitation and exercise prescription, because it provides exercising persons of all fitness levels with simple guidelines regarding intensity of their exercise. The American College of Sports Medicine (ACSM) has recommended RPE since 1986 for both fitness and Cardiac rehabilitation purposes. ACSM's guidelines recommend a RPE range of 12 to 16 as the perceived exertion range associated with a cardiovascular training effect; roughly corresponding to 60%-85% of the Maximal Heart Rate (HRmax = 220 – age). Page 14 of 27
  • 15. Points Effort Verbal meaning 6 20% Very, very light (Rest) 7 30% 8 40% 9 50% Very light - gentle walking 10 55% 11 60% Fairly light 12 65% 13 70% Moderately hard – steady pace 14 75% 15 80% Hard 16 85% 17 90% Very hard 18 95% 19 100% Very, very hard 20 Exhaustion Table 2. 15 Point Scale WHO WILL RECEIVE THE ALERTS? The alerts can be delivered to several actors in the SAPHIRE system: - The patient - The physician at SSK - The patient’s family members - The nurse at SSK - The software application (like the guideline model agent and the decision support system). The delivery of the alerts to the patient is advisable in the home setting, and is a precondition for the patient’s clinical and psychological safety. The red alerts should be delivered via a strong audio signal and have to be stopped by the patient himself. SOURCES OF ERRORS The main problem arising when using an alert system is the generation of artefacts. Taking into consideration that the wireless monitoring in the SAPHIRE system will allow the patient to do exercise training in a Home Application scenario, artefacts of signals will be possible and should be expected. Good quality of signals should be ensured by the system and continuous check-up by nurse/physician/patient family/patient himself could Page 15 of 27
  • 16. diminish this aspect. The green signal on the alert system may be suitable to demonstrate not only that all parameters are within the determined ranges but also that there are no artefacts. Missing alerts could be another problem. Furthermore the interpretation of vital red alerts as yellow ones due to artefacts/ algorithms represent a big problem. Combining signals or alerts or assigning higher alert levels for high risk patients could help avoid this aspect. Mistakes in alert signalising or receiver’s error in responding could be another problem that has to be taken into account when a decision will be generated. Continuous feedback to identify these potential dangerous problems will help fixing errors. Excessive alerts due to patient event signalising or non-compliance or even to the design of the alert system can be a problem that has to be carefully resolved during system testing in the pilot applications. 2.4.1 SPECIAL SYSTEM REQUIREMENTS In addition to the data requirements expressed by SCUB (see D8.1.1), the following data should be available when designing the database in order for the alert system to work properly - List of personal details fields. Most of this information is included in the hospital database. - Current patient status, thresholds and alerts. The physician responsible for the patient sets thresholds that will trigger alerts when exceeded. These thresholds correspond to limits on indices, such as blood pressure, measured by the patient sensors and transmitted electronically to the system where they are stored. - Medication prescription details for each patient. - For each patient, name of responsible physician at SSK and the practitioner. Also, their address and contact numbers. This association is important especially when an alert is raised and the system has to contact any of these professionals. - Lab results - ECG results - Results of 24 hrs blood pressure monitoring - Pulmonary function test results - Spirometry results - Problems that were observed during the ergometer training - Starting time end ending time of the ergometer training - RPM / Wattage - Frequency and duration of the training - Percentage of training with the recommended wattage CONCLUSION Computerized alerting systems, which can notify physicians about problems that occur asynchronously may decrease error rates and improve rehabilitation therapy, thereby improving outcomes, including survival, and reducing readmission rates. 2.5 HomePA Clinical Guidelines Model There are no clinical guidelines for the scenario realized by SSK. However, it is possible to some degree to model the flow of a training session, using the following kinds of GLIF1 steps: 1 Guideline Interchange Format (GLIF), http://www.glif.org Page 16 of 27
  • 17. Patient Synchroni- Decision Action Branch State zation Figure 3. GLIF step primitives The general flow of an exercise session is outlined in the following figure: Patient Measure Vital Patient Resting Parameters (1) Exercises Patient Measure Vital Measure Vital Ends Parameters (3) Parameters (2) Exercise Generate Report Figure 4. Flow of the exercise (Overview) The steps “Measure Vital Parameters (1)”, “Measure Vital Parameters (2)”, and “Measure Vital Parameters (3)” are macro action steps describing the steps of measuring the vital parameters and checking them against thresholds defined during the inpatient phase. Even though the same vital parameters are measured in the three steps, they’re compared against different thresholds to take the context into account. For example a heart rate of 100 would be considered tachycardia, if it were measured in rest, resulting in an alert. However, the same heart rate should not trigger an alert if measured during the actual exercise. On the other hand, an irregular heart rate will trigger an alert in all three macro steps. Figure 5 shows how the macro action step “Measure Vital Parameters” can be resolved. In this case, we assume that the patient has already started the exercise, and that the respiratory rate is derived from the ECG, as described in [Mo85] that has been validated in [Mo86]. As discussed in [Le03], the respiratory rate can also be monitored using a standard pulse oximeter. The respiratory rate could also be measured directly (for example by wearing a respiration monitor belt), but it would be preferable to keep the number of sensors to a minimum. Decision steps like “ECG Okay?” should be considered macro decision steps. “ECG Okay?” checks for the ECG alerts defined in Table 1. The limits needed for the decision steps “BP within limits?” and “RR okay” need to be individualized for each patient. It should be noted that the flow shown in Figure 5 is a simplification of the flow that will be needed for the actual exercise. For example, the flow shows only one generic kind of alert, even though the system differentiates between “green alerts”, “yellow alerts” and “red alerts”. From a medical standpoint, it makes sense to differentiate further between “hard” and “soft” alerts. Event alerts (triggered by the patient pushing the yellow or red button), ECG alerts and blood pressure alerts are considered “hard” alert. On the other hand, alerts triggered by the respiratory rate or the oxygen saturation should be considered “soft” alerts that require further investigation. A respiratory rate that is too high might indicate that the patient has problems dealing with the training load. But another possible reason might be a telephone call that the patient is answering during the exercise. Page 17 of 27
  • 18. Measure Vital Parameters (2) Vital Signs Create ECG Measure BP Measure SpO2 BP within ECG limits? SpO2<95%? No Yes Derive RR Check ECG No No ECG okay? Patient Alert stops exercise No RR okay? Yes Yes Patient ECG Vital Signs continues exercise Figure 5. Measuring vital parameters under exercise 2.6 HomePA GUI for Agent Behavior Configuration The HomePA GUI for agent behavior configuration of the HomePA is the same GUI used in the hospital scenario. The GUI is described in deliverable D8.1.1. Page 18 of 27
  • 19. 2.7 HomePA Support Interface for Physicians In both scenarios, Physicians need an interface that offers a real-time visualization of the sensor data. In the homecare scenario, this will be necessary mostly during the inpatient-phase, where the patient trains under supervision, based on recommendations that were derived from the initial exercise test done after the patient’s transfer into the rehabilitation. 2.8 HomePA GUI for Patients The patient communicates with the SAPHIRE system using a graphical user interface (GUI) that is displayed on a touch screen that is attached to the patient’s ergometer. With the patient population in mind, designing an easy-to- use user interface will be one of the greater challenges of the project, even though three weeks of training under supervision will mitigate the problems to some degree. The next figures show a first concept of the user interface. The interface will rely on clear, concise messages and color-coded buttons that use a traffic-light scheme, meaning that a red button signals a severe problem, yellow a problem or an issue while green is generally the sign to go ahead. The order of the figures reflects the steps of use case UC-1 from deliverable D3.2.1. Figure 6. Welcoming the patient Page 19 of 27
  • 20. Figure 7. Instructions for the application of the sensors Figure 7 is only one way to guide the patient through the process of applying the sensors. As soon as patients become more proficient with the system, they might not want to acknowledge each electrode but rather have to acknowledge only once that they applied all the sensors. Figure 8. Reminding the patient to plug the ergometer in, if needed Page 20 of 27
  • 21. Figure 9. Interoperability Platform establishes connection with sensor network Figure 10. Asking the patient to initiate the connection to the clinic As shown in Figure 10, the connection needs to be initiated by the patient. By doing so, the patient agrees to transmit the sensor and training data to the clinic. Page 21 of 27
  • 22. Figure 11. Status screen during a connection attempt Figure 12. Connection to the clinic failed Figure 12 would be displayed to the patient if the platform cannot establish the connection to the clinic. This figure also implies that the system requires first level support, helping the patient resolve technical issues they might be experiencing with their system. Page 22 of 27
  • 23. Figure 13. Measuring the vital signs in rest before the training begins Figure 14. The patient can begin the training If the vital signs are within the limits defined by the physician, the patient can begin the training. A push on the red button aborts the training, raising an alarm, while the yellow one serves as an even button. Page 23 of 27
  • 24. Figure 15. The vital signs indicate a possible problem If the patient’s vital signs during the training leave the “safe corridor”, a message is displayed on the screen, telling the patient why the resistance is being adapted in order to bring the vital signs back into the allowed corridor. Figure 16. Training is being aborted If the sensor data indicate a severe problem, the training will be aborted. An aborted training like this will also send a high-priority alert to the physician who can then contact the patient and/or initiate other measures, e.g. sending an ambulance to the patient’s home. Page 24 of 27
  • 25. Figure 17. After the exercise As outlined in use case UC-1, the patient’s vital signs are measured during the “cool-down” phase after the actual exercise. After this, the patient is asked to specify the perceived exertion, using the (modified) Borg scale. Figure 18. Asking the patient about the percieved exertion 3 OPERATIONAL SCENARIOS The patients for the HomePA are recruited for study participation directly after successful coronary intervention at the beginning of the three week rehabilitation program. The patients will be informed and instructed in detail. A continuous preparation and testing of the equipment should begin after the first week of rehabilitation. 3.1 Rehabilitation of the inpatient Page 25 of 27
  • 26. According to the guidelines one part of the cardiac rehabilitation program is based on an exercise training program (1-3). Exercise training starts with multiple sessions of low-intensity exercise, with gradual increase in the duration of the sessions. The individual resistance of each patient should be tested by bicycle ergometer. 3.2 Secondary prevention of the outpatient A total observation period of three months is planned for four patients. 40 minutes training five times a week according to the specifications should be completed. During this time the ergometer performance as well as the heart and breathing frequency is continuously recorded. Intermittently, a 12-lead ECG is recorded at rest, 30 minutes after exertion, as well as 1, 5 and 10 minutes after the exertion phase. Intermittently, the blood pressure is recorded at rest, after each 10 minutes of exertion as well as 5 and 10 minutes after the end of the exertion phase. The thresholds of all parameters are set individually. The acceptable zone of values is defined as the “green zone”. The so called “yellow zone” of values will be defined as the relative alarm zone, which alarms the patient to stop the exercise and to control the parameters at the resting period. The so called “red zone” is the absolute alarm zone, which advises the patient to go to the practitioner the next day. If the patient feels under par he will be advised to go to hospital immediately. The applicable stop criteria for the ergometer training are angina pectoris, shortness of breath, as well as increasing malaise. The patient can stop at any time when these symptoms occur but must activate the red signal by himself. After normal completion of the training a subjective view of the degree of exertion according to the modified Borg scale is recorded by the patient on a hand held console. A continuous data acquisition is planned for the duration of the exercise training. After the training has been completed the set of data should be sent to the central office at the SSK, where the evaluation is performed within 24 hours. If irregularities in the training data are noted when it is evaluated then the responsible investigator of SSK will notify the patients and give them appropriate instructions. The transmission of the 12-lead ECG data also occurs after every training programme, and will be evaluated in the SSK. If respective ECG irregularities are diagnosed then the SSK will also get in contact with the patient. 4 MEDICAL ETHICS, SECURITY AND CONFIDENTIALITY REQUIREMENTS The HomePA within the SAPHIRE Project is a clinical study that will be mainly observational, meaning that no action/drug will be tested on the patient. However, based on the Clinical Decision Support System, physician’s actions are susceptible to be influenced by the patient’s enrolment in the pilot application due to patient-specific generated recommendations and alerts. Therefore, medical ethics and security issues can be raised and specific requirements should be formulated to ensure safety of the patients and of the physicians and also the compliance to existent ethical regulations. The selection of patients in a stable status, not requiring intensive care has been planned to minimise risks for this application. The patients will only be enrolled in the HomePA after signing an informed consent. The approval of the Ethical Committee for the planned clinical investigation we will ensure that the legal and ethical requirements are fulfilled. Page 26 of 27
  • 27. The HomePA interface should guarantee confidentiality for the patient and therefore the name and personal data of a certain patient should only be available to the treating physician, member of the SAPHIRE team. For the web system architecture, a special patient identification number should be generated. Security issues related to sensor data and transmission of data in the system are part of system’s architecture and will be all covered by the responsible partners. 5 REFERENCES [Bo70] Borg G. Perceived Exertion as an indicator of somatic stress. Scandinavian Journal of Rehabilitation Medicine. 1970;2:92-98. [Le03] Leonard P, Beattie TF, Addison PS, Watson JN. Standard pulse oximeters can be used to monitor respiratory rate. Emerg Med J 2003;20:524-525 [Mo85] Moody GB, Mark RG, Zoccola A, Mantero S. Derivation of Respiratory Signals from Multi-lead EGCs. Computers in Cardiology 1985;12:113-116 [Mo86] Moody GB, Mark RG, Bump MA, Weinstein JS, Berman AD, Mietus JE, Goldberger AL. Clinical Validation of the ECG-Derived Respiration (EDR) Technique, Computers in Cardiology 1986; 13:507-510 Page 27 of 27