B E Computer Final Year Project PDF

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.
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
Department of Computer Engineering
INDEX
1. PROJECT SYNOPSIS
1.1 Context
1.2 Problem
1.3 Solution
1.4 Benefits
2. FEASIBILITY STUDY REPORT
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

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.2 General Information
5.3 Use Case Diagrams
5.4 Use Case Templates
6. BEHAVIOR : SEQUENCE DIAGRAMS
6.1 Sequence Diagram Overview For Entire System
33
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
10.1
Component Diagram Description
10.2
Deployment Diagram Description
11. SYSTEM TESTING DOCUMENT

11.1
General Information
11.2
Test Plan
11.3
Test Case Specification
60
65
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 ehealth 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
Authenticate doctor.
High
Show all patient record.

Show ECG of desired patient.
Business Goals:
Cost-effective
High
High
User can upload database, insert or update

entities and use it for analysis.
The Doctor will be assigning unique ID and
password to access the patient database.
The patient record is shown in tabular format.
ECG of desired patient is shown.
To reduce development cost
High
High
Technological Goals:
Implementation simplicity
Reliability
High
Quality Goals:
Performance
Usability
High
High
Since the resources required are cheap, the

organization doesnt have to spend capital on
it.
Using open source and freeware development
tools development cost can be reduced.
Customization of product according to
hospitals need.
The product should be reliable to ensure
correct Info. Of patient.
The optimization of operational speed.
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
M
2
M
3
Start Planning
Phases of project are
decided.
Feasibility study done with
objective planning.
Start Execution
Planning
Data collection and study
Collect
and
study
research material for
existing systems and for
implementing proposed
system.
M
5
M
6
Scope
and
clarified.
Start Introduction
2011-09-28
concept
2011-09-30
2011-11-08
2011-11-15
2012-1-15
Confirm Execution
Design the System
M
4
2011-09-25
Develop a model of the 2012-1-25

system
2012-02-08
2012-02-17
Decide algorithms and

implementation of system
Release Product
Start Coding
Test Model.
Run test cases and 2012-08-25

release the product on
success.
2012-10-08
Close Project
2012-04-22

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
Wireless Interactive System for Patient Healthcare
WISPHMUA
Monitoring System Using Android Mobile.

A document that completely describes all of the
functions of a proposed system and the constraints
Software
Specification
Requirements
under which it must operate. For example, this

document
Collection of all the information monitored by this
Database
system.
It
is
a relational
database
management
system (RDBMS) that runs as a server providing multiMySql
user access to a number of databases.
GUI
Graphical User Interface.

It is platform consist of a set of services, APIs and
protocols that provide the functionality for developing
J2EE
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
1. Patient record updation.
The problem of
2. Inaccessible data.
1. User switching from one handset to
Affects
another(of same or different company)
The impact of which is
1.Handset loss and Connectivity problem
A successful solution
1. Cross Platform Support.
would
2. Increased Security.
2.1 PRODUCT PERSPECTIVE
PRODUCT POSITION STATEMENT

For
Who
That
Unlike
Our product
The Mobile Users.

Android users.
Is used to view the patient records and ECG.
Viewing the database in paper form.
Is simple in handling and will increase user satisfaction.
2.1.1 System Interfaces

System Environment
Platform
Front End
Back End
: Windows operating system

: Android 2.2 and above
: JSP
: 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
1. The database should have proper database schema to manage the
Preconditions
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
DESCRIPTION
Admin will login at server PC using login details.
He /She can invoke database using SQL queries.
He /She can also modify database directly.
Step
Error Scenario
File is not properly imported as the original .db file.
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
Trigger
DESCRIPTION
DESCRIPTION
No secondary actors present.

The action will be initiated when a Doctor enters Username and
Password.
Step
1
Doctor open respective Android app.
He /She performs authentication.
He /She gets access to the system.
Step
Error Scenario
User enters invalid username or password or both.
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.
Secondary Actors
Trigger
The action will be initiated when doctor logged in successfully.
DESCRIPTION
Step
DESCRIPTION
Doctor will be logged in on MCD.
MCD will fetch patient details from Patient Database.
User can see Patient details on MCD.
Step
Error Scenario
Not enough memory to load details on MCD.
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.
1. Doctor should select patient whose ECG image he want.
Preconditions
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.
Secondary Actors
Trigger
The action will be initiated when a doctor select desired patient.
DESCRIPTION
Step
DESCRIPTION
Doctor will select desired Patient from list.
The system will show ECG image of selected patient.
Step
Error Scenario
Image of desired patient is not available into db.
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
1. Authenticate the admin
Basic course of action
2. For authentication verify admin login details.

3. Connect database with admin.
4. Now
perform
operations
like
modify,delete,update
database.
Alternate course of
1. Manually update database using mysql.
action
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
Basic course of action 2. Check details in database

3. Give response from database.
Alternate course of
action
MESSAGE DESCRIPTION
Message
Enter user name and password
Type
Simple
message
From Object
Doctor
Authenticate the details
Message
self
to System
Fetch details
Simple
message
System
Details found
Reply
message
Doctor Database System
Login successful
Reply
message
System
Invalid data
Reply
message
Doctor database System
Notify doctor
Reply
message
System
Doctor
Unsuccessful login
Message
self
to Doctor
Doctor
To Object
System
System
Doctor
Database
Doctor

Use Case
Use case3
Scenario Name
Show all patient records
Steps
1. Invoke the database
Basic course of action 2. Select all records from patient database

3. Send all records as response
4. Display all records
Alternate course of Show record of specific patient
action
MESSAGE DESCRIPTION
Message
Authenticate login
Type
Simple message
From Object
Doctor
To Object
System
Verify id
Message to self
System
System
Request for patient Message to self

details
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.
Basic course of action
2.
Get ECG of desired patients.
MESSAGE DESCRIPTION
Message
Select
Type
desired Simple message
From Object
Doctor
To Object
System
patient
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
Accept login details Simple
Action Set
1Accept admin username
2.Accept admin password
3.Proceed details
Admin logged in Simple

successfully
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
Process details
Details
are Method of input
Transition Action
Data get processed
received
Validate admin
Logged
Details
get Database
verified
properly
in Admin logged in Connection to server Admin
successfully
Login failed
invoked Admin is authenticated
available
Admin
login Re-enter details
failed
and
database
connection established
Ask for login again
Object Name
States
Doctor
Accept Login details

Doctor logged in successfully
Login failed
State Name
Type
Accept login details Simple
Action Set
1Accept doctor username
2.Accept doctor password
3.Proceed details
Doctor logged in Simple

successfully
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
Transition
Process details
Event
Details
received
Guard condition
are Method of input
Validate doctor
Details
verified
get Database
properly
Logged
successfully
Login failed
Transition Action
Data get processed
invoked Admin is authenticated
in Doctor logged in Connection to server Doctor and database

available
connection established
Doctor
failed
login Re-enter details
Ask for login again
Object Name
States
Doctor
Connect to database
Show patient records
State Name
Connect
database
Type
to Simple
Action Set
1.Authenticate the doctor
2.invoke database
3.connected to database
Show
records
patient Simple
1.connect to database
2.fetch all patient records
3.forward all patient details
4.display records
Transition
Event
Guard condition
Connection
Database
established
invoked
get Patient
records
Transition Action
not All
empty
patient
fetched and forwarded to

display
records
Object Name
States
Doctor
Select patient
Show ECG report
Display error message
State Name
Type
Selecting a patient Simple
Action Set
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
message
error Simple
1.no image
location
found
at
given
Transition
Event
Guard condition
Patient found
Desired
patient Patient
found
Image found
not Image path is set
empty
ECG
image
desired
of Image name duplicate Image is forwarded to
patient is avoided at given display
found
Image not found
database
Transition Action
location
ECG image not Path stored in database Display error message

found
at
given is correct
location

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
Class Type
Characteristics
Super class
Subclass
Variables
Services
Responsibilities
1. create_record()
Create Record
Control
Create the patients record
None
1. Quick Create
TBD
1. Perform creation of records
Collaborators
1. patient_db
CRC TEMPLATE #2
Class Name
Class Type
Characteristics
Super class
Subclass
Variables
Services
Responsibilities
1. instant_upload()
Upload Record
Practitioner
Upload records to server
None
Instant upload
TBD
1. Perform uploading of records
Collaborators
1. patient_db
CRC TEMPLATE #3
Class Name
Class Type
Characteristics
Super class
Subclass
Variables
Services
Responsibilities
1. register_user()
2. validate_user()
Perform Authentication
Doctor
Authorizes user
None
Perform Login
Validate Existing Users
TBD
1. Validate existing users
Collaborators
1. doc_db
2. doc_db
CRC TEMPLATE #4
Class Name
Class Type
Characteristics
Super class
Subclass
Variables
Services
Responsibilities
1. accept_login_details()
Validate Existing Users

Doctor
Provide system access to valid users
Perform Authentication
None
TBD
1. Accept login details
2. Validate user
Collaborators
1. doc_db
CRC TEMPLATE #5
Class Name
Class Type
Characteristics
Super class
Subclass
Variables
Services
Responsibilities
1. view_log()
View Record
Doctor
View patient record
Check patient details
None
TBD
1. View details of patient health
Collaborators
1. patient_db
CRC TEMPLATE #6
Class Name
Class Type
Characteristics
Super class
Subclass
Variables
Services
Responsibilities
1. view_images()
View image.
Doctor
View ECG image
Check ECG report
None
TBD
1. View patient ECG report
Collaborators
1. patient_db

Mobile
System Implementation Document
GENERAL INFORMATION
Informational Item
Information
Document Title
System Implementation document.
Version
1.0
Author
Abhijit,Charudatta,Rohit,Piyush
Wireless Interactive System for Patient
Project Name
Healthcare Monitoring using Mobile

Computing Devices.
Project Phase
Project Iteration
VERSION CONTROL
Date
Version
Description
Author
Apr-20-2012
1.0
Created
INFORMATION DETAILS
Informational Item
Information
Filename
Application
Last Saved On
Thursday, April 19, 2012, 11:47:00 PM
Last saved by
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
Responsibilities
The module gives secure access to the

application
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
1. Accept User input.
Processing
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
Constraints
Compositions
It provides the facility to check the record

of the patient.
Doctor should be authenticated
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
Informational Item
Document Title
Version
Author
Information
Test Cases
1.0
Abhijit,Charudatta,Piyush,Rohit
Wireless Interactive System for patient
Healthcare Monitoring using Android
mobile.
Phase 1
1
Project Name
Project Phase
Project Iteration
VERSION CONTROL
Date
Apr-20-2012
Version
1.0
Description
Created
Author
INFORMATION DETAILS
Informational Item
Filename
Last Saved On
Last saved by
Number of Pages
Information
Application
Thursday, April 19, 2012, 11:47:00 PM
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
Test items
Input specifications
Output specifications
Special procedure requirements
Inter-case dependencies
TC-1
Check WIFI connectivity
Clicking Sign-in button
Active connection to the device
WIFI connection
None
2.1.1 Test Procedure

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

Setup/Startup
Proceed
Measure
Preconditions
Post conditions
Stop
Wrap up
Contingencies
When Sign-In button is clicked

Procedure
Message of connection established
WIFI connectivity should be available
Redirection to next screen
Exit from application
Generate a completion message
Abnormal termination of any thread
2.2 TEST CASE 2:

Test items
1.2.1
Test Procedure
Test item checklist

Purpose
1.2.2
TC-2
Signing in for Doctor
Accept doctor information
Notification of signed in successfully
No requirement
Test case 1 should be successful
Description
TP-2
Enable the doctor to use the application.
None.
Procedure steps
When Sign-up button is clicked
Procedure
Accept necessary information from the
doctor.
When doctor clicks on sign-in, It notifies
user whether successfully logged in or not.
Sign In screen is displayed to the user.
User must fill mandatory text fields
Notification is provided when logged in.
Click on the close button
Sign in unsuccessful.
Setup/Startup
Proceed
Measure
Preconditions
Post conditions
Stop
Wrap up
Contingencies
2.3 TEST CASE 3:

Test items
TC-3
Authentication of an doctor
Accept username and password
Displays the Patient list.
Active WIFI connection
1.3.1
Test Procedure
Test item checklist

Purpose
1.3.2
Description
TP-3
Secure use of application
Username and password should match.
Procedure steps
When application is started.
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.
Sign In screen is displayed to the doctor.
User must fill all text fields
Redirection or error message.
Click on the Exit button
Authentication failed.
Setup/Startup
Proceed
Measure
Preconditions
Post conditions
Stop
Wrap up
Contingencies
2.4 TEST CASE 4:

Test items
TC-4
View ECG of patient.
Patient link is clicked.
View ECG of specified patient.
Database Connectivity.
2.4.1 Test Procedure

Test item checklist
Purpose
Description
TP-4
View ECG of patient to doctor.
Database Connectivity.
2.4.2
Procedure steps
When patient list is displayed.
Procedure
Patient list is displayed (List view)
Doctor clicks desired patient .
Successfully showing ECG.
Image is displayed to user.
Database of patient should be connected.
ECG image is displayed.
Click on the Back button
ECG not displayed.
Setup/Startup
Proceed
Measure
Preconditions
Post conditions
Stop
Wrap up
Contingencies
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 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

B E Computer Final Year Project PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Wireless Interactive System for

Patient Healthcare Monitoring using

Under the guidance of

DEPARTMENT OF COMPUTER ENGINEERING

Bansilal Ramnath Agarwal Charitable Trusts

Head of the Department

Vishwakarma Institute of Technology, Pune-37.

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

Assumptions and Constraints

Recommendations and Conclusion

3. SOFTWARE PROJECT PLAN

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

4. SOFTWARE REQUIREMENT SPECIFICATION

4.8 Product Perspective

Assumptions and Dependencies

4.12.1 External Interfaces

5. USE CASE ANALYSIS DOCUMENT

5.1 Use Case Specifier List

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

7. BEHAVIOR : STATE CHART DIAGRAMS

7.1 State Chart Diagram Overview

8.1 Activity Diagram Description

9.1 Class Diagram

Component Diagram Description

Deployment Diagram Description

11. SYSTEM TESTING DOCUMENT

Test Case Specification

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

Wireless Interactive System

Software Project Synopsis

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

Wireless Interactive System

Feasibility Study Report

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

2.1 CURRENT SYSTEMS AND PROCESSES

2.2 SYSTEM OBJECTIVES

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

2.4 ASSUMPTIONS AND CONSTRAINTS

4. RECOMMENDATIONS AND CONCLUSION

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

Wireless Interactive System

Software Project Plan

Department of Computer Engineering

Vishwakarma Institute of Technology, Pune-37.

Organisations are involved for providing

2. GOALS AND SCOPE

Show all patient record.

User can upload database, insert or update

To reduce development cost

Since the resources required are cheap, the

Department of Computer Engineering