TO: All IV-D Agents and Staff KASES Network Memo # 64

COMMONWEALTH OF KENTUCKY Cabinet for Health and Family Services Department for Community Based Services

TO: All IV-D Agents and Staff KASES Network Memo # 64 Division of Child Support

FROM: Mark S. Cornett Acting Director

DATE: January 24, 2008

SUBJECT: Date of Death Match with Vital Statistics

A new interface has been developed between Vital Statistics and DCBS. The Kentucky Automated Management Eligibility System (KAMES) interface has already been implemented, and the Office of Information Technology intends to begin the Vital Statistics interface with the Kentucky Automated Support Enforcement System (KASES) on February 6, 2008.

KASES will run a batch process each night to match participants on KASES with the Vital Statistics file containing the entire death population in Kentucky. The criteria for the match and the update of the Date of Death field on KASES will occur on all case types, including interstate, and all participant types.

A new field, Verification Source Code, will be placed on the Participant Data screens to identify the source of the date of death information. The screens are the Update Child Participant Data, ASEPT1; the Update Participant Data, ASEC2A and the Inquire Participant Data, ASEQ2A. Attachments A, B, and C provide screen samples. The values for this field are as follows:

Blank- A date of death does not exist on KASES CW- The Caseworker verified and entered the date of death VS- The data was received through the Vital Statistics Interface IT- Information Technology override

Before the implementation of the interface, the Verification Source Code for all records with an existing Date of Death field will be set to CW. The Verification Source Code will remain CW, unless the code is updated by the Vital Statistics match or OIT overrides the code. After the implementation of the Interface, the system will have the following edits that limit the update of the Verification Source Code:

The CW Code is accepted only if the Verification Source Code is Blank or CW. The VS Code can override a blank, CW or VS code. The IT Code can override a blank, CW or VS codes. KASES Network Memo No. 64 January 24, 2008 Page 2

The caseworker will receive an error message when attempting to change the Date of Death field with a Verification Source Code of VS or IT.

The Match Process

The participant’s Social Security Number, the first five characters of the last name and the first character of the first name must all match on the Vital Statistics file and on KASES in order to be considered as a matched participant. The name match only looks at the primary name for the participant. When the interface results in a match, the following actions will occur:

1. If the Date of Death field is blank on KASES, the Vital Statistics’ date of death will be loaded to KASES with the Verification Source Code of VS.

2. If the Date of Death field in KASES is already populated, but it does not match the Vital Statistics’ date of death, the Date of Death field and the Verification Source Code on KASES are not updated, and the participant is listed on a new RDS report, “Weekly Date of Death Error Report.”

3. If the Date of Death field on KASES matches Vital Statistics’ date of death, the Verification Source Code is changed from CW (caseworker) to VS.

4. If the Date of Death field on KASES was previously received through the interface and has a Verification Source Code of VS, and a different date of death is received in the Vital Statistics interface, the new date of death will be updated in KASES and the Verification Source Code will remain VS.

5. The Verification Source Code of IT is not updated in the batch process.

A new screen “Participant Death Maintenance,” (ASESMI), off of the Supervisor Functions Menu (Option 7 on the Main Menu) will allow the override of the VS Verification Source Code. Only staff with the Office of Information Technology (OIT) can access this screen. When a worker verifies that the date of death provided through the Vital Statistics Interface is incorrect, the worker must send an email request to CHFS KASES Help Desk to override Vital Statistics’ date of death. OIT will complete the “Participant Death Maintenance” screen, which includes changing the Verification Source Code from VS to IT. By changing the Verification Source Code from VS to IT, participants with mismatching dates of death between the two systems will not continue to appear on the “Weekly Date of Death Error Report.” Caseworkers should enter events with verifying information prior to requesting an override.

Weekly Date of Death Error Report, HRCS 1612

A new RDS report has been created to list cases that fail the following match criteria: KASES Network Memo No. 64 January 24, 2008 Page 3

1. The Social Security Numbers on KASES and the Vital Statistics file match, but the names (first five characters of the last name and first character of the first name) do not match, and

2. The Social Security Numbers and names on KASES and the Vital Statistics file match, but the date of death on KASES does not match the date of death on the Vital Statistics file. If the dates of death on KASES and the Vital Statistics file do not match, information is not updated on KASES.

The “Weekly Date of Death Error Report” is sorted by county, responsible worker and MPI number. The report contains the participant’s Social Security Number, the participant’s last name, first name and date of death on KASES, and the participant’s last name, first name and date of death on the Vital Statistics file. The participant data will be listed under the county and responsible worker for the open case with the lowest IVD number. The report is generated weekly and the participant will continue to appear on the report until the mismatch data is corrected or the Verification Source Code is set to IT. Four (4) versions of the report will be retained on RDS.

When the participant appears on the “Weekly Date of Death Error Report,” the worker must determine if the data is correct on KASES or if Vital Statistics’ data is correct. If Vital Statistics’ data is correct, the mismatching data in KASES is updated to match the data from Vital Statistics. The data will match in the next nightly interface, and the Verification Source Code for the date of death will be set to VS. The system will then generate the events, worklists, and case updates discussed under the “Case Updates and Worker Notifications” section of this memorandum.

If the worker determines that the data is correct or should remain as it is on KASES, an Email message is sent to the CHFS KASES Help Desk to enter the Verification Source Code as IT. If the IT Verification Source Code is not entered, the participant will continue to appear on the “Weekly Date of Death Error Report.” In the email, include an explanation of why the information will not be changed and the IT override is necessary. Examples of why the data will not be changed are the participant may be using multiple Social Security Numbers, the name on the Vital Statistics file may be an alias name in KASES, a last name suffix (Jr. or II) is on one file but not the other, the spelling is different, the Social Security Number on the Vital Statistics file is incorrect, etc. Vital Statistics obtains the death information from the funeral homes and the information is entered as it is received. In testing the interface, KASES staff found that an incorrect Social Security Number on the Vital Statistics file resulted from the funeral home inadvertently entering the surviving spouse’s Social Security Number for the deceased. In this instance, the email would explain that the worker verified that the Social Security Number belongs to the deceased person’s spouse.

Case Updates and Worker Notifications:

When the match occurs, the date of death will be entered in the participant data record for all participant types and in all case types. For cases in the Archived Status (ARCV) and dangling KASES Network Memo No. 64 January 24, 2008 Page 4 participants, only the Participant Data screens will be updated with the date of death and the Verification Source Code. Case updates and events will occur when the participant is the active CP, NCP or child in an open or closed case. Worklists will be generated only when the participant is the active CP, NCP or child in an open case. Additional case actions will automatically occur based on the participant type, case status and other conditions in the case. Attachment D provides the following information in a chart format.

In addition to the update of the participant date of death and Verification Source Code, the following actions will occur on cases in an Open, Pending (PNDA or PNDF) or Incomplete (INCO) case status:

Participant Type NCP  In non-order cases, automated case closure will be initiated with case Closure Reason Code CDIE.  In order cases, a “C” hold will be placed at the NCP Participant Account level.  In both non-order cases and order cases, the responsible worker for each open case will receive a worklist, and an event will be created in the Participant Event History. The event/worklist Code and description is as follows:

PDEC Participant MPI# XXXXXXX died on MM/DD/CCYY

Participant Type Client  In non-order cases, automated case closure will be initiated with Case Closure Reason Code CNOA.  In order cases, a “C” hold will be placed at the Case Account level.  In both non-order and order cases, the responsible worker for each open case will receive a worklist and an event will be created in the Participant Event History. The event/worklist code and description is as follows:

Participant Type Child- Only Active Child in the Case  In non-order cases, automated case closure will be initiated with Case Closure Reason Code CNOA.  In order cases, a “C” hold will be placed at the case account level. If arrears are owed, the IVD Type will change to ARRP when only KTAP and FC arrears are owed and ARRN when other arrears types, with or without KTAP and FC, are owed. If no arrears are owed, automatic case closure will initiate with Case Closure Reason Code CNOA.  In both non-order and order cases, the responsible worker for each open case will receive a worklist and an event will be created in the Participant Event History. The event/worklist code and description is as follows:

PDEC Participant MPI# XXXXXXX died on MM/DD/CCYY KASES Network Memo No. 64 January 24, 2008 Page 5

Participant Type Child- Other Active Children  In non-order cases, no action will occur.  In order cases with a pro-ratable obligation, a “C” hold will be placed at the Case Account level.  In both non-order and order cases, the responsible worker for each open case will receive a worklist and an event will be created in the Participant Event History. The event and worklist code and description is as follows:

 In order cases with a pro-ratable order type, a second case event and worklist are created. The event and worklist code and description is as follows:

PDCR Participant Died in Pro-ratable Order"

The following actions will occur on cases in the Closed (CLSD) status:  For all participant types, the participant record will be updated with the date of death and the Verification Source Code.  For all participant types, a participant event will be created. The event code and description is as follows:

 If the active NCP deceased, the Case Closure Reason Code is changed to CDIE.

On-line Access to the Vital Statistics Death Records

A new menu option will be added to the Inquiry Functions Menu, Screen ASEMQA, to provide inquiry in the Vital Statistics file being used by KASES for the match. The new menu option is Option 22 - Vital Statistics Death Records. The Social Security Number must be used for this search. New screen, “Vital Statistics Death Information” (ASEKDT), will display the participant name, sex, date of birth, date of death for the Social Security Number entered, and the Volume Number, Volume Year and Certificate Number where the death is recorded. Attachment E provides a screen sample of how to access the “Vital Statistics Death Records from the “Inquiry Functions Menu”.

Attachments

Attachment A Attachment B Attachment C Attachment D Attachment E