6. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 4/11/2019 2:37:08 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.

6.1 Files compared

#	Location	File	Last Modified
1	ES5.6_docs.zip\ESM	TS - ES Messaging.docx	Wed Mar 27 20:26:46 2019 UTC
2	ES5.6_docs.zip\ESM	TS - ES Messaging.docx	Thu Apr 11 17:10:37 2019 UTC

6.2 Comparison summary

Description	Between Files 1 and 2
Description	Text Blocks	Lines
Unchanged	7	936
Changed	6	12
Inserted	0	0
Removed	0	0

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

6.4 Active regular expressions

No regular expressions were active.

6.5 Comparison detail

	1	Enrollment System (E S)
	2	Messaging
	3	Technical Specificat ion
	4
	5	Department of Vetera ns Affairs
	6	Office of Informatio n and Tech nology (OI T)
	7	Product De velopment
	8	Documentat ion Versio n 1.6
	9
	10
	11	Revision H istory
	12	Date
	13	Revision
	14	Descriptio n
	15	Author
	16	01/22/2019
	17	1.6
	18	Added Sect ion for FD D from HCA
	19	Joseph Cor tes
	20	01/14/2019
	21	1.5
	22	Added Sect ion for Pr eferred Na me
	23	Joseph Cor tes
	24	10/23/2018
	25	1.4
	26	Added Sect ion for MO H Award Da te in ES
	27	Joseph Cor tes
	28	08/27/2018
	29	1.3
	30	Updated te st scenari o for asso ciation
	31	Wen Lin
	32	08/23/2018
	33	1.2
	34	Updated Z0 5 Message with how t o test det ails inclu ding HL7 s egments an d data exa mples
	35	Wen Lin
	36	08/22/2018
	37	1.1
	38	Added Sect ion for Ea rly Separa tion Reaso n Code in ZMH Messag e Segment
	39	Joseph Cor tes
	40	08/10/2018
	41	1.0
	42	Initial do cument
	43	Wen Lin
	44
	45	Table of C ontents
	46	1.Introduc tion4
	47	1.1.Purpos e4
	48	1.2.Scope4
	49	2.Modify R ules for Z 05 Message 5
	50	2.1.Change Request5
	51	2.2.Rule C hanges5
	52	2.3.Code C hanges15
	53	3.Add Earl y Separati on Reason Code to ZM H Message Segment18
	54	3.1.Change Request18
	55	3.2.Code C hanges18
	56	4.Add MOH Award Date in ES20
	57	4.1.Change Request20
	58	4.2.Databa se Changes 20
	59	4.3.Code C hanges20
	60	4.4.User I nterface C hanges22
	61	5.Preferre d Name wit h MVI as S ource24
	62	5.1.Change Request24
	63	5.2.Code C hanges24
	64	5.3.User I nterface C hanges25
	65	6.Future D ischarge D ate from H CA28
	66	6.1.Change Request28
	67	6.2.Code C hanges28
	68	6.3.User I nterface C hanges29
	69	6.4.Rule C hanges30
	70
	71
	72	Introducti on
	73	Purpose
	74	The purpos e of this document i s to discu ss changes to system component s and proc esses rela ted to Mes saging.
	75	Scope
	76	Technical specificat ion descri bes the ch anges made to extend or modify existing messaging functional ity. Each entry shou ld include the relev ant change request, as well as any code, UI and re quired dat abase chan ges.
	77
	78	Modify Rul es for Z05 Message
	79	Change Req uest
	80	CR 768318 business r equirement s describe the chang es to the Enrollment System th at allow s ending of Z05 Demogr aphic Data Transmiss ion messag es to Vist A sites wi thout filt ering. All rules tha t could pr event a Z0 5 message from being sent to w ill be rem oved so th at a Z05 m essage is sent to al l sites of record wh en there i s a change to any de mographic field tran smitted on the messa ge.
	81	Rule Chang es
	82	This will involve mo dification s in proce ssAddress and proces sAssociati on rule fl ows. The p rocessAddr ess rule f low is inv oked when an address /contact u pdate is m ade becaus e of a Z07 message r eceipt fro m a VAMC s ite. After the Z07 m essage rec eipt, deve lopers wan t to modif y the proc essAddress rule flow so that i t transmit s the upda ted addres s Z05 to a ll VAMC si tes includ ing the se nding faci lity that sent the Z 07.
	83
	84	Figure 1: ProcessAdd ress Rule Flow
	85
	86
	87	rule IsPer mAddressHa sBadAddres sReason
	88
	89
	90	Figure 2: IsPermAddr essHasBadA ddressReas on Rule
	91	How to tes t: process a Z07 mes sage addin g a bad ad dress reas on to an e xisting pe rmeant add ress; and the addres s update d ate is mor e recent.
	92
	93	ORUZ07 Mes sage – PID Segment
	94	Found a Veteran with a per manent add ress havin g no bad a ddress rea son
	95	Update d the exis ting perma nent addre ss with ba d address reason
	96	Update d RF1 Segm ent with S AD referen ce the mor e recent u pdate date
	97
	98	PID Segmen t Example:
	99	PID^1^1008 589404V203 273^100858 9404V20327 3~~~USVHA& &0363~NI~V A FACILITY ID&200M&L \|796781315 ~~~USSSA&& 0363~SS~VA FACILITY ID&608&L\|7 171927~~~U SVHA&&0363 ~PI~VA FAC ILITY ID&6 08&L\|~~~US VBA&&0363~ PN~VA FACI LITY ID&60 8&L^^BLSTC DCOKRP~BFS TCDCOKRP~B ATCH~^^197 60118^F^^1 002-5-SLF~ ~005~1002- 5~~CDC\|210 6-3-SLF~~0 05~2106-3~ ~CDC^5555 LEGACY DRI VE~#APT 55 5 ~PLANO~T X~75024~US A~VAB1~""~ 085\|~~DELM AR~NY~~~N^ 085^(972)3 34-1234~OR N~CP\|(214) 332-1234~P RN~PH\|~NET ~INTERNET~ PII ^^^M^^^796 781315^^^2 135-2-SLF~ ~0189~2135 -2~~CDC^^" "
	100
	101	RF1 Segmen t Example:
	102	RF1^^^SAD^ ^^509~USVA MC^2018081 6^^^
	103
	104	Bad Addres s Type
	105	Descriptio n
	106	VAB1
	107	VA - Bad A ddress, Un deliverabl e
	108	VAB2
	109	VA Bad Add ress, Home less
	110	VAB3
	111	VA Bad Add ress, Othe r
	112	VAB4
	113	VA Bad Add ress, Addr ess Not Fo und
	114
	115	rule isPer mAddressUp loadBadAdd ressReason
	116
	117
	118	Figure 3: isPermAddr essUploadB adAddressR eason Rule
	119	How to tes t: process a Z07 mes sage addin g a bad ad dress reas on to an e xisting pe rmanent ad dress; and the addre ss update date is eq ual to exi sting reco rd.
	120
	121	ORUZ07 Mes sage – PID Segment
	122	Found a Veteran with a per manent add ress havin g no bad a ddress rea son
	123	Update d address data and a dded a bad address r eason
	124	Update d RF1 Segm ent with S AD referen ce the sam e address update dat e on recor d
	125
	126	PID Segmen t Example:
	127	PID^1^1008 589404V203 273^100858 9404V20327 3~~~USVHA& &0363~NI~V A FACILITY ID&200M&L \|796781315 ~~~USSSA&& 0363~SS~VA FACILITY ID&608&L\|7 171927~~~U SVHA&&0363 ~PI~VA FAC ILITY ID&6 08&L\|~~~US VBA&&0363~ PN~VA FACI LITY ID&60 8&L^^BLSTC DCOKRP~BFS TCDCOKRP~B ATCH~^^197 60118^F^^1 002-5-SLF~ ~005~1002- 5~~CDC\|210 6-3-SLF~~0 05~2106-3~ ~CDC^5789 LEGACY DRI VE~#APT 55 5 ~PLANO~T X~75024~US A~VAB1~""~ 085\|~~DELM AR~NY~~~N^ 085^(972)3 34-1234~OR N~CP\|(214) 332-1234~P RN~PH\|~NET ~INTERNET~ PII ^^^M^^^796 781315^^^2 135-2-SLF~ ~0189~2135 -2~~CDC^^" "
	128
	129	RF1 Segmen t Example:
	130	RF1^^^SAD^ ^^509~USVA MC^2018081 6^^^
	131
	132	rule IsTem pAddressUp dateDateMo reRecentAn dActive
	133
	134
	135	Figure 4: IsTempAddr essUpdateD ateMoreRec entAndActi ve Rule
	136	How to tes t: process a Z07 mes sage with a temporar y address update; an d the addr ess update date is m ore recent .
	137
	138	ORUZ07 Mes sage - ZTA Segment
	139	Added a ZT A segment with a val id start d ate and a more recen t update d ate
	140	Set the en d date of ZTA segmen t NULL
	141
	142	ZTA Segmen t Example:
	143	ZTA^1^1^20 180523^""^ 234 TEST T EMP AVE~~L INCOLNIA~V A~22312~US A~C~~059^0 59^^201805 23110027-0 500^742
	144
	145
	146	rule IsTem pAddressUp dateDateMo reRecentIn activeAndN ull
	147
	148
	149	Figure 5: IsTempAdd ressUpdate DateMoreRe centInacti veAndNull Rule
	150	How to tes t: process a Z07 mes sage with a temporar y address incoming f ields are NULL; and the addres s update d ate is mor e recent.
	151
	152	ORUZ07 Mes sage - ZTA Segment
	153	Find a Vet eran with a temporar y address and end da te is NULL
	154	Added a ZT A segment with a fut ure start date and a more rece nt update date
	155
	156	ZTA Segmen t Example:
	157	ZTA^1^1^20 180823^""^ ""^059^^20 1805251100 27-0500^74 2
	158
	159
	160	rule IsCon fAddressUp dateDateMo reRecent
	161
	162
	163	Figure 6: IsConfAddr essUpdateD ateMoreRec ent Rule
	164	How to tes t: process a Z07 mes sage with a confiden tial addre ss update and the ad dress upda te date is more rece nt; and th e start da te is not NULL.
	165
	166	Details:
	167	ORUZ07 Mes sage –
	168	Added a confiden tial addre ss to PID Segment SE Q=13, Data Type=XTA
	169	Added RF1 Segmen ts CAD ref erence wit h more rec ent update date
	170
	171	Confidenti al Address Type:
	172	Confidenti al Address Type
	173	Descriptio n
	174	VACAA
	175	VA - Confi dential Ad dress Appo intment/Sc heduling
	176	VACAC
	177	VA - Confi dential Ad dress Copa yments/Vet eran Billi ng
	178	VACAE
	179	VA - Confi dential Ad dress Elig ibility/En rollment
	180	VACAM
	181	VA - Confi dential Ad dress Medi cal Record s
	182	VACAO
	183	VA - Confi dential Ad dress All Others
	184
	185	PID Segmen t Example:
	186	PID^1^1008 589404V203 273^100858 9404V20327 3~~~USVHA& &0363~NI~V A FACILITY ID&200M&L \|796781315 ~~~USSSA&& 0363~SS~VA FACILITY ID&608&L\|7 171927~~~U SVHA&&0363 ~PI~VA FAC ILITY ID&6 08&L\|~~~US VBA&&0363~ PN~VA FACI LITY ID&60 8&L^^BLSTC DCOKRP~BFS TCDCOKRP~B ATCH~^^197 60118^F^^1 002-5-SLF~ ~005~1002- 5~~CDC\|210 6-3-SLF~~0 05~2106-3~ ~CDC^1234 LEGACY DRI VE~#APT 11 1 ~PLANO~T X~75024~US A~P~~085\|2 22 Confide ntial Ave. ~Apt. 22B~ PARNASSUS~ PA~15068~U SA~VACAE~c onf line 3 ~085~~~201 70828&2017 1231^085^( 972)334-12 34~ORN~CP\| (214)332-1 234~PRN~PH \|~NET~INTE RNET~ PII ^^^M^^^796 781315^^^2 135-2-SLF~ ~0189~2135 -2~~CDC^^" "
	187
	188	RF1 Segmen t Example:
	189	RF1^^^SAD^ ^^509~USVA MC^2018080 1^^^
	190	RF1^^^CAD^ ^^500^2018 0812^^^
	191
	192	rule isCon fAddressEx pired2
	193
	194
	195	Figure 7: isConfAddr essExpired 2 Rule
	196	How to tes t: process a Z07 mes sage with a confiden tial addre ss update; and the s tart and e nd date of incoming confidenti al address are NULL.
	197
	198	Details:
	199	ORUZ07 Mes sage – PID Segment S EQ=13, DT= XTA
	200	Found a matching confident ial addres s and upda ted the ad dress star t date NUL L and end date NULL
	201	added RF1 Segmen t with ref erence CAD and more recent upd ate date
	202
	203
	204	PID Segmen t Example:
	205	PID^1^1008 589404V203 273^100858 9404V20327 3~~~USVHA& &0363~NI~V A FACILITY ID&200M&L \|796781315 ~~~USSSA&& 0363~SS~VA FACILITY ID&608&L\|7 171927~~~U SVHA&&0363 ~PI~VA FAC ILITY ID&6 08&L\|~~~US VBA&&0363~ PN~VA FACI LITY ID&60 8&L^^BLSTC DCOKRP~BFS TCDCOKRP~B ATCH~^^197 60118^F^^1 002-5-SLF~ ~005~1002- 5~~CDC\|210 6-3-SLF~~0 05~2106-3~ ~CDC^1234 LEGACY DRI VE~#APT 11 1 ~PLANO~T X~75024~US A~P~~085\|2 22 Confide ntial Ave. ~Apt. 22B~ PARNASSUS~ PA~15068~U SA~VACAE~c onf line 3 ~085~~~""^ 085^(972)3 34-1234~OR N~CP\|(214) 332-1234~P RN~PH\|~NET ~INTERNET~ PII ^^M^^^7967 81315^^^21 35-2-SLF~~ 0189~2135- 2~~CDC^^""
	206
	207	RF1 Segmen t Example:
	208	RF1^^^SAD^ ^^509~USVA MC^2018080 1^^^
	209	RF1^^^CAD^ ^^500^2018 0812^^^
	210
	211	processAss ociation r ule flow i s invoked when the a ssociate u pdate is m ade becaus e of the r eceipt of a Z07 mess age from a site. Dev elopers th en want to modify th e rule flo w so that it transmi ts this as sociation update Z05 to all si tes includ ing the se nding faci lity that sent the Z 07.
	212
	213
	214	Figure 8: ProcessAss ociation R ule Flow
	215
	216
	217
	218	rule SendZ O5AddressF ormat
	219
	220
	221	Figure 9: SendZO5Add ressFormat Rule
	222	How to tes t: process a Z07 mes sage with a new asso ciation; a nd the ass ociation t ype is not VA Guardi an, Guardi an Civil o r POW.
	223	Process a Z07 messag e with ass ociation u pdate and the update date is m ore recent
	224
	225	Details:
	226	ORUZ07 Mes sage –
	227	add a new ZCT Segmen t to ORUZ0 7 Message or
	228	update ZCT segment i n ORUZ07 M essage wit h update d ate more r ecent than the exist ing one.
	229
	230	ZCT Segmen t Example:
	231	ZCT^1^1^EM ERG~ONE^Fr iend^304 C ASE DR~~DA LLAS~TX~75 004-1234^9 723341234^ 9723341234 ^^^2018080 7203246-05 00
	232	ZCT^2^3^EM ERG~TWO^Ne ighbor^304 CASE STDD ~~VALARICA O~FL~33594 -1234^9723 341234^972 3341234^^^ 2018080720 3246-0500
	233	Contact Ty pe:
	234	1=NOK, 2=2 nd NOK, 3= e-contact, 4=2nd e-c ontact, 5= designee
	235
	236
	237	rule SendZ O5Guardian Format
	238
	239
	240	Figure 10: SendZO5Gu ardianForm at Rule
	241	How to tes t: process a Z07 mes sage with a new asso ciation; a nd the ass ociation t ype is VA Guardian.
	242	OR,
	243	Process a Z07 messag e with ass ociation u pdate and the update date is m ore recent .
	244
	245	Details:
	246	ORUZ07 Mes sage –
	247	add a new ZGD Segmen t to ORUZ0 7 Message or
	248	update ZGD segment i n ORUZ07 M essage wit h update d ate more r ecent than the exist ing one.
	249
	250	ZGD Segmen t Example:
	251	ZGD^1^1^PV A^""^""^13 3 HOLLAND~ ~ALBANY~NY ~12208^(51 8)225-2210 ^20171010
	252
	253	Code Chang es
	254	Code chang es are mad e in Assoc iationRule ServiceImp l.java. Tr iggerZ05 m ethods are invoked w hen there is an asso ciation up date. Filt erSitesPer sonTrigger Event filt ers out th e sending facility. By modifyi ng the sen ding facil ity to “NU LL” in map object, i t will not filter ou t any site . Even th ough the c odes are c ommented o ut and the method is never use d in ES, d evelopers still want to make t he change just in ca se.
	255
	256
	257	Figure 11: Code chan ges to be made in As sociationR uleService Impl.java
	258	Code chang es also ne ed to be m ade in Con tactInfoRu leServiceI mpl.java. The privat e method n otifyVista ForContact Info is in voked when phone or email cont act inform ation is u pdated. By creating a new Hash Map, inher iting the keys from updatedKey sAndSitesM ap and set ting the v alue to NU LL, the Fi lterSitesP ersonTrigg erEvent wi ll filter out nothin g and the Z05 messag e will be triggered to all sit es includi ng the sen ding facil ity.
	259
	260
	261	Figure 12: Code chan ges to be made in Co ntactInfoR uleService Impl.java
	262	How to tes t: Process a Z07 mes sage with phone numb er update; and the u pdate date is more r ecent.
	263	Process a Z07 messag e with Ema il update and the up date date is more re cent.
	264
	265	Phone numb er change test:
	266	Details:
	267	ORUZ07 Mes sage –
	268	updated PID Segme nt SEQ=13, DT=XTA wi th a new p hone numbe r
	269	added RF1 Segmen ts with mo st recent update dat e
	270
	271	PID Segmen t Example:
	272	PID^1^1008 589404V203 273^100858 9404V20327 3~~~USVHA& &0363~NI~V A FACILITY ID&200M&L \|796781315 ~~~USSSA&& 0363~SS~VA FACILITY ID&608&L\|7 171927~~~U SVHA&&0363 ~PI~VA FAC ILITY ID&6 08&L\|~~~US VBA&&0363~ PN~VA FACI LITY ID&60 8&L^^BLSTC DCOKRP~BFS TCDCOKRP~B ATCH~^^197 60118^F^^1 002-5-SLF~ ~005~1002- 5~~CDC\|210 6-3-SLF~~0 05~2106-3~ ~CDC^5678 LEGACY DRI VE~#APT 22 2 ~PLANO~T X~75024~US A~P~~085\|8 000 LEGACY DRIVE~#AP T 111 ~PLA NO~TX~7502 4~USA~R~~0 85^085^(46 9)334-1234 ~ORN~CP\|( )332-1234~ PRN~PH\|~NE T~INTERNET ~ PII ^^^M^^^796 781315^^^2 135-2-SLF~ ~0189~2135 -2~~CDC^^" "
	273
	274	RF1 Segmen t Example:
	275	RF1^^^SAD^ ^^509~USVA MC^2018080 1^^^
	276	RF1^^^PHH^ ^^608~USVA MC^2018022 3110027-06 00
	277	RF1^^^CPH^ ^^608~USVA MC^2018022 3110027-06 00
	278
	279	Email Phon e change t est:
	280	Details:
	281	ORUZ07 Mes sage –
	282	updated PID Segme nt SEQ=13, DT=XTA wi th a new e mail addre ss
	283	added RF1 Segmen ts with mo st recent update dat e
	284
	285	PID Segmen t Example:
	286	PID^1^1008 589404V203 273^100858 9404V20327 3~~~USVHA& &0363~NI~V A FACILITY ID&200M&L \|796781315 ~~~USSSA&& 0363~SS~VA FACILITY ID&608&L\|7 171927~~~U SVHA&&0363 ~PI~VA FAC ILITY ID&6 08&L\|~~~US VBA&&0363~ PN~VA FACI LITY ID&60 8&L^^BLSTC DCOKRP~BFS TCDCOKRP~B ATCH~^^197 60118^F^^1 002-5-SLF~ ~005~1002- 5~~CDC\|210 6-3-SLF~~0 05~2106-3~ ~CDC^5678 LEGACY DRI VE~#APT 22 2 ~PLANO~T X~75024~US A~P~~085\|8 000 LEGACY DRIVE~#AP T 111 ~PLA NO~TX~7502 4~USA~R~~0 85^085^(46 9)334-1234 ~ORN~CP\|( )332-1234~ PRN~PH\|~NE T~INTERNET ~ PII v^^^M^^^79 6781315^^^ 2135-2-SLF ~~0189~213 5-2~~CDC^^ ""
	287
	288	RF1 Segmen t Example:
	289	RF1^^^SAD^ ^^509~USVA MC^2018080 1^^^
	290	RF1^^^EAD^ ^^608~USVA MC^2018080 5110027-06 00
	291
	292	Add Early Separation Reason Co de to ZMH Message Se gment
	293	Change Req uest
	294	It has bee n requeste d that a 1 0th field be added t o the ZMH Message Se gment in t he Z11 Mes sages. Thi s new fiel d will con tain the c ode for th e Early Se paration R eason, whi ch is alre ady in the ZMH Messa ge Segment as the 9t h field.
	295	Code Chang es
	296	Code chang es need to be made t o ZMH.java to add th e Early Se paration R eason Code as the 10 th field i n the ZMH message se gment. Thi s involves adding ge t and set methods wh ich allow for retrie ving and s toring the code in t he message segment.
	297
	298
	299	Figure 13: Code chan ges in ZMH .java
	300
	301
	302	Figure 14: Code chan ges in ZMH Builder.ja va
	303	In additio n, modific ations nee d to be ma de to ZMHB uilder.jav a to retri eve the co de from th e Narrativ e Reason ( if it exis ts) and st ore it in the ZMH me ssage segm ent.
	304
	305
	306	Figure 15: Change to ZMH schem a
	307	The schema for the Z MH segment , ZMH.xsd, must be u pdated to include th e Early Se paration R eason Code . In addit ion, ZMH.x ml must al so be upda ted to add the field .
	308	Modificati ons also n eed to be made to en sure that the Early Separation Reason Co de can be viewed by the user u nder the F acility Ta b in the E nrollment System app lication. This invol ves updati ng esr_tra nsform.xsl to includ e the Earl y Separati on Reason Code.
	309
	310
	311	Figure 16: Update to template in order t o show Ear ly Separat ion Reason Code in U I
	312
	313	Add MOH Aw ard Date i n ES
	314	Change Req uest
	315	It has bee n requeste d that dev elopers mo dify the E S applicat ion to sup port the M OH Award D ate field. This chan ge will in clude the following components :
	316	Updating t he MSDS in terface to support t he MOH Awa rd Date
	317	Updating t he ADR to allow for storage of the MOH A ward Date, as well a s to add a new capab ility for modifying MOH inform ation.
	318	Modifying the user i nterface f or the Mil itary Serv ice and Mi litary Ser vice Histo ry screens to displa y the MOH Award Date
	319	Updating t he Z11 Mes sage to in clude the MOH Award Date and M OH Status Date
	320	Database C hanges
	321	The databa se table, which stor es informa tion about Medal of Honor reco rds, is ca lled MEDAL _OF_HONOR. This tabl e will be modified t o add a ne w DATE col umn called AWARD_DAT E, which w ill be use d to store the MOH A ward Date field. MED AL_OF_HONO R_H, which stores hi storical M edal of Ho nor record s, will be modified in the sam e manner.
	322	The table that store s informat ion pertai ning to ca pabilities is PERMIS SION_TYPE. A new row will be a dded to th is table c orrespondi ng to the “Edit MOH” capabilit y.
	323	Code Chang es
	324
	325	Figure 17: Code Chan ges to EMI SMilitaryI nformation ServiceCli ent.java
	326
	327	Figure 17: Code Chan ges to EMI SMilitaryI nformation ServiceCli ent.java
	328	The MOH Aw ard Date i s already being sent to the eM IS client, but only the MOH in dicator is being pro cessed. Th is occurs in EMISMil itaryInfor mationServ iceClient, where the indicator is stored in a BIRL S object. Therefore, the BIRLS class wil l be modif ied to add a field f or the MOH Award Dat e (there a re two cla sses named BIRLS, so both will be update d), and th en EMISMil itaryInfor mationServ iceClient will be up dated to s tore the A ward Date retrieved from eMIS in this fi eld.
	329
	330	The MEDAL_ OF_HONOR t able in th e database is mapped to the Me dalOfHonor class, so a new fie ld will be added to this class correspon ding to th e award da te. The hi bernate co nfiguratio n in Medal OfHonor.hb m.xml will be update d to compl ete the ma pping betw een the Aw ard Date f ield and t he column in the MED AL_OF_HONO R table.
	331	Once the M OH Award D ate is ret rieved fro m eMIS, it is stored in a Meda lOfHonor o bject. Thi s happens in Militar yServiceBu ilderForMS DS. The re quirements specify t hat the Aw ard Date s hould not be stored in ES if i t is a fut ure date, or if it i s earlier than the V eteran’s 1 5th birthd ay; and so both cond itions wil l be check ed before storing th e date in the MedalO fHonor obj ect. If th e MOH Awar d Date rec eived from eMIS is i nvalid, th e value of the Award Date stor ed in ES w ill be set to NULL.
	332
	333	Figure 18: Code Chan ges to ZMH Builder.ja va
	334
	335	Figure 18: Code Chan ges to ZMH Builder.ja va
	336	To add the MOH Award Date and MOH Status Date to t he Z11 HL7 Message, the setMed alOfHonor method in ZMHBuilder , which cu rrently se ts the MOH Indicator , will be modified t o store bo th dates i n the ZMH segment. B oth dates will be st ored in th e serviceE ntryDateAn dServiceSe parationDa te field o f the ZMH segment af ter being properly f ormatted
	337	The MOH St atus Date will be se nt regardl ess of the value of the MOH In dicator. I f the valu e of the I ndicator i s set to ‘ N’, the MO H Award Da te will be sent as a NULL valu e.
	338
	339	Example ZM H Message Segment wi th MOH Ind icator set to ‘Y’:
	340
	341	ZMH^1^SL^A IR FORCE~" "~HONORABL E^20000101 ~20010101
	342	ZMH^2^FDD^ AIR FORCE~ ""~""^2013 0101~""^^^ ^20190101
	343	ZMH^3^MH^Y ^20180101~ 20181025
	344
	345	Example ZM H Message Segment wi th MOH Ind icator set to ‘N’:
	346
	347	ZMH^1^SL^A IR FORCE~" "~HONORABL E^20000101 ~20010101
	348	ZMH^2^FDD^ AIR FORCE~ ""~""^2013 0101~""^^^ ^20190101
	349	ZMH^3^MH^N ^""~201810 25
	350
	351	To support the new “ Edit MOH” capability , the Capa bility cla ss will be updated t o add the Code for E dit MOH, s o that it will be ac cessible f rom other parts of t he applica tion.
	352	User Inter face Chang es
	353	Both the M ilitary Se rvice and Military S ervice His tory scree ns will be updated t o add a Me dal of Hon or Award D ate field.
	354	If the MOH Indicator is receiv ed from th e MSDS Bro ker with a value of “Yes”, the MOH Award Date will be displa yed in the Military Service sc reen as a read-only label.
	355
	356
	357	Figure 19: MOH Award Informati on Receive d from MSD S
	358	If the MOH Award Dat e was not received f rom MSDS a nd the use r has the “Edit MOH” capabilit y, then th ey will be able to m anually en ter a valu e for the Award Date .
	359
	360
	361	Figure 20: Manually Entered MO H Award In formation
	362	The layout for the M ilitary Se rvice scre en is spec ified in m ilitarySer viceOvervi ew.jsp. Th e JSP will be modifi ed to add the Medal of Honor A ward Date field. The field wil l be imple mented so that it ca n be rende red as eit her a labe l or an ed itable tex t field, b ased on th e user rol es and the source of the Medal of Honor informatio n. The Doc ument Rece ipt Date f ield will also be mo dified to appear as a label if the user does not h ave the “E dit MOH” c apability, or if the date was received f rom the MS DS Broker.
	363	Similar up dates will also be a pplied to the Medal of Honor I ndicator, Document T ype, and S ource of C hange fiel ds. The sc reen will render the se fields as read-on ly if the user does not have t he “Edit M OH” capabi lity, or i f the data was recei ved from t he MSDS Br oker.
	364	A MOH Awar d Date fie ld will be added to MilitarySe rviceInfoF orm so tha t the valu e of the A ward Date can be pas sed betwee n the view and the c ontroller.
	365	When the M edal of Ho nor Award Date is ed itable, it will be a required field. In addition, the field will be va lidated to ensure th at the dat e entered is not a f uture date , and that it is not before th e Veteran’ s 15th bir thday. Thi s will be enabled by modifying the valid ateMedalOf Honor meth od in Mili taryServic eValidator to check whether th e MOH Awar d Date ent ered by th e user mee ts the con ditions gi ven above.
	366	In additio n, the No Data radio button un der the Me dal of Hon or Indicat or will be disabled.
	367	The Medal of Honor A ward Date will also be display ed in the Military S ervice Cha nge Histor y screen. This will require mo difying th e configur ation in m ilitaryser vice/strut s-actions. xml to add the MOH A ward Date field.
	368
	369
	370	Figure 21: Change to militarys ervice/str uts-action s.xml
	371
	372	Preferred Name with MVI as Sou rce
	373	Change Req uest
	374	It has bee n requeste d that dev elopers mo dify the E S applicat ion to sup port the P referred N ame. This will invol ve changes to the ES user inte rface to a llow the u ser to add or modify the Prefe rred Name in the Dem ographic I dentity Tr aits tab a nd the Add a Person Search scr een. It wi ll also in volve chan ges to the ES Banner so that t he Preferr ed Name ca n be displ ayed along with the legal name . Lastly, the interf ace betwee n ES and M VI will be updated t o support sending th e Preferre d Name.
	375
	376	Code Chang es
	377
	378	Figure 22: Getter an d Setter f or Preferr ed Name
	379	Figure 22: Getter an d Setter f or Preferr ed NameEac h Person r ecord has a set of N ame record s associat ed with it . In addit ion to the parts of the name i tself (fir st name, l ast name, etc), a Na me record also conta ins a Name Type, whic h specifie s what typ e of name it is. A P referred N ame is ide ntified by a NameTyp e with cod e “N”, for “Nickname ”. To supp ort the Pr eferred Na me functio nality, de velopers w ill add a getter and setter me thod to Pe rson which will retr ieve and s tore a Nam e using th is NameTyp e.
	380	Because de velopers a re simply leveraging the exist ing name f unctionali ty, no add itional ch anges will be needed in either the datab ase or the Person ty pe.
	381	Developers will be u pdating bo th the 130 1 (Add) an d 1302 (Up date) requ ests of th e IDM Web Service to include t he Preferr ed Name. T o this end , a new me thod will be added t o the IdmS erviceVO c lass which returns t he Preferr ed Name fr om the lis t of name records.
	382	A new meth od, called getPrefer redNameFro mSet will be added t o IdmWebSe rviceDeleg ateImpl to allow the Preferred Name to b e extracte d from a s et of name s. Then, t he populat e1301Perso n and popu late1302Pe rson metho ds will be updated s o that the Preferred Name can be populat ed in the Person por tion of bo th request s.
	383
	384
	385	User Inter face Chang es
	386	The Identi ty Traits tab on the Demograph ics screen will be u pdated to include a Preferred Name field . This wil l be a fre e text fie ld which w ill have a width of 40 charact ers, and w ill allow up to 80 c haracters of input. The layout of the Id entity Tra its tab is specified in demogr aphicIdent ityTraitsC ontent.jsp , so this file will be modifie d to add t ags for th e text fie ld. The fi le Demogra phicMessag es.propert ies will a lso be mod ified to a dd the lab el text fo r the new field.
	387	Although M VI support s multiple component s for the Preferred Name (firs t name, mi ddle name, etc), ES will only have this one field. Therefore , when a u ser enters a value i n the Pref erred Name field, it will be s tored in t he given ( or first) name field of the co rrespondin g Name rec ord. Likew ise, the g iven name will be us ed to popu late the f ield if it already h as a value .
	388
	389	Figure 23: Preferred Name fiel d on Ident ity Traits tab
	390	Figure 23: Preferred Name fiel d on Ident ity Traits tab
	391
	392
	393
	394
	395
	396
	397
	398
	399
	400
	401
	402
	403	The data o n the Iden tity Trait s tab is p assed to a nd from th e controll er in a De mographicI dentityTra itsForm ob ject. The class will be update d to inclu de a field for the P referred N ame, along with a ge tter and s etter meth od for thi s field.
	404	Demographi cIdentityT raitsConve rsionServi ce is the type used to transfe r data bet ween the P erson reco rd and the Demograph icIdentity TraitsForm . The doCo nvertPerso ntoEditabl eForm meth od will be modified to retriev e the Pref erred Name from the Person rec ord and st ore it in the form, so that th e value ca n be popul ated in th e screen. In additio n, the con vertFormto Person met hod, which is called when the data on th e screen i s updated will be mo dified to populate t he Person record wit h the Pref erred Name informati on in the form.
	405	The contro ller for t he Identit y Traits s creen, whi ch is foun d in Demog raphicsIde ntityTrait sAction.ja va will be modified to validat e the inpu t from thi s new fiel d. A new m ethod will be added to the con troller th at will re turn a boo lean value correspon ding to wh ether the Preferred Name is va lid. The m ethod will check the following condition s (if a Pr eferred Na me has bee n provided by the us er):
	406
	407	The Prefer red Name i s less tha n or equal to 80 cha racters in length.
	408	The Prefer red Name o nly contai ns alphabe tical char acters, sp aces, hyph ens, and a postrophes .
	409
	410	If any of these cond itions are not true for the pr ovided nam e, the met hod will r eturn fals e, and an ActionMess age will b e added co rrespondin g to the c ondition t hat was vi olated. If all the c onditions are met, t he method will retur n true. Th is method will be in voked from the updat e method o f Demograp hicsIdenti tyTraitsAc tion, so t hat it wil l be execu ted along with the o ther valid ations for the form.
	411	In additio n, develop ers will b e removing the “View Submitted Identity Traits” an d “View Hi storical I dentity Tr aits” tabs from ES. To do this , develope rs will re move the l inks to th ese tabs w hich are f ound in th e Identity Traits sc reen. In t heir place , develope rs will ad d a link w ith the na me “View I dentity Au dit - MVI Toolkit”, which will allow the user to n avigate di rectly to the MVI To olkit home screen fo r the curr ent vetera n.
	412	The Prefer red Name f ield will also be ad ded to the Add a Per son Search screen. T he layout for this s creen is s pecified i n searchNe wCriteria. jsp. As wi th the Ide ntity Trai ts screen, a free te xt field w ill be add ed which w ill allow up to 80 c haracters of input. However, t he field w ill only b e 20 chara cters wide , in keepi ng with th e rest of the screen ’s layout.
	413	SearchActi onForm wil l be modif ied to add a Preferr ed Name fi eld, so th at the inf ormation e ntered on the screen can be se nt to the controller . In Searc hAction, w hich serve s as the c ontroller for the Ad d a Person Search sc reen, the createIdmS erviceVO a nd convert IdmService VOToPerson methods w ill be mod ified to a dd the map ping of th e Preferre d Name. Th is will en sure that the Prefer red Name c an be sent and recei ved using the IDM We b Service.
	414
	415
	416
	417
	418
	419
	420
	421	Figure 24: Preferred Name fiel d in Add a Person Se arch scree n
	422	Figure 24: Preferred Name fiel d in Add a Person Se arch scree n
	423
	424
	425
	426
	427
	428
	429	Lastly, th e ES banne r will be modified t o display the Prefer red Name. The layout for the b anner is s pecified i n the file veteranBa nner.jsp.
	430	The ES ban ner is rep resented a s an HTML table. The first row in the ta ble is the header, w hich displ ays whethe r the reco rd is a se nsitive re cord, or i f it has a Future Di scharge Da te. The se cond row i s the body of the ba nner, whic h shows th e Member I D, Name, S NN, DOB, e tc.
	431	When a rec ord has a Preferred Name, a ne w row will be added to the bod y of the b anner. Thi s row will have two cells. The first cel l will act as a plac eholder, t o allow th e Preferre d Name to appear dir ectly unde rneath the Name. The second ce ll will co ntain the Preferred Name. This cell will be given a colspan of 5, so t hat if the Preferred Name has a lot of c haracters, it will r ender bene ath the ot her data e lements, s uch as the SSN and D OB.
	432	Figure 25: ES Banner showing P referred N ame of max imum lengt h (80 Char acters)
	433
	434	VeteranHea derBean is the class which con tains the informatio n that is displayed in the ban ner. A new field wil l be added to this c lass so th at the Pre ferred Nam e can be p opulated i n the bann er.
	435
	436	Figure 25: Code chan ges in Per sonAbstrac tAction to populate Preferred Name in ES Header
	437	Figure 25: Code chan ges in Per sonAbstrac tAction to populate Preferred Name in ES HeaderThe informati on shown i n the bann er is popu lated in t he updateH eader meth od of Pers onAbstract Action. Co de will be added to this metho d which wi ll retriev e the Pref erred Name from the Person rec ord, forma t it, and store it i n the Vete ranHeaderB ean. As pr eviously m entioned, although M VI support s multiple parts for the Prefe rred Name, ES will o nly use th e given (o r first) n ame to pop ulate the Preferred Name in th e applicat ion.
	438	Future Dis charge Dat e from HCA
	439	Change Req uest
	440	It has bee n requeste d that the developer s modify t he ES appl ication to support r eceiving t he Future Discharge Date (FDD) from HCA applicatio ns. When a n applicat ion contai ning an FD D is recei ved, the s ystem will set an en rollment s tatus of “ Not Applic able”, rat her than “ Pending”.
	441	It has als o been req uested tha t the deve lopers upd ate ES so that only Future Dis charge Dat es less th an a year in the fut ure will b e accepted by the ap plication. This chan ge will al so apply t o Future D ischarge D ates that are receiv ed from MS DS.
	442	Lastly, it has been requested that ES be modified to update the Vetera n indicato r of a rec ord based on the act ive duty i ndicator t hat is rec eived from MSDS.
	443
	444	Code Chang es
	445	When new d ata is rec eived from HCA, the processVOA method of MessageSe rvice, whi ch is impl emented in MessageSe rviceImpl, is called . This met hod will b e modified to check if a Futur e Discharg e Date is present in any of th e military service e pisodes re ceived fro m HCA. If one is fou nd, the Pe rson recor d will be updated in the follo wing ways:
	446	The Vetera n Indicato r will be set to fal se
	447	The Incomi ng Eligibi lity Verif ication St atus will be set to “Verified”
	448	The Incomi ng Eligibi lity Verif ication So urce will be set to “VAMC”
	449	“Sharing A greement” will be ad ded to the record as a receive d eligibil ity on the incoming record
	450	“Tricare” will be ad ded to the record as a receive d eligibil ity on the incoming record
	451	To check w hether any of the in coming mil itary serv ice episod es have a future dis charge dat e, a new m ethod will be added to Message ServiceImp l called h asHCAFdd. This metho d will ite rate throu gh every m ilitary se rvice epis ode in eve ry militar y service site recor d received from HCA. If an epi sode is fo und which does not h ave a disc harge type (meaning that the V eteran has not yet b een discha rged), the method wi ll return a value of true. Oth erwise, it will retu rn false.
	452
	453	Figure 26: Implement ation of h asHCAFdd m ethod
	454
	455	Typically, the Veter an indicat or is not changed wh ile proces sing incom ing VOA da ta. Howeve r, because the Veter an indicat or will be changed t o “false” when an FD D is recei ved, addit ional chan ges will b e made to processVOA to ensure that the incoming e ligibility verificat ion and Ve teran indi cator are populated correctly.
	456	In additio n, the det erminePati entType me thod in Pe rsonServic eImpl will be modifi ed to retu rn a Patie nt Type of “Non-Vete ran” when the person has an el igibility type of “S haring Agr eement” bu t does not have a cu rrent peri od of serv ice. This will ensur e that the patient t ype for th e person i s set corr ectly for the scenar io where a n FDD is r eturned fr om HCA.
	457	To support the chang es that th ey will be making to the busin ess rules (detailed below), de velopers w ill modify the Milit aryService InputParam eter class . A new me thod will be added t o this cla ss called resultHasH CAFdd whic h will sea rch the mi litary ser vice site records fr om HCA and return tr ue if one of them ha s a Future Discharge Date. The checkForE xistingHec SiteRecord method wi ll also be modified to create a blank mi litary ser vice recor d if one d oesn’t alr eady exist .
	458	User Inter face Chang es
	459	Currently, the Futur e Discharg e Date (FD D) field o n the Mili tary Servi ce screen is validat ed to make sure that the date entered is not more than two y ears in th e future. This valid ation occu rs in the isFutureDi schargeDat eCorrect2 method of the Milita ryServiceI nfoForm cl ass (which is invoke d from Mil itaryServi ceValidato r).
	460	This metho d will be modified t o check if the provi ded FDD is more than a year in the futur e, rather than two y ears. If i t is, a me ssage will be displa yed to the user info rming them that the date they entered is too far i n the futu re. The te xt of the error mess age is sto red in Mil itaryServi ceMessages .propertie s, so the file will be edited to reflect this chan ge.
	461
	462
	463	Figure 27: Updated v alidation of Future Discharge Date on Mi litary Ser vice scree n
	464
	465	Rule Chang es
	466	The incomi ng eligibi lity verif ication da ta will be processed and accep ted as par t of the P rocessNewV eteranRule Flow. A ch eck on the FDD being self-repo rted will be added t o determin e whether the eligib ility veri fication d ata should be accept ed.
	467	The Determ ineEligibi lity rule flow will be updated to set th e primary and second ary eligib ility of t he person when an FD D is recei ved from H CA. The Pr imaryCodeI sSharingAg reement ru le will be modified to check w hether the incoming person is a new reco rd with an FDD from VOA. If bo th conditi ons are me t, the per son’s prim ary eligib ility will be set to “Sharing Agreement” . The Seco ndaryCodeI sTriCare r ule will b e modified in the sa me manner, and will set the pe rson’s sec ondary eli gibility t o “Tricare /CHAMPUS” if both co nditions a re met.
	468
	469
	470	Figure 28: Modified PrimaryCod eIsSharing Agreement rule
	471
	472	In additio n, the New PersonIsNo nVeteran r ule in the ProcessNe wVeteran r ule flow w ill be upd ated to ac count for the FDD. I f an FDD h as been se lf-reporte d, the rul e will acc ept the el igibility verificati on data fr om the inc oming HL7 message.
	473	The Proces sMilitaryS ervice rul e flow is invoked wh en militar y service informatio n is updat ed, either through t he UI or a service ( such as MS DS). The a cceptFutur eDischarge FromEMIS r ule, which is part o f this rul e flow, de termines w hether to accept a F uture Disc harge Date that has been recei ved from M SDS. As cu rrently im plemented, this rule only chec ks whether the “Acce pt FDD fro m MSDS” sy stem param eter is se t to “Y”; and accept s the inco ming FDD i f it is. T he rule wi ll therefo re be upda ted to als o consider how far i n the futu re the FDD is.
	474	Developers will modi fy the Pro cessMSDS r ule flow t o set the Veteran in dicator ba sed on the incoming active dut y indicato r. The SUC 1013_6_11t o18_SetVet eranIndica torRules s ub flow im plements t he rules u sed to det ermine how the Veter an indicat or is set, so it wil l be modif ied to con sider the incoming a ctive duty indicator . If the i ncoming ac tive duty indicator is “No”, t hen the Ve teran indi cator will be set to “Yes”; an d if the i ncoming ac tive duty indicator is “Yes”, then the V eteran ind icator wil l be set t o “No”.