Professional Documents
Culture Documents
B E Computer Final Year Project PDF
B E Computer Final Year Project PDF
BE H 54
ROHIT KHADKE
BE H 55
PIYUSH SHANKAR
BE I 51
CHARUDATTA KANDARE
BE H 49
2011 - 2012
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
Name:
Name: Prof.S.B.Karthick
Signature:
Signature
External Examiner
Name:
Signature
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 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
2.11
Alternatives
2.12
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
Product Functions
4.11
4.12
Specific Requirements
Reliability
4.12.5.2
Availability
4.12.5.3
Security
4.12.5.4
Portability
23
33
42
51
56
10.2
General Information
11.2
Test Plan
11.3
60
65
12. SNAPSHOTS
73
13. CONCLUSION
81
14. REFERENCES
83
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.
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.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.
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).
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
ECG.
Priority
Comment/Description/Reference
Functional Goals:
Perform database operation.
High
Authenticate doctor.
High
High
High
High
High
Technological Goals:
Implementation simplicity
Reliability
High
Quality Goals:
Performance
Usability
High
High
Project Goal
Priority
Comment/Description/Reference
Constraints:
Resource Constraints
High
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.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
Description
Milestone Criteria
Planned
Date
M
0
Start Project
Budget Release
2011-09-15
Understand
the
requirements and define
project goals and scope
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
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
Start Coding
Test Model.
Close Project
2012-04-22
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.
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.
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.
Term or Acronym
Definition
Wireless Interactive System for Patient Healthcare
WISPHMUA
Software
Specification
Requirements
Database
system.
It
is
a relational
database
management
GUI
J2EE
1.4 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
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
A successful solution
would
2. Increased Security.
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:
Windows XP or higher.
RAM: 1 GB
Hard Drive: 4 GB
3. SPECIFIC REQUIREMENTS
3.1 EXTERNAL INTERFACES
ECG machine
3.2 FUNCTIONS
Process 2
Process 2
: The system uploads newly added and modified contacts on the server .
Process 2
: The system shall check for user with valid username, password..
Process 2
Objective 1
Process 1
Process 2
Process 2
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.
2. GENERAL INFORMATION
System Context Diagram:
3.1 USECASE # 1
USE CASE # 1
Goal
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.
Post Conditions
Primary Actors
Admin
Secondary Actors
Trigger
The action will be initiated when a tester has to import a .db file.
DESCRIPTION
Step
DESCRIPTION
Step
Error Scenario
3.2 USECASE # 2
USE CASE # 2
Perform Authentication.
Goal
Purpose
Precondition
Post condition
Primary Actors
Doctor.
Secondary Actors
Trigger
DESCRIPTION
DESCRIPTION
Step
Error Scenario
3.3 USECASE # 3
USE CASE # 3
Goal
Purpose
Preconditions
Post Conditions
Primary Actors
Doctor.
Secondary Actors
Trigger
DESCRIPTION
Step
DESCRIPTION
Step
Error Scenario
3.4
USECASE # 4
USE CASE # 4
Goal
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
Post Conditions
Primary Actors
Doctor.
Secondary Actors
Trigger
DESCRIPTION
Step
DESCRIPTION
Step
Error Scenario
Error in connection.
Use case1
Scenario Name
Steps
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
Message to self
System
System
System
Doctor database
Update database
Message to self
Doctor Database
Doctor Database
Doctor Database
Admin
System
Patient database
Update database
Message to self
Patient database
Patient database
Patient database
Admin
Use case2
Scenario Name
Authenticating Doctor
Steps:
action
MESSAGE DESCRIPTION
Message
Enter user name and password
Type
Simple
message
From Object
Doctor
Message
self
to System
Fetch details
Simple
message
System
Details found
Reply
message
Login successful
Reply
message
System
Invalid data
Reply
message
Notify doctor
Reply
message
System
Doctor
Unsuccessful login
Message
self
to Doctor
Doctor
To Object
System
System
Doctor
Database
Doctor
Use case3
Scenario Name
Steps
MESSAGE DESCRIPTION
Message
Authenticate login
Type
Simple message
From Object
Doctor
To Object
System
Verify id
Message to self
System
System
System
System
System
Patient db
Message to self
Patient db
Patient db
Forward records
Reply message
Patient db
System
Reply message
System
Doctor
Use case4
Scenario Name
Steps
1.
Invoke database.
2.
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
Patient db
Patient db
Reply message
Patient db
system
Simple message
system
doctor
Object Name
States
Admin
State Name
Type
Accept login details Simple
Action Set
1Accept admin username
2.Accept admin password
3.Proceed details
1Admin is validated
2.Allow admin to access database
3.establish connection between
admin and system database
Login failed
Simple
Transition
Event
Guard condition
Process details
Details
Transition Action
Data get processed
received
Validate admin
Logged
Details
get Database
verified
properly
successfully
Login failed
available
Admin
failed
and
database
connection established
Ask for login again
Object Name
States
Doctor
State Name
Type
Accept login details Simple
Action Set
1Accept doctor username
2.Accept doctor password
3.Proceed details
1Doctor is validated
2.Allow doctor to access database
3.establish connection between
doctor and system database
Login failed
Simple
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
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
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
Display
message
error Simple
1.no image
location
found
at
given
Transition
Event
Guard condition
Patient found
Desired
patient Patient
found
Image found
empty
ECG
image
desired
found
Image not found
database
Transition Action
location
at
given is correct
location
Activity Diagram
3. DISPLAY ECG
IMAGE
4. UPDATE DATABASE
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()
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
GENERAL INFORMATION
Informational Item
Information
Document Title
Version
1.0
Author
Abhijit,Charudatta,Rohit,Piyush
Wireless Interactive System for Patient
Project Name
Project Phase
Project Iteration
VERSION CONTROL
Date
Version
Description
Author
Apr-20-2012
1.0
Created
Abhijit,Charudatta,Rohit,Piyush
INFORMATION DETAILS
Informational Item
Information
Filename
Application
Last Saved On
Last saved by
Abhijit,Charudatta,Rohit,Piyush
Number of Pages
16
1.1 COMPONENT #1
Component name
Perform Login
Classification
Module
Definition
Responsibilities
Constraints
Compositions
Wi-Fi connection.
Uses/Interactions
Resources
Processing
1.2 COMPONENT #2
Component name
Classification
Definition
Responsibilities
Constraints
Compositions
Uses/Interactions
Resources
Processing
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
Abhijit,Charudatta,Piyush,Rohit
INFORMATION DETAILS
Informational Item
Filename
Last Saved On
Last saved by
Number of Pages
Information
Application
Thursday, April 19, 2012, 11:47:00 PM
Abhijit,Charudatta,Piyush,Rohit
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.
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)
TC-1
Check WIFI connectivity
Clicking Sign-in button
Active connection to the device
WIFI connection
None
Description
TP-1
Connection to server
WIFI connectivity
Test Procedure
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
Generate a completion message
Sign in unsuccessful.
Setup/Startup
Proceed
Measure
Preconditions
Post conditions
Stop
Wrap up
Contingencies
TC-3
Authentication of an doctor
Accept username and password
Displays the Patient list.
Active WIFI connection
Test case 1 should be successful
1.3.1
Test Procedure
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
Generate a completion message
Authentication failed.
Setup/Startup
Proceed
Measure
Preconditions
Post conditions
Stop
Wrap up
Contingencies
TC-4
View ECG of patient.
Patient link is clicked.
View ECG of specified patient.
Database Connectivity.
Test case 3 should be successful
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
Generate a completion message
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.
Snapshots
Sign in Activity
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.
References
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