Implementation Of The Application In The Field Of Healthcaredocx

=== Implementation of the application in the field of healthcare ===

Abberviation List

API = Application Programming Interface

App = Application

ASP = Active Server Pages

BPM = Beats Per Minute

DAO = Data Access Object

GUI=Graphical User Interface

HTTP = Hypertext Transfer Protocol

IDE = Integrated Development Environment

JPA = Java Persistence API

JSF = Java Server Faces

JSP = Java Server Pages

OS = Operating System

POJO = Plain Old Java Object

UI = User Interface

URL = Uniform Resource Locator

XML = Extensible Markup Language

Figures List

Fig. 1.1 Diferența unor cadre între ceea ce percepe ochiul uman (a) și ceea ce se obține după procesare

Fig. 1.2 Planul U V, pentru o luminanță Y=0.5

Fig. 1.3 Privire de ansamblu(conceptuală) a sistemului de sănătate informatic implementat

Fig. 1.4 Relația dintre activitățile și serviciile ce implementează diveresle funcționalități și activitatea Main.

Fig. 1.5 Arhitectura bazată pe straturi

Fig. 3.1 Smartphone sales worldwide from 2009 up to 2014

Fig. 3.2 There is a large variety of smartphones on the market

Fig. 3.3 Instant Heart Rate app

Fig. 3.4 WebMD app

Fig. 4.1 Worldwide Smartphone OS Market share based on unit shipments

Fig. 4.2 MySQL Workbench SQL Editor interface

Fig. 4.3 Comparison between what the human eye sees (a) and how skin color changes in reality (b)

Fig 4.4 Screenshot of an Android camera app, to illustrate the camera preview frame

Fig. 4.5 Example of U-V color plane, Y' value = 0.5

Fig. 4.6 DAO pattern implementation in the webserver platform

Fig. 5.1. Conceptual overview of the HealthCare platform

Fig. 5.2 Conceptual view of the Android application activities

Fig. 5.3 Android application main menu

Fig .5.4 Edit profile interface

Fig. 5.5 Appointment interface

Fig. 5.6 Heart rate interface and dialog after a measurement is complete

Fig. 5.7. Heart rate measurement. Overall view

Fig. 5.8 Heart rate computation algorithm

Fig. 5.9 Measurement history graph

Fig. 5.10 The Alert SMS

Fig. 5.11 Schematic view of the layered architecture

Fig. 5.12 Patients page layout and contents

Fig. 5.13 Patient measurements graph

Fig. 5.14 Alert location page

Fig. 5.15 Schedule Interface

Fig. 6.1 Appointment creation and result

Fig. 6.2 Heart rate measurement result

Fig 6.3 Graph comparing the results of the two parallel measurements

Fig. 6.4 Graph displaying error values[%] of heart rate application

Table List

Table 6.1 Comparison of measurements between the application and a heart rate sensor

Romanian Summary

Această lucrare de licență propune implementarea unui sistem de sănătate informatică folosind un smartphone prin intermediul unei aplicații Android, fiind destinat unui medic de familie, cu un număr relativ mic de pacienți ce nu ar justifica achiziția unui sistem informatic complex cum sunt cele prezente în spitalele mari de exemplu.

În primul capitol, intitulat State of the art (Stadiu actual) am prezentat modul în care tehnologia informației a început să fie folosită în sistemul de sănătate și cum au ajuns telefoanele mobile să fie atât de dezvoltate încât le putem considera computere de buzunar, dar și ce sisteme informatizate sub forma aplicațiilor mobile există momentan pe piață.

Înainte ca tehnologia informației să fie dezvoltată, sistemul de sănătate era mult mai greu de administrat datorită cantității imense de informație stocată pe hârtie. Toate datele, programările și diversele documente dintr-un spital erau stocate în arhive ce aveau un dezavantaje imense: spațiul ocupat, timpul îndelungat necesar căutării anumitor documente, dar și transportul acestora.

Odată cu apariția tehnologiei, cea mai mare parte a documentelor în format fizic au fost înlocuite cu varianta electronică. Astfel, tot ceea ce înainte ocupa săli întregi, acum încape pe spațiul de stocare al unui computer personal. Următorul pas important a fost momentul în care internetul a ajuns să fie la îndemâna oricui. Astfel, s-a facilitat transportul de date, dar și comunicarea între medici, spitale și pacienți.

În ultimii 5 ani piața dispozitivelor mobile a explodat. În 2014 vânzările de smartphoneuri au depășit 1 miliard de unități, așteptându-se să treacă de 2 miliarde la sfărșitul lui 2015. Se poate afirma fără nici un dubiu că în acest moment, aproape toată lumea deține un smartphone sau o tabletă. Aceste dispozitive dispun de o putere de procesare mai mare decăt a computerelor de acum 10 ani, astfel au devenit o paltformă de bază pentru dezvoltarea de diverse aplicații. Cu ajutorul camerei, sistemului de localizare și a diverșilor senzori(accelerometru, senzor de proximitate, etc) s-au dezvoltat o gamă largă de aplicații destinate sistemului de sănătate. Momentan există sute de aplicații de acest fel, cu diferite facilități: Informare despre dozajul medicamentelor, proceduri de prim-ajutor, măsurarea bătăilor inimii, etc.

Ceea ce propune această lucrare, este de a combina toate aceste facilități într-o aplicație Android simplă, ușor de folosit și cu costuri reduse. Această aplicație, destinată pacienților se va conecta la o aplicație web(server), ce va fi utilizată de către medic.

În următorul capitol, numit Theroetical fundamentals (Fundamentare teoretică), am descris pe scurt principalele elemente teoretice, ce vor fi folosite pentru implementarea propriu-zisă a sistemului.

Aplicațiile Android sunt scrise în limbajul de programare JAVA, având câteva elemente-cheie: interfața XML, activități și servicii.

Interfața grafică din aplicațiile Android se construiește folosind fișiere de tip XML. Fiecare componentă (de exemplu un buton) are o serie de parametrii configurabili(mărime, culoare, spațiere, acțiuni, etc).

Activitățile implementează logica din spatele interfețelor, de exemplu acțiunile ce se vor executa când un buton este apăsat. În cadrul unei activități elementele din interfață sunt extrase folosind ID-ul acestora. Astfel, componentele de interfață pot fi manipulate și din interiorul activităților prin cod Java.

Serviciile sunt asemănătoare activităților, dar acestea nu au o interfață asociată. Acțiunile efectuate de servicii rulează în fundal, spre exemplu un serviciu poate fi folosit pentru a colecta date legate de locație.

Pentru a implementa mecanismul de măsurare a bătăilor inimii am folosit principiile descrise într-un articol publicat de cercetătorii de la MIT și Cambridge. Acest articol evidențează cum ochiul uman nu poate observa toate schimbările subtile din informația vizuală. Una din aceste schimbări este modul în care culoarea pielii pulsează o dată cu fiecare bătaie a inimii. Articolul descrie o metodă numită magnificare video Euleriană, ce descompune si procesează informația vizuală pentru a observa aceste detalii ce nu se pot vedea cu ochiul liber.

Fig. 1.1 Diferența unor cadre între ceea ce percepe ochiul uman (a) și ceea ce se obține după procesare

Deși nu am folosit această metodă, am folosit principiile prezentate în articol. Motivul pentru care nu am folosit magnificarea video Euleriană a fost că această metodă proceseaza imagini de o complexitate ridicată, iar pentru a măsura bătăile inimii din informația vizuală provenită de la suprafața degetului plasat pe lentila camerei nu este nevoie de o complexitate ridicată, dat fiind faptul că imaginile procesate consistă în variații ale culorii roșii. Astfel, cu fiecare bătaie a inimii, intensitatea de roșu crește considerabil, iar măsurând intervalul dintre aceste vârfuri de intensitate se poate determina rata bătăilor inimii.

Pentru a calcula valorile culorii de roșu, a trebuit mai întâi să decodez formatul imaginii din YUV în RGB. Android folosește ca format al culorilor YUV pentru informația video. Formatul YUV este caracterizat de o componentă de luminanță Y și două componente de crominanță U și V(Fig. 1.2 .Aceste două componente ce conțin informații legate de crominanță sunt codate ținând cont de caracteristicile ochiului uman, folosind o bandă (respectiv cantitate de memorie în stocare) mai redusă.

Fig.1.2 Planul U V, pentru o luminanță Y=0.5

În ceea ce privește platforma web, am descris caracteristicile de bază a principalelor clase și module folosite pentru dezvoltare.

Entitățile reprezintă echivalentul unei tabele din baza de date în cod Java. Fiecare câmp al unei clase de tip entitate reprezintă o coloană din baza de date. De asemenea, cu ajutorul adnotărilor, se pot preciza și diferitele relații dintre entități (one to many, many to one,one to one).

Toate operațiile legate de entități sunt efectuate de Data Access Objects (DAO).Pentru implementarea DAO, am definit o interfață ce conține o serie de reguli și standarde necesare implementării, iar apoi în implementarea propriu-zisă a acestei interfețe Java am creat mecanismele de bază pentru lucrul cu entități: salvare în baza de date, ștergere din baza de date, citirea tuturor entităților din baza de date sau citirea unor entități în funcție de un parametru dat.

Logica aplicației este efectuată în managed beans. Acestea sunt legate de componentele din interfața grafică și prin intermediul DAO-urilor implementează funcționalităile necesare aplicației.

În capitolul Implementation(Implementare) am descris mai întâi conceptul general al aplicației, prezentând modul în care cele două aplicații(Android și web) vor interacționa între ele(Fig.1.3)

Fig.1.3 Privire de ansamblu(conceptuală) a sistemului de sănătate informatic implementat

]n ceea ce privește aplicația Android am implementat următoarele funcționalități: Editare profil, programare consult medical, măsurarea bătăilor inimii, afișarea măsurătorilor anterioare sub formă de grafic și un sistem de alertă.

Fiecare funcționalitate este implementată printr-o activitate Android specifică, cu excepția alertei ce e implementată de un serviciu(Fig.1.4).

Fig. 1.4 Relația dintre activitățile și serviciile ce implementează diveresle funcționalități și activitatea Main.

Aplicația web s-a dezvoltat luând în considerare o arhitectură bazată pe straturi(Layered Architecture), astfel la nivelul de bază se află stratul de date(data layer), ce este responsabil de toate operațiile legate de baza de date. Doar acest strat are acces la baza de date pentru a insera sau a prelua informații.Asftel, aplicația beneficiază de o securitate, utilizatorul neavând acces la baza de date decât printr-un set de mecanisme bine definite. Stratul de date conține entitățile, interfețele DAO și implementările aferente.

Stratul de business (Business Layer) implementează toată logica din spatele aplicației. Acest strat procesează informațiile preluate de la stratul de prezentare și de la baza de date prin intermediul stratului de date. În acest strat se găsesc managed beans, ce implementează logica din spatele paginilor web.

Stratul de prezentare(Presentation Layer) reprezintă înterfața grafică cu care va interacționa utilizatorul. Interfața e implementată folosind componente Primefaces. Acestea au o referință către managed beans din stratul de business, prin acest mod fiind permisă o legătură pentru schimbul de date.

Fig.1.5 Arhitectura bazată pe straturi

Ca și facilități, aplicația web oferă o pagină de administrare a pacienților, prin care medicul poate adăuga, șterge sau vizualiza datele pacienților săi.

Sistemul de alertă este implementat cu o pagină ce folosește Google Maps pentru a localiza alertele primite de la pacienți.

Pentru a facilita programările, medicul are la dispoziție o pagină în care își poate administra programările pacienților. Pagina are formatul asemănător calendarului din Microsoft Outlook, fiind ușor de folosit.

În cadrul capitolului Experimental results(Rezultate experimentale) am întocmit o serie de scenarii de test, ce au scopul de a verifica funcționalitățile principale ale aplicației. Aceste teste au fost efectuate atât pentru aplicația Android, cât și pentru aplicația web. Un scenariu de test este caracterizat în principiu de următoarele: Titlu, descrierea testului, pașii necesari pentru a efectua testul, rezultatul așteptat, situații excepționale ce pot surveni în efectuarea testului și rezultatul actual al testului.

În urma testelor efectuate asupra aplicației Android, am observat că toate funcționalitățile de bază sunt fiabile și funcționează pe măsura specificaților. Astfel, au fost evaluate cu succes testele de lansare a aplicației, de editate a profilului(inclusiv cazul excepțional în care se lansează fereastra de editare profil, dar nu există un profil stocat local), de programare consult (inclusiv cazul excepțional în care nu există un profil definit), de vizualizare a istoricului măsurătorilor sub forma unu grafic și de alertă.

În ceea ce privește măsurarea bătăilor inimii, am întocmit un test ce presupune realizarea a 10 măsurători folosind aplicația în paralel cu alte 10 măsurători folosind un senzor ce detectează bătăile inimii. S-a observat că aplicația are o marjă medie de eroare în jurul valorii de 11%, eroare acceptabilă având în vedere faptul ca aplicația nu utilizează senzori speciali sau echipament medical pentru a detecta bătăile inimii.

Ca și concluzie, se poate afirma că această lucrare și-a îndeplinit scopul de a crea un sistem informatizat de sănătate, destinat medicilor cu un număr relativ mic de pacienți. Fiind un sistem simplu, intuitiv, și cu costuri reduse, poate fi disponibil oricărui medic pentru care nu este justificată achiziționarea unui sistem informatic de sănătate asemănător celor din spitale datorită complexității mari și a costurilor ridicate.

De asemenea, această platformă poate fi folosită ca punct de plecare pentru a crea alte platforme, adaptate la nevoile fiecărui medic. Pot fi aduse o serie de îmbunătățiri precum: Extinderea detaliilor legate de pacienți – momentan, aplicația stochează doar câteva informații de bază pentru fiecare pacient, dar poate fi dezvoltată în continuare pentru a stoca mai multe informații, în funcție de nevoile medicului.

Crearea unei legături dintre sistemul de alertă și sistemul de urgență național: în momentul în care medicul primește o alertă, aceasta ar putea fi transmisă mai departe sistemului național de urgențe.

Adăugarea de mai multe informații medicale în cadrul aplicației Android, cum ar fi : informații legate de acordarea primului ajutor sau informații legate de dozajul divereselor medicamente.

Astfel, această platformă poate fi considerată și o bază solidă pe care se vor putea dezvolta diverse sisteme medicale informatizate, indiferent de domeniul medical destinat.

Work planning

State of the art

Healthcare has always been one of the most important aspects of peoples’ lives. Throughout history people kept seeking ways to improve and ease healthcare access. Even though healthcare itself is highly evolved, it is essential to provide access to as many people as possible.

Accessibility has been greatly improved after the first computers were developed. They provided a much easier and simple way of healthcare access and management. Access to patients’ data was greatly improved by storing the data in electronic format, rather than a physical one.

As computers evolved, so did the healthcare information systems. At first (around 1960), computers were expensive and large. Even though electronic systems provided an improvement for healthcare, there were only a few hospitals that implemented these systems due to high costs. Some hospitals even shared a mainframe to lower costs, but its’ downside was the shared hospital accounting systems. [Health_Catalyst]

Electronic healthcare systems became more popular after the cost and size of computers lowered drastically. Networking and internet also played a huge role in the development of these systems, because besides that the information was stored electronically; it was also easier to transfer information from one hospital to another through networks and internet.

After smartphones appeared on the market, they provided a new way of access to healthcare.

Around 2002, smartphones began to take over the mobile device market. Blackberry and Nokia launched their first mobile devices that incorporated computing features besides communication. These were the first smartphones to become available at a large scale worldwide.

In 2007 Apple launched the iPhone, and in 2008 Android devices appeared on the market. [NCBI]

As it can be seen in Fig. 3.1 , in 2014 smartphone sales passed one billion devices, and it is expected to go over two billion by the end of 2015. [Sales_Stats].

Fig. 3.1 Smartphone sales worldwide from 2009 up to 2014

According to the Oxford advanced learner’s dictionary [Oxford], a smartphone is “a mobile/cell phone that also has some of the functions of a computer, for example the facility to use apps and the Internet”

Smartphones provide access to more than just mobile calls and texting. They are a small computer that fits inside a pocket. You can access the internet for various information, or use a huge variety of applications for different purposes: weather, finance, scheduling, entertainment, and even healthcare. These devices come in different varieties of size, operating system, hardware specifications and price range, making them available for almost anyone (Fig.3.2)

.

Fig. 3.2 There is a large variety of smartphones on the market

Due to the fact that smartphones feature a variety of sensors, they provide a reliable platform for healthcare. Healthcare applications are used by both doctors and patients. These applications provide various features such as:

Drug dosage regulation

Disease information (cause, effect, treatment)

Health tracking

Heart rate monitoring

Combining all these features (smartphone sensors,. Communication, applications), a smartphone can provide an easy and reliable way for any patient to access healthcare systems.

Instant Heart Rate [Instant_HeartRate] is an Android app available on Google Play. This app measures your heartrate using the camera. Although measurements are pretty accurate, the app only stores all past measurements, but it can’t be used to send these measurements to a doctor.

Fig. 3.3 Instant Heart Rate app

Another notable medical app is WebMD. As stated in [Web_MD], “WebMD helps you with your decision-making and health improvement efforts by providing mobile access 24/7 to mobile-optimized health information and decision-support tools including WebMD’s Symptom Checker, Drugs & Treatments, First Aid Information and Local Health Listings.”

Fig. 3.4 WebMD app

There are already different healthcare systems for hospitals and clinics, used to manage patient data records, and smartphone apps that provide different services for patients, but it is also possible to create a platform which combines all these features into a single application.

In the case of a doctor with a private cabinet, acquiring a complex healthcare system might be too expensive and inefficient (it is not worth acquiring a healthcare system used in large hospitals for a private cabinet with considerably less patients than a clinic for example). Also, a smaller cabinet does not need all the complex features a large informatics healthcare system provides.

This project implements this approach: creating a simple, efficient and low cost healthcare system for doctors with a small number of patients. The platform consists of two main elements: a webserver platform and an Android application.

Designed for the doctor, the webserver platform stores all patient data, and provides several functionalities: viewing patient details and history records, managing patient appointments and a simple emergency system.

On the patient’s side, there is the Android application, which combines the functionalities of multiple existing applications into one. It would be much easier for a patient to use a single application for all his basic healthcare needs such as: measuring heart rate, sending emergency alerts to a doctor or a contact person, viewing past heart rate measurements or planning a doctor’s appointment.

Theoretical Fundamentals

Tools and technologies used

Java programming language

Java is a class-based, object-oriented programming language. One of its’ main features is portability: Write Once, Run Anywhere(WORA), which means that a compiled Java application will run on any platform that supports Java, without needing recompilation..Initially, Java was developed in 1995 by Sun Microsystems (was afterwards acquired by Oracle Corporation).Java syntax is derived from C and C++, but with fewer low-level features.

As stated in [Oracle_Official], “From laptops to datacenters, game consoles to scientific supercomputers, cell phones to the Internet, Java is everywhere!”

97% of Enterprise Desktops Run Java

89% of Desktops (or Computers) in the U.S. Run Java

9 Million Java Developers Worldwide

#1 Choice for Developers

#1 Development Platform

3 Billion Mobile Phones Run Java

100% of Blu-ray Disc Players Ship with Java

5 Billion Java Cards in Use

125 million TV devices run Java

5 of the Top 5 Original Equipment Manufacturers Ship Java ME

„For this project, Java was used to develop the server side application of the web platform.

Android

Android is the Operating System used by hundreds of millions of devices worldwide. It is the most spread mobile OS on the market, as can be seen in Fig. 4.1, since the second quarter of 2012 Android has over 70% of the worldwide market share based on unit shipments [IDC_Stats].

Fig. 4.1 Worldwide Smartphone OS Market share based on unit shipments

Portability is another important feature of Android applications. The UI can adapt automatically if an application is installed on a smartphone or a tablet device, and at the same time providing the developer control of the UI on the different types of devices, meaning that one can create an Android application with general characteristic that adapt for different devices, and also having some particular configurations for specific devices.

The client application for this project was developed as an Android application.

Eclipse

Eclipse is mostly known as a Java IDE, but it also has IDE versions for PHP and C/C++, and is available on Windows, Linux and Mac OS. The main advantage is that Eclipse is an open source platform with plugin support. Every developer can customize the IDE in order to suit his needs. There is a great number of plugins available on the Eclipse Marketplace such as tools for modeling, charting, testing, or GUI builders.

Apache Maven

Initially used to simplify the build processes in the Jakarta Turbine project, Maven has now become a reliable tool that is used to ease building and managing of Java-based projects.

Maven provides an uniform built system, by using its project object model (POM) and a set of plugins that are shared by all projects using Maven.

Spring Framework

Spring provides an infrastructural support at the application level, allowing developers to focus on application-level business logic, without restrictions related to a specific deployment environment. Some of Spring’s main features include: Dependency injection, Aspect-Oriented Programming, Spring MVC web application and REST ful web service framework, foundational support for JDBC, JPA, JMS.

Primefaces

Primefaces is a JSF 2.0 component suite. It contains a high number of different components to suit any graphical interface needs. From a styling point of view, all components are fully customizable via CSS or by using its’ own skinning framework containing over 25 built in themes. All Primefaces components are easy to understand and implement due to the rich documentation available (online as a component showcase, and via pdf, containing numerous code examples)

MySQL

MySQL is one of the most popular open source databases, now being developed and distributed by Oracle Corporation. It provides a relational database management system, and also provides a free visual environment, in order to ease database management. MySQL Workbench allows users to graphically manage and design MySQL databases, as displayed in Fig. 4.2

Fig. 4.2 MySQL Workbench SQL Editor interface

Apache Tomcat

Tomcat is a web server and servlet container, which implements several Java EE features such as JSP, Java Servlet or WebSocket, providing a HTTP web server environment for Java code to run on. It differentiates from Apache HTTP Server which at its’ core is just a plain old webserver.

Theoretical background used to implement the Android application

Android applications are developed using either Eclipse IDE with Android SDK plugin, or Android’s own IDE, Android Studio (launched in December 2014). Every Android application consists of two main elements: layout and back-end logic. Layouts are developed using xml files, and back-end logic is implemented through Activities, Services and other “utile” classes which provide different features or mechanisms used by the first two.

Android XML layout

If we consider the following layout for an application screen (activity_manin.xml):

<TableLayout xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:id="@+id/AppointmentLayout"

android:layout_width="match_parent"

android:layout_height="match_parent"

android:layout_gravity="bottom"

android:background="@color/background"

android:paddingBottom="@dimen/activity_vertical_margin"

android:paddingLeft="@dimen/activity_horizontal_margin"

android:paddingRight="@dimen/activity_horizontal_margin"

android:paddingTop="@dimen/activity_vertical_margin">

<Button

android:id="@+id/button1"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:background="@drawable/generalbutton"

android:onClick="onEditProfileSelect"

android:shadowColor="#A8A8A8"

android:text="Edit Profile" />

<Button

android:id="@+id/button4"

android:layout_width="189dp"

android:layout_height="wrap_content"

android:layout_marginBottom="16dp"

android:layout_weight="0.28"

android:background="@drawable/generalbutton"

android:onClick="onAlert"

android:shadowColor="#A8A8A8"

android:text="Alert" />

</TableLayout>

In this case, the layout contains two simple buttons. It can be noticed that each component or layout has a series of customizable parameters like width, height, color, text and so on.

Android Activity

The activity is a java class which extends the Activity class.

public class MainActivity extends Activity

When the Activity is created, several superclass methods need to be implemented. One of them is on Create

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

}

This method is fired when the activity launches, and by setting the content view to activity_main, the activity and layout are linked together. Button action events can trigger methods in the activity just by setting the method name on the “onclick” parameter of the button. For example if Edit Profile button is pressed, the onEditProfileSelect (View view) method is triggered.

In order to start an activity from another activity, intent is used. The intent can be seen as a link between two activities. It can also be used to transfer data from one activity to the other.

public void onHeartMonitorSelect(View view) {

Intent HeartInt = new Intent(this, HeartRateMonitor.class);

startActivity(HeartInt);

}

This code snippet shows how the HeartRateMonitor is started from the MainActivity class. This method is linked to the “Heart Rate” button on the layout, and when the button is pressed, the method is fired, starting the HeartRateMonitor activity.

Relation between XML layout components and back-end implementation in Activities

Interface components can also be handled through java code in activities. The components can be modified, or one can extract values, parameters or properties to be used in different methods that implement the business logic of the application.

The following code snippet illustrates how an interface component’s value can be extracted inside an activity

EditText lastname = (EditText) findViewById(R.id.editTextSurname);

Besides the xml labels, components also have a correspondent as a Java class, which can be used to manipulate that component from within the activity.

In the example above, last name is an object of the EditText class, being initialized with the value of the EditText component found on the interface having the id editTextSurname. The findViewById method implements this feature: it searches the current activity’s layout for a component which has the id specified as a parameter.

Heart Rate Monitoring

The main question that arises is how can a smartphone camera be used to monitor heart rate? To answer this question, one must consider the fact that the human eye can’t observe subtle changes in the received visual information. Actually, the human skin changes its’ color intensity every heartbeat. This change is invisible to the naked eye, but it can be captured using a camera.

Fig 4.3 Comparison between what the human eye sees (a) and how skin color changes in reality (b)

Fig. 4.3 shows how the human eyes perceives visual information (a) and in comparison (b), how skin color changes with every heartbeat. Researchers at MIT and Cambridge developed a method that uses video processing to “reveal temporal variations in videos that are difficult or impossible to see with the naked eye and display them in an indicative manner. The method, called Eulerian Video Magnification, takes a standard video sequence as input, and applies spatial decomposition, followed by temporal filtering to the frames. The resulting signal is then amplified to reveal hidden information.” [MIT_CSAIL]

This complex method can be used on any video to reveal hidden information, not only heart rates.

For the heart rate monitoring feature in the Android Application, the Eulerian Video Magnification is not used, but the main principles behind this method are taken into consideration. Heart rate monitoring is by video recording the user’s finger placed on top of the camera lens. This simplifies the image processing, because the image will contain only different variations of red, unlike the examples in [MIT_CSAIL], which use more complex recordings as input.

By recording images of the finger and breaking them into frames afterwards, heart rate can be measured by tracking the time intervals between two color intensity peaks.

Android camera color format

As input, the Android camera preview frame is used. The camera preview frame represents a real time video input from the camera, without the need of a video file to be saved on the storage. The same preview frame is used in all Android camera applications: it’s what the user sees on the screen through the camera before he takes a photo or starts filming (Fig. 2.4)

Fig 4.4 Screenshot of an Android camera app, to illustrate the camera preview frame

Android’s preview frame captures visual data in NV21 color format, which is a derivate of YUV. The YUV format is defined by a luminance component: Y and two chrominance components U and V. These two chrominance components are encoded taking account human eye perception, allowing the use of a reduced bandwidth. An example of the UV chrominance plane can be observed in Fig. 2.5

Fig. 4.5 Example of U-V color plane, Y' value = 0.5

Theoretical fundamentals used to implement the webserver platform

Model Classes

A model class (or entity) represents a table in the database, and every instance of a model class is a row of that table. Relations between entities are places using annotations (ex: @OneToMany, @ManyToOne, @OneToOne).

The code snippet below shos an example of a model class, the Measurement class:

@Entity

@NamedQueries({ @NamedQuery(name = "measurement.findAll", query = "select o from Measurement o"), })

public class Measurement {

@Id

@GeneratedValue(strategy = GenerationType.AUTO)

private int id;

private int value;

private Date timestamp;

@ManyToOne(fetch = FetchType.EAGER)

@JoinColumn(name = "PatientId", referencedColumnName = "Id", nullable = false)

private Patient patient;

public int getId() {

return id;

}

public void setId(int id) {

this.id = id;

}

public int getValue() {

return value;

}

public void setValue(int value) {

this.value = value;

}

public Date getTimestamp() {

return timestamp;

}

public void setTimestamp(Date timestamp) {

this.timestamp = timestamp;

}

public Patient getPatient() {

return patient;

}

public void setPatient(Patient patient) {

this.patient = patient;

}

}

The @Entity annotation lets the compiler know that this is an entity class. Optionally, a @Table (name=”xyz”) annotation can be added to explicitly tell the name of the table this entity respresents. If no @Table annotation is present, it is assumed that the table name is identical with the class name (in this case, the Measurement class will correspond with the Measurement table in the database). Java Hibernate provides a feature that allows the database tables to be crated from the entity classes (including relational aspects provided by annotations), thus the deployment of the application is made much easier, without the need of creating the wholde database structure beforehand.

Besides the added annotations, the model class contains a set of variables (corresponding to a table’s columns) and their getters and setters, similar to a POJO (Plain Old Java Object).

DAO/DAOImpl

Dao patterns are used for separation of low level data access and high level business logic operations, thus being a link between these two levels by providing the upper level with data fetched from the lower level (database).

The Dao pattern used in the application is presented in Fig. 2.6 below.

All Daos are interfaces which only supply the required specifications of a Dao’s functionality (similar to a set of rules), which are then implemented by DaoImpl classes. EntityDao and EntityDaoImpl provide all generic dao functionalities (persist, findAll, remove, etc). The other Dao interfaces and DaoImpl classes extend EntityDao and EntityDaoImpl, and provide their specific functionalities. This way, all generic functionalities are kept in one place (EntityDao, EntityDaoImpl), making them easier to maintain.

Dao Implementation classes are also annotated with @Component. This annotation, specific to the Spring Framework declares the class as a component, which can be later injected in other components. Using this annotation Daos can be injected into controllers (which implement business logic).

Fig. 4.6 DAO pattern implementation in the webserver platform

Beans

Managed beans implement the business logic layer of the application and provide the data to be displayed on the graphical interface.

They are interconnected using spring framework. All beans are annotated with @Component annotation (components can be named using the value parameter). Another annotation type used is the scope annotation. Managed beans can be of different scope types, the most used being:

Singleton (@Singleton) Singleton beans are instantiated only once per application lifespan.

Session (@SessionScoped): The lifespan of a session scoped controller is throughout a user’s HTTP session. Session scoped beans are used to store data which is retrieved once or only a few times from the database. For example, the list of patients which populates a table can be stored in a data holder thus avoiding unnecessary database queries every time the patients table is rendered throughout a session.

Request (@RequestScoped): Request scoped bean instances have a short lifespan, only during HTTP requests. They are used to implement the business logic of different buttons, for example a request scoped bean can contain a method which implements the “Delete Patient” logic. The user clicks the button, a new instance of the request-scoped bean is created and the delete Patient () method is called. After the method runs, the bean’s lifecycle ends.

Servlets

The servlet is a Java program that extends the features of a server. Mostly, servlets implement applications hosted on web servers (an equivalent of Java’s servlets are the web content technologies such as PHP and ASP.NET), usually being used with the HTTP protocol.

Implementation

Mainly, the healthcare platform developed in this project consists of two core elements: an Android application and a WebServer connected to a database.

The Android application is the patient’s way to communicate with the doctor, while the WebServer is a doctor’s tool, where he can view details about his patients.

A conceptual overview of the HealthCare platform is presented in Fig.5.1

Fig. 5.1. Conceptual overview of the HealthCare platform

Implementation of the Android Application

The Android application is intended to ease communication between a patient and his doctor. Using the application, a patient can monitor his heart rate, view measurements history, make a doctor’s appointment and use an alert service.

Each feature is implemented through its’ own activity and layout. Every activity is started from the Main Activity, which starts when the application is launched. A conceptual overview of the application’s activities is presented in Fig.5.2.

Fig. 5.2 Conceptual view of the Android application activities

Main Menu

The main menu has a simple interface that can be used with ease by any user. Each button represents a feature provided by the application, grouped according to their functionalities.

Fig. 5.3 Android application main menu

Edit Profile

Every user must configure their profile in order to benefit from all functionalities provided by the application. (Fig. 5.4)

Fig .5.4 Edit profile interface

The interface consists of several input text components and labels (one pair for every data required), and a button which saves all the information.

Storage of the user’s profile is done by using an XML file. If a profile already exists, the application reads the xml file and fills the fields in the edit profile screen; otherwise, the fields are blank and a new XML file is created to store the data.

All XML operations are handled by the XMLOperation class. The class contains methods for reading and writing an XML file.

Appointment

Users can make doctor’s appointments through the application. All the user has to do is select a date and time for the appointment and press the Make Appointment button. If the appointment is successful, the user receives a confirmation.

Fig.5.5 Appointment interface

Appointments are handled by the AppointmentActivity class. When making the appointment, a method is called to handle the newly created appointment and send it to the server.

public void onMakeAppointment(View v) {

final XMLData xmlData = XMLOperation.readXML();

ClientConnection conn = new ClientConnection(this);

TimePicker timePicker = (TimePicker) findViewById(R.id.appointmentTimePicker);

int hour = timePicker.getCurrentHour();

int minute = timePicker.getCurrentMinute();

DatePicker datePicker = (DatePicker) findViewById(R.id.appointmentDatePicker);

int year = datePicker.getYear();

int day = datePicker.getDayOfMonth();

int month = datePicker.getMonth();

GregorianCalendar date = new GregorianCalendar(year, month, day, hour,

minute);

long dateFrom = date.getTimeInMillis();

date.add(Calendar.HOUR, 1);

long dateTo = date.getTimeInMillis();

conn.setMessage("4" + "," + xmlData.getCnp() + "," + dateFrom + ","

+ dateTo);

conn.execute();

}

Selected date and time values are extracted from the DatePicker and TimePicker components, and then they are inserted in a message to be sent to the server. Every message contains a message ID, CNP of the Patient and appointment data. For the application, every appointment is set to be 1 hour long.

Heart rate

Users can measure their heart rate by placing their finger on the camera lens. The interface of heart rate measurement feature consists of a camera preview frame (in order to give some feedback to the user, in order to make sure that the finger is placed correctly on the lens and illumination is sufficient for a correct measurement), and a brief instruction set for the user. When a heart rate has been measured, a dialog appears containing the value allowing the user to either save or discard the measured value.

If the user chooses to keep the measurement, it will be saved locally in a text file and also sent to the server.

Fig.5.6 Heart rate interface and dialog after a measurement is complete

The main concept behind heart rate measurement is presented in Fig.5.7

Fig. 5.7. Heart rate measurement. Overall view

After the Heart rate measurement activity is started, the device will start its’ camera preview frame

Using data from the preview frame the app will compute the current heartrate.

The heart rate computation algorithm is presented in Fig.5.8 below:

Fig. 5.8 Heart rate computation algorithm

Mainly, when a user places its’ finger on top of the camera lens, the application will compute the average value of red pixels in the image. The image is taken from the device’ camera preview frame in real time. Before finding the average values of red in the image, the image format is decoded from YUV to RGB. After the YUV-RGB conversion, the application computes the average value of red in the current frame and it places it in an array. This array stores the latest computed values of the red component.

When the array is filled and one of the values is significantly greater than the rest, it means that there is a heartbeat, so a counter associated with the number of heartbeats will be incremented.

During several seconds, the application computes the number of heartbeats, and the value is generalized for number of beats per minute. This small wait time (around 20 seconds) is required in order to obtain a more accurate measurement.

Measurement graph

As stated in 3.1.4, if the user decides to keep the measured value, it will be saved locally in a text file. This text file is processed and used to generate a graph for the user, in order to view his measurements history (Fig.5.9).

Fig.5.9 Measurement history graph

public class ChartActivity extends Activity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_chart);

if (savedInstanceState == null) {

getFragmentManager().beginTransaction()

.add(R.id.container, new PlaceholderFragment()).commit();

}

GraphView graph = (GraphView) findViewById(R.id.graph);

graph.getGridLabelRenderer().setLabelFormatter(

new DateAsXAxisLabelFormatter(this));

graph.getGridLabelRenderer().setNumHorizontalLabels(4);

Series series = BpmData.readFile();

graph.getViewport().setMinX(series.getLowestValueX());

graph.getViewport().setMaxX(series.getHighestValueX());

graph.getViewport().setXAxisBoundsManual(true);

graph.getViewport().setXAxisBoundsManual(true);

graph.addSeries(series);

}

The code snippet above shows how the graph is created. When ChartActivity Is launched, a GraphView component is initialized with data read from the measurements file.

Users also have an option to clear all history, which will delete the measurements file.

Alert

A basic emergency system is included in the application. It has been developed for patients that suffer from different chronical diseases like epilepsy or severe heart rate conditions. When a crisis appears, in some situations it is vital to get help, but a person might be alone, without any other people around. Emergency calls might take several seconds or even minutes to get through (for example when someone calls the 112 emergency systems, an automatic response machine first greets the user providing instructions, and only after that an operator will answer). Using the alert feature, just by pressing a button a contact person and the doctor (assuming that their data has been filled in the application profile) will receive an alert SMS containing the name of the person sending the alert, map coordinates and a link to google maps which pinpoints the location of the device.

Fig. 5.10 The Alert SMS

In order for the application to be able to get location details, location service on the device must be activated beforehand (Android’s API does not allow to automatically turn on the location system).

Location coordinates are taken from a service running in the background, being then used by the Alert Activity to send the message. Sending the SMS message is done using Android’s API through SMS Sender class:

SmsSender.sendSmsMessage(contactNumber, text);

Besides the SMS, an alert is also sent to the server.

Connection

In order for the application to send data to the server, a connection is required. Given that messages sent are just plain text, a URL connection would be most suitable for this purpose. Android does not allow connections to run on the main thread that is why connections are implemented by extending the AsyncTask class.

AsyncTask execution goes through several steps:

onPreExecute(), The first step of the execution, usually used for initialization or displaying an initial message to the user. onPreExecute() runs on the UI thread.

doInBackground(Params…), After onPreExecute is finished, doInBackground() is started automatically. In this method handles all data running on a background thread, like sending a file or message through a URL connection. Being on a separate thread, UI components can’t be manipulated inside this method.

onProgressUpdate(Progress…). This method does not have an exact timing, being activated when an update is sent from doInBackground. Running on the UI thread, onProgressUpdate() can be used do display a loading bar to the user.

onPostExecute(Result). The final step which starts when doInBackground() is finished. onPostExecute() also runs on the UI thread.

Using an URL connection, the applications sends messages to the server in doInBackground() method.

URL url = new URL("http://" + SettingsStorage.getServerIp()+"/healthcare.web/AndroidConnectionServlet");

URLConnection connection = url.openConnection();

String inputString = message;

connection.setDoOutput(true);

connection.setDoInput(true);

OutputStreamWriter out = new OutputStreamWriter(connection.getOutputStream());

out.write(inputString);

out.close();

WebServer Platform

The webserver platform is written in Java and deployed using Apache Tomcat. The Database client used for this webserver platform is MySQL.

Using the webserver platform, a doctor can view and manage his patients’ info, or their heart rate measurement history, respectively alert history. Client-Server communication is made through servlets.

From an architectural point of view, the webserver application implements a layered architecture on three levels, Data, Business and Presentation, as can be seen in Fig. 5.11

Fig.5.11 Schematic view of the layered architecture

The Data Layer handles all database-related operations and passes forward the data to the business layer. It is important that acces to the database is made only through the Data Layer, making the system more secure (this way, the database can’t be accessed only through specific procedures and mechanisms implemented by the Data layer).

Contents of the Data Layer include Model(or Entity) classes or DAO interfaces and their implementations.

The Business Layer implements application logic(or business logic). This is the layer where data is processed and sent to the Presentation Layer, or to the Data Layer to be stored in the database. Mostly all alghorithms used to process data are stored here. A good analogy would be with a signal processing module in a circuit: an input signal enters the module where it is porcessed, and the result goes out as another signal. Managed Beans(Data holders or managers) can be found in this layer.

The Presentation Layer represents the front-end of the application, being the layer that users interact directly with. All GUI components are encolsed in this layer.

Patients page

The patient’s page contains a table with all registered patients, and a toolbar with different functionalities: Add, View/Edit and Delete (Fig. 5.12).

Fig.5.12 Patients page layout and contents

All business logic behind the patients’ page is handled by two managed beans: PatientDataHolder and PatientManager.

PatientDataHolder is a session scoped bean, responsible with storing all patient data throughout a web session, such as the patient list, or the selected patient.

Patients list is initialized right after the bean is instantiated, in the init() method, annotated with @PostConstruct. The following code snippet illustrates patients’ initialization:

@PostConstruct

public void init() {

try {

patients = patientDao.findAll();

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

PatientDataHolder uses patientDao to retrieve all patients from the database. PatientDao is injected using spring’s @Autowired annotation.

@Autowired

private PatientDao patientDao;

PatientManager is a request scoped bean, managing all requests coming from the page. Such requests are: add patient, save patient or delete patient. Each request is linked to a different method from this bean. The following code snippet illustrates a method responsible with removing a patient from the system.

public void removePatient() {

if (patientDataHolder.getSelectedPatient() != null) {

patientDataHolder.getPatients().remove(

patientDataHolder.getSelectedPatient());

try {

patientDataHolder.getPatientDao().remove(

patientDataHolder.getSelectedPatient().getId());

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

patientDataHolder.setSelectedPatient(null);

}

}

PatientDataHolder is injected using Spring in order to access the patients list and current selected patient. When the remove patient button is pressed, this method is executed: Selected patient is removed from the patients list stored in session, and also from the database.

When viewing a patient’s details, the medic can view a graph of that patient’s BPM measurements history.

The graph is implemented using the Primefaces Chart component, which generates a graph or chart from a list of data given as input.

Fig. 5.13 Patient measurements graph

Alert localization

Using this page, the doctor can view all alerts from his patients. Alerts can be filtered for a specific patient, or to display alerts from all patients.

Primefaces offers a customizable Google Maps plugin, where alerts can be placed as markers on the map. In order for this feature to be functional, the webserver host must have internet access.

Pinpoints on the map are implemented using the Marker class which has the following properties: latitude, longitude and title. All markers are then placed in a MapModel array linked to the UI component.

Fig. 5.14 Alert location page

Schedule

A doctor can manage his schedule and appointments using this feature. It is similar with the calendar feature from Microsoft Outlook, with an easy to use, intuitive interface.

Fig. 5.15 Schedule Interface

Scheduling is managed through ScheduleView bean. The UI component is populated from a ScheduleModel, an array containing all events from the calendar. All events are instances of ScheduelEvent class, with different parameters, of which the most notable would be:title, description, dateFrom and dateTo. Detailed information, including source code can be found in the appendix.

Client Connection

Client connections are handled through a servlet named AndroidConnection servlet.

@WebServlet("/AndroidConnectionServlet")

public class AndroidConnectionServlet extends HttpServlet

The servlet is declared by adding the @WebServlet annotation, followed by its’ name. AndroidConnectionServled handles all connectivity logic between the web platform and the android application. Each message sent through the connection is defined after the following pattern: <MessageId>,<Patient CNP>,<Data>,<Data>, … ,<Data>

<MessageId> is an int which identifies the message type sent by the client.

MessaageId=1: The message contains heart measurement data

MessaageId=3: The message contains an alert

MessaageId=4: The message contains an appointment request

<PatientCNP> is used to identify the patient that used the application to send the message, and for the webserver to know for who to assign the data to in the database.

<Data> values are handled differently, depending on the message type.

When a message is received, a switch statement is used to handle the data

Experimental Results

HealthCare platform should provide a simple, yet reliable way for patients to communicate with a doctor through their Android application. Reliability of this platform can be checked by using different test cases.

A test case represents a short report on checking if a specific feature works as intended. Usually, a test case is described by the following: Title, Description, Test steps, Input data (if necessary), Expected result, Actual result, Exceptional cases.

Android test cases

Edit profile tests

The following tests will check if Edit profile functionality works as intended

Test No. 1

Title: Edit profile launch

Description: Test if launching the Edit Profile section of the application works correctly

Test steps:

1. Start the application

2. Press Edit Profile

Expected result: The edit profile interface should be displayed, containing information related to the current user profile

Exceptional case: If there is no profile file available, all fields should be blank.

Actual result: Pressing Edit profile launches the activity, displaying profile information. Considering the exceptional case, all fields are blank.

Test No. 2

Title: Edit profile save functionality

Description: Test if profile data is saved correctly

Test steps:

1. Start the application

2. Press Edit profile

3. Insert or modify data

4. Press Save profile

5. Exit application

6. Start the application

7. Press Edit profile

8. View displayed data

Expected result: After saving or modifying data, view

Exceptional case: If there is no profile file available, all fields should be blank.

Actual result: Pressing Edit profile launches the activity, displaying profile information. Considering the exceptional case, all fields are blank.

Appointment tests

These tests will confirm if the appointment feature works as intended.

Test No. 1

Title: Appointment launch

Description: Test if launching the Appointment feature works as intended.

Test steps:

1. Start the application

2. Press Appointment

Expected result: The Appointment interface should be displayed without any errors or crashes.

Exceptional case: If there is no profile file available, a dialog appears informing the user that there is no profile created.

Actual result: Pressing Appointment launches the activity, and if there is no profile created, a dialog appears.

Test No. 2

Title: Make appointment

Description: Test if making an appointment is successful

Test steps:

1. Start the application

2. Press Appointment

3. Select a date and time

5. Press Make appointment

6. Check for confirmation message

7. Check on the webserver if the appointment has been made

Expected result: The Appointment should be sent to the webserver and the user should receive a confirmation message

Exceptional case: If the selected date overlaps with another existing appointment, the appointment will not be created and the user should receive a notification.

Actual result: Making an Appointment is successful, and for the exceptional case, a notification is displayed informing the user that the appointment could not be made.

Fig. 6.1 Appointment creation and result

Heart rate tests

These tests will check if the heart rate functionality works as intended, and if the measurements are accurate enough (10-12% error rate is considered acceptable)

Test No. 1

Title: Heart rate launch

Description: Test if launching the Heart rate feature of the application works correctly

Test steps:

1. Start the application

2. Press Heart Rate

Expected result: The heart rate interface should be displayed, containg a camera preview frame and a set of instructions below

Exceptional case: –

Actual result: Pressing Heart rate launches the activity, displaying the Heart rate layout

Test No. 2

Title: Heart rate measurement

Description: Test if the Heart rate feature displays measured values.

Test steps:

1. Start the application

2. Press Heart Rate

3. Place a finger on the camera lens

4. Wait for the measurement to be completed (around 20 seconds)

Expected result: After placing the finger on the camera lens and waiting for around 20 seconds, a dialog should appear displaying the measured value

Exceptional case: –

Actual result: Pressing Heart rate launches the activity, displaying the Heart rate layout

Fig. 6.2 Heart rate measurement result

Test No. 3

Title: Heart rate measurement accuracy

Description: Check the accuracy of heart rate measurements

Test steps:

1. Start the application

2. Press Heart Rate

3. Place a finger on the camera lens

4. Wait for the measurement to be completed (around 20 seconds)

5. Use a more exact measurement (in this case, a heart rate sensor will be used)

6. Make several (around 10) measurements in parallel with both methods

7. Compare the results

Expected result: The application Heart rate feature should have an average error rate of 12% or lower

Exceptional case: –

Actual result:

Table 6.1 Comparison of measurements between the application and a heart rate sensor

Fig 6.3 Graph comparing the results of the two parallel measurements

Fig. 6.4 Graph displaying error values[%] of heart rate application

The average relative error value is around 10.5% (if we consider all error values as abs (e)). This error can be tolerated, considering that the application uses a camera to monitor heart rate.

Measurement history graph tests

These tests have the purpose to verify if the graph plotting a user’s previous measurements is working as intended.

Test No. 1

Title: Measurement history launch

Description: Test if measurement history launches without errors or crashes

Test steps:

1. Start the application

2. Press Measurement History

Expected result: A graphical representation of the past measurements should be displayed

Exceptional case: There are no previous measurements stored

Actual result: The graphical representation is shown, displaying measurement history. In the exceptional case, a blank graph is shown.

Test No. 2

Title: Measurement history clear

Description: Test if measurement history is cleared successfully

Test steps:

1. Start the application

2. Press Measurement History

3. Press Clear History

4. Go back

5. Press Measurement History again

Expected result: All preivous measurements should be cleared

Exceptional case: –

Actual result: After clearing history, all history items are gone.

Alert tests

Alert tests ensure that the alert functionality works properly.

Test No. 1

Title: Alert check

Description: Test if pressing the Alert button will send alert messages

Test steps:

1. Start the application

2. Press Alert

Expected result: The contact person and medic should receive an SMS containing the alert message; location coordinates and link to google maps

Exceptional case: There is no profile information stored, or the location service is unavailable

Actual result: After pressing the Alert button, the contact person and medic receive the alert SMS. If a profile is not available, a dialog window is displayed informing the user to create a new profile. If location is not activated, the sms will contain 0;0 coordinates and send “link unavailable” instead of the google maps link.

Android application tests Summary

Overall, these tests ensure that the Android application can provide a reliable way for a patient to measure his own heart rate, with a tolerable error rate, taking into account that these measurements are not taken by professional medical equipments. Also, patients can communicate with their doctor easier, by making appointments using the application. In some situations, a patient’s life can be saved with the help of the alert system.

Webserver test cases

Patients page tests

Test No. 1

Title: Patients table display test

Description: Test if all patients are displayed correctly in the table

Test steps:

1. Go to the webserver link

2. Click on the Patients page

3. Check the Patients table contants

Expected result: All patients should be displayed in the table

Exceptional case: There is no patients stored in the database

Actual result: When opening the page, all patients are shown in the table. In the exceptional case, the table is empty.

Test No. 2

Title: Add patient feature

Description: Test if add patient mechanism works properly

Test steps:

1. Go to the webserver link

2. Click on the Patients page

3. Click the new button

4. Fill in the required fields

5. Click save

Expected result: The new patient should be saved in the database and appear in the table

Exceptional case: –

Actual result: After filling the required data and pressing add, a new patient is added to the table.

Test No. 3

Title: Delete patient feature

Description: Test if delete patient mechanism works properly

Test steps:

1. Go to the webserver link

2. Click on the Patients page

3. Select a patient from the table

4. Press delete

Expected result: The selected patient should be removed from the system

Exceptional case: –

Actual result: After pressing delete, the patient is removed from the table and database

Test No. 4

Title: View patient graph

Description: Test if a patient’s history is displayed correctly as a graph

Test steps:

1. Go to the webserver link

2. Click on the Patients page

3. Select a patient from the table

4. Press View/Edit

5. Select the Patient BPM rates tab

6. Check if the graph is displayed correctly

Expected result: A bar graph showing the selected patient’s past measurements should be displayed

Exceptional case: The selected patient has no measurements stored in the database

Actual result: The graph is displayed accordingly, showing all past measurements. If no measurements are stored in the database, the graph is blank.

Alert location tests

These tests ensure that the webserver part of the alert system is reliable and works properly.

Test No. 1

Title: Alert display test

Description: Test if alerts are displayed correctly on the map, according to the selected patient

Test steps:

1. Go to the webserver link

2. Click on the Alert Location page

3. Select a patient from the dropdown list

4. Check if the page refreshes and only the selected patient alerts are displayed

Expected result: Only the selected patient alerts should appear on the map

Exceptional case: There are no patients stored in the database

Actual result: When selecting a patient from the dropdown menu, the map is refreshed with the alerts received only from that patient.

Schedule tests

Test No. 1

Title: Schedule display test

Description: Test if all scheduled events from the database are displayed on the schedule page

Test steps:

1. Go to the webserver link

2. Click on the Schedule page

3. Check if all scheduled events are displayed correctly

Expected result: All events should be displayed on the Schedule page

Exceptional case: There are no schedules in the database

Actual result: When viewing the Schedule page, all events are displayed accordingly

Test No. 2

Title: Add event test

Description: Test if adding a new event is working

Test steps:

1. Go to the webserver link

2. Click on the Schedule page

3. Click on a calendar date

4. Fill in the form

5. Click Save

Expected result: The new event should be added to the schedule view

Exceptional case: –

Actual result: After adding a new event, it is displayed on the schedule view and saved in the database

Webserver platform tests summary

The tests performed on the webserver platform proved that the web application is fully functional, providing the doctor with information about his patients, and also view all appointment requests and heart rate measurements from patients, keeping him always in contact with them. Also, the doctor can view all alerts, being able to send help to his patients.

Conclusions

After analysing the test results, it can be stated that the main objective of this project has been achieved. A healthcare system using an Android application has been implemented successfully, providing basic features that are reliable and intuitive for both patient and doctor.

Using the Android application, the patient can regularly check his heart rate even in situations when he does not have access to medical equipment for measurement. All pastmeasurements can be viewed as a graph. Also, the patient can make a doctor’s appointment much easily through the application, just by selecting a date and time and pressing a button.

And most important, in some cases the alert system could save a patient’s life, by noticing the doctor and a contact person with a message containing his exact location only by pressing a button.

The web application provides the doctor an easier way to manage his patients details, and also to constantly keep in touch with them. Scheduling is managed much easier using the page from the web application, and alerts can be viewed on a map for each patient.

Finally, besides the functionalities described in this paper, this healthcare system can be customized further, in order to suit any medical speciality needs. That’s why this system can also be considered as a basic framework for a lighweight, low cost healthcare system.

The patient details page could be further developed to include other patient related data according to the doctor’s requirements.

Also, the alert system could be connected to communicate with the national emergency system, allowing doctors to call for help faster for patients sending alerts.

These were just some of the possible improvements and customizations possible using this platform.

References

[Sales_Stats] Statista: The Statistics Portal http://www.statista.com/statistics/263437/global-smartphone-sales-to-end-users-since-2007/; Last accessed: June 2015

[Health_Catalyst] Health Catalyst Website: https://www.healthcatalyst.com/healthcare-information-systems-past-present-future Last accessed: June 2015

[NCBI] National Center for Biotechnology Information website http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3437811/ Last accessed: June 2015

[Oxford] Oxford dictionary website http://www.oxforddictionaries.com/definition/learner/smartphone Last accessed: June 2015

[Oracle_Official] Java Oracle Official Website https://www.java.com/en/about/ Last accessed: June 2015

[IDC_Stats] IDC Website http://www.idc.com/prodserv/smartphone-os-market-share.jsp Last accessed: June 2015

[Android_ImgFormat] Image Format- Android Developers webpage http://developer.android.com/reference/android/graphics/ImageFormat.html#YV12 Last accessed: June 2015

[MIT_CSAIL] Hao-Yu Wu, Michael Rubinstein, Eugene Shih, John Guttag, Fredo Durand, William Freeman , 2012, Eulerian Video Magnification for Revealing Subtle Changes in the World, MIT CSAIL , Quanta Research Cambridge, Inc http://people.csail.mit.edu/mrub/evm/ Last accessed: June 2015

[Instant_HeartRate] Instant Hearr Rate Google Play page: https://play.google.com/store/apps/details?id=si.modula.android.instantheartrate Last accesed: June 2015

[Web_MD] WebMD Google Play page: https://play.google.com/store/apps/details?id=com.webmd.android; Last accessed: June 2015

Appendix

Pacient Data Holder and PacientManager beans structure

Schedule View source dode

This bean implements the web application scheduling mechanism

package healthcare.web.bean;

@Component(value = "scheduleView")

@SessionScoped

public class ScheduleView implements Serializable {

/**

*

*/

private static final long serialVersionUID = 8923110008558669912L;

private ScheduleModel eventModel;

private ScheduleModel lazyEventModel;

private List<Appointment> appointments = new ArrayList<Appointment>();

private ScheduleEvent event = new DefaultScheduleEvent();

private String selectedListPacientId;

@Autowired

private PacientDataHolder pacientDataHolder;

@Autowired

private AppointmentDao appointmentDao;

@PostConstruct

public void init() {

eventModel = new DefaultScheduleModel();

try {

appointments = appointmentDao.findAll();

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

for (Appointment appointment : appointments) {

eventModel.addEvent(appointmentToEvent(appointment));

}

lazyEventModel = new LazyScheduleModel() {

@Override

public void loadEvents(Date start, Date end) {

Date random = getRandomDate(start);

addEvent(new DefaultScheduleEvent("Lazy Event 1", random,

random));

random = getRandomDate(start);

addEvent(new DefaultScheduleEvent("Lazy Event 2", random,

random));

}

};

}

public Date getInitialDate() {

Calendar calendar = Calendar.getInstance();

calendar.set(calendar.get(Calendar.YEAR), Calendar.FEBRUARY,

calendar.get(Calendar.DATE), 0, 0, 0);

return calendar.getTime();

}

public ScheduleModel getEventModel() {

return eventModel;

}

public ScheduleModel getLazyEventModel() {

return lazyEventModel;

}

public ScheduleEvent getEvent() {

return event;

}

public void setEvent(ScheduleEvent event) {

this.event = event;

}

public void addEvent(ActionEvent actionEvent) {

if (event.getId() == null)

eventModel.addEvent(event);

else

eventModel.updateEvent(event);

try {

Appointment appointment=eventToAppointment(event);

appointmentDao.persist(appointment);

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

public void onEventSelect(SelectEvent selectEvent) {

event = (ScheduleEvent) selectEvent.getObject();

}

public void onDateSelect(SelectEvent selectEvent) {

event = new DefaultScheduleEvent("", (Date) selectEvent.getObject(),

(Date) selectEvent.getObject());

}

public void onEventMove(ScheduleEntryMoveEvent event) {

FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_INFO,

"Event moved", "Day delta:" + event.getDayDelta()

+ ", Minute delta:" + event.getMinuteDelta());

addMessage(message);

}

public void onEventResize(ScheduleEntryResizeEvent event) {

FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_INFO,

"Event resized", "Day delta:" + event.getDayDelta()

+ ", Minute delta:" + event.getMinuteDelta());

addMessage(message);

}

private void addMessage(FacesMessage message) {

FacesContext.getCurrentInstance().addMessage(null, message);

}

private Appointment eventToAppointment(ScheduleEvent event) {

Appointment appointment = new Appointment();

appointment.setDateFrom(event.getStartDate());

appointment.setDateTo(event.getEndDate());

appointment.setDescription(event.getDescription());

appointment.setTitle(event.getTitle());

appointment.setPacient(((Appointment) event.getData()).getPacient());

return appointment;

}

private ScheduleEvent appointmentToEvent(Appointment appointment) {

DefaultScheduleEvent event = new DefaultScheduleEvent();

event.setData(appointment);

event.setDescription(appointment.getDescription());

event.setEndDate(appointment.getDateTo());

event.setStartDate(appointment.getDateFrom());

event.setTitle(appointment.getTitle());

return event;

}

public String getSelectedListPacientId() {

return selectedListPacientId;

}

public void setSelectedListPacientId(String selectedListPacientId) {

this.selectedListPacientId = selectedListPacientId;

for (Pacient pacient : pacientDataHolder.getPacients()) {

if (pacient.getId() == Integer.parseInt(selectedListPacientId)) {

if (event.getData() == null)

((DefaultScheduleEvent) event).setData(new Appointment());

((Appointment) event.getData()).setPacient(pacient);

break;

}

}

}

public PacientDataHolder getPacientDataHolder() {

return pacientDataHolder;

}

public void setPacientDataHolder(PacientDataHolder pacientDataHolder) {

this.pacientDataHolder = pacientDataHolder;

}

public List<Appointment> getAppointments() {

return appointments;

}

public void setAppointments(List<Appointment> appointments) {

this.appointments = appointments;

}

public AppointmentDao getAppointmentDao() {

return appointmentDao;

}

public void setAppointmentDao(AppointmentDao appointmentDao) {

this.appointmentDao = appointmentDao;

}

}

Android Main activity XML layout

<TableLayout xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:id="@+id/AppointmentLayout"

android:layout_width="match_parent"

android:layout_height="match_parent"

android:layout_gravity="bottom"

android:background="@color/background"

android:paddingBottom="@dimen/activity_vertical_margin"

android:paddingLeft="@dimen/activity_horizontal_margin"

android:paddingRight="@dimen/activity_horizontal_margin"

android:paddingTop="@dimen/activity_vertical_margin"

tools:context="healthcare.client.MainActivity$PlaceholderFragment" >

<Space

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:layout_gravity="fill_vertical" />

<Button

android:id="@+id/button1"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:background="@drawable/generalbutton"

android:onClick="onEditProfileSelect"

android:shadowColor="#A8A8A8"

android:text="Edit Profile" />

<Button

android:id="@+id/button5"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:background="@drawable/generalbutton"

android:onClick="onAppointmentSelect"

android:shadowColor="#A8A8A8"

android:text="Appointment" />

<Button

android:id="@+id/button2"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:layout_marginTop="84dp"

android:background="@drawable/generalbutton"

android:onClick="onHeartMonitorSelect"

android:shadowColor="#A8A8A8"

android:text="Heart Monitor" />

<Button

android:id="@+id/button3"

android:layout_width="111dp"

android:layout_height="wrap_content"

android:layout_marginBottom="32dp"

android:background="@drawable/generalbutton"

android:onClick="startGraph"

android:shadowColor="#A8A8A8"

android:text="GRAPH" />

<Button

android:id="@+id/button4"

android:layout_width="189dp"

android:layout_height="wrap_content"

android:layout_marginBottom="16dp"

android:layout_weight="0.28"

android:background="@drawable/generalbutton"

android:onClick="startConnection"

android:shadowColor="#A8A8A8"

android:text="Alert" />

</TableLayout>

YUV to RGB decoding

package healthcare.client.heartrate;

/**

* This abstract class is used to process images.

*

*

*/

public abstract class ImageProcessing {

private static int decodeYUV420SPtoRedSum(byte[] yuv420sp, int width,

int height) {

if (yuv420sp == null)

return 0;

final int frameSize = width * height;

int sum = 0;

for (int j = 0, yp = 0; j < height; j++) {

int uvp = frameSize + (j >> 1) * width, u = 0, v = 0;

for (int i = 0; i < width; i++, yp++) {

int y = (0xff & yuv420sp[yp]) – 16;

if (y < 0)

y = 0;

if ((i & 1) == 0) {

v = (0xff & yuv420sp[uvp++]) – 128;

u = (0xff & yuv420sp[uvp++]) – 128;

}

int y1192 = 1192 * y;

int r = (y1192 + 1634 * v);

int g = (y1192 – 833 * v – 400 * u);

int b = (y1192 + 2066 * u);

if (r < 0)

r = 0;

else if (r > 262143)

r = 262143;

if (g < 0)

g = 0;

else if (g > 262143)

g = 262143;

if (b < 0)

b = 0;

else if (b > 262143)

b = 262143;

int pixel = 0xff000000 | ((r << 6) & 0xff0000)

| ((g >> 2) & 0xff00) | ((b >> 10) & 0xff);

int red = (pixel >> 16) & 0xff;

sum += red;

}

}

return sum;

}

/**

* Given a byte array representing a yuv420sp image, determine the average

* amount of red in the image. Note: returns 0 if the byte array is NULL.

*

* @param yuv420sp

* Byte array representing a yuv420sp image

* @param width

* Width of the image.

* @param height

* Height of the image.

* @return int representing the average amount of red in the image.

*/

public static int decodeYUV420SPtoRedAvg(byte[] yuv420sp, int width,

int height) {

if (yuv420sp == null)

return 0;

final int frameSize = width * height;

int sum = decodeYUV420SPtoRedSum(yuv420sp, width, height);

return (sum / frameSize);

}

}

Android Activity classes