76
1 Cross Platform Applications for Mobile Devices René Toft Jensen Kongens Lyngby 2010 IMM-B.Eng-2010-38

Cross-Platform Applications for Mobile Devicesetd.dtu.dk/thesis/268471/dip10_38.pdfCross Platform Applications for Mobile Devices ... The mobile application should be a light weight

Embed Size (px)

Citation preview

1

Cross Platform Applications for Mobile Devices

René Toft Jensen

Kongens Lyngby 2010

IMM-B.Eng-2010-38

2

Technical University of Denmark Department of Informatics and Mathematical Modeling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk

3

Abstract

In this thesis I describe how it is possible to make an application that fits all mobile devices on the market.

To prove my concept, I'm making a mobile version of an already existing piece of software running at

Frederiksberg Hospital.

The outcome of the analysis was a web based application running in a browser. Keywords around this

solution are reusable code and a fluent design. Data is retrieved through already existing web services, and

so the application design is handling the data and displaying it in a proper way.

Tests show that the chosen application design runs and fits all tested mobile devices as expected. Data is

easily extracted and performance-wise the application is doing well.

Based on my test results and the way the application is designed, the concept has been clearly proven.

More functionality can be added to this prototype application and also more screen sizes can easily be

supported by adding new style sheets. The application is therefore also future proof for both new mobile

devices and if new functionalities should be added.

The actual application can be viewed by going to the website - http://twerft.kedermig.dk

4

Resumé

I dette projekt beskrives det hvordan det er muligt at udvikle én applikation der kan køres på alle mobile

enheder. For at bevise det er muligt, udvikles en mobil version af et stykke software der allerede eksisterer

og testes på Frederiksberg Hospital.

Resultatet af analysen er en web baseret applikation der kører i en browser. Nogle nøgle argumenter for

denne løsning er genbrug af kode samt flydende og skalerbart design. Data hentes fra en allerede

eksisterende web service, og dermed vil applikationens design omhandle håndtering af data og vise denne

data på en fornuftig måde.

Testen viser at det valgte design kører og tilpasser sig fint til alle testede mobile enheder som forventet.

Data kan nemt udtrækkes og selve applikationens ydeevne er forholdsvis god.

Ud fra testens resultatet og hvordan applikationen er designet, er konceptet klart blevet bevist. Mere

funktionalitet kan tilføjes senere ligesom flere skærmstørrelser kan understøttes ved at tilføje nye style

sheets. Applikationen er derfor også fremtidssikret for både nye mobile enheder og nye funktionaliteter.

Selve applikationen kan ses ved at gå ind på - http://twerft.kedermig.dk

5

Preface

This thesis was prepared at Informatics Mathematical Modeling, the Technical University of Denmark in collaboration with Pallas Informatik A/S as partial fulfillment of the requirements for acquiring the B.Eng. degree in software engineering. The thesis deals with the issue of making one application that fits all mobile devices. Different aspects such as platform, screen sizes and type of mobile device will be discussed along with different design solutions. The entire span of the thesis is 12 weeks which is a workload corresponding to 20 ECTS points. The thesis supervisors are Jakob Eg Larsen from the department of Informatics and Mathematical Modeling at the Technical University of Denmark, and Rune Saaby from Pallas Informatik.

Kongens Lyngby, Oktober 2010 René Toft Jensen

6

Table of contents Introduction ....................................................................................................................................................... 8

Analysis ............................................................................................................................................................ 10

2.1 Platforms ............................................................................................................................................ 10

2.2 Screen sizes ........................................................................................................................................ 13

2.3 Analysis of application models ........................................................................................................... 14

2.3.1 Hybrid application ....................................................................................................................... 14

2.3.2 Web application .......................................................................................................................... 15

2.3.3 My choice .................................................................................................................................... 16

2.4 Interview ............................................................................................................................................ 17

2.5 Interaction .......................................................................................................................................... 19

2.6 Use cases ............................................................................................................................................ 21

2.7 Use case descriptions ......................................................................................................................... 22

2.7.1 Receive patient ........................................................................................................................... 23

2.7.2 Book examination ....................................................................................................................... 23

2.7.3 Get patient to- and from examination ........................................................................................ 24

2.8 Risk analysis ....................................................................................................................................... 24

2.8.1 System loses access to the web service ...................................................................................... 25

2.8.2 Human errors .............................................................................................................................. 25

2.8.3 Login ............................................................................................................................................ 25

Design .............................................................................................................................................................. 27

3.1 Views ................................................................................................................................................... 27

3.2 Multiple screen sizes .......................................................................................................................... 29

3.3 Application architecture ..................................................................................................................... 31

3.4 Application flow .................................................................................................................................. 32

Web Service ..................................................................................................................................................... 34

4.1 LogIn .................................................................................................................................................... 34

4.2 GetTeams ............................................................................................................................................ 35

4.3 GetTafder ............................................................................................................................................ 35

4.4 GetSenge ............................................................................................................................................. 35

4.5 GetPatienter........................................................................................................................................ 35

4.6 GetPatientEvents ................................................................................................................................ 36

7

4.7 CreatePatientEvent ............................................................................................................................. 37

Implementation ............................................................................................................................................... 39

5.1 Methods.cs.......................................................................................................................................... 39

5.2 List View .............................................................................................................................................. 41

5.2.1 Default.aspx ................................................................................................................................. 41

5.2.2 Default.aspx.cs ............................................................................................................................. 42

5.3 Patient View ........................................................................................................................................ 43

5.3.1 Patient.aspx ................................................................................................................................. 43

5.3.2 Patient.aspx.cs ............................................................................................................................ 45

Test .................................................................................................................................................................. 48

6.1 Use Cases ............................................................................................................................................ 48

6.2 Compatibility ....................................................................................................................................... 50

6.3 Functionality ....................................................................................................................................... 52

Future Work..................................................................................................................................................... 53

Perspectivation ................................................................................................................................................ 55

Conclusion ....................................................................................................................................................... 57

8

Chapter 1

Introduction

Whether it is handheld PC’s, iPads or smart phones; the amount of new mobile devices hitting the market is

increasing rapidly. New technologies and hardware is used and different companies use different operating

systems on their devices. There are tons of differences between the devices, and the possibility to write

one application that would apply to them all seems a tough task to comprehend. However the need to

make such application is much desired by many companies since it’s a time- and money saver compared to

writing specific applications to all devices. The focus of this project will be to examine the possibility to

write this type of application and as proof this can be achieved, a mobile version of Afdelings Tavlen will be

developed.

Afdelings Tavlen is a system currently used at Frederiksberg Hospital to create an overview of the patients

at the Acute Admission Department. The application shows information about all patients such as name,

diagnose, severity of condition, treatment plan, in which bed the patient is staying and so on. This

information can be changed throughout the patients’ hospitalization, and each interaction made in the

application is stored in a history log.

At times, the hospitals staff would find it useful if they could bring the information from Afdelings Tavlen

with them to the patient. And this is where the cross platform application for mobile devices is a solution.

The mobile application should be a light weight version of the current application but still hold all the

necessary information needed by the staff. It should be light weight in the sense that typing text

information into the system is limited. First of all, the majority of text input is written into the system

before the patient arrives at the hospital, this includes the patients name, CPR, home address, diagnose

9

and treatment plan etc. All this information will be submitted by a secretary through the stationary version

of Afdelings Tavlen, hence it’s not really needed to type text input when you’re actually next to the patient,

and therefore we limit the mobile version to only handle touch based input. For this same reason, the

project has been limited to focus solely on devices with touch screen functionality.

In this report I’ve started out analyzing the different operating systems currently on the market and

hereafter I’ve given my thoughts on a few possible application models, and I explain which model I’ll be

using and why. I’ve also been looking into what the current Afdelings Tavle can do, and what my mobile

version should be able to do. I will explain the design choices I’ve made and what I’ve done to make the

application apply to different devices. I’ll explain some key components in the system, and follow up by

testing not only the program functionality, but also its compatibility with different handheld devices. Before

the conclusion I’ll discuss different perspectives surrounding the system such as what impact this system

would have on the staff’s daily routine. Lastly a conclusion will sum up the entire project.

The final application can be viewed by going onto - http://twerft.kedermig.dk

10

Chapter 2

Analysis

If our application has to reach as many devices as possible, it’s important that we can reuse as much of the

same code on each device as possible. This will reduce the amount of work required to make the

application work on the different platforms. First and foremost I’ve tried to determine what type of

operating systems is currently on the market and what development languages they can utilize. I’ve also

looked at different screen sizes and how this can affect my application. Lastly, with all the information I

gathered I’ve studied different types of application models in order to find out how the application should

be build and which model will fit our needs in the best possible way.

Concerning the actual application, I’ve analyzed what it should do, what technologies are available and how

it should be different- or similar to Afdelings Tavlen.

2.1 Platforms

We are working with mobile devices with touch screen functionality. These devices include smartphones

such as the iPhone and Android phones etc, but also the iPad or even handheld PC’s running a regular copy

of the Windows XP operating system or a newer OS from Microsoft. The handheld PC doesn’t work any

different compared to a normal PC. The only difference is basically its size and touch screen. The handheld

11

PC also offers a range of standard PC capabilities such as USB connection and Wi-Fi to connect to the

internet, all in all it’s very much like a normal PC and therefore it shouldn’t be a huge problem to port the

application to this device since everything will more or less run on a Windows operating system.

To mention the iPad shortly, it runs on Apples MAC OSX which is basically the same operating system that is

used for iPhone and regular MAC computers. An application developed for the iPhone will therefore also

run on the iPad. The only trouble will be fitting the application with the different screen sizes, but we’ll get

to that later on.

I’ve made a thorough market and platform analysis which can be found in Appendix A, and from the

analysis I’ve derived a chart that sums up the differences between the platforms. It can be seen bellow in

figure 1.

12

Figure 1: And overview of the different Operating Systems currently on the market and their differences.

iPhone Android Windows Mobile Symbian Blackberry/RIM Palm webOS

OS Version iOS version 3.x, 4.x for iPhone 4, 3GS and 3G

1.5 1.6 2.0-2.1 2.2

WinMo 2003 WinMo 5 WinMo 6.5.x Windows Mobile 7

Symbian OS 6, 7, 8 Symbian OS 9.5 (2007) Symbian^1 Symbian^2, ^3, ^4

RIM 4.x.x RIM 5

1.4.x

Programming Language

Objective-C With Apple’s SDK incl. Xcode, Interface Builder and a simulator

Java/XML With the Android SDK which has an included simulator.

C++, C#, VB The new Windows Mobile 7 phone will support Silverlight and apps made in Blend

Mostly C++ (Symbian C++), but Python and Perl is supported

Java, or BlackBerry Web Development using HTML and scripting languages

C, C++, HTML and Scripts using Palm’s Plug-In Development Kit (PDK)

Browser Safari, no flash support, based on webKit

Based on webKit, other browsers can be downloaded

Mobile version of Internet Explorer

Based on webKit BlackBerry browser, others can be downloaded.

Based on webKit

Customer satisfaction

71% 67% 24% Not in the survey 37% 57%

Facts, positives and negatives.

- Big market - All devices are the “same” - Well documented SDK - Requires a MAC and an iPhone developer license - Will need approval from apple in order to publish apps to the AppStore - Steep learning curve for Objective-C

- Growing market - Developing for android is easy to learn - Open Source - Android is shipped on a wide range of devices, which makes it more demanding for the programmer to adapt his apps to different screen sizes and keyboards etc.

- Good documentation on Microsofts website - The development opportunities with Windows Mobile 7 is promising - Bad customer satisfaction. - Not that many devices with this OS on the market, compared to others. - Mostly on PDA’s or other business oriented phones

- The wide range of development languages and different devices using Symbian. - no popular smart phones

- Mostly on PDA’s and business oriented phones

- Applications are based on scripts and HTML. - Easy and fast development. - Some limitations to application functionality due to everything running on scripts.

13

The chart more or less speaks for itself, but it’s worth mentioning a few key facts about some of the

operating systems. First of and most importantly, it’s impossible to find any similarities between the

different operating systems and their native development languages. The languages range from Objective-C

to Java, C# and scripting. However for each operating system, it is possible to develop in another

programming language than the native one. With MonoTouch from Novell for example, you can make .NET

applications for your iPhone and this is actually quite well documented on the official MonoTouch website.

For the most part however, developing in another language than the native ones does require some

tweaking of the devices in order to make it work properly and mostly this kind of tweaking lacks some

proper documentation. It’s therefore not advised to take this approach when making an application for a

certain device, unless you want to explore the potential of the device to the fullest. For the same reason it

will be very difficult to make one application that will fit several platforms.

One thing most of the platforms do have in common is their browser which is based on the webKit engine.

This means the browsers will handle certain events in the same way; browser history, back-forward list and

links clicked etc but also HTML will be rendered the same way. So if we stay clear of flash, a website shown

on an iPhone will look similar to the same site shown on an Android based device. All in all, the browsers

act the same way which will make it easier to make a mobile website that will work on the various smart

phones on the market.

2.2 Screen sizes

Besides the challenge of writing an application that fits multiple platforms, comes the challenge of fitting

the same application to the different screen sizes and user input methods of the devices. Since I’ve chosen

to focus on smart phones with touch screen functionality, the challenge of fitting the application to

different user input methods is easy manageable since the only physical buttons these phones have, are

the ones used for standard phone navigation such as returning to your home screen or opening a settings

panel. Fitting the application to different screen sizes is another matter.

If you write an application in the phones native language, it isn’t a big problem to make it fit different

screen sizes. The UI Frameworks can handle this resizing of the layout for you as long as your code is done

properly with the use of device independent pixels (dip)1. Using dip to define an application’s UI is highly

recommended as a way of ensuring proper display of the UI elements. If you combine the use of dip with a

layout to place the elements relative to each other, you’ve made a UI that will display the same way on all

kinds of screens. It’s possible to develop after this principle on all the platforms and even if you develop in

another language than the native one, that language will still utilize the standard UI framework of the

phone in one way or another. When developing a native application, you should always make your UI like

1 A dip is a virtual pixel unit that applications can use in defining their UI, to express layout dimensions or

position in a density-independent way.

14

explained above; simply because it makes your UI robust as well as making sure the application will still

look good on future screens.

If you’re making a web based application, or mobile website, you won’t get so easily around fitting the

application to different screen sizes. It requires a little more programming and a few CSS files to define the

layout, but it can be achieved by using relative measures when positioning and sizing elements.

2.3 Analysis of application models

The proof of concept application I’m building, gets its data through a set of .Net Web Services, therefore

the device needs to be connected to the internet at all times. Hence a Wi-Fi connection is vital in order for

the application to communicate with these services to renew its data. Fortunately most portable devices

have some sort of built in Wi-Fi adapter to allow for this connection.

It’s important to investigate different types of application models in order to find out which one fits our

demands in the best possible way. I’ve looked into two different types of models that each have their own

advantages and disadvantages.

2.3.1 Hybrid application

This type of model requires a part of the application to be written in native code, namely the GUI and web

service handling, and another part which is reusable, being the web service of course. The web service

handler/interface is needed to transport data to and from the web service. Since the web service will be

the reusable part of the application, the way we handle it needs to be written in native code. Bellow you

can see a drawing of the whole system, figure 2.

15

Figure 2: Hybrid application design.

The down part is that we still need to do device specific coding when coding the GUI and the interface

layer, and it will be a time consuming task to write the GUIs for all devices.

With this application type, we have the opportunity of making a graphically well designed application that

will be fast and easy to use. The only limitation in how fast the application will run, is how fast the web

services respond to requests, but that’s something we can’t prevent no matter what type of application is

chosen.

The handling of web service calls and the logic is the big part of this system and a large amount of time

should be dedicated to developing this. The GUI part is finding out how we should present our data in the

best possible way, it should feel intuitive for the user.

It all sounds like a nice solution, but we need to be able to run the application on many platforms, and since

we need to code the web service handling and GUI in the devices native language it will be time consuming

and not really cross-platform. The solution would be excellent though, if one could agree on what platform

we should be targeted.

2.3.2 Web application

This is actually a website optimized for mobile devices. The optimization means we need to cut down the

use of data heavy objects, images, the amount of page loads needed to obtain the information you’re

looking for and we need to make the website apply to all screen sizes.

For this solution we would be coding the website in HTML, CSS and Java Script. All the logic is handled by

the interface to the web service. The system should look something like what is displayed on figure 3

bellow.

16

Figure 3: Web based application design.

How the website looks on each device is device specific. A HTML button on an Android based device will

look slightly different than the same button on an iPhone for example. Fortunately the popularity of the

webKit framework will make the website look almost similar on each device because it renders HTML the

same way.

The architectural design of the web application is somewhat similar to that of the hybrid application. The

big and important difference is, that in the web application we use a browser to display our data which

makes it cross platform in the sense that we only need to write one application.

This solution would be the easiest to implement and it will work on all devices, however the grade of

functionality will be reduced and the user experience will suffer since we can’t make a beautiful UI that

performs as fast as the UI on the hybrid application. Every time we click a button or a link, it’s not just a call

to the web service that hinders the program, it’s also loading in all the HTML and it can slow down the

program.

2.3.3 My choice

I have chosen to make a web solution. There are simply too many differences between the various

platforms to make anything else possible. The hybrid application requires too much native code which will

make it a very time consuming task to implement. Trying to write code in another language than the native

one won’t work as well. The different frameworks will make it impossible to port a C# application, made

with MonoTouch for the iPhone, over to Windows Mobile. Same story for an Android Java application, it

can’t be ported to a BlackBerry phone without making lots of changes to the application.

The only solution is to make a web application. One interesting project has crossed my eyes when doing my

research. PhoneGap is a cross platform collection of tools that wraps around a web application and turns it

17

into a stand-alone application. The project has constructed native wrappers for the major smartphones,

and in theory it's possible to write one web application that could be converted into a stand-alone

application for each platform. This simply sounds too good to be true, and although I haven’t fiddled with

these tools yet, I’ve chosen to discard the idea anyway. There’s a lot of work involved in setting up all the

environments for all the devices you want to use the tool for. You need to set up PhoneGap for Eclipse to

do Android, set it up for Xcode to do iPhone and so on. Also, there’s a lack of information on how to code

with PhoneGap in general and judging from the comments I read about the tools, people are complaining a

lot about errors they can’t solve. It would simply be too risky to work with in my case.

I’ve chosen to make my web application around a .Net environment, more precisely ASP.NET with Visual

Studio. I’ve chosen this since the web services I’m using are .Net web services, and therefore it’s natural to

use Visual Studio and ASP.NET to easily connect the web services with the rest of the application.

2.4 Interview

The following is the short interview I did with the head nurse of the Acute Admission Department. My

questions are written in black, and the answers are colored blue.

1. How does Afdelings Tavlen make your day at work better?

Creates a better overview, and better patient security.

2. What is the most common task performed on Afdelings Tavlen?

Type what you have done at the patient, but we still need to write a handwritten journal.

3. Do you have any suggestions as to what would make Afdelings Tavlen even better?

Get more information from it. Fx. If you could see x-ray photos or just a description of the x-ray

photo would be enough for the doctor to make a decision. This could spare a phone call or a walk

to the x-ray department.

People sometimes forget to type in different things when they’ve been visiting a pation, but that

could be solved if you could take the Afdelings Tavle with you to the patient and type in it next to

him.

Better monitors and the touch screen would be handy.

Sometimes it’s a little bit slow. It would be nice that the information you’re looking for will be

shown the second you push a button.

4. Do you have a need to bring Afdelings Tavlen with you when you’re visiting a patient?

That would be a very good idea. As I mentioned before, if you could take the x-ray description or a

blood test result with you to the patient, you could spare a phone call.

18

5. Could a mobile version of Afdelings Tavlen make working more efficient?

It depends on what it can do. If there’s a test result where we need to make a decision, it will make

the process faster because we don’t need to make a phone call or walk down to another

department.

Sometimes you need to wait at the stationary version if another person is using it. Not everyone is

as good as waiting, so they might forget to type in their data and it’s very important that the data

we get is the newest.

6. What information would you need on a mobile version of Afdelings Tavlen, and is there any functionality

you don’t need on the mobile version compared to the current version?

We use all the information available on the current Afdelings Tavle. Hospitalization method, course

and plan for the patient. Everything is used and nothing can be removed.

7. Try and describe how you would use the mobile version when you’re standing at the patient.

1. Pick up the device and login.

2. Check if it’s the correct patient by CPR number

3. Check x-ray and blood test on the device

4. Check if there’s a result from the tests done at the pulmonary department.

5. Change the patient status - you can go home today or you need to stay one more day etc.

6. Type in that you’ve visited the patient.

7. Ask if there’s anything else you could assist with? Order a cab if the patient can go home for

example.

8. Check the last data to finish visiting the patient.

9. Logout.

8. How much would doctors use this mobile device?

Review and order x-ray photos, order specialists and check up on patients.

We can draw a few quick conclusions when reading the answers to this interview. She mentions that no

information can be spared between the current version and the mobile version of Afdelings Tavlen. It might

prove challenging to include all functionality and information onto a small screen, but when I was fiddling

with the stationary version myself, I concluded that there is a few things I can cut down as they are not

largely necessary for the intended use of the mobile version. For example, I am assuming that the patient a

nurse is going to visit has already been checked in. Hence, the functionality to check in patients can be

discarded in my case.

She also mentions a new functionality that she would find very handy. The possibility to view test results

directly on the mobile device. This is not even implemented in the stationary version of the program, and

so it’s out of my scope to take up this task even though she mentions it 3 times and stating how important

it would be. Also in question 7, she talks like the functionality is already implemented when she says:

19

“4. Check if there’s a result from the tests done at the pulmonary department.”

Despite this the answers given in question 7, the interview gives me a good insight in how they perform

their work at the patients. She doesn’t mention what buttons she presses, but she gives a chronological

view of the whole process which is useful when making my use cases and ultimately the final design.

The last thing worth mentioning is that the current stationary version runs a bit slow at times. Performance

is a huge factor when making mobile applications, or just any application in general, so hearing her saying

this, has made me even more aware of the problem. If it shows on the stationary, who knows how it will be

on a mobile device.

2.5 Interaction

Figure 4 shows a screen dump of a part from the current Afdelings Tavle. When There are two ways of

interacting with Afdelings Tavlen, via mouse clicks and keyboard input. When we click the patient’s name, a

window appears wherein we can enter text input to various categories. But skipping that part, and looking

at the screen dump we see some buttons that can be clicked to make certain changes. It is this mouse click

part of the current Afdelings Tavle that is most interesting for my case. The reason for skipping the text

input part, is that writing text on an on screen keyboard can be difficult and mistyping frequently occur to

an inexperienced user, but most importantly most of the text input written to this system is done before

the patient has even arrives at the hospital by a secretary. This text input include the patients name, CPR,

home address, diagnose and so on. The text input is therefore discarded in the mobile version, and we

focus more on the touch based interaction of the system. Below is a view of one patient from Afdelings

Tavlen. This view contains all the information my mobile version should hold and I’ve explained what each

element means to give an idea of what the application can do.

Figure 4: Web based application design.

1. The top letter “B” displays what special unit the patient is linked with. The background color is

changed according to what special unit is selected. Bellow the numbers “01.1” indicates the patient

20

is in bed 1 of ward 01. The clock shows when the patient arrived at the hospital and how long he’s

been there.

2. The name of the patient. Can be clicked to get a window where text input can be made.

3. The patient’s diagnosis.

4. The patient’s treatment.

5. The patient’s age.

6. The patients triage. Can be stable, partly stable and unstable which equals the colors white, blue

and red accordingly.

7. This button deals with the reception of the patients. It is white if the patients hasn’t arrived at the

hospital yet, turns red when he’s there and green when the initial papers has been filled.

8. This button shows whether the patients’ journal has been created.

9. This button indicates whether or not the patient has had his first review performed by a doctor.

10. This button indicates if the patients need more reviews.

11. This button is used to assign specialists to the patient.

12. These buttons appear when a specialist has been assigned to the patient. The red button “U”,

indicates that a specialist has been assigned but he hasn’t visited the patient yet. The other green

button shows that the particular specialist has already visited the patient. The green button can be

clicked once to make it go away.

13. From this button you can order special examinations.

14. Shows what examinations have been ordered. The red button shows the patient is waiting to be

picked up, blue indicates the patient has been picked up and the green button indicates the patient

is back in his bed.

Worth noting are the initials “ASP” that appear on the buttons 7 - 9, this shows who have performed that

particular action at the patient. In my case, the interactive part of the system will be the numbers 6 - 14.

Fortunately the interaction in this part of the system is pretty much what I’m looking for in my mobile

version since it is one click interaction almost everywhere.

Later on when I talk about the chronological flow of a patients’ hospitalization, I mean the flow from

buttons 7 - 10 in the above figure. Naturally a patient is received before anything else happens to him,

that’s button 7. Afterwards a journal is created - button 8, a Review is done - button 9, and finally frequent

ward rounds can occur - button 10. This is the normal flow of a patients’ hospitalization, but exceptions can

be made and ordering specialists and examinations can be carried out at any time.

21

2.6 Use cases

Below is a figure of the most important functionalities the staff makes use of.

Figure 5: The most important use cases

There are two other use cases as well, but I didn’t include them in the figure above since it is features all

the actors can make use of. The last two use cases are changing a patient’s triage and selecting a patient

from a list. In the table on the next page I’ve described what each use case is about.

22

Use Case

Description

Receive patient

A patient is on the way to the hospital, and the nurse will receive him once he is there.

Ward round The nurse checks up on the patients. This can be done many times during the whole process. The frequency of visits depends on the patient’s triage.

Journal entry A doctor creates the patients journal.

Patient Review A doctor examines the patient.

Book examination The doctor books an examination. X-ray, blood test etc.

Assign specialist The doctor can assign a specialist which can depend on test results.

Get patient to- and from examination

A porter picks up the patient at his bed, and gets him to the booked examination and back again.

Specialist examination The examination is done by the assigned specialist. It could be a cardiologist checking on a patient.

Triage How critical is the patient condition. Ranges from stable, partly stable and unstable.

Selecting a patient Select a patient from a view of all the patients that are hospitalized.

2.7 Use case descriptions

This part contains fully described use case descriptions. This means, the above mentioned use cases will be

described with thorough details so it is clear what actions the actor performs. Later on I will use these

descriptions to develop my application, because then it’s clear what bahavior I should implement. In all

cases, I’m assuming the user of the device has logged in. Only the most interesting use cases are put here,

the rest can be seen in Appendix B.

23

2.7.1 Receive patient

Actor Nurse

Precondition The patient has been submitted into the system and has just arrived at the hospital. A white button shows the patient is waiting to be received by a nurse.

Post condition The application shows the patient has been received and who has received him. A new red button will appear bellow to indicate the patient is ready for his journal to be created.

1. The nurse makes sure she’s at the right patient by checking his CPR-number. She then selects the patient from a list.

2. The nurse clicks the white button once she has guided the patient to his bed. The button now turns red to indicate the patient is waiting to be visited.

3. From the original Afdelings Tavle, a nurse is assigned to visit this patient. The red button will now have the assigned nurse’s initials next to it to indicate who should go and visit the patient.

4. The nurse clicks the red button to indicate she has visited the patient. The nurse’s initials still appear on the button and the button turns green to indicate the visitation is finished.

2.7.2 Book examination

Actor Doctor

Precondition The patient has been submitted into the system and has arrived at the hospital. He needs an x-ray examination.

Post condition A red button with the letters “Rtg” inside appears next to the booking button.

1. The doctor clicks on the drop down list for making special examinations. 2. From the list that appears, the doctor selects the “Rtg” option.

24

2.7.3 Get patient to- and from examination

Actor Porter

Precondition A doctor has booked an x-ray examination; a red button with the letters “Rtg” inside shows this.

Post condition The button turns green to show the patient is back in his bed after the x-ray examination.

1. The porter makes sure he’s at the right patient, and selects him from the list view.

2. The porter picks up the patient, and indicates this by selecting “Rtg” from the drop down list. The

button will now turn blue to indicate the patient has been picked up.

3. After the x-ray examination is done, the porter drives the patient back to his bed. He then selects

“Rtg” from the drop down list once more and the button turns green to indicate the patient is back

from the x-ray examination.

Side note: Multiple examinations can be ordered. If there is more than one, the buttons will appear next to

each other.

2.8 Risk analysis

There’s a lot of risk analysis to be made for an application for the medical industry. To limit the size of this

project, I’ll only analyze a few aspects. Legal issues and ensuring the security of the patients’ data have

been excluded from my analysis since analyzing these risks is too big a subject to cover. Below are a few

sections of potential threats to this application with a short description of each threat. The frequency is

how likely the threat is to happen, and the severity is how severe the impact will be on the system should

the threat become reality. Frequency and severity is getting points on a scale from 1-10 where 10 is very

likely or very severe.

25

2.8.1 System loses access to the web service

Frequency/Severity 3 / 7

What causes this Device hardware- or wireless router malfunction or server shut down.

What happens We lose the ability to update data, whether it be fetching data or adding new data.

Impact The severity depends on what caused the application to lose its access to the web server. If it’s a device hardware malfunction, try another device. If it’s a wireless router malfunction, then again it wouldn’t be a huge issue since you can retrieve and add new data from the stationary version. Unless this is also running on the wireless network. If the servers shut down, the nurses and doctors will have to stick with the old ways where they did everything by pen and paper. When the hardware is back up and running, they can manually re-enter all the data they collected during the down period. The biggest threat however, is that the doctors and nurses won’t have access to the newest possible data stored on the servers. This can lead to mistreatment which can cause deteriorating health for the patients, or worse. Fortunately the staff still makes physical journals all the time, so the severity isn’t as big a problem as initially assumed.

2.8.2 Human errors

Frequency/Severity 10 / 2

What causes this Miss clicks, or miss typing.

What happens Wrong data.

Impact Miss typing can always be undone with help from the undo functionality in the stationary version. However, if the person who made the miss typing is unaware that he did it, incorrect data will be shown in the system. This can, as in the previous risk, cause mistreatment of the patient.

2.8.3 Login

Login is crucial for this system. One could argue that each doctor is assigned his own device, and hence

login isn’t required because the system will know who is performing the task by knowing each device. This

26

is true, but what if this device was stolen? Then the thief would have access to all the patient data and he

can make all the changes he wants to. Therefore a secure login procedure is absolutely necessary and

statutory. However to reduce the amount of work for this project, I’ve decided to leave this matter and flag

it as an improvement for the future.

27

Chapter 3

Design

The following sections will describe the layout design choices and how I make them apply to different

screen sizes. I will also explain the main architecture of my application, and how the flow of the entire

application is.

3.1 Views In the original Afdelings Tavle, all the beds and patients are shown in one single view. Because of the

limited size of handheld devices, I’ve had to come up with a different solution. What I’ve done is, creating

two different views, a List View showing all patients, and a Patient View showing all information about a

single patient.

The list view should simply show all patients and only the most important information such as in what ward

and bed the patient is staying, his CPR number, triage and of course his name. In Afdelings Tavlen, beds

have been grouped together in teams and this grouping should also be visible in the ListView. The intended

use for the List View is that the staff will quickly be able to find their patient and identify him by checking

his CPR number. When they click on the appropriate patients’ name, they will be redirected to a page

showing all the information about that patient - this is the Patient View.

Since the nurses and doctors are already used to working with Afdelings Tavlen, the actual layout of the

Patient View should be as close to that as possible. Working with two different designs of an application

28

that’s more or less designed to do the same job is inappropriate. I began looking at how the Afdelings Tavle

shows a patients information, and then made a mock up of how I want my design to look. The mock up can

be seen below on figure 6.

Figure 6: Left figure is a mock up of Patient View, right figure is how the

patients information is shown in the original Afdelings Tavle.

When comparing the mock up of the Patient View with the information shown about a single patient in the

Afdelings Tavle, it’s easy to spot the similarities and hopefully the end user will feel the same way. With the

numbers shown on the figure, I will explain what each element is.

1. The special unit the patient is committed to, and it shows the ward and bed he’s in.

2. The patients name, and bellow it shows when he arrived at the hospital.

3. A drop down list showing the patients triage, and you should be able to change his triage in this

element as well.

4. Reception button.

5. Journal Entry button.

6. Patient Review button.

7. Ward Round button.

8. Drop down list where you can order examinations.

9. Drop down list where you can assign specialists.

10. Go back button, to return the user to the List View.

All the button and drop down list elements explained above will be used later on with their given name for

easy reference.

The plan is to support both landscape and portrait display of the program, but when looking at figure 6 it’s

easily noticed that the program would probably look best in landscape mode.

29

3.2 Multiple screen sizes

To make my application apply to multiple screen sizes, I have to know what screen resolutions to work

with. I’ve taken a look at the screen sizes of some smart phones currently on the market and made a chart

which can be seen on figure 7 below.

Smart phone

Height x Width (pixels)

iPhone 4

960 x 640

Motorola Droid X

854 x 480

Samsung Galaxy S, HTC Desire, HTC HD2

800 x 480

Nokia N97

640 x 360

BlackBerry Storm 2 9550

480 x 360

iPhone 3GS, Palm Pre

480 x 320

HTC Tattoo

320 x240

Figure 7: Shows screen sizes of some of the well known phones on the market.

The screen sizes in the chart above, is the ones I will target for my application. It’s worth noting that all the

smart phones mentioned, have a built in accelerometer which allows the given phone to be in either

landscape- or portrait mode. Besides the smart phones shown above, I’m also targeting the Archos 9 which

is a handheld PC running a regular copy of windows. The Archos 9 has a screen resolution of 1024 x 600.

As we can see from the chart, there’s a big difference in screen resolutions between the smallest and

largest. What’s further noticeable is the different devices have different dpi. The Archos 9 has a screen size

of 8.9 inches whereas the iPhone 4 has a screen size of 3.5 inches, but their resolutions are almost the

same. This diversity will have to be managed in some way, and what I’ve done is separated the resolutions

into different groups as seen below.

Small screens Medium screens Large screens

320 x 240 960 x 640 854 x 480 800 x 480 480 x 360 480 x 320

1024 x 600

Initially I did put the resolutions 480 x 360 and 480 x 320 in the small screens category, but when testing I

found that the application looked a lot better with the style sheet used for the medium sized screens.

30

I’m targeting one device for which I will make a reference design. I’ve chosen the HTC Desire, meaning I will

make the application and optimize the design for this device and use it as a reference design for the other

device groupings. The reference should still adapt perfectly to the rest of the devices in the same grouping.

Designing the application this way, should keep the design process more simple and with style sheets I

should be able to control the layout of the different devices groups once the reference design is finished.

This means that a style sheet for each device group is necessary along with a script to measure the screen

sizes in order to find out what style sheet should be used. Avoiding pixel and absolute measures is also

necessary. Instead, percentages and relative measures such as larger or bolder would be preferable.

31

3.3 Application architecture

This chapter explains the main architecture of the application. Figure 8 bellow shows the different classes

and pages used and their relation to each other. The application is divided into a Web Service part, an

interface to handle the communication between the Web Service and GUI, and of course the GUI itself.

Figure 8: The application architecture

The classes Event.cs and TimelogEvent.cs are merely two different types of objects. They’re needed when

we extract and sort patient events from the database. Everything that happens to a patient is stored in the

database as patient events of different types. Events.cs corresponds to most of the events but the

TimelogEvents are a little different and thus requires its own object.

Methods.cs is a class that holds a few methods that are used in both code behind files, Default.aspx.cs and

Patient.aspx.cs.

The page Default.aspx corresponds to our previously mentioned ListView and when our application

launches, it will start in this view. It only makes use of one style sheet even though we previously discussed

why we need a style sheet for each grouping. The reason for only having one style sheet in the list view is

simple. It only shows a scrollable list of patients and since the size and width of the elements shown on this

page are relative to the screen resolution and as lists has no height limits, only one style sheet is needed.

The code behind file Default.aspx.cs feeds the ListView with data from the Web Service.

32

Patient.aspx is equivalent to the PatientView. It makes use of three different style sheets, one for each

device grouping. The appropriate style sheet is applied when the page loads as a script measures the screen

size of the device trying to use the application. A lot of controls are added on this page, and thus a lot of

event handling takes place as well. The code behind file to Patient.aspx handles all these events and data

to- and from the web service.

3.4 Application flow

This section will explain the natural flow of the application and figure 9 below shows a flow chart where

this exact flow can be seen. The yellow diamonds shows when a user interacts with the application, the

green squares represent what the applications does and the red boxes show what calls- and when the web

service is called.

Figure 9: Shows the flow of the application.

33

The figure should be viewed from the top and down. The application always starts by loading the List View,

and to populate the list we call a series of web service methods. From the List View, you find the patient

you’re looking for and click on his name. His name functions as a link to that patients own and unique

Patient View page. The Patient View is populated by calling another set of web service methods, and from

here you have several options to interact with the program. You can either go back to the List View by

clicking the “Tilbage” button or refresh the Patient View to get the newest data by clicking the “Refresh”

button. Lastly you can perform an action, but before doing that, a member of the staff has visited the

patient to do either a journal entry, review or assigned a specialist etc. When he’s done, he clicks the

appropriate button, or selects the appropriate action from a drop down list to indicate he’s performed that

action. This will cause the application to call the web service to add the event, afterward the Patient View is

updated to show the newly performed action. A full update of all data isn’t done in this step, only the

particular control holding the information about the updated event is being updated. To make a full

update, the refresh button must be clicked.

34

Chapter 4

Web Service

I this section I will quickly describe the web service methods I use in my application. One thing all the

methods have in common is, they all take a GUID, ID and a DateTime as parameter. The GUID is needed in

every other web service method call as a basic security measure. An ID can be specified to only extract the

object matching that ID, and the DateTime means that only objects later than the specified DateTime will

be returned. All methods return a result type that contains an error code and description to tell us whether

the method call was successful or not.

4.1 LogIn

This method is used to log in to the system and to give the user his GUID which is used in all other method

calls. To call this method a user name and password is naturally necessary, but since I currently don’t

support any login system, these parameters are hard coded into the method call. Hence the same user is

always listed as the one who performed an action it the history log.

When calling the method, a bunch of information is returned about the user who logged in. The only

information I’m interested in is the GUID which is generated when a user logs in.

35

4.2 GetTeams

The hospital staff is divided into teams of nurses and doctors. Each team has a certain amount of beds

associated with them which they take special care of. This method returns all teams or a specific team if

that teams ID is written as parameter when calling the function.

4.3 GetTafder

This method gets a specific- or all departments/special units that a patient can be associated with.

4.4 GetSenge

Will return a number of beds depending on what parameters the method is called with. A specific bed can

be returned by specifying the ID of the bed or the ID of a patient. All beds associated with a team can be

returned by setting the team ID. If all the beds should be returned, simply set all the mentioned parameters

to -1.

4.5 GetPatienter

Returns a specific- or a list of patients depending on the parameters the method is called with. A specific

patient can be returned by specifying his ID or CPR-number, whereas a list of patients can be returned by

specifying a department ID, first name or last name. Again, all patients can be returned by setting the above

parameters to either -1 or empty where parameters taken should be strings.

36

4.6 GetPatientEvents

This is the most used method in this application. It gets the events surrounding a specific patient, or just all

events for all patients in the system. The method call looks like this:

Just like all other methods, the GetPatientEvents also takes a GUID and an ID to extract only one specific

event. Next there’s the ptntID which will return all events associated with a specific patient. The evtpID

returns all the events corresponding to that event ID. The return type PtntEventsRec is a List of

PtntEventRec2, and it will hold all the returned patient events.

The PtntEventRec object holds information about one specific event. This information includes an ID,

patient ID, event ID, an XML string, who created the event and a DateTime for when it was created. There

can be several types of events and depending on the value of evtpID, the format of the XML string changes.

I’ve made a table to show the different event types and given an example of how the XML string will be

formatted accordingly. The table is on the next page.

2 Notice the difference. PtntEventsRec is the whole List, whereas PtntEventRec is one patient event.

PtntEventsRec GetPatientEvents(Guid guid, int ID, int ptntID, int evtpID, DateTime modifiedAfter, out TWError result);

37

evtpID XML string

Meaning

1 <Diagnose>KOL i xac.</Diagnose>

Diagnosis

2 <Plan>Akut EKG, blodprøver</Plan>

Treatment

3 <Tilsyn>H1</Tilsyn><Status>Bestilt</Status>

Specialist

4 <Tele>1</Tele>

Tele

5 <Tidslog>Spl. Anamnese start</Tidslog>

Timelog

6 <Isolation>0</Isolation>

Isolation

7 <Kørsel>0</Kørsel><Modtaget>0</Modtaget><Faxes>1</Faxes>

Medicinlist

8 <Kørsel>0</Kørsel><KorselsKrav>3</KorselsKrav><Bestilt>0</Bestilt> <EgetHjem>1</EgetHjem><TilHosp>1</TilHosp> <Adresse>Helsevej 3 Stednavnet 9876 Testby</Adresse>

Driving

9 <Stabilitet>2</Stabilitet>

Stability (triage)

10 <VisitationsPlan>Ingen</VisitationsPlan><Haendelse>0</Haendelse> <Øremærket>0</Øremærket>

Visitation plan

11 <Undersogelse>Rtg</Undersogelse><ENUM>1</ENUM> <Status>Bestilt</Status><Year>2009</Year><Month>11</Month> <Day>3</Day><Hour>0</Hour><Minute>0</Minute>

Examination

12 <Orlov>Kommer mandag</Orlov><Status>1</Status>

Leave

Figure 10: Shows the different event types in the system.

As said, there are several types of different events and if you look at the XML strings we quickly realize that

none of them are similar. This means we need individual handling for each event type. Fortunately, not all

event types are handled by my application; in fact I only make use of the events with the ID’s 1, 2, 3, 5, 9

and 11.

4.7 CreatePatientEvent

We’ve just seen how we get all the information about a patient from the above function. When we’ve

performed an action on a patient, we store the action as a new Patient Event. We simply call this function

38

and give a PtntEventRec as parameter to create a new event in the database. The method returns the ID of

the newly created event.

39

Chapter 5

Implementation

This section describes some of the implementations in detail. Only the most important and difficult parts of

the code will be described. All the previously described Use Cases has been implemented.

5.1 Methods.cs

At this moment, this class only contains one method. However this method is used in both the ListView and

the PatientView. The method is called getNewestPatientEvent . It takes a list of patient events as

parameter, finds the newest event of that type and returns the value of the XML String as a string. On the

next page is a presentation of the entire method.

40

It is intended to call this method with only one type of event; events where evtpID equals 9 for example.

We iterate through all the events and compare the current event’s created time with the newest

registered. If the current event’s created time is newer that the previous one, then we read the XML from

that event, store it in a variable and set a new created time for the newest variable. A switch statement

makes sure we handle the XML according to the event type. It should be noticed we add root elements

when parsing the XML string. The reason for this is badly formed XML from the web services which doesn’t

have root elements by default. I won’t be able to read the XML properly if it doesn’t contain root elements,

therefore I add them myself when parsing.

Also notice the switch statement doesn’t contain all event types. The reason for this is, the rest of them

(Timelog, Examination and Specialists) must be handled in a special way and this method is not sufficient.

However switch statement can be expanded to take other event types in the future should these be added.

public string getNewestPatientEvent(PtntEventsRec PatientEvents) { string xml = String.Empty; DateTime newest = DateTime.Parse("01-01-1753 12:00:00"); XElement xe; if (PatientEvents.Len != 0) { foreach (PtntEventRec p in PatientEvents.PatientEvents) { if (p.CreatedDateTime > newest) { newest = p.CreatedDateTime; xe = XElement.Parse("<root>" + p.XMLstring + "</root>"); switch (p.evtpID) { case 1: xml = xe.Element("Diagnose").Value; break; case 2: xml = xe.Element("Plan").Value; break; case 9: xml = xe.Element("Stabilitet").Value; break; default: break; } } } } return xml; }

41

5.2 List View

In the code, the file corresponding to the List View is called Default.aspx. It has a code behind file with the

extension .cs and a style sheet called Default.css. The .aspx file and it’s code behind file will be explained in

detail below.

5.2.1 Default.aspx

This file is as simple as possible. It contains four different placeholders encased in their own div-class tag.

The code behind file will populate these placeholders with controls to make the final list view. The four

placeholders will store information about beds, patient names, a patients triage and their cpr-number.

The style sheet for this page will make sure the elements are placed and displayed properly. It contains a

relative values for the font size and aligns the elements by either float-left of float-right. This makes the

design very universal and it shows brilliantly on all screen sizes, and for the same reason only one style

sheet is needed.

42

5.2.2 Default.aspx.cs

This class contains only two methods, Page_Load and convertCPR. The Page_Load method is where all the

magic happens, meaning we extract all the information needed to populate the ListView. The extracted

information populates the placeholders through a series of foreach loops, and below is a summary of the

code doing just that. Some parts of the actual code have been replaced with green comments explaining

what the actual code does. This is done to save space, and the actual code isn't hard ot understand since

it's mostly assigning values to the different labels or checking values. To view the actual code, I refer to the

CD that came with this project.For help with the contents of the CD, I refer to Appendix E.

Before the first foreach loop above, three calls have been made to the web service. In these calls we return

all teams, beds and patients currently in the system. Since the ListView should group the beds into teams,

01 foreach (TeamRec team in teams.Teams) 02 { 03 foreach (SengRec bed in beds.Senge) 04 { 05 if (bed.teamID.Equals(team.ID)) 06 { 07 // Create label controls 08 09 // Set the bed number in the corresponding label 10 11 ph_beds.Controls.Add(label_bed); // Add the label to the placeholder 12 13 // Check if TeamName is empty. If not, insert extra line break 14 15 if (bed.ptntID == 0) // If current beds ptntID = 0, no patient is in bed 16 { 17 // Set line breaks (empty) for labels name, cpr and triage. 18 } 19 else 20 { 21 foreach (PatientRec patient in patients.Patienter) 22 { 23 if (patient.ID.Equals(bed.ptntID)) 24 { 25 // Set the name and cpr of the patient in the corresponding labels 26 27 switch 28 (m.getNewestPatientEvent(client.GetPatientEvents(...), out error))) 29 { 30 // Set value of the triage label 31 } 32 } 33 ph_names.Controls.Add(label_name); 34 ph_cpr.Controls.Add(label_cpr); 35 ph_triage.Controls.Add(label_triage); 36 } 37 } 38 } 39 } 40 }

43

the first foreach loop will iterate through the different teams. The next loop iterates through all the beds

and finds the beds with a team ID matching the current team we're iterating through (line 05). When a

matching bed has been found, we set the text property of the corresponding label control to the name of

the bed.

In line 13 we check if TeamName is empty. It’s a variable that hold the currents teams’ name if we need to

write it to the ListView, otherwise it’s empty. Next we check the patient ID of the current bed, if it’s 0 no

patient is currently in the bed and therefore the name, cpr and triage should be set to empty for this

particular bed. However if the patient ID is different from 0, we iterate through all the patients until we find

the matching patient. We extract that patients name, cpr and triage. The triage is found by calling the

method getNewestPatientEvent from the class Methods.cs which has been explained earlier.

5.3 Patient View

The creation of the Patient View consists of the code behind file Patient.aspx.cs and the Page Patient.aspx

as well as three style sheets.

5.3.1 Patient.aspx

To make a fluent design I’ve split the initial mock up of my design into five horizontal blocks spanning the

entire width of the browser. As we’ve previously discussed, the width of the screen doesn’t matter since

you can define the width of the element using percentage values. The height is another matter. Below is a

figure that illustrates how the blocks have been made.

Figure 11: The design split into blocks

44

By using these blocks, it’s easier to place and size the different elements as they can just be placed with the

relative terms float-left or right. The .aspx file thus contains a div element for each of these blocks. Within

these block tags are the actual controls, which again is placed inside their own div tags. Below is a code

example of how Block 2 is made.

It’s very straight forward coding, and if we compare this code example to block 2 in figure 11 above, it’s

easy to see where the Label- and Button controls are placed.

To make the Patient View apply to the different device groupings, we use three different style sheets to

change the sizes of the different blocks and controls. The correct style sheet for each device group is

chosen when the page loads. The java script below applies the style sheet by measuring the screen size of

the device loading the page.

The way I determine what style sheet should be loaded, might seem a little awkward and it is. When testing

if the correct style sheet was loaded I discovered some flaws in how the screen size is measured on some

devices. One some Android devices, namely the HTC Desire, the screen sizes measured were not similar

each time the page was loaded. I measured sizes between 389x800 to 1134x800 pixels. Through further

testing it seems like it measures the size of the browser window instead of the actual screen size, and thus

the measured size changes depending on whether the address bar is hidden or visible. On other Android

devices however, it measures the screen size correctly. This is a problem I really can’t do anything about,

but I’ve managed to code my way through it and that’s why the if state conditions in the script above might

look awkward.

The difference between the style sheets is the height of each block, font sizes and size of buttons and drop

down lists. In the reference design each block is 50 pixels high, which gives a combined height of 250 pixels.

All buttons and drop down list controls share the same height as a block, and furthermore the buttons have

a width of 50 pixels where the drop down lists width is flexible. The labels have a flexible width and a

relative font size.

<script type="text/javascript"> if (screen.height < 300 || screen.width < 300) { document.getElementById("style").href = "Patient_small.css"; } else if (screen.height == 600 && screen.width == 1024) { document.getElementById("style").href = "Patient_large.css"; } else { document.getElementById("style").href = "Patient.css"; } </script>

<div id="block_2"> <div id="diagnosis"><asp:Label id="lbl_diagnosis" runat="server"/></div> <div id="reception"><asp:Button id="btn_reception" runat="server"/></div> </div>

45

In the style sheet for the small screens, the height of each block is 35 pixels and all other controls are made

smaller as well. For large screens the size of each block is 85 pixels.

5.3.2 Patient.aspx.cs

This is the file that gets data from the web service, populates the Patient View and adds data to the

database. When the page loads, we use the before mentioned getNewestEvent method from Methods.cs

to populate the diagnosis-, treatment- and triage controls.

I will now explain how we set the state of the buttons reception, journal entry, patient review and ward

round. When the page loads, a method named createTimeLog is called with a list of patient events.

The fourth parameter, ”5”, is the type of event we want, in this case Tidslog (Timelog). The line above calls the createTimeLog method with all the patient events of type Timelog for the patient with the matching ID. The event types returned above also includes cancelled events. A cancelled event is an event that has been undone in the stationary version. The createTimeLog method creates a TimelogEvent List and a cancelEvent List. The CancelEvent ID's are matched with the ID's in the TimelogEvent List, and removed if they match. A TimelogEvent List is returned that only holds TimelogEvents that haven't been cancelled by the user. Finally this method calls the changeButtons method which will change the state of the buttons according to the event list we just created. Every time one of the buttons are clicked, the event fired will call the createTimelogEvent method which will create a patient event and thereafter call the createTimeLog method which will ultimately update the buttons. To build the buttons for the examinations and assigned specialists we use the method createEventList. The method takes a list of events as parameter as well as an integer telling what type of events the list consists of. We get the list of events from the method getNewestEvents which is almost similar to getNewestEvent from Methods.cs, except this method gets all the newest events of a particular ID. A list of newest events is returned and used in the createEventList method. On the next page is a code example of the entire class showing how the buttons are created and added to the corresponding placeholder.

createTimeLog( client.GetPatientEvents(userLogin.guid, -1, patient.ID, 5, earliestDate, out error));

46

In the Patient.aspx file we’ve created two placeholders to store the buttons for examinations and assigned specialists respectively. Depending on what type of event list, examinations or specialists, we want to build in our Patient View, that placeholder is cleared initially. The parameter eventType is used to determine just that in lines 05 - 08. With the correct placeholder cleared, we iterate through the list of events as the next step. In line 12 we check if the current event has the status “Afsluttet”, if so we shouldn’t create button since finished events shouldn’t be shown in the Patient View. However if the event does not equal “Afsluttet”, we create a new button and assign its text field to the name of the event. In line 18 a switch statement will style the button according to the status of the event. The buttons can be either red or green, and if it’s an examination it can also be blue. Lastly we add the newly created button to the corresponding placeholder. When a new specialist assignment or examination is picked from one of the drop down lists, the corresponding event will call the method createEvent. Just as the above explained method, this method needs a list of newest events as parameter along with the event type as integer. The method also needs the value of the selected item in the drop down list. The method will iterate through the list of newest events and find the event name that matches the value of the selected item. Once found, the status of that event will be checked and a variable will be set to hold the new status value. This is shown in the example on the next page.

01 private void createEventList(List<Event> newestEvents, int eventType) 02 { 03 if (newestEvents.Count > 0) 04 { 05 if (eventType.Equals(3)) 06 ph_specialists.Controls.Clear(); 07 else if (eventType.Equals(11)) 08 ph_examination.Controls.Clear(); 09 10 for (int i = 0; i < newestEvents.Count; i++) 11 { 12 if (!newestEvents[i].status.Equals("Afsluttet")) 13 { 14 // Create btn for placeholder 15 Button btn = new Button(); 16 btn.Text = newestEvents[i].name; 17 18 switch (newestEvents[i].status) 19 { 20 case "Bestilt": 21 btn.CssClass = "button_red"; 22 break; 23 // Set button styles for the rest of the possible status 24 } 25 26 if (eventType.Equals(3)) 27 ph_specialists.Controls.Add(btn); 28 else if (eventType.Equals(11)) 29 ph_examination.Controls.Add(btn); 30 } 31 } 32 } 33 }

47

The format of the XmlString variable depends on what event type we’re adding. We determine what format we should use and then add the new event status and selected item value accordingly. If it’s an examination event, we also add an enum value which indicates what examination we add. Lastly we create the event by calling the web service with the appropriate parameters as shown below.

The values of for ID and CreatedBy are set to 0 and “” accordingly, since these values are added automatically by the web service.

client.CreatePatientEvent(userLogin.guid, new PtntEventRec { ID = 0, ptntID = patient.ID, evtpID = eventType, XMLstring = XmlString, CreatedBy = "", CreatedDateTime = DateTime.Now, }, out error);

foreach (Event e in newestSpecialistEvents) { if (e.name.Equals(selectedItemValue)) { switch (e.status) { case "Bestilt": if (eventType.Equals(3)) // Specialist eventStatus = "Udført"; else if (eventType.Equals(11)) // Examination eventStatus = "Afhentet"; break; case "Afhentet": eventStatus = "Tilbage"; break; case "Tilbage": eventStatus = "Afsluttet"; break; case "Udført": eventStatus = "Afsluttet"; break; default: break; } } }

48

Chapter 6

Test

The test section will include testing the Use Cases, Compatibility and unintended use of the program.

6.1 Use Cases

In all the following tests, the results are compared to the information shown on the stationary version of

the Afdelings Tavle. The test device used is a HTC Desire smart phone running Android 2.2.

What’s tested here is exactly what is written in the Full Use Case Descriptions, and nothing more. That

means we only test if the system works when used as intended. We don’t test any error scenarios or what

will happen if a change is made in the stationary version while using the portable version. These situations

will be tested later on. Below is a figure that shows what Use Cases have been tested and if that test

passed. A fully detailed test description can be seen in Appendix C.

49

Test Passed

Selecting a Patient

Receive Patient

Journal Entry

Patient Review

Ward Round

Book Examination

Get Patient to- and from Examination

Assign Specialist

Specialist Examination

Triage

Figure 12: Use case’s test results

From the tests it can be concluded that it is possible to perform all the implemented Use Cases, but that

doesn’t mean the system is error proof. The program now works when used as intended, but for everyday

use we will have to test error cases as well.

50

6.2 Compatibility

The compatibility test will test the programs ability to adapt to multiple screen sizes and

browsers/platforms. I’ve performed the tests by running both the list view and the patient view on each

device in both landscape- and portrait mode. Some of the devices cannot show both landscape- and

portrait mode, but it will be shown in the test if they cannot. The interaction has also been tested, but

that’s not the important part of this test, so the results from that will not be documented. Below is a table

that shows the test devices used and the results. Note that I’ve only tested the compatibility on the devices

I’ve had access to, and no emulators has been used during these tests.

Device Screen size Landscape Portrait

iPad 1024 x 768

Galaxy Tab 1024 x 600

Archos 9 1024 x 600 N/A

iPhone 4 960 x 640

HTC Desire 800 x 480

iPhone 3GS 480 x 320

HTC Tattoo 320 x 240

Figure 13: Compatibility test results

From this test it can be concluded that the application applies to these devices flawlessly. Especially when

taking into account the wide range of different types of devices this application was tested on, it should be

considered even more successful. We’ve tested on tablets, smart phones and the handheld PC from Archos.

And in all cases the tests were successful. On the following page, figure 14a shows a photo taken of the list

view running on the Galaxy Tab and figure 14b shows the same patient view on the Galaxy Tab and HTC

Desire smart phone.

51

Figure 14a: Shows the List View on the Galaxy Tab.

Figure 14b: Shows the same Patient View on both the Galaxy Tab and the HTC Desire phone.

52

6.3 Functionality

In this part we test the behavior of the mobile version compared to that of the stationary version. We’ve

already established that the program works just like the stationary version when it’s used as intended, so

now we test unusual use of the program. With unusual use I mean, what actions can or cannot be

performed if you don’t follow the chronological flow of the program, if you undo an action in the stationary

version and such. I’ve written in detail what I’ll test, how the stationary version behaves and how the

mobile version behaves compared to the stationary. Ideally there shouldn’t be any differences at all. The

most interesting tests performed can be viewed below, and the rest can be seen in Appendix D.

Test #1 Can you perform any actions before the patient has been received? (the reception button is white)

Expected behavior Journal entry, Patient Review and ward round and changing triage can all be performed. Ordering examinations or specialists cannot.

Actual behavior Examinations and specialists still cannot be assigned and Journal entry, Patient Review and Ward Rounds cannot be performed either. That’s a difference compared to the Expected Behavior.

Test #2 Can you deviate from the chronological flow of a patient’s hospitalization? (Can you perform an action with the buttons journal entry, patient review or ward round before the previous button is green)

Expected behavior Actions on the Journal entry-, Patient Review- and Ward Round buttons can all be performed before the previous button in the chronological flow is green.

Actual behavior None of the above actions can be performed in the current version. If you press a white button before the previous button is green, the system will act like you pressed the non green button once, record that event and change the buttons accordingly.

From these two tests above, we can conclude that the program doesn’t behave as it should. I turns out that

there’s a lot of different rules applying to the original Afdelings Tavle that I was unaware about. It’s a big-

and complicated application and since I’ve only been working with it a few weeks before I started coding, I

haven’t wrapped my mind around all the special rules and details. Because these special rules are missing,

misleading information might occur on the mobile application. This is a huge problem and should be a first

priority to change when doing future work.

From test #3 and #4, it can be concluded that changes made in the stationary application will show up on

the mobile version, and vice versa. This means the applications are connected as intended and test #5

concludes that the program makes changes depending on what action reaches the database the latest, if

changes are made at the same time.

Test #6 states that if all specialists- and examinations are ordered at once, it will clump up the screen and

force some elements out of place. This is a very extreme and unusual scenario however, and even in the

original version, this isn’t handled. Therefore I don’t make any extra changes to start handling this unlikely

event, but you might consider it in the future.

53

Chapter 7

Future Work

There's a lot of future work to be done with this application if it needs to be ready to the end user. First of

all, we've already discussed that the behavior of the application is slightly different to the original one. This

should be changed as soon as possible.

To avoid concurrency issues with the original application there should be a check every time we want to

create an event. This check should ensure that a new change hasn't occurred since the last time we

extracted information, and then afterwards we can apply our change. This would somehow help on the

problem above where we have some issues with different behaviors.

When examinations are ordered or specialists assigned, buttons will appears with a certain color to indicate

the state of that examination or specialist’s treatment. These buttons are not interactive at this moment,

and you have to use the drop down list to change the state of the buttons. It would be a lot easier and

more intuitive if you could just press the buttons to change their state.

Currently there's only a "refresh" button in the Patient View to refresh the page and get the newest

available information. The Afdelings Tavle checks for changes in the database every 10 seconds. A similar

feature should be considered for the mobile version. I steered away from this initially since I was unsure

how fast the page loads on a mobile device, so having automatic updates regularly could potentially

damage the user’s opinion of the application. Therefore the refresh button turned our as the chosen way to

get the newest possible data at this moment.

54

Currently there's no Login system, and I've previously explained why in the Risk Analysis on page 25 -26.

This is definitely an implementation that's needed before the application hits the end user.

More functionality can always be added, but getting the above mentioned implementations and

corrections done first will have higher value than adding new functionality. New functionality also depends

on what the customer wants it to do, and too much functionality could make the application confusing.

One more thing to add is an error page to display a friendly error when one occurs. A friendly and

informative error page that explains to the user why an error occurred increases the users experience a lot

more than the standard .aspx error page which doesn’t make sense unless you made the application.

55

Chapter 8

Perspectivation

In this section I will talk about what impact this application could have on the staff’s daily routine. Some of

the things it would change have already been said by the nurse I interviewed. These changes include saving

phone calls or long walks to and from the stationary Afdelings Tavle which ultimately makes it a time saver.

For instance, a doctor won’t have to walk to the stationary version to find out where his patient is staying

and what his diagnosis is. With the mobile version he can check this information at his office or at the

patient. Also, once he’s done visiting the patient, he won’t have to walk to the stationary version once

again to type that he has visited the patient. This can also be done using the mobile version, and if one

doctor saves 5 minutes each time he visits a patient this way, he saves 30 minutes in total if he visits 6

patients a day. The amount of time saved is enough to visit one more patient each day pr doctor, and since

there’s always more than one doctor at work an anytime and patients are under constant monitoring,

these 30 minutes in time one doctor saves for visiting 6 patients, might mean 5 hours of work has been

saved if 10 doctors are at work visiting 6 patients each. Basically a doctor is capable of visiting more

patients each day and thus the hospital could potentially get rid of one doctor to save money. The

calculations above are just an estimate.

The drawback of this system however, could be the face-to-face contact between doctors and nurses might

fade a little. But since doctors still have to fill out the patients physical journal when he has visited a

patient, he will still stay in some kind of contact with the nurses.

56

Implementing this system at a hospital will require implementing new security measures as well. The

program is now available to anyone who knows the URL, and we already discussed how important a login

system will be. But a login system is not secure enough since one could argue that the staff shouldn’t be

able to log in and retrieve information about patients when they are at home. If you restrict the use of the

application in such way, that it is only possible to access the website if your device is logged onto the

hospitals WiFi network, it would make the patients data more secure.

To mention the future of this application, I think its true potential lies in connecting the different

departments of the hospital into this one application. You would be able to view all tests performed on the

patient, whether it be x-rays or a scan it doesn’t matter. A full detailed description of the patients visit to

different departments should be visible, and in the far future, I think this whole system could potentially

eliminate the need for physical patient journals. By law handwritten journals must be constructed and

updated for every single patient, but since everything else is being digitalized nowadays, why not get rid of

the old system?

Everything written in a physical journal is already available in the stationary version of the Afdelings Tavle,

so the technology is in place. To begin with, a printable version of the Afdelings Tavle could be made. When

printed, it should be identical to the physical journal. Digitalized journals will also make it easier to find one

particular journal through intelligent search algorithms, and every detail about a patient is already logged in

the database so you have full history logs of every patients visit to the hospital. This helps save the amount

of space needed to store physical journals as well as lower the cost of archiving maintenance. All journals

would be safely placed on servers doing daily backups.

57

Chapter 9

Conclusion

The implementation of the Use Cases went relatively smoothly. I spend a good amount of time trying to

understand the data I received from the web services, and how the whole database part of the system

worked. The stationary version is programmed in Delphi, so some of the data we receive from the web

services are optimized for that language. This naturally meant I had to make some workarounds to make

the data fit my application. In the end it wasn’t a problem working with the web services, and progress

were made more rapidly.

I’ve implemented all the Use Cases I had planned, but the behavior is somewhat different to that of the

stationary version. I’ve already explained why in the Test chapter. To get the behavior to be similar to the

one in the stationary version, it would mean a re-write of some of the code. By the time I found the

behavior to be wrong, I was already in the later stages of the project and since the error would be too time

consuming to correct, I decided to leave it as it is. It has a very big priority for when doing further work on

the application however, and not realizing this issue earlier has been the worst part of the project. This

mistake however, taught me that knowing the problem domain is very important to get all the little details

in place.

I spent a good amount of time fiddling around with HTML and style sheets in order to get a fluent design

that would look similar on all devices. But in the end I think this is the part of the project that has been

most successful of all. I’m very pleased with how the final design applies to all devices, smart phones,

handheld PC’s, iPad and APad. What more do you want?

58

I’m also quite happy that the application is very future proof. The fluent design should apply to all new

devices in the near future as it is, but should you want to change the design, or make the design apply to

other devices, you just add a new style sheet or change the existing ones. Also, new features are very easy

to add and you can basically add all you want as long as you think about how to integrate it in the current

layout of the application.

The fact that the application looks a lot like the stationary version is accomplished as well. This can always

be slightly changed to use images as buttons the same way the stationary version does it. But generally the

staff should recognize the mobile version as an application they are familiar with. This is especially

important for the doctors since they only see and use the application a few times a day.

The application loads itself in about 1.5 seconds on the mobile network (3G), and on wireless network it’s

about 1 second. I think this is acceptable and I don’t think the performance can be noticeably improved by

changing the code. For the HTML part, I’m not using any images or any other data heavy objects, so the

speed comes down to how quickly you get data to and from the web services, and how often. I’m already

calling the web services only when necessary, and update only a single control when it needs to be

updated. I see this as the ideal solution, and hence I don’t see how the page load performance can be

noticeably improved at the moment.

Overall I was supposed to prove the concept that one application could be written that would fit all devices

and screens. Taking away the behavioral flaw of the mobile- contra the stationary version and only thinking

about the cross platform part, I think I achieved just that. I think the chosen application model, where we

get data through web services and then write an adaptable web site, suits the purpose perfectly. The

concept is clearly proved, and when HTML 5 becomes more common in browsers, the concept could be

further improved.

59

Litterature

1. StatCounter global: Graphs showing Browser- and OS usage for mobile devices, used October 2010.

http://gs.statcounter.com

2. Searching for info about the different operating systems, used August 2010.

http://en.wikipedia.org

3. Consumer satisfaction, used August 2010.

http://www.changewaveresearch.com/articles/2010/05/smart_phones_20100525.html

4. Finding out what iOS is, used August 2010.

http://developer.apple.com/iphone/index.action

5. Finding out what android- and android NDK is, used August 2010.

http://developer.android.com/guide/basics/what-is-android.html

http://developer.android.com/sdk/ndk/index.html#overview

6. How does MonoTouch work, used August 2010.

http://monotouch.net/

7. What PyObjC is, used August 2010.

http://pyobjc.sourceforge.net/

8. What is Windows Mobile, used August 2010.

http://msdn.microsoft.com/en-us/library/ff402531%28v=VS.92%29.aspx

9. ComScore: Android grows US smartphone market share as all others decline, used September

2010.

http://www.engadget.com/2010/07/09/comscore-android-grows-us-smartphone-market-share-as-all-others

NPD: Android is now top-selling OS in American smartphones, used August 2010.

http://www.engadget.com/2010/08/04/npd-android-is-now-top-selling-os-in-american-smartphones

10. Changing Style Sheets dynamically, used September 2010.

http://www.velocityreviews.com/forums/t163074-how-to-change-stylesheet-using-javascript.html

11. A developer’s-eye view of smart phone platforms , used August 2010.

http://www.infoworld.com/d/developer-world/developers-eye-view-smartphone-platforms-565?page=0,0

12. Effective design for Multiple Screen Sizes, used September 2010.

http://mobiforge.com/designing/story/effective-design-multiple-screen-sizes

13. Book: O’Reily - Programming ASP.NET 3.5, Jesse Liberty, Dan Maharry and Dan Hurwitz. Chapters

around Basic Controls and More Controls have been viewed a lot.

60

Appendix A

Market Analysis

I’ve done most of my research around smartphones, since they’re the devices I know the least about and

they have big differences between them. Also since the handheld PC acts like a regular computer, we can

get it to run almost any kind of program fairly easy. One of the first things I did was to try and get some

kind of overview over the various types of operating systems, and what kind of phones that is currently on

the market. I looked at some graphs to get my first impression of the market share of the different

operating systems. The graphs3 I looked at can be seen bellow.

3 The graphs are from StatCounter. They collect data through a net of more than 3 million websites all over the world.

61

The image above shows the Top 8 Mobile Operating Systems in North America.

The image above shows the Top 8 Mobile Operating Systems in Europe.

62

I’ve chosen the stats from Europe and North America since they give the best picture of the smart phone

market right now; simply because they’re the two continents in the world with the largest consumer

market. You have to keep in mind however; it isn’t only stats from smart phones on these graphs. It’s data

from regular mobile phones and even the PSP (PlayStation Portable) as well. It is based on what mobile

operating system a website request comes from, but naturally the most requests comes from smart phones

so the graphs are usable despite the regular mobile phones showing as well. Also keep in mind; this isn’t

the actual market share.

Not surprisingly, we can see the iPhone is topping the market at this exact moment in both North America

and Europe with 36.89% and 43.97% respectively. In North America it’s worth mentioning that iPhone is

losing some ground each month while BlackBerry/RIM and Android are gaining. In Europe we see Symbian

have a fairly large portion of the market, but it’s declining at a steady rate each month. One thing to note

about the Symbian operating system is, that it’s a very wide spread OS, meaning it exists on a huge amount

of different phones. A reason for the decline in website requests from a Symbian based phone is probably

the fact that a lot of the phones are of the older generation before smart phones were introduced. A lot of

the Symbian phones out there do not have the same internet capabilities as a smart phone; they’re slow

and have a bad presentation of websites due to the small screens. With a smart phone you tend to use the

internet a lot more than you would on your old standard mobile phone, and since more and more people

are getting a smart phone nowadays; the Symbian graph is declining because there’s more and more

requests coming from competing smart phones.

When looking at these graphs, you might notice the absence of the windows operating system. Windows

might be the one showing as “Unknown”, but I’m not even sure myself. For this reason, and the reason that

the graphs aren’t giving a clear enough view of the current market share I tried to dig deeper.

Shows the top 5 Smartphone platforms of Q2 in the US.

63

This chart4 shows Android was the only platform with a growth in amount of subscribers during the second

quarter in the US. All the other big competitors declined in the same period. This chart is backed by an

article on http://www.engadged.com stating:

“NPD's number crunchers have just announced their findings for Q2 2010, concluding that 33 percent of

phones sold during the period had Android on board. This marks the first time in eons (Q4 2007, to be more

precise) that RIM has not held the crown of most purchased smartphone OS on US soil, with its BlackBerrys

accounting for 28% of the market and Apple's iPhone occupying third spot with 22%.”

We can also see Microsoft showing on this chart with a 13.2% of the market, but they will most likely be

overtaken by the advancing Android system in the future. The conclusion can only be what it already has

been for many months now, Android is proving to be a force to reckon with and its competitors should be

worried.

Platforms

Having a good feeling of how the market is now and what the future might bring, it’s time to dig into the

different kinds of operating systems to see what properties they contain and if there’s any kind of similarity

between them. To make it easier for everyone, I’ve been concentrating my study around six of the largest

platforms: iPhone, Android, Windows Mobile, Symbian, RIM, and Palm webOS.

iPhone

The native language for iPhone is Objective-C, which is an object oriented version of the C programming

language. It is Apples own language, and in order to obtain the documentation and development tools you

have to purchase a developer license from Apple. However, once this is acquired, and you have accepted a

rather strict policy from Apple, you get access to very good documentation and plenty of examples. The

development tools include Xcode, Interface Builder and a simulator amongst others. The Interface Builder

is for making the layout of your application, and you do so by drag’n dropping elements onto the screen of

the simulator. The main tool is Xcode wherein you write the application itself. All the way from Xcode to

the final product you get the feeling that everything is very well connected between the different

development tools, and that Apple has tried to make it very stylish and elegant.

Despite the good documentation and loads of examples, Objective-C can still be a very hard language to

learn and it has a very steep learning curve. There’s no garbage collection, so allocation- and freeing

memory is the programmer’s job. The syntax used in Objective-C can also be a hurdle since it’s generally

very different compared to other languages. Especially if you’re from a Java world, it can be very hard to

adapt to Objective-C.

The iPhone uses a mobile version of the Safari browser, and they currently do not support flash. The reason

behind this is that the iPhone developers Terms of Service agreement prohibits it by saying:

4 http://www.engadget.com/2010/07/09/comscore-android-grows-us-smartphone-market-share-as-all-others/

64

“An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built in interpreter(s).” 5 Many iPhone customers have complained about the lack of flash support, but Apple defends themselves by

saying they won’t support an old technology and claims it runs slowly and will make for a bad user

experience. However you can get flash to work in the Safari browser if you jailbreak your iPhone and install

a plug-in. I doubt that I will need to do this, as I’m not planning on using flash for this kind of application.

Despite not supporting flash, the Safari browser still supports the standard HTML, CSS and Java Scripts.

Android

Native development for the Android platform is done in the more familiar Java language. Like with iPhone,

development for Android is very well documented with plenty of startup guides, tutorials and examples.

The tools needed to start Android development are freely available on the Android website. Android has

some special plug-ins designed for the Eclipse editor which makes it possible to write your code like you

normally would, and with a single button click it will run your Android application on a simulator. The

interface is built with xml code, and there’s no built in drag’n drop tools made available in the Android SDK,

so you’re stuck with a lot of copy-paste operations when designing your interface since xml coding is very

trivial. There is a drag’n drop tool available on the internet6 where you drag ‘n drop the elements directly in

the browser itself, and afterwards it will generate the xml code for you. This sounds good, but it actually

doesn’t work as intended. The generated code doesn’t exactly match the layout you’ve created, so you

have to manually change values in the generated code to make it right. From my experience you’re actually

better of just doing it the hard way from the beginning.

The Android browser is based on the very popular webKit framework. It supports HTML, CSS, Java Scripts

and Flash.

It’s worth mentioning that Android is an open source community, hence why the tools are available for

free, and you don’t have to go through agreements or fill in your credentials to start developing as you

would with iPhone. The open source community is, from my experience, more polite, helpful and friendly

than other more closed communities. It’s very easy to find help if you’ve run into a problem, and people

are generally more open minded. Since it’s an open source community, most applications are free via the

Android Market. It’s up to the developer himself to determine if he wants a fee, and how big a fee, when

people download his program. Most programs are free though, or you can download a light version on the

program for free while the full/pro version will cost you money.

Windows Mobile

Programming for this platform is done in C# or Visual Basic. You develop your applications in Visual Studio

and simulators are available for the different devices that are shipped with Windows Mobile as operating

system. Naturally Windows Mobile works well with Microsoft SQL servers and sites running ASP.NET. When

5 clause 3.3.2 of the iPhone SDK agreement

6 http://www.droiddraw.org

65

the new Windows Mobile 7 smart phone hits the market, you’ll be able to make applications directly in

Microsoft’s Expression Blend and Silverlight applications will be supported aswell.

Windows Mobile runs a mobile version of Internet Explorer, which means it supports basic HTML, Scripts,

Flash and Silverlight.

Before Windows Mobile, Microsoft called their platform Pocket PC’s, which were very business oriented

devices. Lately they’ve tried to get back into the market by making more general purpose phones and they

renamed their platform to Windows Mobile. The difference between the mobile platform and a desktop

application is starting to grow, and the new Windows phones are very appealing to fans of the .Net

environment.

Symbian

While there’s an ongoing hype around iPhone and Android smart phones, Nokia’s Symbian platform

continues to sell cheap low-end mobile phones that are still appealing to some people. They might not have

a large screen, or a very well functioning browser, GPS, or other tools but they run Java ME applications at a

much lower cost for the customer. Besides these old fashioned phones, Nokia have begun making smart

phones like the N97 which does support touch screen, GPS, Bluetooth and much more just like the iPhone

for example.

General development for Symbian is tricky because of the many different devices that range from black and

white screen phones with large fonts to smart phones with large touch screens. Fortunately, I’m only

focusing on smart phones, so a large portion of the Symbian phones can be discarded in my case.

Developing for the Symbian platform can be done in C, standard C++ or Symbian C++. The choice of editor is

can range from Visual Studio, Eclipse, Carbide or even by using command line with GCC (GNU Compiler

Collection). Despite the above choices, you can Python and Perl is also supported.

Just like Android, the browser used for this platform is based on webKit and supports HTML, CSS, Scripting

and Flash.

RIM/BlackBerry

BlackBerry targets the business man and enterprise developers. You can quickly create applications for

BlackBerry phones using BlackBerry’s MDS Studio. The tool allows you to drag and drop components onto a

page that will be turned into your simulator. The tool connects all components and you don’t have to write

any code in this step. Java is the chosen language for the RIM operating system, unless you make your

application with BlackBerry Web Development I which case you’d be coding HTML and scripting.

BlackBerry’s browser supports HTML, CSS, scripting and Flash. Other browsers can be downloaded as well if

you aren’t satisfied with the stock browser.

Palm webOS

Is a fairly new operating system that takes an interesting approach to the smart phone market. It runs on a

linux kernel, the user interface is designed to run on smart phones with touch screen. Applications for this

66

platform are written in HTML, Java Scripts, AJAX and some other common web technologies that are

handled by the webKit framework. It is also possible to write C and C++ applications. The use of web

technologies for writing applications was intended by Palm, since they wanted to spare developers to learn

a new programming language.

The browser used in webOS is also based on webKit and of course it supports HTML, CSS and scripts but

also flash.

67

Appendix B

Use Case Descriptions

Ward round

Actor Nurse

Precondition The patient is in his bed, and it’s time for the nurse to do her ward round. The nurse has made sure she’s at the right patient and has selected him from the list.

Post condition The button is updated with new initials.

1. The nurse clicks the appropriate button to indicate she’s visited the patient.

Side note: If it’s the first ward round, the button pressed is red. It will turn green when this ward round is

completed. The following ward rounds the button will remain green, but it can still be pressed and all new

ward round will be logged.

Journal entry

Actor Doctor

Precondition A red button indicates it’s time for a doctor to create the patients’ journal. The doctor has made sure he’s at the right patient at has selected him on the list.

Post condition The application shows who created the journal, and a new red button appears to indicate the patient is waiting to get a visit from a doctor.

1. The doctor clicks the red button when he has created the journal. The button turns green to indicate it has been created. The initials of the doctor who created the journal are shown as well.

68

Patient review

Actor Doctor

Precondition A red button indicates it’s time for a doctor to examine the patient. The doctor has made sure he’s at the right patient.

Post condition The application shows who has examined the patient by writing the initials on the button.

1. When the patient has been examined, the doctor clicks the appropriate red button. The button turn to green to indicate the examination is complete.

Assign specialist

Actor Doctor

Precondition The patient has been submitted into the system and has arrived at the hospital. He needs a specialist examination. We will assign the specialist “H1”.

Post condition A red button with the letters “H1” inside appears next to the drop down list.

1. The doctor clicks the appropriate drop down list to assign a specialist.

2. From the list that appears, the doctor selects “H1”.

Specialist examination

Actor Specialist

Precondition A doctor has assigned a specialist to examine a patient. A red button shows what type of specialist has been assigned; in this case it reads “H1”.

Post condition The button turns green to indicate the patient has been examined.

1. The specialist arrives and examines the patient. When he’s done, he selects “H1” from the drop

down list.

Side note: Multiple specialists can be assigned. If there is more than one, the buttons will appear next to

each other.

Selecting a patient

69

Actor Nurse (but can be anyone)

Precondition The nurse needs to do ward round on Bo Poulsen with the CPR-number 050787-3176.

Post condition The correct person is found and shown in the patient view. The nurse can now start her wards round.

1. The nurse finds the patients name in the list view.

2. She selects the patient by touching his name when she has checked the patients CPR-number is

similar to the one shown on the screen.

Triage

Actor Nurse (but can be anyone)

Precondition The patient has been submitted to the system with the triage set to “partly stable”. A nurse is performing her routine ward round.

Post condition The triage is changed and the change is visible on in the list view. The change to stable means the frequency of how often nurses need to visit the patient is decreased.

1. The nurse finds the patient’s condition has improved. She clicks the triage drop down list, and from

the menu that appears she changes his condition from “partly stable” to “stable”.

70

Appendix C

Test of Use Cases

Preliminary information

Bo Poulsen has been submitted into the system, but he hasn’t arrived yet. According to his private doctor

he has been given the diagnose “KOL i exac”. Furthermore Bo has been placed assigned to bed “01.1”,

special unit “B” and has been given the triage “delvis stabil”.

Test 1: Selecting a Patient

In this test we will simply select a patient from the list view, and check if it’s the correct patient that will be

shown accordingly. The patient has just arrived at the hospital.

1. The nurse finds the patients name in the list view.

2. She selects the patient by touching his name when she has checked the patients CPR-number is

similar to the one shown on the screen.

The selected person and all his information is shown in the patient view once he’s been selected.

Test 2: Receive Patient

In this test we will test if a patient can be received and the color of the button changes according to what

state the reception process is in.

5. The nurse guides the patient to his bed and clicks the white button once. The button now turns red

to indicate the patient is waiting to be visited.

6. From the original Afdelings Tavle, a nurse is assigned to visit this patient. The red button will now

have the assigned nurse’s initials next to it to indicate who should go and visit the patient.

71

7. The nurse clicks the red button to indicate she has visited the patient. The nurse’s initials still

appear on the button and the button turns green to indicate the visitation is finished.

As the last state of the reception process if finished, the Journal Entry button turns red to indicate a doctor

should take care of the next step.

Test 3: Journal Entry

A doctor has been selected to deal with creating the journal from the stationary Afdelings Tavle. His initials

will now appear on the red button.

1. The doctor clicks the red button when he has created the journal. The button turns green to

indicate it has been created. The initials of the doctor who created the journal are shown as well.

The patient review button turns red to indicate we are ready to perform the next step in the process.

Test 4: Patient Review

We test to see if the buttons change state according to how far in the process the patient is. A doctor has

been selected to handle the review from the stationary Afdelings Tavle.

1. When the patient has been examined, the doctor clicks the appropriate red button. The button

turns to green to indicate the examination is complete.

The patient has now had his first review, and he might only need one. But if he needs more, a ward round

can be performed many times. Initially the ward round button remains white since you’re not supposed to

do two patient reviews in one day. But the following day at 7 in the morning, the ward round button should

turn red.

Test 5: Ward Round

We wait until the following morning to see if the button turns from white to red.

1. The nurse clicks the appropriate button to indicate she’s visited the patient.

The nurses’ initials are shown on the button. If a new ward round is performed after this one, the nurse

who performed the latest ward round’s initials will be shown.

Test 6: Book Examination

In this test we will order an X-Ray examination for the patient.

1. The doctor clicks on the drop down list for booking examinations.

2. From the list that appears, the doctor selects the “Rtg” option.

72

A red button with the letters “Rtg” will appear next to the drop down list to indicate the examination has

been ordered, and the patient is now waiting to be picked up.

Test 7: Get Patient to- and from Examination

Here we test if the “Rtg” button will change in color according to how far in the examination process the

patient is.

4. The porter picks up the patient, and indicates this in the system by selecting “Rtg” from the

examination drop down list. The button will now turn blue to indicate the patient has been picked

up.

5. After the x-ray examination, the porter drives the patient back to his bed. He then selects “Rtg”

from the drop down list once more and the button turns green to indicate the patient is back from

the x-ray examination.

Multiple examinations can be ordered at once and if a completed examination, e.g. a green button, is

selected from the drop down list once more, it disappears.

Test 8: Assign Specialist

This part tests if we can assign the specialist “H1” to the patient.

1. The doctor clicks the appropriate drop down list to assign a specialist.

2. From the list that appears, the doctor selects “H1”.

A red button with the letter “H1” appears next to the drop down list. It indicates a specialist has been

assigned.

Test 9: Specialist Examination

We will check if the button changes color in order to show if the patient has been examined by a specialist

or not.

1. The specialist arrives and examines the patient. When he’s done, he selects “H1” from the drop

down list.

The button changes green and the “H1” letters are still visible. Again, multiple examinations can be ordered

at once and if you select “H1” from the drop down list again the button will go away.

73

Test 10: Triage

Here we will test if we can change a patients triage and if the change will be shown in the list view as well.

1. The nurse finds the patient’s condition has improved. She clicks the triage drop down list, and from

the menu that appears she changes his condition from “partly stable” to “stable”.

The change is made, and it’s shown in the list view as well.

74

Appendix D

Test of Functionality

Test #3 If an action is performed on the stationary version, will it show on the mobile

version?

Result It will show on the mobile version after you refresh the page.

Test #4 If an action is performed on the mobile version, will it show on the mobile stationary?

Result The action performed is registered as soon as the stationary version performs an update check.

Test #5 If we undo a patients Journal entry completely. And at the same time, we want to start the Patient Review from the mobile version. What happens?

Result Depending on what action is added to the database lastly, two things can happen. If the undo events are added before we press the patient review button, then the patient review will be performed and shown in both versions. However in the stationary version, the journal entry is still cancelled, while in the mobile version it is not. If the patient review action is in the database before the undo action, then the mobile version will show all buttons as green, meaning the undo event isn’t shown, but in the stationary version the journal entry button will be correctly displayed as red.

75

Test #6 What happens if we assign all possible specialists and examinations?

Result When all possible buttons are added onto the screen, it will take up all the space allocated within the block. This means the specialist buttons will force the examinations and ward round buttons to be shown below the specialist buttons as it’s illustrated on the figure below.

Shows Patient View when all specialists and examinations have been ordered

76

Appendix E

CD Contents and loading the application

The content of the cd includes the following:

- Complete source code; go to ~/Application/eTavle Mobile/eTavle Mobile.sln

The application was developed in Visual Studio 2010 using the .Net Framework 3.5, and I would

recommend opening the application in this version.

To view the actual running application, go to http://twerft.kedermig.dk