B.E. Computer Final Year Project

Wireless Interactive System for
Patient Healthcare Monitoring using

Android Mobile

A project report submitted in partial fulfillment of

the requirements for the degree of

Bachelor of Engineering

by

ABHIJIT KAWARE BE H 54

ROHIT KHADKE BE H 55

PIYUSH SHANKAR BE I 51

CHARUDATTA KANDARE BE H 49

Under the guidance of

Prof. Mrs. MUGDHA SHAH

DEPARTMENT OF COMPUTER ENGINEERING

VISHWAKARMA INSTITUTE OF TECHNOLOGY PUNE

2011 - 2012

Bansilal Ramnath Agarwal Charitable Trusts

VISHWAKARMA INSTITUTE OF TECHNOLOGY, PUNE - 37

( An Autonomous Institute Affiliated to University of Pune )

CERTIFICATE
This is to certify that the project report entitled Wireless Interactive System
for Patient Healthcare Monitoring using Android Mobile has been submitted in the
academic year 2011-12 by

ABHIJIT KAWARE BE H 54

ROHIT KHADKE BE H 55

PIYUSH SHANKAR BE I 51

CHARUDATTA KANDARE BE H 49

under the supervision of Prof. Mrs. MUGDHA SHAH in partial fulfillment of the
requirements for

the degree of Bachelor of Engineering in COMPUTER Engineering as prescribed by
University of Pune.

Guide/Supervisor Head of the Department

Name: Name: Prof.S.B.Karthick

Signature: Signature

External Examiner

Name:

Signature
Vishwakarma Institute of Technology, Pune-37.
Department of Computer Engineering

Acknowledgments

We wish to express our sincere gratitude to Prof. Dr. R.M.Jalnekar, Director,
VIT, Pune and Prof. S.B.Karthick, HOD of Computer Department of Vishwakarma
Institute of Technology for providing us an opportunity to do our project work on
Wireless Interactive System for Patient Healthcare Monitoring using Android
Mobile as a part of B.E. project.

Our project bears an imprint of many people. We sincerely thanks to our project
guide Prof. Mrs. Mugdha Shah, Computer Department of Vishwakarma Institute of
Technology for guidance and encouragement in carrying out this project work.
We also wish to express our gratitude to Prof. V.D.Pawar, Computer Department
of Vishwakarma Institute of Technology. Without his constant efforts and monitoring
designing and structure of project would not up to mark.
We also wish to express our gratitude to the officials and other staff members of
Computer Department of Vishwakarma Institute of Technology who rendered their help
during the period of our project work.

Date:

ABHIJEET KAWARE

ROHIT KHADKE

PIYUSH SHANKAR

CHARUDATTA KANDARE

INDEX

1. PROJECT SYNOPSIS 1
1.1 Context
1.2 Problem
1.3 Solution
1.4 Benefits
2. FEASIBILITY STUDY REPORT 4
2.1 Introduction
2.2 Purpose
2.3 Methodology
2.4 References
2.5 General Information
2.6 Current System and Processes
2.7 System Objectives
2.8 Objectives of Research
2.9 Issues
2.10 Assumptions and Constraints
2.11 Alternatives
2.12 Recommendations and Conclusion
3. SOFTWARE PROJECT PLAN 6
3.1 Overview
3.2 Goals and Scope
3.2.1 Project Goals
3.2.2 Project Scope
3.2.2.1 Included
3.2.2.2 Excluded
3.3 Schedule and Milestones


4. SOFTWARE REQUIREMENT SPECIFICATION 10
4.1 Introduction
4.2 Purpose
4.3 Scope
4.4 Definitions, Acronyms and Abbreviations
4.5 References
4.6 Overview
4.7 Overall Description
4.7.1 Problem Statement
4.8 Product Perspective
4.9 Product Position Statement
4.10 Product Functions
4.11 Assumptions and Dependencies
4.12 Specific Requirements
4.12.1 External Interfaces
4.12.2 Functions
4.12.3 Performance Requirements
4.12.4 Logical Database Requirements
4.12.5 Software System Attributes
4.12.5.1 Reliability
4.12.5.2 Availability
4.12.5.3 Security
4.12.5.4 Portability
5. USE CASE ANALYSIS DOCUMENT 23
5.1 Use Case Specifier List
5.3 Use Case Diagrams
5.4 Use Case Templates
6. BEHAVIOR : SEQUENCE DIAGRAMS 33
6.1 Sequence Diagram Overview For Entire System


7. BEHAVIOR : STATE CHART DIAGRAMS 42
7.1 State Chart Diagram Overview
7.2 Object State Description
7.3 State Description
7.4 Specific Description
8. ACTIVITY DIAGRAMS 51
8.1 Activity Diagram Description
9. SYSTEM DESIGN DOCUMENT 56
9.1 Class Diagram
9.2 CRC Template
10. SYSTEM IMPLEMENTATION DOCUMEN 60
10.1 Component Diagram Description
10.2 Deployment Diagram Description
11. SYSTEM TESTING DOCUMENT 65
11.2 Test Plan
11.3 Test Case Specification
12. SNAPSHOTS 73
13. CONCLUSION 81
14. REFERENCES 83



Wireless Interactive System
for Patient Healthcare
Monitoring using Android
Mobile

Software Project Synopsis


1. CONTEXT

Recently there has been a need to incorporate the use of mobile computing
devices in hospital or clinical applications, to enhance patient care. The advancement of
wireless technology has created unique mechanisms of interaction that can meet the
needs of e-health system robustness, reliability and accuracy requirements.

2. PROBLEM

A study of medical records found that many healthcare organisations still record
and distributed instrument output data and patient records in paper form, which can lead
to errors in interpreting records and ultimately to misdiagnosis. When a doctor is on leave
or out of station then he/she wont be able to provide treatment to their patient.

3. SOLUTION

We examine mobile and wireless information technology concepts that can be
used to interact with a medical information system for viewing patient information
records.

4. BENEFITS

The use of android mobiles and other wireless networking technologies in e-
health environments for patient record, resource or time management has the potential to
improve overall patient care by reducing the occurrence of mistreatment incidents caused
by faulty information. This will also help doctors to treat their patient from anywhere.



Mobile

Feasibility Study Report


1. INTRODUCTION

The purpose of this document is to determine the feasibility of enhancing a
Wireless Interactive system .This study also aims at analyzing the various issues that are
expected to arise during development of this application as software system concerning
its hardware implementation, interaction and integration with other systems and
potentially competing alternatives to the proposed system.
The aim is to obtain general information about current system and processes,
system objectives, assumptions & constraints. This document also supplies the
comparison of alternatives

1.1 PURPOSE

The feasibility study determines whether proposed system can be mapped to real
life software products. The study involves mobile and wireless information technology
concepts that can be used to interact with a medical information system for viewing
patient record.

1.2 METHODOLOGY

The feasibility study involved detailed study of Wireless Interactive System for
Patient Healthcare Monitoring using Mobile Computing Devices. Every system was
thoroughly studied in order to compare and comprehend the extra features. Issues related
with each system was also studied as part of the feasibility and then Mobile Computing
Devices was selected for viewing the records.


1.3 REFERENCES

1) http://www.google.co.in
2) http://developer.android.com/index.html -:Official Android Guide By GOOGL
3) http://en.wikipedia.org/wiki/Programming_language
4) Professional Android Application Development-: Reto maier WROX publications

2. GENERAL INFORMATION

This section describes about the existing patient monitoring system and the
problems associated with them. We also describe in detail our proposed system and its
objectives along with the general assumptions and constraints the system is subjected to.

2.1 CURRENT SYSTEMS AND PROCESSES

Currently such a system doesnt exist. Today still patient record work has been
done on papers only.

2.2 SYSTEM OBJECTIVES

The proposed project involves developing a system which will update patient
records through laptops. Also the system shall enable the doctor to view patient records
on handset having Android OS (version 2.2 or above) from remote places.

2.3 ISSUES

The user may not view the record if he is not having gprs service. The users
mobile Android OS should be (2.3.3 or more than that). Also, during viewing the patient

record data loss can occur if the server hangs or error in network connection. The slow
network may pose problem of delays in system operation if online framework system is
used.

2.4 ASSUMPTIONS AND CONSTRAINTS

Assumptions:
1. Resources such as consistent wireless connectivity for efficient online framework.
2. There is no other Android app available for Patient Healthcare Monitoring.

3. ALTERNATIVES

This section describes the viable alternatives for the system. This section defines
the alternative and describes how it would satisfy the system requirements.
We can use internet connection instead of wireless system for remote diagnosis.
Also we can develop a web page using HTML and browse it using internet. For this we
need to maintain a server. (We can use the database server).

4. RECOMMENDATIONS AND CONCLUSION

The recommended approach is to develop a system which will enable the user to
update and monitor the patient data is best for the project needs of the organization and
its requirements. The user will require basic knowledge of the system and how to operate
it. Also, the system is user friendly can be modified and customized as per needed.
Overall, the system will reduce manual and repetitive tasks and automate a lot of tasks.
The other alternatives are not efficient in terms of time and available features as
compared to this system.



Mobile

Software Project Plan


1. OVERVIEW

Earlier, many healthcare organisations still record and distributed instrument
output data and patient records in paper form, which can lead to errors in interpreting
records and ultimately to misdiagnosis. So, the product is mainly for doctors for viewing
patient details and ECG reports on MCDs. The project will deliver wireless monitoring
system for patients (e-health).As the product involves new technology; it will last till new
version with better interface comes. Medical Organisations are involved for providing
ECG.

2. GOALS AND SCOPE

2.1 PROJECT GOALS

Project Goal Priority Comment/Description/Reference
Functional Goals:
Perform database operation. High
User can upload database, insert or update
entities and use it for analysis.
Authenticate doctor. High The Doctor will be assigning unique ID and
password to access the patient database.
Show all patient record. High The patient record is shown in tabular format.
Show ECG of desired patient. High ECG of desired patient is shown.
Business Goals:
Cost-effective High Since the resources required are cheap, the
organization doesnt have to spend capital on
it.
To reduce development cost High Using open source and freeware development
tools development cost can be reduced.
Technological Goals:
Implementation simplicity Customization of product according to
hospitals need.
Reliability High The product should be reliable to ensure
correct Info. Of patient.
Quality Goals:
Performance High
The optimization of operational speed.
Usability High
The ease of using the system

Project Goal Priority Comment/Description/Reference
Constraints:
Resource Constraints High Internet connectivity and mobile phone with
Android OS are required.

The project will deliver a system which will consist of an android application and
an online service which will work together. It will help the doctor to check the patient
record when he is out of station. The customer may expect system to support different
platforms such as symbian, java, iOS etc but the system will provide support only for
Android OS. A team of four people are involved in delivering the project.

2.2 PROJECT SCOPE

2.2.1 Included

The project will deliver a system which will consist of an android application on
client side and an online service which will manage the server related operations.

2.2.2 Excluded

The customer may expect system to support different platforms such as
symbian, java, iOS etc but system will provide support only for Android OS.


3. SCHEDULE AND MILESTONES

Milestones Description Milestone Criteria Planned
Date
M
0
Start Project Budget Release 2011-09-15
Understand the
requirements and define
project goals and scope
Research on the domain
to clearly identify the
current development
tools and needs for the
improvement in
alternative techniques.
2011-09-18
M
1
Start Planning 2011-09-25
Phases of project are
decided.
Planning 2011-09-28
Feasibility study done with
objective planning.
Scope and concept
clarified.
2011-09-30
M
2
Start Execution 2011-11-08
Data collection and study Collect and study
research material for
existing systems and for
implementing proposed
system.
2011-11-15
M
3
Confirm Execution
2012-1-15
Design the System Develop a model of the
system
2012-1-25
M
4
Start Introduction
2012-02-08
Decide algorithms and
implementation of system
Start Coding
2012-02-17
M
5
Release Product
2012-04-22
Test Model. Run test cases and
release the product on
success.
2012-08-25
M
6
Close Project 2012-10-08



Mobile

Software Requirements Specification


1. INTRODUCTION

The SRS the current contact will give you a brief idea about Interactive Wireless
Information system. The SRS states the specific requirements for the Interactive Wireless
Information System for Android. The SRS also gives an overview of the databases
required in the system, system attributes and the assumptions made.

The SRS describes an Interactive Wireless Medical Information System for
Android and also describes how to access patient record through the mobile. The system
will be designed using flexible architecture.

1.1 PURPOSE

This SRS assures that the project management, clients and development team has
understood the business requirement documentation in proper manner. This also provides
the confidence that the team will develop functionality which has been detailed. The SRS
contains information which is organized in such a way that the developers will not only
understand the boundaries within which they need to work, but also what functional
needs are to be developed and in what order.

1.2 SCOPE

The software product will be named as Wireless Interactive System for Patient
Healthcare Monitoring System Using Android Mobile (WISPHMUA).
The project will deliver a system which will consist of an android application on
client side and an online service which will manage the server related operations. The
client application shall be made available to users via Android Market.


The system will provide the following two main features:
Update Record: This feature will allow user to update the patient
database and record ECG images on server.
Check Patient Record: This feature will allow the doctor to check patient
details on his android phone.

The customer may expect the system to support different platforms such as
symbian, java, ios etc but system will provide support only for Android OS.

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

Term or Acronym Definition
WISPHMUA
Wireless Interactive System for Patient Healthcare
Monitoring System Using Android Mobile.
Software Requirements
Specification
A document that completely describes all of the
functions of a proposed system and the constraints
under which it must operate. For example, this
document
Database
Collection of all the information monitored by this
system.
MySql
It is a relational database management
system (RDBMS) that runs as a server providing multi-
user access to a number of databases.
GUI Graphical User Interface.
J2EE
It is platform consist of a set of services, APIs and
protocols that provide the functionality for developing
multitier, Web-based application.

1.4 REFERENCES


1.5 OVERVIEW

The SRS contains the system interfaces, user interfaces, system functions,
dependencies, database information, system attributes of the WISPHMUA. The system
interfaces of the WISPHMUA will help the managing team to keep track of the system
after delivery, in case of any failure. It describes the informal requirements and is used to
establish a context for the technical requirements specifications.
The Requirement Specification document is written primarily for the owners of
the system and describes in technical terms the details of the functionality of the product.
Both sections of the document describe the software product entirely.

2. OVERALL DESCRIPTION

PROBLEM STATEMENT

The problem of
1. Patient record updation.
2. Inaccessible data.
Affects
1. User switching from one handset to
another(of same or different company)

The impact of which is
1.Handset loss and Connectivity problem

A successful solution
would
1. Cross Platform Support.
2. Increased Security.

2.1 PRODUCT PERSPECTIVE

PRODUCT POSITION STATEMENT

For The Mobile Users.
Who Android users.
That Is used to view the patient records and ECG.
Unlike Viewing the database in paper form.
Our product Is simple in handling and will increase user satisfaction.

2.1.1 System Interfaces

System Environment : Windows operating system
Platform : Android 2.2 and above
Front End : JSP
Back End : MySQL

2.1.2 User Interfaces

All functionalities provided in our system will be bounded to each other with the
help of software interfaces. The system as a whole will be realized by user with the help

of user interface. Thus it is nothing but connecting link between our well bounded system
and its user.

Login: The authenticate doctor should prove his identification at the start for using
the system and the new users should register to access the system.
Menu: The system gives three options to the user after successful login:
View Patient record.
View ECG Report.

2.1.3 Hardware Interfaces

Intel Pentium 4 1.6 GHz CPU
Minimum 4 GB of disk space.
Android Device with Wi-Fi.

2.1.4 Software Interfaces

Windows XP or higher.
MySQL 4.1.x and higher.
2.1.5 Communications Interfaces

The main communication system is Mobile which communicates with database
server.

2.1.6 Memory Constraints

RAM: 1 GB
Hard Drive: 4 GB

2.2 PRODUCT FUNCTIONS

1. Allowing existing doctor to sign in.
2. Checking availability of user-id for new doctor.

3. Accepting username and password for existent users.
4. Validating username, password before access to the system.
5. Storing information of the new doctor in the database.
6. Restoring the password if user forgets using security question..
7. Detecting new record addition or modification to patient record list.
8. Storing newly added or modified record information on server database.
9. Allowing doctor to check the record information on current platform.
10. Displaying list of patient record.
11. Displaying desired patient ECG report.

2.3 ASSUMPTIONS AND DEPENDENCIES

Following are the assumptions and dependencies made in order to design the project:
Resources such as consistent internet connectivity, mobile handset with
Android OS version 2.2 and above are available.
Operational cost will involve internet charges.

3. SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACES

ECG machine

3.2 FUNCTIONS

Goal 1: Update database.

Objective 1: Create record
Process 1 : The user will create a record of the patient.
Process 2 : The system shall upload record on the server.


Objective 2: Insert or update entities.
Process 1 : The user will select which patient record to be updated.
Process 2 : The system uploads newly added and modified contacts on the server .

Goal 2: Authentication of Doctor.

Objective 1: The system shall allow to add new user.
Process 1 : The system shall accept user required information.
Process 2 : The system shall store user information in database.

Objective 2: Grant access to existing user.
Process 1 : The system shall check for user with valid username, password..
Process 2 : The system shall allow valid user to access system.

Goal 3: Show all patient record and view ECG

Objective 1 : Show all patient record.
Process 1 : The patient record to be shown.
Process 2 : The system will show patient record on doctor side..

Objective 2: View ECG.
Process 1 : The recorded ECG of desired patient is shown.
Process 2 : The system will show patient record on doctor side.

3.3 PERFORMANCE REQUIREMENTS

Only Authenticate users can access the system as per their need. This will be
achieved by creating various instances for multiple users where the system will block the
access by the other users to the data which is being used by other instance.


3.4 LOGICAL DATABASE REQUIREMENTS

The WISMPHAM system will consist of the following databases:
Doctor database: This database will consist of account information of each doctor
such as username, password.
Patient database: This database will consist of patient details including ECG images.
It include attributes such as name, age, blood group, sex, description
Of diseases.
The WISMPHAM system will maintain above databases on server

3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.1 Reliability

The reliability of the system shall be assured by the simple implementation of the
system. Even in the worst case, where many users access the system at the same time
altering the system database, the system will handle the overload.

3.5.2 Availability

This system is designed to run 24/7 and be readily available to the user. It will
also be available to any number of simultaneous administrators.

3.5.3 Security

Login :
An authenticated user can login to the system and thus access the system. To get
a login id and password, the user should contact the system administrator, who has the
rights to assign new users to the system and also remove the users from the system. If the
system crashes, then backup facility is provided by data warehouse.
3.5.4 Portability

Android Mobile is the only portable device.


Mobile

Use Case Analysis Document


1. USE CASE SPECIFIER LIST

1.1 USE CASE ID

1. Perform operations on Database.
2. Authenticate doctor.
3. Show all patient records.
4. Show ECG of desire patient.

2. GENERAL INFORMATION

System Context Diagram:


3.1 USECASE # 1


USE CASE # 1

To Update Database of patient
Goal Import .db files
Purpose The purpose of this use case is to import test cases in .db format
Preconditions
1. The database should have proper database schema to manage the
test cases.
2. There should be a .db file.
Success Condition Test cases in .db files are readable.
Failed Condition .db file is not readable.
Post Conditions .db file can be read.
Primary Actors

Admin
Secondary Actors Cant have secondary users for database security reasons.
Trigger The action will be initiated when a tester has to import a .db file.
DESCRIPTION Step
1 Admin will login at server PC using login details.
2 He /She can invoke database using SQL queries.
3 He /She can also modify database directly.
DESCRIPTION Step Error Scenario
1 File is not properly imported as the original .db file.
2 Error in database connectivity.


3.2 USECASE # 2


USE CASE # 2

Perform Authentication.
Goal To check if Doctor is Valid or invalid user.
Purpose The purpose is to give doctor access of the system.
Precondition 1. The Doctor is valid user.
Success Condition Doctor successfully logged in .
Failed Condition Invalid User name and Password.
Post condition Doctor gets access to the system.
Primary Actors

Doctor.
Secondary Actors No secondary actors present.
Trigger
The action will be initiated when a Doctor enters Username and
Password.
DESCRIPTION Step
1 Doctor open respective Android app.
2 He /She performs authentication.
3 He /She gets access to the system.
1 User enters invalid username or password or both.
2 User enters incomplete information for login.


3.3 USECASE # 3


USE CASE # 3

Show all Patient record.
Goal Display details of all Patients from database.
Purpose The purpose is to fetch patient details from Patient Database.
Preconditions The doctor is authenticated to use the system.
Success Condition Patient details displayed Successfully.
Failed Condition There is no Database connectivity.
Post Conditions All Patient records showed on MCD.
Primary Actors

Doctor.
Trigger The action will be initiated when doctor logged in successfully.
DESCRIPTION Step
1 Doctor will be logged in on MCD.
2 MCD will fetch patient details from Patient Database.
3 User can see Patient details on MCD.
1 Not enough memory to load details on MCD.
2 There is no connectivity between MCD and Server database



3.4 USECASE # 4


USE CASE # 4

Show ECG image of desired patient.
Goal Show ECG image on MCD.
Purpose
The purpose of this use case is to fetch ECG image from database on
display on MCD.
Preconditions
1. Doctor should select patient whose ECG image he want.
2. There should be ECG image present into the Database of desired
patient.
Success Condition ECG image displayed on MCD.
Failed Condition ECG image cant display.
Post Conditions ECG image file format cant be supported be desired MCDs.
Primary Actors

Doctor.
Trigger The action will be initiated when a doctor select desired patient.
DESCRIPTION Step
1 Doctor will select desired Patient from list.
2 The system will show ECG image of selected patient.
1 Image of desired patient is not available into db.
2 Error in connection.



Mobile

Behavior: Sequence Diagram


1. SEQUENCE DIAGRAM OVERVIEW

1.1 SCENARIO DESCRIPTION #1


Informational Item Information
Use Case Use case1
Scenario Name Performing operations on database
Steps
Basic course of action
1. Authenticate the admin
2. For authentication verify admin login details.
3. Connect database with admin.
4. Now perform operations like modify,delete,update
database.
Alternate course of
action
1. Manually update database using mysql.

MESSAGE DESCRIPTION

Message Type From Object To Object
Enter admin id Simple message Admin System
Check for update Message to self System System
Search id of doctor Simple message System Doctor database
Update database Message to self Doctor Database Doctor Database
Successfully updated Reply message Doctor Database Admin
Search id of patient Simple message System Patient database
Update database Message to self Patient database Patient database
Successfully updated Reply message Patient database Admin




Use Case Use case2
Scenario Name Authenticating Doctor
Steps:
1. Accept doctor id and password
2. Check details in database
3. Give response from database.
Alternate course of
action
-

MESSAGE DESCRIPTION

Enter user name and password Simple
message
Doctor System
Authenticate the details Message to
self
System System
Fetch details Simple
message
System Doctor
Database
Details found Reply
message
Doctor Database System
Login successful Reply
message
System Doctor
Invalid data Reply
message
Doctor database System
Notify doctor Reply
message
System Doctor
Unsuccessful login Message to
self
Doctor Doctor




Use Case Use case3
Scenario Name Show all patient records
Steps
1. Invoke the database
2. Select all records from patient database
3. Send all records as response
4. Display all records
Alternate course of
action
Show record of specific patient

MESSAGE DESCRIPTION

Authenticate login Simple message Doctor System
Verify id Message to self System System
Request for patient
details
Message to self System System
Check details in db Simple message System Patient db
Fetch all records Message to self Patient db Patient db
Forward records Reply message Patient db System
Show all records. Reply message System Doctor




Use Case Use case4
Scenario Name Show ECG image
Steps
1. Invoke database.
2. Get ECG of desired patients.

MESSAGE DESCRIPTION

Select desired
patient
Simple message Doctor System
Check details Message to self System System
Forward details Simple message System patient db
Search ECG image Message to self Patient db Patient db
ECG image found Reply message Patient db system
Show ECG image Simple message system doctor



Mobile

Behavior: State Chart Diagram


STATE CHART DIAGRAM OVERVIEW

1. OBJECT STATE DESCRIPTION #1

Object Name States
Admin Accept Login details
Admin logged in successfully
Login failed


1.1 STATES DESCRIPTION

State Name Type Action Set
Accept login details Simple 1Accept admin username
2.Accept admin password
3.Proceed details
Admin logged in
successfully
Simple 1Admin is validated
2.Allow admin to access database
3.establish connection between
admin and system database
Login failed Simple 1Invalid login details entered
2.Notify error message
3.Ask for re-login

1.2 SPECIFIC DESCRIPTION

Transition Event Guard condition Transition Action
Process details Details are
received
Method of input Data get processed
Validate admin Details get
verified
Database invoked
properly
Admin is authenticated
Logged in
successfully
Admin logged in Connection to server
available
Admin and database
connection established
Login failed Admin login
failed
Re-enter details Ask for login again



Object Name States
Doctor Accept Login details
Doctor logged in successfully
Login failed



Accept login details Simple 1Accept doctor username
2.Accept doctor password
3.Proceed details
Doctor logged in
successfully
Simple 1Doctor is validated
2.Allow doctor to access database
3.establish connection between
doctor and system database
Login failed Simple 1Invalid login details entered
3.Ask for re-login


Process details Details are
received
Method of input Data get processed
Validate doctor Details get
verified
Database invoked
properly
Admin is authenticated
Logged in
successfully
Doctor logged in Connection to server
available
Doctor and database
connection established
Login failed Doctor login
failed
Re-enter details Ask for login again



Object Name States
Doctor Connect to database
Show patient records



Connect to
database
Simple 1.Authenticate the doctor
2.invoke database
3.connected to database
Show patient
records
Simple 1.connect to database
2.fetch all patient records
3.forward all patient details
4.display records


Connection
established
Database get
invoked
Patient records not
empty
All patient records
fetched and forwarded to
display



Object Name States
Doctor Select patient
Show ECG report
Display error message



Selecting a patient Simple 1.Authenticate doctor
2.identify the patient
3.search in database
4.fetch the path of image
Show ECG image Simple 1.trace the path of image
2.fetch the image
3.store image in temporary file
4.display the image file
Display error
message
Simple 1.no image found at given
location


Patient found Desired patient
found
Patient database not
empty
Image path is set
Image found ECG image of
desired patient
found
Image name duplicate
is avoided at given
location
Image is forwarded to
display
Image not found ECG image not
found at given
location
Path stored in database
is correct
Display error message



Mobile

Activity Diagram


ACTIVITY DIAGRAM OVERVIEW

1. DOCTOR LOGIN PROCESS


2. DISPLAY PATIENT RECORD


3. DISPLAY ECG IMAGE


4. UPDATE DATABASE



Mobile

System Design Document


CLASS DIAGRAM


CRC TEMPLATE #1

Class Name Create Record
Class Type Control
Characteristics Create the patients record
Super class None
Subclass 1. Quick Create
Variables
TBD
Services 1. Perform creation of records
Responsibilities
1. create_record()
Collaborators
1. patient_db

CRC TEMPLATE #2

Class Name Upload Record
Class Type Practitioner
Characteristics Upload records to server
Super class None
Subclass Instant upload
Variables
TBD
Services 1. Perform uploading of records
Responsibilities
1. instant_upload()
Collaborators
1. patient_db

CRC TEMPLATE #3

Class Name Perform Authentication
Class Type Doctor
Characteristics Authorizes user
Super class None
Subclass
Perform Login
Validate Existing Users
Variables
TBD
Services 1. Validate existing users
Responsibilities
1. register_user()
2. validate_user()
Collaborators
1. doc_db
2. doc_db

CRC TEMPLATE #4

Class Name Validate Existing Users
Class Type Doctor
Characteristics Provide system access to valid users
Super class Perform Authentication
Subclass None
Variables
TBD
Services
1. Accept login details
2. Validate user
Responsibilities
1. accept_login_details()
Collaborators
1. doc_db

CRC TEMPLATE #5

Class Name View Record
Class Type Doctor
Characteristics View patient record
Super class Check patient details
Subclass None
Variables
TBD
Services 1. View details of patient health
Responsibilities
1. view_log()
Collaborators
1. patient_db

CRC TEMPLATE #6

Class Name View image.
Class Type Doctor
Characteristics View ECG image
Super class Check ECG report
Subclass None
Variables
TBD
Services 1. View patient ECG report
Responsibilities
1. view_images()
Collaborators
1. patient_db



Mobile

System Implementation Document


GENERAL INFORMATION

Document Title System Implementation document.
Version 1.0
Author Abhijit,Charudatta,Rohit,Piyush
Project Name
Wireless Interactive System for Patient
Healthcare Monitoring using Mobile
Computing Devices.
Project Phase 3
Project Iteration 1

VERSION CONTROL

Date Version Description Author
Apr-20-2012 1.0 Created Abhijit,Charudatta,Rohit,Piyush

INFORMATION DETAILS

Filename Application
Last Saved On Thursday, April 19, 2012, 11:47:00 PM
Last saved by Abhijit,Charudatta,Rohit,Piyush
Number of Pages 16


1. COMPONENT DIAGRAM DESCRIPTION

Each subsection of this section will refer to or contain a detailed description of a
system software component. The discussion provided should cover the following
software components attributes.


1.1 COMPONENT #1

Component name Perform Login
Classification Module
Definition
The module gives secure access to the
application
Responsibilities
Checks Wi-Fi connectivity and Secures
login.
Constraints It needs Wi-Fi connection.
Compositions Wi-Fi connection.
Uses/Interactions User Login for authentication
Resources
Android enabled device and Wifi
connection
Processing
1. Accept User input.
2. Click on Accept remember me icon
3. Authenticates.

1.2 COMPONENT #2

Component name Manage Patient Record
Classification Different Records of Patient
Definition The processes performed by the user.
Responsibilities
It provides the facility to check the record
of the patient.
Constraints Doctor should be authenticated
Compositions
1.Patient ID.
2.ECG Recorded
Uses/Interactions It uses the List view/Tab view
Resources It needs different Interaction patterns.
Processing
1.Select the ID.
2.Start the required procedure.

2. DEPLOYMENT DIAGRAM DESCRIPTION



Mobile

System Testing Document


GENERAL INFORMATION

Document Title Test Cases
Version 1.0
Author Abhijit,Charudatta,Piyush,Rohit
Project Name
Wireless Interactive System for patient
Healthcare Monitoring using Android
mobile.
Project Phase Phase 1
Project Iteration 1

VERSION CONTROL

Date Version Description Author
Apr-20-2012 1.0 Created Abhijit,Charudatta,Piyush,Rohit

INFORMATION DETAILS

Filename Application
Last Saved On Thursday, April 19, 2012, 11:47:00 PM
Last saved by Abhijit,Charudatta,Piyush,Rohit
Number of Pages 13


1. TEST PLAN

1.1 PURPOSE

The purpose of this document is to determine the feasibility of enhancing a
Wireless Interactive system .This study also aims at analyzing the various issues that are
expected to arise during development of this application as software system concerning
its hardware implementation, interaction and integration with other systems and
potentially competing alternatives to the proposed system.
The aim is to obtain general information about current system and processes,
system objectives, assumptions & constraints. This document also supplies the
comparison of alternatives
The feasibility study determines whether proposed system can be mapped to real
life software products. The study involves mobile and wireless information technology
concepts that can be used to interact with a medical information system for viewing
patient record.
The feasibility study takes into account following factors:
Android architecture.
Platforms (android, blackberry, ios).

1.2 TEST PLAN IDENTIFIER

The software items to be tested are the goals that the software is designed to
accomplish. These goals manifest themselves as functional requirements of the System.
The following features of the system will be tested.

1.3 CHECK DATABASE CONNECTIVITY.

1. Check WIFI connectivity.
2. Authenticating user by username and password.
3. Check ECG of patient.

1.4 TEST ITEMS

1. Storing user information.
2. User Authentication
3. Provide patient records.
4. View ECG of patient.

1.5 FEATURES TO BE TESTED

Initially system will check whether WIFI connectivity is available. If it is not
available user will not be redirected to next screen and notified regarding no network
connectivity. Provision of authentication of the user. The user will only transfer to next
screen if he has provided correct username and password.

1.6 FEATURES NOT TO BE TESTED

The features of the system that will not be tested are those that mapped to the non
functional requirements of the system. This include features like reusability, efficiency,
correctness, reliability, performance.

1.7 ITEM PASS/FAIL CRITERIA

The criteria to be used to determine whether each test item has passed or failed.
Testing is a combination of the right output being given for the right input and also an
invalid or incomplete input being handled in appropriately whenever it occurs. If both
these criteria were to be satisfied the item under test would be considered to have passed
the test. In other situation it will be considered to have failed the test.


1.8TEST DELIVERABLES
The test deliverables include primarily test input data and test output data. They
also include the test results indicating the error and features in which the error was
identified.

1.9ENVIRONMENTAL NEEDS
Android SDK 2.3.3
Eclipse INDIGO.
Android enabled device (Samsung Galaxy)

2. TEST CASE SPECIFICATIONS

2.1TEST CASE 1:

Test case specification identifier TC-1
Test items Check WIFI connectivity
Input specifications Clicking Sign-in button
Output specifications Active connection to the device
Special procedure requirements WIFI connection
Inter-case dependencies None

2.1.1 Test Procedure

Test item checklist Description
Test procedure specification ID TP-1
Purpose Connection to server
Specific requirements WIFI connectivity

2.1.2 Procedure steps

Setup/Startup When Sign-In button is clicked
Proceed Procedure
Measure Message of connection established
Preconditions WIFI connectivity should be available
Post conditions Redirection to next screen
Stop Exit from application
Wrap up Generate a completion message
Contingencies Abnormal termination of any thread

2.2 TEST CASE 2:

Test items Signing in for Doctor
Input specifications Accept doctor information
Output specifications Notification of signed in successfully
Special procedure requirements No requirement
Inter-case dependencies Test case 1 should be successful


Purpose Enable the doctor to use the application.
Specific requirements None.


Setup/Startup When Sign-up button is clicked
Proceed
Procedure
Accept necessary information from the
doctor.
When doctor clicks on sign-in, It notifies
user whether successfully logged in or not.
Measure Sign In screen is displayed to the user.
Preconditions User must fill mandatory text fields
Post conditions Notification is provided when logged in.
Stop Click on the close button
Contingencies Sign in unsuccessful.

2.3 TEST CASE 3:

Test items Authentication of an doctor
Input specifications Accept username and password
Output specifications Displays the Patient list.
Special procedure requirements Active WIFI connection



Purpose Secure use of application
Specific requirements Username and password should match.


Setup/Startup When application is started.
Proceed
Procedure
Accept Username and password.
When user clicks on Sign-in authenticates
the user and either direct him to next page
or show error message.
Measure Sign In screen is displayed to the doctor.
Preconditions User must fill all text fields
Post conditions Redirection or error message.
Stop Click on the Exit button
Contingencies Authentication failed.

2.4 TEST CASE 4:

Test items View ECG of patient.
Input specifications Patient link is clicked.
Output specifications View ECG of specified patient.
Special procedure requirements Database Connectivity.


Purpose View ECG of patient to doctor.
Specific requirements Database Connectivity.



Setup/Startup When patient list is displayed.
Proceed
Procedure
Patient list is displayed (List view)
Doctor clicks desired patient .
Successfully showing ECG.
Measure Image is displayed to user.
Preconditions Database of patient should be connected.
Post conditions ECG image is displayed.
Stop Click on the Back button
Contingencies ECG not displayed.

SUMMERY OF RESULTS:

The summary of these testing documents is to test above procedures and programs
which will give output as expected from the system and results of tests are correct and
matching with the results specified while analyzing the requirements of the project.



Mobile

Snapshots



Application (AndroidPRS) in home screen



First Appearance of application



Sign in Activity



Providing authenticated details



Unsuccessful login due to wrong credentials



Displaying patient records



Displaying ECG image



Mobile

Conclusion



CONCLUSION

The project has been implemented in android OS. Android OS is open source
operating system and SDK is freely available in the market. Hence developing cost of
application was negligible. Checking patient details and ECG anywhere in hospital
premises was not possible for doctor. Using an android mobile now he can diagnose the
patient.

The project is very much user friendly and helps doctor deal with his patients.
This project stands out with the combination of database connectivity,WiFi connectivity
and appropriate ECG viewing.



Mobile

References



REFERENCES


B.E. Computer Final Year Project

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

B.E. Computer Final Year Project

Uploaded by

Copyright:

Available Formats

Wireless Interactive System for

Patient Healthcare Monitoring using

You might also like