Artemis Deliverable D6

Document Sample
Artemis Deliverable D6 Powered By Docstoc
					          IST-27074 SAPHIRE                                                      D.9.1.1

                            IST- 27074 SAPHIRE
                   “Intelligent Healthcare Monitoring based on a
                        Semantic Interoperability Platform”


          PRIORITY 2.4.13 Strengthening the Integration of the ICT research effort in an
          Enlarged Europe Focus: eHealth

SAPHIRE – Deliverable 9.1.1- Delivery of the Test
   Environment and the Assessment Criteria

      Due Date:                        December 15, 2007 (M22+45 days)
      Actual Submission date:          January 8, 2007
      Project Dates:                   Project Start Date : January 01, 2006
                                       Project End Date : June 30, 2008
                                       Project Duration : 30 months
      Leading Contractor               ALTEC

       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
 CO       Confidential, only for members of the consortium (including the Commission

IST-27074 SAPHIRE                                                             D.9.1.1

SAPHIRE Consortium Contacts:

Organisation Name                  Phone              Fax                    E-Mail
METU-SRDC Asuman Dogac             +90-312-2105598    +90(312)2101004
CYBERFAB     Micheal Setton        +33-476-081-957    +33-672-995-202
OFFIS        Marco Eichelberg      +49-441-9722-147   +49-441-9722-102
ALTEC        Adamantios            +30 2310 595646    +30 2310 565630
IPA SA       Gabriel Spiridon      +40 21 230 25 12   +40 21 230 70 63
SCUB         Maria Dorobantu       +4021 3170108      +4021 3170108

SSK          Michael               +49 5424641565     +49 5424641202         mboeckelmann@schuechtermann
TEPE         Bulent Kunac          +90-312-2919100    +90-312-2662998

Document History:

Version   Date           Changes                                       From                  Review

0.1       10/08/2007     First deliverable version                     ALTEC                 ALTEC

0.2       13/12/2007     Second Deliverable version                    All                   ALTEC

0.3       28/12/2007     Third Deliverable version                     METU                  ALTEC

1.0       08/01/2008     Final Deliverable Version                     ALTEC                 ALTEC

                                                                                    2 / 43
IST-27074 SAPHIRE                                                                                         D.9.1.1

                                               Table of contents
1      Executive summary................................................................................................ 4
2      VALIDATION PROCESS MODEL ..................................................................... 5
    2.1      ESTABLISH VALIDATION REQUIREMENTS ........................................ 5
    2.2      VALIDATION SCOPE ................................................................................. 6
       2.2.1      SPECIFY VALIDATION ...................................................................... 6
       2.2.3      METRICS SELECTION ....................................................................... 7
       2.2.4      EXECUTE THE VALIDATION ......................................................... 10
    2.3      ASSESSMENT CRITERIA DEFINITION ................................................. 11
       2.3.1      Definition of the evaluation objectives and criteria for SAPHIRE Pilot
       Applications ......................................................................................................... 12
3      Hospital Pilot Application Operational Medical Scenarios ................................. 16
    3.1      Testing Environment for Hospital Pilot Application ................................... 21
    3.2      HPA TECHNICAL SPECIFICATIONS ..................................................... 23
       3.2.1      HARDWARE SPECIFICATIONS ...................................................... 23
       3.2.2      PCs AND PERIPHERALS SPECIFICATIONS ................................. 29
4      Homecare Pilot Application Operational Medical Scenarios .............................. 33
       4.1.1      Rehabilitation of the inpatient .............................................................. 33
       4.1.2      Secondary prevention of the outpatient ............................................... 34
       4.1.3      Alarms and exceptions ......................................................................... 34
       4.1.4      Report of the training results................................................................ 37
    4.2      Testing Environment for Hospital Pilot Application ................................... 39
    4.3      Hardware Specifications .............................................................................. 40
       4.3.1      Ergometer Bike .................................................................................... 40
       4.3.2      Panel PCs ............................................................................................. 41
5      Conclusions .......................................................................................................... 42
6      References ............................................................................................................ 43

                                                                                                                   3 / 43
IST-27074 SAPHIRE                                                      D.9.1.1

1 Executive summary

In this deliverable we provide the testing environment specifications for the pilot
applications realized within the scope of SAPHIRE work packages 7 and 8 and we
describe our reasoning behind choosing the pilot application assessment framework,
comprising of metrics, measurements, and assessment criteria.

The document is structured as follows:

The second chapter is dedicated to Validation Process model that we will employ in
tasks 9.2.1 and 9.3.1. in this section we give an overall description of our validation
approach based on ISO standards and we present the quality metrics for our
assessment measurements, as well as the SAPHIRE pilot application assessment

Chapters three and four are dedicated in providing information regarding our Hospital
and Homecare pilot applications respectively. There, we provide information on the
testing environments the hardware and software requirements, and brief descriptions
of the operational scenarios to be employed for the actual pilot applications
assessments. The information provided in these chapters is heavily based on the
reports produced in work packages 7 and 8.

                                                                             4 / 43
IST-27074 SAPHIRE                                                        D.9.1.1

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

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.

                                                                               5 / 43
IST-27074 SAPHIRE                                                     D.9.1.1

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.

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
2. Assessment criteria definition

                                                                            6 / 43
IST-27074 SAPHIRE                                                         D.9.1.1


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 pilot application scenarios, 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.

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 operational environment.


We select those metrics that will be easy to apply and to measure. Our metrics are
user-oriented, meaning that are monitoring the user’s behaviour by using the system
in the way each validation scenario dictates.

System’s requirements (functional and non-functional) 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, according to ISO standards ([1],
[2], [3]) of metrics when it comes to user-oriented validation namely Effectiveness,
Efficiency and Satisfaction.

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

                                                                                7 / 43
IST-27074 SAPHIRE                                                        D.9.1.1

       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
      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 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 trash).

                                                                               8 / 43
IST-27074 SAPHIRE                                                                                     D.9.1.1

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.

The proposed metrics for our pilot application include the following:

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

Task              What              User test        M1 = |1-ΣAi|                 0<= M1 <=1                    -
effectiveness     proportion                         Ai= proportional value of    The closer to 1.0
                  of the goals of                    each missing or              the better.
                  the task is                        incorrect component in the
                  achieved                           task output
Task              What              User test        X = A/B                      0<= X <=1                     Ratio
completion        proportion                         A = number of tasks          The closer to
                  of the tasks is                    completed                    1.0 the better.
                  completed?                         B = total number of tasks
Error             What is the       User test        X = A/T                      0<= X                         Absolute
frequency         frequency of                       A = number of errors         The closer to 0
                  errors?                            made by the user             the better.
                                                     T= time or number of
Task time         How long does     User test        X = Ta                       0<= X                         Interval
                  it take to                         Ta = task time               The smaller the
                  complete a                                                      better.
Task efficiency   How efficient     User test        X = M1 / T                   0<= X                         T= Time
                  are the users?                     M1 = task effectiveness      The larger the                X=
                                                     T = task time                better.                       proportion/
Software          What is the       Usage            X = 1-A / B                  0<= X <=1                     Absolute
damage            Frequency of      statistics       A = number of                The closer to 1
                  software                           occurrences of software      the better.
                  corruption?                        corruption
                                                     B = total number of usage
Data              What is the       Count the        a) X= 1 – A / N              0<=X<= 1                      Absolute
corruption        frequency         occurrences of   A= Number of times that a    The closer to
prevention        of data           major and        major data                   1.0 is the
                  corruption        minor data       corruption event occurred    better.
                  events?           corruption       N= Number of test cases

                                                                                                            9 / 43
IST-27074 SAPHIRE                                                                               D.9.1.1

                                  events.             tried to cause data
                                                      corruption event
Failure density   How many        Count the           X= A1 / A2                0<=X                      Absolute
against test      failures        number of           A1 = number of detected   It depends on
cases             were detected   detected failures   failures                  stage of
                  during          and                 A2 = number of            testing.
                  defined trial   performed test      performed test cases      At the later
                  period?         cases.                                        stages,
                                                                                smaller is

This stage consists of the following phases:
1. Data Scoring
2. Statistical Analysis
3. Presentation of results
4. Performance results

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

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 the mean.

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 discouraged.

A table of results may be presented for groups of related tasks 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 presented. Testers
should report additional tables of metrics if they are relevant to the product’s design
and a particular application area.

                                                                                                     10 / 43
IST-27074 SAPHIRE                                                       D.9.1.1


Assessment criteria definition specifies how the results of validation along the various
metrics and according to the various rating levels should be summarized. ISO/IEC
14598 provides set of design processes for the software/product validation for
different validation up-takers, namely for: Developers, End-users, Evaluators.
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 pilot application validation
procedure, described in the following section.

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.

These scenarios have been identified in tasks 7.2 and 8.2 for the homecare and
hospital applications respectively. We provide here the necessary information for
tracking purposes for the actual validation activities in task 9.2.

                                                                             11 / 43
IST-27074 SAPHIRE                                                      D.9.1.1

2.3.1 Definition of the evaluation objectives and criteria for SAPHIRE
      Pilot Applications

In previous section we presented the validation metrics for our pilot applications. The
measurements on Satisfaction, Effectiveness, and Efficiency give a good indication of
the quality of the validated system’s functionalities. Still, we need to identify the
overall user criteria based on which the system as whole could be simply and easily

We identify our User Acceptance Criteria with the aim to provide an abstract
assessment layer, beneath which, our validation metrics categories rest. Our approach
is schematically presented below:


           Usefulness             Operability            Usability


          Metrics on             Metrics on            Metrics on
          Efficiency            Effectiveness          Satisfaction

                         Figure 1 Overall Assessment Approach

The identification and definition of evaluation objectives primarily needs to be based
upon the definition of user needs. What are the key questions to which the users,
decision makers and other stakeholders concerned in the project must have answers?

With evaluation objectives, there should correspond criteria for making judgments
and these evaluation objectives should relate closely to the implementation and use of
the system.

                                                                            12 / 43
IST-27074 SAPHIRE                                                         D.9.1.1

“User Acceptance” evaluation is the most significant when it comes in evaluating a
pilot application at site. User acceptance evaluation aims to estimate users’ attitudes
to and perception of system investigated, usually based on questionnaire surveys,
interviews, etc.

Our user-oriented assessment criteria marked in the table below have been defined as
being possible to evaluate at this stage of furnishing and refining our SAPHIRE

                    User acceptance Assessment Criteria
Usefulness Criteria
   Relevance of the alarms generated
   Sufficiency of the information provided
   Worth of the information provided
   Work-ability of the information provided
Usability criteria
   Clearness of information / messages
   Adaptation to users' understanding
   Easiness to learn
   General ergonomics of the Human Computer Interface
Operability criteria
   Human control
   Efficiency of the switching functions
   Efficiency of the search and retrieving functions
   Alarm management

According to the rules defined in the Evaluation Plan, each evaluator (SAPHIRE
stakeholder) has to provide his opinion or feelings on the SAPHIRE system so that the
results could be further exploited and compared with those of other evaluators.

Therefore, each criteria will be evaluated separately and according to quite strict rules.
Evaluators will have to be requested to provide their judgement by giving a mark
from A to D. The meanings of these letters are:

   A = no, not at all, absolutely not
   B = less than medium, less than satisfactory
   C = more than medium, more than satisfactory
   D = very, very good, very well

User acceptance indicator forms
Below, we present the models of the evaluation forms that will be filled in by
evaluators. They have to fill in these forms with their marks, i.e. A to D, according to
their evaluation of the criteria.

                                                                               13 / 43
IST-27074 SAPHIRE                                                                     D.9.1.1

Evaluators name:                          Date of Evaluation:
Role of Evaluator (Saphire stakeholder) :
           Scenario Number: ##            Scenario name:
                                          H/W           S/W                             Erroneous
                                          Operation     Operation                       operation
                                                        Sensors,      Messages,       management
                                                        PCs,          Human            Errors
Usefulness Criteria                                     Ergobike        Computer            trapped
                                                          etc.           Interfaces         Alerts etc
Relevance       of        the     messages/alerts
   Do the messages/alarms (detection) provided by
    the system have an obvious relationship with the
    current functionality ?
Sufficiency of the information provided
   Do the relevant messages/alarms (detection)
    provided by the system have an unambiguous
    relationship with current functionality?
Work-ability         of         the   information
   Do the received relevant, sufficient and
    worthwhile information allow or help me to take
    the appropriate decision?
                                        Table 1 Usefulness Criteria

Evaluators name:                             Date of Evaluation:
Role of Evaluator (Saphire stakeholder) :
Scenario Number: ##                 Scenario Name:
               Operability Criteria:                           Evaluation mark
Human control
 Do I receive assistance from the system ?
 In which extend do I keep the control of the system ?
 Do I have the possibility to verify the information provided by
    the system ?

Efficiency of the switching functions
 Do the switching functions allow me to perform my job
    efficiently when no message/error occur ?
 Do the switching functions allow me to perform my job
    efficiently when one or several messages/errors occur ?
Efficiency of the search and retrieval functions
 Am I always able to provide all the requests that I wish ?
 Do I receive relevant answers to my requests from the system ?
 Am I able to efficiently "travel" through the various functions
    made available from the system ?
Alarm management
Are the alarm messages easy to exploit ?
Are the alarms easy to process ?
                                   Table 2 Operability Criteria

                                                                                            14 / 43
IST-27074 SAPHIRE                                                   D.9.1.1

Evaluators name:                             Date of Evaluation:
Role of Evaluator (Saphire stakeholder) :
Scenario Number: ##                 Scenario Name:
                Usability Criteria:                            Evaluation mark
Clearness of information / messages
 Are all the messages that are provided by the system simple,
    clear and unambiguous ?
Adaptation to users’ understanding
 Are all the messages communicated to and actions required
    from operators well adapted to their level of understanding ?
Easiness to learn
 Is it easy to learn and use the system ?
General ergonomics of the HCI
 Is the SAPHIRE system user-friendly ?
 Is the SAPHIRE system pleasant to use ?
                                      Table 3 Usability Criteria

                                                                         15 / 43
 IST-27074 SAPHIRE                                                     D.9.1.1

 3 Hospital Pilot Application Operational Medical Scenarios

 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

 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
       directly or composing sensor data.

Therefore, we have built up Medical Operational Scenarios to deal with:
 1.      Starting the monitoring:
      Choose the patient
      Assign the sensor set
      Set up the monitoring parameters and the alert thresholds
      Choose the guidelines
 2.      Receiving data form the sensors:
      Visualize of the sensor data
      Analyze of the sensor data
 3.      Receiving the system alerts:
      Red alerts
      Yellow alerts
      Alerts from the guidelines
 4.      Retrieving data from the EMR/HIS:
      Input data to the EMR/HIS
      Output data from the EMR/HIS
 5.      Executing the guidelines:
      Execution of the Clinical guideline by accessing the sensor data and Electronic
         Healthcare Records of the Patient
      Generation of clinical decisions/ recommendations
      Validation of the clinical decision/recommendations
 6.      Training the medical staff to use the system:
      Inform the patient
      Attach the sensors
      Check quality of transmitted data
      Check the alerts on a regular basis
      Correct transmission if artifacts/ interruption
 7.      Discontinuation of patient monitoring:
      Stop the monitoring
      Medical conclusions and discharge report

                                                                            16 / 43
IST-27074 SAPHIRE                                                          D.9.1.1

8.       Periodic system service/ check-up
        Check the sensors
        Check the EMR
        Check transmission and functions of the system
        Check web services and security

                        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               Patient-specific                  Available sensors set
 to the patient                    monitoring parameters             is selected via GUI
                               (5) and user alert              (4)
          (6)                      thresholds defined

         CONTINUED FOR 24-48 HOURS

                                                                                17 / 43
IST-27074 SAPHIRE                                                            D.9.1.1

                       2. Receiving data form the sensors
                                Sensor data
                               ECG, BP, SpO2

              Bluetooth connection
  (2)         BT Manager                 (1)
              BT Communication

                                                                          SENSOR ALERTS
                               GATEWAY PC:
               Visualization of the data in the patient window                •   VIA MOBILE
                                                                              •   VIA EMAIL
   Analyzing the data:
                           Server PC:
                                                                              •   ALERTS TO
        - Compare to thresholds                                                   BE TAKEN
        - ECG analysis (Rhythm and ST deviation)                                  AS INPUT
        - + data fusion and trend detection                                       FOR THE

                          3. Receiving the system alerts

                      Doctor/nurse on-call receives an alert

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

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

                                                                                  18 / 43
IST-27074 SAPHIRE                                                             D.9.1.1

                    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/ laboratories)

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

                            5. Executing the guidelines

                            PATIENT MONITORING STARTED

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

                                     Sensor alarms are sent to the CGMs

 Display flowcharts to be               executing of the flowcharts
 executed and initiate                  may be triggered by sensor
 execution                              alarms

                                                                 (5)    Go to related
                                                                        flowcharts/ guidelines if
                                                                        the case
                                                      RECOMMENDATIONS/ ALERT MESSAGES

               MEDICAL ACTION

                                                                                   19 / 43
IST-27074 SAPHIRE                                                                   D.9.1.1

               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)
      Verify the quality of the sensor                     Regular checks of the alerts
      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 tests
                     - 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 CCU
              - 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

                                                                                         20 / 43
IST-27074 SAPHIRE                                                       D.9.1.1

                     8. Periodic system service/ check-up

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

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

 3.1 Testing Environment for Hospital Pilot Application

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 pictures 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 application.

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

                                                                             21 / 43
IST-27074 SAPHIRE                                                            D.9.1.1

           Picture 1 Isolated area, secured and used as monitoring area for HPA.

               Picture 2. Monitoring area and access to the wards for HPA.

                                                                                   22 / 43
IST-27074 SAPHIRE                                                             D.9.1.1

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


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 synchronization.
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).

                                                                                   23 / 43
            IST-27074 SAPHIRE                                                         D.9.1.1

Bluetooth radio                                                                                   SD Card

                                                                                            LCD display

 Oximeter                                                                                         Navigation

            - 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 configuration.
            - 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 gateway.
            - 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.

                                                                                           24 / 43
IST-27074 SAPHIRE                                                         D.9.1.1

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.

The pulse oximeter can be fitted with 3 types of sensors depending on healthcare
professional preferences:
    - 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

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
   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       330 mmHg adult ; 165 mmHg
   (first fault condition):                            neonatal mode

                                                                               25 / 43
IST-27074 SAPHIRE                                                       D.9.1.1

   Time required for BD measurement:                  typical (normal) 25s
                                                      max.: adults 90s,
                                                      max.: neonates 60s


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.

                                                                             26 / 43
IST-27074 SAPHIRE                                                    D.9.1.1

The PS410 ECG Simulator (Fluke Biomedical) is to be used for sensors simulation in
Hospital PA; General features of the simulator shown below:

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:
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 respiration
ECG Performance, Lead II
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
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

                                                                          27 / 43
IST-27074 SAPHIRE                                             D.9.1.1

Arrhythmia Selections
PVC1 Left           PVC2 Early, RV     Ventricular        Atrial Fibrillation
Ventricular Focus Focus                Fibrillation       Coarse/Fine
PVC1 Early, LV      PVC2 R on T, RV    Supraventricular   Atrial Tachycardia
Focus               Focus              Tachycardia
PVC1 R on T, LV     Bigeminy           Premature Atrial   Conduction
Focus                                  Contraction        Defects

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 Block
Frequent            Ventricular        Irregular Rhythm   Left Bundle
Multifocal PVCs     Tachycardia                           Branch Block
PVC2 Right                             Atrial Flutter
Ventricular Focus

                                                                   28 / 43
IST-27074 SAPHIRE                                                      D.9.1.1

                     Figure 2 Simulator controls and terminals


No.   Name          Quantity                              Functionality      Remarks
 1.   Dell            1pc.     CPU: Intel Xeon            Server:                 optionally, a PCI-
      PowerEdge                3.2GHz                                              express VGA card
                                                            Interoperabi
      1800 SCSI,                                                                   can be installed for
                               MB: Chipset Intel           lity Platform
      Xeon                                                                         increased
      3.2GHz,                                               Cardionics?           performance; in
      2GB                      VGA: ATI Radeon                                     such case a silent
                               7000-M 16MB                  Care2x / or
                                                                                   one is strongly
                               SDRAM                       custom DBs
                               MEM: 2x1GB (Max              Back-up              the optical and
                               12GB)                                               floppy drives
                               HDD: 3x73GB 10K                                     are only
                                   U320 Hot Plug                                   necessary for
                                   SCSI +                                          the initial setup
                                   2x320GB                                         and the
                                   SATAII                                          following
                               OPT: DVDRW DL                                       work and
                               FDD: 3.5" 1.44MB                                    should be
                                                                                   disabled for
                               LAN: Intel Gigabit                                  day-to-day use
                               82541 Server Adapter
                                                                                  all the

                                                                            29 / 43
IST-27074 SAPHIRE                         D.9.1.1

                    KB&MOUSE: DELL                  specifications
                                                    listed are subject to
                    LCD: SAMSUNG
                                                    changes upon
                    SyncMaster 931BF or
                                                    acquisition, after
                                                    having seen the
                    UPS: APC 1500VA                 offers form the
                    or better                       market. However,
                                                    the main features
                                                    are the ones
                                                    presented and only
                                                    minor changes are

                                               30 / 43
IST-27074 SAPHIRE                                              D.9.1.1

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

                                                                    31 / 43
IST-27074 SAPHIRE                                             D.9.1.1

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

                                                                    32 / 43
IST-27074 SAPHIRE                                                      D.9.1.1

4 Homecare Pilot Application Operational Medical
4.1.1 Rehabilitation of the inpatient

Within the cardiac rehabilitation program the patient shall learn to know his
individual cardiovascular risk constellation. There are risk factors that can not be
changed: disposition to develop coronary artery disease, age, and gender. Other risk
factors can be changed: smoking, diabetes mellitus, arterial hypertension,
hyperlipidemia, adiposity, and the lack of exercise training.

Exercise training (ET) is on the one hand the treatment of one important risk factor
and is on the other hand an effective tool to support the improvement in the other
above mentioned risk factors. Additionally it enables the patient himself to take part
in the treatment and in secondary prevention of his cardiovascular disease. He is not
only treated by drugs, operations or catheter interventions, but he can also be active.

The data of this exercise test will be used to calculate the recommended heart
frequency during the aerobe exercise-session, called training-pulse. Also the cut-off
level for the training-intensity (e.g. maximum watt) should be fixed.

The exercise prescription is made by the responsible physician. He documents
intensity, frequency and duration of the ET-program. Then the trainer, who supervises
the training of the inpatients, will start the ET-program. The patient will do the
training session on the SAPHIRE-bicycle, that has been programmed with the ET-
prescription data, especially trainings-pulse and resistance. Exercise training starts
with 1-2 exercise-sessions per day of lower intensity, with gradual increase in the
duration of the sessions within the limits of the exercise prescription.

The other SAPHIRE hardware components to measure bodyweight, oxygen
saturation, blood pressure, and heart frequency will be used during every training-
session. In this setting the alert thresholds will be programmed, so that the MSHCP
can start working under direct supervision.
After establishing an individual threshold-setting the patient will be able to go home
in order to continue the ET under the advice of the alert-agents and the MSHCP. He
will be informed about the threshold-values and he will know, what to do in case of
yellow or red alarm.

If the patient is able to perform ET without any relevant problems during the three
weeks of the inhouse rehabilitation, he should also be able to continue his ET at
home. He will receive a detailed instruction about the training prescription to take
home. On behalf of secondary prevention it is most important, that the patient
continues the ET at home. In order to keep him training and to improve his
compliance we will continue the rehabilitative treatment in form of the outpatient-ET-

                                                                            33 / 43
IST-27074 SAPHIRE                                                        D.9.1.1

4.1.2 Secondary prevention of the outpatient

A total observation period of three months is planned for four patients. 40 minutes
training five times a week according to the specifications should be completed.
During this time the ergometer performance as well as the heart and breathing
frequency is continuously recorded. Intermittently, a 12 led ECG is recorded at rest,
30 minutes after exertion, as well as 1, 5 and 10 minutes after the exertion phase.

Intermittently, the blood pressure is recorded at rest, after each 10 minutes of exertion
as well as 5 and 10 minutes after the end of the exertion phase.

The thresholds of all parameters are set individually. The acceptable zone of values is
defined as the “green zone”. The so called “yellow zone” of values will be defined as
the relative alarm zone, which alarms the patient to stop the exercise and to control
the parameters at the resting period. The so called “red zone” is the absolute alarm
zone, which advises the patient to go to the practitioner the next day. If the patient
feels under par he will be advised to go to hospital immediately.
The applicable stop criteria for the ergometer training are angina pectoris, shortness of
breath, as well as increasing malaise. The patient can stop at any time when these
symptoms occur but must activate the red signal by himself. After normal completion
of the training a subjective view of the degree of exertion according to the modified
Borg scale is recorded by the patient on a hand held console.

A continuous data acquisition is planned for the duration of the exercise training.
After the training has been completed the set of data should be sent to the central
office at the SSK, where the evaluation is performed within 24 hours. If irregularities
in the training data are noted when it is evaluated then the responsible investigator of
SSK will notify the patients and give them appropriate instructions.
The transmission of the 12 Channel-ECG-Data also occurs after every training
programme, and will be evaluated in the SSK. If respective ECG irregularities are
diagnosed then the SSK will also get in contact with the patient.

4.1.3 Alarms and exceptions
The demands on the HomePA Clinical Decision Support System differ to the
demands on the HospitalPA Clinical Decision Support System: In the HomePA the
decision is first given to the patient, in contrast to the HospitalPA, in which the
decision is given to the clinician.


A medical alert should be real-time generated and first be transmitted to the patient.
The patient and his spouse or partner must be trained extensively in deciding the
procedure after an alert during exercise training. If no life threatening condition
enforces admission to a hospital, every alert should also de assigned and interpreted
by the SSK. After every alert the cause must be discussed with the patient.
Electronic alerts should deliver a very simple message in a way that prevents
physicians from bypassing them in daily practice(2). For this reason, such decision
support should be limited to selected high-risk events for which key decisions are

                                                                              34 / 43
IST-27074 SAPHIRE                                                      D.9.1.1

Usually, electronic alerts can be graded in three categories:
      Green alerts: they indicate that all parameters are within the threshold, no
       danger condition.
      Yellow alerts: these are alerts indicating the appropriate parameter´s range is
       out of normal, but do not require emergent action. If a yellow alert is given
       twice at rest (repetitive measurement within 5 minutes), the patient will not
       begin with exercise training and is advised to contact his physician at SSK. If
       a yellow alert is given during exercise training, the performance of the
       exercise bicycle will be reduced automatically. If the yellow alert does not
       disappear within 5 minutes it will change to the red alert and the exercise
       training will be stopped immediately and automatically.
      Red alerts: these are given if conditions such as to high or to low blood
       pressure, new onset of supraventricular or ventricular arrhythmias, atrial
       fibrillation, atrial flutter, SA- or AV-block, complete right or left bundle
       branch block, significant ST-segment deviation (especially signs of acute MI),
       SpO2<95% (according to individual limits) at rest or under exercise lead to an
       interruption of the performance on the exercise bicycle and the patient will be
       advised to stop immediately. In addition, if the patient suffers from continuous
       chest pain, dizziness or other discomfort he will be advised to get admitted to
       a coronary care unit.

In the SAPHIRE System, there will be at least two types of alerts to be generated by
the system:

  1. Local alert system: Alerts coming from the sensors and alert the patient using a
     decision support system;
  2. Central alert system: Alerts coming from the Home Pilot Applications and alert
     the SSK for further decision making.

1. Alerts coming from the sensors could be the following:

      ECG alerts:
         o HR alerts:
                 Bradycardia
                 Tachycardia
                 HR change
                 Irregular HR
                 Asystole
                 Artefact
         o Arrhythmia alerts:
                 Supraventricular and ventricular arrhythmias
                 Atrial fibrillation
                 Absolute arrhythmia with atrial flutter
         o Intracardiac block alerts:
                 SA-Block II°-III°

                                                                            35 / 43
IST-27074 SAPHIRE                                                        D.9.1.1

                  AV-Block I°-III°
                  complete right or left bundle branch block
           o ST - segment deviation alerts:
                  ST - segment depression
                  ST – segment elevation / signs of an acute myocardial

      Blood pressure (BP) alerts:
          o High BP
          o Low BP
          o Non-detectable BP
          o Artefact

      Pulse oximeter alerts:
          o Low oxygen saturation (SpO2)
          o Non-detectable SpO2
          o Artefact

      Respiratory rate alerts (optional):
          o Respiratory rate out of range
          o Artefact

      Alerts from the exercise bicycle
          o After identification of the patient = ready to start
          o End of exercise
          o Speed too low/to high
          o Yellow alert = slow down
          o Red alert = stop immediately (resistance will be switched off)

      Event alerts coming from the patient:
          o Chest pain alert
          o Dyspnea alert (“shortness of breath”)
          o Palpitations alert

The alarms/alerts coming from the sensors are depending to a large degree on the type
of sensors to be used by the SAPHIRE system. For the optional 12-lead ECG system
diagnostic of ischemic events and location algorithm based on ECG leads could also
be available and therefore some new alerts could be defined like “acute ST-depression
or elevation.

In addition to an objective evaluation of the patient’s state of health based on the data
generated during individually adapted exercise training the subjective patient’s state
of exhaustion shall be documented by a rating of perceived exertion (RPE).

There are a number of RPE scales but the most common is the Borg’s 15 point scale
(6-20), illustrated below. Borg’s Rating of Perceived Exertion (RPE) is based on a
subjective feeling of exertion and fatigue during exercise. The patient will give a
numerical value on a scale from 6 to 20, representing a verbal expression of effort
during exercise.

                                                                              36 / 43
IST-27074 SAPHIRE                                                      D.9.1.1

4.1.4 Report of the training results
At the end of each exercise training a report should be generated containing the
actually relevant training data as well as a trend analysis considering the data of all
already performed training sessions. The data should be presented in form of tables
and graphics.

A report should contain in detail:
1. Patient identification data derived from the central data base:
        - Name, first name, date of birth etc.
 2. Training data:
        - Consecutive training number
        - Date and time of start and end of training session
        - Type of training: exercise training (bicycle ergometer)
        - Method of training: permanent load with 3 minutes (each) „warm up“ and
            „cool down“ at 50 % of the training load
        - Training program: Load-controlled or controlled by heart rate
        - Number of training sessions per week, average duration, average duration
            per week
        - Average heart rate per training session (or additionally minimum and
            maximum heart rate for load-controlled training)
        - Average performance (or additionally maximum and minimum
            performance for heart rate controlled training)
        - Average speed (RPM) as well as minimum and maximum speed per
            training session
 3. Anamnestic medical data:
        - Since last training session occurrence of complaints?
        - Complaints concerning heart, respiration, muscles; cold, infections or other
        - Contact to a physician?
        - Hospitalisation?
        - Was the current medication taken as planned?
        - Change in medication?
        - Technical problems during last training session?
        - Regular Stop of last training session? Specific complaints, exhaustion,
            interruption, lack of motivation?
4. Actual medical data:
        - Heart rate at rest, average heart rate, minimum heart rate, maximum heart
            rate, heart rate at recovery (5th minute after exhaustion)
        - Blood pressure at rest, average blood pressure, minimum blood pressure,
            maximum blood pressure, blood pressure at recovery (5th minute after
        - SpO2 at rest, average SpO2, minimum SpO2, maximum SpO2, SpO2 at
            recovery (5th minute after exhaustion)
        - Respiratory rate at rest, average respiratory rate, minimum respiratory rate,
            maximum respiratory rate, respiratory rate at recovery (5th minute after
        - Automatical ECG-validation (heart rhythm, rhythm disorder, ST - segment
            deviation etc., depending on compulsory 3-lead-ECG or optional 12-lead-
5. Patient’s assessment after exhaustion

                                                                            37 / 43
IST-27074 SAPHIRE                                                       D.9.1.1

       -    Borg-Scale (level of exhaustion)
       -    Complaints (palpitations, dyspnea, nausea, dizziness, muscle-exhaustion,
            other complaints)
6. Actual individual thresholds (according to individual definition)
        - At rest: heart rate, blood pressure, SpO2, respiratory rate and ECG
        - At stress: heart rate, blood pressure, SpO2, respiratory rate and ECG
        - At recovery: heart rate, blood pressure, SpO2, respiratory rate and ECG
 7. Documentation of triggered alerts
        - Technical alerts (concerning sensor function and /or placement)
        - Measurement alerts (single parameters)
        - ECG alerts
        - Alerts caused by patient documentation
 During a single training session as well as for all already performed training sessions
 relevant training data, medical data and alert data should be presented graphically.

                                                                             38 / 43
IST-27074 SAPHIRE                                                         D.9.1.1

 4.2 Testing Environment for Hospital Pilot Application

       Sensor Network


                            MSHCP                              MSHCP

     Patient Display                                                       Physician GUI/

     Patient’s Home                                           Clinic

                        Figure 3 SAPHIRE System Architecture (Overview)

On the left hand sight of the figure, the patient’s home is seen, that is connected to the
clinic (on the right hand side) through the internet. On both sides, the MSHCP (Multi-
Services Homecare Platform) takes a central role in connecting the system
components. In the patient’s home, the sensors are connected with the MSHCP, as is
the patient’s display that is affixed to the ergometer bike.

The connection between the sensors and the MSHCP is established wirelessly, using
Bluetooth technology. In the homecare scenario, the sensors deployed will measure
the oxygen saturation, the blood pressure, and they will acquire ECG data. Since a 12-
lead ECG is probably not feasible, only three leads will be used. The respiratory rate
will either be derived from the ECG, or from the plethysmogram (as described in
Error! Reference source not found.Error! Reference source not found.), or (if
these methods are not robust enough) by deploying a fourth sensor to measure the
respiratory rate directly.

The MSHCP deployed at the hospital side renders the output for the Physician GUI
(the Real-Time Viewer used by physicians to get a live display of the sensor data).
Also, the results of a training session will be condensed into a training report that will
be exported to the EHR (Electronic Health Record) where physicians can access it.
The latter access will be the standard scenario, since patients in the homecare scenario
are not critical enough to warrant real time monitoring at all times.

                                                                               39 / 43
IST-27074 SAPHIRE                                                           D.9.1.1

4.3 Hardware Specifications
4.3.1 Ergometer Bike

In the Homecare Scenario, the daum electronic “ego_bike medical8” bike is used.
The specifications follow:
Big illuminated colour screen with a resolution of 320*240 pixels
Integrated 32 bits 266 MHz processor with 64MB of RAM
64 MB flash memory (>40 MB free for future applications
Software update by means of the memory card
128 MB SD memory card included
USB connector optional, for future applications
Network and Internet connections optional
Stereo playback over headphones, integrated loudspeakers or external amplifier
Playback of mp3 music tracks saved on the memory card
Integrated help system with keywords index
Display of: braking power in watt, training time, distance, heart rate and aerobic heart rate
zone, speed, RPM or step rate, maximum and average values, time and date, BMI, weight and
body fat content curves
Playback of mp3 music tracks saved on the memory card
Multilanguage user directions (D, E, F, I)
Physical energy dissipated in kJoule and kcal
Programmable limit values for: watt, heart rate, kJoule, time, km, elevation as well as idle
time and time windows
Storing of all personal data (name, address, weight, body fat content, medical advice
Coded heart rate measurement via a Polar receiver
Carecard2 capability for training under medical supervision
Manual watt load control as well as watt-controlled fixed programs and performance tests
(WHO, Conconi, PWC)
Manual Cardio program as well as heart rate controlled fixed programs
RPM or speed controlled manual and fixed programs
Torque controlled strength program
generation of any number of your own training programs
Graphical comparison of a current training session with a previous reference training session
Saving of all the training data to the memory card at a resolution of one second
Graphical display of all the data (watt, heart rate,...) for every single training session
Fitness measurement and evaluation
Braking power 20-1000 Integrated performance measurement for the bike models
Standard handlebars/pedals and saddle position
Safety class 1 with safety guide
Manual level adjustment
Weight carrying capacity 150 kg Manufactured acc. to DIN EN 957-1
Manufactured acc. to DIN EN 957-5, VDE 0750-238, ICE EN 60601-1
Dimensions (L x W x H in cm) 97/54/125
Weight 45kg

                                                                                 40 / 43
IST-27074 SAPHIRE                                                    D.9.1.1

4.3.2 Panel PCs

In order to provide the patient with more comfortable means of communication with
the system, a panel PC has been mounted to the ergometer bike. This allows the
patient to interact with the system using a big touchscreen. Error! Reference source
not found.Error! Reference source not found. shows the ergometer bike with a
panel PC mounted. The panel PC is equipped with a 17” TFT touch-screen, a 2.8GHz
Intel Celeron CPU, 512MB RAM, a 80GB HDD and a CDRW/DVD drive.

                              Picture 4 Ergometer Bike

                                                                          41 / 43
IST-27074 SAPHIRE                                                     D.9.1.1

5 Conclusions

This is the first of a series of three deliverables dedicated to Pilot application
validation. In this first report we present the SAPHIRE assessment “recipe” and all
the necessary ingredients for a successful application assessment.

We conceptually view the activities belong to work package 9 as the final linchpin in
the chain of all assessment-evaluation-validation activities held in work package 3
referring to Software and Architecture evaluation of our proposed system.

We continued this legacy framework which had been identified early on, and in each
assessment, towards this of final system’s, we take advantage of the previous
assessment findings, and thus, we explore our evaluation framework in an incremental
manner, giving to the consortium and (we hope to external readers) the opportunity to
catch the steps carried out. Hence, by exploiting the user oriented metrics and
measurements (applicable to the Pilot application operational scenarios), we were able
to provide a link to our SAPHIRE “User Acceptance” assessment criteria.

This 9.1.1 issue, will pave the way to the second report 9.2.1– to be produced in
month 30 – this of the actual validation of the pilot applications.

                                                                           42 / 43
IST-27074 SAPHIRE                                               D.9.1.1

6 References

[1] PD ISO/IEC TR 9126-4:2004, Britsh Standards (BSI) Standard Quality in Use

[2] ISO/IEC DIS 14598-1:1996, Information Technology - Software Product
Evaluation - Part 1: General Overview

[3] IEEE 1061-1992, 1992. IEEE Standard for a Software Quality Metrics

IEEE 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology

                                                                     43 / 43