7. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 10/2/2017 3:33:01 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.

7.1 Files compared

#	Location	File	Last Modified
1	OSCIF_ CPRS Enh P1_OR_3.0_439_build_4_August_2017.zip	GMTS_27_120 Design Document.docx	Fri Sep 29 16:04:00 2017 UTC
2	OSCIF_ CPRS Enh P1_OR_3.0_439_build_4_August_2017.zip	GMTS_27_120 Design Document.docx	Mon Oct 2 15:18:27 2017 UTC

7.2 Comparison summary

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

7.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

7.4 Active regular expressions

No regular expressions were active.

7.5 Comparison detail

	1	Detailed D esign – Me dication R econciliat ion Worksh eet (Tool #2)
	2	Software D etailed De sign
	3	Conceptual Design
	4	Product Pe rspective
	5	Currently, on the Me dication W orksheet ( aka, Medic ation Reco nciliation Tool #2 ( MRT2)), no n-VA medic ations do not displa y in the s ame way as VA prescr ibed medic ations.
	6
	7	This reque st is to r emove the inconsiste ncies in t he display on the pa tient-faci ng report generated from Healt h Summary data and g iven to a patient wh en admitte d, dischar ged or tra nsferred. Per the Jo int Commis ions’s NPS G.03.06.01 , a medica tion summa ry must be given to a patient upon each admission, discharge or transf er. The do cument use d currentl y does not display n on-VA medi cation inf ormation a s thorough ly as it d oes VA med ications.
	8	Software I nterfaces
	9	FileMan v2 2.0
	10	Health Sum mary v2.7
	11	Order Entr y/Results Reporting v3.0
	12	National D rug File v 4.0
	13	Outpatient Pharmacy v7.0
	14	Pharmacy D ata Manage ment v1.0
	15	Registrati on v5.3
	16	Kernel v8. 0
	17	Product Fe atures
	18	This subse ction shou ld provide a summary of the ma jor featur es of the software.
	19	For exampl e, an SDD for an acc ounting pr ogram migh t use this section t o address customer a ccount mai ntenance, customer s tatement, and invoic e preparat ion withou t mentioni ng the vas t amount o f detail t hat each o f those fe atures req uires.
	20	Note: For clarity, r emember th ese items when creat ing this s ection of the SDD:
	21	The featur es should be organiz ed in a wa y that mak es the lis t of featu res unders tandable t o the cust omer or to anyone el se reading the docum ent for th e first ti me.
	22	Textual or graphical methods c an be used to show t he differe nt feature s and thei r relation ships.
	23	Such a dia gram is no t intended to show a design of a product , but simp ly shows t he logical relations hips among variables .
	24	User Chara cteristics
	25	The Medica tion Works heet (MRT #2) is use d by VA St aff that d o Medicati on Counsel ing with p atients.
	26	Dependenci es and Con straints
	27	This subse ction shou ld provide a descrip tion of an y other it ems that w ill limit the develo per’s opti ons. The f ollowing l ist includ es items t hat limit the develo per’s opti ons.
	28	Regulatory policies
	29	Hardware l imitations (for exam ple, signa l timing r equirement s)
	30	Interfaces to other applicatio ns
	31	Parallel o peration
	32	Audit func tions
	33	Control fu nctions
	34	Higher-ord er languag e requirem ents
	35	Reliabilit y requirem ents
	36	Criticalit y of the a pplication
	37	Safety and security considerat ions
	38	Usability (including 508 compl iance)
	39	This secti on of the SDD should contain a ll the sof tware desi gn to a le vel of det ail suffic ient to en able progr ammers to develop a system tha t satisfie s the requ irements d efined in the RSD. I t should b e detailed so as to make it ea sy for tec hnical sta ff to find the metho ds to comp lete the d esigned fu nction.
	40	These requ irements s hould, at minimum, i nclude the following items:
	41	An indicat ion of the associate d requirem ent(s) in the RSD wh ich is bei ng designe d
	42	A descript ion of the functiona lity being designed
	43	The design entities (and their attribute s) affecte d
	44	The algori thm execut ed (where appropriat e) to impl ement the functional ity.
	45	Because th e Dependen cies and C onstraints section i s often th e largest and most i mportant p art of the SDD, the following principles apply:
	46	Specific d esign shou ld be cros s-referenc ed to earl ier, relat ed documen ts (e.g., the RSD).
	47	All design should be uniquely identifiab le.
	48	Items in t his sectio n should b e identifi ed from a technical level rath er than an end user level. (i. e., an opt ion name s hould be i dentified rather tha n the menu text for that optio n).
	49	Specific R equirement s
	50	Database R epository
	51	The Databa se Reposit ory sectio n in the R SD can be referenced in this s ection.
	52	If a logic al databas e design i s a part o f the syst em, it sho uld be lis ted here. Logical da tabase des ign should specify t he logical requireme nts for an y informat ion that i s to be pl aced into a database . This may include:
	53	Types of i nformation used by v arious fun ctions
	54	Frequency of use
	55	Accessing capabiliti es
	56	Data entit ies and th eir relati onships
	57	Integrity constraint s
	58	Data reten tion requi rements.
	59	Recommenda tion: Crea te a block diagram s howing the databases and where the data resides.
	60	System Fea tures
	61	Describe t he system features, functional requireme nts, sub-r equirement s, etc. wh ich can be organized in an out line forma t that mat ches the R SD. Specif ic formatt ing and or ganization of the pa ragraphs ( i.e., sect ion number ing) is le ft to the discretion of the au thor and i s dependen t on the l evel of de tail essen tial to fu lly descri be the des ign. Some designs ma y only req uire two l evels; oth ers may re quire mult iple level s. The inf ormation n ecessary t o define t he items o r to speci fy modific ations to the items affected b y the func tionality being desi gned shoul d be provi ded in the appropria te design element ta bles. Wher e feasible , instead of duplica ting the R SD, it can be refere nced via a link, to avoid unne cessary du plication. The key g oal is to provide tr aceability to requir ements.
	62	Design Ele ment Table s
	63	Routines ( Entry Poin ts)
	64	Table 14: Routines ( Instructio ns)
	65
	66	Table 15 ( Grouping): Routines
	67	Routines
	68	Activities
	69	Routine Na me
	70	GMTSPST2
	71	Enhancemen t Category
	72	New
	73	Modify
	74	Delete
	75	No Change
	76	Related Op tions
	77	CPRS GUI, Reports Ta b, Health Summary Re ports, Med ication Wo rksheet
	78
	79
	80	Routines
	81	Activities
	82	Data Dicti onary (DD) Reference s
	83	No updates to Data D ictionary.
	84	Related Pr otocols
	85	None
	86	Related In tegration Control Re gistration s (ICRs)
	87	None
	88
	89	Current Lo gic
	90	Non-VA Med ications a re separat ed and lis ted in lis t-only for mat. The w orksheet g rids do no t print fo r each ind ividual me dication.
	91	Modified L ogic
	92	Non-VA Med ications w ill now sh ow in an i ndividual listing, w ith a grid for each medication to allow the VA per son doing medication review to indicate times for administra tion