ORIENTAL INSTITUTE OF SCIENCE &

TECHNOLOGY

Virtual Medical Home

Software Requirements Specification

Team:
Archangels

Team Members:
Deep Saran
Harsh Hemani
Shubhankar Roy

Project Guide:
Mr. Prakash Narayan Harda
 INDEX & TABLES

SNO. CONTENTS PAGE NO.

1 Introduction 3
1.1 Objective 3
1.2 Scope 3
1.3 Abbreviations 4
1.4 References 4
1.5 Technologies 5
2 Overall Description 5
2.1 Product Perspective 5
2.2 Software Interface 6
2.3 Hardware Interface 6
2.4 Communication Interface 6
2.5 Product Function 7
2.6 User Characteristics 7
2.7 Constraints 7
2.8 Use-Case Model Survey 8
2.9 Architecture Diagram 9
2.10 Database Design 10
2.11 Assumptions and Dependence 12
3 Specific Requirements 12
3.1 Use-Case Reports 12
3.2 Supplementary Requirements 27

2
Introduction
Objective: The objective of this project, Virtual Medical Home is to provide
essential medical services online to everyone hardly matters you live in
metro or a remotely located village. Users can connect through their
home internet or approach any nearby kiosk to get these services. What
motivate to build this system are:
 Very few or no doctors at remote locations
 Limited hour services and lack of sophisticated medical equipments
 No patient’s history/lab data management

Scope:
 Create different system users and manage their details.
 Doctors and Kiosk Managers will be added as a user of the system
only after manual verification from administrator.
 Patients can make online appointment, look their previous health
records, doctor’s prescriptions, lab reports and medical expenses
 Doctor’s can give appointments, e-prescriptions, and view patient’s
history.
 Web-cam based interaction between patient and doctor.
 Kiosk Manager can see/adjust appointments, perform day open &
close activities and calculate his commission.
 In case of any medical error (wrong medication or lab report) patient
can register a complaint. Patient’s grievance and feedback goes to
Admin he can forward it to any doctor to answer.
 Facilitates appropriate communication between all stakeholders -
Discussion forum/chat/mail/polls
 Site has details online help manual for patients. Local language
support is also provided.
 Admin to take backup of all kind of data, view log and generate
system reports.

3
Abbreviations:
Payment transaction: Transaction between Kiosk manager and Patient
for all the payment of its e-prescription and
commission.
Personal details: Details of all the users such as username, company, phone
number, address, messenger_Id, e-mail address etc.
Contact details: Contact details of doctors associated with the company and
kiosk managers.
HTML: Hypertext Markup Language is a markup language used to design
static web pages.
EJB: Enterprise Java Beans.
J2EE: Java 2 Enterprise Edition is a programming platform— part of the Java
Platform—for developing and running distributed multitier
architecture Java applications, based largely on modular software
components running on an application server.
DB2: DB2 Database is the database management system that delivers a
flexible and cost-effective database platform to build robust on
demand business applications.
WAS: Web sphere application server is an application server that runs
business applications and supports J2EE and web services
standards.
WSAD: Web sphere studio application developer is a toolkit which is
designed for the creation of more complex projects, providing fully
dynamic web application utilizing EJB’s. This consist of EJB tools ,
CMP ,data mapping tools & a universal test client that is designed to
aid testing of EJB’ s.
HTTP: Hypertext Transfer Protocol is a transaction oriented client/server
protocol between web browser & a Web Server.
TCP/IP: Transmission Control Protocol/Internet Protocol, the suite of
communication protocols used to connect hosts on the Internet.
TCP/IP uses several protocols, the two main ones being TCP and IP.

4
References:
 IEEE SRS Format
 Problem Definition

Technologies:
 J2EE: Application Architecture
 DB2: Database
 WSAD: Development Tool
 WAS: Web Application Server
 Rational: Design Tool

Overall Description
Describe the general factors that affect the project and its requirements.

Product Perspective:

5
  The web pages (XHTML/JSP) are present to provide the user interface on
customer client side. Communication between customer and server is
provided through HTTP/HTTPS protocols.
 The Client Software is to provide the user interface on system user client
side and for this TCP/IP protocols are used.
 On the server side web server is for EJB and database server is for storing
the information.

Software Interface:

Client on Internet: Web Browser, Operating System(any)

Client on Intranet: Client Software, Web Browser, Operating System(any)
Web Server: WAS, Operating System(any)
Data Base Server: DB2, Operating System(any)
Development End: WSAD (J2EE, Java, Java Bean, Servlets, HTML),
DB2, Operating System (Linux), Web Server.

Hardware Interface:

Client Side
Processor RAM Disk Space
Internet Explorer Pentium II at 64 MB 1 GB
6.0 500MHz
Server Side
Web Sphere Pentium III at 1 512 MB 2GB
Application GHz
Server V 5.0
DB2 V8.1 Pentium III at 1 512 MB 1 GB (Excluding
GHz data size)

6
Communication Interface:
 Client on the Internet will be using HTTP protocol.

Product Function:
Track Account Level Data: In this module, receivables from customer
are maintained.
Authenticate Doctors and Kiosk Managers: The administrator will
manually check the details of each doctor and kiosk manager
and authenticate him/her.
Service Level Agreements: It contains the agreements of providing the
services to patients, doctors and kiosk managers.
User Contact Information: It maintains all the details (Personal,
Official, Contact, and Company) of different users.
Transactions Records: Maintenance of transactions related to
the services provided to patients, kiosk managers.
Maintaining Logs: Activities of the various users can be tracked through
the logs, which are maintained by the system.

User Characteristics: Every user should be comfortable of working with

computer and net browsing. Although we have provided
the support of using local languages yet it is preferred
that user should use English language.

Constraints:
 For full working of Virtual Medical Home requires internet connection.
 Login and password is used for identification of the various users that are
patient, doctor and kiosk manager.
 This system is working for single server.
 For backing up the data, the administrator will have to manually do it.

7
Use-Case Model Survey:

USE-CASE DIAGRAM

View own
Health Records & View own details
Lab reports details

Calculate fees
Medical
Expenses

Prescriptions

Doctor
Appointments
Patient
Patient’s
History
Calculate
commission

View own
details

Kiosk Manager

View all
details
Manage
View log
users
reports

Back-up all
System Administrator kind of data
reports

8
Architecture Diagram:

Application Layer Business Layer Data Layer

User_UI User User

User_Admin
User_Admin_UI User_Admin

User_Kiosk_UI User_Kiosk User_Kiosk

User_Doctor_UI User_Doctor User_Doctor

Prescription_UI Prescription_Taken Prescription_Taken

Appointment_UI Appointment_Made Appointment_Made

Poll_UI Poll_Record Poll_Record

Chat_UI Chat_Record Chat_Record

Forum_UI Forum_Records Forum_Records

Transaction_UI Transaction_Records Transaction_Records

9
Database Design:
User_Patient
Patient_Id
User_Id
User_Admin Gender
User_Id Height
User_Name Weight
Password Blood_Group
First_Name Disease
Last_Name Lab_Reports
E-mail History
Modified Interests
Created Free_info
Mail_Record

User
User_Id
User_Name User_Doctor
Password Doctor_Id
User_Id
First_Name
Gender
Last_Name
E-Mail IS_A Field
Company_Name
Modified
Created Company_Contact
Fees
Birth_Date
Address Interests
Zip_code Free_info
City
State
Country
Phone
Mobile User_Kiosk
Fax Doctor_Id
Messenger_Id User_Id
Mail_record Centre_Name
Photo Commission
About me
Expense_Record

10
Appointment_Made Prescription_Taken Complaint_Patient
App_Id PP_Id CP_Id
Patient_Id Patient_Id Patient_Id
Doctor_Id Doctor_Id Doctor_Id
Date Prescription Complaint
Time Date/Time Area
Kiosk Kiosk
Approval Expense

Forum_Records Chat_Records Poll_Records

FR_Id Chat_Id Poll_Id
Topic Patient_Id User_Id
User_Id Doctor_Id Topic
Date/Time Date/Time Question
Comment Option_A
Option_B
Option_C
Option_D
Transaction Records Ans_A
Transaction_Id Ans_B
From_Id Ans_C
To_Id Ans_D
Mode_of_Transaction Date/Time
Subject
Date
Time
Transaction_Detail
Kiosk_Manager

11
Assumptions and Dependencies:
 The details related to the patient, doctor, kiosk manager and
transaction provided manually.
 Administrator is created in the system already.
 Roles and tasks are predefined.

Specific Requirements:
Use-Case Reports:

Administrator: Responsible for managing all the three types of users, viewing
logs and managing standard groups of the system.
 Manage System Users: The Administrator will provide the system
users, Doctors and Kiosk Managers, authentication to use the site.
 View Logs: Responsible for checking the logs of different system
user for auditing and maintaining the integrity of the system.
 System Reports: The Administrator is responsible to generate
system reports for the future references.
 View All Details: View the users’ details, chatting details, complaint
details, daily service transaction details.
 Back Up data: The Administrator is responsible to back up all the
data at a particular time everyday.

Manage system users

12
Name of use case: View System Users
Description: View the list of system users in a role and view the details of
roles, tasks and permissions assigned to a system user.
Preconditions:
 Administrator is already logged in.
 System users have already been created and assigned some roles, tasks
and permissions.
Normal flow of events:
 The system user or a role will be selected.
 Query will be submitted.
 Relevant output will be displayed (If system user is selected then roles,
tasks and permissions assigned to one will be displayed and if role is
selected then list of system users assigned to that role will be displayed).
Alternate flow of events: None.
Post Condition: None.

Name of use case: Create System Users

Description: To create system users (Giving them a login name, password and
assign roles, tasks and permissions to them).
Preconditions: Administrator is already logged in.
Normal flow of events:
 New Login name, password, details, roles, tasks and permissions will be
entered.
 Save the details.

13
Alternate flow of events:
 A message appears for duplicate login name.
 The administrator has to fill the details again.
Post condition: A login id is generated with its details.

Name of use case: Update details of Users

Description: To update the details of system users (assigning or revoking roles,
tasks and permissions).
Preconditions:
 Administrator is already logged in.
 System Users have already been created.
Normal flow of events:
 Select the user name.
 Assign or Revoke the roles, tasks and permissions.
Post Condition: None

14
Name of use case: View logs
Description: To view the activities (logs) of the system users.
Precondition:
 Administrator is already logged in.
 System Users have already been created.
Normal flow of events:
 Select user name.
 Select date.
Post Condition: None

Kiosk Manager: Responsible to see/adjust appointments, perform day open &

close activities and calculate his commission.
 Login: Kiosk Manager can login to the site only if it receives an
authentication mail from the administrator.
 Appointments: Kiosk Manager can arrange appointments between a
patient and a doctor.
 View own details: Kiosk Manager can view his details and can also
update his profile but not its centre name and location.
 Calculate Commission: Kiosk Manager can calculate his
commission at the end of his day activities.

15
Name of the use case: View own details.
Description: View the personal details.
Precondition: Kiosk manager is already logged in.
Normal flow of events:
 View Personal details.
 The detail of corresponding Kiosk manager is viewed.
Alternate flow of events: None
Post condition: None.

16
Name of the use case: Calculate commission.
Description: Calculate the commission.
Precondition: Kiosk manager is already logged in.
Normal flow of events:
 Calculate Commission
 The commission of Kiosk manager is displayed.
Alternate flow of events: None
Post condition: None.

Name of the use case: Fix Appointment.

Description: Fix the appointment of patient with the doctor.
Precondition: Kiosk manager is already logged in.
Normal flow of events:
 Select Ask for appointment.
 The request for appointment is sent to the doctor.
Alternate flow of events: Patient can directly ask for appointment.
Post condition: Appointment may or may not be approved by doctor.

17
Doctor: Responsible to give appointments, e-prescriptions and can also view his
patient’s history.
 Login: A Doctor can login to the site only if it receives an
authentication mail from the administrator.
 Appointments: The Doctor can approve or give the appointments to
his/her patient.
 Prescriptions: The Doctor can provide the patients with
e-prescriptions.
 Fees: The Doctor can calculate his fees for the prescriptions he/she
provided it to patients.
 Patients’ History: The Doctor can view his/hers patients’ history
that he attended.
 View own details: The Doctor can view his details and can also
update his profile but not its field, company name and location.

18
Name of the use case: View own details.
Description: View the personal details.
Precondition: Doctor is already logged in.
Normal flow of events:
 View Personal details.
 The detail of corresponding Doctor is viewed.
Alternate flow of events: None
Post condition: None.

Name of the use case: View Patient’s History.

Description: View Patient’s health records, previous prescription & related information.
Precondition: Doctor is already logged in.
Normal flow of events:
 View Patient’s History.

19
  Enter the PatientID.
 The required details are displayed.
Alternate flow of events: None
Post condition: None.

Name of the use case: Calculate Fees

Description: Calculate the Fees.
Precondition: Doctor is already logged in.
Normal flow of events:
 Select calculate Fee.
 The fee is displayed.
Alternate flow of events: None
Post condition: None.

20
Name of the use case: Give E-Prescription.
Description: Doctor gives prescription to his patient.
Precondition: Doctor is already logged in.
Normal flow of events:
 Select give E-Prescription.
 The mail is sent to the PatientID.
Alternate flow of events: None
Post condition: Save the E-Prescription.

Name of the use case: Approve Appointments.

Description: Doctor gives appointment to the patient.
Precondition: Doctor is already logged in.
Normal flow of events:
 Select Approve Appointments.
 Doctor approve and fix the Appointment.(with any change in date and time)
Alternate flow of events: None

21
Post condition: Save the approved appointment.

Patients: Patients can make online appointment; look their previous health
records, doctor’s prescriptions, lab reports and medical expenses.
 Login: Patients can easily register to the site and after verification
they can easily login.
 Appointments: Patients can ask for appointments from their
respective doctor.
 Prescription: Patients can keep the records of the prescriptions
they’d been given by their respective doctors.
 Health Records: Patients can watch their previous health records in
their profile.
 Lab Reports: Patients can watch their previous lab reports provided
to them from their respective doctors.
 Medical Expense: They can keep a record of all the medical
expense and watch them in their profile.

22
Name of the use case: Ask for Appointment.
Description: Ask for appointment with the doctor.
Precondition: Patient is already logged in.
Normal flow of events:
 Select Ask for appointment.
 The request for appointment is sent to the doctor.
Alternate flow of events: Patient can ask for appointment through Kiosk Manager.
Post condition: Appointment may or may not be approved by doctor.

23
Name of the use case: View Prescription.
Description: View the prescription given by the doctor.
Precondition: Patient is already logged in.
Normal flow of events:
 Select View E-Prescription.
 E-Prescriptions list is displayed.
 Select the E-Prescriptions to be viewed from the list.
 E-Prescriptions is displayed.
Alternate flow of events: None
Post condition: None.

Name of the use case: View Health Record.

Description: View the health record.
Precondition: Patient is already logged in.
Normal flow of events:
 Select View Health Record.
 The Health Record is displayed.
Alternate flow of events: None.
Post condition: None.

24
Name of the use case: Update Health Record.
Description: Update the health record.
Precondition: Patient is already logged in.
Normal flow of events:
 Select Update Health Record.
 Make Changes to the existing health record.
 Updated Health Record is displayed.
Alternate flow of events: None.
Post condition: None.

25
Name of the use case: View Lab Reports.
Description: View the Lab Reports given by the doctor.
Precondition: Patient is already logged in.
Normal flow of events:
 Select View Lab Reports.
 Lab Reports list is displayed.
 Select the Lab Report to be viewed from the list.
 Lab Report is displayed.
Alternate flow of events: None
Post condition: None.

Name of the use case: View Medical Expenses.

Description: View total medical expenses.
Precondition: Patient is already logged in.
Normal flow of events:
 Select View Medical Expenses.
 Medical Expenses are displayed.
Alternate flow of events: None
Post condition: none.

26
Supplementary Requirements:
 Have hours of operation that are 24 x 7 - Because system can be an automated
process, so it can stay open for 24 hours a day. If the base is now the entire world,
staying open 24 hours a day becomes critical. System is required to be available 24X7 so
UPS support must be on server site for at least 8 hours in case of power failure. System
will remain inaccessible to users at 2:00 to 4:00 am for backup and maintenance
purpose.
 Reduce the cost of a sales transaction - To the extent that one can automate the
sales process through this system, one can start to reduce the cost of that sales
transaction. This is particularly true of mundane sales transactions where the customer
knows what they want.
 Make the existing Web site more dynamic in nature - Many early Web
implementations consisted of static HTML pages. This becomes very difficult to manage
if the number of pages gets too large. An effective system should be largely dynamic
taking advantage of technology that automates this process rather than relying on manual
processes. Application should serve dynamic user based customized web pages to its
clients from server.
 Tie the existing Web site into existing enterprise systems – Any existing Web site
that relies on the manual duplication of data from another system is one that can be
improved. Most of the business data in the world today exists in enterprise servers that
can be connected to the Web servers to make this process far more effective.

27