estudogeral.sib.uc.pt sinais... · web viewthis scenario, which is already being lived in europe,...

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 of 76

Versions

Version Description Date

0.1Create the Original

Document 28 August 2008

0.2 Create the Final Document 1 September 2008


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.


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.


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


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


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


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


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


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


Electronic Instrumentation Center Professor Carlos Correia [email protected] http://

lei.fis.uc.pt/


http://lei.fis.uc.pt/

http://lei.fis.uc.pt/

mailto:[email protected]

http://www.isa.pt/


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.


Coimbra Surgical Center Doctor António Travassos [email protected]

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 [email protected]

Rafael Simões Software [email protected]

Tomé Matos Hardware [email protected]

Supe

rvis

ors

Professor Carlos Correia - CEI Hardware;Firmware [email protected]

Professor Jorge Landeck - ISA Software [email protected]

Professor José Basílio Simões - ISA Hardware;Firmware [email protected]

Engineer Lara Osório - ISA Software [email protected]

Engineer Paulo Santos - ISA Hardware;Firmware [email protected]

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.


http://www.ccci.pt/

http://www.ccci.pt/



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


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


Table III – Scheduling for First Semester


Table IV - Scheduling for Second Semester – Part I


Table V - Scheduling for Second Semester – Part II


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


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


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


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


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.


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


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


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)


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.


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


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.


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.


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


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;


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.


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


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;


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);


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.


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


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


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


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.


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.


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.


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


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.


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


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


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


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.


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.


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


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


Legend: The messages are defined in Table X and Table XI

Figure 20 – Flowchart of Protcol.cs


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


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


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


10.Annexes

10.1. UserGuide (Detached)

10.2. Tests (Detached)

10.3. Database Specification (Detached)

10.4. Look4MyHealth (Detached)


10.5. Session Document


10.6.


10.7. Report Example


estudogeral.sib.uc.pt sinais... · web viewthis scenario, which is already being lived in europe,...

Documents