18. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 5/8/2017 10:03:19 PM Eastern Daylight Time. See www.araxis.com for information about Merge. This report uses XHTML and CSS2, and is best viewed with a modern standards-compliant browser. For optimum results when printing this report, use landscape orientation and enable printing of background images and colours in your browser.

18.1 Files compared

#	Location	File	Last Modified
1	var-utility-web-Release-1.0.0-Branch.zip\MHED_VAR_DOCS	Utility_v1_Business+Requirements+Document+(BRD).docx	Mon May 8 15:44:04 2017 UTC
2	var-utility-web-Release-1.0.0-Branch.zip\MHED_VAR_DOCS	Utility_v1_Business+Requirements+Document+(BRD).docx	Mon May 8 18:51:10 2017 UTC

18.2 Comparison summary

Description	Between Files 1 and 2
Description	Text Blocks	Lines
Unchanged	2	998
Changed	1	2
Inserted	0	0
Removed	0	0

18.3 Comparison options

Whitespace
Character case	Differences in character case are significant
Line endings	Differences in line endings (`CR` and `LF` characters) are ignored
CR/LF characters	Not shown in the comparison detail

18.4 Active regular expressions

No regular expressions were active.

18.5 Comparison detail

	1	Utility_v1 _Business Requiremen ts Documen t (BRD)
	2
	3	VAR Utilit y
	4	Scheduling Enhanceme ntsWork Ef fort Under Schedulin g Enhancem ents Contr act
	5	Includes V AR Utility Release v 1.0.0
	6
	7	Business R equirement s Document
	8	February 2 016
	9	BRD Versio n 1.0
	10
	11	Revision H istory
	12	Note: The revision h istory cyc le begins once chang es or enha ncements a re request ed after t he Busines s Requirem ents Docum ent has be en approve d.
	13	Date
	14	Descriptio n
	15	Author
	16	November 1 0, 2015
	17	Initial ve rsion
	18	Jennifer Z inck
	19	Date when Business O wner/Busin ess Liaiso n and OI&T sign-off
	20	Approved v ersion
	21	Business O wner Name (date of a pproval)
	22	Business L iaison nam e (date of approval)
	23	OI&T name (date of a pproval)
	24
	25
	26
	27	1.Purpose
	28	The Busine ss Require ments Docu ment (BRD) is author ed by the business c ommunity f or the pur pose of ca pturing an d describi ng the bus iness need s of the c ustomer/bu siness own er. The BR D provides insight i nto the AS -IS and TO -BE busine ss area, i dentifying stakehold ers and pr ofiling pr imary and secondary user commu nities. It identifie s what cap abilities the stakeh olders and the targe t users ne ed and why these nee ds exist, providing a focused overview o f the requ est requir ements, co nstraints, and other considera tions iden tified. Th is documen t is a bus iness case and does not mandat e a develo pment meth odology, h owever the requireme nts are wr itten usin g agile me thodology terminolog y. The int ended audi ence for t his docume nt is the Office of Informatio n and Tech nology (OI &T).
	29	2. Overvie w
	30
	31	Who: The C onnected H ealth Offi ce (CHO) i s supporti ng this re quest.
	32	What: The request i s for the creation o f a Schedu ling Admin istration Utility th at include s:
	33	The abilit y to suppl y customiz ed message s related to user re gistration status an d availabi lity of se rvices for direct sc heduling
	34	The abilit y to selec t and edit direct ap pointment service of ferings fo r select F acilities/ Clinics
	35	When: The Period of Performan ce for the VAR enhan cements co ntract is September 28, 2015 t hrough Sep tember 27, 2016.
	36	Where the change wil l occur: The enhanc ements wil l be compl eted in th e VA Mobil e Framewor k (VAMF).
	37	How the IT solution will impro ve the bus iness proc ess:
	38	Provide sy stem admin istrator c ontrol and customiza tion of of ferings an d informat ion displa yed in VAR
	39	Why is the project n ecessary o r desired: The VAR enhancemen t project is needed to:
	40	Allow admi nistrators control o ver schedu ling optio ns and con tent
	41	3.Scope
	42	The scope of this ef fort inclu des the fo llowing pr imary enha ncement ar eas:
	43	Enhancemen t
	44	Descriptio n
	45	CLIN 7 (PW S 5.2.6) - Create Sc heduling A dministrat ion Utilit y
	46	Allow VA facilities to locall y maintain custom me ssages and parameter s used by VAR and di rect sched uling capa bilities.
	47
	48	4. Custome r and Prim ary Stakeh olders
	49	Dr. Kathle en Frisbee , represen ting Conne cted Care (previousl y Connecte d Health), is the pr imary stak eholder fo r this req uest. Revi ew Appendi x C (link to be adde d) for the complete list of pr imary and secondary stakeholde rs.
	50	5. Goals, Objective s, and Out come Measu res
	51	To be dete rmined by the busine ss owner.
	52	Goal/Objec tive
	53	Impact/Ben efit
	54	Measuremen t
	55
	56
	57
	58
	59
	60	6. Enterpr ise Need/J ustificati on
	61
	62	Improve th e quality of health of Veteran s
	63	Increase t he quality of health care avail able throu gh the VHA
	64	Improve th e efficien cy of Prov iders as w ell as sup porting st aff
	65	Continuous ly expand Veteran's overall sa tisfaction with VA
	66
	67	7. Busines s Requirem ents
	68	7.1. Theme s, Epics ( Needs), an d User Nar ratives (B usiness Re quirements )
	69
	70	The requir ements tab le below p rovides a list of th e epics th at are det ailed in t he Require ments Trac eability M atrix (RTM ) for this project. The RTM is stored as a separat e document and can b e accessed via the R equirement s Traceabi lity Link located on the Requi red Artifa cts wiki p age.
	71
	72	Scheduling Administr ation Util ity Requir ements Tab le
	73	Identifier
	74	Epic
	75	VAR-1573
	76	Scheduling Administr ation Util ity
	77	7.2. User Access Lev els
	78
	79	User Level
	80	Role
	81	Responsibi lities
	82	Access Lev el
	83	Primary
	84	Utility Us er
	85	View, Upda te facilit y direct a ppointment schedulin g configur ations for VAR
	86	View, Upda te facilit y request submission configura tions for VAR
	87	Scheduling Admin Acc ess (by fa cility)
	88	Provider a uthenticat ion with S D_Supervis or authori zation
	89	7.3. Known Interface s and Data Sources
	90	This is th e business community ’s best un derstandin g of known interface s and may not be a c omprehensi ve listing . All requ ired inter faces will also be s tated as B usiness Re quirements in the RT M.
	91	Name of Ap plication
	92	Descriptio n of curre nt applica tion
	93	Interface Type
	94	ExistingFu nctionalit y
	95	Deliverabl es
	96	VAR (web)
	97	Veteran fa cing appoi ntment and request s ubmission system
	98	Automated
	99	No
	100	Ability to configure facility settings f or appoint ment reque sts and di rect booki ngs in VAR via the u tility
	101	VistA Aut horization Services
	102
	103	Automated
	104	No
	105	Authentica tion with Auth Servi ces and un ique ident ifier to i dentify sc heduling s upervisors (administ rators for the utili ty) at eac h site
	106	7.4. Relat ed Project s or Work Efforts
	107	VAR - Sche duling Enh ancements
	108	Scheduling Manager - Schedulin g Enhancem ents
	109
	110	8. Service Level Req uirements (SLR)
	111
	112	8.1. Avail ability
	113	SLR Questi on
	114	SLR Criter ia
	115	Descriptio n
	116	1. How muc h time sho uld the sy stem be av ailable (a nd how muc h down tim e is accep table due to inciden t [unexpec ted] outag e)?
	117	99% (3.65 days down time)
	118	99.5% (1.8 3 days dow n time)
	119	99.9% (8.7 6 hours do wn time)
	120
	121	2. When sh ould the s ystem be a vailable ( what will be the cor e operatin g hours of the syste m)?
	122	9-5 standa rd weekday s
	123	24-hour st andard wee kdays
	124	24x7
	125
	126	3. How soo n should t he system fully reco ver from a n outage? (Includes Mean Time to Restore [MTRS])
	127	8-24 hours
	128	2-8 hours
	129	minutes
	130
	131	4. How muc h data wil l be resto red when o utage is r ecovered?
	132	24 hours b ack
	133	2-8 hours back
	134	100% (cont inuous bac kup)
	135
	136	5. What ti me period should be considered for maint enance per iods?
	137	Early morn ing (defin e)
	138	After hour s (define)
	139	Overnight (define)
	140
	141	6. In what standard time zone will the s ystem oper ate?
	142	Local (spe cify time zone i.e., ET Standa rd)
	143	More than one time z one (speci fy)
	144	All time z ones
	145
	146	8.2. Capac ity and Pe rformance
	147	SLR Questi on
	148	SLR Criter ia
	149	Descriptio n
	150	1.How many users wil l be on th e system h ourly?
	151	1-100
	152	101-1000
	153	>1000
	154
	155	2. How man y transact ions will each avera ge user pe rform each hour?
	156	1-5
	157	6-10
	158	>10
	159
	160	3. What ar e the anti cipated pe ak user ti mes during the day?
	161	Business d ay (specif y)
	162	Erratic Pe ak (specif y)
	163	No peak (s mall numbe r of users on system )
	164	Other (spe cify)
	165
	166	4. What is the antic ipated pea k transact ion load ( when do yo u think th at there w ill be the most tran sactions b eing perfo rmed on th e system) during the day?
	167	Business D ay (specif y)
	168	Evenings ( specify)
	169	Weekends ( specify)
	170	None
	171	Other (spe cify)
	172
	173	5. How man y new user s will be added in o ne year?
	174	0-100
	175	101-1000
	176	>1000
	177
	178	6. How man y more (if any) tran sactions w ill be add ed in one year?
	179	0-5
	180	6-10
	181	>10
	182
	183	7. What ki nd of info rmation wi ll be stor ed? (Spec ify averag e of each kind per m onth)
	184	Small docu ments (exa mple pdf o r Word fil e)
	185	Forms & Do cuments th at are for matted (ex ample form s or docum ents with images)
	186	All Media (example v ideo, audi o, and med ical image s)
	187
	188	8. What ki nd of sear ch capacit y is requi red?
	189	Light (les s than 10 per hour)
	190	Medium (11 -1000 per hour)
	191	Heavy (gre ater than 1,000 per hour)
	192
	193	9. What ty pe of syst em(s) is/a re require d?
	194	Local (reg ional)
	195	Intranet ( All VA)
	196	Internet ( public)
	197
	198	10. Is the re a need for heavy applicatio n reportin g? If yes, when?
	199	None
	200	End of day
	201	End of mon th
	202	End of qua rter
	203	Other (spe cify)
	204
	205	8.3. Inter faces and Security
	206	If you ans wer "yes" to any of the follow ing questi ons, provi de an expl anation in the Descr iption col umn.
	207	SLR Questi on
	208	SLR Criter ia
	209	Descriptio n
	210	Does this system int eract with other exi sting syst ems?
	211	Yes
	212	VistA Auth Services, VAR web
	213	2. Will th is system require ad ditional m onitoring for Inform ation Tech nology (IT ) system m etrics?
	214	Yes
	215	Use of Me trics Serv ice
	216	3. Will th is system contain pe rsonally i dentifiabl e informat ion (PII), Protected Health In formation (PHI), Hea lth Insura nce Portab ility and Accountabi lity Act ( HIPAA) inf ormation, or other c onfidentia l/regulate d data?
	217	No
	218
	219	4. Who wil l be the a nticipated users of this syste m?
	220
	221	Utility Us ers (VistA Schedulin g Clerks w ith the SD Superviso r scheduli ng key
	222	9. Other C onsiderati ons
	223	9.1. Alter natives
	224	Identify a lternative s the stak eholder pe rceives as available . These ca n include buying a c ommercial product, e nhancing a n existing capabilit y, buildin g a custom solution or simply maintainin g the stat us quo. In clude the major stre ngths and weaknesses of each a lternative as percei ved by the stakehold er or end user.
	225	9.2. Assum ptions
	226	An assumpt ion is a s tatement t hat is pre sumed to b e true wit hout concr ete eviden ce to supp ort it. As sumptions are made c oncerning how the so lution wil l be used, how it wi ll evolve, and what business e nvironment it will o perate in. Briefly l ist the as sumptions for this r equest.
	227	9.3. Depen dencies
	228	Dependenci es include , but are not limite d to, the availabili ty of reso urces (e.g . stakehol ders, subj ect matter experts [ SME]), app lications, and syste ms that in teract wit h this one , hardware , faciliti es, equipm ent, busin ess proces ses, regul atory appr ovals, pol icy, and t raining.
	229	Additional ly, use th is section to docume nt possibl e interfac es, relati onships, a nd/or conf licts with ICD (diag nosis and/ or procedu re) code u sage (such as edit/e ntry/displ ay/print). Additiona l guidance regarding this proc ess can be found at the follow ing link - - http://g o.va.gov/2 etl.
	230	9.4. Const raints
	231	Constraint s are expl icit limit ations tha t will be encountere d in pursu ing an obj ective. Th ese includ e regulato ry, techno logical, o r business realities that legi timately c onstrain s olution de velopment. In listin g the cons traints, i nclude a b rief state ment stati ng why thi s is a con straint.
	232	An example might be “The new s ystem must be in pla ce by Marc h 1st beca use treasu ry will st op issuing checks."
	233	If known, specify th e constrai nts that c ould inclu de require d software products or license d data set s as part of the dev elopment o f the prod uct. Some examples i nclude spe cialized i nstallatio n software , 3rd-part y tools th at require licensing , and/or d ata sets t hat requir e license agreements (e.g., Fi rst Data B ank, E&M C odes, Code 1, etc.)
	234	9.5. Busin ess Risks and Mitiga tions
	235	List any p otential b usiness th reats to t he develop ment and/o r implemen tation of the propos ed enhance ment. Incl ude any po ssible mit igation st rategies f or minimiz ing or eli minating t he risk. Business R isks shoul d be writt en using ' if-then' s yntax.
	236	Business R isks
	237	Mitigation
	238	If there i s insuffic ient fundi ng to supp ort develo pment or a cquisition , then nec essary imm unization data will not be col lected.
	239	Coordinate with Busi ness Owner s and lead ership to ensure pro ject fundi ng.
	240	If resourc es are not available , then the deploymen t of BCMA enhancemen ts may be delayed.
	241	Coordinate with stak eholders t o ensure u nderstandi ng of BCMA requireme nts as par t of their scope.
	242
	243
	244	Appendix A : Referenc es
	245	Provide a complete a lphabetica l list of all docume nts refere nced elsew here in th is documen t, includi ng sources from the VA Softwar e Document Library a nd relevan t hyperlin ks. Identi fy each do cument by title, rep ort number (if appli cable), da te, and pu blishing o rganizatio n. Specify the sourc es from wh ich the re ferences c an be obta ined. If n ecessary, provide th is informa tion by re ference to an append ix or anot her docume nt. Includ e strategi es, HIPAA, public la w.
	246	VA Handboo k 6500 – I nformation Security Program ht tp:/ DNS /vapubs/vi ewPublicat ion.asp?Pu b_ID=638&F Type=2
	247
	248	Appendix B : Models
	249	Describe, with Flowc harts or o ther busin ess proces s models, the “as is ” user exp erience wi th the cur rent solut ion. In so me cases, especially where bus iness proc esses are being modi fied, it m ay also be necessary to docume nt the “to be” state of user e xperience with the d esired sol ution. Mo dels to be inserted, imbedded or hyperli nked. Exam ples of th e BPMN for mat can be found at the follow ing link: http://go. va.gov/svx y
	250	Appendix C : Stakehol ders, User s and Work groups
	251	Stakeholde rs
	252	It is nece ssary to i dentify an d involve all of the stakehold ers as par t of the R equirement s Modeling process t o effectiv ely provid e products and servi ces that m eet the ne eds of sta keholders and users. It is nec essary to identify t he users o f the syst em and ens ure that t he stakeho lder commu nity adequ ately repr esents the m. Provide a profile of the st akeholders and users involved in the req uest.There are a num ber of sta keholders with an in terest in the system ’s develop ment and n ot all of them are e nd users. Present a summary li st of the business o wner and t hese non-u ser stakeh olders. Th e stakehol ders ident ified in t his sectio n should b e linked t o the busi ness archi tecture. L ist all co ntributors to the BR D in this section. C ertain rep resentativ es may act in the ro le of more than one type of st akeholder.
	253	Stakeholde r Support Team (BRD Developmen t)
	254	Type of St akeholder
	255	Descriptio n
	256	Responsibi lities
	257	Delete thi s row afte r reviewin g instruct ional text .
	258	Name, (use Shift + E nter to pu t a charac ter return after the name)Titl e, Organiz ation of S takeholder
	259	Bullets sh ould only be used wh en listing more than one stake holder per cell.
	260	Summarize the stakeh olders’ ke y responsi bilities w ith regard to the sy stem being developed --that is, their int erest as a stakehold er. For ex ample, thi s stakehol der monito rs the pro ject’s pro gress and approves f unding.
	261	Requester
	262	Name
	263	Title, Org anization
	264	Submitted request. S ubmits bus iness requ irements. Monitors p rogress of request. Contribute s to BRD d evelopment .
	265	Endorser
	266	Name
	267	Title, Org anization
	268	Endorsed t his reques t. Provide s strategi c directio n to the p rogram. El icits exec utive supp ort and fu nding. Mon itors the progress a nd time li nes.
	269	Business O wner(s)/Pr ogram Offi ce(s)
	270	Name
	271	Title, Org anization
	272	Provide fi nal approv al of BRD with sign- off author ity. Provi de strateg ic directi on to the program. E licit exec utive supp ort and fu nding. Mo nitor the progress a nd time li nes.
	273	Business S ubject Mat ter Expert (s) (SME)
	274	Name
	275	Title, Org anization
	276	Provide ba ckground o n current system and processes . Describe features of current systems, including known prob lems. Iden tify featu res of enh ancement.
	277	Technical SME(s)
	278	Name
	279	Title, Org anization
	280	Provide te chnical ba ckground i nformation about the current s oftware an d requeste d enhancem ents.
	281	User SME(s )
	282	Name
	283	Title, Org anization
	284	Ensure tha t the enha ncements w ill accoun t for curr ent busine ss process es and exi sting soft ware capab ilities.
	285	Security R equirement s SME(s)
	286	Name
	287	Title, Org anization
	288	Responsibl e for dete rmining th e Certific ation and Accreditat ion (C&A) and other security r equirement s for the request.
	289	Service Co ordination SME(s)
	290	Name
	291	Title, Org anization
	292	Responsibl e for ensu ring all a spects of non-functi onal requi rements ha ve been ac curately r ecorded fo r this req uest.
	293	Business L iaison Sta ff
	294	Name
	295	Title, Org anization
	296	Serve as t he liaison between t he Program Office (B usiness Ow ner) and P roduct Dev elopment t hroughout the lifecy cle.
	297	Requiremen ts Analyst (s)
	298	Name
	299	Title, Org anization
	300	Responsibl e for work ing with a ll stakeho lders to e nsure the business r equirement s have bee n accurate ly recorde d for this request.
	301	Appendix D : Usabilit y Requirem ents
	302	User Exper ience enco mpasses di rect and i ndirect in teractions between t he user an d the syst em Improvi ng usabili ty over th e prior ve rsion is a key requi rement for this appl ication. T he Interna tional Org anization for Standa rdization (ISO) defi nes usabil ity as “th e extent t o which a product ca n be used by specifi ed users t o achieve specified goals with effective ness, effi ciency, an d satisfac tion in a specified context of use” (199 8).
	303	For an opt imal user experience the syste m must mee t the requ irements o utlined in this sect ion, which involve a ttributes of the app lication a nd the pro cess requi red to ach ieve them.
	304	In order t o improve usability of VA-deve loped or p urchased a pplication s, the fol lowing act ions are r equired:
	305	In accorda nce with t he Office of the Nat ional Coor dinator fo r Health I nformation Technolog y’s Meanin gful Use S tage 2 fin al ruling, employ an industry recognized User Cent ered Desig n (UCD) pr ocess. The methods f or UCD are well defi ned in doc uments and requireme nts such a s ISO 9241 –11, ISO 1 3407, ISO 16982, Nat ional Inst itute of S tandards a nd Technol ogy Intera gency Repo rt 7741, I SO/Interna tional Ele ctrochemic al Commiss ion 62366, and ISO 9 241-210. Developers will choo se their U CD approac h; one or more speci fic UCD pr ocesses wi ll not be prescribed .
	306	Adhere to an industr y recogniz ed User In terface (U I) Best Pr actices Gu ideline or Style Gui de. For ex ample, fir st follow UI guideli nes for th e developm ent platfo rm. In in stances wh ere platfo rm guideli nes are no t availabl e, adhere to VA’s Be st Practic es Guideli nes/Style Guide.
	307	Inform req uirements and design s with det ailed huma n factors work produ cts that h ave been/w ill be com pleted for the speci fic projec t. Example s of speci fic human factors ac tivities m ight inclu de heurist ic evaluat ions, site visits, i nterviews, applicati on-specifi c design g uides, and usability testing o n existing systems o r prototyp es.
	308	A sound UC D and deve lopment pr ocess base d on human factors s hould incl ude the fo llowing ac tivities:
	309	Understand ing of the users, th e users’ t asks, and the users’ environme nts
	310	Review of similar or competiti ve systems to inform requireme nts and de sign
	311	Heuristic evaluation of prior versions, prototypes , or basel ine applic ations, if applicabl e
	312	Iterative design and formative usability testing ( formative usability testing is used to d iscover us ability pr oblems dur ing the de sign and d evelopment process)
	313	User risk analysis
	314	Summative validation usability testing ( summative usability testing is used to q uantify an d validate usability of a prod uct with m easures of effective ness, effi ciency, us er percept ions, etc. )
	315	To demonst rate high usability, the appli cation sho uld be:
	316	Intuitive and easy t o learn, w ith minima l training
	317	Effective by allowin g users to successfu lly comple te tasks
	318	Efficient by allowin g users to complete their work in a mann er consist ent with c linical pr actice and workflow
	319	Perceived to have hi gh usabili ty, as dem onstrated by appropr iate surve y measures
	320	Designed t o aid user s in meeti ng task go als withou t being an additiona l burden
	321	The system must be r eliable an d enable u ser trust by providi ng:
	322	Stable and reliable performanc e
	323	Accurate d ata
	324	Display of all data that is av ailable in native or interface d systems and intend ed to be a vailable i n the appl ication
	325	Accessible informati on related to the so urce of da ta
	326	The applic ation shou ld include a modern Graphical User Inter face that allows the user to v iew data f rom multip le sources and inclu de:
	327	Integrated display o f structur ed and uns tructured data
	328	Rich data visualizat ion and gr aphical di splay of d ata
	329	Ability to switch be tween tabu lar and gr aphical da ta views
	330	Ability to interact with displ ayed data to obtain additional details r elated to the data a nd source of the dat a
	331	User custo mizable co mponents a nd setting s
	332	The applic ation must provide f or advance d and up-t o-date sea rching, to include:
	333	Fast searc h function ality with auto-comp lete and r eal-time d isplay of matched re sults duri ng typing
	334	Search his tory
	335	The applic ation must provide f or advance d filterin g capabili ties, to i nclude:
	336	Filtering of data ta bles, list s, and gri ds
	337	Filtering of search results
	338	The applic ation desi gn should be modifie d to:
	339	Address th e specific findings from a hum an factors heuristic evaluatio n conducte d on the p rior versi on of the applicatio n
	340	Address th e specific findings reported f rom field use of the prior ver sion
	341	Address th e specific findings reported f rom usabil ity testin g of the p rior versi on or rele vant proto types
	342	Identifier
	343	Usability/ User Inter face Requi rements
	344
	345	Left align content i n table ce lls to fac ilitate qu ick visual scan.
	346
	347	Left align text for column hea ders to fa cilitate v isual scan and make columns an d content appear mor e organize d.
	348
	349	Use mixed case inste ad of all caps whene ver possib le (e.g., dropdown l ist items, table dat a, table h eaders, hy perlinks, tab names) . Limit th e use of “ all caps” throughout the appli cation.
	350
	351	Simplify b utton labe ls. Re-lab el buttons to reflec t standard terminolo gy that is common in web inter faces and other appl ications ( e.g., “Can cel”). Emp hasize the action be ing perfor med in the most succ inct way p ossible. M inimize re dundancy i n text/ter minology t hat is use d to conve y the same action.
	352
	353	Left align page/sect ion titles to anchor titles in consisten t location s regardle ss of wind ow sizing.
	354
	355	Labels for fields sh ould be le ft aligned to facili tate quick visual sc an and mak e forms an d field gr oupings ap pear more organized.
	356
	357	Avoid usin g acronyms or abbrev iations un less (a) t hey are wi dely under stood/well known or (b) there is very li mited spac e to displ ay the ful l meaning. This supp orts naïve user unde rstanding. If limite d space re sults in u sing a non -common ac ronym/abbr eviation, ensure it is specifi ed within “Help” and /or as a t ooltip.
	358
	359	Use colors such as r ed and gre en only fo r status d riven cont ent. Avoi d using re d for text /content, links, but ton labels , etc. Thi s will red uce risk f or user er ror, impro ve link di scoverabil ity, and f acilitate understand ing of dif ferences i n navigati on/actions /content. It will a lso help u sers to is olate impo rtant stat us informa tion (usin g red, gre en, etc.) from other less impo rtant info rmation wh en viewing and proce ssing info rmation pr ovided to them on a page.
	360
	361	Provide vi sual separ ation betw een the na vigation s pace and t he main co ntent area .
	362
	363	Add field level vali dation and notificat ion of mis sing infor mation on the same p age withou t launchin g a new wi ndow or na vigating t o another page.
	364
	365	Make all t ext hyperl inks appea r consiste nt in styl e.
	366
	367	Make drop- down selec tion box w idths appr opriate fo r content and visual appeal.
	368
	369	Use standa rd and alw ays visibl e radio bu ttons for “Yes/No” o ptions ins tead of re quiring th e user to click in a drop down box and t hen click to select the “Yes” or “No” op tion.
	370
	371	Use standa rd date an d time sel ection wid gets. Whe re date an d time are selected/ picked fro m a standa rd widget, also prov ide direct data entr y to suppo rt keyboar d navigati on. Enabl e field le vel valida tion immed iately upo n entry. Include in structiona l format t ext within the field entry box .
	372
	373	Provide st andard sor t behavior and visua l indicati ons on col umns in al l tables.
	374
	375	Define and adhere to a standar d model fo r use and design of controls, buttons, h yperlinks, and navig ation elem ents.
	376
	377	Ensure tha t text is sized to b e readable (for exam ple, by us ing the 00 7 Rule to assure tex t size is readable f or users w ith 20/40 vision. Th e formula: Text heig ht = .007 * distance between e yes and sc reen).
	378
	379	Place comm on navigat ion elemen ts in cons istent loc ations.
	380
	381	Place crit ical infor mation “ab ove the fo ld” (i.e., in the to p portion of the scr een that i s immediat ely viewab le).
	382
	383	Use consis tent scree n flow mod els, eleme nts, and t erms to su pport simi lar workfl ows.
	384
	385	Use consis tently nam ed buttons when acti ons are th e same (e. g., Add vs . Save vs. Submit).
	386
	387	Enable use rs to prin t views fr om where t hey are in the inter face. Avo id requiri ng the use r to “run a report” in order t o print so mething th at is view able on th e screen.
	388
	389	Provide fi eld entry tool tips at the fie ld locatio n. Ensure consisten cy across the applic ation in f ield label s, formats , location of toolti ps, and to ol tip tex t.
	390
	391	Provide vi sual indic ation of r equired fi elds.
	392
	393	Display fi eld labels in close proximity to entry e lements.
	394
	395	Use consis tent eleme nts to fil ter data.
	396
	397	Use consis tent eleme nts to sor t data.
	398
	399	Use a cons istent mod el for dis play, layo ut, and gr ouping of data entry fields.
	400
	401	Provide al ternate ro w shading in lengthy tables of data, for m elements , etc.
	402
	403	Ensure tha t icons ar e recogniz ed by user s.
	404
	405	Provide so me “white space” bet ween statu s icons in report vi ews, white board vie ws, etc.
	406
	407	Auto-popul ate defaul t values i n entry/se lection fi elds when possible a nd appropr iate.
	408
	409	Visually d ifferentia te status icons from clickable icons, wh en appropr iate.
	410
	411	Define and support t he appropr iate user tab sequen ce through fields in forms in order to s upport key board navi gation whe n entering data in f orms.
	412
	413	Define and adhere to standard action but ton placem ent on scr eens, form s, etc.
	414
	415	Visually d istinguish the prima ry action button on a page.
	416
	417	Consistent ly use scr een elemen ts, action elements, workflow sequences within/acr oss screen s, languag e, etc.
	418
	419	Provide er ror messag es in user -centric l anguage wi th specifi c instruct ions on th e meaning of the err or and how to recove r from it. Use error messages and method of displa y consiste ntly acros s the inte rface.
	420
	421	Provide co ntext-spec ific Help.
	422
	423	Do not use the term “sex” or a ny like ab breviation s of that to represe nt gender.
	424	Appendix E : Acronyms and Abbre viations
	425	Include te rms used i n the docu ment and p rocess mod els other than instr uctional t ext.
	426	Term
	427	Definition
	428	BRD
	429	Business R equirement s Document
	430	HIPAA
	431	Health Ins urance Por tability a nd Account ability Ac t
	432	ISO
	433	Internatio nal Organi zation for Standardi zation
	434	IT
	435	Informatio n Technolo gy
	436	MAP
	437	Mobile App lication P rogram
	438	MTRS
	439	Mean Time to Restore
	440	OI&T
	441	Office of Informatio n and Tech nology
	442	PHI
	443	Protected Health Inf ormation
	444	PII
	445	Personally Identifia ble Inform ation
	446	RTM
	447	Requiremen ts Traceab ility Matr ix
	448	SLR
	449	Service Le vel Requir ements
	450	SME
	451	Subject Ma tter Exper t
	452	UCD
	453	User-Cente red Design
	454	UI
	455	User Inter face
	456	VA
	457	Department of Vetera ns Affairs
	458	VHA
	459	Veterans H ealth Admi nistration
	460	VistA
	461	Veterans H ealth Info rmation Sy stems and Technology Architect ure
	462	Appendix F : Approval Signature s
	463	This secti on is used to docume nt the app roval of t he BRD dur ing the Fo rmal Revie w. The rev iew should be ideall y conducte d face-to- face where signature s can be o btained ‘l ive’ durin g the revi ew. Howeve r, the fol lowing for ms of appr oval are a cceptable:
	464	Physical s ignatures obtained f ace-to-fac e or via f ax
	465	Digital si gnature ti ed cryptog raphically to the si gner
	466	/es/ in th e signatur e block, p rovided th at a separ ate digita lly-signed e-mail in dicating t he signer’ s approval is provid ed and kep t with the document
	467	The requir ements def ined in th is documen t are the high-level business requiremen ts necessa ry to meet the strat egic goals and opera tional pla ns of the <Program O ffice (ins ert name o f PO)>. Fu rther elab oration to these req uirements will be do ne in more -detailed artifacts.
	468	Business O wner
	469	Signifies that the c ustomer ap proves the documente d requirem ents, that they adeq uately rep resent the customers desired n eeds, and that the c ustomer ag rees with the define d scope.
	470
	471	Signed:___ __________ __________ __________ __________ __________ __________ __________ __________ _________
	472	<Business Owner Name and Title > Date
	473	Include ap proval mes sage attac hments HER E
	474	Business L iaison
	475	Signifies appropriat e identifi cation and engagemen t of neces sary stake holders an d the conf irmation a nd commitm ent to qua lity assur ance and c ommunicati on of busi ness requi rements to meet stak eholder ex pectations .
	476
	477	Signed:___ __________ __________ __________ __________ __________ __________ __________ __________ _________
	478	<Business Liaison Na me and Tit le> Da te
	479	Health Ent erprise Sy stems Mana ger (for V HA)
	480	XXXXX (for VBA)
	481	XXXXX (for NCA)
	482	XXXXX (for Corporate )
	483	Include ap proval mes sage attac hments HER E
	484
	485	Customer A dvocate
	486	Confirms t hat the re quest meri ts conside ration and review by the Busin ess Intake Review Bo ard.
	487
	488	Signed:___ __________ __________ __________ __________ __________ __________ __________ __________ __________
	489	<Customer Advocate N ame and Ti tle> Date
	490	Additional signature for out-o f-cycle re quests pro cessed thr ough the B usiness In take Revie w Board: D eputy Chie f Officer for Health Systems ( VHA)
	491	Executive Customer A dvocate Co rporateExe cutive Cus tomer Advo cate Benef its and Ce metery
	492	Include ap proval mes sage attac hments HER E
	493	Office of Informatio n and Tech nology
	494	Indicates agreement that the r equirement s have bee n received , are clea r, underst andable, a nd are doc umented su fficiently to facili tate proje ct plannin g when the project i s approved and funde d. It is u nderstood that negot iations ma y need to occur with the busin ess during project p lanning as a result of technic al reviews and feasi bility.
	495
	496	Signed:
	497	<OIT Name and Title> Date
	498	Include ap proval mes sage attac hments HER E
	499
	500