Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Application for Texas Certificate of Title Form 130U by ynt39010

VIEWS: 479 PAGES: 130

Application for Texas Certificate of Title Form 130U document sample

More Info
									                                  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 8.2.1
       Design of the Implementation of
      Hospital Pilot Application Scenarios

Due Date:                                   March 31, 2007
Actual Submission date:                     April 03, 2007
Project Dates:                              Project Start Date : January 01, 2006
                                            Project End Date : June 30, 2008
                                            Project Duration : 30 months
Leading                     Contractor IPA

                     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)
Saphire Consortium Contacts:

Organisatio     Name                Phone              Fax             E-Mail
METU-           Asuman Dogac        +90-312-           +90(312)210100
SRDC                                2105598            4
CYBERFAB Micheal Setton             +33-476-081-       +33-672-995-
                                    957                202
OFFIS           Marco               +49-441-9722-      +49-441-9722-
                Eichelberg          147                102
ALTEC           Adamantios          +30         2310 +30          2310
                Koumpis             595646           565630
IPA SA          Gabriel Spiridon +40 21 318 00 +40 21 316 16
                                 55            20
SCUB            Maria Dorobantu +4021 3170108          +4021 3170108
SSK             Michael             +49 5424641565 +49 5424641202 mboeckelmann@schuechterm

TEPE            Bulent Kunac        +90-312-           +90-312-
                                    2919100            2662998

Document History:
Version Date                   Changes                 From                                  Review

0.1      August 21, 2006       First draft of template IPA                                   Internal
0.2      September      20, Second draft of            IPA                                   Internal
         2006                  template
0.3      November 10,          First release           IPA, METU SCUB, OFFIS, TEPE,          Internal
         2006                                          CYBER
0.4      November 28,          First release updated   IPA, METU SCUB, OFFIS, TEPE,          Internal
         2006                                          CYBER
0.5      December 06,          Second release          IPA, METU SCUB, OFFIS, TEPE,          Internal
         2006                                          CYBER
0.6      December 15,          Second release          IPA, METU SCUB, OFFIS, TEPE,
         2006                  updated                 CYBER
0.7      February 09, 2007 Third release               IPA, METU, TEPE, SCUB                 Internal
0.8      February 20, 2007 Third release updated METU, TEPE, IPA, SCUB CYBER                 Internal
0.9      March 12, 2007        Final release           METU, IPA, SCUB                       Internal

                                                                                         2 / 130
1.    INTRODUCTION                                                                          6

1.1. PURPOSE AND SCOPE                                                                       6

1.2. DEFINITIONS, ACRONYMS AND ABBREVIATIONS                                                 6

1.3. OVERVIEW                                                                                7

2.    GENERAL HPA ARCHITECTURE                                                              9

2.1 HPA SYSTEM GENERAL ARCHITECTURE                                                          9

2.2 HPA WARDS AND MONITORING ROOM DISTRIBUTION                                              11

3.    OPERATIONAL MEDICAL SCENARIOS                                                         13

4.    CLINICAL MEDICAL GUIDELINES TO BE USED IN HPA                                         21

4.1 MEDICAL FLOWCHARTS                                                                      21

4.2 CLINICAL MEDICAL GUIDELINES                                                             25
   4.2.1 CGM 1                                                                              25 GRAPHICAL REPRESENTATION OF CGM 1 [7,8]                                       25 PRELIMINARY SIMULATION                                                        26 URL FOR CGM1                                                                  31
   4.2.2 CGM 2                                                                              31 GRAPHICAL REPRESENTATION OF CGM 2                                             31 GUIDELINE MODELING                                                            32 PRELIMINARY SIMULATION                                                        32 URL FOR CGM2                                                                  32


5.    SUPPORT INTERFACES REQUIRED FOR HOSPITAL PA                                           36

5.1 ELLECTRONICAL HEALTH RECORD                                                             36
   5.1.1 EHR STANDARDS AND CODING SCHEMES                                                   36
   5.1.3 PATIENT EHR DEVELOPMENT                                                            47 HL7 CDA                                                                       47 CREATING CDA OF THE PATIENT                                                   48 STORING CDA OF THE PATIENT IN THE XDS REPOSITORY                              49

5.2 WEB SERVICES INTERACTING WITH MIS                                                   50
   5.2.2 EXPOSING MIS FUNCTIONALITIES AS WEB SERVICES                                   54

5.3 EHR + WEB SERVICES ALPHA TESTING                                                        55
   5.3.1 TESTING OF EHR TOOL                                                                55
   5.3.2 TESTING FOR CDA CREATION                                                           55
   5.3.3 TESTING FOR MEDICAL WEB SERVICES                                                   56

5.4 RULES FOR FILTERING AND STORING SENSOR DATA                                             58

5.5 HPA WEB SERVICES FOR EXPOSING SENSOR DATA                                               63

                                                                                  3 / 130
6.    ALARMS                                                                                          64

6.1 ALERT COMPONENT DEVELOPING                                                                         64
   6.1.1 TRANSMISSION CHANNELS DESIGN [communication medium, transmission secured methods, user
   devices, etc.]                                                                                      64 COMMUNICATION BETWEEN SYSTEM AND ALARM COMPONENT                                         64 COMMUNICATION BETWEEN ALARM COMPONENT AND USERS                                          66
   6.1.2 USER MANAGEMENT SUBCOMPONENT                                                                  69 USERS                                                                                    69 DEVICE(S) ADAPTATION DESIGN                                                              72 ALERTS PRIORITIZATION                                                                    72 DELIVERY CONTROL DESIGN [including alert receiving acknowledge]                          74

6.2 SENSORS ALARM                                                                                      75
   6.2.1 DEFINING ALARM THRESHOLDS                                                                     75
   6.2.2 DEFINING ALARM MESSAGES (syntax)                                                              75

6.3 CGMs ALARMS                                                                                        77
   6.3.1 DEFINING ALARM THRESHOLDS                                                                     77
   6.3.2 DEFINING ALARM MESSAGES (syntax)                                                              77

6.4 ALERT SYSTEM CONFORMITY WITH RELATED MEDICAL STANDARDS                                             79

7.    HPA EQUIPMENT MEDICAL CERTIFYING                                                                80

8.    HPA TECHNICAL SPECIFICATIONS                                                                    83

8.1 HARDWARE SPECIFICATIONS                                                                            83
   8.1.1. SENSORS SPECIFICATIONS                                                                       83 GENERIC SYSTEM FUNCTIONALITIES                                                           83 PULSE OXIMETER                                                                           85 BLOOD PRESSURE MONITOR                                                                   85 TWELVE LEAD ECG                                                                          86 RESPIRATION RATE                                                                         87 SENSORS SIMULATOR                                                                        88
   8.1.2 PCs AND PERIPHERALS SPECIFICATIONS                                                            92

8.2 SOFTWARE SPECIFICATIONS                                                                            95

AND VALIDATION                                                104

9.1 INTRODUCTION                                                                                      104

9.2 VALIDATION PROCESS MODEL                                                                          104
   9.2.1 ESTABLISH VALIDATION REQUIREMENTS                                                            105 VALIDATION SCOPE                                                                        106
   9.2.2 SPECIFY VALIDATION                                                                           107 QUALITY METRICS SELECTION FOR HPA PILOT APPLICATION                                     107 ASSESSMENT CRITERIA DEFINITION                                                          108
   9.2.3 DESIGN THE VALIDATION OF HPA PILOT APPLICATION                                               108 TEST FACILITY                                                                           109 SELECTING THE SCENARIOS                                                                 109 METRICS SELECTION                                                                       109
   9.2.4 EXECUTE THE VALIDATION                                                                       117 DATA SCORING                                                                            117 STATISTICAL ANALYSIS                                                                    117 PRESENTATION OF THE RESULTS                                                             117 PERFORMANCE RESULTS                                                                     117

                                                                                            4 / 130
TESTING]                                                          119

11. REFERENCES                                                    130

                                                            5 / 130

This document contains the structure for the ―Design of the Implementation of Hospital Pilot
Application Scenarios‖, and requires contributions from all the involved partners. All these
contributions will be reviewed, refined and used as building blocks for the final release of D.8.2.1
and as such will play an important part in the fulfillment of the SAPHIRE in-Hospital Pilot
Application (Project Milestone M11).
The Hospital Pilot Application will be one of the two practical demonstrations of the SAPHIRE
system, together with the Home Pilot Application. Its scope is to test the intelligent bedside
monitoring of the patients through wireless sensors and to integrate the data from the sensors with
the data from the electronic medical records in the system interoperability platform in order to
generate alerts and recommendations via an intelligent Decision Support System based on specific
clinical guideline models.
The ultimate goal of this pilot application will be to provide guideline-based, patient-specific
recommendations to the hospital doctors, in order to optimize in-hospital care in terms not only of
timing of reaction and medical action, but also in terms of European standards. This system will
have to be useful for the patients (optimized care), useful for the doctors (guidelines
implementation, medical education, reducing workload, avoiding human error) and also useful for
the hospital care system in terms of cost-effectiveness.
The goals of this document will be to list all the foreseeable scenarios for the HPA, to identify the
specific constraints at the implementation site, to underline the required support subsystems – even
those that are not part of the SAPHIRE project, like the MIS – the hardware and software
specifications, as well as to identify possible problems that might arise during the implementation
phase at SCUB – such is the lack of a MIS – and propose solutions to overcome these problems.
A set of procedures and assessment criteria for testing, tuning and validation will also be developed,
and SCUB will also provide some sample patient data to facilitate the HPA prototype alpha testing.

The following definitions and acronyms are going to be encountered in the text of this document:
       Hospital Pilot Application (HPA) = in-hospital pilot demonstration for the SAPHIRE
       Emergency Hospital of Bucharest (SCUB) = partner responsible for the HPA development;
       Institute for Automation Bucharest (IPA) = strongly involved partner in the design of HPA;
                                                                                             6 / 130
      Middle East Technical University (METU) = SAPHIRE project coordinator;
      Medical Information System (MIS) = a comprehensive, integrated information system
       designed to manage the administrative, financial and clinical aspects of a hospital – this
       encompasses paper-based information processing as well as data processing machines which
       aims to achieve the best possible support of patient care and administration by electronic
       data processing.
      Electronic Health Records (EHR) = a personal medical record in digital format, which
       includes information relating to the current and historical health, medical conditions and
       medical tests of its subject, as well as data about medical referrals, medical treatments,
       medications and their application, demographic information and other non-clinical
       administrative information
      Web-service (WS) = a software system designed to support interoperable machine-to-
       machine interaction over a network, as defined by W3C
      Clinical Guideline (CG) = a document with the aim of guiding decisions and criteria in
       specific areas of healthcare, as defined by an authoritative examination of current evidence
       (evidence-based medicine); guidelines usually include summarized consensus statements,
       but unlike the latter, they also address practical issues.
      Clinical Guideline Model (CGM) = a clinical guideline represented in a computerized
       format that can be interpreted by a computer program which can than perform the necessary
       actions (for e.g. request data from an electronic health record)
      Care2X (C2X) = an open source software designed to integrate different information
       systems in healthcare organizations into a single system.

First of all the proposed general HPA architecture will be reviewed, and point out the particularities
of its deployment site at SCUB (wards, monitoring rooms‘ distribution etc.).
Next, the suggested steps for HPA scenarios will be presented, as well as the operational medical
scenarios that will be implemented.
Afterwards the clinical guideline models (CGMs) that are going to be used in HPA that have
already been developed by METU and IPA based on the medical flowcharts of the clinical
guidelines (CGs) provided by SCUB will be analyzed.
Some the support subsystems which are required by HPA will be than discussed:
   -   MIS – focusing on the EHR standards, coding specifications and the interface extensions
       that will have to handle these specific HPA data;

                                                                                             7 / 130
   -   Web-services that will expose the necessary data to the system, from the MIS, according to
       the CMGs‘ requirements, and from the sensors, as well as rules for storing the filtered
       sensors‘ data into the MIS
   -   The alarm subsystem – specifying the types of alarms (sensor or CGMs alarms) required by
       SCUB at HPA, together with their thresholds and alarm messages, as well as the user
       management system for these alerts (for e.g. subscription of certain users to specific types of
       alarms), alerts prioritization, delivery methods and control procedures
The next topic will cover the hardware equipment required for HPA: the bio-sensors and the PCs
and peripherals which will be deployed at SCUB.
The technical specifications for HPA will be listed in chapter 9, covering both hardware
specifications – for bio-sensors, PCs and peripherals and the rest of equipments and materials
required for the HPA implementation – and the corresponding software specifications for all the
modules that will be specifically developed for the HPA.
This deliverable will be concluded with the procedures and assessment criteria for testing, tuning
and validation.
Appendix: some sample patient data for HPA prototype alpha testing, provided by SCUB

                                                                                             8 / 130

The Hospital Pilot Application will have the following main components:
 HPA Sensors Network;
 HPA Interoperability Platform;
 HPA Clinical Decision Support System:
- Agent assignment + Agent Factory component;
- Clinical Guidelines Models;
- Alarms sending component;
- Support Interface for Doctors;
 Sensors Data Real Time Visualization Interface;
 WebMedicalServices Interfaces (1st Troponin I/T Measurement LabOrder, 2nd Troponin I/T
Measurement LabOrder, Cardiac Troponin Measurement LabOrder, CKMB Mass Measurement
LabOrder, Coronary Angiography LabOrder, etc.);
 Med. Analyses Explanation Software Packages (ECG / Cardionics / HES…);
 Security and Confidentiality component;
The Hospital Pilot Application will have the following main graphical interfaces:
•   GUI Agent Assignment + Agent Factory (authentication, patient and sensors selection, CGM
selection, parameters customisation);
• Support Interface for Doctors (Steps trace, Alarms, Recommendations);
• Sensors Data Real Time Visualisation Interface;
• WebMedicalServices Interfaces (1st Troponin I/T Measurement LabOrder, 2nd Troponin I/T
Measurement LabOrder, Cardiac Troponin Measurement LabOrder, CKMB Mass Measurement
LabOrder, Coronary Angiography LabOrder, etc.);
• EMR Interface.
• Alarm System Web Interface

                                                                                    9 / 130
The general HPA architecture is shown in the figure from below (figure 2.1):

                              Figure 2.1 – General HPA architecture

                                                                               10 / 130
The Hospital Pilot Application (HPA) will be developed in the Department of Cardiology of the
Emergency Hospital of Bucharest. Two regular wards, each of 2 beds, will be dedicated to the
application (see photo 1, 2, 3). One of the wards will have oxygen availability for oxygen mask
ventilation. Toilets and showers will be separate rooms for each ward, located 1 meter from the
wards. Therefore, there will be between one and four patients monitored at the same time (ideally
all 4 beds will be occupied by patients taking part in the application). Depending on patients'
diagnosis and severity, 24 to 48 hours of monitoring will be performed for each patient during the
The monitoring/ development area will be located right near the wards, being isolated by walls form
the main corridor. All area will be secured and the equipment will be installed in the office in this
area. The distance from the wards will be no more than 10 meters. Personnel in charge with the
development of the application will access the area every 2 hours to check for emails/ messages/
malfunctioning. Rapid response to red alerts will be provided from the intensive care unit (25
meters distance) upon receiving of the message on a dedicated phone to be carried by the person on-
call in charge for the HPA. As this is an emergency facility, 24 hours supervision will be available.
More details about the alarm transmission can be found within chapter 7.1.1 specifications.

               Photo 1. Area to be isolated, secured and used as monitoring area for HPA.

                                                                                              11 / 130
  Photo 2. Monitoring area and access to the wards for HPA.

Photo 3. One of the two identical wards to be used for the HPA.

                                                                  12 / 130

 The Operational Scenarios, as already defined in D.8.1.1 illustrate, from the user‘s perspective,
 what will be experienced when utilizing the HPA system under various situations.
 These operational scenarios are a set of different testing procedures, regarding:
          System functionality based on the simulation of the sensor network operation
          Alarm functionality (direct alarms from sensor network)
          CGMs general operations:
                           adequate recommendations and alarms
          Functionality of Medical Services and eInterpretations by CGMs
          Functionality of Medical Analyses of the sensor data
                       1.      directly or composing sensor data.
 From the medical point of view, the operational scenarios will be developed before the actual start
 of the Hospital Pilot Application and will include different possible medical and practical
 situations that could be imagined to arise when using the system. The Scenarios will be used for
 the following purposes:
     1.      to test the functionality of the systems involved and of the communications between them;
     2.      to test the training of clinical staff in the operation of the system;
     3.      to test the tolerance of the system for the patients and the possible problems arising from
             continuous wireless monitoring;
     4.      to test the response of the Clinical Guidelines Model and the medical response to the
             Intelligent Clinical Decision Support System, as well as the medical response to the Alert
     5.      to test the medical validation of the system's decisions/ recommendations.
Therefore, we have built up Medical Operational Scenarios to deal with:
 1.        Starting the monitoring:
           1.          Choose the patient
           2.          Assign the sensor set
           3.          Set up the monitoring parameters and the alert thresholds
           4.          Choose the guidelines
 2.        Receiving data form the sensors:
           1.          Visualize of the sensor data
           2.          Analyze of the sensor data
 3.        Receiving the system alerts:
           1.          Red alerts

                                                                                              13 / 130
     2.         Yellow alerts
     3.         Alerts from the guidelines
4.   Retrieving data from the EMR/HIS:
     1.     Input data to the EMR/HIS
     2.     Output data from the EMR/HIS
5.   Executing the guidelines:
     1.     Execution of the Clinical guideline by accessing the sensor data and Electronic
     Healthcare Records of the Patient
     2.         Generation of clinical decisions/ recommendations
     3.         Validation of the clinical decision/recommendations
6.   Training the medical staff to use the system:
     1.     Inform the patient
     2.     Attach the sensors
     3.     Check quality of transmitted data
     4.     Check the alerts on a regular basis
     5.     Correct transmission if artifacts/ interruption
7.   Discontinuation of patient monitoring:
     1.     Stop the monitoring
     2.     Medical conclusions and discharge report
8.   Periodic system service/ check-up
     1.     Check the sensors
     2.     Check the EMR
     3.     Check transmission and functions of the system
     4.     Check web services and security

                                                                                  14 / 130
                              1. Starting the monitoring

                                        Patient selected
                                 Dx: Acute coronary syndrome
                           In a stable status (does not require CCU)
               Patient signs informed                  Patient is moved to a
               consent to participate                     dedicated ward

Set of guidelines chosen
  and assigned to the                 Patient-specific                 Available sensors set is
         patient                   monitoring parameters                 selected via GUI
                            (5)   and user alert thresholds                   interface
                                          defined             (4)


                             2. Receiving data form the sensors

                              Sensor data
                            ECG, BP, SpO2

 (2)                                    (1)
                BT Manager
                   BT                                                       SENSOR ALERTS
                             GATEWAY PC:
                                                                            •VIA MOBILE (RED)
              Visualization of the data in the patient window
                                                                            •VIA EMAIL

               Server PC & Workstation PC:
                                                                (3)         •ALERTS TO BE
                                                                            TAKEN AS INPUT
 Analyzing the data:                                                        FOR THE
       - Compare to thresholds
       - ECG analysis (Rhythm and ST deviation)
       - + data fusion and trend detection

                                                                                            15 / 130
The sensors data visualization interface requirements have been defined in D8.1.1. The following
refinements need to be done here:
         the interface should be running on the 2 gateway PC's in the wards, allowing in the
meantime setup of the monitoring parameters and thresholds for each patient
         a patient-specific window for each patient should be available on the gateway (each ward
will have 2 patients monitored in the same time, so we should have 2 windows for visualizing the
sensors data on each gateway PC.
         there is no need for continuous ECG 12 lead display, one rhythm lead should be all right, as
long as 12 lead analysis is possible real-time;
         main thresholds (HR, BP, SpO2) should be seen on the screen to avoid misinterpretation of
         HR, SpO2 and BP values can be displayed as values or curves or both;
         the trends should be displayed as curves or value tables on a pop-up window and they can
generate alert messages that should be also displayed and sent to the Alert System;
         a pop-up window should display a list of red and yellow alerts for last 6-8 hrs and should
allow visualization of the alert recorded (i.e. ECG strip), to allow checking for correctitude/artifacts;
         the data visualization interface should allow displaying of sensors data and alarms;

                                          3. Receiving the system alerts

                            Doctor/nurse on-call receives an alert

                                                      Yellow alert
     Red alert                                        Via email/ registered in the system on
     Via mobile phone/pager                           the interface, that should be checked
                                                      every 2-6 hrs

     Immediate medical                   Medical validation:
     intervention:                       • Check the patient and the alert
     • Check the patient and             • Decide if action is necessary
     the alert
                                         • Check initiation of guidelines execution (if the case)
     • Validate                          • Check clinical decision/recommendation by SAPHIRE
     • Medical action                    Platform (if the case)
                                         • Validate
                                         • Medical action

                                                                                                 16 / 130
                                  4. Retrieving data from the EMR/HIS

                                            Patient selected
                                     Dx: Acute coronary syndrome
                               In a stable status (does not require CCU)


       Doctor fills in all the data in the dedicated EMR system, according to patient file and
                                        to the pre-specified codes
            (no web services available to automatically retrieve the data from the labs/files/


                     Data from the EMR/HIS is used by Agents via web services

N.B.: To be mentioned that new available data should be fed into the system while monitoring
the patient and should be continuously sent to the Platform (i.e. a result form coronary
angiography that has been recommended by the Guidelines Model).

                                                                                            17 / 130
                                 5. Executing the guidelines


              Information transmitted from Gateway PC to Interop. Platform:
       Receives and integrates sensor data (pre-defined rules) and EMR data for this
                                    analyzed and alarms are detected
                     Sensor data is (2)

                                Sensor alarms are sent to the CGMs

Display flowcharts to be             executing    of    the
executed and initiate                flowcharts  may     be
execution                            triggered  by   sensor
                                                                Go to related flowcharts/
                                                                guidelines if the case

                                                    GENERATION OF CLINICAL
              MEDICAL                             DECISION/ RECOMMENDATIONS/
             VALIDATION                     (7)         ALERT MESSAGES


                                                                                       18 / 130
                     6. Training the medical staff to use the system

                                   Patient selected
                  Inform the patient about the application and get
                                the consent signed

            (1)                                       (2)
Attach the sensors                    (2)
                                               Regular checks of the alerts
Verify the quality of the sensor
data on the interface                          - every 2 hours

Train on a volunteer                           - correct if artifacts


             Remove and re-attach sensors if:
             - patient moves to different wards or to different
             - sensors fell off
             - any malfunction (bad quality of signal, aso.)

                        7. Discontinuation of patient monitoring

                                Discontinue the monitoring
          - when is finished (24-48 hours); thanks to the patient!
          - when adverse events occur that need return of the patient to
          - on patient's request

   Doctor fills in a medical discharge report in a separate database with medical
     conclusions of the participation of that specific patient to the application
                     Possible follow-up of the patient after discharge

                                                                                19 / 130
                                 8. Periodic system service/ check-up

             Check-up and service for                            Back-up of the EMR data
             the sensors                                         - every day
             - once a week

             Check-up transmission                               Check-up web services and
             and function of the                                 security
             system's components                                 - once a week
             - once a week

N.B. Simulation tests for all possible situations in the guidelines flowcharts will be carried out using
a patient's alert/ data simulator and also using samples of patient data in the EMR, one month before
the actual start of HPA. After starting the application, we will still carry on once a week some
simulations for red alerts, to test continuous functionality of the system. Service of the sensors and
security of the services should be carried on by the partners involved in their development.

The operational scenarios will be tested in a special testing phase that will be performed before the
actual start of the pilot application on the patients and they will require a patient simulator to
generate all the possible alerts/ trends/ clinical situations.

                                                                                               20 / 130


The medical flowcharts related to Clinical Guideline 1 are described in D.5.2.1 / Section 2.4.
The following medical flowcharts have been developed for Clinical Guideline 2.

                   Flowchart 1. Diagnosis of acute coronary syndrome (Level A)

                                                                                            21 / 130
 Flowchart 2a.. Risk stratification (Level A) / For long-term risk

    Flowchart 2b. Risk stratification (Level A) / For acute risk

Flowchart 3. Troponin-based stratification and therapeutic strategy

                                                                      22 / 130
Flowchart 4. Recommended treatment in non ST-elevation ACS.

                                                              23 / 130
                             Flowchart 5. Invasive treatment decision.

It is possible that in future these flowcharts to support some small refining, according with end-user

                                                                                            24 / 130

4.2.1 CGM 1
Clinical Guideline Model 1, the specifications of which have been defined by the healthcare
professionals in SCUB, has been computerized by METU. The tasks accomplished in
computerization of CGM 1 can be classified into several categories which will be described in the
following subsections.
In the beginning of the process, conforming to the flowcharts provided by SCUB, CGM 1 has been
defined in GLIF using the Protégé Ontology Editor. Then the clinical guideline model has been
visualized by SAPHIRE Monitoring User Interface. As a result the graphical model presented in 0
has been obtained.
After obtaining the model, handlers have been implemented to handle the different constructs in
GLIF. Thereafter the input and output facilities which the system has to interact with during the
guideline execution has been integrated to SAPHIRE. In this stage testing of external components
which will be provided by other partners (such as Medical Web Services, Sensor Web Services) has
been performed by substituting those services with locally implemented non trivial tester versions. GRAPHICAL REPRESENTATION OF CGM 1 [7,8]
The guideline model which is converted to GLIF structure has been displayed with Monitoring GUI
component of SAPHIRE. As well as seeing the whole guideline flow, this provided us with a good
way of testing the CGM. The graphical representation of CGM 1 obtained from Monitoring GUI is
given in Figure 4.1.

                                                                                           25 / 130
                           Figure 4.1 - Graphical representation of CGM 1 PRELIMINARY SIMULATION GUIDELINE MODELING
Modeling of the clinical guideline in GLIF has been done using the Protégé Ontology Editor. The
flowcharts provided by SCUB have been carefully examined and the guideline steps that exist in
those flowcharts have been transformed into GLIF constructs. The GLIF used in guideline modeling
is an extended version of GLIF, which enables the users to define the real life structures that exist in
                                                                                              26 / 130
Hospital Pilot Application (such as Sensor, EHR Entities, Medical Services and Alarms). After the
guideline has been implemented, it has been exported to OWL format. The execution and
processing of the guideline is conducted using this exported OWL model. GUIDELINE HANDLING
After the guideline model has been exported to OWL format, the system has to be able to process
the OWL file. The GLIF Model has different sections to represent the Medical entities which need
to be handled during the guideline execution.
Separate handlers have been implemented for the different types of constructs. These handlers can
be grouped into the following categories according to their related constructs.
       Criteria Handlers
       Guideline Step Handlers
       Action Handlers
The handlers have been implemented and tested using the OWL Model of CGM1 and validated
through this test.
The handler classes are generic and they are not specific to only the CGM1. Those handlers are
available to be used in processing of other guidelines that will be subject to SAPHIRE project. The
handling of GLIF constructs is detailly specified in Deliverable 5.1.1. EHR SERVICES
In Deliverable 8.1.1, the healthcare professionals in SCUB had specified the necessary patient
information that needs to be stored in Electronic Health Record of the patient. In pre-simulation of
the CGM1, the specified data has been stored in IHE XDS Repository. A CDA document is
constructed which is used while retrieving the data stored in the XDS. The details of this process are
provided in Deliverable 4.4.1.
During the guideline execution, EHR Data has been fetched from this example CDA document via
JADE agents named EHR Agent and has been semantically mapped into GLIF entities. Deliverable
5.1.1 elaborates on semantic mapping of EHR data.
The document references related to the patient are semi-automatically assigned into the guideline
instance before start of the execution. This assignment is performed by Data Access Matching
Definer (DAMD) component of SAPHIRE. All guideline actions that need data access points are
listed in the DAMD and for each guideline action, according to their semantic category, available
documents are listed by searching the XDS registry. Please refer to Deliverable 5.2.2 for the details
of DAMD component.

                                                                                            27 / 130 SENSOR WEB SERVICES
In Hospital Pilot Application, there are three kinds of sensors which are namely ECG, BP and SpO2
Sensors, the data of which will be accessed through web services. In the pre-simulation of CGM1,
these services have been prototyped on METU side. The services have been implemented as cache
services. For the moment, they find the corresponding value from a database by using the id of the
patient. These cache services will also be able to be used to accelerate the setup of SAPHIRE
system for further testing purposes. The data that are needed by CGM1 from those three sensors
      ECGPR Status
      Patient Generated Event
      ECG ST Elevation Status
      SpO2 Status
      Heart Rate
      Systolic BP
One important group of services in entire SAPHIRE system is the Medical Services. In the
conceptual design, medical services are modeled as web services. These medical services include
lab orders, prescription orders, etc.
In the pre-simulation of CGM1, Care2X has been used as the medical services provider. Orders that
are created according to results of guideline execution have been stored in database of Care2X via
Web service interface. Those orders were able to be checked from the web interface of Care2X.
There are two kinds of web services needed for execution of CGM1. First kind of web services is
traditional synchronous web services. These services store procedure order, recommendation and
prescription which are decided from the evaluation of guideline steps. The synchronous web
services implemented for CGM1 simulation are as follows:
      storeProcedure
      storeMedication
Also implementation of an asynchronous web service was needed to test CGM1. An exemplary
asynchronous web service has been implemented for this purpose which has the name:
       coronaryAngiographyOrder
This service pushes an angiography order to the system and gets the result when the result medical
order is available.

                                                                                         28 / 130
As in the other services, medical web services have been assigned before execution of the guideline
semi-automatically by DAMD component (described in Deliverable 5.2.2). ALARM SYSTEM
Detailed specification of the Alarm System has been given in Deliverable 5.3.1 and the Alarms in
Hospital Pilot Application are discussed in Section 7 of the document. In this section, the alarms
that have been included in CGM1 have been described.
In CGM1, the alarm messages function as a notification facility which informs the healthcare user
about medical actions and decisions taken by the system. On this purpose, in the GLIF Model of
CGM1, Message Oriented Actions have been placed after Medically Oriented Actions. These alarm
messages are as follows:
       Aspirin Prescription Message
       CAGB Recommendation Message
       Clopidogrel Prescription Message
       Intravenously NTG Treatment Message
       Coronary Angiography Order
       Fibrinolysis Recommendation Message
       Metoprolol Treatment Message
       Morphine Treatment Message
       NTG Recommendation Message
       Oral Metoprolol Treatment Message
       Oxygen Medication Message
       PTCA Recommendation Message
These messages have been specified with URGENCY 2, which asserts the alarm has medium
degree of importance; also since this is a Hospital Pilot Application, the responsible person in all
messages has been specified as the DOCTOR. The delivery settings (medium, acknowledgment,
contact address) can be set by adjusting the rule based preferences. These alarms have been tested
successfully in the pre-simulation of the guideline. TESTING, INTEGRATION AND RESULTS
After the components have been implemented in the pre-simulation they are tested both separately
and integrated with the CGM1. The key issues concentrated in this testing have been stated as
      The proper flow of the guideline steps:
After the guideline handlers have been tried with simple guideline models which can be considered
as small and toy models compared to original ones , the handling mechanisms have been tested
                                                                                          29 / 130
through the actual Clinical Guideline Model #1. After correcting some minor bugs related to the
branching and synchronization of flow, the handling mechanism has been proved to work properly
      Data Retrieval from different sources:
As mentioned before, in Guideline Execution, patient data has to be retrieved from different data
sources. These can be Sensor data, EHR Data or Consulting Data which are obtained through web
services, XDS and ACL Messages respectively.
After these facilities have been separately tested, they are integrated into CGM1. The initial tests
showed that some issues had to be resolved to ensure the consistency with the data formats of the
received data and their mapping to the GLIF entities. The issues related to data formats have been
fixed in this phase however some of the mappings has been bypassed for performance issues and
left to future ameliorations.
      Correct Execution of the Scripts:
The Java Scripts that have to be executed for the decision steps and criteria handling had been
placed into the guideline definitions using Protégé. However it was not possible to test scripts
separately since scripts need retrieved data to return a meaningful result. Therefore the testing of the
scripts was performed right after the data retrieval mechanisms were integrated to the system. In the
integrated testing, some syntactic errors have been detected in the script and they have been fixed.
Moreover some errors due to name and type inconsistencies of the variables have been removed.
      Invocation of Medical Web Services:
The medical web services were tested separately first and the results were checked from Care2X
database. After the integration, the invocation within the guideline steps has been tested. In this
phase, some minor modifications on the invocation parameters, mappings and SOAP Client have
been done.
      Delivery of Alarm Messages:
SAPHIRE Alarm Component has been designed as a discrete component from the system.
Therefore initial testing of alarm delivery had been done independent from the guideline execution
with alarm messages generated by a tester agent. Alarm Component is integrated into Guideline
Execution Utility providing ACL Messaging communication between the related agents. This
integration has been tested and no disintegration between components has been recorded in this
phase. The alarm messages mentioned in have been tested through the guideline execution
and no problems have been observed.
      Monitoring of the Guideline Execution:
An essential part of Hospital Pilot Application is monitoring of the results. During the pre-
simulation of CGM 1, a monitoring facility with only one monitoring agent has been implemented.
Every change in the guideline execution has been reported to the monitoring side and a friendly user

                                                                                              30 / 130
interface is provided to the user. Through this interface, healthcare user is able to trace the guideline
execution and history. The details can be obtained from the Deliverable 5.4.1. URL FOR CGM1
The OWL file for CGM1 can be obtained from the URL below:
This file is obtained through exporting the GLIF Model of CGM1 to OWL and does not contain
assigned data access services. After that assignment is complete, the new OWL file is deployed on
Embedded Tomcat of the computer that assigns the data access services.

4.2.2 CGM 2
Clinical Guideline Model 2, the specifications of which have been defined by the healthcare
professionals in SCUB, has been computerized by IPA. The tasks accomplished in computerization
of CGM 2 can be classified into several categories which will be described in the following
In the beginning of the process, conforming to the flowcharts provided by SCUB, CGM 2 has been
defined in GLIF using the Protégé Ontology Editor. Then the clinical guideline model has been
visualized by SAPHIRE Monitoring User Interface. As a result the graphical model presented in 0
The guideline model which is converted to GLIF structure has been displayed with Monitoring GUI
component of SAPHIRE. As well as seeing the whole guideline flow, this provided us with a good
way of testing the CGM. The graphical representation of CGM 2 obtained from Monitoring GUI is
given in Figure 4.2.

                                                                                               31 / 130
                          Figure 4.2 - Graphical representation of CGM 2 GUIDELINE MODELING
Modeling of the clinical guideline in GLIF has been done using the Protégé Ontology Editor. The
flowcharts provided by SCUB have been carefully examined and the guideline steps that exist in
those flowcharts have been transformed into GLIF constructs. The GLIF used in guideline
modeling is an extended version of GLIF, which enables the users to define the real life structures
that exist in Hospital Pilot Application (such as Sensor, EHR Entities, Medical Services and
Alarms). After the guideline has been implemented, it has been exported to OWL format. The
execution and processing of the guideline is conducted using this exported OWL model. PRELIMINARY SIMULATION
METU has tested CGM 1 extensively, including necessary tests. As for CM1, for CGM2 have been
developing similar preliminary tests, by tracing the guideline steps, invoking the services and
functionalities (HER, Sensor and medical web services, alarm system), checking guideline steps
proper flow, data retrieval from different sources, correct execution of the scripts, execution of
medical web services, alarms delivery, monitoring of guideline execution.
We estimate that these tests will be achieved before the 2nd D.8.2.1 release. URL FOR CGM2
The OWL file for CGM2 can be obtained from the URL below:

                                                                                         32 / 130
This file is obtained through exporting the GLIF Model of CGM 2 to OWL and does not contain
assigned data access services. After that assignment is complete, the new OWL file is deployed on
Embedded Tomcat of the computer that assigns the data access services.


Medical practice standards set levels of 'good practice', i.e. they identify the quality standard below
which a service provider or facility must not fall for a particular service. For the medical domain,
they are recognized as medical guidelines. They can have a local or regional applicability and they
can be included in the legislation of that region. The implementation of guidelines in medical
practice is considered very important and their computerized modeling is a suggestion of Council of
Europe Memorandum on the Methodology of Guideline Development. ―Integrating guidelines in
computerized decision support systems is an effective implementation strategy, especially with
patient-specific interactive reminders.‖1
The desirable attributes of clinical practice guidelines (IOM 1990):
              Validity
              Clinical flexibility
              Strength of evidence
              Clarity
              Estimated outcomes
              Multidisciplinary process
              Reliability/reproducibility
              Scheduled review
              Clinical applicability
              Documentation
Hospital Pilot Application for the SAPHIRE Project will be developed in Romania. Romania will
become member of the EU in January 2007. More than that, the Romanian Society of Cardiology
has been a member of the European Society of Cardiology (ESC) for years and so the guidelines of
ESC have been endorsed here.
There are some rules in development of medical guidelines. The most important is the ‗evidence-
based medicine‘. ―When evidence has been systematically collected and there is sound data on
effectiveness, it forms a good basis for further interpretation.‖1 For Cardiology domain, there are

                                                                                             33 / 130
two big working groups for guidelines development: AHA (American Hearth Association) and ESC
(European Society of Cardiology), as we have stated in D 5.2.1. in regard to clinical medical
guidelines. Their guidelines are based on results of many big studies and meta-analysis recognized
over the world.

The flowcharts for medical decisions of SAPHIRE project have been built based on ESC
practice guidelines, as mentioned in D5.2.1 "Clinical Guidelines Models to be Used in Clinical
Decision Processes. The American ACC/AHA Guidelines have also been taken into consideration
as medical standards for building and validating the models:
1.     Management of acute coronary syndromes in patients presenting without persistent
ST-segment elevation; The Task Force on the Management of Acute Coronary Syndromes of
the European Society of Cardiology
European Heart Journal (2002) 23, 1809–1840
Michel E. Bertrand, Chair, Maarten L. Simoons, Keith A. A. Fox, Lars C. Wallentin, Christian W.
Hamm, Eugene McFadden, Pim J. De Feyter, Giuseppe Specchia, Witold Ruzyllo

2.     ACC/AHA guidelines for the management of patients with unstable angina and non–
st-segment elevation myocardial infarction: A report of the american college of cardiology/
american heart association task force on practice guidelines (committee on the management
of patients with unstable angina)
J. Am. Coll. Cardiol., Sep 2000; 36: 970 - 1062.
Eugene Braunwald, Elliott M. Antman, John W. Beasley, Robert M. Califf, Melvin D. Cheitlin,
Judith S. Hochman, Robert H. Jones, Dean Kereiakes, Joel Kupersmith, Thomas N. Levin, Carl J.
Pepine, John W. Schaeffer, Earl E. Smith, III, David E. Steward, Pierre Theroux, Raymond J.
Gibbons, Joseph S. Alpert, Kim A. Eagle, David P. Faxon, Valentin Fuster, Timothy J. Gardner,
Gabriel Gregoratos, Richard O. Russell, and Sidney C. Smith, Jr

3.     Management of acute myocardial infarction in patients presenting with ST-segment
elevantion; The Task Force on the Management of Acute Coronary Syndromes of the
European Society of Cardiology
European Heart Journal (2003) 24, 28–66
Frans Van de Werf, Chair, Diyo Ardissire, Amadeo Betriu, Dennis V. Cokkinos, Erling Falk, Keith
A.A. Fox, Desmand Julian, Maria Lengyel, Franz-Josef Neumann, Witold Ruzyllo, Christian
Thygesen, S. Richard Underwood, Alec Vahanian Freek W.A. Verhengt, Willam Wijns

  Council of Europe Memorandum on the Methodology of Guideline Development: ‗Recommendation Rec(2001)13
adopted by the Committee of Ministers of the Council of Europe on 10 October 2001‘
                                                                                             34 / 130
4.     ACC/AHA guidelines for the management of patients with ST-Elevation myocardial
infarction—executive summary: A report of the American College of Cardiology/American
Heart Association Task Force on practice guidelines (writing committee to revise the 1999
guidelines for the management of patients with acute myocardial infarction)
J. Am. Coll. Cardiol., Aug 2004; 44: 671 - 719.
Writing Committee Members, Elliott M. Antman, Daniel T. Anbe, Paul Wayne Armstrong, Eric R.
Bates, Lee A. Green, Mary Hand, Judith S. Hochman, Harlan M. Krumholz, Frederick G. Kushner,
Gervasio A. Lamas, Charles J. Mullany, Joseph P. Ornato, David L. Pearle, Michael A. Sloan,
Sidney C. Smith, Jr, Task Force Members, Elliott M. Antman, Sidney C. Smith, Jr, Joseph S.
Alpert, Jeffrey L. Anderson, David P. Faxon, Valentin Fuster, Raymond J. Gibbons, Gabriel
Gregoratos, Jonathan L. Halperin, Loren F. Hiratzka, Sharon Ann Hunt, Alice K. Jacobs, and
Joseph P. Ornato

                                                                                   35 / 130

The EHR requirements of the clinical guidelines are described in detail in Table 2.8.1 of Chapter
2.8 in D.8.1.1 "Hospital Pilot Application Requirements" (see page 32). The EHR codes and fields
fulfill the requirements of the flowcharts that have been built for guidelines modeling. These
requirements are being examined by TEPE, and the necessary database structure is being
implemented. In this database, all the appropriate codes from coding schemes like LOINC,
SNOMED, ICD10 will be specified for each relevant field. Patients' data are to be filled in this
specific repository by the doctors, following the coding schemes. These data will be used to create
EHR documents in HL7 CDA level three format, where each section and entry will be annotated
through coding schemes specified in the database. Through these EHR documents, the guideline
agent will be able to access the pieces of patient EHRs which are represented in machine
processable format.

Current normal laboratory values for SCUB (Triage Meter) - could be altered until actual start of
the HPA in 2008:
               cardiac troponin T, cTnI: <0.005 mcg/ml;
               cardiac troponin I, cTnT: <0.01mcg/ml;
               creatinkinase, CK < 130U/L
               creatinkinase-MB, CKMB: <5% of CK or < 25 U/L
               C reactive protein, CRP: 0.5-1.2 mg/dl;
               fibrinogen: 200-400 mg/dl;
               mioglobin, Mb < 5ng/ml;
               creatinine: 0.6-1.2mg/dl.

                                                                                         36 / 130

Clinical Guideline Models to be used in clinical decision processes require specific data to be
retrieved from patient Electronic Health Records (EHRs). EHR Information System is implemented
based on the requirements (demographic and medical data) of SCUB to provide the necessary input
to the guideline execution environment.
Following figures is illustrated how the importance of EHR data in the Clinical Decision Support

            Figure 5.1 EHR Information System in the Clinical Decision Support System

Main functionalities of EHR Information System can be summarized as: Storing different medical
data in related data bases (e.g. demographic, sensors, patient medical history, data related with
medical services, alarms, recommendations, etc.) providing the requested data to the agent during
the guideline execution.
The functionalities in the graphical user interface are provided to the users (SCUB healthcare
professionals) for entering patient related data. The EHR Database stores following information of
patient which is defined in the D.8.1.1 and D.5.2.1. The possible values for these fields are also
defined based on the requirements presented in these deliverables.
         Demographic data
         Clinical data
         Medical Services
                                                                                         37 / 130
            o From the laboratory (Laboratory data)
            o From the echocardiograph (Echocardiography)
            o From different procedures (Non-invasive stress test)
            o From the Catheterism Laboratory (Coronary angiography)
            o From the bedside (Invasive monitoring)
Following Figure 5.2 shows the schema of the EHR DB storing the all related patient medical

There are 22 tables in EHR Information System database as presented in upper. Seven of these
tables are directly related to patient medical record. Patient EHR is composed of the following
tables‘ data.
       Patient History
       Patient Symptom
       Patient Medication
       Patient Lab
       Patient Admission
       Patient ECG
       Patient Allergy
EHR Information System composes of a Relational Database Management System (RDBMS) at the
back side and the Java interface that is provided for easy retrieval and storage of data.
MySQL Database Version 5.0 is used as the RDBMS that is behind the Saphire EHR Information
System. MySQL is preferred because it is an easy to use and fully documented popular open source
database implementation. Another advantage is, there is a tool named phpMyAdmin which is
written in PHP and handles the administration of MySQL over the web.
EHR Information System Applications (GUI) is implemented with Java 1.5.0_10. Application
connects the JBoss Application Server 4.0.5 with EJB 3.0. Open Standards and Open Source JBoss
AS is J2EE 1.4 certified and has a business friendly open source license that makes JBoss AS free
to download, use, embed, and distribute and also it is the most widely used Java application server.
A J2EE certified platform for developing and deploying enterprise Java applications, Web
applications, and Portals, JBoss Application Server provides the full range of J2EE 1.4 features as
well as extended enterprise services including clustering, caching, and persistence. JBoss
Application Server includes support for Enterprise Java Beans (EJB) 3.0 which is designed to
dramatically simplify the enterprise Java programming model.
JBoss Application Server connects MySQL RDMS with Datation Object Relational Mapping
Library. Datation is a registered open source java tools project.

                                                                                            38 / 130
Figure 5.2 EHR DB Schema

                           39 / 130
The user menu of EMR Information System consists of the following parts:

1. New Patient:
The user can register a new patient that comes to monitor cardiovascular patients in the Emergency
Hospital of Bucharest in Romania. New Patient module can be found under the Patient menu.

Patient Registration
Patient Registration facilitates registration of new patients into the EHR Information System and
generates a unique patient identification number. It allows capture of demographic information
(Patient Name, Birth Date, Gender, Marital Status, Hospital File No, and Home Address) as
illustrated Figure 5.3 and admission information as illustrated Figure 5.4. After saving the patient,
the admission tab is activated (Figure 5.4). Starting an administration, patient admission
information like Physician, Diagnosis should be entered (Figure 5.4).

                                  Figure 5.3 Patient Registration

                                                                                           40 / 130
                                  Figure 5.4 Patient Registration

Patient EHR
This functionality in the graphical user interface provided to enter patient medical information as
illustrated in following Figures. The users can define following patient data by EHR Information
System :
      History (Asthma, Angina, Claudation etc. patient history data) is shown in Figure 5.5
      Symptom (Chest Pain, Dyspnea etc.) is shown in Figure 5.6
      Medication (Beta Blocker, Sartan etc.) is shown in Figure 5.6.
      Allergy (Fibrionolysis) is shown Figure 5.6
      ECG (Q waves, LBBB) is shown Figure 5.7.
      Blood (MB, CKMB) is shown Figure 5.8.
Following screens shows the related EHR data in detail regarding to the categorization.

                                                                                          41 / 130
           Figure 5.5 Patient EHR - History

Figure 5.6 Patient EHR – Symptom / Medication / Allergy
                                                          42 / 130
Figure 5.7 Patient EHR – Non-Invasive/Invasive Explorations

            Figure 5.8 Patient EHR – Lab Data
                                                              43 / 130
2. Patient Search:     It provides facility to search registered patient in the EHR Information
   System. Patient Search module can be found under the Patient menu. This functionality is
   acquired to user to see the EHR information of registered patient or to accept the registered
   patient for new admission.
There are two types of search criteria are provided by system to find a patient as illustrated in
following Figure 5.9
      Patient id
      Patient name
Searching result provide the user can reach the entire patient related data (demographic and
medical) as shown Figure 5.10, Figure 5.11 and Figure 5.12

                                    Figure 5.9 Patient Search

                                                                                        44 / 130
  Figure 5.10 Patient Search – Admissions

Figure 5.11 Patient Search – Demographic Info
                                                45 / 130
Figure 5.12 Patient Search – EHR

                                   46 / 130

In this section, a brief summary of the work to create and deploy CDA documents have been
presented. More detailed version of this summary can be found in (Deliverable 4.4.1 Software Tools
to develop and semantically annotate Web Services exposing Medical Information System
functionality). HL7 CDA
In the SAPHIRE architecture, EHR documents of the patients are represented as the HL7 Clinical
Document Architecture (CDA) documents. The HL7 CDA is an XML encoded document, deriving
machine processable semantics from the HL7 RIM.A CDA document is composed of two main
parts: the Header and the Body. The structure can be seen in Figure 5.13. The header identifies and
classifies document providing information on authentication, encounter, patient and providers. The
actual clinical report of the patient is embodied in the body part of the CDA Document .The body
can be either an unstructured blob, or can be comprised of structured markups. The structured form
of CDA body is composed of nestable sections. Each section contains a single narrative block
(optional) and a number of CDA entries. CDA entries typically contain information about the
patient data presented in the narrative block. The data in the entry is encoded through coded terms
in order to provide machine processability.




                                  Figure 5.13 HL7 CDA Structure

                                                                                         47 / 130
CDA provides different levels of semantic support, In SAPHIRE, Level Three CDA documents,
which are semantically most enhanced, are used. More details related to CDA can be found in
The CDA of the patient is extracted from the medical information system (MIS) through a module
which is named as CDA Creator. The CDA creator operates on the databases of the MIS. The
operation that CDA creator module performs is depicted in Figure 5.14.

                           CDA Document

                       <component>                  CDACreator      patienthistory
                        <section>                                  patientsymptom
                          <code code=.. />                                 ..
                          <entry>                                          ..
                           <observation>                             patientecg

                               Figure 5.14 CDA Creation from the Database

The related information in the EHR database in the MIS constitutes the main resource for the CDA
document. The information such as document author, comment texts, titles etc. are provided by the
property files.
Creation of the CDA document is a two-step process (as the CDA document is composed of two
main parts): Header and Body creation.

The header part of the document is mainly constructed using the properties file (display name,
author and custodian info.). The demographics data is retrieved from the database. Date and time
info is inserted on the fly.

Structured Body:
The body of the CDA document is constructed retrieving the patient data from the database. This
data is complemented with the property file elements.
Properties file, includes the code, code system and title information for each section. In the CDA
document, each section under the structured body is covered by a ―component‖ tag. Generally
                                                                                         48 / 130
speaking each component corresponds to a table in the database. The ―entry‖ tags which are
covered under ―section‖ corresponds to the columns in the database table. The code information is
retrieved form the ―code‖ table of the database.
The user interface enables user to configure the sections to be included in the document. After
selecting the sections to be included, user can create the document as an XML file
The CDA creator module is integrated to the EHR Tool. More details related to the module can be
After the document is created, the CDA document has to be stored in the XDS repository.         The
communication between the XDS Server and CDA Creator is realized through the web service
invocation. The related web service is deployed on the XDS server side. The name of the service is
XDSRegistryClientPort: The name of the operation is provideAndRegistryDocumentSet. The web
service is invoked with the following parameters.
      xdsRegistryURL: String
      patientid: String
      name: String
      surname: String
      semanticCategory: String
      documentURL: String
      mimeType:String
      documentid: String
The document has to be deployed on a URL that the XDS server can access. Thus, the created CDA
document is deployed on the local application server (on port 8080) of the client.

                                                                                         49 / 130

The list of data sources (EHR and Sensor Web Services) that are used for retrieving patient related
data in CGM 1 is given below. It should be noted that these reflect the requirements of the
guidelines, the actual Web services will have output structures based in Medical standards. The
related data will be extracted from these standard based parameters through the semantic mediation

Output Name                     Source          Output Type

ECGNewLBBBStatus                Sensor          "true" or "false"

ECGSTElevationStatus            Sensor          "true" or "false"

PatientGeneratedEvent           Sensor          "Angina", "Dyspnea", or "none"

SaO2Status                      Sensor          Numerical

SystolicBP                      Sensor          Numerical

HeartRate                       Sensor          Numerical

ECGPRStatus                     Sensor          Numerical

AspirinMedicationStatus         EHR             "active", "suspended" or "no"

BaselineBP                      EHR             Numerical

AnginaStatus                    EHR             "true" or "false"

NYHAClass                       EHR             Numerical

asthmaStatus                    EHR             Numerical (0= no; 1= yes; 9= not known)

BronchialSpasmStatus            EHR             "true" or "false"

AnxietyStatus                   EHR             "true" or "false"

KillipClass                     EHR             Numerical

ChestPainStatus                 EHR             Numerical

chestPainSymptomsTimestamp EHR                  date (yyMMddHHmmss)

birthDate                       EHR             date (yyMMdd)

FibrinolysisContradictionStatus EHR             "true" or "false"

LVEFStatus                      EHR             numerical

                                                                                          50 / 130
The list of web services of the hospital through which CGM 1 and the hospital communicate is
given below:

WebService Description            WebService Output Name        Output Type
Coronary           Angiography coronaryAngiographyStatus        numerical (0,1,2,3,4)

Store Prescription of the patient -                             The status of the insertion
                                                                (―Successful‖ or ―Failed‖)
Store Procedure for the patient   -                             The status of the insertion
                                                                (―Successful‖ or ―Failed‖)

For CGM 2 the data services relating to the EHR system and Sensor Web Services are listed below:

Output Name                            Source         Output Type

bleedingHistory                        EHR            numerical (0,1,2,3,9)

acuteHeartFailureStatus                EHR            numerical (0= no; 1= yes; 9= not known)

birthDate                              EHR            date (yyMMdd)

asthmaStatus                           EHR            numerical (0= no; 1= yes; 9= not known)

ECGRhythm (avBlockStatus)              EHR            numerical (1,2,3,4,5,6,7,9)

cabgHistory                            EHR            numerical (0,1,2,3,9)

chestPainSymptomsTimestamp             EHR            date (yyMMddHHmmss)

chfStatus                              EHR            "true" or "false"

coronarySpasmStatus                    EHR            0=no; 1=yes; 9=NA

creatinineElevationStatus              EHR            numerical (to be compared with 1.2 mg/dl)

dmStatus                               EHR            "true" or "false"

coronaryAngiographyStatus              EHR            numerical (0,1,2,3,4,9)

dynamicSTChangesStatus                 Sensor         "true" or "false"

hypertensionStatus                     EHR            "true" or "false"

DefaultCRPStatus                       EHR            numerical

inflammatoryMarkerCRPStatus            EHR            numerical     (to   be    compared      with

                                                                                        51 / 130
DefaultFibrinogenStatus              EHR      numerical

inflammatoryMarkerFibrinogenStatus   EHR      numerical     (to   be   compared      with

DefaultIL6Status                     EHR      numerical

inflammatoryMarkerIL6Status          EHR      numerical     (to   be   compared      with

lvefLevel                            EHR      numerical

miHistory                            EHR      0= no, 1= recent (less than one month), 2=
                                              older than one month; 9= not known

miTimestamp                          EHR      date (yyMMddHHmmss)

patientGeneratedEvent                Sensor   enumeration (eg. ―chestPain‖)

recurrentChestPainStatus             Sensor   "true" or "false"

stDepressionStatus                   EHR      "true" or "false"

stDepressionValue                    Sensor   numerical

stElevationValue                     Sensor   numerical

tWavesInversion                      EHR      "true" or "false"

thrombusStatus                       EHR      0=no; 1=yes; 9=NA

transitorySTDeviationStatus          EHR      "true" or "false"

transitorySTElevationStatus          Sensor   "true" or "false"

normalTroponinStatus                 EHR      numerical

troponinElevationStatus              EHR      numerical     (to   be   compared      with

                                                                               52 / 130
WebService Description         WebService Output Name   Output Type
1st     Troponin           I/T firstTroponinElevated    "true" or "false"
Measurement LabOrder
2nd     Troponin           I/T secondTroponinElevated   "true" or "false"
Measurement LabOrder
Cardiac          Troponin cardiacTroponinElevated       "true" or "false"
Measurement LabOrder
CKMB Mass Measurement ckmbMassElevated                  "true" or "false"
Coronary       Angiography coronaryAngiographyStatus    numerical (0,1,2,3,4)

Store Prescription    of   the -                        The status of the
patient                                                 insertion (―Successful‖
                                                        or ―Failed‖)
Store Procedure      for   the -                        The status of the
patient                                                 insertion (―Successful‖
                                                        or ―Failed‖)

                                                                            53 / 130

Exposing Medical Information as Semantically Enriched Web Services aims to provide data stored
in MIS to the Web Service Consumer in a standard service manner.
The MIS Web services can be categorized into two: Synchronous and asynchronous Web services.
The Web services let the Saphire Decision Support System to use the medical information
effectively. The Web Service description syntax (Wsdl) is provided in the Appendix.
Synchronous Web Services as described in following:
   User Web Services: User Web Service provides operations to manage the checking the user‘s
    information is right or not. The following operations are provided
    checkUser (username: String, password: String):Boolean : Checks the user from EHR
    Information System for the specified username and password. This web service will be used by
    all components which will connect to the EHR Information System.
   Patient Web Service: Patient Web service provides operations to manage the Patient
    Information. Through this Web service the Saphire system can search a patient or get the details
    of a patient. The following structure and operations are provided
    quickSearch (patientcode: String): PatientEntity: Searches the EHR Information System for
    the parameters given and returns the PatientEntity.
    advancedSearch (patientcode: String; name: String, diagnosis: string): PatientEntity[] : A
    more advanced version of the quickSearch.
    read (patientID:string): PatientEntity : Searches a patient with primary key, the result is
    always one patient.
   Procedures Web Service: This Web service provides the operation to manage the procedures.
    The following message structures and operation are provided.
    Store (ProcedureEntity): This function save the Procedure Entity data into PatientProcudure
   Medication Web Service: This Web service provides the operation to manage the medications.
    The following message structures and operation are provided.
    Store   (MedicationEntity):     This   function   save     the   Medication   Entity   data    into
    PatientPrescription and PatientPrescriptionNote table.
In addition to these synchronous Web services, asynchronous Web service also provided as follows:
   Order Web Service: This Web service provides the operation to manage the orders. The
    following message structures and operation are provided.
    Order (OrderString:string) : String : This function save the order data into Order table.

                                                                                            54 / 130
In this section, the initial testing of the tools related to the Medical Information System (MIS) for
the Hospital Pilot Application are presented. The efforts for the Alpha Testing of these tools can be
classified into three categories. In the first subsection, alpha testing for the EHR Tool developed by
TEPE is described. Later on, the results of CDA creation, deployment of CDA to the XDS
Repository and the compatibility with guideline execution utility are mentioned. The last subsection
elaborates on the initial testing of medical web services.

The EHR Tool, as mentioned in the related section, was developed by TEPE Teknoloji. After the
initial tests performed in TEPE, the EHR Tool has been deployed and tested on METU side.
First of all, the database connectivity of the tool has been tested. The EHR Tool utilizes Object
Relational Models and EJB in order to perform database connections over JBoss Application
Server. In these tests, the connectivity problems related to JBoss deployment have been discovered
and resolved. Later on, the tool was assessed in terms of validity. In order to be able to extract valid
CDA documents, the tool had to store the necessary information in the underlying database. For
testing the conformity of the real data with the data residing in the database, the data fields have
been compared through the requirement specifications given by SCUB (D8.1.1). The necessary
updates have been notified and reported at this stage.

In the Athens Meeting, the EHR Tool was demonstrated to the to SCUB members in order to get
the necessary feedbacks from the end users. Modifications and updates have been performed in the
light of these feedbacks.

The CDA Creation Tool, which is developed by METU, is integrated into the EHR Tool. Firstly,
testing effort on the CDA Creation tool was the one which is mentioned above. The database was
reviewed, in order to detect any missing fields needed for CDA creation. During database review,
some UMLS codes have been updated to better fulfill the medical concepts. These modifications
have been reflected to the clinical guideline also.

After the CDA Creation Tool has been developed, the output CDA document has been compared
through the previous CDA documents which were created manually. Some differences related to
the date format and allergy sections have been discovered and the CDA Creation Tool has been
adapted to eliminate those differences.

                                                                                              55 / 130
Another testing was on CDA submission to the XDS Server. For testing the submission of a CDA
document, the submission phase has been divided to the atomic operations of XDS Server. These
are creating PID feed for Document Source, creating PID feed for Document Consumer, sending
these PID Feeds and sending the CDA document itself. After each atomic operation has been tested
and verified, the complete procedure has been tested successfully.

The last tests for the created CDAs were on their integrity with the guideline execution. The created
CDAs have been tested with CGM1. Due to the differences with the manually created previous
CDA format, modifications and updates had to be performed. These modifications were done on
the guideline execution side. In order to retain compatibility with the new CDA, two kinds of
updates have been performed. First, the JavaScripts in the guideline definition have been modified.
Some of the scripts, calculations, variable names and their related fields have been updated in GLIF
Model of CGM1 through Protégé. Secondly, for CDA parsing, some of the tables in the database
have been updated due to the altered section names in the new CDA document. After these
modifications have been performed, the guideline execution utility worked smoothly with the
automatically created CDA documents. The CDA document used in these tests can be viewed at:

Medical web services for Hospital Pilot Application have been developed by TEPE; integrated and
tested by METU. Firstly, the web services (two synchronous services and one asynchronous
service), which are Axis services, have been deployed on an Apache Tomcat server.

The testing of the medical services has been performed in two phases. First the deployed web
services have been tested separately using the client stubs. In these tests, the successful deployment
of the web services has been verified, the incompatibilities due to parameter mismatches have been
detected and modifications on invocation parameters have been performed. In the first phase of the
verification, the values have been inspected from the database. In the next phase, it is verified that
the submitted values in the database can be seen from the TEPE Hospital Application Tool without
any problem. For the asynchronous web service, the arrival time of the request to the TEPE
Hospital Application Tool and the return of the response have been observed so that there will not
be a considerable delay while communicating with the asynchronous web service.

Later on, the complete testing of the web services has been performed by invoking them from the
Guideline Agent during guideline execution. In this phase, the integrity of the system has been
tested and faults undetected till that stage have been spotted and fixed.

                                                                                            56 / 130
The validity of web service invocation results has been monitored through the EHR Tool and EHR

WSDL URLs of the tested web services are as follows:

                                                                                     57 / 130

The use of sensor networks to collect the data from various sources offers many benefits such as
mobility, the use of real time data. However, since the data can be in large volumes, it needs to be
managed in order to be more useful. In order to achieve this, the role of the middleware is important
in data collection, querying, filtering, aggregating and storing. In addition, since the processing
capabilities and the storage space are limited in many sensor devices, the work done by the
middleware is increasing.
Tepe will provide the mechanism for defining rules and then filtering the sensor data. These rules
will be decided by the end users (doctors) as they know which kind of sensor data needs to be
stored to the MIS better.
The General Practioner initiate the filtering system by selecting a predefined sensor which schema
information is retrieved from the Saphire Repository since it is a central source of information in
Saphire System. The General Practioner can define the rules and then save the final Configuration
through the Configuration Interface. Based on this, the filtered data is imported to HIS.
―IHE Patient Care Device Technical Framework‖ proposes a filtering mechanism for importing
sensor data to Medical Information Systems, which would be good base on this approach. This
mechanism is integrating the filtering component to the Gateway component, where the flow of
sensor data is filtered and imported to MIS based on the rules. In this case the sensor Web services
are only used for guideline execution.
Also adding to this explanation following diagram, from "IHE Patient Care Device Technical
Framework", explains the integration of the system. This will be implemented on the flow of sensor
data on Gateway. PCDD is a broker which corresponds to the import manager in the Saphire
system. EPCDD Client is a user interface for specifying the parameters for the rules and the
filtering process such as selecting a sensor or defining the maximum and minimum values, intervals
in the rules.

                                                                                            58 / 130
                                                  Figure 5.15

The main entity of storing the sensor data in EHR is the reports. Each report includes a set of sensor
data conforming to the specified rules for the report. These rules, in fact, constitute the regulations
to be executed by Saphire filtering mechanism. According to the Saphire requirements, there are
four types of reports in the Saphire:
      White report – sensors data are in normal ranges;
      Yellow report – assigned to yellow alert;
      Red report – assigned to red alert;
      Event report – assigned to event alert (patient pressed the alert button).
      Artifact report – reports set by medical staff as artifact report. In the most of cases an artifact
       will be stored as yellow/red report by the system and in this situation the medical staff will
       set it as artifact report.
The rules to be used to create these reports can be stated as following.

                                                                                                59 / 130
White report (WR)
Time interval:
        Start: end of last report OR the beginning of monitoring;
        End: start of alert OR 12 P.M. of day
Core – minimal and maximal value for each sensor data in this time interval:
               ECG: maximal and minimal value for heart rate;
               ECG: maximal and minimal value for ST segment deviation, elevation and depression;
                this could also be stored as a baseline resting 12 leads ECG to have a comparison for
                the future alarms.
               Blood pressure: maximal and minimal value for systolic and diastolic blood pressure;
               Pulse oxymeter: maximal and minimal value for respiratory rate RR and arterial
                saturation of oxygen SpO2.
               Measure blood pressure every 30 minutes for day time and every 60 minutes for night
               Measure SpO2 values every 3 seconds.

Yellow report (YR)
Time interval:
        Start: start of yellow alert;
        End: end of yellow alert;
               ECG – record of ECG for 10 seconds;
               Blood pressure – record value every 10 minutes;
               Pulse-oxymeter – record value every one minute;
               Measure blood pressure every 10 minutes;
               Measure SpO2 values every 3 seconds.

Red report (RR)
Time interval:
        Start: start of red alert;
        End: end of red alert;
               ECG –continuous record of ECG;
               Blood pressure – record value every 3 minutes;
                                                                                            60 / 130
                   Pulse-oxymeter – record SpO2 value every 3 seconds;
                   Measure blood pressure every 3 minutes;
                   Measure SpO2 values every 3 seconds.

Event report (ER)
Time interval:
        Start: date+time of push event button;
        End: date+time of start + 5 seconds;
                   ECG – record of ECG for 5 seconds from start of event;
                   Blood pressure – record value at the start of event (one value);
                   Pulse-oxymeter – record value at the start of event (one value);
                   Measure blood pressure at the start of event;
                   Measure SpO2 values at the start event.

Artifact report (AR):
        Time interval:
                     Start: date+time of start artifact;
                     End: date+time of end artifact;
                    ECG – record of ECG for 10 seconds from start of event;
                    Blood pressure: maximal and minimal value for systolic and diastolic blood
                    Pulse oxymeter: maximal and minimal value for respiratory rate RR and arterial
                     saturation of oxygen SpO2

The value of the extensive information about the situation is critical during critical alerts. Therefore,
the categorization of the reports as stated above is very important to provide sufficient complex
information to the physician to make an adequate decision. The clinical alert is obtained through
Saphire Alert system through a service interface. The filtering mechanism changes the rules
according to the alert and creates different reports accordingly.
An overview of the system is depicted in Figure 5.16. The data obtained from the sensors is stored
in the sensor data database. The filtering component provides a GUI (corresponding to the EPCDD
Client of IHE Patient Care Device Technical Framework) to define the parameters to execute the
                                                                                               61 / 130
rules specified above. This GUI also enables to monitor the filtering process. The component
directly connects to the sensor data database to get the data to be filtered and imported to EMR. In
addition, the alarm distribution agent informs the component for the alerts in order to switch
between the reports.

                           Figure 5.16 Overview of the Filtering Process

Some examples of recording in EHR are depicted below. As seen, different kinds of reports are
stored in the EHR in different time periods:

               WR                 WR                RR             WR

         WR       ER            YR             WR      RR          WR

                        WR RR

The list of reports will be stored in each patient's EHR and should be available for medical check-up
and validation. This will be somehow different from the "list of alarms/alerts" stored in the Sensor

                                                                                           62 / 130
Data Visualization Interface from the gateway, where we can store only last 4-6 hours alerts. The
EHR list of sensor data reports should stay there for good, covering the whole 24-48 hours time
interval when the specific patient is monitored during the application.


The Interoperability Platform offers the sensor data for consumption through web services that are
then semantically annotated so they can be used during guideline execution. For this purpose, web
services for blood pressure data, for oxygen saturation data and for ECG data are required. For BP
and SpO2, web services with a custom schema have been designed, and the ECG web service will
simply return an aECG file with raw ECG data and annotations that have been produced by the
Cardionics software.
These web services have been described in deliverable D4.1.1 (―Web Services for exposing Sensor
Data‖) and are being secured with the WS-Security implementation WSS4J that is described in
deliverable D6.3.1 (―Security Mechanisms for Web Services‖).

                                                                                         63 / 130

6.1.1 TRANSMISSION CHANNELS DESIGN [communication medium, transmission
secured methods, user devices, etc.]

The transmission media in SAPHIRE Alarm Component can be discussed in two distinct parts. One
of them is the communication between the system and the Alarm Component, the other is the
communication between Alarm Component and the users. First one can be considered as an internal
communication facility that takes place between two parts of the SAPHIRE. Since the
communicating parties are JADE agents, the medium is ACL messaging which is FIPA compliant.
Communication with the healthcare user is performed through 3 different kinds of media according
to the user preferences (instant messaging, e-mail communication, SMS communication). In the
following sections, the communication channels of SAPHIRE Alarm System are described in detail. COMMUNICATION BETWEEN SYSTEM AND ALARM COMPONENT
As mentioned above, the communication between the system and the alarm component is an
internal type of communication where the both ends of the transmission are JADE agents. The
standard way of communication between JADE agents is ACL Messaging, which is a FIPA
compliant communication facility.
This inner communication can be further classified into two categories
      Guideline Agent- SAPHIRE Alarm Component Communication (For CGM Alarms)
      Interoperability Platform- SAPHIRE Alarm Component Communication(For Sensor
The communication between system and Alarm Component is a one-way communication. Alarm
Component is always in receiver role and does not need to reply to the sender parties.
The content and format of the message is as follows:
          Alarm Message
           o      Patient Info
                     Assignment ID (STRING)
                     Patient ID (STRING)
                     Guideline ID (STRING)
                     Patient Name (STRING)
           o      Message Content
                     Urgency (INTEGER)

                                                                                         64 / 130
                      Role (STRING)
                      Content (STRING)

In the Patient Info part, the properties that are essential for the patient are specified. Patient ID is
the unique patient id in the database, Guideline ID specifies the guideline model whereas
Assignment ID is the id of patient-guideline pair which is maintained in order to handle multiple
assignments of same guideline to a patient.
To define the format of ACL Messages between the parties, a JADE ontology named
AlarmOntology has been created. In the following two subsections the communication
specifications are discussed. GUIDELINE AGENT- SAPHIRE ALARM COMPONENT
This communication channel is established in order to transport the alarms that generated in Clinical
Guideline Models. The aim of these alarms may be to warn the healthcare users about an urgency or
only to notify the user about an accomplished medical task.
Here it is useful to give brief information about the generation of CGM alarms. CGM alarms are
previously defined constructs in the guideline specifications as Message Oriented Actions. When
guideline execution algorithm reaches a Message Oriented Action, the Message Content is extracted
from the OWL instance of the guideline, and the patient info is retrieved within the guideline agent.
After the info is ready, message is packed and sent to the Alarm Component. INTEROPERABILITY PLATFORM – SAPHIRE ALARM COMPONENT
This type of communication has been defined for the alarms coming directly through the sensor
data. Although the message format is same, the sensor alarm messages have some properties
different from CGM Alarm Messages.
Firstly, sensor alarms are not bound to guideline definitions like CGM Alarms. Assignment ID and
Guideline ID sections in Patient Info part does not stand for the same kind of information because
they are not defined as Message Oriented Actions in Guideline specifications
The generation of sensor alarm messages also differs from alarm messages generated within clinical
guideline models. There is a control agent on the sensor side, which continuously checks the Alert
Database for the new Alerts. When a new alert is noticed, control agent adjusts the parameters of
the alarm message and sends it to the Alarm Component, and then the Alarm Component processes
the message. Different from CGM Alarms, both Patient Info and Message Content are depending
on the entry in the Alarm Database.

                                                                                              65 / 130 COMMUNICATION BETWEEN ALARM COMPONENT AND USERS
The communication between SAPHIRE Alarm Component and the SAPHIRE Healthcare users is
the transparent and user oriented part of the communication. The communication with the users is
performed via three different media according to user defined rules.
o      Instant Messaging
o      E-Mail
o      SMS
Each type of communication has acknowledgement mechanisms; therefore communication with the
users can be viewed as a 2-way communication.
In the following subsections, specifications of these transmission channels are presented in detail. INSTANT MESSAGING
Instant messaging offers both free and fast communication over the Internet. It is especially suitable
for the healthcare users who spend their significant amount of time online. Considering the time
saving advantage, instant messaging facility has been included in the SAPHIRE Alarm System as a
delivery medium.
Among many instant messaging providers, GoogleTalk has been selected as the appropriate instant
messaging choice for the SAPHIRE Alarm System. The determinants that made GoogleTalk, the
most appropriate choice are as follows:
      GoogleTalk is one of the most popular IM services. It has been widely used by the people
and it is also available from G-Mail.
      GoogleTalk has a brief and simple user interface appropriate for Hospital use.
      GoogleTalk API is simple, easy to use and it does not cause any conflicts with other
SAPHIRE resources.
      GoogleTalk is completely free.
Smack API [1] ( is used as the GoogleTalk API. Smack is a
general-purpose XMPP (Jabber) client library for instant messaging and presence which is
implemented in Java. Smack API provides a simple interface for SAPHIRE instant messaging
facility. When the Alarm Distribution Agent is created, it simply logs in GoogleTalk with the
username saphirealarmsystem. When SAPHIRE Alarm Component decides to send an instant
message a chat session is generated between user and system and message is sent. The user
saphirealarmsystem remains online as long as the system is on. E-MAIL COMMUNICATION
The e-mail messaging is one of the most important communication channels for the SAPHIRE
Alarm Component. Everyone has an e-mail address for both personal usage and also as a result of a

                                                                                             66 / 130
company policy to stay connected over the Internet. Although Internet connection is needed to
receive e-mail, e-mail sending is almost free and there is no limitation for the amount of data that
can be transmitted by e-mail.
In SAPHIRE Alarm Component, E-Mail communication is considered a reasonable medium for the
users who regularly check their inboxes. An important feature of the SAPHIRE E-Mail facility is
that, it provides security and privacy mechanisms for the users. If a certificate is specified for the
user, the SAPHIRE sends e-mails encrypted with the public key encryption using that certificate,
otherwise the common SMTP is used to send e-mails.
The sender of SAPHIRE e-mail messages is, the subject line of the
e-mails are of the form ―Saphire Alarm Message:‖ + URGENCY + MESSAGEID
The functionality of URGENCY here is to notify the receiving user about the importance of the
alarm. MESSAGID is a automatically generated id that makes the message unique, which is
essential for checking the acknowledges which will be mentioned below
   Non-secure E-Mail:
When users do not specify a certificate file to the Alarm Component, e-mail messages are sent
through SMTP as a MIME message without any security enhancements. First a mail session is
created. Then the message subject is set, the target user is added to the recipients (as a TO
recipient), content is attached and delivery is performed. Standard mail API of Java is utilized in
non-secure e-mail implementation
The e-mail message consists of Patient ID, Guideline ID, Assignment ID, Patient Name, Urgency
and Content.
   Secure E-Mail in SAPHIRE:
The SAPHIRE Alarm System is concerned with the security and privacy issue of the users for the e-
mail communication channel. This is important for both security& privacy of the user and the
confidentiality of medical information In order to achieve this, a certificate based private-public key
mechanism for e-mail communication channel has been implemented. When a user deploys his/her
public key to the system, he/she receives the e-mails encrypted.
The user first creates certificate file (with the .CER extension) using the facilities provided by a
browser, then the certificate is uploaded to the system by the user. From that time, all the e-mails to
be sent to that particular user will be encrypted using that CER file. Enhyrdra Oyster API which is
built upon BouncyCastle[4] Library is utilized in e-mail encryption. The body of the S/MIME
message is encrypted using the CER file of the user. The remaining part does not differ from the
non-secure e-mail implementation.
When the user receives the e-mail, he/ she can read the mail after decrypting it by the private key of
his/her own via the facilities provided by every e-mail client (Outlook, Thunderbird). The public
and private keys can be obtained for free from providers such as Thawte [3].

                                                                                             67 / 130 SMS COMMUNICATION
In the healthcare domain where the urgency situations take place more often, the healthcare actors
are mostly bounded to their mobile phones to keep up with the emergency situations. SMS is one of
the simplest but useful standards for mobile phone communication. SAPHIRE Alarm System
utilizes SMS messaging which is a fast and high delivery percentage communication channel. It has
an affordable cost which can be negligible compared to expenses in e-health industry
SAPHIRE Alarm System can send SMS messages to healthcare users. For SMS sending and
acknowledgement controls, SAPHIRE Alarm System uses a GSM Gateway provided by
SMSExplorer [5] whose URL is SAPHIRE Alarm
System has been registered to the service in order to send SMS from the gateway. The SMS sending
is accomplished by HTTP POST to the gateway URL. The SMS gateway offers a service to prepare
messages in XML formats an example which can be found below.


The action ‗0‘ matches with SMS sending for the gateway; the message body and the contact
number are provided within the related tags. The SMS gateway offers to send messages with the
name of ―SAPHIRE‖ which is stated in the Originator tag. After doing a HTTP POST to the
specified URL, the gateway returns a unique id for the sent SMS message, where this unique id will
be used for the follow-up of the SMS.

                                                                                         68 / 130
This section discusses the user groups that are involved in the Saphire Alarm Component with their
functionalities and interactions with the system in detail. Saphire Alarm Component differentiates
different kinds of users with different kind of functionalities. The user groups that take part in
Saphire Alarm Component are listed below:
      Healthcare Administrators
      Doctors
      Nurses
      Patient Relatives
      Patients

This list is considered to be comprehensive to cover all the requirements of the project but it is
extendible to fulfill the needs that may emerge in the future.
User management is performed through the Saphire Alarm System Web Interface, which provides
user interface facilities through a Tomcat Web Server. The specifications related to user groups that
access to the user interface can be found in the following subsections. HEALTHCARE ADMINISTRATORS
The healthcare administrators can be thought as the super users in the system. The role of the
administrators can be generally thought as management of other users. The functionalities that can
be performed by the administrators are as follows:
      Add/Remove Users: The administrator can add new healthcare users with different rules
       filling the web form. Also administrator can remove existing users through the web interface
      Manage Assignments: The administrator is responsible from assigning the healthcare users
       responsible from the alarm messages of a specific patient. In this functionality; healthcare
       user can assign doctors, nurses and relatives for a patient-guideline pair and also revoke
       their duty through the interface.

                                                                                           69 / 130
                        Figure 6.1 - Healthcare Administrator Screen DOCTORS & NURSES & PATIENT RELATIVES
Although the medical functionalities of a doctor, nurse and patient relative are completely
different in medical procedures, in the scope of Saphire Alarm System user component, the
actions that they can perform are coherent. Therefore, although they are defined as separate
roles; the options they can access through the web interface are identical.
The functionalities in the graphical user interface provided to the users belonging to these
groups are generally related to the efficient delivery of the alarm messages. The users can define
delivery rules, determining the medium of the message delivery, number of times that the
messages is sent repeatedly and whether there is a need for message acknowledgement or not;
also they can assign alternate users, to redirect the messages that cannot be acknowledged.

                                                                                        70 / 130
                         Figure 6.2 - Other Healthcare User Screen

The user menu which can be seen in Figure 6.2 consists of the following parts:
      Edit Contact Info:       The user can specify the email address; instant messaging
       (GoogleTalk) contact and mobile number that he/she wants to get the alarm messages.
      Message Logs: Through this item, user can see the message history related to him/her.
       In addition to this he/she can filter the alarm messages according to date, urgency,
       medium and assignment
      Route User: For the messages that cannot be delivered on time, the healthcare user
       assigns other healthcare users to receive the unacknowledged messages. The assignment
       of the alternative user is performed through this facility
      Edit Alarm Rules: Through this menu, user can specify the way that he/she prefers to
       get the alarm messages for a specific assignment with a defined urgency. The parameters
       that can be set are medium type, acknowledgement need, number of tries, wait duration
       between tries and routing option. The figure 6.3 shows the user interface.

                                                                                     71 / 130
                                Figure 6.3 -Edit Alarm Rules Screen

Other than these specialized functionalities, every user is capable of changing his/her password,
retrieve forgotten password, updating user details(name, surname, email address) and uploading a
public key for receiving secure e-mails. DEVICE(S) ADAPTATION DESIGN
The devices that the alarm receivers use are standard PCs (for e-mail, and instant messaging)
and ordinary cellular phones (for SMS) both of which do not require a special adaptation. ALERTS PRIORITIZATION
This section discusses the prioritization of alarm messages in the hospital pilot application. Since
the correct and punctual delivery of the alarm messages is vital in healthcare domain; there has to
be some measures to ensure reliability of the system. A failure or latency of message deliveries my
cause to disastrous results. In the hospital pilot application, there is a default prioritization
mechanism that pre-defines the delivery mediums in a reasonable way.
According to this default prioritization, the alarms are classified into three in ascending urgency
GREEN, YELLOW, RED. By default, GREEN and YELLOW alarms are sent by e-mail to the

                                                                                            72 / 130
user, however the RED alarms which need more immediate response from the user are sent through
The default values can be overridden through the user component of the alarm system, that have
been mentioned in the previous section.
As mentioned above, the Saphire System has two kinds of alarms, one from generated in Clinical
Guideline Model executions, the other generated by the sensors directly. The urgencies of clinical
guideline alarms are predefined by the healthcare users, in the guideline definition. When the
execution component reaches this task, alarm component is informed about the urgency defined in
the guideline model.
For the sensor alarms, another urgency detection mechanism is applied. In the sensor alarms
database, there exists to separate parameters (indices) about the denoting importance of the alarm.
One of them is Severity Index (SI), which indicates how serious the situation is, the other is
Confidence Index (CI), which indicates how reliable the generated alarm is.
SI can take values 0, 1, 2 which corresponds GREEN, YELLOW and RED alarms respectively,
whereas CI is a floating point number that can be in the range [0.0, 1.0]. 1.0 denotes that sensor
alarm is 100% reliable, 0 denotes the opposite.
The urgency is determined in the following way:
      Assuming that, the alarm‘s CI is maximum (CI=1.0);
                                               Table 1 CI=1.0
                                          SI             URGENCY
                                          0                 GREEN
                                          1                YELLOW
                                          2                  RED

      In the case that CI is not 1.0, the CI is compared with a constant number which is defined as
       0.5 and if CI is less than 0.5, the urgency is set to one level below of the previous case the
       following table describes which conditions yield which urgencies.
                                  Table 2 The case that CI<1.0
                         SI                         CI              URGENCY
                          0                       CI<0.5             GREEN
                          0                       CI>=0.5            GREEN
                          1                       CI<0.5             GREEN
                          1                       CI>=0.5           YELLOW
                          2                       CI<0.5            YELLOW
                          2                       CI>=0.5              RED

                                                                                           73 / 130 DELIVERY CONTROL DESIGN [including alert receiving acknowledge]
In Saphire Alarm Component, it is essential that the system wants to ensure that the responsible
user had really received the alarm message by setting the acknowledgment parameter as TRUE in
the database. When the user receives the message he/she has to perform some action in order to
verify the successful delivery of the alarm message. This action depends on the communication
medium by which the message is sent. The following subsections describe the acknowledgment
mechanisms for each medium type. GOOGLETALK ACKNOWLEDGEMENT
When an alarm conducted via Google Talk needs acknowledgment, the situation is handled as
follows. The chat session mentioned above is not destroyed after the first delivery, and a Chat
Listener attached to the chat session waits for a message from the user the content of which is not
important. If the acknowledgment is received, message sending process is complete, otherwise the
message is re-sent after a certain amount of time according to some rules which can be defined by
the user through the web interface of the Saphire Alarm Component. E-MAIL ACKNOWLEDGEMENT
When an alarm needs an acknowledgement, after sending the mail, the inbox is checked after a
certain (specified by the user) amount of time. A reply to the message with the subject containing
the same MESSAGEID (mentioned above) expected. If this reply is observed, message
acknowledgement is complete. Otherwise the e-mail is re-sent according to the user defined rules. SMS ACKNOWLEDGEMENT
The acknowledgement operation is done with the help of SMS gateway. As there is a unique id for
the sent SMS message, the gateway can be queried for the status of the message. The querying is
done as in the way of SMS sending. After a certain amount of time, an HTTP request is sent to the
gateway and the result is retrieved. If the message is received by the user acknowledgment is
complete, otherwise failure is reported to the system. In SMS Communication, alarm message is not
re-sent to the user.

                                                                                          74 / 130
The definition and description of the alarm thresholds has been detailed in D.8.1.1 "Hospital Pilot
Application Requirements", section 2.4.1, pages 13-22.

Alarm messages should be sent to the doctors via mobile phone (for red alarms) or via e-mail for
yellow alarms. The alarm message should state the following:
      patient ID; as maximum 4 patients will be monitored at the same time, a number from 1 to 4
should be allocated to each patient;
      sensors data for which the alert is generated: cardiac rhythm (HR), blood pressure (BP),
event signaled by patient, aso.
      comparison of the current value with the thresholds or statement about the different alarm,
as defined in D8.1.1.
Based on the definition of thresholds in D.8.1.1, we propose the following types of alarm messages:

        Alert Type         Detection       Alert Threshold         ALARM MESSAGE
       ECG alerts
       Bradycardia         HR (bpm)        <60                     "HR <60"
       Tachycardia         HR (bpm)        >100                    "HR >100"
       HR change           HR (bpm)        HR/5min >15bpm         "HR change"
       Irregular HR        HR (bpm)        -                       "Irregular HR"
       Asystole            HR (bpm)        Isoelectric line        "Asystole"
       SVT                 HR (bpm)        >120                    "SVT"
       JT                  HR (bpm), P >100, no P waves            "JT"
       AFl                 HR (bpm), P Arrhythmia                  "AFl"
                           waves       algorithm
       AF                  HR (bpm), P Arrhythmia                  "AF"
                           waves       algorithm
       VT                  QRS complex, Arrhythmia                 "VT"
                           HR (bpm)     algorithm
       VF                  QRS complex     Arrhythmia              "VF"

                                                                                          75 / 130
SVEs               RR interval, P Arrhythmia     "SVE"
                   waves          algorithm
VEs                RR interval, Arrhythmia       "VE"
                   QRS complex algorithm
Bradycardia        HR (bpm)       < 40           "HR <40"
                                  < 30           "HR <30"
Asystole/Cardiac   HR (bpm)       Arrhythmia     "Asystole"
arrest                            algorithm
ST-segment         ST segment at >1              "ST-segment
deviation          J+80 (mm)                     elevation/depression/deviation"
ST-segment         ST segment at > 1
elevation          J+80 (mm)
ST-segment         ST segment at > 1
depression         J+80 (mm)
BP alerts
Low BP             BP (mmHg)      < 90mmHg       "SBP<90"
                                  < 60mmHg       "SBP<60"
High BP            BP (mmHg)      >160mmHg       "SBP>160"
                                  > 200mmHg      "SBP>200"
Non-detectable     BP (mmHg)      Not detected   "BP ND" = not detectable,
BP                                               unable to measure
Pulse-oximeter alerts
Bradypnea          Respiratory    <12/min        "RR<12"
                   rate (RR)      <8/min         "RR<8"
                   per minute
Tachypnea          Respiratory    >18/min        "RR>18"
                   rate (RR)
                                  >24/min        "RR>24"
                   per minute
Abnormal curve     Respiratory    Algorithm      "R abnormal"
                   curve                         "R" stands for "respiration"
Low SpO2           SpO2 (%)       <94%           "SpO2<94%"
                                  <80%           "SpO2<80%"
―Event‖ alerts
Chest pain         Event mark     Presence       "Event: CP"
                                                 "CP" stands for "chest pain"
Dyspnea            Event mark     Presence       "Event: D"

                                                                       76 / 130
                                                                      "D" stands for "dyspnea"
       Palpitations         Event mark       Presence                 "Event: P"
                                                                      "P" stands for "palpitations"

Apart from the above messages for the sensor data, the sensors will generate malfunction alarm
messages, of the types:
      "lead off"
      "no ECG/BP/SpO2 signal"
      "battery off" or "low battery"
      "artifact"
All the alarm messages should be displayed to the patient's window on the gateway and stored in
the patient's EHR. All alarm messages must be defined according with Chapter 7.1.1 specifications.

Clinical Guidelines Model System will generate alarms to be received as messages and also as input
for execution of some of the guidelines' flowcharts, in a manner previously described in D8.1.1
""Hospital Pilot Application Requirements", section 2.4.1 and D.5.2.1 "Clinical Guideline Models
to be used in Clinical Decision Systems". The CGM thresholds are all defined in the flowcharts
generated from the guidelines (see D.5.2.1), have pre-specified thresholds not to be altered during
the execution of the application and generate messages as alarms that are also defined in the
flowcharts and have been modeled as alarms in the CGM 1 and 2.

The alarm messages coming from the guidelines clinical model will be displayed as defined in the
guidelines flowcharts and will have two functions:
           function of alarm to generate action
           function of clinical decision/ recommendation in the Clinical Decision Support Tool, as
they promote execution of certain steps to generate further actions/ recommendations.
All the messages sent to the doctors by the CGM can also be looked upon as alarm messages. For
example, for the Guidelines 2, we can gat a diagnosis statement as "Acute coronary syndrome",
that will generate execution of risk stratification and treatment flowcharts, but will also be stored as
an alarm message regarding patient's status. The same thing will happen if the message says "High-
risk patient" (see guidelines 2 model), this will be regarded as an alarm message. We will detail
below all the messages in the flowcharts that can be also stored as alarm messages. In contrast to
the sensors alarms, the CGM alarms will generate medical action following recommendation from

                                                                                              77 / 130
the clinical decision Support tool, after medical validation. The validation of these alarm messages
requires storing of all the alarms coming from the CGM in the patient's EHR.

Here is the list of displays/ messages from the 2 guidelines models to be regarded as alarm
            GUIDELINES 1
            Flowchart 1:
            "Fibrinolysis recommended"
            "Invasive rperfusion therapy recommended"

            Flowchart 2:
            no alarm messages

            Flowchart 3:
            "Start Metoprolol IV"
            "Start metoprolol orally"

            Flowchart 6, 7
            will only be displayed, not executed, red alarm messages coming from sensors

            Flowchart 8:
            "Urgent catheterization" will be the only message stored as alarm.

            Flowchart 9:
            "High-risk patient" will be the only message stored as alarm.

            GUIDELINES 2
            see diagrams above, all alarm messages are listed in "!!....!!" format
            Flowchart 1
            "Consider coronary spasm (Prinzmetal)"
            "Start continuous multi-lead ST-segment monitoring"
            "Prinzmetal angina"
            "Non-ST segment elevation ACS"
            "Measure troponin immediately!"
            "Measure CKMB, MB"

                                                                                           78 / 130
            "Repeat troponin"

            Flowchart 2
            "Acute risk of thrombosis"

            Flowchart 3
            "High-risk: consider treatment with LMWH, GP IIB/IIIA Inh.
            Consider invasive strategy"

            Flowchart 4
            There should be no alarm messages form flowchart 4, they will only be regarded as
            from the clinical Decision Support System.

            Flowchart 5
            No alarms, just recommendations.

All alarm messages must be defined according with Chapter 7.1.1 specifications.


After the analyzing of the documents and information received from METU, OFFIS, SCUB –as
HPA end user - stated that the design and logistic for alert system will be finally defined according
with those stipulated in Sections 5.3, 7.1.1, 7.1.2, 7.2.1 and 7.3.1. There are no other conditions
(with related medical standards) for alerts.

                                                                                           79 / 130

The following European standards have been identified for the types of sensors to be used in the
            CEN EN ISO 9919:2005 - Medical electrical equipment — Particular requirements for the
             basic safety and essential performance of pulse oxymeter equipment for medical use (ISO
             9919:2005)EN 865:1997
            CEN EN 1060-1:1995 Non-invasive sphygmomanometers — Part 1: General requirements
             —EN 1060-1:1995/A1:2002 Note 3
            CEN EN 1060-2:1995 Non-invasive sphygmomanometers — Part 2: Supplementary
             requirements for mechanical sphygmomanometers
            CEN EN 1060-3:1997 Non-invasive sphygmomanometers — Part 3: Supplementary
             requirements for electro-mechanical blood pressure measuring systems — EN 1060-
             3:1997/A1:2005 Note 3
            CEN EN 1060-4:2004 Non-invasive sphygmomanometers — Part 4: Test procedures to
             determine the overall system accuracy of automated non-invasive sphygmomanometers —
             CEN EN ISO 13485:2003
            Medical devices — Quality management systems — Requirements for regulatory purposes
             (ISO 13485:2003) EN ISO 13488:2000, EN ISO 13485:2000 31.7.2006
There have been no standards identified for the ECG sensors, so they will be included in electrical
medical equipment.
The COUNCIL DIRECTIVE 93/42/EEC of 14 June 1993 concerning medical devices stated the
following in regard to medical devices, to be applied for the SAPHIRE HPA:
            Article 5
Reference to standards
1. Member States shall presume compliance with the essential requirements referred to in Article 3
in respect of devices which are in conformity with the relevant national standards adopted pursuant
to the harmonized standards the references of which have been publishes in the Official Journal of
the European Communities; Member States shall publish the references of such national standards.
3. If a Member State or the Commission considers that the harmonized standards do not entirely
meet the essential requirements referred to in Article 3, the measures to be taken by the Member
States with regard to these standards and the publication referred to in paragraph 1 of this Article
shall be adopted by the procedure defined in Article 6 (2).

                                                                                           80 / 130
Clinical investigation
1. In the case of devices intended for clinical investigations, the manufacturer, or his authorized
representative established in the Community, shall follow the procedure referred to in Annex VIII
and notify the competent authorities of the Member States in which the investigations are to be
3. In the case of devices other than those referred to in the second paragraph, Member States may
authorize manufacturers to commence clinical investigations, immediately after the date of
notification, provided that the ethics committee concerned has delivered a favourable opinion with
regard to the investigational plan.
4. The authorization referred to in paragraph 2 second sub-paragraph and paragraph 3, may be made
subject to authorization from the competent authority.

1. The devices must be designed and manufactured in such a way that, when used under the
conditions and for the purposes intended, they will not compromise the clinical condition or the
safety of patients, or the safety and health of users or, where applicable, other persons, provided
that any risks which may be associated with their use constitute acceptable risks when weighed
against the benefits to the patient and are compatible with a high level of protection of health and
2. The solutions adopted by the manufacturer for the design and construction of the devices must
conform to safety principles, taking account of the generally acknowledged state of the art. [...]
2.2. for devices intended for the clinical investigations covered by Annex X:
- data allowing identification of the device in question,
- an investigation plan stating in particular the purpose, scientific, technical or medical grounds,
scope and number of devices concerned,
- the opinion of the ethics committee concerned and details of the aspects covered by its opinion,
- the name of the medical practitioner or other authorized person and of the institution responsible
for the investigations,
- the place, starting date and scheduled duration for the investigations,
- a statement that the device in question conforms to the essential requirements apart from the
aspects covered by the investigations and that, with regard to these aspects, every precaution has
been taken to protect the health and safety of the patient.

                                                                                              81 / 130
Ethical considerations
Clinical investigations must be carried out in accordance with the Helsinki Declaration adopted by
the 18th World Medical Assembly in Helsinki, Finland, in 1964, as last amended by the 41st World
Medical Assembly in Hong Kong in 1989. It is mandatory that all measures relating to the
protection of human subjects are carried out in the spirit of the Helsinki Declaration. This includes
every step in the clinical investigation from first consideration of the need and justification of the
study to publication of the results.
2.3. Methods
2.3.1. Clinical investigations must be performed on the basis of an appropriate plan of investigation
reflecting the latest scientific and technical knowledge and defined in such a way as to confirm or
refute the manufacturer's claims for the device; these investigations must include an adequate
number of observations to guarantee the scientific validity of the conclusions.
2.3.2. The procedures used to perform the investigations must be appropriate to the device under
2.3.3. Clinical investigations must be performed in circumstances similar to the normal conditions
of use of the device.
2.3.4. All the appropriate features, including those involving the safety and performances of the
device, and its effect on patients must be examined.
2.3.5. All adverse incidents such as those specified in Article 10 must be fully recorded and notified
to the competent authority.
2.3.6. The investigations must be performed under the responsibility of a medical practitioner or
another authorized qualified person in an appropriate environment.
The medical practitioner or other authorized person must have access to the technical and
clinical data regarding the device.
2.3.7. The written report, signed by the medical practitioner or other authorized person responsible,
must contain a critical evaluation of all the data collected during the clinical investigation.
All medical devices sold in the EU must have the CE Marking affixed to demonstrate compliance to
the Medical Directives. It is essential for companies to have access to the harmonized European
Standards that provide the presumption of conformity with the obligatory essential requirements of
the EU Directives.
CYBER stated in PCM Athens presentation the Bluetooth modules are CE marked (Bluegiga
WT11, Class 1, Bluetooth 2.0 Protocol). Also, all measurement modules are CE marked (and all
from Germany): ECG (Corscience for 12 lead OEM Board; Merit cable : color coded with 15 Pin D
sub connector), pulse oximeter (Chipox module from MCC), blood pressure module (NIBP 2010
Module from MCC).

                                                                                                  82 / 130
      o PCs AND PERIPHERALS [including PDAs, mobiles, communication devices,
          bluetooth devices, etc.]
  There are no medical specifications for this devices.


  The system core is an MSP430F169 from Texas Instruments. The low power microcontroller
  manages all signal processing, display and communication. There is also a real time clock for data
  time stamping and synchronisation.
  All sensors are equipped with a Bluetooth radio with the following characteristics:

                                       Bluetooth Features
                                       Compliance:        Version 2.0 compliant
                                       Classification:    Class 1 (up to 100 meter range)
                                       Profile:           Serial Port Profile (SPP)
                                       Operation:         Slave Point-to-Point
                                       Antenna Type:      Internal

  - Event button: On the pulse oximeter and the ECG sensor, there is a large orange event push button
  that patients can push to indicate the way they feel (one time for palpitations, two for …, etc.).

Bluetooth radio                                                                                   SD Card

                                                                                          LCD display

  Oximeter                                                                                       Navigation

                                                                                                83 / 130
- Batteries:
The pulse oximeter and ECG sensors are powered by 3.7 V lithium ion batteries. Recharging can
take place either using a USB port on a computer or via a 5V jack that can be connected.
A USB hub can be connected to the gateway and serve as a recharging hub for the sensor batteries.

The blood pressure monitor contains a 9V NiMH battery as it needs to be able to get fairly high
current for the cuff inflation pump.
- LCD display: Information common to all sensors such as battery indicator, date and time, etc. will
be displayed on a 128 x 64 pixels LCD display.
- User menus: There are two kinds of menus:
    - Simplified menu: This is for the case when the sensor is used by one person for a relatively
    long time; the options for this case are just to start the recording, stop the recording.
    - Advanced menu: This menu is reserved for medical personnel or for initial sensor
- A navigation switch on the side of the units allows the selection of the various functions, start,
stop, menu selection or character input (for example to create a new patient file on the SD card).
- Bidirectional communication: The sensors can be sent ASCII commands to start and stop from the
- SD memory card:
Every sensor has an SD card which allows two functions:
    -   Data storage in case communication with the gateway is lost; for non critical situations, to
        save battery power, it is conceivable to write the data to the Flash memory and relay the
        information wirelessly via bursts (every 10 to 30 seconds for example) instead of on a
        continuous basis.
    -   Patient information retrieval for data tagging when transmission starts.
Patient selection on the SD Card: A list of patients name and relevant information can be stored on
the SD card as .txt file. This list can easily be created using a spreadsheet program such as
Microsoft Excel.
When starting a measurement, medical personnel can select the right patient from the list and the
identity of the patient will be added at the beginning of the transmission to the gateway.

                                                                                                84 / 130 PULSE OXIMETER
The pulse oximeter can be fitted with 3 types of sensors depending on healthcare professional
   -   finger sensor
   -   ear sensor
   -   wrap sensor (also on finger but less bulky than standard finger sensor).

                        Technical performance
                        O2 saturation range (% SpO2)     0-100 %

                        Pulse rate range                 0-300 bpm

                        Effective Blood O2 saturation    45 – 100 %
                        Effective Heart rate pulse       20-300 bpm

                        Accuracy Blood O2 saturation 70-100 % +/- 2 digits
                        Accuracy Pulse rate              +/- 2 %
                        Operating T°                     -20°C - 60°C
                        Storage and transport            -30°C - 70°C

                        Recording Resolution:            12 bit
                        Adjustable analog sampling       75-300 Hz BLOOD PRESSURE MONITOR
The specifications are the following:

   Technical performance
   Type of measurement                                        Oscillometric
   Real time clock                                            Date and time stamp
   Max. operating current:                                    750 mA (5V)
   Pressure range                                             0 to 300 mm
   Measurement ranges for adults:                             - pSYS : 25 - 280 mmHg
                                                              - pDIA : 10 - 220 mmHg
                                                              - pMAP: 15 - 260 mmHg

                                                                                       85 / 130
    Measurement ranges for neonates:                            - pSYS : 20 - 150 mmHg
                                                                - pDIA : 5 - 110 mmHg
                                                                - pMAP: 10 - 130 mmHg
    Leakage rate of the system                                  < 3 mmHg / minute
    Overpressure limits                                         300 mmHg adult
                                                                150 mmHg neonatal mode
    Shutdown and pressure release after exceeding (first 330 mmHg adult ;                 165      mmHg
    fault condition):                                    neonatal mode
    Time required for BD measurement:                           typical (normal) 25s
                                                                max.: adults 90s,
                                                                max.: neonates 60s TWELVE LEAD ECG
Initial tests were carried out with the Bluetooth enabled ECG from Corscience. The unit comes with
the HES software for data analysis on a PC.
The following issues were identified:
-         Display: No information appears on the LCD screen until a Bluetooth connection is
established; users therefore can not check correct electrode positioning if they are not in the vicinity
of an access point or gateway.
-         Pairing: Once it is paired to a Device, one needs to press the On button for 20 seconds to
unpair it; precludes Bluetooth roaming in the future
-         No time stamping of the data.
To overcome these limitations, a decision was made to use the OEM ECG board sold by Corscience
and add our own microcontroller, LCD and Bluetooth radio. This module has been available only
since October 16th and provides the following:

                                          Technical performance
                                          Common mode rejection > 94 dB
                                          Current consumption      < 200 mA
                                          Resolution               < 2.6 µV/Bit
                                                                   ECG 18 Bit
                                          Bandwidth                0 to 150 Hz

Medical personnel will also have the possibility of only connecting some of the 12 leads instead of
all 12.

                                                                                                86 / 130 RESPIRATION RATE
This sensor has not been fully defined yet because there are several methods possible. They are
presented here by order of increasing difficulty of implementation:

A - Chest belt:
We     propose       the   use         of     the      stretch   sensor   made    by    Merlin    Systems;
The resistance increases proportionally to the sensor displacement.
This sensor would be self contained and would have its own data format.

B - ECG derived respiration:
We would use the algorithm as detailed in the following article:
The interesting part is that the C algorithm is available and more importantly precompiled libraries
for Linux.

C- Oximeter based respiration measurement:
Two approaches:
Deriving it from the photoplethysmogram provided by the oximeter:
Apply wavelet transformation to the signal, similar to the work done by Cardiodigital, ('A Fully
Automated         Algorithm      for        the     Determination    of   Respiratory   Rate     from        the
Photoplethysmogram', P.A. Leonard, J.G. Douglas, N.R. Grubb, D.Clifton, P.S. Addison, J.N.
Watson, Journal Of Clinical Monitoring and Computing, 2006, Vol.20, 33-36.) but their algorithm
is patented and this requires signal processing at the gateway level.

SCUB, CYBER and OFFIS stated that there is no need for Repiratory rate sensor for HPA
application (the needed respiratory rate data can be derived from either ECG or pulse oximeter).

                                                                                                  87 / 130 SENSORS SIMULATOR
CYBER has proposed the PS410 ECG Simulator (Fluke Biomedical) to be used for sensors
simulation in HospitalPA; PS410 ECG Simulator is a compact, lightweight, high-performance
simulator for use by trained service technicians for patient monitor testing. The Simulator replicates
various electrocardiogram conditions based on settings you select.
Within the below table there are some general features for simulator:

Environmental                                       Indoor use
Temperature, Operating                              15 to 35 °C
Temperature, Storage                                0 to 50 °C
Maximum Humidity, Operating                         80 % relative humidity up to 31 °C (88 °F),
                                                    decreasing linearly to 50 % relative humidity at
                                                    40 °C
Display                                             15 x 30 mm (0.58 x 1.15 in.) window displaying
                                                    up to two lines of text
Interface                                           RS232 bi-directional interface. Baud rate: 9600.
ECG Output Connectors                               10 AHA/IEC color-coded connectors accepting
                                                    ECG snaps and pins
Menu Selection                                      Lists all code line values that you can execute in
                                                    the Simulator.
12 Leads with Independent Outputs Referenced
to RL
Output Impedance                                    940 ohms between leads
High Level Output                                   1000x Lead II
Rates                                               30, 40, 60, 80, 100, 120, 140, 160, 180, 200,
                                                    220, 240, 260, 280, and 300 BPM
Default Rate                                        80 BPM
Rate Accuracy                                       ± 1 % of selection
Adult or Pediatric Waveforms
ECG Amplitudes                                      0.5, 1.0, 1.5, and 2.0 mV
Amplitude Accuracy                                  ± 2 % (Lead II).
Superimposed Artifact                               50 and 60 Hz, muscle, baseline wander, and
ECG Performance, Lead II
                                                                                             88 / 130
Square Wave                                 0.125 and 2.0 Hz
Pulse                                       30, 60, and 120 BPM; 60 ms pulse width
Sine Waves                                  0.5, 5, 10, 40, 50, and 60 Hz (1 mV amplitude)
Triangle Wave                               2.0 Hz
ST Segment Analysis

Elevated or Depressed                       - 0.2 mV to + 0.6 mV in 0.2 mV steps
Pacemaker Selections

Pacemaker Rhythm                            Demand Occasional Sinus

Pacemaker Non-Function                      Demand Frequent Sinus

Pacemaker Non-Capture                       A-V Sequential

Arrhythmia Selections
PVC1 Left Ventricular    PVC2 Early, RV     Ventricular Fibrillation Atrial Fibrillation
Focus                    Focus              Coarse/Fine               Coarse/Fine
PVC1 Early, LV Focus PVC2 R on T, RV        Supraventricular          Atrial Tachycardia
                         Focus              Tachycardia
PVC1 R on T, LV          Bigeminy           Premature Atrial          Conduction Defects
Focus                                       Contraction
Pair PVCs                Trigeminy          Premature Nodal           First Degree
Run 5 PVCs               PVCs 6 / minute    Asystole                  Second Degree
Run 11 PVCs              PVCs 12 / minute   Missed Beat               Third Degree
Multifocal PVCs          PVCs 24 / minute   Nodal Rhythm              Right Bundle Branch
Frequent Multifocal      Ventricular        Irregular Rhythm          Left Bundle Branch
PVCs                     Tachycardia                                  Block
PVC2 Right                                  Atrial Flutter
Ventricular Focus

                                                                                     89 / 130
Figure 9.1 (below) describes the simulator controls and terminals.

                              Figure 9.1: Simulator controls and terminals

These main simulating procedures are the following (described by function):
- ECG / Arrhythmia: the Simulator replicates several different types of arrhythmias, from
inconsequential types of PNCs to asystole. In addition, the Simulator can send waveforms to test
any electrocardiograph, and can accommodate twelve-lead configurations with independent outputs
for each signal lead referenced to the right leg (RL).
      ECG Waveform: the Simulator replicates three ECG waveform amplitudes, with a ± 2 %
       accuracy of selection (Lead II). The Simulator uses these as references only during
       arrhythmia simulations;
      NSR: the Simulator replicates fifteen normal sinus rhythms (NSRs);
      Adult and Pediatric NSR QRS: You can set an adult NSR with a QRS width of 80 ms or a
       pediatric NSR with a QRS width of 40 ms;
      Arrhythmias: Premature Beats;
      Arrhythmias: Ventricular;
      Arrhythmias: Atrial;
      Arrhythmias: Conduction Defects;
      ST Elevation and Depression Waves;

                                                                                       90 / 130
      Superimposed Artifacts: the Simulator replicates five different artifacts. Their purpose is to
       evaluate the effect of these artifacts on ECG accuracy;
      Pacemaker;
The Simulator replicates six paced rhythms/signals.

- ECG Performance Testing
      Square Wave;
      Triangle Wave;
      Pulse Wave;
      Sine Wave: the Simulator fixes amplitude at 1.0 mV for sine waves;

The product is CE marked: manufacturer‘s declaration of product compliance with applicable EU
directives / standards.

                                                                                           91 / 130

No.   Name         Quantity                            Functionality    Remarks
                                                                         optionally, a PCI-
 1.   Dell           1pc.     CPU: Intel       Xeon Server:
                                                                          express VGA card
      PowerEdge               3.2GHz
                                                        Interoperabi     can be installed for
      1800 SCSI,
                              MB: Chipset      Intel   lity Platform      increased
                                                                          performance; in
      3.2GHz,                 E7520                     Medical
                                                                          such case a silent
      2GB                                              analyses
                              VGA: ATI Radeon                             one is strongly
                              7000-M    16MB                              recommended
                              SDRAM                    packages /        the optical and
                                                       Cardionics         floppy drives
                              MEM: 2x1GB (Max                             are only
                              12GB)                     Medical
                                                                          necessary for
                                                                          the initial setup
                              HDD: 3x73GB 10K
                                                        EMR              and the
                                  U320 Hot Plug
                                                       component          following
                                  SCSI        +
                                  2x320GB               Back-up
                                                                          work and
                                                                          should be
                              OPT: DVDRW DL                               disabled for
                                                                          day-to-day use
                              FDD: 3.5" 1.44MB                           all the
                              LAN: Intel Gigabit                          listed are subject to
                              82541 Server Adapter                        changes upon
                                                                          acquisition, after
                              KB&MOUSE: DELL
                                                                          having seen the
                              LCD:    SAMSUNG                             offers form the
                              SyncMaster 931BF or                         market. However,
                              better                                      the main features
                                                                          are the ones
                              UPS: APC 1500VA                             presented and only
                              or better                                   minor changes are

                                                                                      92 / 130
                                                             optionally, a low-
2.   Dell       2pcs.   CPU: Intel PentiumD Gateway:
                                                              profile PCI-express
     OptiPlex           945 3.4GHz
                                             Bluetooth       VGA card can be
     Pentium            MB: Chipset Intel gateway for         installed for
                        945                 the available     increased
                                            sensors           performance; in
                        MEM: 2x1GB DDR2  Real-time           such case a silent
                        (Max. 4GB)          Sensor Data       one is strongly
                                            Visualization     recommended
                        HDD:          250GB Interface        the optical and
                        SATAII or better                      floppy drives are
                                             Filtering
                                                              only necessary for
                        OPT: DVDRW DL       component
                                                              the initial setup and
                        VGA: Intel Graphics                   the following
                        Media   Accelerator                   maintenance work
                        950                                   and should be
                                                              disabled for day-to-
                        FDD: 3.5" 1.44MB                      day use
                                                             all the
                        LAN:           Gigabit                specifications
                        Ethernet                              listed are subject to
                                                              changes upon
                        KB&MOUSE: DELL
                                                              acquisition, after
                        LCD:    SAMSUNG                       having seen the
                        SyncMaster 931BF or                   offers form the
                        better                                market. However,
                                                              the main features
                        UPS: APC 900VA or                     are the ones
                        better                                presented and only
                                                              minor changes are
                        Bluetooth         USB                 expected
                        Dongle       to     be
                        modified by Cyber
                        for             greater
                        connectivity coverage

                                                                          93 / 130
                                                                               optionally, a low-
 3.    Dell              2pcs.    CPU: Intel PentiumD Workstation:
                                                                                profile PCI-express
       OptiPlex                   945 3.4GHz
                                                       Intelligent             VGA card can be
       Pentium                    MB: Chipset Intel Clinical                    installed for
                                  945                 Decision                  increased
       3.4GHz,                    MEM: 2x1GB DDR2 Support                       performance; in
                                  (Max. 4GB)          Interface                 such case a silent
                                                            (Agent              one is strongly
                                  HDD:          250GB       Assignment          recommended
                                  SATAII or better          GUI + Agent        the optical and
                                                            Factory,            floppy drives are
                                  OPT: DVDRW DL             CGMs, Alarm         only necessary for
                                                            component,          the initial setup and
                                  VGA: Intel Graphics
                                                            Interface for       the following
                                  Media   Accelerator
                                                            General             maintenance work
                                                            Practitioners)      and should be
                                  FDD: 3.5" 1.44MB                              disabled for day-to-
                                                                                day use
                                  LAN:           Gigabit                       all the
                                  Ethernet                                      specifications
                                                                                listed are subject to
                                  KB&MOUSE: DELL                                changes upon
                                                                                acquisition, after
                                  LCD:    SAMSUNG
                                                                                having seen the
                                  SyncMaster 931BF or
                                                                                offers form the
                                                                                market. However,
                                  UPS: APC 900VA or                             the main features
                                  better                                        are the ones
                                                                                presented and only
                                                                                minor changes are


Isolation and security of the area pre-specified for developing of the HPA will start soon. Materials
necessary for this action will be acquired from SAPHIRE funds and listed when they will be
available. They will include isolation walls, secure door with coded locker, internet cables,
transmission cables, phones, aso. Complete list of materials and equipments will be available in the
following D8.3.1 deliverable – ―Development of the Hospital Pilot Application Scenarios‖.

                                                                                            94 / 130

The following Saphire software components (see table below) will be developed and integrated
within Hospital PA.
In this respect, various development and system software packages will be necessary to be used in
Hospital PA configuration: operation systems, software packages for development of Saphire
components, modeling the clinical guidelines (flowcharts), software applications running, data
bases developing and maintenance, etc.

                                                                                        95 / 130
Crt.   Component          Coordinator   / Deadline      for Development         Code     / Provider              License       Remarks
no.    Name               developer       achievement       and         system version
                                          (according with software
                                          project           packages

1      Interoperability   OFFIS                             1 Linux             Kernel     Open Source           GPL           OS
       platform                                                                 2.6.x

                                                            2   Knopflerfish 2.0           Open Source           BSD

                                                            3 MySQL             5.X        MySQL AB              Dual License Database

                                                            4         Apache 5.5.x         Apache        Software Apache
                                                            Tomcat        Web              Foundation            License 2.0

                                                            5 Apache Axis       1.4        Apache        Software Apache       SOAP Engine
                                                                                           Foundation            License 2.0

                                                            6 Eclipse           3.2        Eclipse Foundation    Eclipse
                                                                                                                 (EPL) 1.0
2       Clinical decisions support system

2.A     HPA          Agent METU+IPA         1 JADE          3.3      TILAB                LGPL            Agent Platform
                                            2        Apache 5.0.28   Apache       Software Apache         Web Server
                                            Tomcat                   Foundation           License

                                            3 MySQL         5.0      AB                   GPL             DBMS

                                            4 Hibernate     3.2      JBoss Labs           LGPL            object/relational
                                                                                                          persistence         and
                                                                                                          query service

2.A.1   GUI    for    data IPA                                                            Eclipse
        introducing and                                                                   Public
        validation                                                                        License
                                                                                          Version 1.0
                                            1. Eclipse      3.2.1      ("EPL")


                                                                                                                   97 / 130
                                   2. Zend Studio     5.2.0

2.A.2   Agent factory   METU       1 JADE             3.3         TILAB                 LGPL            Agent Platform

                                   2        Apache 5.0.28         Apache       Software Apache          Web Server
                                   Tomcat                         Foundation            License

                                   3 MySQL            5.0         AB                    GPL             DBMS

                                   4 Hibernate        3.2         JBoss Labs            LGPL            object/relational
                                                                                                        persistence         and
                                                                                                        query service

2.B     Clinical        METU+IPA   1 Protege          3.1         Stanford University   Open Source     Ontology Editor
                                                      V3.4    +
        Models                     2.          GLIF
                                                      METU        METU                  Open-source

                                   3.   Flowcharts 5.06       Trial License
                                   Modelling Tool
                                   - WizFlow

                                                                                                                 98 / 130
                               2 Jena            2.2          HP   Labs Semantic Open Source     a Java framework
                                                              Web Research                       for         building
                                                                                                 Semantic         Web

                               3    freebXML 3.0 Beta 1       freebxml     Software The          OASIS       ebXML
                               Registry                       Foundation           freebxml      Registry
                                                                                   License,      Reference
                                                                                   Open Source   Implementation
                                                                                                 and   the      JAXR

                               4 Axis            1.4          Apache       Software Apache       SOAP
                                                              Foundation           License       Implementation

                               4.       Microsoft XP    Commercial-
                               Windows           Profession                        license

2.C   Alarm       METU+OFFIS   1 MySQL           5.0          AB                   GPL           DBMS
                               2 Smack           2.2.1        Jive Soft            Apache        XMPP              API
                                                                                   License       (GoogleTalk)

                               3 Oyster          2.1.6        Enhydra              LGPL          S/Mime Library

                               4 JADE            3.3          TILAB                LGPL          Agent Platform

                                                                                                            99 / 130
2.D   Support           METU   1 JADE            3.3       TILAB                          LGPL       Agent Platform
      interface   for
                               2 Prefuse         Beta      Berkeley Institute of                     Visualization
                                                           Design                                    toolkit

                               3 CASTOR   Started and originally Apache             Open Source data
                                                           developed      by      Keith License,     binding framework
                                                           Visco and Assaf Arkin Version 2.0         for Java between
                                                           of       Intalio,       Inc.              Java objects, XML
                                                           Complete        list     of               documents             and
                                                           contributors is available                 relational tables
                                                           on its web page.

                               4 Jena            2.2       HP Labs Semantic Web Open Source          a Java framework
                                                           Research                                  for          building
                                                                                                     Semantic          Web

                               5 Xerces          2.7.0     Apache          Software Apache           XML parser
                                                           Foundation                     Software

                               6        Catalina 5.0.28    Apache          Software Apache           Embedded
                               Tomcat                      Foundation                     Software   Tomcat

                                                                                                               100 / 130
3   Sensors         data CYBER + TEPE      1 Linux             Mandrake   MandrakeSoft          Open Source    Operating system
    Real        Time (for      filtering                       8.1
    visualization       component)
                                           2          Apache Tomcat       Apache       Software Open Source    J2EE server
                                           Tomcat              5.x        Foundation

                                           3 Active MQ         Active          Open Source    Message bus
                                                               MQ 4.0.2

                                           4         MySQL V5.0           MySQL AB              Open Source    DB system

                                           5 Apache Axis       1.4        Apache       Software Apache         SOAP Engine
                                                                          Foundation            License 2.0

                                           6           JBoss 4.0.5        Red Hat Middleware    LGPL           Application
                                           Application                                                         Server

                                           7        Enterprise 3.0        Sun Microsystems      Java      EE
                                           Java Beans                                           License

                                           8 JBoss             V4.0       Jboss Labs            Open Source

                                           9 Axis2             1          Apache     Software Open Source

                                                                                                                        101 / 130
                                 10 Eclipse       V3.2    Eclipse Organization      Open Source

4   EMR component TEPE+METU      1 JADE           3.3     TILAB                     LGPL          Agent Platform

                                 2 Care2X-HIS     2.1     Care2X Development GPL                  Open         Source
                                                          Team.    Consists    of                 Hospital
                                                          more      than      100                 Information
                                                          members                                 System     together
                                                                                                  with EHR support

5   Medical      web TEPE+METU   1 Axis           1.3     Apache       Software Apache            SOAP
    services    (data                                     Foundation                License       Implementation
                                 2 Axis2          2.0     Apache       Software Apache            SOAP
                                                          Foundation                License       Implementation

                                 3         MySQL 3.0.9o   AB                        GPL           DBMS Driver

6   Medical analysis CYBER       1 C language             Cardionics                Proprietary   Real time cardiac
    interpretation                                                                                event software

                                                                                                           102 / 130
    packages                 2 TBD                Cardiodigital   Proprietary   Respiration         rate

7   Security     and CYBER   1 OpenSSL     TBD                    Open Source
                             WS Security   V1.1   Oasis           Open Source   Web        Services

                                                                                        103 / 130

This section will present the SAPHIRE approach to general procedure and assessment criteria for
testing tuning and validation of the HPA pilot application.
In this section, ALTEC has provided a general framework that combines two ISO standards in order
to effectively select the appropriate validation procedure and quality requirements along with their
associated metrics for the system‘s measurement.
These two ISO standards are the ISO 14598:1 and ISO 9126: 3-4, while the first provides a
framework and guidelines to the Validation process model, the latter provides the quality
characteristics and the metrics upon which the actual validation of the produced software should
The elaboration and reinforcement of evaluation conditions and specific criteria (taking into account
also, the Use Cases definition / design from deliverables D.3.2.1/"Requirement Specification of the
SAPHIRE System" and D.3.3.1/"Conceptual design of Saphire Architecture") in order to test the
Hospital Pilot Application prototypes (tasks 3.5 and 3.6) will be developed / provided in the
deliverable D.3.7.1 – ―Delivery of the Assessment Criteria for Software Validation‖. The completion
of the testing strategy, including test scenarios for HPA platform, will be made in deliverable D.9.1.1
– ―Delivery of the Test Environment and the Assessment Criteria Definition‖.

The process as adopted from the ISO 14598 standard involves the use of quality characteristics. The
model orders four stages:
1. Establish validation requirements
2. Specify the validation
3. Design the validation
4. Execute validation

                                                                                            104 / 130
In this step we identify the focus and purpose of validation. This is achieved, with the help of the
quality model specification, where one needs to set quality goals for the system under study.

As shown from the figure above, there are three classes of validation requirements and their
associated metrics recognized in the ISO standards: internal metrics, external metrics and quality in
use metrics.
   1. The internal metrics may be applied to a non-executable software product during its
       development stages (such as request for proposal, requirements definition, design
       specification or source code). Internal metrics provide the users with the ability to measure
       the quality of the intermediate deliverables and thereby predict the quality of the final
       product. This allows the user to identify quality issues and initiate corrective action as early
       as possible in the development life cycle.
   2. The external metrics may be used to measure the quality of the software product by
       measuring the behavior of the system of which it is a part. The external metrics can only be
       used during the testing stages of the life cycle process and during any operational stages. The
       measurement is performed when executing the software product in the system environment
       in which it is intended to operate.
   3. The quality in use metrics measure whether a product meets the needs of specified users to
       achieve specified goals with effectiveness, productivity, safety and satisfaction in a specified
       context of use. This can be only achieved in a realistic system environment.

                                                                                            105 / 130 VALIDATION SCOPE
ISO 14598 gives us insights on when to apply what, as the categories of metrics are appropriate for
different phases of the systems development life cycle.
The tables below depicts an example model that links the Software Development life cycle process
activities (activity 1 to activity 8) to their key deliverables and the relevant reference models for
measuring quality of the deliverables (i.e., Quality in Use, External Quality, or Internal Quality).
Row 1 describes the software development life cycle process activities. (This may be customized to
suit individual needs). Row 2 describes whether an actual measure or a prediction is possible for the
category of measures (i.e., Quality in Use, External Quality, or Internal Quality). Row 3 describes
the key deliverable that may be measured for Quality and Row 4 describes the metrics that may be
applied on each deliverable at each process activity.

              Activity 1   Activity 2    Activity 3   Activity 4     Activity 5   Activity 6   Activity 7    Activity 8
   Phase     Requirement Architectural Software        Software   Software       System      Software  Software
               analysis      design     detailed      coding and integration integration installation acceptance
              (Software                  design         testing and software and system                 support
                          (Software and
             and systems)                                        qualification qualification
                                                                   testing       testing
9126 series Required user Predicted      Predicted      Predicted    Predicted    Predicted    Predicted     Measured
   model      quality, quality in use,   quality in     quality in   quality in   quality in   quality in    quality in
 reference                Predicted         use,           use,         use,         use,         use,          use,
                          external       Predicted      Measured     Measured     Measured     Measured      Measured
                           quality,       external       external     external     external     external      external
                          Measured        quality,       quality,     quality,     quality,     quality,      quality,
                           internal      Measured       Predicted    Predicted    Measured     Measured      Measured
                            quality       internal       external     external     internal     internal      internal
                                           quality       quality,     quality,      quality      quality       quality
                                                        Measured     Measured
                                                         internal     internal
                                                          quality      quality

                                                                                                 106 / 130
    Key      User quality Architecture Software Software Software Integrated Installed Delivered
deliverables requirements design of detailed code, product, system, system software
 of activity (specified), Software / design       Test     Test      Test               product
                            system               results results results
  Metrics        Internal       Internal   Internal Internal Internal Internal Internal Quality in
  used to         metrics       metrics    metrics metrics metrics metrics metrics        use
  measure       (External                                                                metrics
                                                    External External External External
               metrics may                           metrics    metrics   metrics   metrics Internal
               be applied to                                                                metrics
              specifications)                                                                 External

Clearly the scope of our validation is around Activities 6-7 and 8, as we validate the pilot application
and not the software itself, as an isolated asset. We focus on the SAPHIRE certain and his
environment conditions and against defined requirements that our system has to fulfill throughout
specific scenarios.

The validation specification step is comprised of two stages:
1. Quality metrics selection
Having identified that the focus of our validation will be around Activities 6-8 and that the purpose
is to provide proof evidence regarding the fulfillment of certain functional requirements imposed by
HPA pilot application scenario, we have to carefully select the quality metrics criteria that will
measure these functional requirements.
For that, we pool our metrics from the External and Quality in use metrics as their context of use is
determined by user factors, task factors and physical and social environmental factors.
                                                                                             107 / 130
More specifically Quality in use is assessed by observing representative users carrying out
representative tasks in a realistic context of use. The measures may be obtained by simulating a
realistic working environment (for instance in a usability laboratory) or by observing operational use
of the product. In order to specify or measure quality in use it is first necessary to identify each
component of the intended context of use: the users, their goals, and the environment of use. The
evaluation should be designed to match this context of use as closely as possible. It is also important
that users are only given the type of help and assistance that would be available to them in the
Assessment criteria definition specifies how the results of validation along the various metrics and
according to the various rating levels should be summarized. One might specify, for example, that
weighted averages be used.
A complementary task is of rating levels definition. This specifies how a score for some metric
relates to satisfaction of some user requirements, expressed as some combination of quality
characteristics. In other words, rating levels definition tells us how some score should be interpreted
in relation to how well some requirements have been satisfied. Some requirements will be critical,
others desirable. Ratings must therefore be further judged in light of such constraints.

This is the most important step. Here we have to define the whole framework, including the
validation methods to be used and the schedule of actions for the evaluator, i.e. producing a plan for
the validation. ISO/IEC 14598 provides set of design processes for the software/product validation
for different validation up-takers, namely for: Developers, End-users, Evaluators (External).
The validation process -according to the ISO/IEC 14598 norms - should consist of a set of activities
which are conducted either by the developers or by acquires (we focus on these two, as these
represent the roles of the partners of the SAPHIRE consortium). We adopt these recommendations
and we draw our HPA pilot application validation procedure, described in the following section.

                                                                                            108 / 130 TEST FACILITY
Intended context of use:
Context used for the test: The first step is the identification of the environment in which the pilot
application evaluation will be carried out. The validation team has to log all the system (software
and hardware) specifications as well as the environment‘s constraints, in order to select the most
representative scenarios to validate, the ones that will maximise the risk of failure and hence
maximise the valuable feedback. SELECTING THE SCENARIOS
The input to this task should be from the one hand the selected (tasks) that we want to validate and
from the other the test facility requirements that we defined in step one. These tasks are a set of
different testing procedures, regarding:
   1. System functionality based on the simulation of the sensor network operation
   2. Alarm functionality (direct alarms from sensor network)
   3. CGMs general operations
   4. Functionality of Medical Services and Interpretations by CGMs
   5. Functionality of Medical Analyses of the sensor data.

Each of these tasks will include different possible medical and practical situations that could be
imagined to arise when using the system. Thus, the outcome of this second step should be a list of
(grouped functionalities) forming the validation scenarios of the tasks. METRICS SELECTION
We select those metrics that will be easy to apply and to measure. Our HPA metrics are user-
oriented, meaning that are monitoring the user‘s behaviour by using the system in the way each
validation scenario dictates. By doing this the system‘s requirements (functional and non-functional)
under study are evaluated and the degree of fulfilment is extracted. We employ a mixture of external
and quality in use metrics that enable us to perform a useful analysis and draw some valuable
conclusions on the received results. There are three broad categories of metrics when it comes to
user-oriented validation namely Effectiveness, Efficiency and Satisfaction.

                                                                                           109 / 130
Effectiveness relates the goals of using the product to the accuracy and completeness with which
these goals can be achieved. Common measures of effectiveness include percent task completion,
frequency of errors, frequency of assists to the participant from the testers, and frequency of accesses
to help or documentation by the participants during the tasks. It does not take account of how the
goals were achieved, only the extent to which they were achieved. Efficiency relates the level of
effectiveness achieved to the quantity of resources expended.
      Completion Rate: The results must include the percentage of participants who completely
       and correctly achieve each task goal. If goals can be partially achieved (e.g., by incomplete
       or sub-optimum results) then it may also be useful to report the average goal achievement,
       scored on a scale of 0 to 100% based on specified criteria related to the value of a partial
       result. For example, a spell-checking task might involve identifying and correcting 10
       spelling errors and the completion rate might be calculated based on the percent of errors
       corrected. Another method for calculating completion rate is weighting; e.g., spelling errors
       in the title page of the document are judged to be twice as important as errors in the main
       body of text. The rationale for choosing a particular method of partial goal analysis should be
       stated, if such results are included in the report.
      Errors: Errors are instances where test participants did not complete the task successfully, or
       had to attempt portions of the task more than once. It is recommended that scoring of data
       include classifying errors according to some taxonomy.
      Assists: When participants cannot proceed on a task, the test administrator sometimes gives
       direct procedural help in order to allow the test to proceed. This type of tester intervention is
       called an assist for the purposes of this report. If it is necessary to provide participants with
       assists, efficiency and effectiveness metrics must be determined for both unassisted and
       assisted conditions. For example, if a participant received an assist on Task A, that
       participant should not be included among those successfully completing the task when
       calculating the unassisted completion rate for that task. However, if the participant went on to
       successfully complete the task following the assist, he could be included in the assisted Task
       A completion rate. When assists are allowed or provided, the number and type of assists must
       be included as part of the test results. In some usability tests, participants are instructed to use
       support tools such as online help or documentation, which are part of the product, when they
       cannot complete tasks on their own. Accesses to product features which provide information
       and help are not considered assists for the purposes of this report. It may, however, be

                                                                                                110 / 130
       desirable to report the frequency of accesses to different product support features, especially
       if they factor into participants‘ ability to use products independently.
Efficiency relates the level of effectiveness achieved to the quantity of resources expended.
Efficiency is generally assessed by the mean time taken to achieve the task. A common measure of
efficiency is time on task.
      Task time: The results must include the mean time taken to complete each task, together with
       the range and standard deviation of times across participants. Sometimes a more detailed
       breakdown is appropriate; for instance, the time that users spent looking for or obtaining help
       (e.g., ncluding documentation, help system or calls to the help desk). This time should also
       be included in the total time on task.
      Completion Rate/Mean Time-On-Task: The measure Completion Rate / Mean Time-On-
       Task is the core measure of efficiency. It specifies the percentage of users who were
       successful (or percentage goal achievement) for every unit of time. This formula shows that
       as the time on task increases, one would expect users to be more successful. A very efficient
       product has a high percentage of successful users in a small amount of time. This allows
       customers to compare fast error-prone interfaces (e.g., command lines with wildcards to
       delete files) to slow easy interfaces (e.g., using a mouse and keyboard to drag each file to the
Satisfaction describes a user‘s subjective response when using the product. User satisfaction may be
an important correlate of motivation to use a product and may affect performance in some cases.
Questionnaires to measure satisfaction and associated attitudes are commonly built using Likert and
semantic differential scales. A variety of instruments are available for measuring user satisfaction of
software interactive products, and many companies create their own.
Whether an external, standardized instrument is used or a customized instrument is created, it is
suggested that subjective rating dimensions such as Satisfaction, Usefulness, and Ease of Use be
considered for inclusion, as these will be of general interest to customer organizations.
While each offers unique perspectives on subjective measures of product usability, most include
measurements of Satisfaction, Usefulness, and Ease of Use. Suppliers may choose to use validated
published satisfaction measures or may submit satisfaction metrics they have developed themselves.

                                                                                            111 / 130 SELECTION CONSIDERATIONS
Upon metrics selection we have to take into consideration the following factors: Interpretation of
When planning the use of metrics or interpreting measures it is important to have a clear
understanding of the intended context of use of the software, and any potential differences between
the test and operational contexts of use. For example, the ―time required to learn operation" measure
is often different between skilled operators and unskilled operators in similar software systems.
Examples of potential differences are given below.
a) Differences between testing environment and the operational environment
Are there any significant differences between the testing environment and the operational
The following are examples:
      testing with higher/comparable/lower performance of CPU of operational computer;
      testing   with   higher/comparable/lower       performance      of   operational   network        and
      testing with higher/comparable/lower performance of operational operating system;
      testing with higher/comparable/lower performance of operational user interface.
b) Differences between testing execution and actual operational execution - are there any significant
differences between the testing execution and operational execution in user environment?
The following are examples:
      coverage of functionality in test environment;
      test case sampling ratio;
      automated testing of real time transactions;
      stress loads;
      24 hour 7 days a week (non stop) operation;
      appropriateness of data for testing of exceptions and errors;
      periodical processing;
      resource utilisation;
      levels of interruption;
      Distractions.
c) User profile under observation

                                                                                             112 / 130
Log any significant differences between test user profiles and operational user profiles.
The following are examples of types of users;
      user skill levels;
      specialist users or average users;
      limited user group or public users.

Issues affecting validity of results
The following issues may affect the validity of the data that is collected:
a) Procedures for collecting evaluation results:
• automatically with tools or facilities/ manually collected/questionnaires or interviews;
b) Source of evaluation results:
• developers' self reports/reviewers‘ report/evaluator‘s report;
c) Results data validation:
• developers' self check/inspection by independent evaluators.

Balance of measurement resources
Is the balance of measures used at each stage appropriate for the evaluation purpose? It is important
to balance the effort used to apply an appropriate range of metrics for internal, external and quality
in use measures.

Correctness of specification
Measurements taken during software product evaluation at different stages are compared against
product specifications. Therefore, it is very important to ensure by verification and validation that
the product specifications used for evaluation reflect the actual and real needs in operation.

Validation of metrics
To obtain valid results from a quality evaluation, the metrics should have the properties stated
below. If a metric does not have these properties, the metric description should explain the
associated constraint on its validity and, as far as possible, how that situation can be handled.
a) Reliability (of metric): Reliability is associated with random error. A metric is free of random
error if random variations do not affect the results of the metric
b) Repeatability (of metric): repeated use of the metric for the same product using the same
evaluation specification (including the same environment), type of users, and environment by the
                                                                                                 113 / 130
same evaluators, should produce the same results within appropriate tolerances. The appropriate
tolerances should include such things as fatigue, and learning effect.
c) Reproducibility (of metric): use of the metric for the same product using the same evaluation
specification (including the same environment) type of users and environment by different
evaluators, should produce the same results within appropriate tolerances.
d) Availability (of metric): The metric should clearly indicate the conditions (e.g. presence of
specific attributes) which constrain its usage.
e) Indicativeness (of metric): Capability of the metric to identify parts or items of the software which
should be improved, given the measured results compared to the expected ones.
f) Correctness (of measure): The metric should have the following properties:
           1) Objectivity (of measure): the metric results and its data input should be factual: i.e.,
               not influenced by the feelings or the opinions of the evaluator, test users, etc. (except
               for satisfaction or attractiveness metrics where user feelings and opinions are being
           2) Impartiality (of measure): the measurement should not be biased towards any
               particular result.
           3) Sufficient precision (of measure): Precision is determined by the design of the metric,
               and particularly by the choice of the material definition used as the basis for the
               metric. The metric user will describe the precision and the sensitivity of the metric.
g) Meaningfulness (of measure): the measurement should produce meaningful results about the
software behaviour or quality characteristics.
The metric should also be cost effective: that is, more costly metrics should provide higher value

                                                                                             114 / 130 HPA VALIDATION METRICS
The proposed metrics for our HPA pilot application include the following:

Metric          Purpose of Method of Measurement,              Interpretation    Metric
Name            the        application formula and             of                scale
                metrics                data    element         measured          type
                                       computations            value

Task            What           User test   M1 = |1-ΣAi|        0<= M1 <=1        -
effectiveness                              Ai= proportional The closer to
                of       the               value of each 1.0
                goals of                   missing or       the better.
                the task is                incorrect
                                           component in the
                                           task output

Task            What           User test   X = A/B             0<= X <=1         Ratio
completion      proportion                 A = number of The closer to
                of the tasks               tasks completed   1.0 the better.
                is                         B = total number
                completed?                 of          tasks

Error           What is the User test      X = A/T             0<= X             Absolute
frequency       frequency                  A = number of The closer to 0
                of                         errors made by the better.
                                           the user
                                           T=   time      or
                                           number of tasks
Task time       How long User test         X = Ta              0<= X             Interval
                does                       Ta = task time      The smaller the
                it take to                                     better.
                complete a
Task            How            User test   X = M1 / T          0<= X             T= Time
efficiency      efficient                  M1      =     task The larger the     X=
                are    the                 effectiveness      better.            proportion/
                users?                     T = task time                         time
                                                                                            115 / 130
Software       What is the Usage           X = 1-A / B           0<= X <=1       Absolute
damage         Frequency     statistics    A = number of The closer to 1
               of                          occurrences of the better.
                                           B = total number
                                           of          usage
Data           What is the Count the a) X= 1 – A / N             0<=X<= 1        Absolute
corruption     frequency   occurrences A= Number of              The closer to
prevention     of     data of          times   that  a           1.0 is the
               corruption major and major data
                           minor data corruption event           better.
                             corruption    occurred
                             events.       N= Number of
                                           test cases tried to
                                           cause data
                                           corruption event
Failure        How many Count the X= A1 / A2                     0<=X            Absolute
density        failures number of    A1 = number of              It depends on
against test   were     detected     detected failures           stage of
               detected failures and A2 = number of
cases                                                            testing.
               during   performed    performed      test
               defined       test cases.   cases                 At the later
               trial                                             stages,
                                                                 smaller is

                                                                                        116 / 130
This stage consists of the following phases:
1. Data Scoring
2. Statistical Analysis
3. Presentation of results
4. Performance results DATA SCORING
The method by which the data collected are scored should be described in sufficient detail to allow
replication of the data scoring methods by another organization if the test is repeated. Particular
items that should be addressed include the exclusion of outliers, categorization of error data, and
criteria for scoring assisted or unassisted completion. STATISTICAL ANALYSIS
Particular items that should be addressed include statistical procedures (e.g. transformation of the
data) and tests (e.g. t-tests, F tests and statistical significance of differences between groups). Scores
that are reported as means must include the standard deviation and optionally the standard error of
Both tabular and graphical presentations of results should be included. Various graphical formats are
effective in describing usability data at a glance. Bar graphs are useful for describing subjective data
such as that gleaned from Likert scales. A variety of plots can be used effectively to show
comparisons of expert benchmark times for a product vs. the mean participant performance time.
The data may be accompanied by a brief explanation of the results but detailed interpretation is
A table of results may be presented for groups of related tasks (e.g. all program creation tasks in one
group, all debugging tasks in another group) where this is more efficient and makes sense. If a unit
task has sub-tasks, then the sub-tasks may be reported in summary form for the unit task. Finally, a
summary table showing total mean task times and completion rates across all tasks should be

                                                                                               117 / 130
presented. Testers should report additional tables of metrics if they are relevant to the product‘s
design and a particular application area.
For example the following template is proposed for presenting the obtained results for the four
selected metrics (Unassisted Task Effectiveness, Assisted Task Effectiveness, Task Time,
Effectiveness / Mean Time-On-Task)

User #               Unassisted Task Assisted    Task Task Time                  Effectiveness /
                     Effectiveness   Effectiveness                               Mean Time-On-
                     [(%)Complete]   [(%)Complete]                               Task

                                                                                         118 / 130

                  Rhythm → sinus rhythm;
                  HR → 107bpm;
                  PR →180ms;
                  QRS → 100ms;
                  ST deviation → +1.6mm in V1, V2, V3;
          2.BP                  160/94mmHg;
          3.SaO2                89%;
          4.Event button        chest pain;

          1. Coronary spasm=FALSE;
          2. Aspirin present in hospital medication;
          3. NYHA I;
          4. No claudication;
          5. No astma/bronhial spasm;
          6. No AVB;
          7. Anxiety is present – this data should be provided to system as a question when the
             system run "first line medication";
          8. Killip=1– this data should be provided to system as a question when the system
             run "first line medication";
          9. PTCA available=TRUE – this data should be provided to system as a question
             when the system run " decision algorithm in AMI ";
          10. Contraindication for fibrinolysis=TRUE;
          11. Chest pain duration=5minutes – this data is define as: [(actual time) OR (chest
             pain stop)] – time of start event;
          12. Coronary anatomy=1;

                                                                                     119 / 130
       EVENT → (From ECG sensor: ST elevation =1.6mm in V1,V2,V3) AND (From event
button: patient push the button for chest event);

       ALERT → system should generate a red alert with the message "ST-elevation";

       FLOWCHART → system should run "Diagnosis of acute coronary syndrome" and provide
the following results:
                        Point 1 → enter point in flowchart (see fig. 10.6);
                        Point 18 →system should generate the following message "Consider coronary
                         spasm (Prinzmetal)" (see fig. 10.6);
                        Point 19 → system should run "Decision algorithm in AMI " (see fig. 10.6);
                        Point 2 → run "first line medication" flowchart (see fig. 10.1);
                        Point 3 → system should generate the following medical recommendation:
                         "Oxygen 1-2 l/min" (see fig 10.2);
                        Point 4 → run " Algorithm for β-blocker" (see fig 10.2);
                        Point 5 → system should generate the following medical recommendation:
                         "Morphine i.v." (see fig 10.2);
                        Point 6 → system should generate the following medical recommendations:
                         "Start Metoprolol i.v. 5mg" and after 5 minutes "Star Metoprolol p.o. 50mg to
                         every 6 hours" (see fig 10.3);
                        Point 7 → system should generate the following medical recommendations:
                         "Start invasive reperfusion therapy" (see fig 10.1) and wait for coronary
                         angiography. After angiography system should run "Invasive reperfusion
                         therapy algorithm";
                        Point 8 →system should generate the following medical recommendations:
                         "Start PTCA" (see fig 10.4);

                                                                                            120 / 130
                  Rhythm → sinus rhythm;
                  HR → 110bpm;
                  PR →160ms;
                  QRS → 100ms;
                  ST deviation → +4mm in V1, V2, V3;
          6.BP                   130/84mmHg;
          7.SaO2                 85%;
          8.Event button         chest pain;

          1. Coronary spasm=FALSE;
          2. Aspirin present in hospital medication;
          3. NYHA I;
          4. No claudication;
          5. No astma/bronhial spasm;
          6. No AVB;
          7. Anxiety is present – this data should be provided to system as a question when the
             system run "first line medication";
          8. Killip = 1– this data should be provided to system as a question when the system
             run "first line medication";
          9. PTCA available = TRUE – this data should be provided to system as a question
             when the system run " decision algorithm in AMI ";
          10. Contraindication for fibrinolysis = FALSE;
          11. Chest pain duration=2hours – this data is define as: [(actual time) OR (chest pain
             stop)] – time of start event;
          12. LVEF=50%;
          13. LBBB=FALSE;
          14. Able to exercise=TRUE;
          15. Exercise test=POSITIVE;
                                                                                      121 / 130
               16. Coronary anatomy=4;

       EVENT → (From ECG sensor: ST elevation =1.6mm in V1,V2,V3) AND (From event
button: patient push the button for chest event);

       ALERT → system should generate a red alert with the message "ST-elevation";

       FLOWCHART → system should run "Diagnosis of acute coronary syndrome" and provide
the following results:
                        Point 1 → enter point in flowchart (see fig. 10.6);
                        Point 18 →system should generate the following message "Consider coronary
                         spasm (Prinzmetal)" (see fig. 10.6);
                        Point 29 → system should run "Decision algorithm in AMI " (see fig. 10.6);
                        Point 2 → run "first line medication" flowchart (see fig. 101.1);
                        Point 3 → system should generate the following medical recommendation:
                         "Oxygen 1-2 l/min" (see fig 10.2);
                        Point 4 → run " Algorithm for β-blocker" (see fig 10.2);
                        Point 5 → system should generate the following medical recommendation:
                         "Morphine i.v." (see fig 10.2);
                        Point 6 → system should generate the following medical recommendations:
                         "Start Metoprolol i.v. 5mg" and after 5 minutes "Star Metoprolol p.o. 50mg to
                         every 6 hours" (see fig 10.3);
                        Point 10 →system should generate the following medical recommendations:
                         "Start fibrinolysis" (see fig. 10.1);
                        Point 11 → before discharge system will run "Algorithm for predischarge
                         evaluation for patients without catheterization" and should generate the
                         following medical recommendations: "High risk patient" and run "Invasive
                         reperfusion therapy algorithm" (see fig. 10.5);
                        Point 12 →system should generate the following medical recommendations:
                         "Start CAGB" (see fig 10.4);

                                                                                             122 / 130
                        Rhythm → sinus rhythm;
                        HR → 98bpm;
                        PR →130ms;
                        QRS → 110ms;
                        ST deviation → -2mm in V2, V3, V4, V5, V6;
               10. BP                   100/60mmHg;
               11. SaO2                        95%;
               12. Event button                chest pain;

               1. Chest pain duration=2hours – this data is define as: [(actual time) OR (chest pain
                   stop)] – time of start event;
               2. First Troponin=FALSE;
               3. Second Troponin=TRUE;
               4. CK-MBmass=50u/l (elevated);
               5. Recent MI=3days;

       EVENT → (From ECG sensor: ST depression =2mm in V2,V3,V4,V5,V6) AND (From
event button: patient push the button for chest event);

       ALERT → system should generate a red alert with the message "ST-depression";

       FLOWCHART → system should run "Diagnosis of acute coronary syndrome" and provide
the following results:
                        Point 1 → enter point in flowchart (see fig. 10.6);
                        Point 13 → system should generate the following message "Non-ST segment
                        Point 14, 15 →system should generate the following message "Wait 6 hours";
                        Point 16→ system should generate the following message "ACS";
                        Point 17 →system should generate the following message "Reinfarction".
                                                                                          123 / 130
     Point 2

                     Point 7

Point 10

       Figure 10.1

                               124 / 130
                                                   First line medication

 Aspirin – is it in       SaO2<90%?(1)      BPs<90mmHg(1)                      HF NYHA>2 (2)                   Angina
  treatment?(2)                                                                                                      OR
                                  YES             OR                                 OR
                                               BPs<BPbs-                        PR>240ms (1)                anxiety? (2)
           NO                                  30mmHg(1)                                                                  YES
                         Oxygen 1-2 l/min                                            OR
                                              HR<60bpm(1)                                             Asthma/ bronchial spasm
CI for Aspirin ? (2)              Point 3         OR                                                            (2)
                                                       NO                  Asthma / bronchial spasm
                                            RV infarction?(2)                         (2)                            OR
                                              Angina?(2)                             OR                 BPs < 100mmHg (1)
           NO                   YES
                                                       YES                  Claudication NO (2)
                                                                                         at rest                     OR
                                                                                                           Killip > 3? (2)
  Aspirin 250mg        Clopidogrel 300mg     HR>100bpm?(1)                                                          NO
                                                                           Algorithm for β-blocker

                                                       NO                                                   Morphine IV

                                            Algorithm for NTG                           Point 4
                                                                                                                      Point 5

                                               Figure 10.2

                                                                                                         125 / 130
             Β-blocker algorithm

                HF NYHA < 3 (2)
                 PR < 240ms (1)
                  AVB < 2 (1)
                HR > 60 bpm (1)
               BPs >100mmHg (1)

           START Metoprolol i.v. 5mg
                 Wait 5 minutes

Point 6
          START Metoprolol orally 50mg
                  Wait 6 hours

                       Figure 10.3
                  Invasive reperfusion therapy algorithm

                           Coronary angiography

                          Coronary stenosis≥50%                          No need for invasive therapy


      1, 2-vessel disease (2)                        3-vessel disaese (2)
               OR                                             OR
    Absence LMS disease (2)                              LMS disease (2)
                    YES                                      DM (2)
                                                         LVEF < 40% (2)

Point 8
                                Point 12                     CABG

                                           Figure 10.4

                                                                                            127 / 130
 Algorithm for predischarge
evaluation for patients without

                                                                          Invazive reperfusion therapy
       LVEF<40%(2)                                                                 algorithm


                                               Point 11                            High risk
          LBBB (2)                YES

                                             Positive dobutamine stress      YES
                                  NO             echography/ stress
     Able to exercise (2)                     myocardial scintigraphy


    Positive submaximal                YES
      exercise test(2)


          Low risk

       Medical therapy

                                       Figure 10.5

                                                                                          128 / 130
                              Point 1

           Point 18

                                        Point 13
   Point 19
                                          Point 15

                                         Point 17
 Point 14

Point 16

                      Figure 10.6

                                             129 / 130

1 Smack API Website

2 An Agent-Based Alert Distribution System for Intelligent Healthcare Monitoring, Akcay B, MS

3 Thawte Corporation Website

4 Bouncy Castle Security Provider

5 SMS Explorer Website

6 The Protégé Ontology Editor and Knowledge Acquisition System

7 SAPHIRE Story Board, August 2006

8 SAPHIRE Deliverable 5.4.1

9 Saphire DoW

10 Saphire D.8.1.1 deliverable

                                                                                   130 / 130

To top