Healthcare Project BRD

Business Requirements Document
(BRD)
for
Healthcare Portal
Version 2.0 [draft]
Prepared !
Pro"ect #ponsor$ Mr. Sadiq
Document %umer$ D&002/HC001/BRD
Version$ 0.2
'ast (pdated$ )
th
%o*emer 20+0
,reation Date$ ++
th
-ctoer 20+0
Business Requirements Document (v02) HealthCare
.ale of ,ontents
./B'0 -1 ,-%.0%.# ................................................................................................................. 2
+.2%.R-D(,.2-% ......................................................................................................................... 3
DOCUMENT PURPOSE ........................................................................................................................................ 4
INTENDED AUDIENCE ........................................................................................................................................ 4
PROJECT BACKGROUND ..................................................................................................................................... 4
PURPOSE OF THE BUSINESS REQUIREMENTS .......................................................................................................... 5
BUSINESS GOALS/OBJECTIVES TO BE ACHIEVED .................................................................................................... 6
BENEFITS/RATIONALE ....................................................................................................................................... 6
STAKEHOLDERS ................................................................................................................................................ 6
DEPENDENCIES ON EXISTING SYSTEMS .................................................................................................................. 7
REFERENCES .................................................................................................................................................... 7
ASSUMPTIONS .................................................................................................................................................. 7
R04(2R050%.# #,-P0 ............................................................................................................. 6
TARGETED LANGUAGES OF THE CURRENT SYSTEM ............................................................................................ !
INFORMATION ARCHITECTURE "MEDICAL TOURISM PORTAL# ................................................................................ !
INFORMATION ARCHITECTURE "PORTAL FOR INDIA# ............................................................................................. $
INFORMATION ARCHITECTURE "ADMIN INTRANET AREA# .................................................................................... 4
1(%,.2-%/' R04(2R050%.# ................................................................................................. +3
USER PROFILES SPECIFICATION "APPLICABLE TO TOURIST PORTAL AND PORTAL FOR INDIA# ..................................... 4
SMS FUNCTIONALITY .................................................................................................................................... 7
PMR FUNCTIONALITY .................................................................................................................................... 7
MAP FUNCTIONALITY / GOOGLE MAP API INTEGRATION ................................................................................. 7
VIRTUAL OFFICE / CLINIC MANAGEMENT APPLICATION .......................................................................................... %
ADVERTISEMENT / BRANDING / ROTATING BANNER MANAGEMENT ........................................................................... $!
JOBS FUNCTIONALITY ....................................................................................................................................... $!
SEARCH / ADVANCE SEARCH ............................................................................................................................ $!
COMMUNICATION / &ORK FLO&S ..................................................................................................................... $!
BUILDING CONSUMER DATABASE ....................................................................................................................... $
MANAGE DATABASE FOR PHARMACISTS/DRUG STORES/ DIAGNOSTICS CENTERS AND LOCATE THEM IN GOOGLE MAP . . . $
COMMUNITY SERVICES / CORPORATE SOCIAL RESPONSIBILITY ................................................................................ $
CONNECT "CONSUMER' SERVICE PROVIDER "DOCTOR' DRUG STORE' DIAGNOSTIC CENTER# ....................................... $
INTERACTIVE FORMS ....................................................................................................................................... $
SERVICE REQUEST .......................................................................................................................................... $
CONTACT US ................................................................................................................................................. $(
FEEDBACK ..................................................................................................................................................... $(
(...PUBLISH BASIC SERVICES "HEALTH TOURIST PORTAL# ............................................................................... $4
D/./ R04(2R050%.# (50D2,/' .-(R2#. P-R./') .......................................................... 27
DATA ARCHITECTURE / METADATA .................................................................................................................. $5
Entity Relationship Diagram ................................................................................................................ 27
DATA VOLUMES ............................................................................................................................................ $%
DATA RETENTION AND ARCHIVING ................................................................................................................... $%
PRIVACY IMPLICATIONS ................................................................................................................................... $%
DATA DEFINITION REPORTS ............................................................................................................................. $)
Entity Definition Report ........................................................................................................................ 29
D/./ R04(2R050%.# (P-R./' 1-R 2%D2/) ......................................................................... 80
DATA ARCHITECTURE / METADATA "FOR PORTAL IN INDIA# ................................................................................ (!
Last revised: Page 2 of !
#0,(R2.9 R04(2R050%.# ...................................................................................................... 80
AUTHENTICATION ........................................................................................................................................... (!
AVAILABILITY REQUIREMENTS ......................................................................................................................... (
USABILITY REQUIREMENTS .............................................................................................................................. ($
SYSTEM HELP REQUIREMENTS ......................................................................................................................... ($
PERFORMANCE REQUIREMENTS ........................................................................................................................ ((
SCALABILITY REQUIREMENTS ........................................................................................................................... ((
User Scalability .................................................................................................................................... 33
Application Scalability .......................................................................................................................... 33
2%.0R1/,0 R04(2R050%.# ................................................................................................... 88
USER INTERFACE REQUIREMENTS ...................................................................................................................... ((
SYSTEM INTERFACE REQUIREMENTS .................................................................................................................. (4
PR-:0,. P'/% /%D D0'2V0R9 #,H0D('0 .......................................................................... 87
7. PROJECT SCHEDULE .................................................................................................................................. (5
7.$ PROJECT SCHEDULE .................................................................................................................................. (5
,-55(%2,/.2-% P'/% ............................................................................................................ 8)
%. PROPOSED COMMUNICATION PLANS ............................................................................................................ (6
PROJECT TEAM ............................................................................................................................................. (6
ESCALATION POINTS ....................................................................................................................................... (6
R0V2#2-% '-; ............................................................................................................................ 86
/PP0%D2,0# .............................................................................................................................. 86
/PPR-V/' .................................................................................................................................. 8<
Last revised: Page of !
+. 2ntroduction
Document Purpose
The purpose of this document is to describe business requirements of Heathcare porta
compete!" accurate! and unambi#uous! in Technoo#!$independent manner. % attempts
ha&e been made in usin# most! business terminoo#! and business an#ua#e 'hie
describin# the requirements in this document. (er! minima and common! understood
Technica terminoo#! is used. (se case / Desi=ner approach is used in modein# the
business requirements in this document.
2ntended /udience
The main intended audience for this document are the business o'ners of the proposed
s!stem. This document shoud be readabe b! business o'ners of the proposed s!stem.
The! must be abe to &erif! that their business requirements ha&e been documented here
compete!" accurate! and unambi#uous!.
Data %rchitects" %ppication %rchitects and Technica %rchitects 'oud aso find the
information in this document usefu 'hen the! need to desi#n a soution that 'i address
these business requirements.
Since the requirements are documented here in Technoo#!$independent manner" the end$
users of the s!stem shoud be abe to comprehend the requirements fair! easi! from this
document.
Pro"ect Bac>=round
Medica tourism industr! in )ndia is #ro'in# rapid! and this industr! is estimated at Rs. 1"*+0
cores ,Source- )ndian ./press. Tue 0ct 0+ 2010 http-//'''.indiane/press.com/ne's/$$C12$
'indfa$a'aits$medica$tourism$$/3*2*+044
5or )ndian doctors" 'estern shores coud be #reener. But for an increasin# number of forei#n
patients" )ndian hospitas are fast becomin# their first choice. 0&er 1.+ a6h medica tourists
tra&eed to )ndia in 2002 aone" brin#in# in earnin#s of 7800 miion.
Since then" the number of such tra&eers has been increasin# b! at east 2+9 e&er! !ear. %
C))$Mc:inse! report pro;ects that earnin#s throu#h medica tourism 'oud #o up to 72 biion
b! 2012. ,Source- Times of )ndia. %pr <" 200=
http-//timesofindia.indiatimes.com/india/Medica$tourism$boomin#$in$
)ndia/articesho'/2*2<2+2.cms4
>eope rush to )ndia for treatment because it is 8+ to <09 esser than the treatment cost in
?S%. )t is not ;ust cost" )ndia has #ot speciaist around the 'ord and 'ord eminent
Doctors/Hospitas 'here there to pro&ide a ser&ices to the patient. .n#ish spea6in# is
another ad&anta#e 'here patients can address/communicate 'ithout an! difficuties.
Last revised: Page " of !
)ndia is one of the most fa&orabe tourist destinations in the 'ord. Medica treatment
combines 'ith tourism 'oud #i&e an added ad&anta#e to the customer.
There are treatments i6e denta and cosmetic sur#er! 'hich are cate#ori@ed as non$ife
threat are most! not co&ered under the heath insurance. These treatments are char#es
e/orbitant
price in ?S%. % person can #et 'ord cass treatment in )ndia and 'oud i6e to ta6e
ad&anta#e of )ndiaAs ancient tradition and e/pore &arious paces and sti sa&e hu#e sum.
B%BCC heathcare is an internet 'eb porta to pro&ide not$heath ris6 medica tourism
ser&ices to the peope of ?S% and buid a database of Hospitas" Cinics" Doctors and
5aciities pro&ided b! each Hospita/Cinic in )ndia.
The porta 'oud potentia! #o' and come to fu bo'n ser&ices in due course of timeD
ho'e&er to start 'ith it is tar#eted to pro&ide medica tourism ser&ices i6e Denta and
Cosmetoo#!. To'ards buidin# of database" can start 'ith ma;or metropoitan cities i6e
H!derabad" Ben#auru" Dehi" Mumbai" :o6ata" Chandi#arh" Chennai" >une" %hmedabad"
2oa and consider to be phase$1 of the pro;ect.
Purpose of the Business Requirements
This section describes the purpose of the Business Requirements.
Business requirements for ma;or enhancements to an e/istin# appication.
Business requirements for ne' appication de&eopment.
Business requirements for repacement appication de&eopment.
Business requirements for a request for proposas ,R5>4.
Last revised: Page # of !
Business ;oals?-"ecti*es to e achie*ed
The ob;ecti&e of this porta is to attract peope from ?S% to &isit )ndia as a medica tourist.
%so a database of Doctors" Hospitas" Cinics and faciities 'oud hep common peope to
search and #et ri#ht treatment. >eope 'oud ha&e an opportunit! to chec6 &arious
aternates a&aiabe to them and compare price of one 'ith the other.
2enerate 100E number of eads and con&ert into +0 number of business
opportunit! in a month
Buid database of 10"000 number of hospitasD 2+"000 number of cinicsD 2+0"000
number of Doctors in a phased manner ,cit! 'ise4
Tar#eted cities in )ndia
Compare ser&ices of one 'ith other in a simiar cate#or!
5eature &arious tourist and &isitin# paces in )ndia
5eature hotes and paces of accommodation
Sho'casin# ?S office address and a person attendin# queries
Channei@in# contacts and si#nin# Mo?s 'ith &arious corporate hospitas
Beta reease tar#et date
% pane of doctors in the compan! board 'oud #i&e an added ad&anta#e
Benefits?Rationale
This section describes the ma;or benefits to be achie&ed 'ith the impementation of the
Business Requirements.

#ta>eholders
>ro;ect sponsors
Hospitas/Cinics in )ndia
Doctors in )ndia
Medica tourists ,Customer4
>atients in )ndia
1eb$site &isitors
>harmaceutica Companies
Dia#nostic Centers
>atients in #enera
Fob see6ers
.mpo!ers
Last revised: Page $ of !
Dependencies on e@istin= s!stems
This section describes the dependencies bet'een the %ppication for 'hich these Business
Requirements are 'ritten and the other e/istin# appications/s!stems.
Got appicabe
References
>ro;ect Charter (er.02
/ssumptions
This section describes ma;or assumptions that 'ere made prior to or durin# the Business
Requirements #atherin# and documentation.
Requirements #cope
%his section sho&s &hat 'usiness functionalit( is in sco)e and out of sco)e for *m)lementation+
*n ,se case a))roach- the out of sco)e ,se cases are indicated in a se)arate 'oundar( 'o.+ *n
/racle Designer a))roach the out of sco)e 0unctions are sho&n in gre( coloured 'o.es+
1. Pulic facin= Aesites (Health tourist portal and 2ndian portal) should ha*e Aorld
class desi=n templates.
5unctiona! there are t'o separate pubic facin# 'ebsites. 0ne is to promote heath
tourists and the other is for )n
2. Content of the 'ebsite 'oud chan#e dependin# upon the tar#eted audience and
mana#ed throu#h countr! )> ,i.e. different oo6 and fee for ?S% and )ndian &isitors4.
(irtua! it is t'o different 'ebsites.
8. % the contents are to be mana#ed throu#h a pass'ord protected admin intranet ,to
pubish formatted te/t" ima#es" &ideos
<. %dmin intranet 'i ha&e &arious user e&e to access/not to ha&e access to certain data
+. >ubish basic ser&ices H identified in the 1
st
phase ,non ife ris6 medica tourists4
3. >ubish anciar! ser&ices ,(isitin# paces" hotes etc.4
I. Customer can compare ser&ices and pricin# on the porta
=. Customer can submit an enquir! form 'hich is considered to be a business ead
*. % the communication 'ith the customer shoud be mana#ed throu#h the admin intranet
10. ./tensi&e search faciit! ,simpe and ad&anced search4
11. )nte#ration 'ith 2oo#e Map %>) ,Shoud be the first of its 6ind information4 5aciit! to
update b! the indi&idua &isitor i6e updatin# address/ocation in the 2oo#e map.
12. Fobs section ,>ost ;obs" Search ;obs reated to heathcare ser&ices4
18. Brandin# and ad&ertisin# b! &arious ser&ice pro&iders ,Jistin# of hospitas/cinics" Jistin#
of doctors" >harmaceutica companies" Ge' product reeases" reated ser&ices i6e
%mbuance" Suppiers etc.4
1<. (irtua office for Doctors H 0nine appointment" s!nc caendar in smart phones ,This ma!
attract some Doctors to be part of this initiati&e4.
1+. Cinic mana#ement soft'are H SaaS soft'are to mana#e sma cinic/independent
doctors
13. Buidin# consumers database 'hich 'oud hep in the future to mar6et
1I. Ge's feeds
1=. .mai inte#ration
1*. SMS inte#ration
20. Communit! ser&ices/Corporate Socia Responsibiit! ,)f the customer is poor and coud
not ocate a doctor" 'e 'i hep them ocatin# ri#ht doctor4
21. >MR ,>ersona Medica Record4
22. Mana#e data bases of >harmacists/Dru# stores and ocate them in 2oo#e Map
28. Connect ,Consumer" Ser&ice pro&iders ,Doctors" Dru# stores" Dia#nostic centers etc..4
+. Besite.
The 'ebsite contains a home pa#e describin# the purpose and na&i#ationa in6s to other
sections. .ach na&i#ation in6 ta6es the 'eb site &isitor to a separate pa#e. Some pa#es i6e
,%bout us" Ser&ices" Contact us" 1h! 'e4 and na&i#ations in6s described in the respecti&e
)%.
T!pica 1ebsite fo' H Tourist porta-
Last revised: Page ! of !
Jo#in
Ser&ices
Contact
%bout us
Ho' 'i it
Benefit me K
Jatest Ge's
Testimonias
Contact Saes
.ar=eted 'an=ua=es of the current s!stem
The pubic facin# 'ebsite of the Heath tourist porta contents to be a&aiabe in the
foo'in# an#ua#es-
i. .n#ish
ii. Spanish
.n#ish is the defaut an#ua#e 'hen 'ebsite is open. There 'oud be an option 'here
user can chan#e the an#ua#e.
% options" menus" tites" abes and on$screen messa#es are to be chan#ed to
LSpanishM 'hen the user seect an#ua#e option.
)t shoud be an eas! to use admin interface to create/update an#ua#e equi&aents for a
ree&ant sections.
.n#ish is the primar! an#ua#e for the )ndian porta.
2nformation /rchitecture (5edical .ourism Portal)
1ebsite Ja!out ,Medica tourist porta4
Jo#o
Banner section to e/pain the 1ebsite / ser&ices features
&*+,-.* /01*/.-.2*
Ji&e Chat section
+ 2 8 3
(isitin# >aces in
)ndia
Compare ser&ices section
Ser&ice cate#ories section
Cient testimonias
Jatest Ge's
Cop!ri#ht NNNNN >ri&ac! O Discaimers O Terms of use
2nformation /rchitecture (Portal for 2ndia)
1ebsite Ja!out ,>orta for )ndia4
Jo#o
1ebsite name/tite
Ji&e Chat
section
Cop!ri#ht NNNNN >ri&ac! O Discaimers O Terms of use
Search Here
#umi.
./. 2enera >h!sician in H!derabad" %bids S'itch to %d&ance Search
Space for %d. banner
Space for ne'
products reeased
Hospitals ,linics Doctors Dia=nostics :os
Space for dispa!in# comparisons
2nformation /rchitecture (/dmin 2ntranet /rea)
1unctional Requirements
(ser Profiles #pecification (/pplicale to .ourist portal and Portal for
2ndia)
This section describes a the %ctors and their profies 'ithin the conte/t of the Business
Requirements ein= documented. /n /ctor is a personC or=aniDation or an e@ternal
s!stem/sub$s!stem/pro#ram that has interactions 'ith the %ppication. %ctors" b! definition"
are e/terna to the s!stem 'ith 'hich the! are ha&in# interactions. %ctors ha&e #oas that are
achie&ed b! use cases. T!pica!" %ctors ha&e beha&iour and are represented b! the roes
the! pa! in the use cases. %n %ctor stimuates the s!stem b! pro&idin# input and/or recei&in#
somethin# of measurabe &aue from the s!stem.
Last revised: Page 3" of !
Super %dmin ?ser-
Super %dmin user has contro o&er the compete s!stem and can mana#e to create other
users" #roups" pri&ie#es and required master data.
The functionait! of the compete appication is moduari@ed and access to each modue
is set b! the appicationAs access contro matri/.
T!pica user access contro matri/-
Roles &&E /dmin
%dd .dit De (ie'
5ana=e ;roups P P P P
5ana=e (sers P P P P
5ana=e Business
parameters P P P P
Super admin can inacti&ate certain 2roups/?sers/5eatures for some reason before
deetin# permanent!. The user ha&in# admin pri&ie#e can acti&ate or inacti&ate a record.
% data &ie' ist can ha&e the option to see %cti&e and )nacti&e records.
%ccesses to indi&idua acti&it! are fi/ed as per the user cassification and roe.
Last revised: Page 3# of !
Super %dmin
?ser
U,*3 N01*
P0,,4536
OK C0/7*2
2roup and ?ser
Mana#ement
Mana#e Business
>arameters
Content
Mana#ement
Cient reationship
mana#ement
Communication
Mana#ement

%dministrator-
%dministrator is another user 'ho inherits some contros from the super admin to perform certain
acti&ities. 2enera! admin user has a the ri#hts of L%dd/.dit or Deete a record. There can be
mutipe admin users.
Content De&eoper-
Content de&eoper is another user 'ho #enera! create ne' contents/edit the content but does
not ha&e ri#ht to deete permission. Content created or edited 'oud not be pubished unti it is
has be re&ie'ed or appro&ed b! the >ubisher.
Content >ubisher-
Content pubisher 'i re&ie'" appro&e or disappro&e an! content to be pubished in the pubic
area.
1ebsite (isitor-
%n! 'ebsite &isitor 'i ha&e access to a the pubic contents pubished in the 'ebsite. 1ebsite
&isitor can search and consume a ser&ices 'hich are set as free ser&ices.
Re#istered ?ser-
Re#istered users 'i ha&e pri&ie#es to access certain pri&ate data and communicate 'ith the
ser&ice pro&iders.
Customer-
Customer is a user 'ho 'oud ha&e access to paid ser&ices.
Last revised: Page 3$ of !
#5# 1unctionalit!
a. %be to confi#ure at east 8 ser&ice pro&iders %>) for sendin# SMS.
b. %be to send bu6 SMS b! the 'ebsite admin/users to the &arious sta6e
hoders.
c. %be to confi#ure in the %dmin internet to send SMS for &arious acti&ities
,./ampe a ne' ead is recei&ed" confirmation to customer that his enquir! is
recorded etc..4
d. Re#istered users / customers can send SMS after o#in
e. %be to aocate number of SMSs a customer can a&ai free and subscribe for
more SMSs ,most! appicabe for &irtua office and reeasin# ne' products4
P5R 1unctionalit!
a. %be to update demo#raphics / persona records
b. %be to update demo#raphics of the fami! members
c. %be to update Doctors information
d. %be to upoad prescriptions ,as attachments4
e. %be to update prescriptions as te/t
f. %be to setup medication
#. %be to setup aerts ,.mai and SMS4 'ith re#ard to re#uar chec6ups"
medicine and doses
h. %be to share medica records 'ith the doctor for a particuar period 'ith
permissions ,(ie' on! / (ie' and Do'noad4
5/P 1unctionalit! ? ;oo=le 5/P /P2 inte=ration
0. %be to ocate Doctors" Hospitas" Cinics" Dru# Stores" Dia#nostic Jabs on a
M%>.
b. Dispa! different icons for each cate#or! of information.
c. )cons are updated throu#h %dmin intranet for each cate#or! of information.
d. %be to dispa! more information throu#h a ca$out 'hen user point on a
particuar icon.
e. %be to &ie' more information in a separate pa#e 'hen user opted to 6no'
more about seected information.
f. ?ser can abe to submit feedbac6s to the site o'ner for an! seected
information.
#. ?ser can abe to report an! errors to the site o'ner for an! seected
information.
h. The feedbac6s / errors reported b! the users are emaied/sms to the
respecti&e site admin/user.
-. The feedbac6 / reported errors are stored in the admin intranet.
;. The user is reported bac6 'hen the corrections are done or feedbac6 are
ac6no'ed#ed.
8. (isitors can add a ocation ,Doctor/Hospita/Cinic/Medica store/Dia#nostics4
if the! fee so b! fiin# a sma form. The Jatitude and Jon#itude shoud be
pic6ed up automatica!.
. The information submitted are stored separate! for the admin to re&ie' and
appro&e or disappro&e.
1. % messa#e emai/sms sent to the user 'ho submitted 'hen the admin
appro&e / disappro&e. )f the admin disappro&e the reason shoud be fied and
intimated.
Virtual office ? ,linic mana=ement application
0. %ppication is based on SaaS ,Soft'are as a ser&ice4 mode
+. %be to pro&ide a separate area for each customer ,Doctor/cinic4 and
accessed throu#h a user name and pass'ord
c. .ach customer can si#n$up to a&ai this faciit!
d. Customer can opt$out this ser&ice b! sendin# an emai/cain# to a site admin
/ support request.
e. %dmin can acti&ate / inacti&ate this ser&ice for a customer
f. 5oo'in# are the faciities incuded in the (irtua office-
a. Customer ,Doctor/Cinic4 update their pace of a&aiabiit!" timin#s for
a particuar period ,Da!" Time" Got a&aiabe time etc..4
+. (isitors ,>atients4 can &ie' the caendar or schedue an appointment
c. Customer to &ie' the caendar and ist of appointments
d. Customer can accept / re;ect one or a appointments for a da! or
period
e. )nformation #oes to the patients 'hen Doctor/Cinic accepted or
re;ected an appointment b! emai / sms
f. Record/update patient &isits
#. %be to #enerate a bi for the ser&ices
h. %be to 'rite a prescription for the patient
i. %be to #enerate a medica certificate for the patient
;. %be to recommend/order a dia#nostics
#. SaaS %rchitecture
1. 5u! Shared DB >er Tenant
Last revised: Page 3! of !
The proposed appication shoud be depo!ed on SaaS patform. The appication shoud ta6e care
of the foo'in# 'hie desi#nin# the appication.
>erformance
Securit!
Reiabiit!
Customi@ation
)nte#ration
Scaabiit!
Muti tenanc!
There are t'o a!ers. DB a!er and %ppication Ja!er. 0r#ani@ation )D is the 6e! for a database
tabes ,Master and transaction4. Data is accessed from the appication b! pro&idin# 0r#ani@ation
)D.
.&er! user is associated 'ith an or#ani@ation id. %n or#ani@ation can ha&e man! users. ?ser )D
is unique throu#hout the database.
There are t'o databasesD one to store a data reated to user" contains ,username" pass'ord"
or#ani@ation id4 for authentication and the other is database contains data reated to appication.
2?)D is used for or#ani@ation id. Mutipe or#ani@ation data can reside in a sin#e database or
mutipe of databases.
/d*ertisement ? randin= ? rotatin= anner mana=ement
a. %be to define the ad pacements in &arious pa#es
b. %be to define price for ad pacements ,ad si@e / duration / price4
7. %be to update/upoad ad content for a ocation 'ith priorit!" number of
impressions" time period etc..
d. %be to mana#e the ad banners and content throu#h admin area
:os functionalit!
a. %be to search ;ob openin#s b! enter search te/t" e/perience/ocation.
b. %be to respond/send resume for a ;ob direct! after o#in
7. %be to pubish ist of recent ;obs b! function and ocation
6. %be to pubish top 10 empo!ers 'ith their o#os. Dispa! ist of current ;ob
openin#s.
e. %be to re#ister and upoad resume b! the ;ob see6ers
f. %be to o#in and update resume b! the ;ob see6ers
#. .mpo!ers to re#ister and update ;ob openin#s
h. .mpo!er o#in and search resumes
i. Do'n oad matchin# resumes for a particuar post
9. .mai to ;ob see6er 'hen a ne' matchin# ;ob is updated b! the empo!er
6. .mai to empo!er 'hen a ne' matchin# resume is updated b! a ;ob see6er.
. Boc6 resumes to be &ie'ed b! certain companies ,b! enterin# 6e! 'ords of
the companies4 b! the ;ob see6er for mana#in# pri&ac!
#earch ? /d*ance search
a. Basic search shoud 'or6 i6e 2oo#e search 'ith su##estions
b. ?ser can shift to ad&ance search and search throu#h seectin# fiters and
criteria
,ommunication ? Bor> floAs
a. The &isitors to the 'ebsite shoud abe to communicate 'ith the site admin /
ser&ice pro&iders b! fiin# pre$defined forms.
+. % confirmation messa#e shoud be sent to the person 'ho submitted b!
emai as a cop! for hi/her record.
c. %part from sa&in# data in a database tabe 'hich can be accessed throu#h
admin intranetD a information shoud be sent to respecti&e site user / ser&ice
pro&ider dependin# on the 6ind of ser&ice request.
d. 1or6$fo's are defined in the admin intranet ,i.e. mai to 'hom" access to
'hom4
Buildin= consumer dataase
a. Consumers are the users 'ho search/see6 &arious ser&ices and submits
request for ser&ices in &arious forms. Re#istered / non re#istered users.
b. % the information are to be compied and cate#ori@ed for future ser&ices i6e
,'hen ne' product / ser&ices are reeased.4
7. %be to attract consumer to re#ister to #et &aue added ser&ices.
5ana=e dataase for Pharmacists?Dru= stores? Dia=nostics centers and
locate them in ;oo=le 5ap
a. %be to search and ocate a dru# store / dia#nostic ser&ices
+. %be to compare prices for different tests bet'een the dia#nostic centers in a
particuar ocait!.
,ommunit! ser*ices ? ,orporate social responsiilit!
a. >eope re#ister as ser&ice pro&ider / &ounteer to e/tend their ser&ices.
+. >eope request to for ser&ices ,./ampe- Joo6in# for hep to ocate a doctor
for a particuar disease" Joo6in# for hep.
c. %be to connect bet'een the ser&ice pro&iders 'ith ser&ice see6ers
,onnect (,onsumerC #er*ice pro*ider (DoctorC Dru= storeC Dia=nostic
center)
a. %be to create a patform to connect bet'een the consumer and ser&ice
pro&ider and brin# them into to a common patform.
b. The information shoud be fashed to nearest Dia#nostics center 'hen Doctor
prescribes tests.
c. Consumer / >atient can compare price for different tests
2nteracti*e 1orms
#er*ice Request
(se ,ase %ame Submittin# onine form
Description Submittin# onine form in the 'ebsite
/ctors >rospecti&e medica tourist ,Customer4
Business Rules
. 5orm can be submitted on! after the user
compete fiin# a the required data.
2. ?ser can s'itch to detaied form / pro&ide
more information if he/she 'iin# to
pro&ide at that moment b! e/pandin#
section of the form.
Basic 1loA /lternate 1loAs
1. 0n screen than6 !ou messa#e.
$. .mai confirmation to the customerAs
emai address as a cop! of the
information submitted.
(. .mai notification to the business
head/concerned e/ecuti&e.
4. Sa&e data in the database for
reportin#
1. The ser&ice request form can be
submitted ,after censorin#4 direct! to the
affiiate hospitas ,Ser&ice pro&iders4 to
submit their quotes.
2. The business head/concerned e/ecuti&e
'i re&ie' and submit the form to Ser&ice
pro&iders.
,ontact us
(se ,ase %ame Submittin# contact us form
Description Submittin# onine form in the 'ebsite
/ctors >rospecti&e medica tourist ,Customer4
1ebsite &isitors
>rospecti&e ser&ice pro&iders ,1anted to ist in
the porta4
Business Rules 1. 5orm can be submitted on! after the user
$. .mai confirmation to the emai
address pro&ided as a cop! of the
8. .mai notification to the business
4. Sa&e data in the database for
reportin#
1eedac>
(se ,ase %ame Submittin# feedbac6 onine
Description Submittin# an onine form in the 'ebsite
/ctors 1ebsite &isitors
Business Rules 2. 5orm can be submitted on! after the user
2. .mai confirmation to the emai
address pro&ided as a cop! of the
8. .mai notification to the business
<. Sa&e data in the database for
reportin#
8.+.+. Pulish Basic #er*ices (Health .ourist Portal)
The content is mana#ed in the admin section and pubished in the home pa#e and
ser&ices section.
?ser can e/pore to 6no' more information ,i.e. Jist of ser&ice pro&iders" their faciities"
pricin# etc4 on seectin# a particuar ser&ice.
%so" user can compare price bet'een ser&ice pro&iders for a seected ser&ice cate#or!.

Last revised: Page 2" of !
Data Requirements (5edical tourist portal)
The content and data required for the porta is coected from &arious sources and updated
throu#h the admin contro pane b! the authori@ed users. The content/data pubished on! after it
has been &erified and appro&ed b! the pubisher.
2nitiall! all the rele*ant data updated ! the portal administrator and pro=ressi*el! an
e@tranet s!stem can e de*eloped Ahich Aould enale the ser*ice pro*ider to update data
throu=h secure lo=in.
1. Core ser&ices H )nformation about &arious hospitas / cinics" their ser&ices" faciities"
pricin# etc.
2. %nciar! ser&ices
a. )nformation about &arious tourist paces
b. )nformation about hotes
c. )nformation about tra&es
(. 0ther ser&ices H Reated ne's and updates

Data /rchitecture ? 5etadata
1. )nformation about a Hospita/Cinic
i. Game and address
ii. Contact teephones
a. 2enera
b. .mer#enc!
c. .ach speciai@ation
iii. .mais
i&. Jocation and direction
&. >hotos
&i. Speciaities / Ser&ice catao#ue
&ii. %chie&ements
&iii. Testimonias
i/. 5aciities
a. >harmac!
b. Canteen
c. Dia#nostics
/. )nfrastructure
0. Ma;or equipments
b. Ma6e
7. >hotos
/i. 0Ts
a. T!pe
b. Specia about theatre
c. >hotos
/ii. Doctors
a. Game and contacts
b. Speciai@ation
c. ./perience
d. %chie&ements
Last revised: Page 2# of !
e. Testimonias
2. )nformation about a (isitin#/Historica pace
i. Game
ii. Short description
iii. %ddress/Jocation
i&. )mportance
&. >hoto#raphs
8. )nformation about a Hotes
i. Game
i&. Tariff
&. >hoto#raphs
<. )nformation about a Tra&e
i. Game
i&. Tariffs
+. Ge's 5eeds
i. )nte#rate 'ith reated ne's feeds
ii. Create an interface to upoad ne's
iii. Ge's tite
i&. Date
&. Source
&i. Te/t
&ii. ima#es
6. Corporate contents ,CMS4
i. %bout us
a. Te/t
b. >hotos
ii. Ser&ices
a. Ser&ice cate#or!
b. Ser&ice description
c. >hotos
iii. 1h! 'e
a. Te/t
b. >hotos
I. 5%Qs ,CMS4
i. Question
ii. %ns'er
=. Ser&ice 'ise price comparison
i. Ser&ice cate#or!
ii. Ser&ice description
iii. >rice in ?S7
i&. 0ther char#es if an! ?S7
Last revised: Page 2$ of !
0ntit! Relationship Dia=ram
Data Volumes
Health .ourist Portal$
)nitia 10 2B incudin# ima#es and annua #ro'th coud #o up to 109
Portal for 2ndia$
)nitia 20 2B incudin# ima#es and annua #ro'th coud #o up to 209
Data Retention and /rchi*in=
This section describes the Data retention ,time frames for onine Data retention before
archi&in#4 and aso the archi&in# requirements.
Pri*ac! 2mplications
This section describes the sensiti&it! e&es of each cass of data. The foo'in# criteria are
used in determinin# the sensiti&it! e&e of each conceptua cass/entit! in ine 'ith the
2o&ernment Core >oic! Manua4.
Non-sensitive information that &ould not reasona'l( 'e e.)ected to cause in4ur( (harm)
if released to the )u'lic5

Protected A: information that- if com)romised- could reasona'l( 'e e.)ected to cause
in4ur( (harm)- e+g+ loss of )rivac(5
Protected B: information that- if com)romised- could reasona'l( 'e e.)ected to cause
serious in4ur( (harm)- e+g+ the conduct of a court )roceeding &ould 'e adversel( affected5

Protected C: information that- if com)romised- could reasona'l( 'e e.)ected to cause
e.tremel( grave in4ur( (harm)- e+g+ loss of life+
Last revised: Page 2! of !
Data Definition Reports
0ntit! Definition Report
This section is appicabe on! to 0race Desi#ner approach. This section describes Data
%rchitecture / definition ,.ntit! Reationship mode4 in narrati&e te/t form.
0ntit! %ame
0ntit! Description
2nitial Data Volume (appro@.)
/nnual Data =roAth rate (in appro@. F)
/ttriutes (fields) of the 0ntit! Game -
Description -
Game -
Description -
Game -
Description -
Game -
Description -
Game -
Description -
Game -
Description -
Data Requirements (Portal for 2ndia)
The content and data required for the porta is coected from &arious sources and updated
throu#h the admin contro pane b! the authori@ed users. The content/data pubished on! after it
has been &erified and appro&ed b! the pubisher.
2nitiall! all the rele*ant data updated ! the portal administrator and pro=ressi*el! an
e@tranet s!stem can e de*eloped Ahich Aould enale the ser*ice pro*ider to update data
throu=h secure lo=in.
. Core ser&ices H )nformation about &arious Hospitas" Cinics" Doctors" Dia#nostic" 5aciities
pro&ided b! them and pricin# etc.
$. %nciar! ser&ices
Fobs
Ge' product reeases
%d&ertisement
(. 0ther ser&ices H Reated ne's and updates

Data /rchitecture ? 5etadata (for Portal in 2ndia)
#ecurit! Requirements
/uthentication
This section describes the %uthentication requirements part of the Business Requirements.
%uthentication is the process of &erif!in# the #enuineness of caims that a person/#roup
ma6es to estabish identit!/ei#ibiit! for access to ser&ices. The foo'in# criteria is used in
determinin# transaction t!pes of each use case/function-
Level 0 : Anonymous transaction 6 triggers transactions that do not require or allo& a
)erson to 'e identified- or transactions &hich require )rotection of a )erson7s identit(+ 0or
e.am)le- access to online information a'out government )rograms or services or )rotecting
a )erson7s identit(+ Com'ining the transaction data &ith other data must not allo&
identification of a )articular individual+
Level 1 : Pseudonymous transaction 6 triggers transactions that do not require a )erson to
'e identified 'ut do require a means for further contact to deliver a )roduct or service+ 0or
e.am)le- a note from some)erson899999+com can not 'e readil( translated into an
individual:s name- 'ut it ma( 'e sufficient to request information- to )rovide some services- or
on;going follo& u)+
Level 2 : Identified transaction 6 triggers transactions that require that a )erson 'e
s)ecificall( identified+ %he nature of the transaction ma( require confirmation of a )erson7s
identit( (e+g+- name- address- 'irth date- etc+) and<or data lin=ing the )erson to a transaction
(e+g+- invoice num'er- )ersonal health num'er- etc+)+
Level 3 : Verified transaction 6 triggers transactions that require: the )erson to 'e
s)ecificall( identified5 verification of the integrit( of the data e.changed and the e.change
itself5 and- the creation of sufficient evidence to indicate that the )erson agreed to 'e 'ound
'( the transaction+ 0or e.am)le- a note signed &ith a digital certificate- audit trails and
securit( logs ma( )rovide sufficient evidence that a s)ecific )erson intended to conduct a
transaction+

/*ailailit! Requirements
The s!stem is a&aiabe o&er the net. The heathcare porta is tar#eted to ?S% and >orta for
)ndia is tar#eted 'hoe of )ndia. The s!stem 'oud re$direct to the user based on )> address.
)f an!bod! tr!in# to access the Heathcare porta from )ndia" the s!stem 'i re$direct to >orta
for )ndia and &ice$&ersa.
The s!stem uptime shoud be **.009. The simiar bac6 to bac6 #uarantee needs to be
obtained from the hostin# compan!.
)n case of an! brea6do'n" appropriate messa#e need to be fashed.
0n$ine chat to be ad;usted 'ith ?S and )ndia time.
Response to user quer! 'ithin 2< hours.
(se ,ase ? Business
1unction %ame
/*ailailit! Requirements
& Re=ular Aor> hours
& 23@6
& /n! other (please descrie)
(sailit! Requirements
This section describes the s!stem usabiit! requirements. % usabiit! requirement specifies
ho' eas! the s!stem must be to use. ?sabiit! is a non$functiona requirement" because in its
essence it doesnRt specif! parts of the s!stem functionait!" but specifies on! ho' that
functionait! is to be percei&ed b! the user" for instance ho' eas! it must be to earn and
operate the s!stem.
#!stem Help Requirements
This section describes 'hat 6ind of S!stem Hep features are needed to be buit into the
s!stem.
(se ,ase ? Business
1unction %ame
Help Requirements
& 1ield le*el (online)
& #creen le*el (online)
& Help Printin= -ptions
& -perations 5anual (-ffline)
& /n! other
Performance Requirements
+.+.1. Stress Requirements
Heath tourist portas must be abe to support minimum of 200 user accessin# records
simutaneous!.
>orta for )ndia must support minimum of +000 users accessin# simutaneous!.
+.+.2. Response$Time Requirements
The ma/imum ao'abe 'ait time from the moment the user submits a request unti the
s!stem comes bac6 'ith a response shoud not #o be!ond = seconds 'ith the data
&oume 800"000E records
#calailit! Requirements
The s!stem shoud be scaabe to accommodate add ne' ser&ices" enhance e/istin#
ser&ices.
(ser #calailit!
/pplication #calailit!
2nterface Requirements
This section describes ?ser and S!stem )nterface requirements for the proposed s!stem.
(ser 2nterface Requirements
BroAser compatiilit!
The 'ebsite shoud support a ma;or bro'sers of the current &ersion and one &ersion
do'n.
1. ).
2. 5ire 5o/
8. Mo@ia ,Mac4
<. Chrome
Last revised: Page of !
Data displa!
The content presented in the porta 'oud be desi#ned professiona! i6e an! 'ord cass
'ebsite. The data can be presented in Jist &ie'/5orm &ie' to the sta6ehoders in their
respecti&e area.
Drop&doAn list
Data consistenc! is maintained throu#h seectin# choices from drop do'n ist. The
appication shoud enabe each customer to add their ne' choices.
The master drop do'n ist is mana#ed throu#h the %dmin area. 1hen a customer
re#ister" set of master data ,pre$requisites4 are a&aiabe for them. This 'oud hep them
to start usin# the appication instant!. %so" each re#istered customer can mana#e their
o'n master data ,add/edit/deete4.
#a*in= report as PD1 file.
5aciitates to sa&e a report in >D5 format
Be 2.0 features
1ebsite / %ppication to be buit on 1eb 2.0 features. >a#e re$oadin# / refresh to be
a&oided compete!.
#!stem 2nterface Requirements
Last revised: Page " of !
Project Plan and Delivery Schedule
7.1 Project Schedule
#' .as> #tart 1inish Duration
1 Definition
S!stem Desi#n
Detaied Desi#n
De&eopment
)nte#ration Testin#
Depo!ment
?%T
Bu# fi/in#
2o Ji&e
6.2 Pro"ect #chedule
Phase 5ilestone Deli*erale
Requirement Definition BRD Si#noff Business Requirement
Document
>rotot!pin# /1ire framin# /
>orta a!outs
Ja!out desi#n si#n$off and
1ireframe Si#noff
>DS" htm and CSSs
>rotot!pe for the proposed
appication
S!stem Desi#n Competion of Desi#n
Document
Desi#n document containin#
fo's" &aidations" inputs and
outputs.
Database desi#n
De&eopment" )nte#ration and
Testin#
Beta Reease of the site for
?%T
Beta &ersion ,Tested fu!4
Depo!ment and 2o Ji&e 5ina Si#noff Source Code for the
appication hosted on i&e
en&ironment. Source code
documentation and ?ser
#uide.
Support Cosin# 5i/ bu#s
Last revised: Page # of !
Communication Plan
8.1 Proposed Communication Plans
Dai! ca
1ee6! re&ie' meetin# 'oud be hed on a preschedued da! ,NNNNNN4 and time.
Re#uar communication 'oud be done throu#h emais" phone and 1ebMeetin# 'ith
emai 'oud be the most frequent communication medium
./tranet porta ,Basecamp4 created for the pro;ect 'oud be the patform throu#h 'hich
the pro;ect reated documents" minutes of the meetin# are shared. The tas6s assi#ned for
the team members are presented and trac6ed throu#h the porta
1ee6! status report shoud be shared 'ith Cient throu#h emai and aso posted to the
e/tranet porta b! end of the 'ee6.
Project Team
#' %ame Role -r=aniDation ,ontact %o 0&mail address
0scalation Points
#' %ame Desi=nation -r=aniDation ,ontact %o 0&mail address
Last revised: Page $ of !
Re*ision 'o=
ate Version C!an"e #eference #evie$ed %y
2+
th
0ct 2010 01$Draft
23
th
0ct 2010 02$Draft
Jist of 5unctionait! incuded for )ndian >orta
1. Communit! /Corporate Socia Responsibiit!
2. >HR ,>ersona Heath Record4.
8. Mana#e data bases of >harmacists/Dru#
stores and ocate them in 2oo#e Map
3
th
Go& 2010 02$Draft 1. Scope is e/pained and e/panded
2. SaaS architecture dia#ram is depicted
8. Connect functionait! is incuded
/ppendices
.nter content here.
/ppro*al
This document has been appro&ed as the officia Business Requirements Document for
the HeathCare pro;ect.
5oo'in# appro&a of this document" chan#es 'i be #o&erned b! the pro;ectAs chan#e
mana#ement process" incudin# impact ana!sis" appropriate re&ie's and appro&as"
under the #enera contro of the Master >ro;ect >an and accordin# to >ro;ect Support
0ffice poic!.
Pre&ared %y 'i"nature ate
%uthorRs Game
STiteT
S0r#ani@ationT

A&&roved %y 'i"nature ate
SCient %cceptorAs GameT
STiteT
S0r#ani@ationT

Last revised: Page ! of !

Healthcare Project BRD

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Healthcare Project BRD

Uploaded by

Copyright:

Available Formats

Business Requirements Document

You might also like