The Windowing Issue

Whether or not an entity uses windowing does not absolve the entity from addressing the above two issues first. IT IS IMPORTANT FOR ALL ENTITIES TO UNDERSTAND HOW AND WHEN THEIR TRADING PARTNERS ARE MODIFYING DATA EXCHANGES DUE TO Y2K ACTIVITY. IT DOESN'T MATTER WHETHER WINDOWING IS USED, THE DATA EXCHANGES MUST STILL BE AGREED UPON. The best way to reinforce this point is to state that most of HCFA's shared systems, FISS, EDS, GTE, CWF, and UHC are using windowing internally in their processes, even though HCFA is requiring 8 digit dates in exchanges. The Medicare contractors decided this was the fastest and least expensive way to achieve Y2K compliance on time. And, they were right. But, a key problem with windowing is the need to establish a "pivot year", which is used in examining a 2 digit year to determine what the 4 digit year should be. For example, I believe CWF is using a pivot year of 17. So, when CWF encounters a 2 digit year of 16 (or anything less than or equal to17), it assumes the 4 digit year would be 2016. If it encounters 18 (or anything greater than 17), it assumes the year is 1918.

For data exchange purposes, when a 2 digit year is passed, it is important for the data exchangers to know what pivot year will be used to process that 2 digit year. Using the example above, if entity A generated a 2 digit year of 16, but was using a pivot year of 15, they may mean for the 2 digit year to represent 1916, not 2016. Yet, if the receiving system used the pivot year of 17, they would process the date as 2016. So, it's important for data exchangers who are passing 2 digit years, or 6 digit dates as cited at the Los Angeles conference, to agree on their data exchange and understand each other's windowing rules.

For exchanges of 8 digit dates, knowing the windowing rules is not as crucial. There is no assumption to be made when a 4 digit year is exchanged. The 4 digit year is what it represents. WE required Medicare systems to react to the 4 digit year as submitted. So, even though several of our standard shared systems and the CWF are using windowing internally and are using different pivot years, they are still required to exchange 8 digit dates to simplify the data exchange. There is no need for FISS to know what CWF's pivot year is, because when it sends a year of 2018, it should be processed as 2018 by CWF, regardless of CWF's pivot year. Instead, it is up to CWF to understand the 4 digit year and bridge it accordingly into its windowing processes.

The bottom line is that windowing is probably the fastest solution on Y2K, especially for those who started late. Also, windowing was adopted early on by EDS as a corporate approach to Y2K. So, states that started late or states that use EDS as a fiscal agent are likely to use windowing. It is important, however, especially where the data exchanges remained in 6 digit format for such entities to clearly and effectively communicate data exchange rules to their partners and to gain buy-in for those rules.

Addendum: Presumably, for cases in which the submitter is telling the provider to "do nothing", the submitter is giving the provider software to react to the "00" when the remit advice and other transactions arrive back at the provider site. In cases where the billing agent does not write the software for the provider shop or does not provide a terminal-to-data base relationship, it is unclear how the provider will be able to cope with data with the year 2000 and beyond. The provider has "side-stepped" the requirement, but has not enabled herself to handle year 2000 and beyond transactions. The "00" still compares low (early) to "99" whereas the correct year "2000" compares high (later) to "1999". Unfortunately, the programs will probably not "blow up" in this case, but run on, with unpredictable results.

http://www.hcfa.gov/y2k/ttesting/e2e-joe.ht

-- Martin Thompson (mthom1927@aol.com), January 17, 2000

Answers

Martin This was a *very good* post. It is unfortunate that the site now gives me a "404" (up through ttesting is ok). Note that this has always been my greatest concern (yes, above that of embedded systems): corrupt data. And different windowing protocols, especially in the context of electronic data interchange (EDI) such as that happening in the HCFA scenario above have been the highest risk areas.

-- Bud Hamilton (budham@hotmail.com), January 18, 2000.

Martin, the problem with the above url (which ends in ht) is that it needs an "m" tacked on after the "ht". Try the following url, it worked for me: http://www.hcfa.gov/y2k/ttesting/e2e-joe.htm

Best Regards, Jim Dowd

-- Jim Dowd (jimdowd@oneimage.com), January 18, 2000.

Thanks Jim

Obviously missed that when I pasted it. After a while the old eyes get a little glazed.

Martin

-- Martin Thompson (mthom1927@aol.com), January 18, 2000.