5. EPMO Open Source Coordination Office Redaction File Detail Report

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

5.1 Files compared

#	Location	File	Last Modified
1	OSCIF_ CPRS Enh P1_OR_3.0_439_build_4_August_2017.zip	CPRS.EP1.system_design_document - September 2016.docx	Fri Sep 29 16:04:08 2017 UTC
2	OSCIF_ CPRS Enh P1_OR_3.0_439_build_4_August_2017.zip	CPRS.EP1.system_design_document - September 2016.docx	Sat Sep 30 01:38:50 2017 UTC

5.2 Comparison summary

Description	Between Files 1 and 2
Description	Text Blocks	Lines
Unchanged	4	4104
Changed	3	7
Inserted	0	0
Removed	0	0

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

5.4 Active regular expressions

No regular expressions were active.

5.5 Comparison detail

1	Computeriz ed Patient Record Sy stem
2	Enhancemen ts Phase I
3	System Des ign Docume nt
4
5
6
7	September 2016
8	Version 1. 0
9
10	Department of Vetera ns Affairs
11
12
13	Revision H istory
14	Date
15	Version
16	Descriptio n
17	Author
18	9/29/2016
19	1.1
20	Added chan ges for NS R 20100911
21	PII
22	8/24/2016
23	1.0
24	Initial Ve rsion
25	PII
26	Place late st revisio ns at top of table.
27	The Revisi on History pertains only to ch anges in t he content of the do cument or any update s made aft er distrib ution. It does not a pply to th e formatti ng of the template.
28	Remove bla nk rows.
29
30	Artifact R ationale
31	The System Design Do cument (SD D) is a du al-use doc ument that provides the concep tual desig n as well as the as- built desi gn. This document w ill be upd ated as th e product is built, to reflect the as-bu ilt produc t.
32
33
34	When to Co mplete Eac h Section of the SDD
35	Section
36	Completed On or Befo re PMAS Ph ase
37	Rationale
38	1 – Introd uction
39	MS 0 Revie w; updated thereafte r
40	Conceptual design sh ould infor m evaluati on of inve stments
41	2 - Backgr ound
42	MS 0 Revie w; updated thereafte r
43	Conceptual design sh ould infor m evaluati on of inve stments
44	3 – Concep tual Desig n
45	MS 0 Revie w; updated thereafte r
46	Conceptual design sh ould infor m evaluati on of inve stments
47	4 – System Architect ure
48	MS 0 Revie w; updated thereafte r
49	Conceptual design sh ould infor m evaluati on of inve stments
50	5 – Data D esign
51	MS 1 Revie w; updated thereafte r
52	Design det ails shoul d be elabo rated upon during PM AS Plannin g phase an d prior to developme nt
53	6 – Detail ed Design
54	MS 1 Revie w; updated thereafte r
55	Design det ails shoul d be elabo rated upon during PM AS Plannin g phase an d prior to developme nt
56	7 – Extern al System Interface Design
57	MS 1 Revie w; updated thereafte r
58	Design det ails shoul d be elabo rated upon during PM AS Plannin g phase an d prior to developme nt
59	8 – Human Machine In terfaces
60	MS 1 Revie w; updated thereafte r
61	Design det ails shoul d be elabo rated upon during PM AS Plannin g phase an d prior to developme nt
62	Attachment s
63	MS 1 Revie w; updated thereafte r
64	Design det ails shoul d be elabo rated upon during PM AS Plannin g phase an d prior to developme nt
65
66	A product’ s system d esign shou ld be defi ned concep tually pri or to the allocation of person nel and re sources th at occur a t project initiation . This gi ves the en terprise a n opportun ity to eva luate IT i nvestments before pr oject team s are stoo d up and f unding is allocated. Sections 1- 4 whic h discuss the high l evel desig n should b e complete d prior to MS 0. All sections should be completed and update d before M S 1. Proj ects will need to ad dress all SDD approv al constra ints prior to the MS 2 review. In addit ion, the S DD should reflect th e as-built product g oing into the MS 2 r eview.
67
68
69	Activity
70	New Capabi lity (1)
71	Feature En hancement (2)
72	Field Depl oyment (A)
73	Yes
74	Yes
75	Cloud/Web Deployment (B)
76	No
77	No
78	Mobile App lication ( C)
79	No
80	No
81
82	Table of C ontents
83	1.Introduc tion1
84	1.1.Scope1
85	1.2.User P rofiles1
86	2.Backgrou nd1
87	2.1.Overvi ew of the System1
88	2.2.Overvi ew of the Business P rocess1
89	2.3.Overvi ew of the Significan t Requirem ents1
90	3.Conceptu al Design2
91	3.1.Concep tual Appli cation Des ign2
92	3.1.1.Appl ication Co ntext2
93	3.1.2.High -Level App lication D esign4
94	3.1.3.Appl ication Lo cations7
95	3.2.Concep tual Data Design8
96	3.2.1.Proj ect Concep tual Data Model8
97	3.2.2.Data base Infor mation8
98	3.2.3.User Interface Data Mapp ing8
99	3.2.3.1.Ap plication Screen Int erface9
100	3.2.3.1.1. <Insert na me of scre en>9
101	3.2.3.2.Ap plication Report Int erface9
102	3.2.3.2.1. <Insert na me of repo rt>9
103	3.2.3.3.Un mapped Dat a Element1 0
104	3.3.Concep tual Infra structure Design10
105	3.3.1.Syst em Critica lity and H igh Availa bility10
106	3.3.2.Spec ial Techno logy11
107	3.3.3.Tech nology Loc ations11
108	3.3.4.Conc eptual Inf rastructur e Diagram1 2
109	3.3.4.1.Lo cation of Environmen ts and Ext ernal Inte rfaces12
110	3.3.4.2.Co nceptual P roduction String Dia gram14
111	4.System A rchitectur e14
112	4.1.Hardwa re Archite cture14
113	4.2.Softwa re Archite cture14
114	4.3.Networ k Architec ture14
115	4.4.Servic e Oriented Architect ure / ESS1 4
116	4.5.Enterp rise Archi tecture15
117	5.Data Des ign16
118	5.1.DBMS F iles16
119	5.2.Non-DB MS Files16
120	5.3.Data V iew17
121	6.Detailed Design17
122	6.1.Hardwa re Detaile d Design17
123	6.2.Softwa re Detaile d Design17
124	6.2.1.Conc eptual Des ign17
125	6.2.1.1.Pr oduct Pers pective18
126	6.2.1.1.1. User Inter faces18
127	6.2.1.1.2. Hardware I nterfaces1 8
128	6.2.1.1.3. Software I nterfaces1 8
129	6.2.1.1.4. Communicat ions Inter faces18
130	6.2.1.1.5. Memory Con straints19
131	6.2.1.1.6. Special Op erations19
132	6.2.1.2.Pr oduct Feat ures19
133	6.2.1.3.Us er Charact eristics19
134	6.2.1.4.De pendencies and Const raints19
135	6.2.2.Spec ific Requi rements20
136	6.2.2.1.Da tabase Rep ository20
137	6.2.2.2.Sy stem Featu res21
138	6.2.2.3.De sign Eleme nt Tables2 1
139	6.2.2.3.1. Routines ( Entry Poin ts)21
140	6.2.2.3.2. Templates2 3
141	6.2.2.3.3. Bulletins2 4
142	6.2.2.3.4. Data Entri es Affecte d by the D esign25
143	6.2.2.3.5. Unique Rec ord(s)25
144	6.2.2.3.6. File or Gl obal Size Changes25
145	6.2.2.3.7. Mail Group s26
146	6.2.2.3.8. Security K eys27
147	6.2.2.3.9. Options29
148	6.2.2.3.10 .Protocols 30
149	6.2.2.3.11 .Remote Pr ocedure Ca ll (RPC)32
150	6.2.2.3.12 .Constants Defined i n Interfac e32
151	6.2.2.3.13 .Variables Defined i n Interfac e33
152	6.2.2.3.14 .Types Def ined in In terface33
153	6.2.2.3.15 .GUI33
154	6.2.2.3.16 .GUI Class es33
155	6.2.2.3.17 .Current F orm34
156	6.2.2.3.18 .Modified Form34
157	6.2.2.3.19 .Component s on Form3 4
158	6.2.2.3.20 .Events34
159	6.2.2.3.21 .Methods34
160	6.2.2.3.22 .Special R eferences3 4
161	6.2.2.3.23 .Class Eve nts34
162	6.2.2.3.24 .Class Met hods34
163	6.2.2.3.25 .Class Pro perties35
164	6.2.2.3.26 .Uses Clau se35
165	6.2.2.3.27 .Forms35
166	6.2.2.3.28 .Functions 36
167	6.2.2.3.29 .Dialog37
168	6.2.2.3.30 .Help Fram e38
169	6.2.2.3.31 .HL7 Appli cation Par ameter39
170	6.2.2.3.32 .HL7 Logic al Link40
171	6.2.2.3.33 .COTS Inte rface40
172	6.3.Networ k Detailed Design41
173	6.4.Securi ty and Pri vacy41
174	6.4.1.Secu rity41
175	6.4.2.Priv acy42
176	6.5.Servic e Oriented Architect ure / ESS Detailed D esign43
177	6.5.1.Serv ice Descri ption for <Consumed Service Na me>43
178	6.5.2.Serv ice Design for <Prov ided Servi ce Name>43
179	6.5.2.1.In troduction 43
180	6.5.2.1.1. Purpose an d Scope of Service43
181	6.5.2.1.2. Links to O ther Docum ents43
182	6.5.2.2.Se rvice Deta ils44
183	6.5.2.2.1. Service Id entificati on44
184	6.5.2.2.2. Service Ve rsions45
185	6.5.2.2.3. Summary of Design an d Platform Details45
186	6.5.2.2.3. 1.SOA Patt ern(s) Imp lemented45
187	6.5.2.2.3. 2.COTS Pla tform vend or names a nd version s for host ing platfo rm45
188	6.5.2.3.De pendencies 45
189	6.5.2.4.Se rvice Desi gn Details 45
190	6.5.2.4.1. Interface Technical Specs45
191	6.5.2.4.1. 1.Service Invocation Type46
192	6.5.2.4.1. 2.Service Interface Type46
193	6.5.2.4.1. 3.Service Name46
194	6.5.2.4.1. 4.Interfac e46
195	6.5.2.4.1. 5.End Poin ts46
196	6.5.2.4.1. 6.Operatio ns or Meth ods46
197	6.5.2.4.1. 7.Message Schemas46
198	6.5.2.4.2. Informatio n Model47
199	6.5.2.4.2. 1.Class Di agram and Descriptio n of Entit ies Involv ed47
200	6.5.2.4.2. 2.Mappings from ELDM to Standa rds Based Schemas47
201	6.5.2.4.3. Behavior M odel (AKA Use Case R ealization )47
202	6.5.2.4.3. 1.Use Case s (Use Cas e Model)47
203	6.5.2.4.3. 2.Interact ion Diagra ms47
204	6.5.2.5.Ga p Analysis 47
205	6.5.2.5.1. Variances from Enter prise Targ et Archite cture48
206	6.5.2.5.2. Variances from SLDs4 8
207	6.5.2.5.3. Variances from Stand ards and P olicies48
208	6.5.2.5.4. Justificat ion for Ex ceptions a nd Mitigat ion48
209	7.External System In terface De sign48
210	7.1.Interf ace Archit ecture48
211	7.2.Interf ace Detail ed Design4 9
212	8.Human-Ma chine Inte rface50
213	8.1.Interf ace Design Rules50
214	8.2.Inputs 50
215	8.3.Output s50
216	8.4.Naviga tion Hiera rchy51
217	8.4.1.Scre en [x.1]51
218	8.4.2.Scre en [x.2]51
219	8.4.3.Scre en [x.3]51
220	9.Attachme nt A – App roval Sign atures51
221	A.Addition al Informa tion52
222	A.1.Identi fication o f Technolo gy and Sta ndards52
223	A.2.Constr aining Pol icies, Dir ectives an d Procedur es52
224	A.3.Requir ements Tra ceability Matrix52
225	A.4.Packag ing and In stallation 52
226	A.5.Design Metrics52
227
228	Introducti on
229	Identify a nd provide a brief i ntroductio n of the s ystem that is the su bject of t his SDD.
230	Scope
231	The CPRS E P1 BRD can be found at:
232	CPRS EP1 B usiness Re quirements Document
233
234	User Profi les
235	There are several ty pes of hea lth profes sionals wh o use Comp uterized P atient Rec ord System (CPRS). P rimarily, the intend ed users a re clinici ans such a s physicia ns, nurses and pharm acists who are deali ng with pa tient care . In addit ion, there are labor atorians, financial staff and others who use CPRS to find pa tient-rela ted inform ation. The se users a re trained on how to use and c ustomize i t to fit t heir needs per their required needs. The re are a l arge numbe r of docum ents and p resentatio ns on many of the fu nctions of CPRS, inc luding onl ine traini ng. To acc ommodate t he varying proficien cy levels vary among those usi ng CPRS, s upport is provided v ia multipl e channels , such as context-se nsitive he lp, variou s support teams, web sites and training on specifi c features of the so ftware.
236	The Inform ation Tech nology (IT ) staff wh o support CPRS are t ypically s upporting multiple s ystems and are famil iar with s upport and maintenan ce of Vete rans Healt h Informat ion System s and Tech nology Arc hitecture (VistA) sy stems. Doc umentation is provid ed with ea ch release of CPRS, covering p roper inst allation t echniques, and suppo rt is prov ided by th e developm ent team d uring depl oyment. In addition, there are staff ava ilable to assist the IT repres entatives should pro blems aris e.
237	Background
238	Overview o f the Syst em
239	CPRS provi des an int egrated pa tient reco rd system for clinic ians, mana gers, Qual ity Assura nce (QA) s taff, and researcher s. The pri mary goal of CPRS is to provid e a fast a nd easy-to -use appli cation tha t makes av ailable to providers the infor mation nee ded in the clinical workflow p rocess. Th e CPRS use r interfac e is integ rated with VistA to facilitate reviewing , document ing and pr eserving o f coordina ted care i nformation and impro ved access ibility of online cl inical inf ormation a nd results .
240	Overview o f the Busi ness Proce ss
241	CPRS EP1 s upports th e followin g business processes :
242	Medication order ent ry in both CPRS and Inpatient Medication s
243	Review of patient’s electronic charts
244	Improved p atient saf ety relate d to patie nt selecti on and dis play areas
245	The Requir ements Spe cification Document (RSD) is c ontained i n Rational Dynamic O bject Orie nted Requi rements Sy stem (DOOR S) Next Ge neration ( NG) and ca n be obtai ned from t he followi ng link:
246	DOORS NG - EP1 - Req uirements
247	Overview o f the Sign ificant Re quirements
248	The CPRS E P1 Busines s Requirem ents Docum ent (BRD) can be fou nd at the following link:
249	CPRS EP1 B usiness Re quirements Document
250	The RSD is contained in Ration al DOORS N Gand can b e obtained from the following link:
251	DOORS NG - EP1 - Req uirements
252	1.GENDER/S EX FIELD I N VETERANS HEALTH IN FORMATION SYSTEMS AN D TECHNOLO GY ARCHITE CTURE (Vis tA)/COMPUT ER PATIENT RECORD SY STEM (CPRS ) - REQUES T #2013030 5
253	2.ALLOW TR ANSFER BET WEEN INPAT IENT, OUTP ATIENT, AN D Non-VA M EDS- REQUE ST #200806 17
254	3.CLINIC O RDERS – IN PATIENT ME DICATIONS EDITS AND BACKDOOR E NTRY- REQU EST #20120 502
255	4.ADDITION OF A FUNC TION TO EN TER STOP A ND START D ATES FOR M EDICATIONS IN CPRS- REQUEST #2 0090602
256	5.Medicati on Reconci liation Wo rksheet No n-VA MEDIC ATION DOSE ENHANCEME NT – REQUE ST #201009 11
257	6.CPRS OPT ION TO PRO HIBIT MEDI CATION REN EWAL- REQU EST 201108 09
258	7.Non-VA M EDICATION VIEW INCON SISTENCY- REQUEST #2 0110315
259	8.PHARMACY VISTA ORD ERS TO DIS PLAY DATES IN MM/DD/ YYYY FORMA T, AND ADD A HARD ST OP FOR DAT E ENTRY- R EQUEST #20 111103
260	9.ADDRESS NOTIFICATI ON SOFTWAR E PROBLEM SEEN WHEN AN ORDERIN G PROVIDER CHANGES R OLE- REQUE ST #201305 04
261	10.PATIENT SELECTION – SIMILAR PATIENTS BOX –REQUE ST #201310 05
262	11.CPRS: A LLERGY VIE W/PREVENT ORDERING M EDS THAT C AUSE ANAPH YLAXIS- RE QUEST #201 31101
263	Conceptual Design
264	This secti on of the SDD provid es details about the following topics:
265	Conceptual Applicati on Design
266	Conceptual Data Desi gn
267	Conceptual Infrastru cture Desi gn
268	Conceptual Applicati on Design
269	Provide de tails of t he ‘As-is” view of t he existin g system a long with the design of “the c urrent inc rement” an d the “To- be.”. The “To-Be” v iew should include t he future applicatio n context, and appli cation hig h level de sign. The “current i ncrement” view shoul d have app lication c ontext and high leve l design o f this spe cific incr ement that this SDD addresses.
270	Applicatio n Context
271	.
272	Provide a diagram sh owing the context wi thin which the appli cation exi sts. The d iagram sho uld includ e:
273	One object for the s ystem that is the su bject of t his design ,
274	One object for each system or external s ervice wit h which th is system interfaces ,
275	One object for each Program Of fice syste m or subsy stem with which this system in teracts, a nd
276	One for ea ch data st ore that t his system shares wi th other s ystems.
277
278
279
280	Figure 1: Sample App lication C ontext Dia gram
281	Table 5 de scribes th e informat ion in the Applicati on Context Diagram i n four sec tions. Not e that the system fo r which th is design applies is represent ed by a si ngle objec t (typical ly in the center of the diagra m). Theref ore, it is not refer red to in Table 5 be low.
282	Table 5 (G rouping): Applicatio n Context Descriptio n
283	Object
284	ID
285	Name
286	Descriptio n
287	Interface Name
288	Interface System
289	< ID from diagram>
290	<Enter nam e of exter nal system , organiza tion, or a gency>
291	<High leve l discussi on of the purpose of the infor mation int erchange>
292	<Name of e ach of the Interface s to this object>
293	<Systems w ith which this syste m interfac es>
294	Interfaces External to OI&T
295	ID
296	Name
297	Related Ob ject
298	Input Mess ages
299	Output Mes sages
300	External P arty
301	< ID from diagram>
302	<Interface name from the objec t rows abo ve>
303	<Object fr om the lis t above th at is the source of this inter face>
304	<For each input mess age, enter a busines s descript ion of the data bein g input>
305	<For each output mes sage, ente r a busine ss descrip tion of th e data bei ng output>
306	<Name of e xternal pa rty>
307
308	Interfaces Internal to OI&T
309	ID
310	Name
311	Related Ob ject
312	Input Mess ages
313	Output Mes sages
314	External P arty
315	< ID from diagram>
316	<Interface name from the objec t rows abo ve>
317	<Object fr om the lis t above th at is the source of this inter face>
318	<For each input mess age, enter a busines s descript ion of the data bein g input>
319	<For each output mes sage, ente r a busine ss descrip tion of th e data bei ng output>
320	<Name of e xternal pa rty>
321	Externally Shared Da ta Stores
322	ID
323	Name
324	Data Store d
325	Owner
326	Access
327	< ID from diagram>
328	<Name of t he data st ore>
329	<Descripti on of the data being stored>
330	<This Syst em / Name of OIT or external o rganizatio n>
331	<Enter the Create, R ead, Updat e, or Dele te (CRUD) operations that this system do es on this data stor e>
332	High-Level Applicati on Design
333	The High-L evel Appli cation Des ign identi fies the m ajor compo nents of t he applica tion and t he relatio nships of the major applicatio n componen ts to each other and to the su rrounding applicatio ns. The ma jor compon ents of th e applicat ion are at the subsy stem or to p-level se rvice area . Many dif ferent gra phical for mats are a cceptable for the Hi gh-Level A pplication Design Di agram. Low er-level s ervices wi ll be defi ned and do cumented i n the Logi cal Applic ation Desi gn section .
334	Error! Ref erence sou rce not fo und. illus trates a H igh-Level Applicatio n Design i n the form of a data flow diagr am. This d iagram dif fers from the diagra m in Figur e 2 in tha t the sing le object representi ng this sy stem in Fi gure 2 is decomposed into its major comp onents. Us e
335	Table 6 to describe the object s in Error ! Referenc e source n ot found..
336	Note: If a n extensio n to a leg acy system is being developed without us e of servi ces, all r eferences to “Servic e” should be changed to “Subsy stem.”
337	A Collabor ation Diag ram, or in the case of Service s, a Servi ce Capabil ity Diagra m may be i ncluded in stead or a n Applicat ion Diagra m if it il lustrates the subjec t better.
338
339
340
341	Figure 2: Sample Hig h-Level Ap plication Design
342
343	Table 6: O bjects in the High L evel Appli cation Des ign
344	Objects / Components to be Bui lt or Modi fied
345	ID
346	Name
347	Descriptio n
348	Service or Legacy Co de
349	External I nterface N ame
350	External I nterface I D
351	Internal I nterface N ame
352	Internal I nterface I D
353	SDP Sectio ns 1&2
354	< ID from diagram>
355	<Name of h igh level service or internal subsystems >
356	<Business level disc ussion of the functi on or role of the se rvice or s ubsystem>
357	<Service / modificat ion to leg acy system >
358	<Name of e ach of the external interfaces to this o bject>
359	<ID of eac h of the e xternal in terfaces t o this obj ect>
360	<Name of e ach of the internal interfaces to this o bject>
361	<ID of eac h of the i nternal in terfaces t o this obj ect>
362	[Approved / Submitte d / Being Developed]
363	Internal D ata Stores
364	ID
365	Name
366	Data Store d
367	Steward
368	Access
369	< ID from diagram>
370	<Name of t he data st ore>
371	<Descripti on of the data being stored>
372	<Name of t he system/ subsystem /service t hat is the steward f or the dat a>
373	<Which CRU D operatio ns does th is system do on this data stor e>
374	Applicatio n Location s
375	Use Table 7 to speci fy the loc ations at which the applicatio n componen ts will be hosted.
376	Considerat ion should be given to adopt c loud techn ologies as potential solutions . Leveragi ng cloud t echnologie s is part of a large r effort b y the Offi ce of Mana gement and Budget (O MB) to ref orm Federa l IT Manag ement. Co nsideratio ns such as regional deployment s etc. sho uld be doc umented in this sect ion.
377	Table 7: A pplication Locations
378	Applicatio n Componen t
379	Descriptio n
380	Location a t Which Co mponent is Run
381	Type
382	<Component name>
383	<Descripti on>
384	<Facility name>
385	<Presentat ion Logic/ Business L ogic/Data Logic/Inte rface Code >
386	Table 8: A pplication Users
387	Applicatio n Componen t
388	Location
389	User
390	<Component name>
391	<Facility name>
392	<Role>
393	Conceptual Data Desi gn
394	Project Co nceptual D ata Model
395	A project conceptual data mode l (CDM) is a high-le vel repres entation o f the data entities and their relationsh ips. It do es not nor mally incl ude the da ta element s that com prise each entity. I t is a fir st step to ward devel oping the more detai led logica l data mod el (LDM) t hat will b e provided during th e Logical Data Desig n.
396	Figure 3 i llustrates a sample of a proje ct CDM.
397	Figure 3: Sample Pro ject Conce ptual Data Mode
398
399	Database I nformation
400	Use Table 9 to ident ify all th e database s that wil l be creat ed, replac ed, interf aced with, or whose structure will be mo dified (i. e., add or delete ta bles or ad d or delet e columns to a table ) as part of this ef fort.
401	Table 9: D atabase In ventory
402	Database N ame
403	Descriptio n
404	Type
405	Steward
406	<Name>
407	<Descripti on>
408	<Create/Re place/Inte rface /Mod ify>
409	<Applicati on/Organiz ation that is the st eward>
410	User Inter face Data Mapping
411	This secti on describ es and def ines the f ormat and informatio n that wil l be avail able for u sers of th e product to be able to enter data into the databa se or to r etrieve in formation from the d atabase, i f applicab le.
412	Applicatio n Screen I nterface
413	Create a n ew subsect ion for ea ch screen of the Gra phical Use r Interfac e (GUI) th at users w ill have a ccess to, in order t o enter or update in formation in the dat abase.)
414	<Insert na me of scre en>
415	Figure 4: <screen na me> Screen represent s the scre en that <d escribes w hat the sc reen accom plishes>; Table 10 d escribes i t. Paste a screensho t below an d complete the table to descri be the scr een.
416
417
418
419	Figure 4: <screen na me> Screen
420	Table 10: <screen na me> Screen Descripti on
421	Graphical User Inter face (GUI) Field
422	Table (Dat abase Tabl e that fie ld connect s to)
423	Field (Fie ld in Tabl e that the GUI field connects to)
424	Comments
425	<Name>
426	<xxx>
427	<PATIENT_ NAME>
428	<Add any c omments or descripti ve informa tion that would be r elevant to the teste r>
429	<SSN>
430	<xxx>
431	<SSN>
432
433	Date of Bi rth (Age)
434	<yyyy>
435	DATE_OF_BI RTH DATE_O F_DEATH (i f deceased )
436
437	Applicatio n Report I nterface
438	This secti on describ es and def ines the r eports tha t will be available in the use r interfac e, if appl icable.
439	<Insert na me of repo rt>
440	<Create a new subsec tion for e ach report > Figure 6 represent <name> sc reen and T able 16 de scribes it …
441	Figure 5 r epresents the <repor t name>; T able 11 de scribes it . Paste a screenshot of the re port below and compl ete the ta ble to des cribe the report.
442
443
444
445	Figure 5: < Report n ame> Repor t
446
447	Table 11: <Report na me> Descri ption
448	Report Col umn
449	Data Sourc e <Table N ame. Field name>
450	Patient
451	<xxx.PATIE NT_NAME>
452	SSN
453	<xxx.SSN>
454	DoB
455	<yyyy.DATE _OF_BIRTH>
456	Unmapped D ata Elemen t
457	In this se ction desc ribe any d atabase el ement that was not m apped to a screen an d the reas on the dat a element( s) was not mapped. T his sectio n may be s kipped if there is n o User Int erface inv olved in t he project , such a b uilding a service of fering etc .
458	Conceptual Infrastru cture Desi gn
459	The Concep tual Infra structure Design sho uld descri be any uni que techno logy that will be us ed, which are either part of t his system , or will attach to this syste m.
460	. Because the system is at a p reliminary design st age, it is expected that the i nformation provided may need t o be chang ed during later desi gn stages or increme nts.
461	The Concep tual Infra structure Design is a high-lev el overvie w of the i nfrastruct ure that w ill be use d to suppo rt the app lication. Primary em phasis is on the env ironments that will be require d and the locations at which t hey will b e installe d. The Con ceptual In frastructu re Design becomes mo re detaile d at later stages as more info rmation is collected regarding the syste m, and the infrastru cture requ irements ( i.e., capa city requi rements) a re better known.
462	System Cri ticality a nd High Av ailability
463	Describe t he approac h that wil l be taken to meetin g the syst em critica lity and h igh availa bility req uirements identified in Sectio n 2.5.6, i ncluding t he extent to which g eographica lly distri buted, hig h availabi lity desig ns are pla nned. Desc ribe the a pproach th at is take n towards high avail ability as well as a ny workloa d distribu tion schem e that is planned to support t he high av ailability implement ation (e.g ., restric ting updat es to a si ngle node) .
464	If the sys tem is not mission c ritical an d high ava ilability is not req uired, the n describe the appro ach that w ill be tak en to prov ide the re quisite le vel of ava ilability and disast er recover y.
465	Special Te chnology
466	If any spe cial techn ology was identified in Sectio n 2.5.9 as part of t his system , describe the devic e and the type of lo cation at which it w ill be ins talled. Th is informa tion may b e provided using Tab le 12.
467	Table 12: Special T echnology Requiremen ts
468	Special Te chnology
469	Descriptio n
470	Notional L ocation
471	TRM Status
472	<Name>
473	n/a. no sp ecial tech nology for CPRS EP1
474	<Business language d escription >
475	<At what t ype of loc ation will this tech nology be deployed?>
476	<Is this t echnology in the Tec hnical Ref erence Mod el (TRM)?
477	(Yes / No) >
478	Technology Locations
479	This secti on describ es the var ious techn ology comp onents tha t will be used. If known, pro vide the n ame of the datacente r at which the techn ology will be instal led. If no t, specify as Site A , Site B e tc. Provid e this inf ormation i n Table 13 .
480	Table 13: Technology Location Details
481	Technology Component
482	Production 1
483	Location
484	Usage
485	Workstatio ns
486
487
488	Special Ha rdware
489
490
491	Interface Processors
492
493
494	Legacy Mai nframe
495
496
497	Legacy App lication S erver
498
499
500	Legacy Dat abases
501
502
503	Other
504
505
506
507	Technology Component
508	Production 2
509	Location
510	Usage
511	<copy from Prod 1 se t, or ente r new ones as approp riate>
512
513
514
515	Technology Component
516	Certificat ion
517	Location
518	Usage
519
520
521
522
523	Technology Component
524	Education
525	Location
526	Usage
527
528
529
530
531	Technology Component
532	Test
533	Location
534	Usage
535
536
537
538
539	Technology Component
540	Developmen t
541	Location
542	Usage
543
544
545
546	Conceptual Infrastru cture Diag ram
547	Location o f Environm ents and E xternal In terfaces
548	Create a d iagram to show the e nvironment s that wil l be suppo rted. As i llustrated in
549	Figure 6, the diagr am should show the f ollowing:
550	Local netw orks to wh ich they w ill be att ached (Pro duction, T est, or De velopment)
551	Locations at which t hey will b e installe d
552	External c onnections (each ext ernal inte rface shou ld be show n in terms of where it enters the networ k).
553
554
555
556	Figure 6: Sample Co nceptual N etworks an d Environm ents
557
558	Conceptual Productio n String D iagram
559	Create a d iagram to show the c onfigurati on of a si ngle produ ction stri ng.
560	Additional component s, such as the mainf rame, othe r Web serv ers, or ot her major components should be included if they ar e expected to be req uired.
561
562
563
564	Figure 7: Conceptual Productio n String D iagram
565	System Arc hitecture
566	This secti on describ es the sys tem and/or subsystem (s) archit ecture for the proje ct. Discus s the gene ral archit ectural de cisions th at have be en approve d. Include diagrams where appr opriate.
567	Hardware A rchitectur e
568	CPRS is a legacy app lication t hat provid es a GUI f ront-end t o the Vist A system a nd is prim arily used by physic ians, nurs es and oth er clinici ans respon sible for providing patient ca re. As suc h, it uses the exist ing VistA hardware a rchitectur e.
569	Some VistA instances are local to the VA Medical C enters (VA MC) that u se it. Oth ers are in stalled in Regional Data Proce ssing Cent ers (RDPC) . Most of these inst ances have hot backu p sites lo cated in a nother, ge ographical ly separat ed, locati on.
570	The primar y architec ture at th is time is a cluster of Linux servers th at act as the applic ation serv er with th e client w orkstation s connecti ng to this cluster. This Linux cluster i s connecte d to a clu ster of VM S servers that act a s the data base serve r, where t he VistA d atabase re sides.
571	The client workstati ons may be local to the VAMC o r they may be remote at Commun ity Based Outpatient Clinics ( CBOC), oth er VAMCs ( in the cas e of integ rated site s) or may even be on e-off remo te worksta tions that connect v ia Citrix Access Gro up (CAG) o r Virtual Private Ne twork (VPN ).
572	While pers onnel outs ide of Pro duct Devel opment are responsib le for det ermining t he best co nfiguratio ns and ens uring adeq uate hardw are and ne twork conn ectivity, the CPRS E P1 project considers additiona l space an d potentia l performa nce impact s. The ult imate goal is to add no more t han 5% to disk space or Centra l Processi ng Unit (C PU) requir ements.
573	During the field tes ting phase , any addi tional fil es created are monit ored to en sure this is not exc eeded. Loc al and reg ional IT s taff monit or the sys tems and n otify CPRS developme nt if the resource d emands exc eeds expec tations ba sed on the developme nt environ ment.
574
575	Software A rchitectur e
576	CPRS is a legacy app lication t hat provid es a GUI f ront-end t o the Vist A system a nd is prim arily used by physic ians, nurs es and oth er clinici ans respon sible for providing patient ca re. CPRS E P1 will no t change t hat underl ying softw are archit ecture.
577	CPRS EP1 w ill use De lphi and M assachuset ts general hospital Utility Mu lti-Progra mming Syst em (MUMPS) as the pr imary prog ramming la nguages.
578	CPRS EP1 i s currentl y using Ra tional Cha nge and Co nfiguratio n Manageme nt (CCM) a s the sour ce code co ntrol syst em.
579	CPRS EP1 r equires no additiona l software for suppo rt, outsid e the exis ting VistA infrastru cture.
580	Network Ar chitecture
581	CPRS is a legacy app lication t hat provid es a GUI f ront-end t o the Vist A system a nd is prim arily used by physic ians, nurs es and oth er clinici ans respon sible for providing patient ca re. The ex ecutable p ortion of CPRS EP1 w ill contin ue communi cate using the exist ing networ k architec ture that supports t he legacy VistA syst ems.
582	CPRS EP1 u ses remote procedure calls (RP Cs) over t he local, or wide, a rea networ k to commu nicate bet ween the c lient and the VistA instance. This commu nication u ses Kernel ’s broker package.
583	Reference the hardwa re archite cture for a high-lev el overvie w of the c ommunicati on pathway s.
584	Service Or iented Arc hitecture / ESS
585	CPRS is a legacy app lication t hat provid es a GUI f ront-end t o the Vist A system a nd is prim arily used by physic ians, nurs es and oth er clinici ans respon sible for providing patient ca re. CPRS E P1 will en hance the existing C PRS system .
586	Refer to t he VistA M onograph f or a full explanatio n of the l arger syst em of whic h CPRS EP1 is a part .
587	Note: The CPRS archi tecture do es not sup ply new se rvices nor does it c onsume exi sting serv ices.
588	Enterprise Architect ure
589	CPRS EP1 i s using De lphi XE8 f or the Del phi develo pment.
590	The server -side code is writte n using Ca che/MUMPS, which is approved u nder the T RM.
591
592	Data Desig n
593	This secti on outline s the desi gn of the database m anagement system (DB MS) and no n-DBMS fil es associa ted with t he system. For netwo rks, detai l the dist ribution o f data and identify any change s to the l ogical dat a model th at may occ ur due to software o r hardware requireme nts.
594	Note: Prov ide a data dictionar y appendix showing d ata elemen t name, ty pe, length , source, validation rules, ma intenance, data stor es, output s, aliases , and desc ription.
595	DBMS Files
596	If a datab ase will b e used lis t and desc ribe the l ogical req uirements that exist for data formats, s torage cap abilities, data rete ntion, dat a integrit y, etc.
597	Describe h ow the dat abase will be design ed, includ ing the fo llowing in formation, as approp riate:
598	Logical mo del; provi de normali zed table layouts, e ntity rela tionship d iagrams, a nd other l ogical des ign inform ation
599	DBMS schem as, subsch emas, reco rds, sets, tables, s torage pag e sizes
600	Access met hods (such as indexe d, via set , sequenti al, random access, s orted poin ter array)
601	Estimate t he databas e file siz e or volum e of data within the file, dat a pages, i ncluding o verhead re sulting fr om access methods an d free spa ce
602	Definition of the up date frequ ency of th e database tables, v iews, file s, areas, records, a nd sets
603	Estimates on the num ber of tra nsactions that the d atabase ma y have to process.
604	Non-DBMS F iles
605	Describe a ll non-DBM S files in cluding na rratives o n the usag e of each file.
606	Identify i f the file is used f or input, output, or both; ide ntify temp orary file s, which m odules rea d and writ e the file , and simi lar.
607	Identify r ecord stru ctures, re cord keys, indices, and refere nce data e lements wi thin the r ecords.
608	Define rec ord length and block ing factor s.
609	Define the file acce ss method such as: i ndex seque ntial, vir tual seque ntial, ran dom access .
610	Estimate t he file si ze or volu me of data within th e file.
611	Define the update fr equency of the file if appropr iate. Prov ide the es timated nu mber of tr ansactions per unit time and t he statist ical mean, mode, and distribut ion of tho se transac tions.
612	Data View
613	A "Data Vi ew" should be includ ed in the Architectu ral Repres entation w henever pe rsistent d ata object s are incl uded in th e system ( they are t ypically p resent in most softw are system s). The da ta view de scribes th e logical data model of the sy stem and i ncludes an Entity Re lationship Diagram ( ERD). For a descript ion of Ent ity Relati onship dia gramming p lease refe r to the w hitepaper <http:// URL
		614
615	Detailed D esign
616	This secti on describ es the pro posed desi gn in deta il. Provid e the nece ssary info rmation fo r the deve lopment te am to inte grate the hardware c omponents and write the softwa re code, s o that the hardware and softwa re compone nts will p rovide a f unctional product. T his is the detailed design, ba sed upon t he concept ual design (high lev el) that w as describ ed in the document u p to this point.
617	Note: Ever y design i tem should map back to the Req uirements Specificat ion Docume nt. These should be captured i n the Requ irement Tr aceability Matrix (R TM).
618	Hardware D etailed De sign
619	N/A. CPRS EP1 will u se the exi sting hard ware infra structure and will b e designed to requir e no signi ficant inc rease in d ata storag e capacity nor CPU r esources.
620	Software D etailed De sign
621	This secti on provide s conceptu al and fin al detaile d informat ion associ ated with the design of the so ftware bei ng deliver ed. This s hould be a n extensio n of the c orrespondi ng section from Sect ion 3.1, b ut should contain ad ditional d etail as t he project progresse s.
622	Conceptual Design
623	This secti on introdu ces the co nceptual i nformation that esta blishes th e basis fo r how the software w ill be bui lt.
624	Product Pe rspective
625	This subse ction of t he SDD sho uld put th e product into persp ective wit h other re lated prod ucts. If t he product is indepe ndent and completely self-cont ained, it should be stated her e. If the SDD define s a produc t that is a componen t of a lar ger system , then thi s subsecti on should relate the requireme nts of tha t larger s ystem to f unctionali ty of the software a nd should identify i nterfaces between th at system and the so ftware.
626	A block di agram show ing the ma jor compon ents of th e larger s ystem, int erconnecti ons, and e xternal in terfaces c an be help ful.
627	Sections o f the RSD can be ref erenced in the subse ctions, if applicabl e.
628	User Inter faces
629	This subse ction shou ld specify the logic al charact eristics o f each int erface bet ween the s oftware pr oduct and its users. This incl udes those configura tion chara cteristics necessary to accomp lish the s oftware re quirements (e.g., sc reens, rol l and scro ll, GUI in terface).
630	Recommenda tion: Crea te a block diagram s howing the user inte rfaces.
631	Hardware I nterfaces
632	CPRS EP1 w ill enhanc e the exis ting CPRS system. No modificat ions to th e existing hardware interfaces are plann ed.
633	Currently, CPRS, usi ng the Ker nel system , will sup port any d evice that Kernel su pports. CP RS EP1 wil l not cont rol this s upport.
634	Software I nterfaces
635	CPRS commu nicates wi th all the VistA cli nical appl ications a nd several of the fi nancial ap plications . In addit ion, CPRS uses FileM an and Ker nel. CPRS is written using the current n ationally released v ersions of each of t hese packa ges and pl ans to con tinue to u se and sup port the c urrently r eleased ve rsions.
636	Communicat ion Interf aces
637	No modific ations wil l be made to the exi sting comm unication interfaces , which ar e under th e control of Enginee ring.
638	Memory Con straints
639	N/A
640	Special Op erations
641	N/A
642	Product Fe atures
643	User Chara cteristics
644	CPRS is us ed primari ly by clin icians suc h as physi cians, nur ses, physi cian assis tants, nur se practit ioners, ph armacists and other ancillary clinical u sers.
645	Dependenci es and Con straints
646	CPRS EP1 m ust utiliz e the exis ting hardw are and ne twork infr astructure . Therefor e, the inc rease in n etwork, me mory, CPU and data s torage sho uld not be significa nt. Some r emote inst allations, such as C BOCs are p articularl y suscepti ble.
647	CPRS EP1 m ust be 508 user acce ssibility compliant.
648	The design must take into acco unt that C PRS is a m ission cri tical appl ication.
649	Specific R equirement s
650	Database R epository
651	Data for C PRS EP1 wi ll be stor ed in the existing V istA datab ase.
652	System Fea tures
653	Please ref er to the RSD:
654	The RSD is contained in DOORS NG and can be obtain ed from th e followin g link:
655	DOORS NG - EP1 - Req uirements
656	Design Ele ment Table s
657	The design element t ables are provided f or your co nvenience. Copy each table as many times as necess ary to add ress multi ple items within eac h section. Add rows and headin gs to the tables to provide an y addition al require d informat ion to def ine the it em or to s pecify the modificat ions to th e item. Nu mbering of the desig n element tables to align them underneat h the appl icable req uirement o r sub-requ irement is recommend ed, but is left to t he author’ s discreti on. For th at reason they are n ot numbere d in this template.
658	Routines ( Entry Poin ts)
659	This secti on is an i llustratio n that is VistA spec ific. The authors ar e free to organize t his inform ation by t echnology, different templates , or optio nal sectio ns dependi ng on the task at ha nd.
660	Complete t he table f or each ro utine affe cted by th e function ality bein g designed .
661	Table 14: Routines ( Instructio ns)
662	Routines
663	Instructio ns
664	Routine Na me
665	List the r outine aff ected by t he functio nality bei ng designe d.
666	Enhancemen t Category
667	Check the appropriat e box: New , Modify, Delete, or No Change .
668	RTM
669	List the R SD item nu mber withi n the SDD (i.e., If the RSD ha s a requir ement of 3 .3.1, add Support fo r a new AP I, then in this colu mn list RS D Requirem ent 3.3.1)
670	Related Op tions
671	List optio ns that di rectly cal l or are c alled by t he routine .
672	Related Ro utines
673	List routi nes that d irectly ca ll or are called by the routin e.
674	Data Dicti onary (DD) Reference s
675	List files that refe rence the routine th rough inpu t transfor ms, cross reference logic, etc .
676	Related Pr otocols
677	List proto cols that reference or are ref erenced by the routi ne.
678	Related In tegration Control Re gistration s (ICRs)
679	List propo sed new IC Rs and sub scribed IC Rs. Also, list any o bscure Sup ported ICR s.
680	Data Passi ng
681	Check the appropriat e box. Als o a short descriptio n of what invokes th e new/chan ged routin e should b e included in this s ection. An example o f such a d escription would be a note tha t the new/ changed ro utine will be invoke d as part of a funct ion call o r it would be invoke d through user menu- driven opt ions, syst em protoco ls, HL7 Lo gical Link s, etc. Th is section refers sp ecifically to the ch ange imple mented wit h the desi gn.
682	Input Attr ibute Name and Defin ition
683	List the I nput Attri butes pass ed into th e new or c hanged rou tine logic . Each att ribute sho uld be def ined.
684	Output Att ribute Nam e and Defi nition
685	List the O utput Attr ibutes ret urned from the new o r changed routine lo gic. Each attribute should be defined.
686	Current Lo gic
687	Define the current l ogic in th e routine that the d esign will modify. I f this is new code, enter “N/A ”.
688	Modified L ogic (Chan ges are in bold)
689	Define the logic in the routin e that the design wi ll impleme nt.
690
691	NSR: 20100 911 – Medi cation Rec onciliatio n Workshee t Non-VA M edication
692	Routines
693	Activities
694	Routine Na me
695	GMTSPST2
696	Enhancemen t Category
697	New
698	Modify
699	Delete
700	No Change
701	RTM
702	555637, 38 6545, 6652 75
703	Related Op tions
704	Medication worksheet in CPRS
705
706	Related Ro utines
707	Routines “ Called By”
708	Routines “ Called”
709
710	Only calle d from CPR S MWS Heal th Summary option
711	Standard F ileMan DBS calls
712	GMTSUP
713	ORCSAVE2
714	ORQ12
715	ORWPS
716	ORX8
717	PSNAPIS
718	PSO52API
719	PSO59
720	PSS50
721	VADPT
722	VASITE
723	XLFDT
724
725	Routines
726	Activities
727	Data Dicti onary (DD) Reference s
728	None
729	Related Pr otocols
730	None
731	Related In tegration Control Re gistration s (ICRs)
732	None
733	Data Passi ng
734	Input
735	Output Re ference
736	Both
737	Global Re ference
738	Local
739	Input Attr ibute Name and Defin ition
740	Name: DFN
741	Definition : Internal Entry num ber of the patient i n file #2
742	Output Att ribute Nam e and Defi nition
743	Name:
744	Definition :
745
746	Current Lo gic
747
748
749	Modified L ogic (Chan ges are in bold)
750	---------- ---------- ---------- ---------
751	GMTSPST2.I NT.1
752	+108 ;I $P(LI STNODE,"^" ,1)["N;" D
753	+109 ;. S:$P( LISTNODE," ^",4)="ACT IVE" NVA($ P(LISTNODE ,"^",2),+L ISTNODE)=
754	LISTNODE
755	+110 ;. S RET URN=1
756	.......... .........
757	\|"CPRS31"\| GMTSPST2.I NT.1
758	+108 I $P(LIS TNODE,"^", 1)["N;" D
759	+109 . S:$P(L ISTNODE,"^ ",4)="ACTI VE" NVA($P (LISTNODE, "^",2),+LI STNODE)=L
760	ISTNODE
761
762	+110 . S RETU RN=1
763	---------- ---------- ---------- ---------
764	GMTSPST2.I NT.1
765	+122 . I $P(R XS(RXSIEN) ,";")["P"! ($P(RXS(RX SIEN),";") ["N") D GE TPEND(RXS
766	IEN) S PSO QPEND=1 Q ;->
767	.......... .........
768	\|"CPRS31"\| GMTSPST2.I NT.1
769	+122 . I $P(R XS(RXSIEN) ,";")["P" D GETPEND( RXSIEN) S PSOQPEND=1 Q ;->
770	---------- ---------- ---------- ---------
771	GMTSPST2.I NT.1
772	+157 N PSOQPD N,PSOQDIND ,PSOQ100,P SOQSCT,GMT SPST2,A
773	.......... .........
774	\|"CPRS31"\| GMTSPST2.I NT.1
775	+157 N PSOQPD N,PSOQDIND ,PSOQ100,P SOQSCT,GMT SPST2
776
777	GMTSPST2.I NT.1
778	+165 S A=$P(R XS(RXSIEN) ,";")
779	+166 I A["P" F PSOQSCT= 2:1:$O(GMT SPST2(":") ,-1) S RXS ("D","PE NDING "
780	_PSOQPDN,P SOQSCT)=GM TSPST2(PSO QSCT)
781	+167 I A["N" F PSOQSCT= 2:1:$O(GMT SPST2(":") ,-1) S RXS ("D","NO N-VA "_
782	PSOQPDN,PS OQSCT)=GMT SPST2(PSOQ SCT)
783
784
785	.......... .........
786	\|"CPRS31"\| GMTSPST2.I NT.1
787	+165 F PSOQSC T=2:1:$O(G MTSPST2(": "),-1) S R XS("D"," PENDING "_PSOQPDN
788	,PSOQSCT)= GMTSPST2(P SOQSCT)
789
790	Routines
791	Activities
792	Routine Na me
793
794	Enhancemen t Category
795	New
796	Modify
797	Delete
798	No Change
799	RTM
800
801	Related Op tions
802
803
804	Related Ro utines
805	Routines “ Called By”
806	Routines “ Called”
807
808
809
810
811	Routines
812	Activities
813	Data Dicti onary (DD) Reference s
814
815	Related Pr otocols
816
817	Related In tegration Control Re gistration s (ICRs)
818
819	Data Passi ng
820	Input
821	Output Re ference
822	Both
823	Global Re ference
824	Local
825	Input Attr ibute Name and Defin ition
826	Name:
827	Definition :
828	Output Att ribute Nam e and Defi nition
829	Name:
830	Definition :
831
832	Current Lo gic
833
834
835	Modified L ogic (Chan ges are in bold)
836
837	Templates
838	Complete T able 16 fo r each tem plate affe cted by th e function ality bein g designed . A short descriptio n of what change wil l be made to the tem plates sho uld be inc luded in t his sectio n.
839	Note: If p referred, copy and p aste this section di rectly fro m VA FileM an DDs ins tead of us ing the ta bles.
840	Table 16: Templates (Instructi ons)
841	Templates
842	Instructio ns
843	Template N ame
844	Identify t he templat e affected by the fu nctionalit y being de signed
845	Enhancemen t Category
846	Check the appropriat e box: New , Modify, Delete, or No Change .
847	RSD Tracea bility
848	List the R equirement Specifica tion Docum ent (RSD) item numbe r within t he SDD (i. e., If the RSD has a requireme nt of 3.3. 1, add Sup port for a new API, then this column sho uld list R SD Require ment 3.3.1 )
849	Template T ype
850	Indicate t he type of template identified (Sort, In put, or Pr int).
851	Related Op tions
852	List optio ns that di rectly cal l or are c alled by t he templat e.
853	Related Ro utines
854	List routi nes that d irectly ca ll or are called by the templa te.
855	Data Dicti onary (DD) Reference s
856	List files /fields th at referen ce the tem plate(s) t hrough inp ut transfo rms, and c ross refer ence logic .
857	Global Ref erences
858	List the I CRs for gl obal refer ences that are outsi de your na mespace.
859	Table 17: Templates
860	Templates
861	Descriptio n
862	Template N ame
863
864	Enhancemen t Category
865	New
866	Modify
867	Delete
868	No Change
869	RSD
870
871	Template T ype
872	Sort
873	Input
874	Print
875	Other
876	Related Op tions
877
878
879	Related Ro utines
880	Routines “ Called By”
881	Routines “ Called”
882
883
884
885
886	Routines
887	Descriptio n
888	Data Dicti onary (DD) Reference s
889
890	Global Ref erences
891
892	Bulletins
893	If the pro ject devel ops or aff ects bulle tins, then complete this secti on; if not then stat e that the section i s not appl icable and delete th e tables a nd content of the se ction. Com plete the table for each bulle tin affect ed by the functional ity being designed. A short de scription of what ch ange will be made to the bulle tins shoul d be inclu ded in thi s section.
894	Note: If p referred, copy and p aste this section di rectly fro m VA FileM an DDs ins tead of us ing the ta bles.
895	Table 18: Bulletins (Instructi ons)
896	Bulletins
897	Instructio ns
898	Bulletin N ame
899	List the s pecific bu lletin aff ected by t he functio nality bei ng designe d.
900	Enhancemen t Category
901	Check the appropriat e box: New , Modify, Delete, or No Change .
902	RTM
903	List the R SD item nu mber withi n the SDD (i.e., If the RSD ha s a requir ement of 3 .3.1, add Support fo r a new AP I, then in this colu mn list RS D Requirem ent 3.3.1) .
904	Related Op tions
905	List optio ns that di rectly sen d the bull etin.
906	Related Ro utines
907	List routi nes that d irectly se nd the bul letin.
908	Mail Subje ct
909	List the s ubject of the mail m essage, i. e., which bulletin t his affect s.
910	Mail Group
911	List the m ail group (recipient s) of the mail messa ge.
912	Parameters
913	List neces sary param eters.
914	Data Dicti onary (DD) Reference s
915	List files /fields th at referen ce the bul letin(s) t hrough inp ut transfo rms, cross reference logic, et c. should be listed under Data Dictionar y (DD) Ref erences.
916
917	Table 19: Bulletins
918	Bulletins
919	Descriptio n
920	Bulletin N ame
921
922	Enhancemen t Category
923	New
924	Modify
925	Delete
926	No Change
927	RTM
928
929
930	Related Ro utines
931	Routines “ Called By”
932	Routines “ Called”
933
934
935
936
937	Routines
938	Descriptio n
939	Mail Subje ct
940
941	Mail Group
942
943	Parameters
944
945	Data Dicti onary (DD) Reference s
946
947	Data Entri es Affecte d by the D esign
948	Provide th e followin g data for each fiel d to be cr eated, mod ified, or deleted or provide a “Before a nd After: Data Entri es Affecte d by the D esign.”
949	Identify t he entries affected by the des ign. If a blanket ch ange will be made to each entr y affected , that cha nge should be define d in this table.
950	Only chang es that ar e unique t o each rec ord should be define d in the U nique Reco rd(s) sect ion (Secti on 6.2.2.3 .5). Redun dant infor mation sho uld not be entered i nto each c hart in th e Unique R ecord(s) s ection.
951	Table 20: Data Entri es Affecte d by the D esign
952	Field Name
953	Current Va lue
954	New Value
955
956
957
958	Unique Rec ord(s)
959	List the u nique reco rd ID(s) t hat will b e affected by the ch anges impl emented by the desig n. This is commonly done in th e .01 fiel d. The val ues define d in the C urrent Val ue and New Value col umns shoul d be the e xact value of the da ta. For ea ch unique record ID, copy this table and provide t he informa tion.
960	Table 21: Unique Rec ord ID
961	Field Name (s)
962	Current Va lue
963	New Value
964
965
966
967	File or Gl obal Size Changes
968	Indicate t he change to the siz e of the f ile or glo bal as a r esult of t he design implemente d with thi s descript ion. Globa l size cha nges tie b ack to the business requiremen ts and RSD . Growth o r reductio n in the s ize of the global sh ould be in dicated in this sect ion. If th e file is static acr oss all Vi stA system s, a blank et stateme nt of how the change will affe ct the siz e of the g lobal will suffice.
969	For exampl e, “The Na tional Pro cedure fil e is a new file and will requi re 8.7K of disk spac e to insta ll.”
970	If a file is dynamic and its s ize may va ry from Vi stA system to VistA system, th e descript ion should indicate the change in the fi le per rec ord and th e number o f records that the s ite may an ticipate. For exampl e, if a fi eld is bei ng added t o the pati ent file t hat will r esult in a n increase of 7K per patient, the site c an estimat e the glob al growth based on t he number of entries in that f ile.
971	Note: If t he Capacit y Planning analysis is availab le, then e nter it he re. If not , then use the Proje ct Team pr ojection.
972	Table 22: File or Gl obal Size Changes
973	File/Globa l Name(s)
974	Estimated Increase
975	Estimated Decrease
976
977
978
979	Mail Group s
980	Complete t he table f or each of the mail groups aff ected by t he functio nality bei ng designe d. A short descripti on of what changes w ill be mad e to the a ffected ma il groups should be included i n this sec tion.
981	Note: If p referred, this can b e captured directly from VA Fi leMan DDs after the fact.
982	Table 23: Mail Group s (Instruc tions)
983	Mail Group s
984	Instructio ns
985	Mail Group Name
986	List the n ame of the mail grou p being mo dified. Th e mail gro up name ma y include a domain n ame.
987	Enhancemen t Category
988	Check the appropriat e box: New , Modify, Delete, or No Change .
989	Related Op tions
990	List optio ns that di rectly ref erence the file.
991	Related Ro utines
992	List routi nes that r eference t he mail gr oup.
993	Data Dicti onary (DDs ) Referenc es
994	List files that refe rence the mail group through i nput trans forms, cro ss-referen ce logic, etc.
995	Related Pr otocols
996	List proto cols that directly r eference t he mail gr oup.
997	Mail Group Descripti on
998	Describe t he purpose for the m ail group.
999	Self-Enrol lment Allo wed
1000	Check the appropriat e box eith er Yes or No.
1001	Type
1002	Check the appropriat e box eith er Public or Private .
1003	Table 24: Mail Group s
1004	Mail Group s
1005	Activities
1006	Mail Group Name
1007
1008	Enhancemen t Category
1009	New
1010	Modify
1011	Delete
1012	No Change
1013	Related Op tions
1014
1015
1016	Related Ro utines
1017	Routines “ Called By”
1018	Routines “ Called”
1019
1020
1021
1022
1023	Mail Group s
1024	Instructio ns
1025	Data Dicti onary (DD) Reference s
1026
1027	Related Pr otocols
1028
1029	Mail Group Descripti on
1030
1031	Self-Enrol lment Allo wed
1032	Yes
1033	No
1034	Type
1035	Public
1036	Private
1037	Security K eys
1038	This secti on lists t he specifi c security keys affe cted by th e function ality bein g designed . A short descriptio n of the c hanges tha t will be made to th e security keys affe cted shoul d be inclu ded in thi s section.
1039	Note: If p referred, this can b e captured directly from VA Fi leMan DDs after the fact.
1040	Table 25: Security K eys (Instr uctions)
1041	Security K eys
1042	Instructio ns
1043	Security K ey Name
1044	List the s pecific na me of the security k ey being m odified.
1045	Enhancemen t Category
1046	Check the appropriat e box: New , Modify, Delete, or No Change .
1047	Related Op tions
1048	List optio ns that di rectly ref erence the security key.
1049	Related Ro utines
1050	List routi nes that r eference t he securit y key.
1051	Data Passi ng
1052	Check the appropriat e box. Ent er a short descripti on of an e vent that would trig ger the ne w/changed routine, f or example , a note t hat the ch ange to th e security key will be referen ced throug h user men u driven o ptions, ro utines, et c. This se ction refe rs specifi cally to t he change implemente d with the design.
1053	Security K ey Descrip tion
1054	List a bri ef descrip tion of th e security key.
1055	Subordinat e Keys
1056	List any s ubordinate keys.
1057	Mutually E xclusive K eys
1058	Enter the name of a key that m ay not be held joint ly with th is one.
1059	Granting C ondition L ogic
1060	Define the logic for the Grant ing Condit ion of the Security Key affect ed by the functional ity being designed.
1061	Current Lo gic
1062	If the sec urity key currently has a gran ting condi tion, defi ne the cur rent logic for that granting c ondition. If the sec urity key did not ex ist before , indicate that ther e is curre ntly no se curity key .
1063	Modified L ogic (Chan ges are in bold)
1064	Define the granting condition that the d esign will implement . If the s ecurity ke y is new t o the fiel d, define the logic here.
1065	Hierarchic al Precede nce
1066	Define whi ch key is used if on e key will take prec edence ove r another key.
1067	Table 26: Security K eys
1068	Security K eys
1069	Activities
1070	Security K ey Name
1071
1072	Enhancemen t Category
1073	New
1074	Modify
1075	Delete
1076	No Change
1077	Related Op tions
1078
1079
1080	Related Ro utines
1081	Routines “ Called By”
1082	Routines “ Called”
1083
1084
1085
1086
1087	Security K eys
1088	Activities
1089	Data Passi ng
1090	Input
1091	Output
1092	Both
1093	Global Re ference
1094	Local Ref erence
1095	Security K ey Descrip tion
1096
1097	Subordinat e Keys
1098
1099	Mutually E xclusive K eys
1100
1101	Granting C ondition L ogic
1102
1103
1104	Current Lo gic
1105
1106
1107	Modified L ogic (Chan ges are in bold)
1108
1109
1110	Security K eys
1111	Activities
1112	Hierarchic al Precede nce
1113
1114	Options
1115	Complete t he table f or each of the optio ns affecte d by the f unctionali ty being d esigned. A short des cription o f the chan ges that w ill be mad e to the o ptions aff ected shou ld be incl uded. Chan ges to the OPTION fi le (#19) a re to be i ncluded, n ot the fun ctionality of the op tion invok ed.
1116	Note: If p referred, this can b e captured directly from VA Fi leMan DD a fter the f act.
1117	Table 27: Options (I nstruction s)
1118	Options
1119	Instructio ns
1120	Option Nam e
1121	(MENU TEXT field)
1122	Enter the name of th e option a ffected.
1123	Enhancemen t Category
1124	Check the appropriat e box: New , Modify, Delete, or No Change
1125	Associated Menu Opti ons that w ill invoke this refe rence
1126	List the m enu type o ptions on which the respective option is or will b e containe d.
1127	Data Passi ng
1128	Check the appropriat e box. Als o a short descriptio n of what invokes th e new/chan ged routin e should b e included in this s ection. An example o f such a d escription would be a note tha t the chan ge to the option wil l be refer enced thro ugh VA Mai lman serve r messages , user sel ection of the option from the VA Kernel Menu Manag ement syst em, etc. T his sectio n refers s pecificall y to the c hange impl emented wi th the des ign.
1129	Menu Text Descriptio n
1130	Enter the name of th e option a s it will be display ed to the user withi n the menu system.
1131	Option Typ e
1132	Specify th e type of option
1133	Option Def inition
1134	Provide al l the info rmation ne cessary to fully def ine the op tion. Incl ude option s that are included in the men u, if appl icable.
1135	Current En try Action Logic
1136	Define the current l ogic for t he entry a ction of t he option affected b y the func tionality being desi gned. If t he entry a ction did not exist before, in dicate tha t there cu rrently is no entry action.
1137	Modified E ntry Actio n Logic (C hanges are in bold)
1138	Define the entry act ion that t he design will imple ment. If t he entry a ction is n ew to the field, def ine the lo gic here.
1139	Current Ex it Action Logic
1140	Define the current l ogic for t he exit ac tion of th e option a ffected by the funct ionality b eing desig ned. If th e exit act ion did no t exist be fore, indi cate that there curr ently is n o exit act ion.
1141	Modified E xit Action Logic
1142	(Changes a re in bold )
1143	Define the exit acti on that th e design w ill implem ent. If th e exit act ion is new to the fi eld, defin e the logi c here.
1144
1145
1146
1147
1148	Table28: O ptions
1149	Options
1150	Activities
1151	Option Nam e
1152
1153	Enhancemen t Category
1154	New
1155	Modify
1156	Delete
1157	No Change
1158	Associated Menu Opti ons that w ill invoke this refe rence
1159
1160	Data Passi ng
1161	Input
1162	Output
1163	Both
1164	Global Re ference
1165	Local Ref erence
1166	Menu Text Descriptio n
1167
1168	Option Typ e
1169	Edit
1170	Print
1171	Menu
1172	Inquire
1173
1174	Action
1175	Run Routi ne
1176	Other
1177
1178	Associated Routine
1179
1180	Option Def inition
1181
1182
1183	Current En try Action Logic
1184
1185
1186	Modified E ntry Actio n Logic (C hanges are in bold)
1187
1188
1189	Current Ex it Action Logic
1190
1191
1192	Modified E xit Action Logic (Ch anges are in bold)
1193
1194	Protocols
1195	Complete t he table f or each of the proto cols affec ted by the functiona lity being designed. A short d escription of the ch anges that will be m ade to the protocols affected should be included i n this sec tion. Chan ges to the PROTOCOL file (#101 ) are to b e included , not the functional ity of the protocol invoked.
1196	Note: If p referred, this can b e captured directly from VA Fi leMan DDs after the fact.
1197	Table29: P rotocols ( Instructio ns)
1198
1199	Protocols
1200	Instructio ns
1201	Protocol N ame
1202	List the n ame of the protocol affected.
1203	Enhancemen t Category
1204	Check the appropriat e box: New , Modify, Delete, or No Change .
1205	Associated Protocols
1206	List the a ncestors o f the prot ocol being designed, i.e., tho se protoco ls that co ntain the respective protocol as an item .
1207	Data Passi ng
1208	Check the appropriat e box. An event that would tri gger the n ew/changed protocol should be included i n this sec tion. An example wo uld be a n ote that t he change to the pro tocol will be refere nced throu gh the VA event driv er, List M anager, us er selecti on of a pr otocol fro m the VA K ernel Menu Managemen t system. This secti on refers specifical ly to the change imp lemented w ith the de sign.
1209	Item Text Descriptio n
1210	Enter the protocol's text as i t appears to the use r on the m enu or sub -header.
1211	Protocol T ype
1212	Define the type of p rotocol to be execut ed
1213	Associated Routine
1214	List any a ssociated routines a ffected by the proto col being designed.
1215	Current En try Action Logic
1216	Define the current l ogic for t he entry a ction of t he protoco l affected by the fu nctionalit y being de signed. If the entry action di d not exis t before, indicate t hat there currently is no entr y action.
1217	Modified E ntry Actio n Logic (C hanges are in bold)
1218	Define the entry act ion that t he design will imple ment. If t he entry a ction is n ew to the field, def ine the lo gic here.
1219	Current Ex it Action Logic
1220	Define the current l ogic for t he exit ac tion of th e protocol affected by the fun ctionality being des igned. If the exit a ction did not exist before, in dicate tha t there cu rrently is no exit a ction.
1221	Modified E xit Action Logic (Ch anges are in bold)
1222	Define the exit acti on that th e design w ill implem ent. If th e exit act ion is new to the fi eld, defin e the logi c here.
1223	Table 30: Protocols
1224	Protocols
1225	Activities
1226	Protocol N ame
1227
1228	Enhancemen t Category
1229	New Mo dify De lete No Change
1230	Associated Protocols
1231
1232	Data Passi ng
1233	Input Output Both Gl obal Refer ence Lo cal Refere nce
1234	Item Text Descriptio n
1235
1236	Protocol T ype
1237	Action Menu P rotocol Protocol Menu Li mited Prot ocol Ex tended Act ion Dia log Oth er
1238	Associated Routine
1239
1240
1241	Current En try Action Logic
1242
1243
1244	Modified E ntry Actio n Logic (C hanges are in bold)
1245
1246
1247	Current Ex it Action Logic
1248
1249
1250	Modified E xit Action Logic (Ch anges are in bold)
1251
1252	Remote Pro cedure Cal l (RPC)
1253	Complete t he table f or each RP C affected by the fu nctionalit y being de signed.
1254	Note: If p referred, this can b e captured directly from VA Fi leMan DDs after the fact.
1255	Table 31: RPCs (Inst ructions)
1256	RPCs
1257	Instructio ns
1258	Name
1259	List the s pecific na me of the RPC affect ed.
1260	TAG^RTN
1261	List the t ag (label) and routi ne.
1262	Input Para meters
1263	This field is used t o identify an input parameter for the AP I.
1264	Results Ar ray
1265	This field tells the RPC Broke r how to p rocess the resulting data from the call.
1266	Descriptio n
1267	Provide a brief desc ription of the RPC a ffected.
1268	Table 32: RPCs
1269	RPCs
1270	Activities
1271	Name
1272
1273	TAG^RTN
1274
1275	Input Para meters
1276
1277	Results Ar ray
1278	Single Va lue
1279	Array
1280	Word Proc essing
1281
1282	Global Ar ray
1283	Global In stance
1284
1285	Descriptio n
1286
1287	Constants Defined in Interface
1288	Provide th e name and descripti on.
1289	Table 33: Constants Defined in Interface
1290	Name
1291	Descriptio n
1292
1293
1294	Variables Defined in Interface
1295	Provide th e name, ty pe, and de scription.
1296	Table 34: Variables Defined i n Interfac e
1297	Name
1298	Type
1299	Descriptio n
1300
1301
1302
1303	Types Defi ned in Int erface
1304	Provide th e name, ty pe, and de scription.
1305	Table 35: Types Defi ned in Int erface
1306	Name
1307	Type
1308	Descriptio n
1309
1310
1311
1312	GUI
1313	List the G UI affecte d by the f unctionali ty being d esigned an d include a short de scription of the cha nges made to the aff ected GUI. The heade rs in the following tables hav e names fo r the info rmation ou tlined. Th ere are a number of items in t his sectio n that wou ld general ly be glob al informa tion and v isible to all other aspects.
1314	Table 36: GUI
1315	Unit Name
1316	Descriptio n
1317
1318
1319	GUI Classe s
1320	Table 37: GUI Classe s (Instruc tions)
1321	GUI Classe s
1322	Instructio ns
1323	Class Name
1324	List the n ame of the class aff ected. The headers i n the foll owing tabl es have na mes for th e informat ion outlin ed. Note t hat only t he new pro perties an d methods for a clas s are list ed below. All ancest or propert ies and me thods are still avai lable and unchanged.
1325	Derived Fr om Class
1326	List the c lass that this is de rived from , its pare nt and any interface s listed a s part of this class .
1327	Purpose
1328	Describe t he functio nality tha t users ca n access f rom this c lass and r elated for m, if any.
1329	Table 38: GUI Classe s
1330	GUI Classe s
1331	Instructio ns
1332	Class Name
1333
1334	Derived Fr om Class
1335
1336	Purpose
1337
1338	Current Fo rm
1339	Provide a screen cap ture or gr aphical re presentati on of the current la yout.
1340	Modified F orm
1341	Provide a screen cap ture or gr aphical re presentati on of the layout tha t the desi gn will im plement.
1342	Components on Form
1343	Table 39: Components on Form
1344	Name
1345	Type
1346	Descriptio n
1347
1348
1349
1350	Events
1351	Table 40: Events
1352	Name
1353	Type
1354	Descriptio n
1355
1356
1357
1358	Methods
1359	Table 41: Methods
1360	Method Nam e
1361	Procedure/ Function
1362	Descriptio n
1363
1364
1365
1366	Special Re ferences
1367	Include re ferences t hat are no t listed e lsewhere.
1368	Special Re ference Na me
1369	Type
1370	Descriptio n
1371
1372
1373
1374	Class Even ts
1375	Table 42: Class Even ts
1376	Name
1377	Type
1378	Descriptio n
1379
1380
1381
1382	Class Meth ods
1383	Table 43: Class Meth ods
1384	Name
1385	Procedure/ Function
1386	Descriptio n
1387
1388
1389
1390	Class Prop erties
1391	Table 44: Class Prop erties
1392	Class Prop erties Nam e
1393	Type
1394	Visibility
1395	Descriptio n
1396
1397
1398
1399
1400	Uses Claus e
1401	Use this s ection to provide a uses claus e that lis ts the oth er units ( code or fo rm units) that this unit will use. This may be doc umented in the form of a Unifi ed Modelin g Language (UML) dra wing.
1402	Forms
1403	This secti on lists t he forms t hat will b e affected or create d by the f unctionali ty being d esigned. A short des cription o f the chan ge that wi ll be made to the fo rms should be includ ed.
1404	Table 45: Forms (Ins tructions)
1405	Forms
1406	Instructio ns
1407	Form Name
1408	List the n ame of the form affe cted by th e function ality bein g designed .
1409	Enhancemen t Category
1410	Check the appropriat e box: New , Modify, Delete, or No Change .
1411	Form Funct ionality
1412	Describe t he form’s functional ity and re fer to the usage of the form. An example of such a descripti on is “Thi s form is used to en ter patien t demograp hic data.”
1413	Current Fo rm Layout
1414	Define the current f orm layout that the design wil l modify. If this is a new for m, enter “ N/A”.
1415	Modified F orm Layout (Changes are in bol d)
1416	Define the form layo ut that th e design w ill implem ent.
1417	Table 46: Forms
1418	Forms
1419	Descriptio n
1420	Form Name
1421
1422	Enhancemen t Category
1423	New
1424	Modify
1425	Delete
1426	No Change
1427	Form Funct ionality
1428
1429
1430	Current Fo rm Layout
1431
1432
1433	Modified F orm Layout (Changes are in bol d)
1434
1435	Functions
1436	The functi ons affect ed by the capabiliti es being d esigned sh ould be li sted in th is section . A short descriptio n of what change wil l be made to the fun ctions and /or new fu nctions sh ould be in cluded.
1437	Table 47: Forms (Ins tructions)
1438	Functions
1439	Instructio ns
1440	Function N ame
1441	List the s pecific fu nction aff ected by t he capabil ity being designed.
1442	Short Desc ription
1443	List a sho rt descrip tion of th e change t hat will b e made to the functi ons and/or new funct ions.
1444	Enhancemen t Category
1445	Check the appropriat e box: New , Modify, Delete, or No Change .
1446	Related Op tions
1447	List the o ptions tha t directly call or a re called by the fun ction.
1448	Related Ro utines
1449	List the r outines th at directl y call or are called by the fu nction.
1450	Data Dicti onary (DD) Reference s
1451	List the f iles that reference the functi on through input tra nsforms, c ross refer ence logic , etc.
1452	Related Pr otocols
1453	List the p rotocols t hat refere nce or are reference d by the f unction.
1454	Related In tegration Control Re gistration s (ICRs)
1455	List propo sed new IC Rs and sub scribed IC Rs. Also, list any o bscure Sup ported ICR s.
1456	Data Passi ng
1457	Check the appropriat e box. An event that would tri gger the n ew/changed function should be included i n this sec tion. An e xample of such a des cription w ould be a note that the new/ch anged func tion will be invoked as part o f a functi on call or it would be invoked through s ystem prot ocols, HL7 Logical L inks, etc. This sect ion refers specifica lly to the change im plemented with the d esign.
1458	Input Attr ibute Name and Defin ition
1459	List the i nput attri butes pass ed into th e new or c hanged fun ction logi c. Each at tribute sh ould be de fined.
1460	Output Att ribute Nam e and Defi nition
1461	List the o utput attr ibutes ret urned from the new o r changed function l ogic. Each attribute should be defined.
1462	Current Lo gic
1463	Define the current l ogic in th e function that the design wil l modify. If this is new code, enter “N/ A”.
1464	Modified L ogic (Chan ges are in bold)
1465	Define the logic in the functi on that th e design w ill implem ent.
1466	Table 48: Forms
1467	Function N ame
1468	Activities
1469	Short Desc ription
1470
1471	Enhancemen t Category
1472	New
1473	Modify
1474	Delete
1475	No Change
1476	Related Op tions
1477
1478
1479	Related Ro utines
1480	Routines “ Called By”
1481	Routines “ Called”
1482
1483
1484
1485
1486	Function N ame
1487	Activities
1488	Data Dicti onary (DD) Reference s
1489
1490	Related Pr otocols
1491
1492	Related In tegration Control Re gistration s (ICRs)
1493
1494	Data Passi ng
1495	Input
1496	Output
1497	Both
1498	Global Re ference
1499	Local Ref erence
1500	Input Attr ibute Name and Defin ition
1501	Name:
1502
1503	Definition :
1504	Output Att ribute Nam e and Defi nition
1505	Name:
1506
1507	Definition :
1508
1509	Current Lo gic
1510
1511
1512	Modified L ogic (Chan ges are in bold)
1513
1514	Dialog
1515	In this se ction list the chang es to the DIALOG fil e (#.84).
1516	Table 49: Dialog (In structions )
1517	Dialog
1518	Instructio ns
1519	Dialog Mes sage (Desc ription)
1520	List the s pecific me ssage affe cted or ne eded by th e changes being desi gned.
1521	Enhancemen t Category
1522	Select the appropria te categor y: New, Mo dify, Dele te, or No Change.
1523	Dialog Mes sage (Desc ription) C ondition
1524	Describe t he dialog message (d escription ) function ality. An example of such a de scription would be t he conditi on that wo uld trigge r the outp ut of the message (d ialog). Th is section refers to the condi tion gener ating the message (d ialog).
1525	Current Di alog Messa ge (Descri ption)
1526	Define the current d ialog mess age (descr iption) th at the des ign will m odify. If this is a new dialog message ( descriptio n) enter N /A.
1527	Modified D ialog Mess age (Descr iption) (C hanges are in bold)
1528	Define the dialog me ssage (des cription) that the d esign will implement .
1529	Table 50: Dialog
1530	Dialog
1531	Instructio ns
1532	Dialog Mes sage (Desc ription)
1533
1534	Enhancemen t Category
1535	New
1536	Modify
1537	Delete
1538	No Change
1539	Dialog Mes sage (Desc ription) C ondition
1540
1541	Current Di alog Messa ge (Descri ption)
1542
1543	Modified D ialog Mess age (Descr iption) (C hanges are in bold)
1544
1545	Help Frame
1546	A short de scription of what ch ange will be made to the Help Frame text and/or ne w text sho uld be inc luded in t his sectio n. Help fr ames may b e associat ed with op tions or w ith data d ictionary fields to provide on -line inst ruction.
1547	Table 51: Help Frame (Instruct ions)
1548	Help Frame
1549	Instructio ns
1550	Help Frame Text
1551	List the t ext affect ed or need ed by the changes be ing design ed.
1552	Enhancemen t Category
1553	Check the appropriat e box: New , Modify, Delete, or No Change .
1554	Help Frame Text Call ing Mechan ism
1555	Provide a short desc ription of the mecha nism used to call th e Help Fra me text in this sect ion. An ex ample of a mechanism would be the name o f the rout ine or an explanatio n of how t he Help Fr ame is cal led. An ex ample of a calling m echanism w ould be th e Standard VA FileMa n API and the keystr oke(s) tha t would tr igger the output of the text.
1556	Current He lp Frame T ext
1557	List the c urrent Hel p Frame Te xt that th e design w ill modify . If new t ext enter N/A.
1558	Modified H elp Frame Text (Chan ges are in bold)
1559	List the H elp Frame Text that the design will modi fy.
1560	Table 52: Help Frame
1561	Help Frame
1562	Descriptio n
1563	Help Frame Text
1564
1565	Enhancemen t Category
1566	New
1567	Modify
1568	Delete
1569	No Change
1570	Help Frame Text Call ing Mechan ism
1571
1572
1573	Current He lp Frame T ext
1574
1575
1576	Modified H elp Frame Text (Chan ges are in bold)
1577
1578	HL7 Applic ation Para meter
1579	Table 53: HL7 Applic ation Para meter (Ins tructions)
1580	HL7 Applic ation Para meter
1581	Instructio ns
1582	HL7 Applic ation Para meter Name
1583	List the H L7 Applica tion Param eter affec ted or nee ded by the changes b eing desig ned.
1584	Enhancemen t Category
1585	Check the appropriat e box: New , Modify, Delete, or No Change .
1586	Applicatio n Status
1587	Check the appropriat e box in t he applica ble column for Curre nt and Mod ified
1588	Facility N ame
1589	List the c urrent and modified value in t he appropr iate colum n.
1590	Country Co de
1591	List the c urrent and modified value in t he appropr iate colum n.
1592	HL7 Field Separator
1593	List the c urrent and modified value in t he appropr iate colum n.
1594	HL7 Encodi ng Charact ers
1595	List the c urrent and modified value in t he appropr iate colum n.
1596	Mail Group
1597	List the c urrent and modified value in t he appropr iate colum n.
1598	Table 54: HL7 Applic ation Para meter
1599	HL7 Applic ation Para meter Name
1600	Descriptio n
1601
1602	Enhancemen t Category
1603	New
1604	Modify
1605	Delete
1606	No Change
1607
1608	Applicatio n Status
1609	Active
1610	Inactive
1611	Active
1612	Inactive
1613
1614
1615
1616	Enhancemen t Category
1617	Current
1618	Modified
1619	Facility N ame
1620
1621
1622	Country Co de
1623
1624
1625	HL7 Field Separator
1626
1627
1628	HL7 Encodi ng Charact ers
1629
1630
1631	Mail Group
1632
1633
1634	HL7 Logica l Link
1635	Table 55: HL7 Logica l Link (In structions )
1636	HL7 Logica l Link
1637	Instructio ns
1638	HL7 Logica l Link Par ameter (LL P) Name
1639	List the s pecific HL 7 Logical Link affec ted or nee ded by the changes b eing desig ned.
1640	Enhancemen t Category
1641	Check the appropriat e box: New , Modify, Delete, or No Change .
1642	Node
1643	List the c urrent and modified value in t he appropr iate colum n.
1644	Institutio n
1645	List the c urrent and modified value in t he appropr iate colum n.
1646	Domain
1647	List the c urrent and modified value in t he appropr iate colum n.
1648	Autostart
1649	List the c urrent and modified value in t he appropr iate colum n.
1650	Queue Size
1651	List the c urrent and modified value in t he appropr iate colum n.
1652	LLP Type
1653	List the c urrent and modified value in t he appropr iate colum n.
1654	Table 56: HL7 Logica l Link
1655	HL7 Logica l Link
1656	Descriptio n
1657	HL7 Logica l Link Par ameter Nam e
1658
1659
1660	Enhancemen t Category
1661	New
1662	Modify
1663	Delete
1664	No Change
1665
1666	Enhancemen t Category
1667	Current
1668	Modified
1669	Node
1670
1671
1672	Institutio n
1673
1674
1675	Domain
1676
1677
1678	Autostart
1679
1680
1681	Queue Size
1682
1683
1684	LLP Type
1685
1686
1687	COTS Inter face
1688	The specif ic communi cation met hod(s) and Applicati on Interfa ce(s) that will be c reated or modified f or the COT S system b eing inter faced shou ld be desc ribed in t his sectio n. A short descripti on of the existing t ools that will be us ed and any new tools that will be develo ped should also be i ncluded.
1689	Table 57: COTS Inter face (Inst ructions)
1690	COTS Inter face
1691	Instructio ns
1692	Communicat ion Method
1693	List the s pecific co mmunicatio n method c reated or modified f or the fun ctionality being des igned.
1694	Applicatio n Interfac e
1695	List the s pecific ap plication interface created or modified for the fu nctionalit y being de signed.
1696	Table 58: COTS Inter face
1697	COTS Inter face
1698	Descriptio n
1699	Communicat ion Method
1700
1701	Applicatio n Interfac e
1702
1703	Network De tailed Des ign
1704	Provide en ough detai led inform ation abou t the comm unication requiremen ts to buil d and/or p rocure the communica tion compo nents for the system . This se ction shou ld provide sufficien t detail t o support the procur ement of h ardware fo r the syst em install ation. Inc lude the f ollowing i nformation in the fo rm of deta iled desig ns (as app ropriate):
1705	Details of servers a nd clients to be inc luded on e ach area n etwork
1706	Specificat ions for b us timing requiremen ts and bus control
1707	Format(s) for data b eing excha nged betwe en compone nts
1708	Diagrams s howing con nectivity between co mponents, data flow (if applic able), and distances between c omponents
1709	LAN topolo gy.
1710	Security a nd Privacy
1711	Security
1712	This proje ct will co ntinue to use the ex isting Vis tA / CPRS security m odel.
1713	Privacy
1714	This proje ct will co ntinue to use the ex isting Vis tA / CPRS privacy mo del.
1715	Service Or iented Arc hitecture / ESS Deta iled Desig n
1716	CPRS is a legacy GUI applicati on that pr ovides a G UI front-e nd to the VistA syst em and is primarily used by ph ysicians, nurses and other cli nicians re sponsible for provid ing patien t care. CP RS EP1 is enhancing the existi ng CPRS sy stem.
1717	Refer to t he VistA M onograph f or a full explanatio n of the l arger syst em that CP RS EP1 is a part of.
1718	Of note: C PRS’s arch itecture d oes not su pply new e nterprise services o r consume enterprise services
1719	Service De scription for <Consu med Servic e Name>
1720	Provide li nk to Serv ice Descri ption docu ment for t he consume d service. This sect ion will r epeat for each consu med servic e. The Ser vice Descr iption inc ludes Serv ice Interf ace and Se rvice Leve l Definiti on (SLD) t o address anticipate d capacity requireme nts.
1721	Service De sign for < Provided S ervice Nam e>
1722	This secti on should describe t he detaile d service design for each ESS and SOA se rvice need ed to obta in an inte nded resul t. The Ser vice Desig n includes Service I nterface a nd Service Level Def inition (S LD) to add ress antic ipated cap acity requ irements.
1723	This secti on will re peat for e ach provid ed service .
1724	Introducti on
1725	Purpose an d Scope of Service
1726	This servi ce was des cribed at a high lev el in the charter do cument. Pl ease refer to it her e via a li nk.
1727	Links to O ther Docum ents
1728	Provide li nks to oth er documen ts created for this service so far in th e SOA life cycle. At a minimum, provide l inks to:
1729	Service Ch arter
1730	Service Ro admap
1731	Service De scription
1732	Service De tails
1733	Service Id entificati on
1734	This secti on will be written a s a table to provide a quick r eference t o the serv ice's what , where, w hy and how - cheat s heet.
1735	Service At tribute
1736	Value
1737	Name and A lias (if a ny)
1738	Name of th e service and other names for the servic e, which m ight be us ed by some one search ing for th is service . Please f ollow ESS naming sta ndards.
1739	Overview
1740	Brief text ual overvi ew of the service.
1741	Version
1742	Version nu mber of th e service being desc ribed here
1743	Latest Sta tus
1744	This field shows the latest st atus for t he above r eferenced version of this serv ice! The s tatus of a service s hows the p rogress of the servi ce from in itiation t hrough dev elopment, deployment , and even tual retir ement. The status al so has a s tatus date associate d with the status - and we wil l be using the lates t one here in this d ocument. V alid value s include: Inception , Design, Provisioni ng, Certif ication / Testing, O peration, Deprecated , Retired, Rejected - Owner ha s decided not to dev elop the s ervice.
1745	Service Ty pe
1746	Used to de fine appli cable arch itecture p atterns. E xamples (f rom Open G roup):
1747	• Interact ion
1748	• Process
1749	• Informat ion
1750	• Partner
1751	• Business Applicati on
1752	• Access
1753	• Service Connectivi ty
1754	Architectu re Layer
1755	Referred t o as class in VA Ser vice templ ate. Used to define applicable architect ure patter ns and rel ationships to govern ing bodies . Examples :
1756	• Solution
1757	• Process
1758	• Informat ion
1759	• Utility
1760	• Underlyi ng
1761	Business D omain
1762	Business V ertical or Business Division w here this service be longs.
1763	Service Do main
1764	The servic e or techn ical domai n that the service b elongs to. Can be us ed to esta blish the namespace.
1765	Business O rganizatio n and Owne r
1766	Person who approves this servi ce & any c hanges. I nclude ema il.
1767	Technical Organizati on and Own er
1768	Person res ponsible f or provisi oning (spe cifying, a cquiring c ertifying) this serv ice. Inclu de email.
1769	Developmen t Organiza tion and O wner
1770	Person who is respon sible for the develo pment proc esses and activities for this service. I nclude ema il.
1771	Support Or ganization and Owner
1772	Person who is respon sible for the suppor t of this service wh ile in pro duction. I nclude ema il.
1773	Target Con sumer Orga nization(s ) and Owne r(s)
1774	Organizati ons and/or developer s roles th at service is intend ed for.
1775	Service Ve rsions
1776	Version Nu mbers
1777	Current St atus of Ve rsion
1778	A Brief De scription of the cha nge implem ented in t hat versio n
1779	This versi on
1780	Being Desi gned
1781
1782	Example: v ersion 2
1783	Example: I n producti on. Will b e retired with this release.
1784	Example: T his releas e added th e ability to look up a person by address .
1785	Provide a link to ea ch version of the se rvice.
1786	Example: v ersion 1
1787	Example: R etired.
1788	Example: T his releas e provided the base minimum fu nctionalit y to look up a perso n by name.
1789	Provide a link to ea ch version of the se rvice.
1790	Summary of Design an d Platform Details
1791	SOA Patter n(s) Imple mented
1792	Name of th e SOA patt ern implem ented – fo r instance , this may be a Pub/ Sub model. Just a na me and ref erence to the docume nt or book with the pattern is sufficien t for popu lar patter ns or VA's own patte rns. If yo u are usin g some eso teric patt ern, more details wi ll help.
1793	COTS Platf orm vendor names and versions for hostin g platform
1794	Example, T IBCO.
1795	Dependenci es
1796	The Depend ency Model identifie s other se rvices, sy stems, dat abases, et c. that [S ervice Nam e] is depe ndent upon or intera cts with t o perform its functi on.
1797	This sect ion should clearly i dentify al l sources and extern al systems that are accessed b y this ser vice to fu lfill the service co nsumers’ r equest. T his sectio n should i nclude dia grams to s how as muc h detail a s necessar y to infor m the deve loper. Pro vide a con text diagr am for the service.
1798	Note: Here our prima ry audienc e includes the provi ders of th e service. So this d ocument in general w ill emphas ize system component s and sub- systems as much as e xternal in teractions .
1799	Service De sign Detai ls
1800	The next s ub-section on Interf ace Techni cal Specs could be j ust a copy from the correspond ing sub-se ction in I nterface s ection in the Servic e Descript ion Docume nt. Here, you could provide mo re detail necessary for buildi ng this se rvice but the interf ace spec n eeds to be consisten t between this docum ent and th e Service Descriptio n Document . This sec tion conta ins all in formation necessary to fully d escribe an interface published by this s ervice...
1801	Interface Technical Specs
1802	The techni cal specif ication al lows devel opers of s ervice con sumers to locate and discover the servic e for run time consu mption.
1803	Service In vocation T ype
1804	Such as: S OAP over H TTP, REST.
1805	Service In terface Ty pe
1806	Such as: W SDL via We b Service 2.0
1807	Service Na me
1808	Technical Service Na me. Comply with ESS naming sta ndards.
1809	Interface
1810	Link to WS DL or othe r interfac e document .
1811	End Points
1812	Provide if known! Ca lls that c an be made into the service. C an be refe renced to the WSDL o r can be i n a separa te table.
1813	Operations or Method s
1814	In the tab le below, the techni cal names of the ope rations, i nputs and outputs ar e used. In puts and o utputs, if parameter s, must ha ve a data type.
1815	Non-primit ive data t ypes must be defined in the Se rvice Info rmation Mo del sectio n.
1816	This table could be generated automatica lly from t he WSDL co ntent or i ts equival ent.
1817	Style can take any o f these va lues: Para meters or Document; and One-wa y or Reque st-respons e or Solic it-respons e or Notif ication.
1818	Use a sepa rate colum n for the operation purpose if you wish.
1819	You might use abbrev iations in the Fault s column a nd explain the abbre viations u sed below the table. For examp le, NF = N ot Found, MI = Missi ng Input.
1820	Operation Name
1821	Inputs
1822	Outputs
1823	Transactio nal Qualit ies if rel evant (Upd ating?, At omic?, Can participa te in tran saction?)
1824	Pre and Po st Conditi ons
1825	Exception (s)
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838	Provide a link to th e Service Informatio n model so that the consumer o f your sys tem knows the schema for the i nput and o utput para meters.
1839	Message Sc hemas
1840	Provide de finitions or links t o definiti ons of the message(s ) related to the ser vice opera tions. Th ese may be dependent on the im plementati on style a nd protoco l binding of the int erface.
1841	Informatio n Model
1842	Even thoug h this sec tion looks similar t o the corr esponding section 3. 2 in Servi ce Descrip tion, reme mber that the primar y objectiv e here is to facilit ate constr uction and to gain a pprovals f rom govern ing bodies . So you w ill provid e more of a “white b ox” view o f the desi gn here to help your developer s code the service.
1843	Class Diag ram and De scription of Entitie s Involved
1844	Map out al l entities involved in the ser vice: inpu t, output, exception s, entitie s manipula ted in per sistent me dia/DBs, i ntermediat e entities created i n memory e tc.
1845	Mappings f rom ELDM t o Standard s Based Sc hemas
1846	Provide ma ppings fro m your nat ive schema to any st andards ba sed schema s your ser vice will use to com municate o utside. Fo r instance , if you a re using H L7 based m essages th en you wil l show how data is c onverted f rom your n ative sche ma to HL7.
1847	Behavior M odel (AKA Use Case R ealization )
1848	The Behavi or Model d efines the actions a nd process es support ed by the service. Actions an d methods represente d in the u se cases a nd sequenc e diagrams shown bel ow are fur ther defin ed by the operation contracts and the me ssage payl oads.
1849	Use Cases (Use Case Model)
1850	Describe h ow this se rvice fits into the larger use case mode l of the c onsumer. Y ou may nee d multiple models fo r multiple consumers . Focus is not on th e internal workings of the new service i nstead of the calls made from external c onsumers. Just a sum mary or th e Use Case Diagram m ay be suff icient. L ist the al ternative and except ion flows. Reference the detai led design documents via a URL .
1851	Interactio n Diagrams
1852	Cut and pa ste screen shot from RSA or si milar tool or provid e link to the model. Provide d escription to help d evelopers build your service. The intera ction diag rams shoul d depict e xternal in teractions and inter nal sequen ces of cal ls between internal components . The sequ ence diagr am should cut throug h all laye rs to show the main, alternate and excep tion flows .
1853	Gap Analys is
1854	Provide a Gap Analys is (Refere nce) to de monstrate compliance of this s ervice wit h various standards, policies, guideline s and laws . The Gap Analysis m ay take th e form of a matrix a s shown in the sampl e below. T his will h elp the go vernance b oards expe dite your request.
1855	Design Ele ments
1856	Policies / SLD eleme nts etc.↓
1857	Design
1858	Element A
1859	Design
1860	Element B
1861	Design
1862	Element C
1863	Comment fo r non-conf ormance
1864	Policy X
1865	Match
1866
1867
1868
1869	Policy Y
1870
1871	Partial
1872
1873
1874	Policy Z
1875
1876
1877
1878	Commercial encryptio n server i n prod wil l have to address th is policy.
1879	Policy A
1880
1881
1882
1883	Compliance with this policy no t required until nex t year.
1884	New / Addi tional Fea tures
1885
1886
1887	New elemen t minimize s manual i nterventio n
1888
1889	Variances from Enter prise Targ et Archite cture
1890	This list of “varian ces” will become a s ubmission to the ESS dispensat ion proces s.
1891	Variances from SLDs
1892	This list of “varian ces” will become a s ubmission to the ESS dispensat ion proces s.
1893	Variances from Stand ards and P olicies
1894	This list of “varia nces” will become a submission to the ES S dispensa tion proce ss.
1895	Justificat ion for Ex ceptions a nd Mitigat ion
1896	This secti on will li st out any non-funct ional and functional requireme nts that a re not bei ng met. Th e non-conf ormance ma y be in vi olation of elements of SLDs, e nterprise architectu re (TRM Te chnology R eference M odel), pri vacy polic ies or gui delines. F or each ex ception pr ovide:
1897	Reasons fo r non-conf ormance (c ost, time, technolog y, etc.)
1898	Mitigating actions t aken to re duce the i mpact of n on-conform ance
1899	Plan (road map) to co me back in to conform ance
1900	This list can grow d epending o n what the Review bo dies may a sk for.
1901	External S ystem Inte rface Desi gn
1902	This secti on details interface s external to system , that are NOT servi ces (ESS/S OA). Typic ally, thes e may incl ude, RPCs, Flat Data Files etc .
1903	External s ystems are systems t hat are no t within t he scope o f the syst em under d evelopment , regardle ss of whet her the ot her system s are mana ged by the vendor or its clien t.
1904	In this se ction, des cribe the interface( s) between the syste m under de velopment (i.e., the system th at is the subject of this SDD) and exter nal system s and/or s ubsystem(s ).
1905	It is best to illust rate these sections with annot ated diagr ams to cle arly ident ify the va rious elem ents of th e interfac es.
1906	Interface Architectu re
1907	Describe t he interfa ce(s) betw een the sy stem being designed and other systems. I nclude the interface architect ure(s) bei ng impleme nted, such as wide a rea networ ks, gatewa ys, etc. P rovide dia grams show ing the co mmunicatio ns path(s) between t his system and other systems.
1908	Interface Detailed D esign
1909	Provide su fficient d etail abou t the inte rface requ irements f or the dev elopment t eam to for mat, trans mit, and/o r receive data acros s the inte rface.
1910	Include th e followin g informat ion (as ap propriate) :
1911	Data forma t requirem ents; if d ata must b e reformat ted before it is tra nsmitted o r after in coming dat a is recei ved. Descr ibe the to ols and/or methods f or the ref ormat proc ess.
1912	Specificat ions for h and-shakin g protocol s between systems; c ontent and format of hand-shak e messages , timing f or exchang ing these messages, and errors handling.
1913	Format(s) for report s exchange d between the system s.
1914	Graphical representa tion of th e connecti vity betwe en systems , showing the direct ion of dat a flow.
1915	Query and response d escription s.
1916	Describe t he individ ual data e lements th at the int erfacing e ntity(s) w ill provid e, store, send, acce ss, and re ceive, suc h as:
1917	Names/iden tifiers
1918	Data Eleme nt Name
1919	Data Forma t/Length
1920	Data Type
1921	Definition
1922	Non-Techni cal Name
1923	Non-Techni cal Synony ms
1924	Specificat ions
1925	Synonyms
1926	Range or e numeration of possib le values (e.g., 0-9 9)
1927	Accuracy a nd precisi on (number of signif icant digi ts)
1928	Priority, timing, fr equency, s equencing, and other constrain ts
1929	Security a nd privacy constrain ts
1930	Sources (s etting/sen ding entit ies) and r ecipients (using/rec eiving ent ities).
1931	Describe t he data el ement asse mblies (re cords, mes sages, fil es etc.) t hat the in terfacing entity(s) will provi de, store, and send, such as:
1932	Names/iden tifiers
1933	Technical Name, e.g. , data str ucture nam e
1934	Non-techni cal Names, e.g. syno nyms
1935	Data eleme nts
1936	Medium/str ucture of data eleme nts/assemb lies
1937	Visual cha racteristi cs (e.g. l ayouts, fo nts, icons etc.)
1938	Relationsh ips among assemblies
1939	Security a nd privacy constrain ts
1940	Sources an d recipien ts.
1941	Describe t he communi cation met hods that the interf acing enti ty(s) will use for t he interfa ce, such a s:
1942	Communicat ion links, bands, fr equencies, and media
1943	Message fo rmatting
1944	Flow contr ol (e.g. s equence nu mbering)
1945	Data trans fer rate
1946	Routing
1947	Transmissi on service s
1948	Safety
1949	Security a nd privacy considera tions.
1950	Describe c haracteris tics of th e protocol s that the interfaci ng entity( s) will us e for the interface, such as:
1951	Priority/l ayer of th e protocol
1952	Packeting
1953	Legality c hecks, err or control
1954	Recovery p rocedures
1955	Synchroniz ation
1956	Status, id entificati on, and ot her report ing featur es.
1957	Where appr opriate de scribe oth er charact eristics, such as ph ysical com patibility of the in terfacing entity(s) (dimension s, toleran ces, loads , voltages , plug com patibility , etc.)
1958	Human-Mac hine Inter face
1959	Describe t he human-m achine int erface (i. e., GUI) r elative to the user. Additiona l informat ion may be added if the sugges ted headin gs are ina dequate.
1960	Interface Design Rul es
1961	CPRS follo ws VA stan dards, Sta ndards and Conventio ns (SAC) g uidelines, as well a s guidelin es from Hu man Factor s/Patient Safety.
1962	Inputs
1963	Mouse and keyboard—n o special or unusual input dev ice is req uired.
1964	Outputs
1965	Please ref er to sect ion 6.2 fo r details regarding output cha nges for e ach of the requests included i n CPRS EP1 .
1966	Navigation Hierarchy
1967	Provide a diagram of the navig ation hier archy that shows how a user mo ves throug h the GUI.
1968	Screen [x. 1]
1969	Provide th e layout o f all inpu t data scr eens or GU Is. Provid e a graphi c represen tation of each GUI, for exampl e, a low-r esolution screenshot . Define a ll data el ements ass ociated wi th each sc reen or GU I, or refe rence the data dicti onary. Lab el each da ta input s creen and/ or GUI.
1970	Screen [x. 2]
1971	Provide a graphic re presentati on of each GUI, for example, a low-resol ution scre enshot. De fine all d ata elemen ts associa ted with e ach screen or GUI, o r referenc e the data dictionar y.
1972	Screen [x. 3]
1973	Provide a graphic re presentati on of each GUI, for example, a low-resol ution scre enshot. De fine all d ata elemen ts associa ted with e ach screen or GUI, o r referenc e the data dictionar y.
1974	Attachmen t A – Appr oval Signa tures
1975	This secti on is used to docume nt the app roval of t he System Design Doc ument. The review sh ould be co nducted fa ce to face where sig natures ca n be obtai ned ‘live’ during th e review. If unable to conduct a face-to -face meet ing then i t should b e held via LiveMeeti ng and con currence c aptured du ring the m eeting. Th e Scribe s hould add /es/name b y each pos ition cite d. Example provided below.
1976	The Busine ss Sponsor and Proje ct Manager are requi red to sig n.
1977
1978	__________ __________ __________ __________ __________ __________ __________ ________
1979	Signed:Dat e:
1980	< Business Sponsor >
1981
1982	__________ __________ __________ __________ __________ __________ __________ ________
1983	Signed:Dat e:
1984	< Project Manager >
1985
1986
1987	Additional Informati on
1988	Attach any addition informatio n that sup plements t he design specificat ion.
1989	Identifica tion of Te chnology a nd Standar ds
1990	Identify t he system and softwa re which a pply to th e SDD, inc luding: id entificati on number( s), title( s), abbrev iation(s), version n umber(s), and releas e number(s ). Identif y all stan dards (e.g ., America n National Standards Institute [ANSI], I nternation al Organiz ation for Standardiz ation [ISO ], Institu te of Elec trical and Electroni cs Enginee rs [IEEE], etc.).
1991	Constraini ng Policie s, Directi ves and Pr ocedures
1992	Identify a ny constra ints or re quirements placed on this docu ment by po licies, di rectives, or procedu res.
1993	Requiremen ts Traceab ility Matr ix
1994	Include an RTM that traces mod ules and d ata struct ures to th e software requireme nts. A ref erence to the locati on of the RTM is als o acceptab le.
1995	Packaging and Instal lation
1996	Outline an y special considerat ions for s oftware pa ckaging an d installa tion.
1997	Design Met rics
1998	Describe a ll metrics to be use d during t he design activity.
1999
2000
2001	Template R evision Hi story
2002	Date
2003	Version
2004	Descriptio n
2005	Author
2006	June 2015
2007	2.10
2008	Changed He ading 1 de fault sett ing to eli minate pag e break be fore
2009	Process Ma nagement
2010	May 2015
2011	2.9
2012	Edited for Section 5 08 conform ance and r emediated with Commo n Look Off ice tool
2013	Process Ma nagement
2014	February 2 015
2015	2.8
2016	Incorporat es revisio ns from PM AS Reform Lockdown; namely rem oving requ irements f or informa tion that can be obt ained from other PMA S authorit ative sour ces.
2017	Andrew Sla wter, Offi ce of Tech nology Str ategies
2018	September 2014
2019	2.7
2020	Adds Enter prise Shar ed Service s terms an d requires AERB Comp liance Cer tificate a ttachment.
2021	Process Ma nagement
2022	August 201 4
2023	2.6
2024	Signature block upda te authori zed by AER B CR_0189 34
2025	Process Ma nagement
2026	March 2014
2027	2.5
2028	Section 50 8 repairs to new ver sion appro ved by AER B Chair ap proved
2029	Process Ma nagement
2030	August 201 3
2031	2.3
2032	Replaced t he Service Architect ure sub-se ction with new sub-s ections fo r consumed and provi ded servic es. Also a pplied mis cellaneous feedback from VA te am.
2033	ASD Enterp rise Share d Services (ESS) Wor k Group
2034	June 2013
2035	1.3
2036	Upgraded t o MS Offic e 2007-201 0 format
2037	Process Ma nagement
2038	June 2013
2039	1.2
2040	Address in consistenc ies in Sec tion 3, Co nceptual D esign, Cor rect headi ngs
2041	Process Ma nagement
2042	March 2013
2043	1.1
2044	Formatted to documen tation sta ndards and edited fo r Section 508 confor mance
2045	Process Ma nagement
2046	January 20 13
2047	1.0
2048	Initial Do cument
2049	PMAS Busin ess Office
2050	Place late st revisio ns at top of table.
2051	The Templa te Revisio n History pertains o nly to the format of the templ ate. It do es not app ly to the content of the docum ent or any changes o r updates to the con tent of th e document after dis tribution.
2052	The Templa te Revisio n History can be rem oved at th e discreti on of the author of the docume nt.
2053	Remove bla nk rows.
2054
2055
2056	See TOGAF® 9.1, Part III: ADM Guidelines & Techniq ues, Gap A nalysis on TOGAF web site at ht tp://pubs. opengroup. org/archit ecture/tog af9-doc/ar ch/chap27. html