Post on 17-Mar-2020
UNIVERSITY OF COIMBRAFACULTY OF SCIENCES AND
TECHNOLOGY
REMOTE VITAL SIGNS MONITORING
Software Module
Rafael Resendes Simões
Master's Degree in Biomedical Engineering
1 September 2008
Rafael Simões Page 2 of 76
Versions
Version Description Date
0.1Create the Original
Document 28 August 2008
0.2 Create the Final Document 1 September 2008
Rafael Simões Page 3 of 76
Acknowledgements
First of all, I would like to thank my family for all the support given during this important
phase of my life.
Secondly, I would like to express gratitude to the supervisors and to all the people who have
contributed with their participation beyond the supervisor’s scope. My gratefulness to the
Software Department at ISA goes beyond words; I am deeply grateful for the knowledge,
friendship and patience shared along the process.
I would like to thank Eng. Lara Osório, for the entrepreneurship spirit transmitted to the
project development and her help throughout the whole process. I also would like to thank Eng.
Jorge Landeck, who, along with Eng. Lara Osório, was responsible for the thesis revision.
Finally, I must have an appreciation word for the availability demonstrated by Doctor
António Travassos, and his group, helping to improve the project, allowing me to have a
concept closer to the medical reality.
Rafael Simões Page 4 of 76
Resumo
O sistema Sinais Vitais permite monitorizar, em tempo real e remotamente, os sinais vitais
de uma determinada pessoa de um modo não invasivo e portátil. Esta característica, associada
com a funcionalidade de elaborar relatórios com a informação dos sinais medidos, permite
afirmar que este sistema e a sua arquitectura podem contribuir para aproximar de um modo
proactivo a saúde dos pacientes.
Este tipo de sistemas têm-se afirmado de uma importância fundamental em sociedades com
altas taxas de envelhecimento porque permitem recolher grandes quantidades de dados médicos
com a utilização de poucos recursos aumentando dessa maneira a eficácia da relação saúde -
custo.
Este documento tem como objectivo enquadrar o sistema e as diferentes fases percorridas
para a sua implementação.
Abstract
The Vital Signs system allows to monitor, in real time and remotely, the vital signs of a
person in a non invasive and portable way. This feature, as well as, the functionality of
elaborating reports containing the information of the measured signs enables to state that this
system and its architecture will certainly contribute to bring health closer to the patients in a
proactive way.
These systems have been recognized as being of an extreme relevance to societies in which
the aging rate is high, since they allow to collect enormous amounts of medical data using few
resources increasing, thus, the efficiency of the health – price relation.
The purpose of this document is to enunciate the framing of the system and the different
steps taken towards its implementation.
Rafael Simões Page 5 of 76
Acronyms
AJAX Asynchronous Javascript And XML
C# CSharp
CCC Coimbra Surgical Center
CEI Electronics and Instrumentation Group
DT Day
EDR Enhanced Data Rate
GDP Gross Domestic Product
GPS Global Positioning System
HL7 Health Level Seven
HO Hour
HP Hewlett-Packard
HR/CF Heart Rate/ Cardiac Frequency
ISA Intelligent Sensing Anywhere
MIN Minute
MTH Month
PAN Personal Area Network
PDF Portable Document Format
RM ReportManager
ROI Return of Investment
SEC Second
SIG Special Interest Group
UWB Ultra Wide Band
VS2005 Visual Studio 2005
VS2008 Visual Studio 2008
YR Year
Rafael Simões Page 6 of 76
List of Figures
Figure 1 – Global aspect of Vital Signs.......................................................................................11
Figure 2 – Projected change in public spending on total age-related expenditures between 2004
and 2050; percent of GDP............................................................................................................22
Figure 3 – Equipment and demonstration of CardioScout...........................................................24
Figure 4 –Architecture of BodyKom Series ECG........................................................................25
Figure 5 –HHRM.........................................................................................................................26
Figure 6 – Wrist Units..................................................................................................................27
Figure 7 - VitalPoint.....................................................................................................................28
Figure 8 – Range versus Data Rate of Common Wireless Technologies....................................36
Figure 9 – Physical Scheme of VitalSigns...................................................................................42
Figure 10 – Physical Architecture of VitalSigns..........................................................................43
Figure 11 – General Logical Architecture....................................................................................43
Figure 12 – Logical Architecture.................................................................................................44
Figure 13 – Basic Flowchart of P1...............................................................................................45
Figure 14 – Main Organization of the Web Pages (Example of the Patients Page).....................49
Figure 15 – Map Site of theVital Signs Web Application...........................................................49
Figure 16 – Help Box in the Patients Page...................................................................................50
Figure 17 – Error message (E=Error; M=Monitoring; 4=Error Code)........................................51
Figure 18 – Help Page..................................................................................................................51
Figure 19 – Operation Mode of Retrieving Information From the Database (Example
GetPatients)..................................................................................................................................52
Figure 20 – Flowchart of Protcol.cs.............................................................................................56
Figure 21 – General Architecture of the Services Module...........................................................57
Figure 22 – Window to Elaborate New Report............................................................................58
Figure 23 - Report Contents.........................................................................................................59
Rafael Simões Page 7 of 76
List of Tables
Table I – Students and Supervisors.........................................................................................14
Table II – General Scheduling................................................................................................16
Table III – Scheduling for First Semester...............................................................................17
Table IV - Scheduling for Second Semester – Part I..............................................................18
Table V - Scheduling for Second Semester – Part II..............................................................20
Table VI – Technical details of CardioScout..........................................................................24
Table VII – Features of Products related to the State of the Art.............................................30
Table VIII – List of Requisites of VitalSigns – Software and their dependencies.................40
Table IX – Entities of VitalSigns Database............................................................................47
Table X – Messages................................................................................................................54
Table XI – Measurement Messages........................................................................................54
Rafael Simões Page 8 of 76
Index
Versions 2
Acknowledgements 3
Resumo 4
Abstract 4
Acronyms 5
List of Figures 6
List of Tables 7
Index 8
1. Introduction 11
1.1. Objective..................................................................................................................11
1.2. Scope........................................................................................................................12
1.3. Audience...................................................................................................................12
1.4. The Document Structure..........................................................................................12
2. Project Planning and Management 13
2.1. Entities involved in the project.................................................................................13
2.1.1. ISA...................................................................................................................13
2.1.2. CEI....................................................................................................................13
2.1.3. CCC..................................................................................................................14
2.2. Team.........................................................................................................................14
2.3. Knowledge Acquisition............................................................................................14
2.4. Scheduling................................................................................................................16
3. Related works 21
3.1. Background Problem................................................................................................21
3.2. State of the Art.........................................................................................................23
3.2.1. BodyKom.........................................................................................................23
3.2.2. IER....................................................................................................................25Rafael Simões Page 9 of 76
3.2.3. WirstClinic.......................................................................................................26
3.2.4. VitalPoint.........................................................................................................28
3.3. Review of our System..............................................................................................30
4. Requirements Analysis 32
4.1. Acquisition Solution.................................................................................................33
4.1.1. Pulse Oximeter.................................................................................................33
4.1.2. Why an Oximeter?............................................................................................34
4.1.3. Acquisition Module..........................................................................................34
4.1.4. Communication between Oximeter and Acquisition Module..........................34
4.1.5. Why Bluetooth?................................................................................................35
4.2. Datacenter.................................................................................................................36
4.2.1. Database...........................................................................................................37
4.2.2. The Web Application.......................................................................................37
4.2.3. Services............................................................................................................38
4.2.4. ReportManager.................................................................................................39
4.2.5. Requisites Dependencies..................................................................................40
5. System Architecture 41
5.1. Physical Architecture...............................................................................................41
5.2. Logical Architecture.................................................................................................43
6. Software Development 47
6.1. Database Design.......................................................................................................47
6.2. The Web Application Design...................................................................................48
6.3. Services....................................................................................................................53
6.4. Report Manager........................................................................................................58
7. Tests 60
8. Conclusion 61
8.1. Future Works............................................................................................................62
8.2. Final Appreciation....................................................................................................65
9. Bibliography 66Rafael Simões Page 10 of 76
10. Annexes 69
10.1. UserGuide (Detached)..........................................................................................69
10.2. Tests (Detached)...................................................................................................69
10.3. Database Specification (Detached)......................................................................69
10.4. Session Document................................................................................................71
10.5. Report Example....................................................................................................75
Rafael Simões Page 11 of 76
1. Introduction
1.1. Objective
This project aims at building a system to acquire and visualize, physiological parameters of a
patient remotely and in real-time. Bearing this vision in mind, an architecture which is
composed by a solution acquisition that is continually sending monitored vital signs to a
datacenter where the monitored data is interpreted and saved must be designed.
The acquisition phase is possible through the use of multiple sensors which measure vital
signs in a non invasive way. During the acquisition process, the measurement data is routed to a
server via wireless and can be visualized through the use of a dedicated web application.
Besides visualization in real-time, the project provides a reporting service, which is responsible
for showing in an interactive and user-friendly way the measurement data and general aspects
concerning the supervision.
In order to achieve this goal, the project was split into three main modules: Hardware,
Firmware and Software each one with its own specificities. The student was responsible for the
Software module and has the objective to provide a supporting platform which enables to store
and view vital signs.
Figure 1 – Global aspect of Vital Signs
Rafael Simões Page 12 of 76
1.2. Scope
This project was developed in a master’s degree of Biomedical Engineering taught at the
University of Coimbra in the academic years 2007/2008. It is the result of a partnership between
ISA, Intelligent Sensing Anywhere, CCC, Coimbra Surgical Center and CEI, Electronic
Instrumentation Center.
1.3. Audience
This document is mainly addressed to the supervisors and juries assigned to this project and
the academic circle around biomedical engineering and informatics.
1.4. The Document Structure
The present document follows a logical division by modules. It is composed by eight
chapters:
1. Introduction – Presentation of the problem and a general approach of its
objective;
2. Project Planning and Management – The team, involved entities, the knowledge
acquisition and the scheduling related to the project will be herein described;
3. Related works– General view of the remote vital signs market and its products;
4. Requirements Analysis – Detailed description of the several requirements that the
system must have. Besides, the main features that the prototype must have will be
herein enunciated;
5. System Architecture – The physical and logical architecture defined in the
system;
6. Software Development – Implementation steps regarding the software
development;
7. Tests – Test Specification;
8. Conclusion – Final impressions and the future work concerning the system.Rafael Simões Page 13 of 76
2. Project Planning and Management
2.1. Entities involved in the project
2.1.1.ISA
ISA, Intelligent Sensing Anywhere, is a leader company in the telemetry market with
solutions spread all over the world. It was the most important partner in this project because of
the human resources made available. Furthermore, it made possible the student integration
among its software team who were very helpful in the planning and implementation of the
application. The stay of the student at ISA lasted 4 months.
Entity Name Main Responsible E-Mail Website
Intelligent Sensing Anywhere Engineer José Basílio info@ isalabs .com http://www.isa.pt/
2.1.2.CEI
CEI, Electronic Instrumentation Center, is a research group of the Physics Department of the
University of Coimbra (UC). Its research covers many areas, such as Atomic Instrumentation or
Biomedical Instrumentation, and has as close collaborators some national and international
partners who are worldly recognized as experts in their fields. CEI was the connection between
ISA and UC. It was there that students learned new concepts and integrated into the system
idea. Professor Carlos Correia, the headman at CEI, made their knowledge available and helped
in the development of hardware and firmware.
Entity Name Main Responsible E-Mail Website
Electronic Instrumentation Center Professor Carlos Correia correia@lei.fis.uc.pt http://
lei.fis.uc.pt/
Rafael Simões Page 14 of 76
2.1.3.CCC
The Coimbra Surgical Centre (CCC) is a private health unit situated in Coimbra. It is a
complement to the existing health institutions within the central region of Portugal and
comprehends diverse medical areas, such as ophthalmology or cardiology, among many others.
Entity Name Main Responsible E-Mail Website
Coimbra Surgical Center Doctor António Travassos info@ccci.pt
http://www.ccci.pt
2.2. Team
This project was carried out by three students with the help of their respective supervisors. It
was divided into three main modules, Hardware, Firmware and Software, each one with their
own architecture and features. Besides the supervisors, Engineer Catarina Pereira had an
important role on this assignment because she was the project planner.
Table I – Students and Supervisors
Name Module(s) Contact
Stud
ents
Nuno Varelas Firmware nunomsv@gmail.com
Rafael Simões Software rrsimoes.ebm@gmail.com
Tomé Matos Hardware tomermatos@gmail.com
Supe
rvis
ors
Professor Carlos Correia - CEI Hardware;Firmware correia@lei.fis.uc.pt
Professor Jorge Landeck - ISA Software jlandeck@isa.pt
Professor José Basílio Simões - ISA Hardware;Firmware jbasilio@isa.pt
Engineer Lara Osório - ISA Software losorio@isa.pt
Engineer Paulo Santos - ISA Hardware;Firmware psantos@isa.pt
2.3. Knowledge Acquisition
The knowledge that the student had to acquire comprehends concepts of software
engineering in order to evaluate the needs of the system and to design an architecture that
embraces these requirements and also concepts of programming languages, like C# or SQL, and
the tools to handle their writing.
Rafael Simões Page 15 of 76
In the first phase of this project the best architectural approach concerning the system was
studied and after the conclusion of this process, the student went on to the implementation
process.
The student had to learn to take advantage of the enormous possibilities offered by Visual
Studio 2005 © supported by .NET framework 3.0. His first experience with this tool consisted
of a windows application which allows to monitor, with a graph, the three axis of an
accelerometer connected via RS-232. Afterwards, and already within the scope of Vital Signs,
the student had to probe his knowledge of web technology. This proved to be the most difficult
step in this project because the ocean involving web concept is very vast.
At approximately the middle of the project, the student upgraded VS2005© to VS2008©,
using now .NET Framework 3.5. In the development of the web application the student felt the
need to improve the user interaction. This was achieved with the help of AJAX. This framework
enables partial post backs, decreasing, thus, the response time of the interface to the actions of
the user, among many other functions. Besides AJAX, the concept of style sheets was able to
provide the user a more friendly visualization. Furthermore, and concerning visualization of
measurement data, the student came into contact with the ChartDirector library which allows
the building of charts in a flexible way.
In developing the database, the student learned many concepts like stored procedures and
triggered and deepened his familiarity within Microsoft SQL Server 2005©, a relational
database management system. Furthermore, and still in Microsoft SQL Server 2005© field, the
student had to learn Reporting Services 2005©, a server-based solution that enables the
creation, management, and delivery of both, traditional paper-oriented and interactive reports
(1).For implementing a real-time solution the student learned Web Services and their many
potentialities. It was also in this task that the student came in contact with JavaScript and
Windows Services.
In conclusion, the student was confronted with new technologies several times during the
project. This was not seen as a barrier to the project advance. On the contrary, all problems
which occurred within the scope of this project were seen as challenges and steps to climb to
reach the best possible solution.
Keywords: Microsoft Visual Studio 2005©; Microsoft Visual Studio 2008©; .NET
Framework 3.0; .NET Framework 3.5; C#; Web; AJAX; Microsoft Sql Server 2005©; Sql
Server 2005 Reporting Services©; Web Services; Windows Services; Web Design – Style
Sheets; ChartDirector
Rafael Simões Page 16 of 76
2.4. Scheduling
Table II – General Scheduling
Legend for Tables III;IV and V:
[1] – Paulo Santos [7] – Acquisition Module
[2] – Catarina Pereira [8] – Solution of a Windows Application – First Skin of VitalSigns
[3] –Emeline Gonçalves [9] – Solution of a Windows Application – Learn concepts related with TCP/IP
[4] – Tiago Marçal [10] - Coimbra Chirurgical Center
[5] – José Luís Malaquias [11] – Web Application
[6] - Datacenter [12] – C# Class
Rafael Simões Page 17 of 76
Table III – Scheduling for First Semester
Rafael Simões Page 18 of 76
Table IV - Scheduling for Second Semester – Part I
Rafael Simões Page 19 of 76
Table V - Scheduling for Second Semester – Part II
Rafael Simões Page 20 of 76
3. Related works
3.1. Background Problem
In this chapter the market of remote health care, as well as, our motivation for developing a system within
this area will be analyzed. Furthermore, a description of some products within this market, each one with its
own specific features, will be given. A good understanding of key functionalities and characteristics of these
systems, and of the market involved, can give us a different perspective of ours. Finally, a brief description of
functions shared by our system and how it stands out from other products will be given.
Aging in the European Union
According to the United Nations, aging throughout the World is gradually becoming one of the most
relevant social, economic and demographic phenomena of our times (2). In Europe, the region's old-age
dependency ratio (the number of people who are 65 and over in relation to those between 15 and 64) is
projected to double to 54 percent by 2050,which means that the EU will change and instead of having four
working people for each elderly person, it will have only two people (3). There are three major reasons for this
scenario: low fertility rates, which are projected to remain the same; baby boomers [Person who was born
during post-World War II, between 1946 and 1960] who are starting to retire will lead to a transitory increase
and the continuous progress of life expectancy, which has increased 8 years since 1960, is expected to
increase five years for both male and female, by 2050.
In Portugal, this situation is no less alarming. As it can be observed from Statistics Portugal Institute (INE)
studies, for each 100 juveniles there are 109 elders. This situation is very disturbing because it reflects an
inversion of the demographic pyramid. Unfortunately, the future will not bring good news as the situation is
becoming worse with the perspective of a contraction in the younger sector and an expansion in the older one.
This scenario, which is already being lived in Europe, has repercussions in the social, political, financial
and health circles. First of all, and perhaps the most relevant aspect is that the aging of working people will
decrease in comparison to the elderly. Nevertheless, politicians have been working on this problem and some
changes to the legislation; which will at least soften the problem, have been made; namely the increasing of
the retirement age. However, many of these changes bash in a wall of public discontentment. Secondly, this
situation will bring a huge pressure on social security models implemented all over Europe because its
workforce will have to support a rapid expansion in the number of retirees. This results in a sharp rise of
Rafael Simões Page 21 of 76
public costs, because of pensions and health expenses, with Portugal as the penultimate country of the EU
which will increase more their age-related public expenses [Figure 2].
Legend: PL=Poland; EE=Estonia; LV= Latvia; AT=Austria; MT=Malta; LT= Lithuania; IT=Italy; SE=Sweden; DE= Germany;
SK=Slovakia; FR=France; UK= United Kingdom; DK= Denmark; NL=Netherlands; FI=Finland; BE= Belgium; HU=Hungary;
CZ=Czech Republic; IE=Ireland; LU= Luxembourg; ES=Spain; SI= Slovenia; PT= Portugal; CY=Cyprus. Source: European Policy
Center and European Commission (2005)
Figure 2 – Projected change in public spending on total age-related expenditures between 2004 and 2050; percent of GDP [Gross
Domestic Product]
How can remote health care help in this process?
With an annual expenditure rate exceeding billions of euros worldwide, healthcare providers have to start
looking for ways to improve the cost effectiveness of care. This reduction cannot be made at the expenses of
healthcare outcomes. The best solution for this problem is to invest on information technologies which can
provide a health care technology at a lower cost, in comparison with the present situation, maintaining, or
even improving health care outcomes. This idea is transmitted in a citation by Janani Narasimhan, analyst
from Frost & Sullivan: “[Remote Patient Monitoring] RPM has the potential to change the way patients
manage their own conditions so that they become the keepers of their own healthcare.”
There is one example, among many others, that has proved the advantages of using remote technologies on
this market - the monitoring of heart failure patients (4) - it was observed that the use of this connected health
care device is responsible for the reduction in mortality, without using less healthcare resources because the
patient does not need to be in the healthcare facility. Furthermore, distributions of products based on a remote
notion will incentive a preventive health system because it facilitates the monitoring process. This is a very
important aspect because it tries to avoid chronicle diseases and, at the same time, it reduces public expenses
according to Sten Lindgren, Medical Doctor at Globenhälsan in Nynäshamn-Sweden - “We know that in the
Rafael Simões Page 22 of 76
health services, each USD invested in preventive health care saves us six USD in medical care and health
insurance.”
Telehealth Care Market
The telehealth care market is a relative new area of business that is very appealing for a wide range of
companies. These companies offer products that are very different among them but with one aspect bringing
them all together – remote vital signs monitoring. This vision is shared from new Nintendo console until more
sophisticated controls like WirstClinic from TelComed.
A study from Frost & Sullivan, an international consulting firm (5), stated that innovation and advanced
technology continue to play a significant role in the remote patient monitoring market, making available
devices increasingly attractive. However, the limited reimbursement offered by European governments is
dampening the market potential. As Janani Narasimhan, said “A critical challenge is governments' refusal to
reimburse remote monitoring of patients.” Despite this restrain, the market is growing stimulated by the aging
people and the related increase in chronic diseases. Frost & Sullivan has found that the European market
earned revenues of U.S. $175 million (1,16 x108 € (6)) in remote care in 2007 and it is foreseen to reach $400
million (2,65x109 € (6)) by 2014 (5).
In conclusion, with hospitals and health centers exceeding their capacity, the aging of the population
increasing exponentially, and other restrictions, governments and companies related to healthcare need to
focus in products that can supervise remotely the vital signals of patients maximizing, thus, the relation
between costs and healthcare outcomes. The impact of telehealth care seems to be very promising (4) - patient
empowerment, cost reductions, improved efficiencies and quality of care.
3.2. State of the Art
3.2.1.BodyKom
BodyKom is a system commercialized, since 2006, by Kiwok (Sweden) with HP as the major business
partner. In June 2006 it was tested in Karolinska University Hospital in Sweden for technical, medical and
economical evaluation with extreme success. Since then, it has been expanded to countries like India or
Norway (7). Although the first experience took place in a hospital, the BodyKom is intended for
diagnostic/investigation of pre-hospital patients and for monitoring /follow up of chronic diseases. It can
Rafael Simões Page 23 of 76
connect wirelessly sensors to the patient and if dangerous changes are detected health care services are
automatically alerted. Besides the vital signs, the health care service can visualize the geographic position of
the patient through the use of GPS technology.
Currently, the equipment of this product consists of [Figure 3]:
A. ECG Electrodes
B. Sensor
C. Smart Mobile Phone
D. Battery charger for sensor and another one for mobile phone
Figure 3 – Equipment and demonstration of CardioScout
The sensor is called CardioScout and is commercialized by PicoMed (8). It is a 2-channel long-term ECG
recorder that weights less than 40 gr and allows measurements for 24 up to 120 hours. All the technical details
can be seen in Table VI.
Table VI – Technical details of CardioScout
Rafael Simões Page 24 of 76
Picomed also makes some software available: CardioExplorer that contains all common analysis
functionality and ReportGenerator which generates examination reports that can be printed in clear, user-
defined formats.
The system has the following behavior [Figure 4]: Monitoring data is collected by the sensor [F4.1] and
transferred by Bluetooth to the smart mobile phone [F4.2]. After that, the smart phone transfers the ECG data,
via mobile network, to a decision support system [F4.3; F4.4] for adjustment and then forwarded to the
caregiver’s system for analysis[F4.5; F4.6].
Figure 4 –Architecture of BodyKom Series ECG Source: (8)
The product is available at a monthly charge per patient kit and operates all over the world, as long as,
there is mobile phone coverage.
The product exhibits some limitations mainly on the type of sensors that can be used for monitoring the
vital signs of one patient. Only one sensor which uses electrodes ECG is available. Besides, data is only
transferred when ECG ratings go beyond the pre established limits. The last limitation lies on the fact that the
BodyKom cannot be purchased by an individual. The only way of buying this product is through a health
facility.
Rafael Simões Page 25 of 76
Dynamic Range +/- 6mVSample Rate 150Hz – 1800 HzTime Constant <=3,2 sDimensions 41 X 61 x18 mm (B x L x T)Weight 37 gr (inclusive battery)Data Acquisition Simultaneous – 2 ChannelRecording Time 24-120 hoursPower consumption 42 mWBatteries Li-IonenInterfaces Serial/BluetoothData Transfer ~ 15 s/24 h
3.2.2.IER
The IER, Integrated Emergency Response Systems, is a solution set, provided by AMS HomeCare (9), that
allows supervising the vital signs, as well as, managing the surrounding environment. The system also
provides personal alarm protection for patients or residents, as well as, staff working alone in unprotected
areas or during the night. The great advantage of this solution is the fact that it embraces a wide selection of
devices and allows establishing a two-way communication system which can be very useful especially for
after hour’s staff assisted calls. With this system, facility administrators will have a comprehensive knowledge
of the environment. They can monitor the facility for temperature and ventilation, security breaches and fires.
Institutions can also monitor patients including their vital signs, their locations, or other vital inputs. Other
interesting characteristic of this system is the wireless technology used – UWB (UltraWideBand) – for PAN
(Personal Area Network).
One of the sensors that is available by the IER solution is the HRRM – Our Heart and Respiration Rate
Monitor. This sensor allows monitoring automated vital signs and bed occupancy. The HRRM is positioned
beneath the mattress [Figure 5] or behind the backrest of a wheelchair. It automatically monitors the presence
of the patient and his heart and respiration rate. This information, after being processed, is relayed
continuously and wirelessly to a central monitoring station that is placed inside the health unit.
This system use UWB transceiver, a directional antenna, digital processing software and a wireless
communication module.
Figure 5 –HHRM
The easy and non invasive way of monitoring vital signs and the possibility of interconnecting the vital
signs monitoring with other types of signals like room temperature, streaming video and audio, among others
are undoubtedly the main advantages of this system. However, its portability may be considered its main
Rafael Simões Page 26 of 76
disadvantage since it can only be used in a bed or behind a wheelchair. Its design precludes the progressive
monitoring by the patient.
3.2.3.WirstClinic
The WirstClinic (10) is a medical remote wireless monitoring equipment commercialized by Telcomed, a
firm of the Medic4All group company. This product can record, store and wirelessly transmit data up to 200
meters and have the following medical monitoring functions: heart rate, blood pressure, respiratory rate, SpO 2
and body temperature.
After the vital signs are measured the data is transmitted to MedicGate or MiniGate which forward the data
to a telemedicine call center through the internet or telephone. Optionally, measurements can be taken
continuously. If transmission is disrupted, WristClinic will store up to 10 readings for transmission at a later
time. The user can visualize the monitored data via e-mail, fax or web-base medical file.
Besides WirstClinic, TelComed offers other sensors like Wireless Blood Pressure Monitor BP102 [Figure
6 (a)] that measures and simultaneously displays systolic and diastolic readings or Weight Scale [Figure 6 (b)]
that enables on-line weight tracking, among others.
The
solution offers, as it was mentioned before, two gateways: MedicGate [Figure 6 (e)] and MiniGate [ Figure 6
Rafael Simões Page 27 of 76
Sensors
Figure 6 (a) - BP102 Figure 6 (b) - Weight Scale Figure 6 (c) - MiniWrist Unit Figure 6 (d) - Wrist Unit
Gateways
Figure 6 (e) –
MedicGate
Figure 6 (f) - MiniGate
(f)]. The first one uses telephone lines, rechargeable batteries for backup (16 hours) and memory for 24
measurement readings, whereas, the second one uses internet communication, it is portable and allows mass-
storage capacity. These two gateways cover all the operation ways that can be used by this system.
The Telcomed telemedicine call center presents all the information related with the supervisions through
the Internet, it has the capability for voice and video conference, handles medical reports, analyzes medical
parameters and is responsible for handling all the communications made by telephone lines, Internet or
cellular protocols.
The web page that can be accessed to visualize all details related to supervisions has two profiles: Doctor
Viewer and User Viewer. In the first mode, a medical record is available on demand, through the web, for
consultation by a physician or other medical personnel whom the patient has authorized. The data is “read-
only” and the patient’s file cannot be modified. As for the User Viewer, the user can add, edit or remove
his/her personal data and store his results of monitored data.
This company offers a vast resource of sensors and multiple methods of redirect this information to a
Database. Furthermore, and supported by some software tools, it allows to obtain medical data from patients
analyzed by their physicians in a secure and friendlier way.
3.2.4.VitalPoint
VitalPoint (11) is a portable system sold by Delphi Medical Systems and allows clinicians to monitor
patients’ conditions remotely. Its main purpose is to monitor people at their homes with a central station
product that offers multiple accessories that are connected via wire. The following accessories are available:
Blood Pressure [Figure 7]
Thermometer
Weight Scale
Pulse Oximeter
Glucometer
ECG/EKG ( available soon)
Rafael Simões Page 28 of 76
Figure 7 - VitalPoint
Vital signs are recorded and are automatically sent to a datacenter via a regular phone line. Afterwards, the
doctor, nurse or other caregiver can log on and check the patient’s information on a website. If the signs
outpace the normal values then a SMS message is sent to the caregiver. The system has a battery that lasts, in
average, five hours.
The main advantage of VitalPoint is its usability that is highly improved with the easy-to-use touch screen.
It is intended for people who want an easy way of tracking their vital signs. Its main limitation lies on the fact
that all sensors are connected via wire to a central station which is connected via telephone. These two facts
restrain the system portability.
Rafael Simões Page 29 of 76
3.3. Review of our System
All these products mentioned above have a series of advantages and limitations as it can be observed in
Table VII. It is our responsibility, after a deep market research, to specify a solution in which the advantages
of these products are presented and their limitations overtop.
Table VII – Features of Products related to the State of the Art
Bod
yKom
IER
Vita
lPoi
nt
Vita
lSig
ns
Wireless Communications
Wireless between AM and TM NA
Wireless between TM and DC
Portability
Sensors
ECG
Thermometer
Blood Pressure
SpO2
Glucometer
Weight Scale
Possibility of integrating more sensors
Continuous Monitoring
Process Monitored Data
User Interaction
Platform of information access
Legend: AM - Acquisition Module; TS – Transmission Module
First of all, and starting with the patient’s mobility, the VitalSigns solution should rely on wireless
technology for all the implemented communications. This technology presents many positive aspects, not only
for the patients but also for the companies that support the system. In the first case, it increases in large scale
the comfort and mobility felt by patients and in the second case the use of wireless technologies has a
Rafael Simões Page 30 of 76
measurable impact on ROI [Return of Investment], with organizations saving a lot on cabling costs and labor
(12). One preoccupation that must be cautioned in the use of wireless technologies is its lower security. In the
specific case of VitalSigns this aspect can be solved with the use of an encryption system.
The VitalSigns system should be used in, at least, two environments: in the hospital and at home. This
multi environment function allows to monitor vital signs even if the patient is not in the hospital. This is a
major step in improving the patient’s empowerment encouraging a preventive medicine. Besides, it provides a
continuous monitoring. This aspect is not shared by all products within this area. The majority of the
companies in this business propose a product which measures one time and only shares this one measurement
data. This represents a major limitation of the product because, in a continuous monitoring, the data available
is much higher, which enables a more complete diagnostic. Furthermore, with this more complete monitoring,
the patient can be alerted, in real-time, if his/her vital signs are abnormal. This factor gives the patient a
feeling of security which is very important in the case of patients with chronic diseases, for instance.
Another limitation experienced with some products is the short supply of sensors which measure vital
signs. According to the patient's condition, it would be desirable a general vision, supported by multiple vital
signs sensors, which can provide more information to elaborate a more complete diagnostic. The first
company enunciated only supports ECG sensors. This can be a limitation to use the product because with only
one sensor the information collected can be insufficient to elaborate a complete diagnostic. An ideal solution
is, for instance, the one presented by Telcomed, WirstUnit, because it can measure many vital signs with the
same product. Our solution should provide a set of sensors and an architecture which would support the
integration of other sensors with little adaptation.
Finally, our system should provide an output for patients and their physicians to visualize recorded data. If
the system output is only composed by alarms and the visualization in real-time of monitored vital signs, a
true feedback to the patients and their physicians is not given. After the supervision session has taken place an
option to see the patient’s measured data related to that supervision must be given to the people involved. This
is an important function because it gives a feedback for the use of the system. If the patients, or their
physicians, cannot see an output of the system they may not feel motivated to use it and can abandon the
system. Besides seeing monitoring data, the system should provide a way of processing and analyzing
measurement data.
In conclusion, VitalSigns system should be an ergonomic, portable and dynamic solution. It must be, at all
levels, a user-oriented solution and provide the measurement of diverse signs in an efficient, secure and real-
time way.
Rafael Simões Page 31 of 76
4. Requirements Analysis
"If you don't know where you are going, any road will take you there" – George Harrison
With different products already in mind, as a consequence of a market analysis, the next step is to assemble
the main functions that our solution should provide. The VitalSigns is a system that must offer the
visualization of the vital signs measured on a patient in real time. Besides, it should allow the reception of
alarms set off within the supervision and the creation of supervision reports.
To improve our product concept and to meet the requisites of possible clients it is very important to hear
what these clients have to say about the product: what is the idea behind the architecture? What are the main
functions that the product must have? How can the product be introduced among products already placed?
How can the application be more user-friendly? In search for answers, two meetings with CCC, a partner in
the development of this project, took place. In the first one (session document in Annex – Session Document)
the main functions that the software should provide were discussed. In the second meeting some final aspects
of the product were demonstrated and discussed.
The global design of the system can be divided into: Acquisition Solution - the equipment in charge of
collecting all the vital signs data – and the Datacenter - system which will provide the handling of that data –.
Both, Acquisition Solution and Datacenter, should have a modular design to support the addition and removal
of sensors in a relative easy way. Thus, the solution set would be very attractive because it would allow a
reconfigurable application which would be modified in agreement with its scope of use.
In the following pages, a brief description of the system will be made. First of all, the components of
Acquisition Solution set will be enunciated and some decisions made along the specification period will be
explained. Secondly, the same argument will be used with the Datacenter. In this last case, a list with all
requisites that the Datacenter should have will also be portrayed.
Rafael Simões Page 32 of 76
4.1. Acquisition Solution
The acquisition module consists of one pulse oximeter, which can evaluate in a non invasive way the
oxygen saturation of a patient's blood, and one device which communicates with that oximeter by Bluetooth
and routes the measurement data by Ethernet. At our disposal, we have the pulse oximeter Nonin Model
4100(annex).
4.1.1.Pulse Oximeter
A pulse oximeter measures and displays the pulse rate and the saturation of hemoglobin in arterial blood.
Its utilization is based on different ratio of hemoglobin absorption (it depends on the oxygen rate). Like most
of the oxygen present in the blood, it is attached with hemoglobin, the saturation of hemoglobin can represent
a reliable way of monitoring the oxygen in the blood. The mode of operation relies on spectrophotometry
principles through the use of two light-emitting diodes, one in red frequency (660 nm) and another one in
infrared (940 nm), and one photo detector (5).
The device works by emitting beams of those two diodes that are passed through a pulsating arteriolar bed.
A Photo detector detects the amount of light absorbed by oxyhemoglobin and deoxyhemoglobin in the red
blood cells. The ratio of red to infrared light measured by the photo detector indicates the amount of oxygen
present in the blood [Equation 1]
Equation 1 – Calculation of SpO2
The normal average values of oximeter are situated above 95% and in most machines the default low
oxygen saturation alarm setting is 90% (13).
Rafael Simões Page 33 of 76
4.1.2.Why an Oximeter?
The advantage of using a pulse oximeter, rather than other sensor, involves many aspects. First of all, it is a
simple, portable and safe equipment to use in a facility healthcare. Besides, it allows to monitor, in a non-
invasive way, the cardio-respiratory status.
It can help to detect the presence of cyanosis [A bluish color of the skin and the mucous membranes due to
insufficient oxygen in the blood (14)],to reduce the frequency of blood time-consuming laboratory tests and
calculate the concentration of oxygen that must be given on thoracic anesthesia when one lung is collapsing
down (15).
In conclusion, a pulse oximeter offers a relative inexpensive, simple and reliable means to monitor the
respiratory function in a wide variety of clinical areas, in hospitals and the community.
4.1.3.Acquisition Module
The Acquisition Module is the component of Vital Signs that will allow the continuous monitoring of vital
signs. Its main function is behaving like a receiver of all measurement data available and route this
information to the Datacenter.
When it receives a message to start a new supervision, the Acquisition Module should search for devices in
range and start collecting measurement data from those which are active. The energy must be supplied by
batteries to allow the portability of the device. Furthermore, a backup system should be implemented to allow
saving collected data when the network is not available for some reason.
4.1.4.Communication between Oximeter and Acquisition Module
When making the choice of a standard communication, there are many requirements that need to be
analyzed. The major requirements for our application are:
Portability: Should be wireless standard to allow the patient’s mobility;
Range: The range of our system should be approximately the area of a bedroom;
Rafael Simões Page 34 of 76
Data Rate: The data rate of the oximeter is 4 bytes per second with a frequency of 1Hz;
Battery Life: The power consumption of the system must be low to prevent the constant replacement
of batteries;
Security: Because very sensitive data is being dealt, communication standard should provide a way of
preventing hijack attacks to the network;
Cost
Steps for recognition/dropping membership: The recognition/dropping of a new device in the
network should be an automatic process.
There are three major standards that assemble those requirements: Bluetooth, ZigBee and Ultra Wideband.
The selection of the Bluetooth protocol will be explained in detail in the next section.
4.1.5.Why Bluetooth?
The main advantage of using Bluetooth, just like any other wireless networks, is the possibility of
implementing a system that does not rely on wires enabling, therefore, portability and consequent comfort.
Bluetooth is a wireless protocol with low power consumption and short range, depending on the class that
is inserted. Furthermore, there is no charge for communicating between two Bluetooth devices because it
operates on an unlicensed radio spectrum (16). This characteristic and the fact that chips are estimated to cost
around $4 (2,68€ (6)) to manufacture (16), makes Bluetooth a very attractive technology in terms of cost.
Furthermore, Bluetooth networks are ad hoc and allow the automatic detection of devices within their
range and form networks with them. Bluetooth networks have the capacity to support up to seven devices
which can be connected to one another within proximity of up to 9 meters, forming a PAN or piconet.
Multiple piconets can be automatically setup for a single room, which in our case is a very important function
(17).
If a device goes out of range, the network automatically drops its membership. Since a Bluetooth device
joins a network, it can communicate with all the devices in the network. In the same way, Bluetooth networks
can communicate among them via bridge devices. Because of its ad hoc nature Bluetooth is more vulnerable
to hijack attacks. Bearing this in mind, the possibility of encrypting data between paired devices was
implemented.
Rafael Simões Page 35 of 76
The last version of Bluetooth is 2.1 + EDR (Enhanced Data Rate), announced in July 2007 (18). It offers
an enhanced data up to 3 Mbps, broadcast and multicast support, along with a further enhanced bit error rate
performance (19).
Actually, the Bluetooth SIG (Special Interest Group) is working with other standard bodies, including
UWB (Ultra Wide Band) specification committees. If this union of standards is successful, it will allow to
cover areas up to 100 meters with a data rate exceeding 100Mbps [Figure 8 – Range versus Data Rate of
Common Wireless Technologies] increasing, thus, the functions where this technology can be used, like
streaming high-quality video.
Figure 8 – Range versus Data Rate of Common Wireless Technologies
In conclusion, Bluetooth is the best solution for the scope of this project due to its robustness, low power,
and low cost and for being in the market for some years. Furthermore, and a major point within this
technology, it has the support that comes from different companies allowing a constant upgrade of the
standard.
4.2. Datacenter
The Datacenter is the heart of the system. It will be the manager of all incoming connections, the storage of
all vital signs measured and the provider of a system front-end through the use of a web application. Although
it requires more work at the very early beginning of the implementation, a web application instead of a
windows application was chosen because its possibilities are more varied – portability, easy-installation,
maintenance, modularity, among others. The Datacenter is composed by the following sub-modules: database,
web- application, services and Report Manager each one of them with different requisites. In the next sector it
Rafael Simões Page 36 of 76
will be described in detail the main requirements which are to be implemented in the VitalSigns software
system.
4.2.1.Database
The database should provide a non-redundant, secure, consistent and fast way of saving and retrieving
information. It should be linked via web application to the users and be placed physically at the server. There
is already a central database in the server that is responsible for patients’ handling. Must be made a interaction
with that database to avoid duplicate data. The main tasks related to this module are:
To save information about patients registered in the system;
To save data measurement;
To save all the details related to the sessions (data measurement, alarms, people who checked the
alarms, etc)
To save users and their access to the application;
To save images that will support the visualization of reports;
4.2.2.The Web Application
The Web Application is the front-end of the system - it will be responsible for making all the functions
available in the system accessible to the users. Firstly, it should allow the visualization of measurement data in
real time and alarms set off during supervision sessions. This interaction is possible because the web
application can control and search for Monitor Acquisitions modules incorporated into the network. Secondly,
it should provide an easy and fast way to supply useful information, such as the patients included in the
system, users and their historical access, data from patients’ supervision, among others. Finally, and to help
users to use the system, it should be implemented a help/guide method which may enable the corrections of
eventual errors that may occur.
The main requisites of this module are:
To visualize patients’ details;
To begin and save a new supervision;
Rafael Simões Page 37 of 76
To monitor data in real time;
To visualize all alarms set off during the sessions;
To see a list of errors that might have occurred and show their potentials solutions;
To visualize sessions details: alarms, begin and end date of supervision sessions; patients’ details,…;
To have an intuitive Interface and be visually appealing;
To build a helping system that can assist the user in navigation;
To create reports.
4.2.3.Services
This is the module in charge of handling the connections with Transmission Modules on the network. It
should provide two supervision behaviors:
1. OffLine – With this behavior, all measurement data is saved in the database but is not shown in the
Web Application. Afterwards, the data related to the session must be available;
2. OnLine – With this behavior, measurement data is saved in the database and shown on the web
application. This is the only mode that allows visualization of alarms in real-time.
For accomplishing these two functions the main requisites to be implemented in the Services module are:
To define a protocol, message/request model, which can be efficiently interpreted by the Datacenter
and Acquisition Module;
To save measurements data in real time and notify the web application of this data (online mode –
web service);
To have a routine that will run in the server allowing continuous data saving of all the connected
equipments (offline mode – window service);
Rafael Simões Page 38 of 76
4.2.4.ReportManager
The ReportManager is the responsible for the output of the supervision sessions. It should be able, in an
interactive way, to add/remove useful information, like measurement data, patients’ details, etc....
Furthermore, it must have a way of exporting the reports for PDF or a printable file. The main requisites in
this module are:
To show all the useful information related to the supervisions;
To export reports to a file which can be printed;
To allow to show/hide information in agreement with each case.
Rafael Simões Page 39 of 76
4.2.5.Requisites Dependencies
Table VIII – List of Requirements of VitalSigns – Software and their dependencies
Legend: RM – Report Manager
Description Dependencies
Dat
aBas
e
R1 - Save information about patients registered in system; -
R2 - Save data measurement -
R3 - Save all details related to sessions (data measurement, alarms, people who checked alarms, etc) -
R4 - Save users and their access to the application -
R5 - Save images that will support the visualization of reports; -
Web
App
licat
ion
R6 - Visualize patients’ details; R1
R7 - Begin and save new supervision; -
R8 – Monitor data in real time data; R16
R9 - Visualize all alarms set off in sessions; R2;R3
R10 - See a list of errors that might have occurred and potential solutions; -
R11 - Visualize sessions details R2;R4
R12 – Have Intuitive Interface and be visually appealing; -
R13 - Build a helping system that can assist user in navigation; R10
R14 - Create reports; R18;R19;R20
Serv
ices
R15 - Protocol – Define a message/request model which can efficiently be interpreted by the Datacenter and the Acquisition Module -
R16 - Web Service - Allow to save measurements data in real time and notify the web application of this data (online mode); R15
R17 - Service – Have a routine that will run in the server and allow continuous data saving of all connected equipments (offline mode); R15
RM
R18 - Show all useful information related to supervisions R1;R2;R3;R5
R19 - Export reports to a file which can be printed R18
R20 - Allow to show/hide information in agreement with each case R18
Rafael Simões Page 40 of 76
5. System ArchitectureIn this chapter it will be described meticulously the features of the embodied components, their
relationship and the environment where they are placed, taking into account human interaction with these
components. Furthermore, the principles governing its design and evolution will also be included. This
chapter is subdivided into two main parts:
1. Physical Architecture : In this section it will be described where the pieces of application are
installed, as well as, the high-level structure around the processes;
2. Logical Architecture: In this module the main processes and data flows will be defined .
5.1. Physical Architecture
VitalSigns is a system that understands two modes of interaction: patient and healthcare provider. As it can
be seen in Figure 9 there is one acquisition module inside every patient bedroom [1] that monitors his vital
signs. The information collected by each Acquisition Solution is routed to a server and can be visualized
through the use of a browser by the nurse center[4], doctor [2] or whoever is authorized to do it [4].
Legend: 1-Acquisition Module; 2 – Doctor; 3 – Nurse Center; 4 – Nurse with PDA
Figure 9 – Physical Scheme of VitalSigns
Rafael Simões Page 41 of 76
The system physical architecture comprehends two main spaces: Acquisition Solution and Server. The
Acquisition Solution, which is placed near the patient, is connected via Ethernet to the Server and sends data
related to vital signs permanently. Inside the server there are three main modules: Database, ReportManager
and Services.
This architecture was designed taking into account many factors. First of all, the use of a web application
provides advantages for both entities related to the project. For companies, who are responsible for the
applications, the web application provides a solution which takes less effort to upgrade, to bug fix and it
requires teams with fewer members because porting and distribution are not required. For healthcare
providers, it increases their mobility, withdraws the installation process task and provides a solution which is
always up-to-date. The Database module consists of a central database, which offers more security and makes
it easier to backup all the information in the system, connected to the Services and ReportManager modules.
Besides being connected to these modules, the Database should be connected to a major Database which
stores all information related to patients, users or other records that are related to global data. Thus, the
isolation of our system is avoided, which is an important factor in the healthcare industry.
The communication between Acquisition Solution and Server was initially defined as wireless but due to
the healthcare facilities infrastructures it was changed to Ethernet. This multi-tier architecture provides a
flexibility system because the subsystems inside the server are built in a modular manner. Because of this, the
three modules can be used in another platform with little implementation effort.
Legend: 1-ReportManager; 2- Database; 3- Services; 4- Web Application
Figure 10 – Physical Architecture of VitalSigns
Rafael Simões Page 42 of 76
5.2. Logical Architecture
VitalSigns is a multi tier solution that has a database engine as a data support and as a user interface a web
application. In between these two tiers, there is a Logic Tier which is composed by Services and
ReportManager modules and Acquisition Solution. It is this tier that is responsible for coordinating the
application flux and handling the measurement data.
Figure 11 – General Logical Architecture
The advantages of the Modular design strategy comprehends several aspects. First of all, modular design
enables a more scalable and flexible solution. Secondly, the maintenance of a modular system takes less effort
and time. Finally, and perhaps the most important feature, it is the ability add/remove components without
affecting the rest of the system.
Rafael Simões Page 43 of 76
The logical architecture of VitalSigns, at a large scale, can be divided into three main processes:
P1 - Visualization and storage of measurement data;
P2 – Elaboration of reports;
P3 - Visualization of global information.
In the next sector it will be detailed each process, and enunciate dataflow switch between modules,
necessaries for the process concretion.
Legend: Orange Lines – P1; Blue Lines – P2; Green Lines – P3
Figure 12 – Logical Architecture
P1 - Visualization and Storage of the Measurement Data
The visualization of the acquisition process begins when a new acquisition module is connected. The
Services module starts handling connections with the Acquisition Solution and routes the measurement data to
the Database. When a user wants to start supervisions in real-time the Web Application sends a request to a
new supervision and the Services starts to route the information to the Web Application, too.
Rafael Simões Page 44 of 76
A very basic flowchart is shown in Figure 13. After the measurement data is acquired it can be redirected
to both, the Database and the Web Application module. The decision concerning the modules to where this
information is routed is made according to the intention of the user of seeing the data or not.
Figure 13 – Basic Flowchart of P1
P2 – Elaboration of Reports
There are three modules which are responsible for the elaboration of a report. The starting module is the
web application where the user asks for a new report. Inside a Request New Report there is different
information related to inputs needed for processing a report: patient’s name, supervision session id, etc… The
ReportManager receives that request and solicits at the Database the information needed for generating a
report. The final step is to incorporate that data into a report and route this report to the web application.
P3 - Visualization of Global Information
This process is triggered when the user wishes to visualize some information stored at the database. The
Web Application module sends a request to the Database soliciting information such as the patient’s details,
details of alarms set off during a session, etc. After this, the Database responds enabling the visualization of
the information asked by the healthcare provider.
The Database Module communicates with Web Application and the ReportManager responding to requests
asking for stored information. The information exchanged between the Database and the ReportManager is
related to supervision data for generating reports while, in the case of the Web Application, the information
exchanged has a larger view, as it can be seen on the next process.
Rafael Simões Page 45 of 76
6. Software Development
6.1. Database Design
In the requirement phase the main requisites regarding the database operation were enunciated. The main
features concerning database are related to saving information of patients, saving information about users
registered in the system and storage of measured data and other information, such as alarms, with reference to
supervision sessions. Bearing these features in mind, the behavior of the database can be divided into three
main modules: patients; users and information related to supervising sessions. Each one of these modules is
composed by several entities, as it can be seen in Table IX.
Table IX – Entities of VitalSigns Database
Mod Entity Description
Patie
nts Patients Patients registers
Sexpatient Genders available per patient
Use
rs
Users Users that can access the system
Access Accesses that are made to the system
Usersfunction Multiple functions associate with users
Supe
rvis
ion
Sess
ions
Monitsession Information concerning supervision sessions
Oximeter Measurements data of pulse oximeter
Images Images of supervisions are saved
Alarms Alarms set off in supervision sessions
Typealarm Alarm types that can occur in one session
Rafael Simões Page 46 of 76
Entities Relationships
The relationships between entities involved in the VitalSigns system can be synthesized in interaction
among patients, users and supervision sessions. A patient has associated a single user and none, one, or
several supervision sessions. A user can be responsible for several supervision sessions and have patients
associated or not. Finally, the supervision sessions always have only one patient and one user. This is a very
basic description of the entities relationships. An ER and physical diagram, as well as, a more detailed
description of the entities relationships are available in the Annex – Database Specification.
6.2. The Web Application Design
When developing a web application many aspects have to be considered: features made available to the
client, general organization of the web site, interconnection of the information stored with visualization and
user interaction. A detailed description of the features and the operation mode of the web site can be consulted
in the Annex – User Guide.
General Organization of the Web Site
To implement a general organization that suits the user intents, the web application must provide a fast
way of traveling across its difference sections. Through the use of a fixed menu, and a frame that changes
across the application, the user can be redirected to the intended section in a fast and efficient way. As it can
be seen in Figure 14 the user has at his/her disposal a menu with several links: “Pacientes”, “Ver
Monitorização”, “Relatórios de Monitorização”, “Alarmes” and “Ajuda”[1]. As the user clicks on the various
links the aspect of the site remains the same and the main window [2] is changed according to the link clicked
on.During the implementation of the web application, the need to improve the user interaction was felt. In
order to improve this aspect the student fell back on AJAX. Along the web application, this feature can be
visualized through the use of modal popups, loading messages, decreasing the web page reload time, among
other characteristics.
Rafael Simões Page 47 of 76
Legend: 1 – Menu; 2 – Main Window
Figure 14 – Main Organization of the Web Pages (Example of the Patients Page)
The map site implemented can be perceived in Figure 15. The web pages that can be acceded by the links
in the menu can be shown at the same level– Alarms, See Monitoring, Patients, Supervision Session and Help.
Furthermore, the point of contact between the Services and the Report Manager module with the web
application is shown.
Figure 15 – Map Site of theVital Signs Web Application
Rafael Simões Page 48 of 76
1
2
1
2
In the Vital Signs system the main features available to the client comprehend the visualization of
measurement data in real-time [Figure 15- See Monitoring] and the visualization of supervision session details
[Figure 15 – Report] with the option of exporting the reports to PDF, or other format. These two features are
presented to the client in an interactive and user-friendly way. Additionally, the visualization of the alarms set
off during a session [Figure 15 - Alarms] and patients registered in the system [Figure 15 - Patients] is
provided, as long as, a filter is used. Finally, a help guide with the errors that can occur and their respective
solution is shown [Figure 15 - Help]. In the implementation of the features into the web application, the
student investigated the importance level of each one and in the process of organizing the web pages into the
web site this information was taken into account.
Help Guide
One of the most important features regarding an application is to provide a clean, interactive and intuitive
interface. This aspect is reflected in the operation mode and in the motivation related to the use of the
application. In each page an in order to improve this component, the user can see a box that has the most
relevant functions of the active page. This help is shown when the user rolls over the help button, as it can be
seen in Figure 16.
Figure 16 – Help Box in the Patients Page
Besides that functionality, and to help the users to solve problems that may occur, the error messages are
broadcast along the web application with the help of a button which is always in the foreground [Figure 17].
Rafael Simões Page 49 of 76
Figure 17 – Error message (E=Error; M=Monitoring; 4=Error Code)
Besides visualizing the origin of the error the user can observe the solutions that can be taken to solve it. If
the user clicks on it is redirected to the Help page and the solutions that are possible to implement are
visualized [Figure 18].
Figure 18 – Help Page
Rafael Simões Page 50 of 76
Interface between the Database and the Web Application
Along the web application there are numerous sections that make use of the database support to visualize
several aspects, such as patients or alarms. The process of retrieving the results from a database and its
subsequent visualization comprehends three main subsystems: Web Application; a middleware project
between the database and the web application – DataBaseManagement.csproj and the Database, as it can be
seen in Figure 19.
Figure 19 – Operation Mode of Retrieving Information From the Database (Example GetPatients)
In Figure 19 one can follow the necessary steps , and their data flow for retrieving information of the
patients registered in the system that are in accordance with the conditions of the filter applied by the user.
After filling the filter field the user clicks on the button “Aplicar Filtro”. This action creates a new instance
of the method GetPatients in the Patient class with the following inputs: name and gender of the patient and
concentrator id [Figure 14]. Inside this method, and after getting the connection string from
ConnectioString.cs, a call to a stored procedure is made. The stored procedure, Pa_GetPatients, with the
inputs regarding the filter information, is executed and retrieves, from the database, the information which is
related to the client’s records that verify this filter. Finally, this information is interpreted and sent to the web
application which attaches the information to a GridView.
Rafael Simões Page 51 of 76
The use of the DataBaseManagement project and stored procedures allows to insulate the database layer
from the users of the data. This encapsulation feature allows a more efficient and cleaner code.
6.3. Services
Requisites
The Services Module is the responsible for providing a platform which can handle the different monitor
solutions that are placed inside the network. Its first function is to be able to dialogue with those devices
opening a communication channel for transmitting vital signs measurement and save that information in a
database. In a second phase, this communication is integrated within the web application for providing a
method of visualization for the users who want to see the monitoring supervisions in real-time. To achieve the
features mentioned above some aspects must been taken into account. First of all, the visualization of the
measurement data in the web site must be made in a way that avoids the complete cycle of refreshing the web
page. This feature is important because it permits to reduce the traffic between the client and the server and it
prevents the flick of the web page providing a more user-friendly visualization. Secondly, the visualization of
measured data must offer a way so that the user may visualize it if monitoring is occurring correctly. For
instance, if the patient has the finger misplaced in the oximeter, the user must know it through the web
application and provide a way of correcting this aspect. Finally, the Services module should communicate
with the acquisition solution by storing the information in the database even if no user is interacting through
the web application with this module.
Implementation – Phase 1
The first step in the implementation of the Services module is to define the messages, and the situations
that lead to their emission, changed between the transmission module and the datacenter. A table with these
messages can be visualized in Table X – Messages. In order to start this interaction, the transmission module
and the datacenter must first give a handshake. This operation is composed by two fundamental steps. The
transmission module connects to the network and sends a message warning the datacenter that there is a new
device in the network. After that, the datacenter receives the message, and with the new socket address,
provided from the transmission module, opens a channel of communication.
Rafael Simões Page 52 of 76
Table X – Messages
Legend: S – Sent to the Datacenter; R – Received in the Datacenter
Type Byte 1 Byte 2 Byte 3
Header Length Status
S Connect_REQ 1 0 -
R Connect_RSP_BTC 1 1 0
R Connect_RSP_BTNC 1 1 1
S Start_REQ 2 0
R Start_RSP 2 1 0
S Disconnect_REQ_SR 4 1 1
S Disconnect_REQ_S 4 1 0
R Disconnect_RESP 4 0 -
Table XI – Measurement Messages
Legend: HR – Heart Rate; SEC – Seconds; MIN – Minutes; HO – Hours; DT – Days; MTH – Months; YR
- Years
Type Header Length HR SpO2 SEC MIN HO DT MTH YR
R Measurement 3 9 - - - - - - - -
After the communication channel is opened, the datacenter sends the message Connect_REQ to the
transmission module. The response by the transmission module can be one of two. If the Bluetooth of the
oximeter is disconnected, a message Connect_RSP_BTNC is sent. If not, a message Connect_RSP_BTC is
sent. If the last case occurs, the datacenter sends a Start_REQ to the transmission module and only if any error
occurs this messages has a response with a Start_RSP. If no problem occurs, it is in this phase that the
measurement data start to be exchanged with the communication channel. Finally, there are two ways of
stopping a monitoring session. The first way consists of sending a Disconnect_REQ_SR and it results in
Rafael Simões Page 53 of 76
stopping sending Measurement messages by the transmission module. If other message was sent,
Disconnect_REQ_S, the transmission module continues to send the measurement data. The content messages
and their flux compose the request/response protocol that has been defined for this system.
After the definition of the communication process and its message it was implemented a C# class, named
Protocol.cs, which is responsible for handling the communication with the transmission module. The
flowchart of the process followed by this class can be seen in Figure 20
Rafael Simões Page 54 of 76
Legend: The messages are defined in Table X and Table XI
Figure 20 – Flowchart of Protcol.cs
Rafael Simões Page 55 of 76
After the Protocol.cs class was implemented, an interface which calls the stored procedure responsible for
inserting the measurement data at database was built. The final step of this phase was the building of a console
application for testing aspects concerning the velocity and bug fixing.
Implementation – Phase 2
The second phase of the implementation consisted in developing a component that is responsible for
interconnecting the Protocol.cs with the web application. For this purpose, an architecture where web services
play a major role was implemented [Figure 21].
Figure 21 – General Architecture of the Services Module
This architecture is based on the asynchronous communication layer provided by Asp.NET AJAX. This
feature provides a way of calling Web service methods on the server through the use of JavaScript and
Rafael Simões Page 56 of 76
facilitates the interactions with them because it generates JavaScript proxies that are available at the client
script.
Furthermore, the page can call server-based methods without a postback or refreshing the whole page,
because the only data that is transferred between the browser and the Web server is the one needed for
visualization. This feature enhances the user experience for the Web application because the whole page
remains the same and only the textboxes which present the measure data are refreshed.
6.4. Report Manager
The idea of integrating a module with report support into the web application emerges due to the need of
outputting the information related to supervising sessions. For implementing this feature the Microsoft SQL
Server Reporting Services 2005 tool was used because it gives a platform which allows the creation and the
management of reports in an efficient and flexible way.
In a configurable way this module allows to build and export to several formats of reports. It is
configurable because the information that is shown in the report can be masked as it can be observed in Figure
22. If the user wants to show the information related to the oximeter, patient data or cardiac frequency, the
respective checkbox just has to be clicked on. This feature was added to the module because these reports can
be exchanged between healthcare providers and it is desirable to show only the medical and personal
information relevant to each case.
Figure 22 – Window to Elaborate New Report
Rafael Simões Page 57 of 76
After the user has chosen these options he/she is redirected to a web page where the report and a serial of
tools for managing its content can be visualized. The user has the following feature in the report page: export
the report to image format (TIFF), xml, web archive or PDF; quick navigation through the report pages; zoom
and the possibility of finding words in the text.
Figure 23 - Report Contents
The contents of a report, and as it can be seen in Figure 23 - Report Contents, comprehends four main
modules: General Data (the only one that cannot be masked), Patient Data, Supervision Session and
Measurement Data, each one with its own scope. The images that can be visualized at the Measurement Data
module are the same shown in the page Historical Report. The table with all values regarding the
measurements can be expanded or shrunk into time intervals equivalent to one day. A report example can be
visualized in the Annex – Report.
Rafael Simões Page 58 of 76
7. Tests
The phase test is an integral part of the system development phase. It can provide confidence in the system,
identify weak areas of and establish the degree of quality. In the final phase of the project development, the
tests prove the usable and operable parts of the system and must provide information to permit to make a
decision on the applicability to deploy.
The test domain has a wide range of types: unit, functionality, usability, interface, performance, security,
among others. In the document provided in the Annex - Tests, a closer look to tests concerning the user
interaction with the web application is made.
Rafael Simões Page 59 of 76
8. Conclusion
The VitalSigns project was developed within the scope of a master’s degree in Biomedical Engineering
and has as main feature the monitoring of vital signs in real-time. This project aims at offering a system which
may bring health closer to the patient in a proactive way. The purpose of the concept of this project is to
gather vital signs information in a non-invasive method and to present that information to a healthcare
provider in an interactive and user-friendly way. This vision can improve the health of the population and
contribute for a reduction in costs concerning health care.
Looking back, the initial objectives regarding the system have been achieved and, in some way, over
achieved overwhelmed. The result of the final system comprehends a web application which provides a
platform for monitoring vital signs, building reports concerning supervisions and visualizing patients and
alarms details. These features are supported by a database and diverse modules that are responsible for
acquiring signals and building reports which can be exported for PDF or any other format.
Besides all this implementation, there are still some aspects that need a deeper investigation. The
continuous accompaniment by a healthcare provider is a powerful tool that has to be maintained in order to
provide a solution which may be as close to reality as possible.
Rafael Simões Page 60 of 76
8.1. Future Works
In the next section some works related with the possible future of this project will be provided. They are
proposals that are framed into the current concept of VitalSigns and take into account the present and near
future technologies.
General Architecture
First of all, the first development to implement in the system should be the inclusion of more vital signs
sensors like ECG, temperature or position. In this developed phase protocols and standards of communication
must be studied, as well as, to adapt the acquisition module for supporting new technologies that may appear
in this process. Still in this phase, and concerning security aspects, an encrypted system should be
implemented for avoiding hijack attacks between sensors and the acquisition solution or between the
acquisition solution and the datacenter. In a subsequent step, a wireless technology in the communication
between the Acquisition Solution and the Datacenter should be implemented. This is an important
characteristic because it allows a more adapted installation of the system and meets the needs of healthcare
providing a more flexible structure. Furthermore, the messages exchange between the transmission module
and the datacenter must be revised.
Integration with other health technologies
In the development of a new system that can be used in a hospital, besides the operational needs of the
system, in the process of implementation some aspects must be taken into account - interaction and integration
with other technologies that are already in use. Bearing this in mind, the VitalSigns system should provide a
method of converting the reports into HL7 or any other medical standard. This functionality will allow a more
efficient exchange of medical data between health provider entities because both entities can interpret the
information in a fast and reliable mode.
Rafael Simões Page 61 of 76
Visualization of Data
In the section of visualization of the vital signs already measured it must be implemented a more user –
friendly architecture with the possibility of zooming, segment the x axis and add comments to a particular
point of the chart. This interaction must enable the possibility of visualizing only an intended part of a
supervision.
Alarms
The alarms visualization is, actually, possible only within the web application. So that the viewing of the
system may be completely portable, the reception of alarms must be made regardless the place where the user
is. In order to turn this feature into reality, the system must include a communication system with portable
devices. This communication must be made in a way that the system should confirm the reception of the
messages. For instance; a beep system is a good example of a communication system that can be implemented
in VitalSigns. It provides a cheap and reliable way of connecting the diverse user applications with the
Datacenter. The datacenter will be the responsible for handling the messages and for whom they will be sent.
The process of sending the messages should follow a hierarchy progression: the first message is sent to the top
of the hierarchy. If this message is not confirmed, the system must provide a way of sending the message to
the next one in the list (and so on). With this method, the set off of an alarm is always checked giving more
security to the patient.
ReportManager
In the report visualization some algorithms, which allow an easier and more efficient visualization by the
healthcare provider, should be implemented. The principal functionalities of these algorithms are: to analyze
the measurement data and to calculate a probability of future conditions; to interpret the measurement data
searching for sporadic events such as, in the case of ECG, a bradycardia [A slow heart rate, usually defined as
less than 60 beats per minute (20) ] or tachycardia [over approximately 100 beats per minute (21)] period. As
an example, and just for future reference, the Pan-Tompkins algorithm (22) is a procedure which allows
detection of QRS complex in ECG signals in real-time.
Login System and Logging Services
The web application can be used by the doctor responsible for the patient, by a nurse center or even by a
single patient who wishes to monitor his/her vital signs. Due o the fact that the web application has different
Rafael Simões Page 62 of 76
types of users, it must provide different access privileges. For instance, a patient can only see his/her personal
data and is not allowed to visualize data from any other patient. To make this possible, it must be implemented
a login system with different authorization levels that handles the access privileges to the multiple sensitive
areas.
With the possible increase of the web application complexity, it is important to provide a logging service
that helps in debugging and auditing application. An example framework that provides these features is the
log4net, a tool supported by Apache which helps the programmer in outputting log statements into several
output targets for a .NET environment (23).
Home Monitoring and Upload Platform
Furthermore, the domain of this system can be expanded to home monitoring. This will be a crucial step to
offer a more complete and flexible solution. So that this vision may become real, some aspects concerning
security and data privacy have to be implemented and some changes in the physical architecture have to be
made.
A very useful feature that can be implemented in VitalSigns is an upload platform that allows patients to
insert new information related to their health. This can be a very important module because it allows to store
in a secure mode all sensitive data related to the patient’s health and increase the information supplied to the
healthcare provider.
Rafael Simões Page 63 of 76
8.2. Final Appreciation
In a Europe that is exponentially aging every day that goes by, the solutions which provide the capability
of approaching the patients to the health care provider, are very important. Furthermore, and knowing the
limitations in budgets concerning health, the health solutions which prove that can improve the relation
between cost and effectiveness will be assisted by governments and health care facilities.
The development of this project was very gratifying in personal and technical terms. Personally, the
integration in a multidisciplinary team in a company has helped me to understand what the steps in developing
a potential product are. In technical terms, the development of this project enabled me to acquire knowledge
and the possibility to learn and work with diverse tools for the first time and to improve my concepts
regarding the code writing.
In conclusion, I am very pleased for taking part in this project and I hope that the future may be of a
continuous improvement, both technically and conceptually.
Rafael Simões Page 64 of 76
9. Bibliography
1. Microsoft. Reporting Services Overview. [Online]
http://www.microsoft.com/sql/technologies/reporting/overview.mspx.
2. Ageing: Europe's Growing Problem. Toyne, Sarah. 2002, BBC News.
3. Carone, Giuseppe and Costello, Declan. International Monetary Fund. Can Europe afford to Grow
Old. [Online] September 2006. http://www.imf.org/external/pubs/ft/fandd/2006/09/carone.htm.
4. Idriss, Shereene. MTB - Europe - Technology for Healthcare. Home Telehealth - The future of home
care. [Online] http://www.mtbeurope.info/content/ft611003.htm.
5. HospiMedica. Europe Remote Patient Monitoring Market. [Online] July 15, 2008.
http://www.hospimedica.com/?option=com_article&Itemid=289860000.
6. 1 USD = 0,665 EUR – Conversion Rate at 2008-08-12.
7. Kiwok. BodyKom Products. [Online] 2003-2008. http://nextprod.com/index.php?id=56&hi=56.
8. Picomed. Picomed - Innovate Medical Solutions. [Online] 2003-2008. http://www.picomed.de/.
9. AMS Homecare Inc. - Independece Mobility. What is IER? [Online] 2006.
http://www.amshomecare.com/EN/what_is_ier?/what_is_ier?/.
10. Medic4All. Telcomed - Wrist Clinic. [Online] http://www.telcomed.ie/allinone.html.
11. Delphi. Vital Signs Monitoring. [Online] http://delphimedical.com/patients/vitalsigns/features/.
12. Cisilion. Advantages of Wireless Networking. [Online]
http://www.cisilion.com/wireless_advantages.htm.
13. High Bean - Encyclopedia. Gale Encyclopedia of Surgery: A Guide for Patients and Caregivers.
[Online] 2004. http://www.encyclopedia.com/doc/1G2-3406200378.html.
14. MedicineNet.com. Medical dictionary definitions. Definition of Cyanosis. [Online] May 24, 2003.
http://www.medterms.com/script/main/art.asp?articlekey=10671.
Rafael Simões Page 65 of 76
15. World Federation of Societies of Anaesthesiologists. Pratical Applications of Pulse Oximetry - Page
2. [Online] http://www.nda.ox.ac.uk/wfsa/html/u11/u1104_02.htm.
16. Blue Tomorrow. Bluetooth Technology. Costs of Bluetooth. [Online]
http://www.bluetomorrow.com/content/section/80/128/.
17. Blue-Tooth-Wireless. Bluetooth Versions. [Online]
http://www.blue-tooth-wireless.com/Bluetooth_Versions.html.
18. Bluetooth - Official. Basics. [Online] http://www.bluetooth.com/Bluetooth/Technology/Basics.htm.
19. O' Reilly - MacDevCenter.com. [Online] http://www.macdevcenter.com/pub/a/mac/2005/11/18/what-
is-bluetooth.html?page=2.
20. [Online] http://www.medterms.com/script/main/art.asp?articlekey=2515.
21. [Online] http://www.mayoclinic.com/health/tachycardia/DS00929.
22. Pan, Jiapu and J.Tompkins, Willis. A Real-Time QRS Detection Algorithm. IEEE Transactions on
Biomedical Engineering, 1985, Vol. 3.
23. Apache. Logging Services. log4net. [Online] http://logging.apache.org/log4net/.
24. Carreira, Rita and Ferreira, Nuno. Web Forms - Caso de Testes. Coimbra : s.n., 2006.
25. USAToday. [Online] March 30, 2005. http://www.usatoday.com/tech/news/2005-03-30-wireless-
monitoring_x.htm.
26. Anaesthesia UK. Principles of Pulse Oximetry. [Online] September 14, 2004.
http://www.frca.co.uk/article.aspx?articleid=332.
27. Jones, Allen and MacDonald, Matthew. Visual C# Recipes. s.l. : Apress, 2006. 1-59059-589-0.
28. Bizarro, Pedro. Introdução à Base de Dados Oracle. Coimbra : s.n., 2000.
29. Mueller, John Paul. Web Development with Microsoft Visual Studio 2005. s.l. : Wiley Publishing,
Inc., 2005. 0-7821-4439-X.
30. McConnel, Steve. Code Complete - A Pratical Handbook of Software Construction. s.l. : Microsoft
Press.
31. Microsoft Project Tutorial. 2003.
Rafael Simões Page 66 of 76
32. Makofske, David B. TCP/IP Sockets in C# - Pratical Guide for Programmers. s.l. : Morgan
Kaufmann. 0-12-466051-7.
33. Sharp, John. Microsoft Visual Studio C# 2005 - Step By Step. s.l. : Microsoft Press, 2006.
34. Testing Solutions. The Importance of Software Testing. 2003.
Rafael Simões Page 67 of 76
10.Annexes
10.1. UserGuide (Detached)
10.2. Tests (Detached)
10.3. Database Specification (Detached)
10.4. Look4MyHealth (Detached)
Rafael Simões Page 68 of 76
10.5. Session Document
Rafael Simões Page 69 of 76
10.6.
Rafael Simões Page 70 of 76
Rafael Simões Page 71 of 76
Rafael Simões Page 72 of 76
10.7. Report Example
Rafael Simões Page 73 of 76
Rafael Simões Page 74 of 76
Rafael Simões Page 75 of 76
Rafael Simões Page 76 of 76