PROJECT PROPOSAL

FOR CONSIDERATION UNDER

BACHELOR OF COMPUTER SCIENCE

(BSc) PROGRAMME
PROJECT TITLE
CONTENT DELIVERY NETWORKS IN eHEALTH USING
MOBILE DEVICES

SUBMITTED BY
Mathews Chibuluma
(Name of Author)

Dr. Laban Mwansa

(Name of Primary Supervisor)

Dr. Charles Chengo, MB ChB

(Name of External Supervisor)

22nd November 2013

(Date of Submission)

This project is a partial fulfillment of the requirements for the award for BSc in Computer
Science.

Page |1
DECLARATION

I, Chibuluma Mathews, do hereby declare that this Project Report is original and has not being
published and/ or submitted for any other degree award to any other University before.

Signed……………….... Date……………………

MATHEWS CHIBULUMA

Page |2
APPROVAL
This project proposal has been submitted for examination with the approval of the following
supervisor.

Signed……………….... Date………………...
Dr. Laban Mwansa (PhD)
Centre for Information Communication Technology.

Page |3
Acknowledgments
I would like to acknowledge the contributions of several people to this research; without whose help it
would not have been possible for me to carry out this research. First and foremost I would like to thank
my heavenly father who has kept me in good health all through the course of this project and reminded
me of a principle of living a day at a time. I would also like to thank Dr Kunda Director at the Center for
Information Communication Technology at Mulungushi University for his leadership he continues to
render to the center, Mr Aaron Zimba for his passionate input as I would ask him anything regarding the
project at any time. I would also like to thank Mr Siyinda Muanei, Mr Mwenge Mulenga, Mr Simfukwe
Macmillan and Mr Chembe Chris lecturers at Mulungushi University who without them I would not be
where I am today.

My supervisor Dr Laban Mwansa, what can I say, you have been the greatest influence in this research.
Thank you for your guidance, insight and for believing in me and my prayer is for this working
relationship to go on even after the completion of this project.

It was also a great honor to have had Dr. Charles Chengo of Lumwana Mines, with an immensely rich CV
as my external project supervisor and I thank him for his contributions especially on the literature review.

Lastly but not the least I would like to thank my beautiful mother Mrs. Diana Malambo for the financial
and spiritual support she continues to render, without her all this would not be possible.

Page |4
ACRONYMS

ICT Information Communication Technology

MDG Millennium development Goals

SQL Structured Query Language

WHO World Health Organization

NCD Non Communicable Diseases

CDN Content Delivery Networks

DOS Denial Of Service

P2P Peer to Peer

UN United Nations

MPLUS Mobile Plus

NHS National Health Service

NHLBI National Heart Lung Blood Institute
BMI Body Mass Index
PMBOK Project Management Body Of Knowledge

Page |5
FIGURES AND TABLES

Figure 1: Smartphone OS Market Share ..................................................................................................... 15

Figure 2: Android Architecture ................................................................................................................... 16
Figure 3: Android to Linux Version ........................................................................................................... 17
Figure 4: iOS Architecture .......................................................................................................................... 19
Figure 5: Windows Architecture ................................................................................................................. 22
Figure 6: Distributed eHealth using Server Oriented Architecture ............................................................. 24
Figure 7: Framework of Dr. SMARTPHONE S. ........................................................................................ 28
Figure 8: Algorithm and content structure. ................................................................................................. 29
Figure 9: KAU Mobile Architecture ........................................................................................................... 30
Figure 10: Respondent Breakdown ............................................................................................................. 35
Figure 11: Simplified DSDM lifecycle ....................................................................................................... 38
Figure 12: Work Breakdown Structure ....................................................................................................... 41
Figure 13: Gantt chart ................................................................................................................................. 42
Table 1: Complexity Factors ....................................................................................................................... 43
Table 2: Functional Point Estimations ........................................................................................................ 44

Page |6
Contents
DECLARATION .......................................................................................................................................... 2
APPROVAL ................................................................................................................................................. 3
Acknowledgments.......................................................................................................................................... 4
ACRONYMS ................................................................................................................................................ 5
FIGURES AND TABLES ............................................................................................................................ 6
Abstract ......................................................................................................................................................... 9
INTRODUCTION ...................................................................................................................................... 10
1.1 Background to the Study ................................................................................................................... 10
1.2 Problem Statement ............................................................................................................................ 11
1.3 Purpose of Research .......................................................................................................................... 11
1.4 Reasons to Justify Research Area ..................................................................................................... 11
1.5 Aim of the Project ............................................................................................................................. 12
1.6 Project Objectives ............................................................................................................................. 13
Conclusion .................................................................................................................................................. 14
CHAPTER 2 ............................................................................................................................................... 15
LITERATURE REVIEW ........................................................................................................................... 15
2.1 Introduction ....................................................................................................................................... 15
Figure 1: Smartphone OS Market Share ............................................................................................. 15
2.2 Android ............................................................................................................................................. 16
Figure 2: Android Architecture ........................................................................................................... 16
Figure 3: Android to Linux Version ................................................................................................... 17
2.3 IPhone OS ......................................................................................................................................... 19
Figure 4: iOS Architecture .................................................................................................................. 19
2.4 Windows OS ..................................................................................................................................... 22
Figure 5: Windows Architecture ......................................................................................................... 22
Systems using mobile devices in eHealth delivery ..................................................................................... 24
Distributed eHealth Using Server Oriented Architecture ....................................................................... 24
Figure 6: Distributed eHealth using Server Oriented Architecture ..................................................... 24
Samsung Medical Center (SMC) Dr SMART S ..................................................................................... 28
Figure 7: Framework of Dr. SMARTPHONE S. ................................................................................ 28

Page |7
 Figure 8: Algorithm and content structure. ......................................................................................... 29
KAU Mobile System................................................................................................................................. 30
Figure 9: KAU Mobile Architecture ................................................................................................... 30
Countries that have implemented eHealth in their service delivery ....................................................... 32
Challenges of implementing eHealth in Zambia ..................................................................................... 32
CHAPTER 3 .............................................................................................................................................. 34
RESEARCH METHODOLOGY ................................................................................................................ 34
3.1 Introduction ....................................................................................................................................... 34
Research Approach and Design .......................................................................................................... 34
Research Setting.................................................................................................................................. 34
The Study Population and Sample ...................................................................................................... 34
Data Collection Instrument ................................................................................................................. 34
Figure 10: Respondent Breakdown ..................................................................................................... 35
Figure 11: Simplified DSDM lifecycle ............................................................................................... 38
3.2 Risk and Quality Management .......................................................................................................... 40
3.3 Scheduling and Work Plan................................................................................................................ 41
Figure 12: Work Breakdown Structure ............................................................................................... 41
Figure 13: Gantt chart ......................................................................................................................... 42
3.4 Effort Costing.................................................................................................................................... 43
Table 1: Complexity Factors ............................................................................................................... 43
Table 2: Functional Point Estimations ................................................................................................ 44
References ................................................................................................................................................... 45

Page |8
Abstract

Background: New possibilities for eHealth have arisen by means of the latest advances in mobile
communications and technologies. With more than 1 billion smartphones and 100 million tablets around
the world, these devices can be a valuable tool in health care management. With the increase in maternal,
child, and non-communicable diseases every advances in providing quality health care is very important
and welcome.

Aim: To develop a mobile based application for the sole purpose of enhancing health delivery in Zambia.

Objectives: (1) To study existing mobile based systems and come up with one that is customized and
suitable for the Zambian setup. (2) To integrate other existing tools within the main app e.g. doctor app,
health calculators etc. (3) To implement content syndication with health information providers e.g. NHS,
NHLBI etc.

Methods: Two reviews were carried out the first review was on the three widely distributed mobile
platforms as given by IDC and mobile market Q3. The second review was on three existing systems that
are using mobile technology in their delivery.

Conclusion: The current approaches in health are not adequate to meet up with the challenges the country
is currently facing, every input from all sectors is of vital importance. With the growth the country is
currently experiencing in mobile penetration, eHealth is the only way forward in meeting up the MDG‟s.

Key words: eHealth; Smartphone; mHealth; current situation; information communication technology

Page |9
 CHAPTER 1

INTRODUCTION

This research proposal will look into Content Delivery Networks and how they can be applied in eHealth
using mobile devices i.e. smartphones, tablets etc. this introduction has been apportioned into various
parts as follows the first part is the background to the research, the second is the problem statement, the
third is the major purpose of the research, fourth is the justification lastly but not least is the aim and
objective of the proposed research.

1.1 Background to the Study

Dr Laban Mwansa (Mwansa, 2013) defines content delivery networks as,

A network of widely distributed servers spread across end-to-end that would be otherwise placed
in a centralized manner but have been put in this way as to increase network efficiency, increase
security, provide better service delivery, fast network access and download speeds and most
importantly fault-tolerance.
CDN make accessibility to websites and general data over the network faster in a sense that the
consumers can register with a CDN provider such as MaxCDN or Akamai for their website to be hosted
on CDN servers, whenever a client wants to access that particular site content is made available according
to the webserver that is nearer to them which is measured by hop counts of the fewest nodes between
them (client and server). CDN also provide a degree of protection from DOS attacks as there are a lot of
distributed servers which will service the client incase the one closer to them is affected. To enhance
security CDN also implement peer to peer (p2p) where nodes can take up any role of both client and
server to be able to share resources, this increases security in a sense that nodes not part of this peer group
can‟t be able to acquire the resources available. This is advantageous with this system being built in a
sense that patients will only be able to make the medical records available to only those authorized to.

Electronic Health or eHealth is defined as a healthcare practice that is supported by Information

communication technology or management of health records electronically. (Chang Liu et al, 2011) also
define eHealth as the software applications that provide tools, processes, and communications in order to
support electronic health care practice. It is a broad topic that encompasses other fields such as tele-
medicine which is the use of tele-communication and information technology in order to provide physical
and mental treatments usually done from a distance which also includes tele-monitoring of patients
where patient routine activities are monitored via satellite, eHealth also includes mhealth which is defined
by the Global Observatory for eHealth (GOe) of the World Health Organization (WHO) as medical and
public health practice supported by mobile devices, such as mobile phones, patient monitoring devices,
personal digital assistants (PDAs), and other wireless devices.

The rapid growth of mobile devices supporting CDN cannot be overlooked; according to the UN Tele-
communication Agency (ITU, 2013) more than 80% which is an equivalence of 5.7 billion people of the
world‟s population have a mobile device in their possession. Fortune magazine also reported that during
the final quarter of November 2010 smart-phones for the first time outsold Personal Computers (PC).

P a g e | 10
(Traxler, 2007) defines a mobile device as typically a pocket size or handheld computing communication
device having a display screen with touch input or keyboard. They are typically wireless enabled allowing
access to the internet and use Web applications to connect to more powerful computing capabilities.

Health is a fundamental good, both for individuals and the society as a whole. For individuals good health
leads to a better quality of life and education, which in turn enhances their chances of living productive
and more happier lives, healthy workers are less frequently absent from their respective workplaces and
this results in increased company revenue and overall increased GDP for a country. As a result of this
governments all over the world have taken a keen role in making sure that its citizenry is kept in good
health by making it a priority that they have access to affordable healthcare.

Zambia is characterized by a vast geographical extent, large populations and vast rural settlements. These
factors coupled with many other factors combined with shortages in healthcare practitioners render
eHealth an effective tool in providing for healthcare to a vast majority of people who do not have decent
access to health.

1.2 Problem Statement

Zambia compared to other developing nations has not taken advantage of this growth in mobile
technology so as to meet various challenges it is facing especially in health. As at present doctors can
reach patients via mobile using Facebook which is somehow cumbersome as most part of the population
has challenges in accessing the same. The country even after 47 years of independence cannot ascertain
accurate statistical data as pertains to health, e.g. how many people are on antiviral drugs, how many
people have access to information. Data gathering is done manually by having medical personnel‟s go
into compounds so as to gather information as pertains to health. This is a great challenge in a sense that
chances of error are quiet high and generation of reports takes time as all the collected data will have to be
put in one place before analysis is done.

1.3 Purpose of Research

The purpose of this research is to harness the power that mobile technology can bring with it when
applied to good use in various sectors of the country‟s economy particularly in health.

1.4 Reasons to Justify Research Area

Here are some of the reasons that make this research very relevant to Zambia‟s economical setup.
According to the world health organization 2001 report on health, low and middle income countries
spending on health accounts for only 11 percent of the overall world spending of which unfortunately
they are home to more than 90% world‟s diseases. The report further on goes to say that life expectancy in
these countries has drastically reduced to the age of 40 or less. A report conducted by the ministry of
health on child mortality rate conducted in 2004 suggested that infant and under-five mortality rates in
Zambia still remained high (95 and 168 per thousand live births). The report further on went on to say that

P a g e | 11
the current intervention on reducing these deaths was inadequate to achieve the impact on reducing child
mortality rate. It suggested that with improved interventions child health mortality rate would be reduced
by 99%. As at now the country only has about a 1,000 medical doctors to a population of about 13 million
people which puts the doctor to patient ratio at approximately 1 to 12000.

With these and many more challenges the country is facing in health, the ministry of health has launched
a National Health Research Center that welcomes from the public any research findings that would help
in reducing these problems. Hence the decision taken to embark on this project, to integrate various ICT
technologies into health so as to be able to stir the country towards meeting the MDG‟s on health. This
system is very essential and below I have outlined the reasons as to why if such kind of an application is
put to use the benefits it would bring with it would be immense:-

 It will reduce maternal, child mortality greatly as issues of communication would be a thing of
the past as a patient can communicate with their doctor at particularly any time as concerns to
their health.
 SMS based reminders will improve a patient‟s drug compliance by between 30% and 70%. This
is where the application according to the doctor‟s prescription on drug compliance will be able to
generate reminders to the patient on what times to take their medicines.
 Diagnostic procedures e.g. x-ray‟s, CT scanners, and ultra-sound taken locally with a camera can
be transferred electronically to specialists for further analysis and treatment using various
communication media Wi-Fi, GPRS etc.
 Doctor‟s using mobile technology will be able to double the number of patients their able to
attend to and this will save on costs as patients would limit frequent visits to the hospital.
 Remote diagnosis will reduce hospital costs, reduction in referrals by a 30% and an average of
25% will be able to receive diagnosis through tele-medicine.
 Such kind of a system will be able to boost the efficiency of national health data collection, it will
limit down on inaccuracy that is found manually by collecting of data and save on unnecessary
expenditure.

Looking at the response rate of the proposed system received when the author attended a
health research conference in Lusaka (See Methodology Section) to present a poster
presentation on the same, it was overwhelming hence the conviction that if this proposal
goes through this system will go a long way in reducing most of the challenges the
country is facing as regards to health care delivery.

1.5 Aim of the Project

 To develop a mobile based application for the sole purpose of enhancing health delivery in
Zambia.

 Able to integrate within the app various tools to aid patients in there day to day activities, tools
such as body mass Indicator, find doctor app, perinatory or pregnancy due calculator‟s tools etc.

P a g e | 12
1.6 Project Objectives

 Mplus will be designed to give an easier to use platform between a medical doctor and patient by
taking advantage of concepts abstraction where the user of the application will not be concerned
about the inner working of the application but will be able to do functionalities of updating to the
SQLite database how there feeling. The system will be able to do content syndicate with NHS
database to get latest feeds regards to health.
 Integrate Doctor Finders App‟s tools that integrate GPS into a mobile phone. The android
platform provides this using there Google maps where various locations are mapped out as co-
ordinates and can be traced via satellite.
 Create both client side and server side and use web services for data transfer communication for
the doctor to be able to read and write to the database server to get information about available
drugs and be able to make orders.

P a g e | 13
Conclusion
In this introduction the author has given a detailed background to the problems that have necessitated this
research proposal. Out rayed the various challenges the country is facing as regards to health i.e. a wide
gap of Doctor to Patient relationship, and few health centers available around the country, limited
expertise in health.

P a g e | 14
 CHAPTER 2

LITERATURE REVIEW
2.1 Introduction

This chapter will look at the four widely used mobile platforms as given by IDC and as shown in figure 1
below, the three existing systems implemented using mobile devices, review of the various languages
powering the mobile Operating Systems platforms and countries that have implemented eHealth in their
health service delivery.

Mobile penetration in Zambia has grown by 78% which represents a growth rate of 29.13% from 2000
(ZICTA, 2013). According to the same report they were only 49,957 mobile users in 2000 but as of
December 2012 the number grew to 10,542,676, the report further on goes to state that the number of
mobile internet users had grown to 2,196,117 as of December 2012. Therefore with this growth in the
usage of mobile technology, eHealth can capitalize and play a vital role in quality service delivery of
health.

Figure 1: Smartphone OS Market Share (Foresman, 2012)

Figure 1 shows Smartphone OS market share for 1st, 2nd, 3rd of 2011 and the first quarter of the year
2012. As can be noticed from the diagram Android has been gaining grounds from between 20% and 40%
in the 1st quarter of 2011 to 60% in the first quarter of 2012. This is seconded by iOS which has grown
from 20% in the first quarter of 2011 to 30% in the first quarter of 2012. Thirdly is Blackberry though
declining from 10% in the first quarter of 2011 to less than 10% in 2012 but still being widely used.

P a g e | 15
Lastly but not the least is Windows Mobile which has steadily being increasing popularity. Symbian will
not be reviewed due to the fact Microsoft are the new proprietary owners of Symbian (Woodil, 2013).
These statistics as given by IDC prompted the author in reviewing these platforms as a tool for eHealth
implementation.

2.2 Android

Android is an open source platform developed by Google meaning Google first builds the code internally
and then releases the code under the apache license. It is the most popular mobile platform used by
developers, and according to the (developer survey of, 2013) 71% of developers used android to do their
application development. (Fingas, 2013) It also has the largest mobile market share which is currently
now standing at 81.3%. (Zhang, 2011) It is based on the Linux 2.6 operating system which is a stable
Linux distro. Android uses java and xml for its application development this mainly due to the fact that
java is widely known by programmers hence increasing its application base (reference). Figure 1 below
shows the android architecture.

Figure 2: Android Architecture (Android App development for beginners, 2011)

P a g e | 16
As can be seen from figure 1 above, the architecture consists of five layers of abstraction, Application,
Application Framework, Libraries, Runtime and the Linux kernel layers. This section will critically
analyze these layers.

Linux Kernel

It is the basic underlining layer of the Android architecture which interacts with the hardware. It is built
on top of the Linux 2.6 version which is a stable Linux distribution as earlier alluded to. (Edureka, 2013)
the kernel never really interacts with the users and developers, but is at the heart of the whole system. The
resource further on to give the importance the kernel provides to the Android system:-

 Hardware Abstraction: - where an application developer or user needs not to know the hardware
implementation to be able to deploy their apps.
 Memory Management Programs: - every app runs in its own memory space this enhances the
security aspect of the device as malicious code in app cannot interfere with other legitimate apps.
 Security Settings
 Power Management Software
 Support for Shared Libraries
 Network Stack

The table below shows various Android Operating systems versions and the corresponding Linux version
they run on:-

Figure 3: Android to Linux Version (Edureka, 2013)

Libraries

The libraries in this layer are either written in C or C++. It contains libraries like SQLite which is the
database engine used in android for data storage. It also contains OpenGL which is used for 2D or 3D
graphics rendering on the screen. It has also WebKit which is the browser engine that displays html
content on the device. The layer also has the media framework that houses different types of codecs so
that the device can be able to play different types of media formats. The surface manager is used for
display management; it is also responsible for drawing different surfaces on the screen.

P a g e | 17
Runtime

The android runtime was developed for the sole purpose of making android meet the needs of running in
an embedded environment, where you have limited battery, limited memory and limited CPU. There two
main components in this layer Dalvik Virtual Machine and Core Libraries. (Edureka, 2013) defines the
Dalvik Virtual Machine as software that is able to run Android apps.

The DVM runs .dex files which are combination of .class and .jar that are generated at built time, these
files run efficiently on small processors and they also use memory efficiently. (Edureka, 2013) The virtual
machine allows multiple instances of itself to be created simultaneously which provides for security,
memory management, threading and support.

The Core Libraries are written in java, they provide for functionality of the java core language as well as
functionality and support for the android specific libraries.

Application Framework

This is the tool kit or platform where all the android applications run. All android applications use the
same framework and API‟s. (Edureka, 2013) gives various functionalities found within this layer as listed
below:-

 Activity Manager: - Manages the activity life cycle of applications. Content Providers: Manage
the data sharing between applications.
 Telephony Manager: - Manages all voice calls. We use telephony manager if we want to access
voice calls in our application.
 Location Manager: - Location management, using GPS or cell tower
 Resource Manager: - Manage the various types of resources we use in our Application

a. Applications

The top most layer where all the pre-installed and our own user developed apps exist. Examples of pre-
installed apps are:-

1. SMS client app

2. Dialer
3. Web browser
4. Contact manager

P a g e | 18
2.3 IPhone OS

IPhone OS is the mobile OS developed and distributed by Apple Inc.(Eurocast, 2011) it is based on the
same technologies based on Mac OS X, which are Mach kernel and BSD interfaces, thus making it a Unix
based system. The apps on iOS unlike Android are built using Objective C which is a superset of the C
language based on SmallTalk that supports Object orientation. . (Fingas, 2013) Its current mobile market
share stands at 13% as of November 2013. It has four layers of abstraction these are Core OS layer, Core
Services layer, Media layer and Cocoa Touch layer. Figure 3 below shows the iOS archictecture:-

Figure 4: iOS Architecture (The iPhone OS Architecture, 2011)

Cocoa Touch

Cocoa Touch layer provides an abstraction of the iOS. (The iPhone OS Architecture, 2011) the Cocoa
Touch layer sits at the top of the iPhone OS stack and contains the frameworks that are most commonly
used by iPhone application developers. Cocoa Touch is primarily written in Objective-C, is based on the
standard Mac OS X Cocoa API and has been extended and modified to meet the needs of the iPhone. The
Cocoa Touch layer provides the following frameworks for iPhone app development:-

 User interface creation and management (text fields, buttons, labels, colors, fonts etc)
 Application lifecycle management
 Application event handling (e.g. touch screen user interaction)
 Cut, copy, and paste functionality
 Web and text content presentation and management
 Data handling
 Inter-application integration
 Push notification in conjunction with Push Notification Service
 Accessibility
 Accelerometer, battery, proximity sensor, camera and photo library interaction.

P a g e | 19
Media Services

(The iPhone OS Architecture, 2011) The role of the Media layer is to provide the iPhone OS with audio,
video, animation and graphics capabilities. As with the other layers comprising the iPhone OS stack, the
Media layer comprises a number of frameworks that can be utilized when developing iPhone apps. Below
is an outline of some of the frameworks found in this layer:-

Core Graphics Framework

(The iPhone OS Architecture, 2011) the iPhone Core Graphics Framework (otherwise known as the
Quartz 2D API) provides a lightweight two dimensional rendering engine. Features of this framework
include PDF document creation and presentation, vector based drawing, transparent layers, path based
drawing, anti-aliased rendering, color manipulation and management, image rendering and gradients.

OpenGL ES framework

OpenGL is the industrial standard for 2D and 3D graphics rendering. (Khronos, 2013) defines OpenGL
ES as a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems -
including consoles, phones, appliances and vehicles. It consists of well-defined subsets of desktop
OpenGL, creating a flexible and powerful low-level interface between software and graphics acceleration.

Media Player framework

The iPhone OS Media Player framework is able to play video in .mov, .mp4, .m4v, and .3gp formats at a
variety of compression standards, resolutions and frame rates.(iOS developer, 2013) the Media layer
contains the graphics, audio, and video technologies used to implement multimedia experiences in apps.

Core Services

This layer is made up of fundamental system services that are used by every application that is running on
the iOS device. The following sections below describe the frameworks of the Core Services layer and the
services they offer:-

Accounts Framework

(IOS developer, 2013) the Accounts framework provides a single sign-on model for certain user accounts.
Single sign-on improves the user experience by eliminating the need to prompt the user separately for
multiple accounts. It also simplifies the development model for you by managing the account
authorization process for an app on the device.

Address Book Framework

(IOS developer, 2013) the Address Book framework provides programmatic access to a user‟s contacts
database. If your app uses contact information, you can use this framework to access and modify that
information. For example, a chat program might use this framework to retrieve the list of possible
contacts with which to initiate a chat session and display those contacts in a custom view.

P a g e | 20
Core OS

It is considered the deepest layer of the iOS architecture. (IOS developer, 2013) the Core OS layer
contains the low-level features that most other technologies are built upon. Below is a description of some
of the frameworks found within this layer:-

Accelerate Framework

(IOS developer, 2013) this framework contains interfaces for performing digital signal processing (DSP),
linear algebra, and image-processing calculations. The advantage of using this framework over writing
your own versions of these interfaces is that they are optimized for all of the hardware configurations
present in iOS devices. Therefore, you can write your code once and be assured that it runs efficiently on
all devices.

Core Bluetooth Framework

(IOS developer, 2013) The Core Bluetooth framework allows developers to interact specifically with
Bluetooth low energy (LE) accessories. The Objective-C interfaces of this framework allow you to do the
following:

 Scan for Bluetooth accessories and connect and disconnect to ones you find
 Vend services from your app, turning the iOS device into a peripheral for other Bluetooth devices
 Broadcast iBeacon information from the iOS device
 Preserve the state of your Bluetooth connections and restore those connections when your app is
subsequently launched
 Be notified of changes to the availability of Bluetooth peripherals

P a g e | 21
2.4 Windows OS

It is family of mobile operating systems developed by Microsoft. . (Fingas, 2013) its current market share
is at 4%. It has four layers of abstraction, applications, App Model, UI Model, Cloud integration and the
Kernel. Figure 4 below shows the architecture of the Windows mobile phone:-

Figure 5: Windows Architecture (Android to WP7-Chapter 1)

Applications

This is the layer where all the applications run on. Consists of various frameworks e.g. Silverlight
(Microsoft, 2013) which is a developmental tool for creating engaging, interactive user experiences for
Web and mobile applications. (Microsoft, 2013) XNA is a set of tools for with a managed runtime
environment that supports video game development. (Microsoft, 2013) also contains HTML/JavaScript
which is client side programing languages used for presentation of web content.

App Model

A model that application management which application is on the top stack, licensing which enforce
licensing policies for applications that you publish in the Windows mobile store, Software updates etc.

UI Model

User interface model contains, shell frame, Session Manager that Saves and restores the state of all or
some windows - either when you want it or automatically at startup and after crashes, direct 3D which is
used for rendering three dimensional graphics etc.

P a g e | 22
Cloud Integration

Cloud integration which allows multiple application programs to share data in the cloud. (Microsoft,
2013) The advantages this provides are a user can access personal data in real time from any device, can
access personal data from any location with Internet access, can employ the same logon information
(username and password) for all personal applications and Cloud integration offers scalability to allow for
future expansion in terms of the number of users, the number of applications, or both.

Kernel

The kernel just like in iOS and Android interacts with the hardware, it does memory allocation for apps,
provides for security, and gives access to apps to use services like GPS, connect through Wi-Fi etc.

P a g e | 23
Systems using mobile devices in eHealth delivery
This section will review the existing systems that have been implemented in eHealth using mobile
technology in their service delivery.

Distributed eHealth Using Server Oriented Architecture

The Second system under review is the distributed eHealth System using SOA (Server Oriented
Architecture).

This is both a Mobile and PC based eHealth system implemented in the United States. It uses Atom, RSS
feeds and Web-Services coupled on top of SOA for system interoperability. SOA is an architecture in
which the building blocks are services. (Kart, 2008), SOA enables reusability of software components,
provides protocol integration. It supports cross platform independence and communication. Figure 7
below shows the architecture implemented using SOA:-

Figure 6: Distributed eHealth using Server Oriented Architecture

The architecture has three modules, the patient, Clinic and Pharmacy modules. These modules have web-
services to allow for interoperability between the various components within the entire system. As can be
shown from figure 7 above access to this system can be done using desktop computers, server computers
and PDA‟s. In line with security the system authenticates users and logs session information and attaches
resource creator so that only privileged users can view or modify the data.

Having only three modules makes the system un-scalable in a sense that it only takes account of three
roles in health which is doctor, patient and pharmacist, what about other key stakeholders e.g. Lab
technicians who need to also have an interface to write blood samples for various tests ran on a patient.
The security implementation of providing a password and session logging information for access to the
system is a brilliant implementation.

P a g e | 24
Clinic Module

The clinic module supports routine activities of physicians and nurses at the clinic by maintaining
information such as appointments for a day or week (Kart, 2008). The module exposes a web server
interface for users who prefer to access the healthcare services from a web browser.

The web server interface is used in various ways e.g. a physician or nurse can use the Web server
interface to access from a desktop computer or PDA, and the patient can use the same interface to request
for an appointment with the physician for a specific date and time. In addition (Kart, 2008) to these
services the module provides, monitoring devices-such as electronic blood pressure monitors, glucose
monitors, weighing scales, pillboxes, and so forth can transmit information to a desktop or laptop
computer via a wired or wireless network and then to the clinic Web server over the internet.

The clinic module is also able to send prescriptions from the physician to the pharmacy Web service. The
prescriptions are sent to the nearest pharmacy closer to the patient‟s home. It does this (Kart, 2008) by
sending a Web service query to a Web service registry, where pharmacies offering such services have
registered and the location is ascertained and checked with where the patient is residing.

The physician (Kart, 2008) can use a PDA to enter and retrieve during or after an appointment and to be
able to access the information later. The system is currently using an OQO PC, which is a full featured 3 x
5-inch PC with an 800 x 480 pixel detailed computer graphic computer. This has disadvantage in a sense
that it makes it difficult for the physician to input information, so in addition to the graphical interface the
device is equipped with speech recognition and synthesis software (Kart, 2008) that lets the physician
enter and retrieve information by speaking and receiving spoken feedback. In the surety of accuracy, the
physician must confirm the prescribed medication and its dosage upon entry to the system because such
information is critical to a patient‟s life as any mistake made would make a patient‟s condition worse.

Pharmacy Module

This module provides services to the pharmacist. It keeps records of the patient‟s prescriptions for
reference and updates prescription status as the pharmacist fills them. The pharmacist can use the Web
Server interface to view prescriptions as he/she receives them from a physician. The Web server interface
lets users access the pharmacy module from a web browser just like in the clinic module.

The patient can use this interface to determine whether a prescription has been filled and is ready for pick
up or delivery. This is very advantageous especially on the part of the patient as it would save them on
resources to go and check up for prescriptions that are not yet ready for pickup.

The communication between the clinic module and the pharmacy module is, the physician at the clinic
will send prescriptions to the pharmacy module over the internet using the pharmacy Web service. The
Web service verifies the physicians‟ identity, and also checks the patient‟s insurance before processing
the prescription. This is also a good mechanism as even though the web services are exposed for
consumption over the internet, credentials still have to be provided a person to log into the system and
make changes. The other advantage of this is the aspect of taking logs for the sole purpose of
accountability so that incases of something going wrong e.g. a wrong prescription to a patient, the system
logs can be checked on who logged in at a particular time to prescribe that particular medication.

P a g e | 25
Patient Module

The Web server interface allows the patient to be able to communicate to the clinic module and be able to
make appointments with a physician on a specific day of the week. And also a patient can be able to track
the progress of their prescriptions, view prescription history and also renew existing prescription.

If a patient (Kart, 2008) requests a prescription to be filled, he/she must make a payment or copayment
before the pharmacist can start to fill the prescription. The pharmacy module sends reminders to the
patient about the status of the patient‟s prescription as well as messages from pharmacist to the patient.

It is through the use of this module that patient‟s health status is assessed and reports are made. The
system supports the use of medical monitoring devices to report periodically or in emergencies, to send
alerts. When a patient queries the system, the query is sent along with the device‟s serial number, the
clinic webserver makes the association with the particular patient and if the device is not yet registered,
the Web service discards the data from the device. This is a good implementation as it enhances on
accountability as the exact credentials are given of whoever tries to gain access to the system.

Underlying Information Technology Used

The prototype (Kart, 2008) “was implemented in java because of its ability to be deployed on small
wireless devices and powerful servers”. To ease development and debugging of the system, the
implementation uses plain old java objects (POJO) based on the spring framework.

The distributed e-healthcare system uses the apache Axis2 framework which is the core engine for
building Web services on the Apache Axiom platform and Tomcat server. Axis2 provides data bindings
that enable application developers to generate SOAP messages minus be concerned about how to create
and parse them. This is a plus as most time is spent on how to use and consume the services unlike how to
build them as the platform will generically build them.

For security purposes (OASIS, 2007) provides a means of incorporating security features in the SOAP
message header. It supports (Kart, 2008) multiple trust domains, encryption technologies, signature
formats, and security token formats.

On the implementation of speech recognition the system uses SRI‟s DynaSpeak speech recognition
software because it supports the integration and use of many languages it also adapts too many accents,
and doesn‟t require prior training. DynaSpeak (Kart, 2008) is ideal for embedded platforms because of its
small footprint its low computing requirements.

The distributed system uses AT&T‟s natural voices speech synthesis software, which can (Kart, 2008)
accurately pronounce words and speak in sentences that are clear and easy to understand. Natural voices
support many languages, male and female voices, and other several interface standards.

In cases where there is a network failure of some kind e.g. in an emergency like there problems with the
internet service provider, (Kart, 2008) earthquakes etc. Atom and RSS which are syndication technologies
based on XML will make it possible for the sharing and communication of information between
heterogeneous platforms by making the information self-describing. Atom will be used to synchronize

P a g e | 26
information on desktop or server with the information on a handheld device. This will make it possible
for physcians, nurses, and pharmacists view and update healthcare information when it‟s offline. This is a
good implementation looking at the reliability of internet provision in Zambia this would work well for
current system to be built.

P a g e | 27
Samsung Medical Center (SMC) Dr SMART S

This section will review Dr SMART a mobile application platform built by Samsung which runs on the
android platform whose major aim is to give doctors mobile access to patient‟s records.

The main features of the application includes; providing for information of inpatient, outpatient, patient at
operating room and patients at emergency room.

Technical Framework

The app is made up of three components as can be seen in seen in figure 7. First component is the server
group, Network infrastructure and Terminal. The (Park, Lyul, 2011) terminal is a kind of smartphone
which can have downloadable apps run on the OS which in this case SMC has chosen the terminal as
Samsung Galaxy S, which loads Dr. SMART on Google Android platform.

The (Park, Lyul, 2011) app was developed using Eclipse IDE (Platform 3.5) meaning java was used as
development language. For the Network infrastructure SMC (Park, Lyul, 2011) makes full use of both
wireless and wired network. The endpoint connected wireless by the terminal is the Aruba wireless access
point (AP-70, IEEE 802.11 a/b/g) as can be noticed in figure 7. The wired is composed of backbone
switch (10 Gbps), which is located in the (Park, Lyul, 2011) computer room, a distribution switch (1
Gbps) from the computer room to every floor in the hospital, and workgroup switch (100 Mbps) at every
floor as well this is for the sole purpose of making network access to everyone in the hospital.

The Server group consists of mobile server (which consist of authentication data) which retrieves data
from legacy system which is repository server and provides the data to the terminal. The OS and database
management system (DBMS) on the mobile server are Windows Server 2003 and MySQL 5 respectively.
The (Park, Lyul, 2011) development tool for mobile server software module was Netbeans 6.0. Legacy
system uses Hewlett-Packard integrity superdome as hardware, HP-Unix 11.23 as OS, TMAX 4.0 as
middleware for heterogeneous platforms to be able to communicate, and Oracle 10g as DBMS
respectively.

Figure 7: Framework of Dr. SMARTPHONE S. (Park, Lyul, 2011)

P a g e | 28
Algorithm and Content Structure

This section will discuss the algorithm and content structure of the application.

The first part is downloading, in order to successfully execute Dr. SMART S; the app has to be firstly
downloaded and installed to the terminal (smartphone).

Figure 8: Algorithm and content structure. MAC: media access control (Park, Lyul, 2011)

The login screen is displayed if the app‟s icon is pushed on the mobile screen. As can be seen from figure
8 above identification as well as a password should be provided which is later encrypted and transmitted
to a mobile server through the wireless network the terminal is connected to.

Authentication is provided in two (Park, Lyul, 2011) levels the ID and Password is the first level which is
also compared with the device’s MAC address of the terminal by the legacy system at the second level.
This level of authentication is good as it protects against unauthorized access even if the phone is lost.

The terminal is disconnected from the network if no activity has taken place on the terminal for a
considerate amount of time which is set by SMC’s policy this is a good security implementation in a
sense that when a legitimate user logins and maybe drops the phone the phone will be disconnected
after some time as they will be no inactivity on the device. After an authorized user successfully logins,
the app displays 6 menus as can be seen in figure 8. The click on any of them will give patient
information. When inpatient is clicked it shows a list of inpatients together with their names, doctors,
and other clinical information such as disease and infection.

In conclusion Dr. SMART’s major objective was to give an easier access to patient’s medical records at a
push of a button. After reviewing this system the researcher will integrate or incorporate MAC
addressing authentication together with the usual ID and password in the proposed system.

P a g e | 29
KAU Mobile System

This section will review the KAU Mobile System a mobile based system implemented in Saudi Arabia.
The major objectives (Alghazzawi & Oadah, 2011) of the system is to provide a complete overview of all
patients from hospital admission to their discharge, coordination of the clinical and non-clinical patient
process that includes therapeutic (is the treatment of disease) and diagnostic order logistics occurring in a
hospital environment.

It is based on Cloud Computing a technological implementation where multiple servers are placed in one
location for easy data access. It uses a centralized architecture for data storage where the medical records
are kept with ministry of Health of security purposes.

KAU-Health OS provides portability and connectivity for optimal interoperability so to be able to run on
different platforms (Alghazzawi & Oadah, 2011) with stringent data security, privacy levels and easy
recoverly in case of system failure. The application system is built on the assumption that various
hospitals have different business plans hence it is made up with high levels of flexibility and
interoperability in mind as they are key to support for customization.

Figure 7 below shows the centralized architecture used in KAU Mobile System.

Figure 9: KAU Mobile Architecture (Alghazzawi & Oadah, 2011)

KAU-Health as previously alluded to ensures portability and connectivity for optimal interoperability so
as to run on all standard hardware platforms with very strict and stringent data security, privacy levels

P a g e | 30
and easy recovery in case of system failures. The architecture above shows the various sections in which
different clusters interact within the system, for security purposes medical records are stored with the
Ministry of Health.

The system as can be seen from the architecture is connected to the emergency hotline 998 which is the
state‟s emergency system‟s line in order to facilitate stakeholder e.g. firefighters and also ambulance
corps coordination with other health centers so as to improve general emergency health care.

Pharmacies module facilitates for electronic prescriptions of drugs which are officially registered in the
health care system.

The health system includes the KAU hospital and several primary care centers connected to it, but it si
designed in such a way as to support future inclusions of more hospitals and health centers.

The relational database in figure 7 shares information with stakeholders of the system and external
entities who in this case is the Ministry of Health. Communication is done via Web Services operations
that perform sending and receiving of customer data. The system gives support to all the stakeholders in
health; doctor, patient, laboratory technicians, nurses etc.

Literature Critic

The system‟s use of a centralized storage structure poses a risk to security in the sense that once
unauthorized personnel gains access to the system he/she will have access to all medical records at a go
there by breaching on confidentiality and integrity of the data. Having multiple requests to a single server
will reduce on performance (Bong, 2011) as they will be multiple requests coming to be serviced by a
single resource and also a hacker can take advantage of this by sending unnecessary ping requests there
by shutting down the database.

Susan Ward (Ward, 2013) gives disadvantages of implementing cloud computing she speaks on firstly
possible down time were she stresses that since cloud computing is heavily dependent on an active
internet connection, a system using cloud computing will have down times incases when the internet
connection is down. The second point she stresses is on the aspect of security where she says that since
data is kept in a cloud, cloud providers find it easy to provide security for smaller organizations with
small amounts of data unlike big organizations handling massive data hence this would be a disadvantage
for this system as patient‟s medical records keep on increasing.

Lastly but not the least the system does not give a comprehensive overview structure on how security will
be implemented. Security is a very important aspect of any medical record system and without a proper
implementation will make a system unusable and render it useless.

P a g e | 31
Countries that have implemented eHealth in their service delivery

This section will cite brief examples in the region, and the rest of the world that have embraced the use of
ICT‟s in their health service delivery.

Countries in the sub-Saharan region have realized the benefit of investing in eHealth to meet their MDG‟s
on health. South Africa released the national health eHealth strategy (Medivate, 2013) to pave way for
improving and streamlining eHealth initiatives in the country whose major aim is to ultimately improve
access to care for millions of South African Citizens and it is currently running a mobile based project
that sends text messages on issues to do with HIV and AIDS.

Zimbabwe has in a bid to move with global developments developed (Mawire, 2012) eHealth strategies to
enhance service delivery and increase competiveness in the health sector by targeting most people in rural
areas.

Malawi also has not been left behind; Prof Vakil (Vakil, 2013) describes their experiences in
implementing an electronic patient record system in a large referral hospital in the southern part of
Malawi. The system known as Surveillance programme of IN-patients and Epidemiology (SPINE) is used
to record patient details during consultations and this data is used to monitor changing patterns of disease
at the hospital.

Egypt also is not left behind in utilizing their ICT infrastructure (IST, 2010) reports that the government
of Egypt and its Ministry of Health have established several eHealth programs to bring better diagnostic
and health services to a wider segment of the Egyptian society whose major objectives are to extend
better medical diagnostic services to rural area, reduce the cost of health care through better patient
management, provide an advanced medical services in cases of emergencies etc.

Outside Africa is India which also has heavily invested in eHealth as a tool to drive economic growth,
(PRNewswire, 2011) which reports that with India‟s growing use of EHR and EMR technology to
differentiate itself, the Ministry of Science & Technology is driving the government‟s role and has since
sanctioned 2, 69 billion rupees which is equivalent to ZMK 23525.65 million for the sole purpose of
improving the countries rural inhabitants.

Challenges of implementing eHealth in Zambia

There are various challenges that affect the countries fully implementation of eHealth (thezambian ,2007)
addresses some of them as inadequate human resource, lack of expertise in health information system
technology this poses a great challenge especially that software development is not given the limelight
that it should have hence no motivation for new innovations and research even in the field of eHealth ,
Resistance by the community to support the same cause where mostly their concerns are on the issues of
security but if they are sure that their monies are safe during mobile banking why shouldn‟t their records
be safe as well when what are being used are the same security frameworks , infrastructure-lack of
Telecom facilities and power and also lack of coordination and intersectoral collaboration caused by lack
of awareness and sensitization by decision makers, journalists and health officials. These and many other
reasons are making it hard for the country fully harness the power that technology when rightly applied to
meet challenges in health can have.

P a g e | 32
In summary this chapter has firstly described the three widely used mobile platforms as availed by IDC
namely android, iOS and Windows mobile, reviewed three existing systems that have integrated mobile
based technologies in their service delivery looked at their strengths, technologies critiqued their
shortfalls and also how some of their implementations can be integrated in the proposed system. Lastly
not but the least cited some examples in the world where eHealth has or is being implemented and also
highlighted some challenges why the author feels the implementation is proving as a challenge in the
Zambian setup.

P a g e | 33
 CHAPTER 3

RESEARCH METHODOLOGY
3.1 Introduction

In this chapter the research methodology used in the study is described. The geographical area where the
study was conducted, the study design and the population sample are described. The instrument that was
used to collect the data which includes methods implemented to maintain validity of the instrument, are
described as.

Research Approach and Design

A quantitative approach was followed. (Burns and Grove, 1998) defines quantitative research as a formal,
objective, systematic process to describe and test relationships among variables. Surveys may be used for
descriptive, explanatory and exploratory research. A descriptive survey design was used. A survey is used
to collect original data for describing a population too large to observe directly (Mouton 1996). A survey
obtains information from a sample of people by means of self-report, that is, the people respond to a
series of questions posed by the investigator. In this study the information was collected through self-
administered questionnaires distributed personally to the respondents by the researcher.

Research Setting

This study was conducted at the recently held 7th national health research conference held at the new
government complex building from 14th – 16th of October 2013. It was held under the theme, “Achieving
Universal Quality Health Care Coverage through increased Investment in Research and Development”. It
is at this conference the researcher demonstrated an A3 poster presentation and also distributed
questionnaires for respondents to fill in.

The Study Population and Sample

According to (Burns and Grove, 1993) a population is defined as all elements (individuals, objects and
events) that meet the sample criteria for inclusion in a study. The study population included all
participants attending the conference targeting mostly medical doctors as they are the major stakeholders
in the research.

A convenient sample of 22 participants was selected. Mouton (Mouton, 1996) defines a sample as
elements selected with the intention of finding out something. This was composition of 13 Medical doctor
and 9 other personnel in the ministry of health.

Data Collection Instrument

A questionnaire was chosen as a data collection instrument. A questionnaire is a printed self-report form
designed to get information that can be obtained through the written responses of the respondents. The
information gotten using a questionnaire is similar to that obtained using interviews but questions tend to
have less depth (Burns & Grove 1993).

P a g e | 34
Data was collected with the aid of questionnaires and interviews were also conducted whilst there at the
conference to get respondents views on eHealth, how it can be applied to the Zambian setup, its relevance
and how much they knew about it. Questionnaires where decided upon mainly because:-

1. They ensured a high response rate as the questionnaires were distributed to respondents to
complete and were collected personally by the researcher.

2. They required less time and energy to administer.

3. Most of the items were closed ended questions, which made it easier to compare the responses.

The questionnaires were filled in by most respondents visiting the poster stand but the major targets
where medical doctors. Below shows the breakdown of the respondents:-

Respondent Breakdown

39%

Doctors
Other

61%

Figure 10: Respondent Breakdown

Find attached the Full evaluation of the Questionnaires in the appendix section.

P a g e | 35
Validity

The validity of an instrument is the degree to which an instrument measures what it is intended to
measure (Polit & Hunger 1998). To achieve content validity, questionnaires included a variety of
questions on the knowledge of the respondents in regards to eHealth.

The questions were formulated in simple language for clarity and ease of understanding. Clear
instructions were given to the subjects and the researcher made it a priority to explain questions that were
not understood by the respondent.

All the respondents completed the questionnaires in the presence of the researcher. This was done to
prevent the respondents from giving other people to fill in on their behalf and also to make sure that the
questionnaires where returned after they were completed.

Research Process Model

A software process is defined as (Bennett, 2007) a structured set of activities required to develop a
software system. The major stages involved are Specification, Design, Validation and Evolution. While as
a process model is defined as an abstract representation of a process or represents a description of a
process from a particular perspective.

This project‟s methodology implementation is the agile way of software design also referred to as soft
methodology in particular Dynamic Systems Development Methodology.

Why Agile

According to (Bennett et l, 2007) problems that had incorporated in traditional lifecycle e.g.
waterfall model included unresponsiveness to change and highly bureaucratic approach that was
heavily dependent on documentation, meaning without a clearer definition of user requirements
which is usually never the case, systems where doomed to fail. Agility assumes that user
requirements are subject to change during the life cycle of a project hence they need to be
accommodated by the development process. Below shows the agile manifesto that confirms the
statement above:

We are uncovering better ways of developing software

By doing and helping others do it.
Through this work we have come to value:
Individuals and Iterations over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

As can be noticed from the manifesto extract written by a team of software developers that met
in February 2001, a new approach in enhancing customer relationship with the development
team is the main major focus of agility. Agile as much as it recognizes the importance of having
user requirements does not put much emphasis on it, as it is subject to change and that even the
users themselves have a blurred image of the system they want to be built for them. The

P a g e | 36
customer in agile methods is also part of the development team and monitors progress at every
stage unlike in traditional methods where the development team closes themselves in and only
comes back to the customer after the system is complete.

Dynamic Systems Development Method (DSDM)

DSDM is defined as (Bennett et l, 2007) a management and control framework for rapid
application development (RAD) meaning it is in fact built from the characteristics RAD has.
RAD is an approach to systems development that aims at building a working system rapidly. The
system to be built is done incrementally until it becomes a working system.

One of the key innovations of DSDM as given by Bennett and the colleagues (Bennett et l, 2007)
is its perspective on project requirements. Instead of seeing the requirements as fixed, and then
attempting to match resources to the project, DSDM fixes the resources for the project (including
the time available for completion) and sets out to deliver what can be achieved within these
constraints, meaning acquisition for requirements is dynamic and subject to change.

DSDM is based upon nine underlying or core principles (DSDM Consortium/Stapleton, 2003):-

1. Active user involvement is regarded as imperative. Many other approaches

especially in traditional methods restrict user involvement in the project design. In
DSDM users are members of the project team. One user who sits on the team is
referred to as „Ambassador‟ user.
2. DSDM teams are empowered to make decisions. A team can make decisions that
refine the requirements and possibly even change them without the direct
involvement without the direct involvement of higher management. This is
beneficial as it cuts down on wasted time waiting for approvals.
3. The focus is on frequent product delivery. A team is geared to delivering products
in an agreed upon time period and it thereafter selects an appropriate approach to
achieve the same. The time periods are referred to as time boxes and are normally
kept short (2 to 6 weeks). It helps team members decide in advance what is
feasible.
4. The essential criterion for acceptance of a deliverable is fitness for business
purpose. Meaning the methodology is geared to delivering essential functionality
meeting business needs at an appropriate and agreed upon time.
5. Iterative and Incremental development is necessary to converge on an accurate
business. Iterative development means allows user feedback to inform the
development of later increments. The delivery of partial solutions is considered
acceptable if it satisfies an immediate and urgent user need. They can be later
refined and further developed later.
6. All changes made during development are kept reversible. If the iterative
development follows an inappropriate path then it is necessary to return to the last
point in the development cycle that was deemed as appropriate (backtracking).
7. Requirements are initially agreed at a high level. Once the requirements are fixed
at a high level they provide the objectives for prototyping. They requirements are
then investigated in detail by the development team to determine how best they

P a g e | 37
 can be achieved.
8. Testing is integrated throughout the lifecycle. Since a partially complete system
may be delivered, it must be tested during development, rather than after
completion. Developers test each component for technical compliance and the
user tests for functional appropriateness.
9. Collaborative and co-operative approach between all stakeholders is essential. The
major emphasis here is on the inclusion of all stakeholders in a collaborative
development process.

The DSDM lifecycle

The DSDM lifecycle has five phases:

1. Feasibility study
2. Business study
3. Functional model iteration
4. Design and build iteration
5. Implementation

Below shows the diagrammatic representation of the relationships between these phases:-

Figure 11: Simplified DSDM lifecycle (DSDM Consortium, 2004)

P a g e | 38
The feasibility study determines whether the project is suitable for a DSDM approach. This
phase lasts for only a few weeks compared to feasibility study in traditional methods which can
even go for months. The feasibility study should answer the following questions (Bennett et l,
2007):-

i. Is the computerized information system technically possible?

ii. Will the benefit of the system be outweighed by its costs?
iii. Will the information system operate acceptably within the organization?

The business study phase identifies (Bennett et l, 2007) the overall scope of the project and
results in agreed high-level functional and non-functional requirements. This is the phase where
maintainability objectives are set; these determine control activities for the remainder of the
project. The three levels of maintainability are:-

i. Maintainable from initial operation

ii. Not necessarily maintainable when first installed but this is addressed later.
iii. Short life-span system that will not be subject to maintenance

The Functional model is concerned with development of prototypes to elicit or mimic detailed
requirements. The prototypes are delivered as operational systems, hence they are developed
sufficiently robust for operational use and also to satisfy any non-functional requirements e.g.
performance. When completed it models high level (Bennett et l, 2007) analysis models and
documentation, combined with prototypes that are concerned with detailed functionality and
usability. The activities (Bennett et l, 2007) that are under during this phase are:-

i. The functional prototype is identified.

ii. A schedule is agreed
iii. The functional prototype is created
iv. The functional prototype is reviewed

The design and build iteration phase is concerned with developing the prototypes to the point where
they can be used operationally. The distinction between this model and the functional model is not
clear, they can work concurrently.

The implementation phase deals with installation of the latest increment, (Bennett et l, 2007)
that includes user training. It is at this point were a critical review how far the requirements have
been met. If some requirements haven‟t been met the project may return to the design and build
iteration phase and if they have been met the project is considered to have finished.

P a g e | 39
3.2 Risk and Quality Management

This section will first discuss the definition of risk management and thereafter discuss on Quality
management.

A risk is defined (office, 2010) as the possibility of an event or condition that would have a negative
impact on a project. Project management body of Knowledge also defines a risk (PMBOK, 2008) as an
uncertain condition that, if occurs has an effect on at least one project objective. Risk management is
therefore defined as (PMBOK, 2008) the process of identifying, mitigating, and controlling the known
risks in order to increase the probability of meeting your project objectives. Objectives in this case
include the scope, quality and cost of the project.

Lack risk management is one of the major factors that cause or result in project failure. Hence resulting in
the attachment my risk management for this particular research where the author has identified some risks
and how they will be avoided.

Quality management (PMBOK, 2008) includes the processes and activities of performing organization
that determine quality policies, objectives and responsibilities so that the project may satisfy the needs of
which it was first undertaken. It addresses the management of the project and the product of the project
meaning quality management is still undertaken even after the product has been delivered. Quality
management of a project is of a vital importance hence a failure to meet product or project quality
requirements can have serious negative consequences for any or all of the project stakeholders.

Find attached my Risk and Quality register in the appendix.

P a g e | 40
3.3 Scheduling and Work Plan

Task scheduling in project management is implemented to aid the development team with coming up with
software that is within budget, scope and meets the end users requirements. The diagram below shows
task break down the project.

Figure 12: Work Breakdown Structure

P a g e | 41
 Figure 13: Gantt chart

Figure 12 above shows the Gantt chart for the project. A Gantt chart as can be shown from figure 12
shows duration of mile stones. Gantt charts illustrate the start and finish dates of the terminal elements
and summary elements of a project. Terminal elements and summary elements comprise the work
breakdown structure of the project.

P a g e | 42
3.4 Effort Costing

Inaccurate estimation of software development cost are one of the largest causes of project failure hence
the need to effectively manage costs of a project right in its infancy.

Effort costing is defined PMBOK (2008) as the process of developing an approximation of the monetary
resources needed to complete project activities. It involves doing cost estimates which are predictions
based on information that is available at a given point in time. It includes identification and considering of
costing alternatives to initiate and complete the project.

In this section the researcher has chosen the Constructive Cost Mode (COCOMO) to do effort costing in
this particular project. CSSE (CSSE, 2002) defines COCOMO as a model that allows one to estimate the
cost, effort, and schedule when planning a new software development activity. It has three developmental
modes Organic, Semidetached Mode and Embedded Mode. Organic mode means the project has been
developed in a familiar, and stable environment meaning the system to be developed is similar to an
already existing system. Embedded means the system to be developed is a new invention and it has not
yet being discovered. This requires a great deal of research and innovation. Lastly is the semidetached
which is in between of Organic and Embedded, meaning some aspects of the system is not yet know
while other aspects is known. The system in consideration will use the organic approach as there are other
already existing systems in existence.

Scale of 1 - 5

Data Communication 3
Heavy Use Configuration 0
End-User efficiency 3
Complex Processing 3
Installation Ease 3
Multiple Sites 0
Performance 4
Distributed Functions 3
On-line update 2
Reusability 3
Operational Ease 3
Extensibility 3

Project Complexity 30

Table 1: Complexity Factors

P a g e | 43
Table 1 shows complexity factors which are defined as (BusinessDictionary, 2013) numbers that denote
the level of complexity of a condition or situation. They are arrived at usually through estimation or
judgment of factors, interrelations and interconnections.

FUNCTIONAL POINT S ESTIMATION(1)

DESCRIPTION LOW MEDIUM HIGH TOTAL

INPUTS X3 4X4 X6 16

OUTPUTS X4 4X5 X7 20
QUERIES X3 4X4 X6 16

FILES 1X7 X10 X15 7

X5 3X7 X10 21
PROGRAM INTERFACES
Total Unadjusted Function

Points 80

Table 2: Functional Point Estimations

Functional points measure a software project by quantifying the information processing functionality
associated with major external data input, output, or file types. As can be seen in table 2 functional inputs
count each unique user data or user data or user control input. External output counts each unique user
data or control data that leaves the external boundary of the system. Files count each logical user or
control data in the system e.g. logical group data that is generated, used, or maintained by the system.

FUNCTIONA POINTESTIMATION (3)

PROCESSING COMPLEXITY (PC) 30
ADJUSTED PROCESSING COMPLEXITY (PCA) 0.65+(0.01*30)=0.95
TOTAL ADJUSTED FUNCTION POINTS 80*0.95 = 76

LOC = 76 X 46 = 3496 ~ 3.5 KSLOC

Efforts = Productivity x KSLOCPenalty

= 3.3 x 3.51.030 = 12 Person-Months

Person-months or man-months are defined as the measure of work effort. It measure the effort put in a
single month on a project. The estimation above shows that my system will have about 3496 lines of code
and the effort or input put in within a month will be 12. The overall system cost is 12x15, 000 =
180,000ZMK + 15% Overhead costs bringing Total to 200,000ZMK.

P a g e | 44
References

1. Medivate. (2013) South Africa Releases National eHealth Strategy. Available:

<http://www.medivate.co.za/news>[ accessed 11 November 2013]
2. ITU, (2009) Mobile Phone subsribers pass 4 billion mark Available from:
<http://www.itu.int/ITU-D/ict/newslog/mobile+phone+subscribers+pass+4+billion+mark.aspx/>
[Accessed 22 November 2013]
Dan Mitchell, (2013) Mobile Sales Surpass PC Sales for Top PC-Seller-Lenovo. Available from:
<http://tech.fortune.cnn.com/2013/08/15/mobile-sales-sales-surpass-pc-sales-for-top-pc-seller-
lenovo/ > [accessed 22 November 2013]
3. Traxler, (2007) What is mobile learning? Available from:<
http://www.academia.edu/104096/what-is-mobile.pdf/> [22 November 2013]
4. Liu C, Zhu Q, Holroyd KA, Seng EK. Status and trends of mobile-health applications for iOS
devices: A developer's perspective. J. Syst. Software. 2011;84(11):2022–2033. doi:
10.1016/j.jss.2011.06.049. [Cross Ref]
5. Wallace Mawire. (2012) Zimbabwe Adopts eHealth Strategies. Available:
<http://www.keycorrespondents.org/2012/11/05/zimbabwe-e-health-strategies/> [accessed 13
November 2013]
6. Dr. Enozia Vakil. (2013) eHealth Implementation in Malawi. Available:
<http://www.medindia.net/news/e-health-implemented-in-malawi-115810.htlm/> [13 November
2013]
7. 1st Africa. (2010) Overview of ICT initiatives in Egypt. Available:< http://www.1st-
africa.org/home/default.asp?page=doc-by-id&docid=5185 > [accessed 13 November 2013]
8. PRNewswire. (2011) Ministry of Science & Technology, Govt of India to Drive eHealth
innovations-2,68 Billion rupees Sanctioned for Health Sector. Available:
<http://www.prnewswire.com/news-releases/ministry-of-science-technology-govt-of-india-to-
drive-ehealth-innovations-268-billion-rupees-sanctioned-for-health-sector.126751993.html/>
[accessed 13 November 2013]
9. thezambian. (2011) Reporting eHealth Challenges for Media. Available:
<http://thezambian.com/2007/08/31/reporting-ehealth-challenges-for-media > [accessed 13
November 2013]
10. Daniyal M. Alghazzawi, Mouath Oadah. (2011) KAU Mobile System. P4-5
11. Jon Fingas. (2013) Android has 81 percent of Smartphone Market Share in Q3. Available:
< http://www.engadget.com/2013/10/31/strategy-analytics-93-2013.phone-share/ > [accessed 11
November 2013]
12. Xiodang Zhang. (2001) Linux Kernel and Android Suspend/ Resume-blog-archive: Blog
Available from : <http://community.freescale.com/thread/261901> [accessed 11 November 2011]
13. Edureka. (2013) The Beginners Guide to Android: Android Architecture 2 January 2013.
Edureka: Blog. Available from : <http://edureka.in/blog/beginners-guide-android-architecture/ >
[accessed 11 November 2011]
14. The Iphone OS Architecture and frameworks. (2011) Available from:
<http://www.techotopia.com/index.php/the-iphone-os-architecture-and-framewoks/ > [accessed
11 November 2011]

P a g e | 45
 15. Khrows group. (2013) The Standard for Embedded Accelerated 3D graphics. Available: from
<http://www.khrows.org/opengles/> [accessed 11 November 2011]
16. Susan Ward. (2013) 5 Disadvantages of cloud Computing. Available from:
<http://sbininfocanada.about.com/od/itmanagement/a/cloud-computing-disadvantages.htm >[
accessed 11 November 2013]
17. Bing Bong. (2011) Distributed vs. Centralized, 2011. September 21 2011. Teachbook: Blog
Available from : <http://blog.teachbook.co.au/index.php/2011/09/distributed-vs-centralized-
databases/> [accessed 1 November 2013]
18. IOS Developer library. (2013) Media Layer. Available from
<htttp://developer.apple.com/library/ios/documentation/miscellaneous/conceptual/iphoneostecho
verview/medialayer.html> [accessed 11 November 2013]
19. Simon Bennett, Steve McRob, RayFarmer (2007). Object-Oriented Systems Analysis And
Design Using UML. 3rd Edition.
20. DSDM Consortium/Stapleton, J. (Ed), DSDM: Business Focused Development (2nd Ed), Harlow:
Addison Wesley/Pearson Education, 2003.
21. PMBOK (2008). A Guide to the Project Management Body of Knowledge. (4th Ed). Project
Management Institute, Inc, 2008.
22. Gary Woodil, (2013). Microsoft buys Symbian for $7.2 Billion: What does it mean for mobile
learning? Availabe from: < http://www.floatlearning .com/2013/09/microsft-says-nokia-7-2-
billion-what-does-it-mean-for-mobile-learning /> [accessed 13 November 2013]
23. CSSE, (2002) COCOMO II. Available from:
<http://csse.uc.edu/csse/research/cocomoii/cocomo.main.html> [accessed 19 November 2013]
24. BusinessDictionery (2013). Complexity factor Available from :
<http://www.businessdictionery.com/definition/complexity-factor.html>[ accessed 19 November
2013]
25. Android to WP7 Chapter 1, (2011) available from: <
http://www.windowsphone.interoperabilitybridges.com/articles/android-to-wp7-chapter-
introducing-windows-phone-platform-to-android-application-developers > [accessed 22
November 2013]

26. Microsoft, (2013). Get silverlight5. Available from: < http://www.microsoft.com/silverlight >
[accessed 12 November 2013]
27. World Health Organization. mHealth: New Horizons for Health through Mobile Technologies:
Based on the Findings of the Second Global Survey on eHealth (Global Observatory for eHealth
Series, Volume 3). 2011. Available from:
<http://www.who.int/goe/publications/goe_mhealth_web.pdf >[accessed 22 November 2013]
28. WHO (2001). Improving Health Of the World‟s Poorest People. Available from
<http://www.prb.org/pdf/improvingthehealthworld_eng.pdf/ >[22 November 2013]
29. Chris Foresman (2012). Apple Owns Us Smartphone Market While Samsung Dominates
worldwide. <http://astechnia.com/apple/2012/08/apples-owns-us-smartphone-dominates-
wordwide/>[ 22 November 2013]
30. MOH (2004) Final Child Health Situation Summary Zambia. Available from:
<http://www.afro/who.int/index.php/ >[Accessed 22 November 2013]

P a g e | 46