1. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 12/6/2017 4:39:06 PM Eastern Standard 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.

1.1 Files compared

#	Location	File	Last Modified
1	eInsurance_Build_17_IB_2_601.zip	TAS+eIns+US2543+Medicare+Beneficiary+Identifier+Request.docx	Wed Nov 8 18:24:02 2017 UTC
2	eInsurance_Build_17_IB_2_601.zip	TAS+eIns+US2543+Medicare+Beneficiary+Identifier+Request.docx	Wed Dec 6 21:33:28 2017 UTC

1.2 Comparison summary

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

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

1.4 Active regular expressions

No regular expressions were active.

1.5 Comparison detail

	1	User Story Number: US2543
	2	User Story Name: Med icare Bene ficiary Id entifier ( MBI) Reque st
	3	Author: eI nsurance
	4
	5	Epic Taxon omy
	6	eBiz Com pliance Port Upda te Increase N o Touch TAS A pps
	7
	8	Story
	9	As an Insu rance Veri fication u ser, I nee d to gener ate an ad hoc (real- time) mess age for a patient wh o may have Medicare coverage t o request the patien t's new Me dicare Ben eficiary I dentifier (MBI) numb er so I ca n load tha t value in the patie nt's Medic are insura nce file.
	10	*Note*
	11	This is VA special a ccess gran ted by the Centers f or Medicar e Services (CMS). Ne ither the existence of this ab ility nor the detail s of this process sh all be sha red outsid e this tea m. Sharing these det ails outsi de of eBus iness Solu tions, the assigned Developmen t team(s), VA Financ ial Servic es Center (FSC), and VA Office of Inform ation and Technology (OIT) wou ld comprom ise the VA ability t o exchange this tran saction wi th CMS. VA eBusiness Solutions is the on ly entity being offe red this s pecial acc ess.
	12	Problem St atement
	13	The Center s for Medi care & Med icaid Serv ices (CMS) is replac ing their Health Ins urance Cla im Number (HICN or H IC) with a Medicare Beneficiar y Identifi er (MBI). The MBI sh all become the ident ifier that eInsuranc e routines store as Subscriber ID for Me dicare sub scribers ( in place o f the HICN ).
	14	Related Do cuments
	15	US2543 – M edicare Be neficiary Identifier (MBI) Req uest – Dev eloper Con sideration s
	16	US2644 – C apture REF Q4 Conten t in Medic are EIV an d MBI Resp onses (Fut ure)
	17	US2646 – A d Hoc Medi care Benef iciary Ide ntifier (M BI) Cleanu p Extract (Future)
	18	eBilling U ser Story 2556 – Rem ove All Ch ecks for V alid HIC F ormat (Dep endency on this user story)
	19	Background
	20	CMS plans a phased t ransition to the use of the MB I. The dat e boundari es for the transitio n period a re below:
	21	Begin Apri l 1, 2018
	22	End Decemb er 31, 201 9
	23	CMS will b egin maili ng new car ds (bearin g the MBI) to their subscriber s in a pha sed mail-o ut, beginn ing April 1, 2018. T he CMS sch eduled “go live” for the MBI R equest tra nsaction b eing offer ed to VA i s March 10 , 2018. Du ring the H ICN-to-MBI transitio n period, CMS will a ccept eith er the HIC N or the M BI as the Subscriber ID in inc oming tran sactions, with the f ollowing e xception:
	24	Patients w ho are new ly enrolle d in Medic are (with effective dates of A pril 1, 20 18, or lat er) will n ot be issu ed a HICN. Any trans actions su bmitted on behalf of these pat ients afte r April 1, 2018, mus t submit t he MBI as Subscriber ID for th at patient (with no exceptions ).
	25	As of Janu ary 1, 202 0, all Med icare tran sactions s ent to CMS must incl ude the MB I. Any tra nsaction w ith a HICN would the reafter be rejected for the re ason Inval id Subscri ber ID.
	26	User Story Scope
	27	The scope of this us er story i ncludes in terdepende nt effort in three f unctional areas:
	28	Developmen t of MB MB I Request action fro m EIV > EI (Request Electronic Insurance Inquiry)
	29	HL7 Admini stration m essage sta ndard impl ications
	30	FSC (EDI 2 70/271) pr ocessing i mplication s
	31	MBI Reques t Menu and Prompt Se quences
	32	It is prop osed that the existi ng EIV men u and EI ( Request El ectronic I nsurance I nquiry) fu nction be used to im plement th e proposed MB MBI Re quest acti on.
	33
	34
	35	Select Pat ient Insur ance Menu <TEST ACCO UNT> Optio n: EIV eI V Menu
	36	AB Add Auto M atch Entri es Using I nsurance B uffer Data
	37	AE Enter/Edit Auto Matc h Entries
	38	EI Request El ectronic I nsurance I nquiry
	39	HL HL7 Respon se Report
	40	IU eIV Auto U pdate Repo rt
	41	LR eIV Payer Link Repor t
	42	MW Medicare P otential C OB Worklis t
	43	NI Potential New Insura nce Found
	44	PR eIV Payer Report
	45	RR eIV Respon se Report
	46	SR eIV Statis tical Repo rt
	47	Select eIV Menu Opti on: EI Re quest Elec tronic Ins urance Inq uiry
	48	Select PAT IENT NAME: <ENTER PA TIENT NAME >
	49	eIV Insura nce Reques t Aug 01, 20 17@18:49:1 8 Page: 1 of 1
	50	Request El ectronic I nsurance I nquiry for Patient: IB,PATIENT IXXXX
	51	*** Patien t has Insu rance Buff er Records
	52	Insur ance Co. Type of P olicy Gr oup Holder E ffect. Expires
	53	1 MEDICA RE (WNR) MEDICARE ( M) PAR T A S ELF 06 /22/2017
	54	2 MEDICA RE (WNR) MEDICARE ( M) PAR T U NKNOWN
	55	Enter ?? f or more ac tions
	56	SE Select Entry MB – MBI Req uest EX Ex it
	57	Select Act ion: Quit/ / MB
	58	Are you su re you wan t to reque st this Pa tient’s Me dicare Ben eficiary N umber? YES // Y
	59	Insurance Buffer ent ry created !
	60	Type <Ente r> to cont inue or '^ ' to exit:
	61
	62
	63	MBI Reques t Business Rules
	64	MBI Reques t (MB) act ion shall be initiat ed from th e EIV EI m enu (and n o other me nu action shall trig ger MBI Re quest).
	65	MBI Reques t (MB) act ion shall be signifi ed on the EIV EI dis play as MB – MBI REQ UEST.
	66	MBI Reques t (MB) act ion shall generate a real-time transacti on which b egins as a n entry in the Insur ance Verif ication Pr ocessor (B uffer) Fil e (#355.33 ) and is s ubsequentl y transfer red to the IIV Trans mission Qu eue (#365. 1) in the same way a s the curr ent EI Req uest Elect ronic Insu rance Inqu iry.
	67	MBI Reques t (MB) act ion shall make inqui ry using t he followi ng data el ements (wh ich shall be derived from the Patient co ntext and shall not be prompte d entries in the MB action):
	68
	69	Data Eleme nt
	70	HL7 Segmen t/Sequence
	71	X12 270 Se gment/Desi gnator/Loo p
	72	Comments
	73	Patient La st Name
	74	PID/5-1-1 (Last Name )
	75	NM1 NM 103 Lo op 2100C ( all)
	76	Populate u sing curre nt process .
	77	Patient Fi rst name
	78	PID/5-2 (F irst name)
	79	NM1 NM 104
	80	Populate u sing curre nt process .
	81	Patient DO B
	82	PID/7-1 (D ate)
	83	DMG DM G02
	84	Populate u sing curre nt process .
	85	Patient So cial Secur ity Number
	86	PID/19 (SS N)
	87	NM1 NM 109
	88	“Reactivat e” HL7 seg ment and p opulate wi th SSN.
	89	VistA shal l map the Patient Na me and Dat e of Birth as sent i n the MBI Request to Buffer fi le.
	90	MBI Reques t (MB) act ion shall assign the Special M BI Payer, as defined in the IB Site Para meters Fil e to the M BI Request and shall display t he value a ssigned to that para meter (def ined as “C MS MBI ONL Y”) in the Insurance Company f ield of th e Buffer d isplay.
	91	For MBI Re quest (MB) , VistA sh all popula te the Sub scriber ID field in the Buffer file and display wi th the val ue “MBIreq uest
	92	MBI Reques t (MB) act ion shall populate t he (existi ng) second repeating NTE segme nt of the HL7 messag e, which i s designat ed as Sour ce of Info rmation (S OI), with the value “MEDICARE. ”
	93	MBI Reques t (MB) act ion shall include a Type of Re quest iden tifier of “MBI” in a proposed third repe ating NTE segment of the HL7 m essage.
	94	When proce ssing the MBI Reques t, VistA s hall autom atically s et Patient Relations hip to Ins ured = Sel f.
	95	MBI Respon se Busines s Rules
	96	VistA shal l map the MBI number received in the HL7 Response (IN1 Segme nt, Sequen ce 2-1) to the Subsc riber ID f ield in th e Buffer f ile.
	97	VistA shal l map the Payer name received in the HL7 Response to the Ins urance Com pany field in the Bu ffer File.
	98	When proce ssing the MBI Respon se, VistA shall auto matically set Patien t Relation ship to In sured = Se lf.
	99	The Respon se receive d as a res ult of the MBI Reque st (even w hen succes sful) shal l not auto -update in the IIV R esponse Fi le (#365).
	100	The Respon se receive d as a res ult of the MBI Reque st shall b e persiste d in the B uffer and shall rema in there u ntil proce ssed by a human.
	101	If CMS is able to lo cate the P atient who is the su bject of a n MBI Requ est, but t he new Ide ntificatio n Card (wi th MBI) ha s not yet been maile d to that patient, w hen CMS/FS C returns the messag e New Medi care Card with MBI N ot Yet Mai led (as de tailed in the Busine ss Rule be low) that message sh all be dis played in the VistA (and ICB) Buffer ent ry (as sta tic inform ation for the user).
	102	FSC Busine ss Rules/R equirement s
	103	FSC-specif ic Busines s Rules ar e stated h ere to ens ure end-to -end cover age of the proposed functional ity.
	104	For the MB I Request X12 270 tr ansaction, FSC shall populate the Patien t Name, Pa tient DOB, and Subsc riber ID ( Patient SS N shall be sent in t he segment for Subsc riber ID, MM109).
	105	The MBI Re quest X12 270 transa ction conv eyed to CM S shall su pply the f ollowing d ata elemen ts for the transacti on (in add ition to t hose popul ated by Vi stA in the HL7 messa ge as arti culated ab ove):
	106	Station NP I (FSC sha ll populat e this fie ld).
	107	A Submitte r ID that is unique to the MBI Request a ction and is differe nt from th e Submitte r ID used for Insura nce Verifi cation req uests sent to CMS (F SC shall p opulate th is field).
	108	Subscriber ID Code Q ualifier = “MI” (FSC shall pop ulate this field in the X12 27 0 as is cu rrently do ne for the Insurance Verificat ion Reques t).
	109	CMS Not Ab le To Loca te Patient
	110	If CMS is unable to locate the Patient w ho is the subject of an MBI Re quest and responds w ith an AAA * Request Validation error of Invalid Su bscriber I D, then FS C shall ec ho back th e Patient Identifica tion (PID) and Payer ID (IN1) that were sent by Vi stA (FSC s hall use e xisting ma pping to e cho).
	111	CMS Able t o Locate P atient but Identific ation Card with MBI Has Not Ye t Been Mai led
	112	If CMS is able to lo cate the P atient who is the su bject of a n MBI Requ est but th e new Iden tification Card (wit h MBI) has not yet b een mailed to that p atient, an d CMS resp onds with the messag e New Medi care Card with MBI N ot Yet Mai led, then FSC shall to use exi sting mapp ing to ech o back the data that was sent by VistA.
	113	When CMS r eturns the message N ew Medicar e Card wit h MBI Not Yet Mailed , FSC shal l convey t hat messag e text to VistA (and also make it availa ble to ICB ) for disp lay in the Buffer en try.
	114	FSC Defini tion and C ommunicati on of Spec ial MBI Pa yer
	115	FSC shall define a S pecial MBI Payer and shall con trol the v alue assig ned to tha t Special Payer usin g a site p arameter.
	116	FSC shall send a Pay er Table U pdate Mess age (File #365.12) t o all site s to creat e the Spec ial MBI Pa yer (Payer ID = VA N ational ID ).
	117	FSC shall send a Tab le Update Message–IB Site Para meters (Fi le #350.9) to the si tes to con vey the va lue (point er) for th e Special MBI Payer.
	118	CMS Test I nterval an d Test Alt ernatives
	119	CMS will b e testing in live pr oduction d uring the period beg inning Jan uary 29, 2 018, and e nding Febr uary 23, 2 018. This window of opportuni ty for VA to test li ve with CM S coincide s with the currently scheduled IOC timef rame for e Insurance Build 4 (J anuary 16 to Februar y 13, 2018 ).
	120	In the eve nt that de pendencies and/or co nstraints do not all ow readine ss to test during th is window, FSC has p roposed a backup pla n to test using a si mulated en vironment.
	121	Test Consi derations
	122	There is s ome Build 4 gatekeep er code wi th restric tive crite ria for th e throughp ut of test patients to the FSC Eligibili ty Communi cator (IBC NEUT7 – Ge neral eIV Utilities) which sho uld not be supplied to sites d uring IOC (due to th e potentia l for crea ting extra work for testers). Suggestion is to tes t this fun ctionality during th e Componen t Integrat ion Test ( CIT) and/o r User Acc eptance Te st (UAT).
	123	The EI Req uest Elect ronic Insu rance Inqu iry functi on has a s ecurity ke y (IBCNE I IV SUPERVI SOR) assig ned at the menu leve l; however , it has b een verifi ed that CP AC assigns that key to all use rs. A futu re user st ory is pro posed to r emove this security key, since it has no effect.
	124	To assist in the ide ntificatio n of the M BI Request /Response and its as sociation with the d esignated Special Pa yer (pursu ant to the proposal to use a u nique Paye r both for the MBI R equest and also for the future Insurance Discovery Extract R equest), t he user sh ould set A uto Match [site para meter X (i nstead of “CMS”)] to [site par ameter Y ( the site p arameter f or the Spe cial MBI P ayer, inst ead of “Me dicare Pay er”)].
	125	Vista must be able t o handle t he conditi on where t he site pa rameter fo r Special MBI Payer has not ye t been pop ulated (du e to the p ossible no n-sequenti al receipt of Table Update Mes sages for the Payer Table and the associ ated site parameter) .
	126	The follow ing FSC-sp ecific fun ctionality (cited in the Busin ess Rules section of this User Story) mu st be test ed with IC B as well as in the VistA user interface :
	127	When CMS r eturns the message N ew Medicar e Card wit h MBI Not Yet Mailed , then FSC shall con vey that m essage tex t to VistA (and also make it a vailable t o ICB) for display i n the Buff er entry ( as static explanator y informat ion for th e user).
	128	Assumption s
	129	It is assu med that, although t he current code for EI Electro nic Insura nce Inquir y (Routine IBCNEQU) blocks inq uiries for non-Veter ans/depend ents, that block wil l not adve rsely impa ct the out come for M BI Request s (spouses and/or de pendents w ould typic ally be co vered by T ri-Care or CHAMPVA).
	130	VistA will not trans mit the GT 1 (Guarant or) segmen t in the H L7 message for the M BI Request , because patient re lationship to insure d will alw ays be Sel f.
	131	Acceptance Criteria
	132	Requiremen t ID
	133	Descriptio n
	134	External D ependency* (Y/N)
	135	Acceptance Criteria: MBI Reque st
	136	1.0
	137	MBI Reques t (MB) act ion, desig nated MB, is selecta ble from t he EIV EI menu and n o other me nu.
	138	N
	139	2.0
	140	MBI Reques t (MB) act ion genera tes a real -time tran saction wh ich begins as an ent ry in the Buffer fil e and is s ubsequentl y transfer red to the Transmiss ion Queue, in the sa me way as EI Request Electroni c Insuranc e Inquiry.
	141	N
	142	3.0
	143	MBI Reques t (MB) act ion makes inquiry us ing the fo llowing da ta element s, all of which are derived fr om the Pat ient Conte xt and non e of which are promp ted entrie s in the M B action:
	144	Patient La st NamePat ient First NamePatie nt DOBPati ent Social Security Number
	145	Y – Potent ial need f or HL7 Adm inistratio n Approval to Reacti vate PID19 for SSN.
	146	4.0
	147	VistA maps the Patie nt Name an d Date of Birth as s ent in the MBI Reque st (and re ceived in the MBI Re sponse) to the Buffe r file.
	148	N
	149	5.0
	150	MBI Reques t (MB) act ion assign s the Spec ial MBI Pa yer, as de fined in t he IB Site Parameter s File, to the MBI R equest and displays the value assigned t o that par ameter in the Insura nce Compan y field of the Buffe r display.
	151	Y – FSC to create Sp ecial MBI Payer
	152	6.0
	153	For MBI Re quest (MB) , VistA sh all popula te the Sub scriber ID field in the Buffer display w ith the va lue “MBIre quest.”
	154	N
	155	7.0
	156	MBI Reques t (MB) act ion popula tes the ex isting sec ond repeat ing NTE se gment of t he HL7 mes sage, whic h conveys Source of Informatio n, with th e value “M EDICARE.”
	157	N
	158	8.0
	159	MBI Reques t (MB) act ion popula tes the th ird repeat ing NTE se gment of t he HL7 mes sage, whic h is desig nated to c onvey Type of Reques t, with th e value “M BI.”
	160	Y – HL7 Ad ministrati on Approva l
	161	9.0
	162	When proce ssing the MBI Reques t, VistA a utomatical ly sets Pa tient Rela tionship t o Insured = “Self.”
	163	N
	164	Acceptance Criteria: MBI Respo nse
	165	10.0
	166	VistA maps the MBI n umber rece ived in th e IN1 segm ent of the HL7 Respo nse to the Subscribe r ID field in the Bu ffer file.
	167	N
	168	11.0
	169	VistA maps the Payer name rece ived in th e HL7 Resp onse to th e Insuranc e Company field in t he Buffer file.
	170	N
	171	12.0
	172	When proce ssing the MBI Respon se, VistA automatica lly sets P atient Rel ationship to Insured = “Self.”
	173	N
	174	13.0
	175	The Respon se receive d as a res ult of the MBI Reque st (even w hen succes sful) does not auto- update in the IIV Re sponse Fil e (#365).
	176	N
	177	14.0
	178	The Respon se receive d as a res ult of the MBI Reque st is pers isted in t he Buffer and remain s there un til proces sed by a h uman.
	179	N
	180	15.0
	181	If CMS/FSC returns t he message New Medic are Card w ith MBI No t Yet Mail ed, then V istA displ ays that m essage in the Buffer entry.
	182	Y – FSC re turns mess age text
	183	*Any depen dencies id entified i n this col umn are co rrelated w ith the de pendency d escription s supplied in the se ction that follows.
	184
	185	Requiremen t ID
	186	Descriptio n
	187	External D ependency( Y/N)
	188	Acceptance Criteria: FSC Funct ionality
	189	Acceptance Criteria pertaining to FSC fu nctionalit y are stat ed here to ensure fu ll coverag e of all r elevant te st/accepta nce criter ia.
	190	16.0
	191	FSC popula tes the X1 2 270 with Patient N ame, Patie nt DOB, an d Subscrib er ID (Pat ient SSN i s sent in the segmen t for Subs criber ID, NM109).
	192	N
	193	17.0
	194	FSC popula tes the X1 2 270 Requ est with t he Station NPI for t he site or iginating the transa ction.
	195	N
	196	18.0
	197	FSC popula tes the X1 2 270 Requ est with a Submitter ID unique to the MB I Request (and diffe rent from the Submit ter ID use d for an e IV Request ).
	198	N
	199	19.0
	200	FSC popula tes the X1 2 270 Requ est (NM108 ) with the Subscribe r ID Code Qualifier “MI,” in t he same wa y that thi s ID Code Qualifier is mapped for an eIV Request.
	201	N
	202	20.0
	203	If CMS is unable to locate the Patient w ho is the subject of an MBI Re quest and responds w ith an AAA *Request V alidation error of I nvalid Sub scriber ID , then FSC uses exis ting mappi ng to echo back the Patient Id entificati on (PID) a nd Payer I D (IN1) th at were se nt by Vist A.
	204	N
	205	21.0
	206	If CMS is able to lo cate the P atient who is the su bject of a n MBI Requ est but th e new Iden tification Card (wit h MBI) has not yet b een mailed to that p atient, an d CMS resp onds with the messag e New Medi care Card with MBI N ot Yet Mai led, then FSC uses e xisting ma pping to e cho back t he data th at was sen t by VistA .
	207	N
	208	20.1
	209	When CMS r eturns the message N ew Medicar e Card wit h MBI Not Yet Mailed , then FSC conveys t hat messag e to VistA (and also to ICB) f or display in the Bu ffer entry .
	210	N
	211	Dependenci es
	212	Dependenci es on HL7 Administra tion Appro val
	213	The eInsur ance Build 4 Patch i ncludes HL 7 message changes th at are pre sently in the HL7 ap proval pro cess. It i s proposed that any additional modificat ions assoc iated with the MBI R equest be included i n the curr ent approv al process (email no tice sent to HL7 Adm inistratio n 8/25/201 7, and con ditional a pproval re ceived 8/2 9/2017).
	214	HL7 approv al is requ ired for t he use of a third re peating NT E segment in the HL7 message t o convey a Type of R equest ind icator (wi th a value of “MBI” for an MBI Request).
	215	HL7 approv al may be required t o reactiva te PID seg ment (sequ ence 19) a nd populat e that seg ment with the Patien t SSN.
	216	HL7 approv al is requ ired to ch ange the T able Updat e Message (Non Payer ) to updat e the site parameter s with the value ass igned to t he Special MBI Payer .
	217	Dependenci es on FSC (repetitio n of Busin ess Rules stated abo ve)
	218	For the MB I Request X12 270 tr ansaction, FSC shall populate the Patien t Name, Pa tient DOB, and Subsc riber ID ( Patient SS N shall be sent in t he segment for Subsc riber ID, MM109).
	219	The MBI Re quest X12 270 transa ction conv eyed to CM S shall su pply the f ollowing d ata elemen ts for the transacti on (in add ition to t hose popul ated by Vi stA in the HL7 messa ge as arti culated ab ove):
	220	Station NP I (FSC sha ll populat e this fie ld).
	221	A Submitte r ID that is unique to the MBI Request a ction and is differe nt from th e Submitte r ID used for Insura nce Verifi cation req uests sent to CMS (F SC shall p opulate th is field).
	222	Subscriber ID Code Q ualifier = “MI” (FSC shall pop ulate this field in the X12 27 0 as is cu rrently do ne for the Insurance Verificat ion Reques t).
	223	CMS Not Ab le To Loca te Patient
	224	If CMS is unable to locate the Patient w ho is the subject of an MBI Re quest and responds w ith an AAA * Request Validation error of Invalid Su bscriber I D, then FS C shall ec ho back th e Patient Identifica tion (PID) and Payer ID (IN1) that were sent by Vi stA (FSC s hall use e xisting ma pping to e cho).
	225	CMS Able t o Locate P atient but Identific ation Card with MBI Has Not Ye t Been Mai led
	226	If CMS is able to lo cate the P atient who is the su bject of a n MBI Requ est but th e new Iden tification Card (wit h MBI) has not yet b een mailed to that p atient, an d CMS resp onds with a the mess age New Me dicare Car d with MBI Not Yet M ailed, the n FSC shal l to use e xisting ma pping to e cho back t he data th at was sen t by VistA .
	227	When CMS r eturns the message N ew Medicar e Card wit h MBI Not Yet Mailed , FSC shal l convey t hat messag e text to VistA (and also make it availa ble to ICB ) for disp lay in the Buffer en try.
	228	FSC Defini tion and C ommunicati on of Spec ial MBI Pa yer
	229	FSC shall define a S pecial MBI Payer and shall con trol the v alue assig ned to tha t Special Payer usin g a site p arameter.
	230	FSC shall send a Pay er Table U pdate Mess age (Payer File #365 .12) to cr eate the S pecial MBI Payer for the sites (Payer ID = VA Nati onal ID).
	231	FSC shall send a Tab le Update Message (N ot Payer) to convey the value for a new Special MB I Payer si te paramet er to the sites.
	232	Dependency of eBilli ng User St ory on US2 543 MBI Re quest
	233	eBilling U S2556 – Re move All C hecks for Valid HIC Format is dependent on the com pletion an d installa tion of th e system c hanges des cribed in this user story.
	234	Related Fu ture User Stories
	235	At least t hree futur e User Sto ries perta ining to t he functio nality spe cified or implied he re exist i n draft fo rm:
	236	US2644 – C apture REF Q4 Conten t in Medic are EIV an d MBI Resp onses
	237	The modifi cations sp ecified in this user story wou ld allow F SC to proc ess rather than dism iss the da ta conveye d in the R EF Q4 segm ent (when returned w ith a AAA) error and pass that informati on to Vist A for pers istence an d possible subsequen t processi ng.
	238	When an EI V Request is sent to CMS for a subscribe r who is d eceased, C MS may ret urn the Su bscriber I D for that person’s qualifying dependent in 2100C/ NM109 and the old ID , as submi tted, in a REF*Q4 se gment.
	239	When an EI V Request sent to CM S supplies the HICN (as Subscr iber ID) a nd an MBI has been p rovided to that subs criber, th en CMS wil l return a n MSG segm ent indica ting MBI h as been as signed/new card has been maile d along wi th the nor mal respon se (CNS wi ll not ret urn the ne w MBI in t his scenar io).
	240	US2646 – A d Hoc Medi care Benef iciary Ide ntifier (M BI) Cleanu p Extract
	241	The functi onality to be specif ied in thi s user sto ry is depe ndent on t he future existence of a CMS-s upplied cr osswalk ta ble or spr eadsheet c ontaining assigned M BI numbers . This use r story wo uld create a VistA e xtract tha t could be triggered by FSC. T his cleanu p extract would assi st with po pulating t he MBI in the Subscr iber ID fi eld for pa tients wit h known Me dicare pol icies that currently contain a HICN – so that insu rance veri fication s taff membe rs do not have to ma nually ent er the MBI in the da tabase.
	242	US[#TBD] – Automatic ally Trigg er Standar d EIV Requ est after Successful MBI and/o r Insuranc e Coverage Discovery Response
	243	The feasib ility of t his potent ial future user stor y is curre ntly being evaluated .
	244	Constraint s
	245	None ident ified.
	246	Summary of Key Dates
	247	Event
	248	Date
	249	eInsurance Build 4 I OC Test Pe riod (curr ent schedu le)
	250	January 16 to Februa ry 13, 201 8
	251	CMS Offeri ng VA Test in Live P roduction Environmen t
	252	January 29 to Februa ry 23, 201 8
	253	Overlap of Build 4 I OC and CMS Live Prod uction Tes t Availabi lity
	254	January 29 to Februa ry 13, 201 8
	255	CMS “Go Li ve” with M BI Request Transacti on being o ffered to VA
	256	March 10, 2018
	257	CMS Begins Transitio n to MBI
	258	April 1, 2 018
	259	CMS First of Several Mailings of New Car ds (Bearin g MBI) to Subscriber s
	260	April 1, 2 018
	261	CMS Will A ccept eith er HICN or MBI in In surance Ve rification Requests
	262	April 2, 2 018 to Dec ember 31, 2018
	263	CMS Conclu des Transi tion to MB I
	264	December 3 1, 2019
	265	All Medica re transac tions sent to CMS mu st include the MBI t o avoid re jection fo r the reas on Invalid Subscribe r ID
	266	January 1, 2020
	267	Risks & Be nefits
	268	No specifi c risks – other than dependenc e on the t iming of t he CMS tes t interval in order to test wi thout crea ting a sim ulated env ironment – have been identifie d.
	269	Approval S ignatures
	270
	271	Revision H istory
	272	Date
	273	Version
	274	Descriptio n
	275	Author
	276	9/14/2017
	277	0.5
	278	Updates af ter all op en issues addressed in USD&P. Added requ irement to populate Submitter ID in Requ est with f iller (MBI request) t o leverage existing real time transactio n processi ng functio nality. S ubmitted t o eInsuran ce and Dev elopment T eams for f inal revie w before s ubmitting for eBusin ess and OI T approval .
	279	R. Russell
	280	9/11/2017
	281	0.4
	282	Modificati ons after Developer Review wit h Tim Zimm er and Hen ry Normand . Removed references to non-HL 7 data ele ments. Cla rified tha t this rea l-time tra nsaction d oes not en ter the Bu ffer queue ; instead, it goes d irectly to the Trans mission Qu eue and ou t (to FSC) . Complete d articula tion of Ac ceptance C riteria (t o correspo nd to Busi ness Rules ).
	283	R. Russell
	284	9/4/2017
	285	0.3
	286	Modificati ons to ref lect the m ost curren t design d ecision fo r conveyin g informat ion in rep eating NTE segments of the HL7 message.
	287	R. Russell
	288	8/30/17
	289	0.2
	290	Incorporat ed suggest ions from first USD& P and pose d addition al questio ns in side bar commen ts.
	291	R. Russell
	292	08/28/17
	293	0.1
	294	Draft for eInsurance Team and Developer Review
	295	R. Russell