Business Requirements Document

(BRD)

For

Hospital Management System

Version 1.0 [Draft]

Prepared by

N Renuka

Project Sponsor: Mr. Sadiq

Document Number: D-002/HC001/BRD

Version: 1.0

Creation Date: 22th June 2021

Business Requirements Document (v02) HealthCare

Table of Contents
TABLE OF CONTENTS................................................................................................................. 2
1. INTRODUCTION.................................................................................................................... 4
1.1. DOCUMENT PURPOSE.....................................................................................................................4
1.2. INTENDED AUDIENCE.....................................................................................................................4
1.3. PROJECT BACKGROUND.................................................................................................................4
1.4. PURPOSE OF THE BUSINESS REQUIREMENTS.................................................................................5
1.5. BUSINESS GOALS/OBJECTIVES TO BE ACHIEVED...........................................................................6
1.6. BENEFITS.......................................................................................................................................6
1.7. STAKEHOLDERS.............................................................................................................................6
1.8. DEPENDENCIES AND ASSUMPTIONS...............................................................................................6
1.9. REFERENCES..................................................................................................................................6
1.10. ASSUMPTIONS................................................................................................................................7
2. REQUIREMENTS SCOPE..................................................................................................... 7
2.1. TARGETED LANGUAGES OF THE CURRENT SYSTEM.......................................................................9
2.3. INFORMATION ARCHITECTURE (MEDICAL TOURISM PORTAL)......................................................9
2.4. INFORMATION ARCHITECTURE (PORTAL FOR INDIA)..................................................................11
2.5. INFORMATION ARCHITECTURE (ADMIN INTRANET AREA)..........................................................13
3. FUNCTIONAL REQUIREMENTS........................................................................................13
3.1. USER PROFILES SPECIFICATION (APPLICABLE TO TOURIST PORTAL AND PORTAL FOR INDIA). .13
3.2. SMS FUNCTIONALITY..................................................................................................................16
3.3. PMR FUNCTIONALITY.................................................................................................................16
3.4. MAP FUNCTIONALITY / GOOGLE MAP API INTEGRATION........................................................16
3.5. VIRTUAL OFFICE / CLINIC MANAGEMENT APPLICATION..............................................................17
3.6. ADVERTISEMENT / BRANDING / ROTATING BANNER MANAGEMENT............................................19
3.7. JOBS FUNCTIONALITY..................................................................................................................19
3.8. SEARCH / ADVANCE SEARCH.......................................................................................................19
3.9. COMMUNICATION / WORK FLOWS...............................................................................................19
3.10. BUILDING CONSUMER DATABASE................................................................................................20
3.11. MANAGE DATABASE FOR PHARMACISTS/DRUG STORES/ DIAGNOSTICS CENTERS AND LOCATE
THEM IN GOOGLE MAP..............................................................................................................................20
3.12. COMMUNITY SERVICES / CORPORATE SOCIAL RESPONSIBILITY..................................................20
3.13. CONNECT (CONSUMER, SERVICE PROVIDER (DOCTOR, DRUG STORE, DIAGNOSTIC CENTER)....20
3.14. INTERACTIVE FORMS...................................................................................................................20
3.14.1. SERVICE REQUEST..................................................................................................................20
3.14.2. CONTACT US...........................................................................................................................22
3.14.3. FEEDBACK...............................................................................................................................22
3.14.4. PUBLISH BASIC SERVICES (HEALTH TOURIST PORTAL).........................................................23
4. DATA REQUIREMENTS (MEDICAL TOURIST PORTAL).................................................24
4.1. DATA ARCHITECTURE / METADATA............................................................................................24
4.2. Entity Relationship Diagram..................................................................................................26
4.3. DATA VOLUMES..........................................................................................................................27
4.4. DATA RETENTION AND ARCHIVING............................................................................................27
4.5. PRIVACY IMPLICATIONS...............................................................................................................27
4.6. DATA DEFINITION REPORTS........................................................................................................28
4.6.0. Entity Definition Report.........................................................................................................28
5. DATA REQUIREMENTS (PORTAL FOR INDIA)................................................................29
5.1. DATA ARCHITECTURE / METADATA (FOR PORTAL IN INDIA).....................................................29

Last revised: Page 2 of 34

Business Requirements Document (v02) HealthCare

5. SECURITY REQUIREMENTS............................................................................................. 29
5.1. AUTHENTICATION........................................................................................................................29
5.2. AVAILABILITY REQUIREMENTS...................................................................................................30
5.3. USABILITY REQUIREMENTS.........................................................................................................31
5.4. SYSTEM HELP REQUIREMENTS....................................................................................................31
5.5. PERFORMANCE REQUIREMENTS...................................................................................................32
5.6. SCALABILITY REQUIREMENTS.....................................................................................................32
5.6.1. User Scalability......................................................................................................................32
5.6.2. Application Scalability...........................................................................................................32
6. INTERFACE REQUIREMENTS...........................................................................................32
6.1. USER INTERFACE REQUIREMENTS...............................................................................................32
6.2. SYSTEM INTERFACE REQUIREMENTS...........................................................................................33
7. PROJECT PLAN AND DELIVERY SCHEDULE.........................................................................34
7.1 PROJECT SCHEDULE.......................................................................................................................34
7.2 PROJECT SCHEDULE..........................................................................................................................34
8. COMMUNICATION PLAN....................................................................................................... 35
8.1 PROPOSED COMMUNICATION PLANS.................................................................................................35
8.2. PROJECT TEAM..............................................................................................................................35
8.3. ESCALATION POINTS....................................................................................................................35
REVISION LOG............................................................................................................................ 36
APPENDICES.............................................................................................................................. 36
Approval........................................................................................................................................ 37

Last revised: Page 3 of 34

Business Requirements Document (v02) HealthCare

1. Introduction

1.1. Document Purpose

The purpose of this document is to describe business requirements of Healthcare portal

completely, accurately and unambiguously in Technology-independent manner. This is to
collect and analyse all sorted ideas that have to come up to define the system and its
requirement with respect to consumer.All attempts have been made in using mostly business
terminology and business language while describing the requirements in this document. Very
minimal and commonly understood Technical terminology is used. Use case / Designer
approach is used in modeling the business requirements in this document.

1.2. Intended Audience

The main intended audience for this document are the business owners of the proposed
system. This document should be readable by business owners of the proposed system.
They must be able to verify that their business requirements have been documented here
completely, accurately and unambiguously.

Data Architects, Application Architects and Technical Architects would also find the
information in this document useful when they need to design a solution that will address
these business requirements.

Since the requirements are documented here in Technology-independent manner, the end-
users of the system should be able to comprehend the requirements fairly easily from this
document.

1.3. Project Background

The Mayo Clinic is an American nonprofit academic medical center currently based in three major
locations, Rochester, Minnesota; Jacksonville, Florida; and Scottsdale, Arizona focused on
integrated patient care, education, and research. Mayo Clinic holds the number 1 rank among
hospitals in the United States.
The 1980s initiated transformative changes that set the course for the modern Mayo Clinic. As an
early adopter of the Internet, Mayo Clinic has been recognized for its online communications to
patients.
Note: Hospital Management System is hereby referred to as HMS.
HMS is designed to store patient records, show availability of beds, manage patients’ billing,
scheduling a doctor’s appointment, and will bring about coordination among the different
departments.
Mayo clinic HMS is an internet web portal to provide medical services to the people of USA and
build a database of Clinic, Patient, Staff, Doctors and Facilities provided by Clinic.

Last revised: Page 4 of 34

Business Requirements Document (v02) HealthCare

1.4. Purpose of the Business Requirements

This section describes the purpose of the Business Requirements.

Business requirements for major enhancements to an existing

application.
Business requirements for new application development.

Business requirements for replacement application development.

Business requirements for a request for proposals (RFP).

Last revised: Page 5 of 34

Business Requirements Document (v02) HealthCare

1.5. Business Goals/Objectives to be achieved

The objective of this portal is to provide health care service to the public of USA. Also
a database of Doctors, Clinics and facilities would help common people to search and get
right treatment. People would have an opportunity to check various alternates available to
them and compare price of one with the other.
The business requirement will be revised as and when required through out the
implementation phase of project to reflect the changing requirements and agreed
solution. It will take the form of a controlled document to ensure sign-off and
approval/process are maintained.

1.6. Benefits

 Reduce operating costs of the hospital.

 Provide reports to senior management for better decision-making.
 Saves patients’ time by making the appointment before hand.
 Keeps patients’ medical records, staff records secure and stored in cloud.
 Keeps track of empty and filled beds in the hospital.
 Easy access to patient data.
 Reduces documentation in the hospital.

1.7. Stakeholders

 Project sponsors
 Doctors
 Patients
 Web-site visitors
 Pharmaceutical Companies
 Diagnostic Centers
 Nurse/Mid Wives
 Insurance companies

1.8. Dependencies and Assumptions

1.9. References

Project Charter Ver.02

Last revised: Page 6 of 34

Business Requirements Document (v02) HealthCare

1.10. Assumptions

This section describes major assumptions that were made prior to or during the Business
Requirements gathering and documentation.

2. Requirements Scope

This section shows what business functionality is in scope and out of scope for Implementation.
In Use case approach, the out of scope Use cases are indicated in a separate boundary box. In
Oracle Designer approach the out of scope Functions are shown in grey coloured boxes.

1. Public facing websites (Health tourist portal and Indian portal) should have world
class design templates.

Functionally there are two separate public facing websites. One is to promote health
tourists and the other is for In

2. Content of the website would change depending upon the targeted audience and
managed through country IP (i.e. different look and feel for USA and Indian visitors).
Virtually it is two different websites.
3. All the contents are to be managed through a password protected admin intranet (to
publish formatted text, images, videos
4. Admin intranet will have various user level to access/not to have access to certain data
5. Publish basic services – identified in the 1st phase (non life risk medical tourists)
6. Publish ancillary services (Visiting places, hotels etc.)
7. Customer can compare services and pricing on the portal
8. Customer can submit an enquiry form which is considered to be a business lead
9. All the communication with the customer should be managed through the admin intranet
10. Extensive search facility (simple and advanced search)
11. Integration with Google Map API (Should be the first of its kind information) Facility to
update by the individual visitor like updating address/location in the Google map.
12. Jobs section (Post jobs, Search jobs related to healthcare services)
13. Branding and advertising by various service providers (Listing of hospitals/clinics, Listing
of doctors, Pharmaceutical companies, New product releases, related services like
Ambulance, Suppliers etc.)
14. Virtual office for Doctors – Online appointment, sync calendar in smart phones (This may
attract some Doctors to be part of this initiative).
15. Clinic management software – SaaS software to manage small clinic/independent
doctors
16. Building consumers database which would help in the future to market
17. News feeds
18. Email integration
19. SMS integration
20. Community services/Corporate Social Responsibility (If the customer is poor and could
not locate a doctor, we will help them locating right doctor)
21. PMR (Personal Medical Record)
22. Manage data bases of Pharmacists/Drug stores and locate them in Google Map
23. Connect (Consumer, Service providers (Doctors, Drug stores, Diagnostic centers etc..)

1. Website.

Last revised: Page 7 of 34

Business Requirements Document (v02) HealthCare

The website contains a home page describing the purpose and navigational links to other
sections. Each navigation link takes the web site visitor to a separate page. Some pages like
(About us, Services, Contact us, Why we) and navigations links described in the respective
IA.

Typical Website flow – Tourist portal:

Login
About us

Services
How will it
Benefit me?
Contact

Latest News

Testimonials

Contact Sales

Last revised: Page 8 of 34

Business Requirements Document (v02) HealthCare

2.1. Targeted Languages of the current system

The public facing website of the Health tourist portal contents to be available in the
following languages:

i. English
ii. Spanish

English is the default language when website is open. There would be an option where
user can change the language.

All options, menus, titles, labels and on-screen messages are to be changed to
“Spanish” when the user select language option.

It should be an easy to use admin interface to create/update language equivalents for all
relevant sections.

English is the primary language for the Indian portal.

2.3. Information Architecture (Medical Tourism Portal)

Last revised: Page 9 of 34

Business Requirements Document (v02) HealthCare

Website Layout (Medical tourist portal)

Logo
Logo Live
Live Chat
Chat section
section
Website name/title

Banner section to explain the Website / services features

1 2 3 4

Visiting Places in Compare services section

India

Service categories section

Client testimonials

Latest News

Copyright _____ Privacy | Disclaimers | Terms of use

Last revised: Page 10 of 34

Business Requirements Document (v02) HealthCare

2.4. Information Architecture (Portal for India)

Last revised: Page 11 of 34

Business Requirements Document (v02) HealthCare

Website Layout (Portal for India)

Logo
Logo Website name/title Space for Ad. banner Live
Live Chat
Chat
section
section

Hospitals
Hospitals Clinics
Clinics Diagnostics
Diagnostics Doctors
Doctors Jobs
Jobs

Space for new

Search Here Submit
Submi products released

Ex. General Physician in Hyderabad, Abids Switch to Advance Search

Space for displaying comparisons

Copyright _____ Privacy | Disclaimers | Terms of use

Last revised: Page 12 of 34

Business Requirements Document (v02) HealthCare

2.5. Information Architecture (Admin Intranet Area)

3. Functional Requirements

3.1. User Profiles Specification (Applicable to Tourist portal and

Portal for India)

This section describes all the Actors and their profiles within the context of the Business
Requirements being documented. An Actor is a person, organization or an external
system/sub-system/program that has interactions with the Application. Actors, by definition,
are external to the system with which they are having interactions. Actors have goals that are
achieved by use cases. Typically, Actors have behaviour and are represented by the roles
they play in the use cases. An Actor stimulates the system by providing input and/or receiving
something of measurable value from the system.

Last revised: Page 13 of 34

Business Requirements Document (v02) HealthCare

Super Admin User:

Super Admin user has control over the complete system and can manage to create other
users, groups, privileges and required master data.

The functionality of the complete application is modularized and access to each module
is set by the application’s access control matrix.

Typical user access control matrix:

Roles --> Admin

  Add Edit Del View
Manage Groups Y Y Y Y
Manage Users Y Y Y Y
Manage Business
parameters Y Y Y Y

Super admin can inactivate certain Groups/Users/Features for some reason before
deleting permanently. The user having admin privilege can activate or inactivate a record.

A data view list can have the option to see Active and Inactive records.

Accesses to individual activity are fixed as per the user classification and role.

Super
Super Admin
Admin
User
User

User
User Name
Name

Password
Password

OK Cancel

Group
Group and
and User
User Manage
Manage Business
Business Content
Content Client
Client relationship
relationship Communication
Communication
Management
Management Parameters
Parameters Management
Management management
management Management
Management

Last revised: Page 14 of 34

Business Requirements Document (v02) HealthCare

Administrator:

Administrator is another user who inherits some controls from the super admin to perform certain
activities. Generally admin user has all the rights of “Add/Edit or Delete a record. There can be
multiple admin users.

Content Developer:

Content developer is another user who generally create new contents/edit the content but does
not have right to delete permission. Content created or edited would not be published until it is
has be reviewed or approved by the Publisher.

Content Publisher:

Content publisher will review, approve or disapprove any content to be published in the public
area.
Website Visitor:
Any website visitor will have access to all the public contents published in the website. Website
visitor can search and consume all services which are set as free services.

Registered User:

Registered users will have privileges to access certain private data and communicate with the
service providers.

Customer:

Customer is a user who would have access to paid services.

Last revised: Page 15 of 34

Business Requirements Document (v02) HealthCare

3.2. SMS Functionality

a. Able to configure at least 3 service providers API for sending SMS.

b. Able to send bulk SMS by the website admin/users to the various stake
holders.
c. Able to configure in the Admin internet to send SMS for various activities
(Example a new lead is received, confirmation to customer that his enquiry is
recorded etc..)
d. Registered users / customers can send SMS after login
e. Able to allocate number of SMSs a customer can avail free and subscribe for
more SMSs (mostly applicable for virtual office and releasing new products)

3.3. PMR Functionality

a. Able to update demographics / personal records

b. Able to update demographics of the family members
c. Able to update Doctors information
d. Able to upload prescriptions (as attachments)
e. Able to update prescriptions as text
f. Able to setup medication
g. Able to setup alerts (Email and SMS) with regard to regular checkups,
medicine and doses
h. Able to share medical records with the doctor for a particular period with
permissions (View only / View and Download)

3.4. MAP Functionality / Google MAP API integration

a. Able to locate Doctors, Hospitals, Clinics, Drug Stores, Diagnostic Labs on a

MAP.
b. Display different icons for each category of information.
c. Icons are updated through Admin intranet for each category of information.
d. Able to display more information through a call-out when user point on a
particular icon.
e. Able to view more information in a separate page when user opted to know
more about selected information.
f. User can able to submit feedbacks to the site owner for any selected
information.
g. User can able to report any errors to the site owner for any selected
information.
h. The feedbacks / errors reported by the users are emailed/sms to the
respective site admin/user.
i. The feedback / reported errors are stored in the admin intranet.
j. The user is reported back when the corrections are done or feedback are
acknowledged.
k. Visitors can add a location (Doctor/Hospital/Clinic/Medical store/Diagnostics)
if they feel so by filling a small form. The Latitude and Longitude should be
picked up automatically.
l. The information submitted are stored separately for the admin to review and
approve or disapprove.

Last revised: Page 16 of 34

Business Requirements Document (v02) HealthCare

m. A message email/sms sent to the user who submitted when the admin
approve / disapprove. If the admin disapprove the reason should be filled and
intimated.

3.5. Virtual office / Clinic management application

a. Application is based on SaaS (Software as a service) model

b. Able to provide a separate area for each customer (Doctor/clinic) and
accessed through a user name and password
c. Each customer can sign-up to avail this facility
d. Customer can opt-out this service by sending an email/calling to a site admin
/ support request.
e. Admin can activate / inactivate this service for a customer
f. Following are the facilities included in the Virtual office:
a. Customer (Doctor/Clinic) update their place of availability, timings for
a particular period (Day, Time, Not available time etc..)
b. Visitors (Patients) can view the calendar or schedule an appointment
c. Customer to view the calendar and list of appointments
d. Customer can accept / reject one or all appointments for a day or
period
e. Information goes to the patients when Doctor/Clinic accepted or
rejected an appointment by email / sms
f. Record/update patient visits
g. Able to generate a bill for the services
h. Able to write a prescription for the patient
i. Able to generate a medical certificate for the patient
j. Able to recommend/order a diagnostics

g. SaaS Architecture

1. Fully Shared DB Per Tenant

Last revised: Page 17 of 34

Business Requirements Document (v02) HealthCare

The proposed application should be deployed on SaaS platform. The application should take care
of the following while designing the application.

 Performance
 Security
 Reliability
 Customization
 Integration
 Scalability
 Multi tenancy

There are two layers. DB layer and Application Layer. Organization ID is the key for all database
tables (Master and transaction). Data is accessed from the application by providing Organization
ID.

Every user is associated with an organization id. An organization can have many users. User ID
is unique throughout the database.

There are two databases; one to store all data related to user, contains (username, password,
organization id) for authentication and the other is database contains data related to application.

Last revised: Page 18 of 34

Business Requirements Document (v02) HealthCare

GUID is used for organization id. Multiple organization data can reside in a single database or
multiple of databases.

3.6. Advertisement / branding / rotating banner management

a. Able to define the ad placements in various pages

b. Able to define price for ad placements (ad size / duration / price)
c. Able to update/upload ad content for a location with priority, number of
impressions, time period etc..
d. Able to manage the ad banners and content through admin area

3.7. Jobs functionality

a. Able to search job openings by enter search text, experience/location.

b. Able to respond/send resume for a job directly after login
c. Able to publish list of recent jobs by function and location
d. Able to publish top 10 employers with their logos. Display list of current job
openings.
e. Able to register and upload resume by the job seekers
f. Able to login and update resume by the job seekers
g. Employers to register and update job openings
h. Employer login and search resumes
i. Down load matching resumes for a particular post
j. Email to job seeker when a new matching job is updated by the employer
k. Email to employer when a new matching resume is updated by a job seeker.
l. Block resumes to be viewed by certain companies (by entering key words of
the companies) by the job seeker for managing privacy

3.8. Search / Advance search

a. Basic search should work like Google search with suggestions

b. User can shift to advance search and search through selecting filters and
criteria

3.9. Communication / Work flows

a. The visitors to the website should able to communicate with the site admin /
service providers by filling pre-defined forms.
b. A confirmation message should be sent to the person who submitted by
email as a copy for hi/her record.
c. Apart from saving data in a database table which can be accessed through
admin intranet; all information should be sent to respective site user / service
provider depending on the kind of service request.
d. Work-flows are defined in the admin intranet (i.e. mail to whom, access to
whom)

Last revised: Page 19 of 34

Business Requirements Document (v02) HealthCare

3.10. Building consumer database

a. Consumers are the users who search/seek various services and submits
request for services in various forms. Registered / non registered users.
b. All the information are to be compiled and categorized for future services like
(when new product / services are released.)
c. Able to attract consumer to register to get value added services.

3.11. Manage database for Pharmacists/Drug stores/ Diagnostics

centers and locate them in Google Map

a. Able to search and locate a drug store / diagnostic services

b. Able to compare prices for different tests between the diagnostic centers in a
particular locality.

3.12. Community services / Corporate social responsibility

a. People register as service provider / volunteer to extend their services.

b. People request to for services (Example: Looking for help to locate a doctor
for a particular disease, Looking for help.
c. Able to connect between the service providers with service seekers

3.13. Connect (Consumer, Service provider (Doctor, Drug store,

Diagnostic center)

a. Able to create a platform to connect between the consumer and service

provider and bring them into to a common platform.
b. The information should be flashed to nearest Diagnostics center when Doctor
prescribes tests.
c. Consumer / Patient can compare price for different tests

3.14. Interactive Forms

3.14.1. Service Request

Use Case Name Submitting online form

Description Submitting online form in the website

Actors Prospective medical tourist (Customer)

Business Rules 1. Form can be submitted only after the user

complete filling all the required data.
2. User can switch to detailed form / provide
more information if he/she willing to
provide at that moment by expanding
section of the form.

Last revised: Page 20 of 34

Business Requirements Document (v02) HealthCare

Basic Flow Alternate Flows

1. On screen thank you message. 1. The service request form can be
2. Email confirmation to the customer’s submitted (after censoring) directly to the
email address as a copy of the affiliate hospitals (Service providers) to
information submitted. submit their quotes.
3. Email notification to the business 2. The business head/concerned executive
head/concerned executive. will review and submit the form to Service
4. Save data in the database for providers.
reporting

Last revised: Page 21 of 34

Business Requirements Document (v02) HealthCare

3.14.2. Contact us

Use Case Name Submitting contact us form

Description Submitting online form in the website

Actors Prospective medical tourist (Customer)

Website visitors
Prospective service providers (Wanted to list in
the portal)

Business Rules 1. Form can be submitted only after the

user complete filling all the required
data.

Basic Flow Alternate Flows

1. On screen thank you message.
2. Email confirmation to the email
address provided as a copy of the
information submitted.
3. Email notification to the business
head/concerned executive.
4. Save data in the database for
reporting

3.14.3. Feedback

Use Case Name Submitting feedback online

Description Submitting an online form in the website

Actors Website visitors

Business Rules 2. Form can be submitted only after the

user complete filling all the required
data.

Basic Flow Alternate Flows

1. On screen thank you message.
2. Email confirmation to the email
address provided as a copy of the
information submitted.
3. Email notification to the business
head/concerned executive.
4. Save data in the database for
reporting

Last revised: Page 22 of 34

Business Requirements Document (v02) HealthCare

3.14.4. Publish Basic Services (Health Tourist Portal)

The content is managed in the admin section and published in the home page and
services section.

User can explore to know more information (i.e. List of service providers, their facilities,
pricing etc) on selecting a particular service.

Also, user can compare price between service providers for a selected service category.

Last revised: Page 23 of 34

Business Requirements Document (v02) HealthCare

4. Data Requirements (Medical tourist portal)

The content and data required for the portal is collected from various sources and updated
through the admin control panel by the authorized users. The content/data published only after it
has been verified and approved by the publisher.

Initially all the relevant data updated by the portal administrator and progressively an
extranet system can be developed which would enable the service provider to update data
through secure login.

1. Core services – Information about various hospitals / clinics, their services, facilities,
pricing etc.
2. Ancillary services
a. Information about various tourist places
b. Information about hotels
c. Information about travels
3. Other services – Related news and updates

4.1. Data Architecture / Metadata

1. Information about a Hospital/Clinic

i. Name and address
ii. Contact telephones
a. General
b. Emergency
c. Each specialization
iii. Emails
iv. Location and direction
v. Photos
vi. Specialities / Service catalogue
vii. Achievements
viii. Testimonials
ix. Facilities
a. Pharmacy
b. Canteen
c. Diagnostics
x. Infrastructure
a. Major equipments
b. Make
c. Photos
xi. OTs
a. Type
b. Special about theatre
c. Photos
xii. Doctors
a. Name and contacts
b. Specialization
c. Experience
d. Achievements
e. Testimonials

Last revised: Page 24 of 34

Business Requirements Document (v02) HealthCare

2. Information about a Visiting/Historical place

i. Name
ii. Short description
iii. Address/Location
iv. Importance
v. Photographs

3. Information about a Hotels

i. Name
ii. Short description
iii. Address/Location
iv. Tariff
v. Photographs
4. Information about a Travel
i. Name
ii. Short description
iii. Address/Location
iv. Tariffs

5. News Feeds
i. Integrate with related news feeds
ii. Create an interface to upload news
iii. News title
iv. Date
v. Source
vi. Text
vii. images

6. Corporate contents (CMS)

i. About us
a. Text
b. Photos
ii. Services
a. Service category
b. Service description
c. Photos
iii. Why we
a. Text
b. Photos
7. FAQs (CMS)
i. Question
ii. Answer

8. Service wise price comparison

i. Service category
ii. Service description
iii. Price in US$
iv. Other charges if any US$

4.2. Entity Relationship Diagram

Last revised: Page 25 of 34

Business Requirements Document (v02) HealthCare

4.3. Data Volumes

Health Tourist Portal:

Initial 10 GB including images and annual growth could go up to 10%

Portal for India:

Initial 20 GB including images and annual growth could go up to 20%

4.4. Data Retention and Archiving

This section describes the Data retention (time frames for online Data retention before
archiving) and also the archiving requirements.

4.5. Privacy Implications

This section describes the sensitivity levels of each class of data. The following criteria are
used in determining the sensitivity level of each conceptual class/entity in line with the
Government Core Policy Manual).

 Non-sensitive information that would not reasonably be expected to cause injury (harm)
if released to the public;

 Protected A: information that, if compromised, could reasonably be expected to cause

injury (harm), e.g. loss of privacy;

 Protected B: information that, if compromised, could reasonably be expected to cause

serious injury (harm), e.g. the conduct of a court proceeding would be adversely affected;

 Protected C: information that, if compromised, could reasonably be expected to cause

extremely grave injury (harm), e.g. loss of life.

Last revised: Page 26 of 34

Business Requirements Document (v02) HealthCare

4.6. Data Definition Reports

4.6.0. Entity Definition Report

This section is applicable only to Oracle Designer approach. This section describes Data
Architecture / definition (Entity Relationship model) in narrative text form.
Entity Name

Entity Description

Initial Data Volume (approx.)

Annual Data growth rate (in approx. %)

Attributes (fields) of the Entity Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :

Last revised: Page 27 of 34

Business Requirements Document (v02) HealthCare

5. Data Requirements (Portal for India)

The content and data required for the portal is collected from various sources and updated
through the admin control panel by the authorized users. The content/data published only after it
has been verified and approved by the publisher.

Initially all the relevant data updated by the portal administrator and progressively an
extranet system can be developed which would enable the service provider to update data
through secure login.

1. Core services – Information about various Hospitals, Clinics, Doctors, Diagnostic, Facilities
provided by them and pricing etc.
2. Ancillary services
Jobs
New product releases
Advertisement
3. Other services – Related news and updates

5.1. Data Architecture / Metadata (for Portal in India)

5. Non-Functional Requirements

5.1. Security Requirements

o The system shall automatically logout all customers after the period
of inactivity
o The system shall confirm all the transactions with customer’s web
browser
o The system shall never display a customer’s password. It shall
always be echoed with special characters
o The system shall never display a customer’s credit card number. It
shall always show up the last 4digit number
o The system backend server shall only be accessible to
authenticated administrators.

5.2. Availability Requirements

o The system is available over the net. In case of any breakdown, appropriate
message needs to be flashed.

o The system is available all the time.

o Response to user query within 24 hours.

Last revised: Page 28 of 34

Business Requirements Document (v02) HealthCare

5.3. Usability Requirements

o The Screens should be self explanatory and very user friendly and should
provides better user experience

5.4. Performance Requirements

o Capacity: The system must be able to support minimum of 500 user accessing
simultaneously.
o Response Time: The maximum allowable wait time from the moment the user
submits a request until the system comes back with a response should not go
beyond 1 second.
o User Interface: The system shall take the initial load time depending on the
internet connection strength.

6. Interface Requirements

This section describes User and System Interface requirements for the proposed system.

6.1. User Interface Requirements

Browser compatibility

The website should support all major browsers of the current version and one version
down.

1. IE
2. Fire Fox
3. Mozilla (Mac)
4. Chrome

Data display

The content presented in the portal would be designed professionally like any world class
website. The data can be presented in List view/Form view to the stakeholders in their
respective area.

Drop-down list

Data consistency is maintained through selecting choices from drop down list. The
application should enable each customer to add their new choices.

The master drop down list is managed through the Admin area. When a customer
register, set of master data (pre-requisites) are available for them. This would help them

Last revised: Page 29 of 34

Business Requirements Document (v02) HealthCare

to start using the application instantly. Also, each registered customer can manage their
own master data (add/edit/delete).

Saving report as PDF file.

Facilitates to save a report in PDF format

Web 2.0 features

Website / Application to be built on Web 2.0 features. Page re-loading / refresh to be

avoided completely.

6.2. System Interface Requirements

Last revised: Page 30 of 34

Business Requirements Document (v02) HealthCare

7. Project Plan and Delivery Schedule

7.1 Project Schedule

SL Task Start Finish Duration

1 Definition
System Design
Detailed Design
Development
Integration Testing
Deployment
UAT
Bug fixing
Go Live

7.2 Project Schedule

Phase Milestone Deliverable

Requirement Definition BRD Signoff Business Requirement

Document

Prototyping /Wire framing / Layout design sign-off and PDS, html and CSSs
Portal layouts Wireframe Signoff
Prototype for the proposed
application

System Design Completion of Design Design document containing

Document flows, validations, inputs and
outputs.
Database design

Development, Integration and Beta Release of the site for Beta version (Tested fully)
Testing UAT

Deployment and Go Live Final Signoff Source Code for the

application hosted on live
environment. Source code
documentation and User
guide.

Support Closing Fix bugs

Last revised: Page 31 of 34

Business Requirements Document (v02) HealthCare

8. Communication Plan
8.1 Proposed Communication Plans
 Daily call
 Weekly review meeting would be held on a prescheduled day (______) and time.
 Regular communication would be done through emails, phone and WebMeeting with
email would be the most frequent communication medium
 Extranet portal (Basecamp) created for the project would be the platform through which
the project related documents, minutes of the meeting are shared. The tasks assigned for
the team members are presented and tracked through the portal
 Weekly status report should be shared with Client through email and also posted to the
extranet portal by end of the week.

8.2. Project Team

SL Name Role Organization Contact No E-mail address

8.3. Escalation Points

SL Name Designation Organization Contact No E-mail address

Last revised: Page 32 of 34

Business Requirements Document (v02) HealthCare

Revision Log

Date Version Change Reference Reviewed by

25th Oct 2010 01-Draft

26th Oct 2010 02-Draft List of Functionality included for Indian Portal
1. Community /Corporate Social Responsibility
2. PHR (Personal Health Record).
3. Manage data bases of Pharmacists/Drug
stores and locate them in Google Map

6th Nov 2010 02-Draft 1. Scope is explained and expanded

2. SaaS architecture diagram is depicted
3. Connect functionality is included

Appendices

Enter content here.

Last revised: Page 33 of 34

Business Requirements Document (v02) HealthCare

Approval
This document has been approved as the official Business Requirements Document for
the HealthCare project.
Following approval of this document, changes will be governed by the project’s change
management process, including impact analysis, appropriate reviews and approvals,
under the general control of the Master Project Plan and according to Project Support
Office policy.

Prepared by Signature Date

Author's Name
[Title]
[Organization]
Approved by Signature Date

[Client Acceptor’s Name]

[Title]
[Organization]

Last revised: Page 34 of 34