You are on page 1of 43

i

PATIENT INFORMATION SYSTEM

SABINA B. ATEKA
REG NO: BIT C006-0253

A Research Project Proposal Submitted To The Department Of Computer Science And


Information Technology For The Partial Fulfillment For Degree Of Science In
Information Technology Of Jomo Kenyatta University Of Agriculture And Technology

DECLARATION
This is to certify that the project report entitled Patient Information System (PiS)submitted
by Sabina B. Ateka in partial fulfillment of the requirements for the degree of Bachelor of
Information Technology embodies the bonafide work done by myself in the final semester of this
diploma under the supervision of the undersigned.
The project or any other part of is my original work, it has not been submitted earlier to other
University/Institution for the award of any Diploma or Degree.

Name: SABINA B. ATEKA


i

REG NO: BIT C006-0253

Signature: ____________________________

Date: ______________________

Approval
This project has been submitted for examination with my approval as the University Supervisor

Name of Supervisor: James Ombogo

Signature: ____________________________

Date: ______________________

(UNIVERSITY SUPERVISOR)

DEDICATION
I dedicate this project to my beloved husband, Edwon O. Nyabuto, who supported me morally
and financially during the project development and research period.

ii

ACKNOWLEDGMENT
Every effort is motivated by an ambition and all ambitions have an inspiration behind in the
height of reaching a mile-stone in life. I owe my deep sense of gratitude that helps me in such a
constructive work with grateful heart, I avail this privilege to express my deep sense of gratitude
and indebtedness to my esteemed guide and supervisor James Ombogo for his guidance,
supervision and critical suggestion throughout the course.
I gratefully extend my sincere thanks to all faculties and to all teaching and non-teaching staff
members of the department.
Sincere thanks are extended to my friends for their valuable advice and moral support. My
thanks are due to my parents and loving sister for their affection, inspiration, patience and
support.

iii

ABSTRACT
Patient Information System is an Android app which sets up online communication between a
doctor and a patient. This app is helpful to patients to ask questions and state their concerns to
doctors regarding their health condition. This app will facilitate the patients to interact with
doctors without making any physical appointments, but the patients are restricted to only one
message per day before receiving a reply. If the patient gets a response from the corresponding
doctor, the patient is allowed to send another message. In addition using this app, the patient can
make an appointment to meet the doctor in clinic/hospital. The app would also facilitate the
patients pharmacy selection to pick up the medication. Similarly, this app is beneficial to
doctors by providing the following functionalities: Patient interaction through messaging,
sending prescription to pharmacies, confirming appointments, information sharing with other
doctors, and patient referrals. Unlike other similar kinds of systems, the system has unique
features such as issuing online prescription to patients, referring patients to a specialist, sending
health tips to patients, and effectively, reducing the cost of customer service and providing a vital
communication link between doctors and patients. This research project will carry out an
experiment whereby it will develop a system and test. Android is compatible with multiple
hardware and supports various features like Web browser, Email, Java, Video calling, Media
iv

streaming, Bluetooth, Wi-Fi, Multitasking, External storage, Screen capturing, and etc. It is
expected that patients will benefit from this system as they will access information at their own
convenience and will save money from purchasing medication by use of the lowest bidder
model.

Table of Contents
DECLARATION.............................................................................................................. i
DEDICATION................................................................................................................ ii
ACKNOWLEDGMENT................................................................................................... iii
ABSTRACT.................................................................................................................. iv
Table of Contents............................................................................................................. v
List of Tables and figures.................................................................................................. vi
Definitions of Key Terms................................................................................................. vii
Abbreviations and Acronyms............................................................................................ viii
CHAPTER ONE.............................................................................................................. 1
1.0

Introduction....................................................................................................... 1

1.1 Background of the Study............................................................................................ 1


1.2 Android Architecture................................................................................................. 2
1.3 Statement of Problem................................................................................................ 4
1.4 Objectives of the Study.............................................................................................. 4
1.5 Motivation and Research Questions..............................................................................5
1.7 Significance of the Research....................................................................................... 5
1.5 Scope and Limitations............................................................................................... 6
v

1.5.1 Scope.............................................................................................................. 6
1.5.2 Limitations....................................................................................................... 7
CHAPTER TWO............................................................................................................. 8
2.0 LITERATURE REVIEW........................................................................................... 8
2.1 Doctor Patient Information System...............................................................................8
2.2 Android Architecture................................................................................................. 8
2.3 Android Database................................................................................................... 10
CHAPTER THREE........................................................................................................ 11
3.0 METHODOLOGY................................................................................................. 11
Introduction........................................................................................................... 11
Development Methodology........................................................................................... 12
3.2 Data collection...................................................................................................... 13
3.2.1 Interviews...................................................................................................... 14
3.2.1.0 Types of interviews......................................................................................... 14
3.2.1.1 Advantages of using an interview.......................................................................14
3.2.1.2 Disadvantages of using an interview....................................................................14
3.2.2 Observation....................................................................................................... 15
3.2.3 Secondary data collection techniques........................................................................15
Appendix I: Android API.............................................................................................. 16
APPENDIX II: GANT CHART..................................................................................... 16
Bibliography & References............................................................................................... 17

vi

List of Tables and figures


Figure 1 Global Mobile Users Statistics..........................................................................................2
Figure 2 Below show the Android Architecture..............................................................................3
Figure 3 Below show the Android Architecture..............................................................................9

vii

Definitions of Key Terms

Android an operating system based on the Linux kernel, and designed primarily for
touchscreen mobile devices such as smartphones and tablet computers.
4G the fourth generation of mobile phone mobile communication technology standards.
Jelly Bean Jelly Bean was an incremental update with the primary aim of improving the
functionality and performance of the user interface.

viii

Abbreviations and Acronyms


API Application Programming Interface
OS- Operating System
IDE- Integrated Development Environment
CMMI- Capability Maturity Model Integration
WRS- World Requirements Specification

ix

CHAPTER ONE
1.0 Introduction
The establishment and improvement of doctor-patient interaction system is a very important
requirement, especially now when the mobile communication technology is developing rapidly.
The advantages of mobile web can be made full use of to make up the time and distance gap
between doctors and patients and to provide fast and adequate medical services. Through the
connection between mobile terminals and specific service, both doctors and patients are able to
obtain required data to achieve a better interaction.

1.1 Background of the Study


Mobile to overtake fixed Internet access by 2014 was the huge headline summarizing the bold
prediction from 2008, and the apps business has finally come, and this worldwide success story
is now growing fast. Apps generated an impressive USD 12 billion in full-year 2012, and in total
46 billion apps were downloaded in the year. That is certainly a rapid growth in market. In 2013,
about 90 per cent of the mobile phones purchased were smart phones, and between 2012 and
2014, the number of smart phone users over the desktop users is increased by about 0.75 billion.
The total usage is now estimated (as of 2014) to be around 1.9 billion.
Figure 1.1 shows that there is a rapid growth in the smart phone users. Smart phone is the
combination of Personal Digital Assistance (PDA) and cellular phone. Every smart phone has its
own mobile operating system which is more advanced in connectivity and computing capabilities
than a traditional mobile phone.

Ref. Link
http://www.smarti
nsights.com/mobil
emarketing/mobilemarketinganalytics/mobilemarketingstatistics/

Figure 1 Global Mobile Users Statistics

1.2 Android Architecture


Android is a Linux based operating system developed for smart phones or tablet computers. It is
a stack of software that includes operating system, middleware and libraries and APIs written in
C [10]. It was developed by Google and Open Handset Alliance in July, 2005. Android is an open
source and Google releases the source code under Apache license. This open source and free
license allow the manufacturers and the enthusiastic developers to freely develop and modify
their applications in Java like language that utilizes Google developed Java libraries [2].
This project Patient Information System (PiS) is developed for the Android Operating system.
Android is a Linux based operating system, primarily designed for touch screen mobile devices
such as smart phones and tablets. Android is compatible with multiple hardware and supports
various features like Web browser, Email, Java, Video calling, Media streaming, Bluetooth, WiFi, Multitasking, External storage, Screen capturing, and etc. The reasons for choosing Android
operating system for developing the PiS app are as follows:
i.

It is an open source technology with lot of online learning available for zero cost.
2

ii.

Large number of users use Android based smart phones, so that our app can serve more
people in the mobile industry.

iii.

According to the market survey, it has the highest number of applications available for
download on Google play store.

iv.

It is also popular among the other operating systems which focuses on low cost,
customizable, and a readymade operating system.

Figure 2 Below show the Android Architecture

1.3 Statement of Problem


Most hospitals have not installed systems that can give access to Patients informations such as
prescriptions, lab results and even access to doctors at their own convenience. For those who
have installed the system it doesnt advice the patients on how they can get the drugs at a cheaper
price. This leads to pharmacists exploiting ignorance of the patients and over charging them.
Therefore this research project incorporates lowest bidder module whereby pharmacists will
register to the system and the patient will post his/her prescription and the pharmacist will post
their quotation then the client will make the right decision on where to buy their products at
affordable prices.
In the current marketplace there are several apps for communication between doctors and
patients but most of their functionalities are commercial, and not really helpful to the users.
There are no apps which actually meet the patients basic needs and no such apps that fulfill the
patients expectations from the doctors. Though these apps have publicized themselves as the
best service providers but all the service is just limited to money making by making
appointments with doctors, tracking the visit history, patient billings, and very minimal
interaction related to disease condition of the patients. This project aims at changing this kind of
misleading and unnecessary interaction between doctors and patients, with a new initiative which
focuses more on patient benefits relating to his/her disease treatment and facilitating the doctors
with an easy and optimal way to treat the patients.

1.4 Objectives of the Study


General Objectives
i.

Analyze the existing management and computer based patient information systems

ii.

Design a patient information access system that incorporates lowest bidder approaches.

iii.

Develop a patient information system that is based on Android Platform Architecture.

iv.

Test and implement patient information access system

Specific Objectives
i.

Maintain accurate data of all prescriptions filled, allow comparisons of patient


signatures, and provide opportunities for personalized service.

ii.

Inventory and replenish most items, create real-time detailed sales reports, monitor
drug allergies and other prescription problems

1.5 Motivation and Research Questions


Motivation
It is quite possible that patient may not remember all the questions which they want to ask a
doctor when they meet in the hospital. This app overcomes this problem by providing a
messaging service between Doctors and patients or clients. This app helps the doctors to send
health tips to their patients clients and possible purchase medications clients and possible
purchase medications. Apart from the above, DPiS also facilitates making appointments with the
doctors, patient referrals to other specialists dealing with similar patients. Through all these
functionalities DPiS fulfills the basic needs of the patients which are totally non-commercial and
beneficial to both patients and doctors.
Research Questions
The study will focus on the following questions:
i.

What are the existing patients system weaknesses?

ii.

What are the problems in the existing systems?

iii.

What are the features of the systems?

iv.

What are the enhancements that can be made to the existing system or the new system we
got to adopt?

1.7 Significance of the Research


Update Module
Update enables patient care by delivering the right information, when it is needed. It has features
such as, find providers for consults and referrals in the Provider Directory, review drug
prescriptions and safety information, check for potentially harmful drug interactions, access
timely medical news and research information, disease information, alternative medications, lab
guides, and more clinical tools.
5

DoctorsAtWork Module
This application manages patient records, appointments, patient visit notes, bill patients, track
customer payments and balance due. This app can be useful for medical professionals and
students that visit patient every now and then. It also helps the patients to get the appointments
with doctors and sends the reminder through SMS or by email, create itemized bills for patients
to track the due amount, maintains the visit history of the patients, etc.
Diagnotes
Diagnotes is a mobile and web-based software system that gives medical groups the tools to
improve physician communication with their patients, care teams, and office staff. User must
have a Diagnotes account in order to benefit from this apps functionality. It routes phone calls
and text, supports documentation of every encounter for continuity of patient care.
1.5 Scope and Limitations
1.5.1 Scope
This product is developed for smart phone users, as we know how the smart phone market has
evolved in the past few years, there are many operating systems available for smart phones but
we opted the Android OS for developing this product because it has a very good user bank
worldwide. Users can only avail the services of the PPSS when they are connected to internet,
because the communication between doctors and patients, and data exchange from cloud server
needs the internet connection. DPiS is compatible on different versions of Android, such as
starting from the minimum sdk version of Android 3.0 (Honeycomb) to recent update Android
5.0 (Lollipop). The app functions well on the recent update of Android, but we support backward
compatibility in view of the other users of Android versions.

1.5.2 Limitations
1. Making source code available to everyone inevitably invites the attention of hackers
6

2. Android operating system uses more amount of battery as compared to normal mobile
phone.
3. As there are so many user sometimes it becomes difficult to connect all the users.
4. As we call Android is world of all applications we continuously need to be connected to
the internet which is not possible for all the users.
5. Android apps require updating and take up more storage space.

CHAPTER TWO
2.0 LITERATURE REVIEW
2.1 Doctor Patient Information System
7

Here we present a doctor-patient interaction system based on Android. Its excellent performance
on mobile terminals makes it possible that patients are able to access the hospital server to obtain
the necessary suggestion about the symptoms and interact with the doctors on their own mobile
terminals, while doctors can track patients whenever and wherever possible or make a diagnosis
of alert depends on the monitoring data from the hardware of mobile terminals.
Paper describes the needful things that the Doctor has to do every day. In this paper, we solve
this problem by proposing a new system based on android technology, through that the doctor
can manage his/her appointments from anywhere. In addition to this the patient who is unable to
go to the clinic and take the appointment can also book his/her appointment from a mobile phone
within 2-3 min. Our solution is to build a system that will help the needful people or every
person who wants to save their precious time. Any needed information can be supplied at the
time of installation. This removes the need for a technician to install software and enormously
quickens the implementation of a patient monitoring system.

2.2 Android Architecture


Android is a Linux based operating system developed for smart phones or tablet computers. It is
a stack of software that includes operating system, middleware and libraries and APIs written in
C [10]. It was developed by Google and Open Handset Alliance in July, 2005. Android is an open
source and Google releases the source code under Apache license. This open source and free
license allow the manufacturers and the enthusiastic developers to freely develop and modify
their applications in Java like language that utilizes Google developed Java libraries [2].
This project Doctor Patient Information System (DPiS) is developed for the Android Operating
system. Android is a Linux based operating system, primarily designed for touch screen mobile
devices such as smart phones and tablets. Android is compatible with multiple hardware and
supports various features like Web browser, Email, Java, Video calling, Media streaming,
Bluetooth, Wi-Fi, Multitasking, External storage, Screen capturing, and etc. The reasons for
choosing Android operating system for developing the DPiS app are as follows:
i.

It is an open source technology with lot of online learning available for zero cost.
8

ii.

Large number of users use Android based smart phones, so that our app can serve more
people in the mobile industry.

iii.

According to the market survey, it has the highest number of applications available for
download on Google play store.

iv.

It is also popular among the other operating systems which focuses on low cost,
customizable, and a readymade operating system.

Figure 3 Below show the Android Architecture

2.3 Android Database


SQLite
Android OS contains the SQLite database management system classes which are used by an
application to maintain its own private database. SQLite is a relational database management
system contained in C programming library. It is mostly preferred as embedded database for
9

local or client storage in application software. It has many bindings to the programming
languages.
The client side us the android application interface that is accessed by the user. MYSQL server
acts as the back end.

CHAPTER THREE
3.0 METHODOLOGY
Introduction
The methodology that is going to be adopted to develop the system is the V-Model.
10

This methodology is widely used today especially in the defense industry. The software
development life cycle will allow the process to have testing and coding as a parallel activity
which enables the changes to be made more dynamically. The V-Model is originally developed
from the waterfall process model. It is a classic software development model.
This model has four main phases which are requirements, specification, design and
implementation. This model also encapsulates the steps in verification and validation phases for
each step in the SDLC. Implementation of modules is tested by unit testing, system design is
tested by integration testing, system specification is tested by system testing and finally
acceptance testing verifies the requirements met.
One of the interesting characteristics of the V model is the ability to move backward which is it
can revert to the analysis stage even though it is half way through the implementation stage.
This will provide provider with the cushion if any error occurred V-model also allows the testing
and coding process to be done parallel making it more dynamic than the waterfall model. The
figure below shows the architecture of the V-model

Development Methodology
Diagram of the V-Model

11

The various phrases of the V-model are as follows


Requirements like BRS and SRS begin the life cycle model just like the waterfall model. But, in
this model before the development started, a system test plan is created. The test plan focuses on
meeting the functionality specified in the requirement gathering.
The High Level Design (HLD) phase focuses on a system architecture and design. It provides
overview of solution, platform, system, product and services/processes. An integration plan is
created in this phase as well in order to test the pieces of the software systems ability to work
together.
The low level design (LLD) phase is where the actual software components are designed. It
defines the actual logic for each and every component of the system. Class diagram with all the
methods and relation between classes come under LLD. Component tests are created in this
phase as well.

12

The implementation phase is, again, where all coding takes place. Once coding is complete, the
path of execution continues up the right side of the V where the test plans developed earlier are
now put to use
Coding: this is at the bottom of the V- shape model. Module design is converted into code by
developers.
Advantages of V-model:
Simple and easy to use.
Testing activities like planning, test designing happens well before coding. This saves a lot of
time. Hence higher chances of success over the waterfall model.
Proactive defect tracking-that is defects are found at early stage.
Avoids the downward flow of the defects.
Works well for small projects where requirements are easily understood.
Disadvantages of v-model:
Very rigid and least flexible
Software is developed during the implementation phase, so no early prototype of the software are
produced.
When to use the v-model:
The v-shaped model should be used for small to medium sized projects where requirements are
clearly defined and fixed.
The v-shaped model should be chosen when ample technical resources are available with needed
technical expertise.
3.2 Data collection
In this section the researcher studied the existing system to establish this weak and strong points.
The information acquired from this study gave the basis for the design of the new system. A
number of steps, procedures and tools were employed as shown below:
3.2.0 Primary data collection techniques.
It comprises of firsthand information collected by the researcher in this case observations and
interviews were used to collect primary data.

13

3.2.1 Interviews
During the study the researcher conducted face to face with few customers, employees and
management in order to get more insight on the system and its implementation interviews are
often more exploratory in nature, an allows for more flexibility since the interviewees have high
response rate than written questionnaire and it is also suitable for use with both literate and
illiterate. Examples of questions asked during the interview are:
How is information stored after getting it from the customers?
How is this information accessed in case it is required?
How many customers visit the gym per day?
What happens after the customers walks in?
3.2.1.0 Types of interviews
Structured interviews- based on standard question written by hand that enabled the interviewer
gain answers based on specific findings
Unstructured interviews- using rapport building, this involved conversation that made it easy to
obtain the feelings of the people, and firsthand information. Some questions were not
predetermined and were asked impulsively.
3.2.1.1 Advantages of using an interview

If the respondent lacks reading skills to answer a questionnaire.


Are useful for untangling complex topics.
The interviewer can probe deeper into response given by an interviewee
Interviews produce a higher response rate.

3.2.1.2 Disadvantages of using an interview

The interviewer can affect the data if he/she is not consistent.


It is very time consuming.
It is not used for large number of people.
The interviewer may be biased and ask close questions.

14

3.2.2 Observation
This technique was used to gather accurate information about how the current system operates
and its processes from the organization. This involves systematically watching and recording the
behaviour and characteristics of operations and processes. Although the method is time
consuming, it gives more detailed and context related information and one can adapt to events as
they occur.
3.2.3 Secondary data collection techniques
This kind of data was obtained from books, journals and various materials from the internet. It
is helpful in providing a baseline with which the collected primary data results can be compared
to.
Secondary data has a pre-established degree of validity and reliability enabling the researchers to
make a comprehensive analysis of the study.

15

CHAPTER 4
DESIGN SPECIFICATION
4.1 USE CASE DIAGRAMS
The architecture of the application is explained using Unified Modeling Language Diagrams.
Unified Modeling Language (UML) provides IT professionals with a common design format to
build and develop computer applications using the design view of the application. Use Case
Diagram in Figure 3.1 demonstrates the functionality of each individual unit in the system. These
diagrams help in better visualization of the functional requirements which includes the
relationship between actors and the use cases.
Figure below describes how communication takes place between doctors and patients. The user
sets up the application in their Android phone, both the doctors and patients are differentiated
based on their logins. All the interactions between a doctor and a patient such as messaging,
sending health tips, sending prescriptions, patient referrals and appointments are initially sent to
the parse web server, these interactions are RESTFUL API service requests made by the user to
store data on the Parse web server. Similarly, the data is fetched from the Parse web server and
then through the web server to the user. The web server acts as an intermediate for the interaction
between the doctors and patients for data exchange. The users should always be connected to the
internet in order to interact with the web server through the web services. Hence this way the
communication takes place in the DPCS app.

Figure 4.1: DPCS Architecture

16

4.2 Use Case Diagram


In Figure below, all the ovals represent the functionalities of the doctors and patients, there are
some common use cases between doctor and patient such as registration, login, and pharmacy
selection are initially made by patient, and otherwise the doctor will be choosing the pharmacy
near to the patient location. Patient will be requesting for doctor appointment which has to be
confirmed by the doctor, similarly for the messages sent by patients, doctor has to reply and vice
versa. Apart from these common features between doctors and patients, doctors also have some
specific functionalities like, adding or blocking patient & send health tips, send prescriptions to
pharmacies and patient referrals.

Figure 4.2: DPCS Use Case Diagram

4.3 Class Diagram


The Class diagram for the application consists of the interfaces, methods, variables and
relationship between them. Figure below is the class diagram for doctor module which describes
the major functionalities of the doctors like registering with the application, login authentication,
checking inbox messages, sending messages to patients, prescribing medicines, adding and
blocking patients. Both registration and authentication are the common classes for doctors and
patients but the screens and functionalities vary based on the attribute role.

17

Figure 4.3: Class Diagram for Doctor Module

Apart from these functionalities, doctors have some more capabilities while dealing with
patients. Every new request from patient comes to doctors dashboard for approval from the
doctor. Once the doctor accepts the request, the doctor can interact with patient and send
prescriptions to patient as well as to pharmacies.
As shown in Figure 4.4 patient interaction and pharmacy classes are dependent on dashboard
class because without approving the patients request doctors will not be exposed to interact with
patients. In this project the pharmacy interaction is a mock service and we do not deal with the
real-time pharmacy services for sending prescriptions. This project is a proof of concept between
doctors and patients, but this service is achievable, if we extend the scope of this project to realtime users in the Android market.

18

Figure 4.4: Class Diagram for Doctor Dashboard

Figure 5.5 is the patient class in which the registration and authentication is quite similar, but the
functionalities and screens are rendered based on the role of the user. After login patients have
little functionality such as checking inbox for the messages from doctors, sending messages to
doctors, view prescriptions from the doctors and, request for an appointment with the doctor to
meet in the hospital.

19

Figure 4.5: Class Diagram for Patient Module

Figure 4.5: Class Diagram for Patient Module

20

4.4. Sequence Diagram


A sequence diagram describes how the communication happens between the user, application,
and cloud data. Figure 4.6 describes the user sequence with the application and how the
application handles the user request. The application processes the user request and makes a
request to the Parse server to get the data from the cloud database.

Figure 4.6: Sequence Diagram for User interaction with application

4.5. User Interaction


The main activities in the application are the user registration page, login page, landing page for
doctors and patients after login, landing page for patient after registration. The other remaining
modules are implemented using fragments which are described in the section 4 of this document.
In order to register with the application details such as first name, last name, social security
number, role, preferred username, password, email, mobile number, and address are required as
shown in Figure 4.7.

21

Figure 4.7. User Registration Screen


22

The Figure 4.8 shows the landing page of the application which is the login page with a link
Click here to register with the application.

Figure 4.8: Login page of the application

23

CHAPTER 5
Implementation of the Application Modules
5.1 Registration & Login
This module provides the functionality to register with the application before they login and use
the services available. There will be a link provided in the landing screen for registering with the
application. After clicking on the register link, the user navigates to signup activity. In this
activity the user has to give details such as first name, last name, social security number, email
id, contact number, user role, user name, password, and address as shown in Figure 4.7. All these
fields are properly validated. After validations, these details are stored on the Parse web server in
_User class and the user is navigated back to the landing screen or login activity of the
application. Table 5.1 shows the code snippet for Signup & registering device on Parse server for
sending push notifications.
Table 5.1: Code Snippet for User Signup & Registering Device in Parse
user.signUpInBackground(new SignUpCallback() {
@Override
public void done(ParseException e) {
if (e == null) {
}
}
});
//Registering device for push notifications
ParseInstallation registerDevice = ParseInstallation.getCurrentInstallation();
registerDevice.put("UserName",username.getText().toString());
registerDevice.put("FirstName",fname.getText().toString());
registerDevice.put("Email",email.getText().toString());
registerDevice.saveInBackground();

After successful registration, the user can login into the application with his/her credentials, the
application validates both the username and password given by the user and also checks the role
of the user and navigates appropriately to the corresponding screen. If the user is a doctor then he
will be navigated to Doctor_AfterLogin.activity, otherwise he will be navigated to
home_patient.activity. Both the users will have different functionalities and features based on
their role in the application. Table 5.2 shows the code snippet for user authentication.
Table 5.2: Code Snippet for User Login Authentication
ParseUser.logInInBackground(edtUserName.getText().toString().trim(),edtPassword.g
etText().toString().trim(),new LogInCallback() {
@Override
public void done(ParseUser user, ParseException e) {
if(user != null){
24

if(user.get("role").toString().equals("Doctor")){
Intent loginIntent = new Intent(getApplicationContext(),Doctor_AfterLogin.class);
loginIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(loginIntent);
}else if(user.get("role").toString().equals("Patient")){
Intent loginIntent = new Intent(getApplicationContext(),home_Patient.class);
loginIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(loginIntent);
}
}
}
});

5.2. User Inbox


User inbox is a fragment in which all the recent messages are shown with the date & time of that
particular message. This functionality is similar for both the doctors and patients, here patient
will be receiving messages from different doctors and similarly doctor gets messages from
different patients. Apart from this message communication between doctors and patients, some
notifications in the application like appointment requests and confirmations are also pushed to
the inbox. All the conversations between doctors and patients are stored on the Parse server in
User Messages class with the sender & receiver first names. Accordingly after login
authentication these messages are loaded from the User_Messages class. All the conversation
between doctors and patients are grouped and the most recent message is shown, when the user
clicks on particular item then the complete conversation between two users is shown in the
message_details fragment. User also has a provision to send a reply from the same grouped
conversation page. Table 5.3 shows the code snippet for loading inbox.
Table 5.3: Code Snippet for loading User Inbox ParseQuery<ParseObject> loadInbox =
ParseQuery.getQuery("User_Messages");
loadInbox.whereEqualTo("MessageTo", ParseUser.getCurrentUser().get("fname"));
loadInbox.orderByDescending("createdAt");

4.3. Doctor Dashboard


Dashboard is the page in which all the requests from the patients are shown, these are
registration requests from a specific patient, these requests need to be approved by the
corresponding doctor. If the request is approved then a push notification is sent to the patient and
further the application allows the patient to interact with that doctor. A doctor can also reject
25

these requests. These requests from the patients are stored in Patient_Requests class on Parse
server. Table 4.4 shows the code snippet for loading the doctor dashboard with patient requests.
Table 4.4: Code Snippet for loading the doctor dashboard with patient request final
ParseObject Pat_Req = new ParseObject("Patient_Requests");
Pat_Req.put("PatientName", ParseUser.getCurrentUser().get("fname").toString());
Pat_Req.put("PatientPrefName",edtPatPrefName.getText().toString());
Pat_Req.put("PatientPrefEmail",edtPatPrefEmail.getText().toString());
Pat_Req.put("PatientSSNID", edtPatId.getText().toString());
Pat_Req.put("PatientPrefMobile",edtPatPrefMbl.getText().toString());
Pat_Req.put("DiseaseDescription",edtPatProb.getText().toString());
Pat_Req.put("DoctorName", docList.getSelectedItem().toString());
Pat_Req.put("Status","Pending");

5.4. Add/Block Patient


Doctors can add patients from the application by entering the patient details in the application, at
which point an email is sent to patient with the invitation from the doctor and a link to download
the application. Once the patient install the application the patient has to sign up with the
application. After sign up this patient will be having direct access to the doctor who has added
him/her. In this case when a patient is added directly by a doctor they will get default access to
the doctor and can start interacting with the doctor without sending any request. When a doctor
adds a patient all the details are stored in Patient_Requests class on the Parse server, by default
with the status as Approved. Table 5.5 shows the code snippet for adding patients.
Table 4.5: Code Snippet for Adding Patient ParseObject addPatientRequestClass =
new ParseObject("Patient_Requests");
String currentUser = ParseUser.getCurrentUser().get("fname").toString();
addPatientRequestClass.put("DoctorName",
ParseUser.getCurrentUser().get("fname").toString());
addPatientRequestClass.put("PatientName",edtPatientFName.getText().toStrin
g());
addPatientRequestClass.put("PatientPrefName",edtPatientFName.getText().toS
tring());
addPatientRequestClass.put("PatientPrefMobile",edtPatientMbl.getText().toStri
ng());
addPatientRequestClass.put("PatientPrefEmail",edtPatientEmail.getText().toStr
ing());
addPatientRequestClass.put("PatientSSNID",edtPatientSSN.getText().toString()
);
addPatientRequestClass.put("DiseaseDescription",edtPatientDiseaseDescriptio
n.getText().toString());
addPatientRequestClass.put("Status","Approved");
addPatientRequestClass.saveInBackground();
26

CHAPTER SIX
6.0 Testing and Evaluation
In this phase the functionality is tested on Nexus 7 tablet which is an Android device with
Android Version 4.4.4. To install apk we need to enable an option in the device settings to allow
installations from other locations. The apk supports minimum Android version 3.0 to Android
version 5.0. To use the application device should be connected to WIFI with good connection.
This chapter deals with testing each module of the application with positive and negative test
cases, first lets start from registering with application.

6.1. Registration
a. Negative Test Case: Clicking on Register button without entering values in any of the fields
and trying to register with the application will generate a dialog by showing registration or
validation failure as in Figure 5.1 (a).
b. Positive Test Case: Figure 5.1 (b) shows the successful registration, by which we ensure the
user is registered successfully with the DPCS app. Before registering the user, we make sure all
the fields are validated.

27

6.2. Login
a. Negative Test Case: From Figure 5.2 (a) it can be seen that, if we enter wrong credentials and
try to login, then an error message displaying Invalid Login Parameters is shown.
b. Positive Test Case: By entering valid credentials and clicking on the Login button user is
authenticated and navigated to the Inbox screen.

28

CHAPTER 7
7.0 Conclusion & Future Work
The major goal of this application is to create online interaction between doctors and patients, to
fulfill the basic needs/problems of the patients. Patients can update their problem to doctors by
messaging and get advice from the doctor. Through the messaging services patients can seek
24/7 help from doctors. DPCS serves as the platform for easy and quick treatment, with extended
support from doctors to patients. DPCS has unique features such as issuing online prescription to
patients, referring patients to a specialist, sending health tips to patients, and finally, reducing the
cost of customer service and providing a vital communication link between doctors and patients.
Future Works
This app can be improved in the future by adding the following functionalities:
Create two separate apps for doctor & patient.
Sharing the medical test reports of patients to doctors through this app.
Supporting video calls to discuss the problems with doctors.

Appendix I: Android API

29

APPENDIX II: GANT CHART


This will be used to indicate the time by which the project is expected to be completed. It has
been summarized according to the number of days.
Duration in days

20

36

Idea Generation
Proposal Writing
Presentation
Research
30

33

12

Implementation
Prepare
Documentation
Final Presentation

Bibliography & References


GOOGLE. (n.d.). Android Developers. Retrieved from
http://developer.android.com/training/basics/firstapp/index.html
DANYL BOSOMWORTH. (2015, Jan 15). Mobile Marketing Statistics 2015. Retrieved
from http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile
marketing-statistics/
Google Play. (2015, May 5). Retrieved from https://play.google.com/
Google. Inc. (2015 May 5). Android Studio Guide. Retrieved from
http://developer.android.com/training/implementing-navigation/nav-drawer.html
GEORGE MATHEW. (2013, Jan 15). GPS and Google Map in Android Applications
Series. Retrieved from http://wptrafficanalyzer.in/blog/gps-and-google-map-in-android
31

applications-series/
Parse Android API Guide. (n.d.). Retrieved from http://www.parse.com/docs/android/api/
Parse Android Docs. (n.d.). Retrieved from https://www.parse.com/docs/android_guide
Registering Parse Push Notifications. (n.d.). Retrieved from
https://parse.com/tutorials/android-push-notifications
Internet Fax Service. (n.d.).Retrieved from http://www.metrofax.com/
GENMYMODEL. (n.d.). To design UML, Class and Sequence Diagrams. Retrieved from
https://api.genmymodel.com/

32

You might also like