This subchapter provides information on how the T2Redesign (T2R) notice process works as well as a listing of the language and captions used by the T2R notice process. The paragraphs and captions listed in NL 00730.000 are located in the Language Development Facility (LDF) and are included for informational purposes only.

The T2Redesign notice process was completely redesigned with Release 3 in June 1999. Unlike the object driven systems (MADCAP, etc.) that generate paragraphs that are unique to a transaction, the T2R notices reflect changes that are a result of all of the data being processed.

The T2R notice process compares the old Master Beneficiary Record (MBR) data to the updated MBR data that reflects all of the processed data. It contains logic that will produce the required notice language based on changed MBR data and combinations of changed MBR data. Because of this type of processing, the T2R notices will not always include language that explains the source of the data.

EXAMPLE: Input to the T2Redesign system is a zip code maintenance change. As this input goes through each T2R business function, the T2R RATES process determines that a monthly benefit amount (MBA) was calculated incorrectly and changes the MBA. This results in the T2R summary process performing paid vs. payable function and establishing an overpayment that can be recovered from the beneficiary’s monthly benefits.

RESULT: The T2R notice will advise the beneficiary that their MBA was changed because we determined that it was incorrect for the specific date(s). It will not mention specifically that the MBA correction is the result of the zip code maintenance change. The T2R notice will also include all appropriate overpayment due process language and appeal rights.

Since the T2Redesign notice process is a completely automated notice process with no “notice input screen“, it is important to understand how the T2R notice is built.

1. 1. 

   The T2R notice process starts with the first beneficiary on the post MBR and:

   • •

     Decides if a notice should or should not be built.

   • •

     Determines what goes in the notice. When working on the notice for a Beneficiary Identification Code (BIC), the T2R notice process compares the pre and post MBR for that BIC.

     NOTE: The T2R notice process can view every BIC’s data on the post MBR, on the pre MBR the T2R notice process can only view one BIC at a time.

2. 2. 

   Auxiliary BIC - Based on this design, for most situations, the T2R notice process can determine why the changes have taken place. However, when an auxiliary BIC’s benefits are resumed the T2R notice process can only determine for the auxiliary BICs that follow the BIC being resumed that the reason for the MBA change is because we started paying another person. The T2R notice process cannot determine for any auxiliary BIC listed on the MBR before the BIC being resumed that the reason for the MBA change is because we started paying another person. This will result in the T2R notice process generating UTI RIN049 on the notice for the auxiliary BIC listed on the MBR before the BIC resumed.

3. 3. 

   T2R3 Sequencing Design - Beginning in T2R3, the sequencing design of the T2R UTIs is changing to be able to logically explain the changes on the updated MBR as a result of T2Redesign processing. Using the Business Function Start Date (BFSD), the T2R notice process compares the pre and post MBR HIST Data to determine if there is a MBA change and/or a HRFST change. When the T2R notice process determines that there are MBA and/or HRFST changes prior to the last occurrence in HIST Data (referred to as embedded periods of HIST Data), the T2R UTIs generated will be sequenced chronologically based on the changes in HIST Data.

   EXAMPLE: The pre MBR shows C1 with a HRFST = A18TRM for May 2004. It has now been determined based on the updated MBR changes that C1 is entitled to student benefits effective May 2004 (BCLM Data posted with BCLM-CEC = S). In addition, the updated MBR also shows that the MBA for C1 for January 2004 was corrected.

   RESULT: The T2R notice process will generate RIN049 with an effective of January 2004 to explain the incorrect MBA. This UTI is sequenced as the first introductory UTI.

   UTI ENT047 (student award paragraph) is generated next with an effective date of May 2004 because payments based on being a student begin with this date. UTI ENT049 would be generated after ENT047 to explain how long benefits can be paid as a student.

   There are some UTIs that are sequenced differently depending on whether the UTI is used for an embedded MBA change period or an ongoing MBA change period.

4. 4. 

   Embedded MBA Change - UTI WCP015 is used to explain a WC/PDB Triennial Redetermination. When WCP015 is generated to coincide with an embedded WC/PDB MBA change, WCP015 is sequenced before the specific WC/PDB MBA change paragraph.

5. 5. 

   Ongoing MBA Change - When WCP015 is generated to coincide with an ongoing WC/PDB MBA change, WCP015 is sequenced after the specific WC/PDB MBA change paragraph. The sequencing of UTIs for an ongoing MBA and/or HRFST change without any embedded MBA and/or HRFST changes are based on the last occurrence of HIST Data. All other UTIS that do not relate to MBA and/or HRFST changes will be sequence appropriately.

   This change in the way the Agency creates notices was implemented with Title II Redesign Release 1 in June 1999 with the retirement of TPAO, JURIS, MAP and PEPPER. With the retirement of SALT, TASTE, the manual portion of WC/PDB and the non-disability portions of TATTER (DEATH and Full Retirement Age), the T2R notice process will be greatly expanded.