Identification Number:
GN 02602 TN 62
Intended Audience:See Transmittal Sheet
Originating Office:ORDP OISP
Title:Continuing Eligibility
Type:POMS Transmittals
Program:Title II (RSI),Title XVI (SSI)
Link To Reference:
 

PROGRAM OPERATIONS MANUAL SYSTEM
Part GN – General
Chapter 026 – Posteligibility
Subchapter 02 – Continuing Eligibility
Transmittal No. 62, 07/25/2019

Audience

PSC: BA, CA, CCRE, CS, DS, ICDS, IES, ILPDS, IPDS, ISRA, PETE, RECONR, SCPS, TSA, TST;
OCO-OEIO: BIES, BTE, CR, CTE, FCR, FDE, PETL, RECONR;
OCO-ODO: BTE, CCE, CR, CST, CTE, CTE TE, DSE, PETE, PETL, RCOVTA, RECOVR;
FO/TSC: CS, CS TII, CSR, CTE, FR, OA, OS, RR, TA, TSC-CSR;

Originating Component

OISP

Effective Date

Upon Receipt

Background

This is a Quick Action Transmittal. These revisions do not change or introduce new policy or procedure.

Summary of Changes

GN 02602.050 Reports of Death

Subsection B - Adjusted language to clarify the items in the provided list are examples. Added policy references. Added note for clarification, stating: "These reports are often referred to as "proven" death information".

Subsection C - Adjusted language to clarify the items in the provided list are examples. Removed State Bureau of Vital Statistics from list of examples. Added note for clarification, stating: "These reports are often referred to as "verified" death information".

Subsection D - Adjusted language to clarify the items in the provided list are examples. Added note for clarification, stating: "These reports are often referred to as "alleged" death".

Subsection G - Updated references:

  • GN 02602.065 Type of Death Alerts

  • GN 02602.070 Procedure for Resolving Death Alerts

  • RS 00210.005 Evidence Requirements for the Lump-Sum Death Payment (LSDP)

  • RS 00207.004 Widow(er)'s Benefits - Table of Proofs and Development - Policy

GN 02602.065 Types of Death Alerts and Exceptions

Title - Changed to "Types of Death Alerts" since exceptions are no longer applicable and are obsolete.

Subsection A - Removed "exceptions" since they are no longer applicable and are obsolete .

Subsection B - Changed sentence from: "There are three types of third-party alerts", to: "These are the types of third-party alerts". Removed T16 DIPS alert types since they are no longer applicable and are obsolete .

Subsection C - Removed section "What is an exception?" since exceptions are no longer applicable and are obsolete .

Subsection D - Removed section "Types of exceptions" since exceptions are no longer applicable and are obsolete .

Subsection E - Updated references:

GN 02602.070 Procedure for Resolving Death Alerts

 

GN 02602.070 Procedure for Resolving Death Alerts and Exceptions

Title - Changed to "Procedure for Resolving Death Alerts" since exceptions are no longer applicable and are obsolete.

Subsection A - Removed "exceptions" since they are no longer applicable and are obsolete .

Subsection A2 - Removed section "Unknown exception" since exceptions are no longer applicable and are obsolete.

Subsection D - Updated references:

GN 02602.050 Reports of Death

A. Policy for accepting reports of death

SSA receives and processes reports of death from a variety of sources. Death information is used to terminate benefits of Title II beneficiaries and Title XVI recipients. Reports of death also alert us to pursue claims for benefits to surviving spouses and children. As part of the Death Processing Redesign effort, the Numident will become the agency’s official source of death information. As such, all death reports must be recorded on the Numident using the Death Information Processing System (DIPS). This system then automatically sends death information to the agency’s payment systems.

B. Proof of death

To terminate benefits, documented proof of death is not required; however, if the death of an individual results in the potential entitlement of another person, you must obtain a proof of death document that meets the requirements for payment of survivor benefits. The following documents are examples of acceptable proofs of death:

  • a death certificate (D/C),

  • an SSA-704 (Certification of Contents of Records) in lieu of a D/C,

  • an SSA-721, or

  • a Numident record that shows death data based on an Electronic Death Registration (EDR) report.

For additional information on deaths that may affect entitlement to benefits, see GN 00304.000, RS 00210.005, and RS 00207.004.

NOTE: These reports are often referred to as "proven" death information.

C. First-party reports of death

A first-party death report is received from an acceptable reporter. The following are examples of first-party reporters:

  • representative payee or agent (e.g., physician, lawyer, accountant),

  • competent adult entitled on the same SSN, or

  • relative, e.g., a spouse, parent, or sibling, etc.

Do not verify first-party reports of death from acceptable reporters.

NOTE: These reports are often referred to as "verified" death information.

D. Third-party reports of death

A third-party death report is an event reported by someone other than a first party. The following are examples of third-party reporters:

  • Centers for Medicare & Medicaid Services (CMS),

  • State social service office (e.g., Welfare Office),

  • Department of Veterans Affairs (VA), or

  • a friend or neighbor

NOTE: These reports are often referred to as "alleged" death information.

Verification of third-party reports

We must verify reports of death for beneficiaries that are received from third- party sources before we can terminate benefits. For third-party reports of death that automatically generate a “Third-Party Verification” alert on the Death Alerts Tracking System (DATS), follow the steps in GN 02602.070, Procedure for Resolving Death Alerts & Exceptions to verify the death report.

Third-party reports of death that do not automatically generate an alert in DATS (such as a phone call from a friend or neighbor) must also be verified by following the steps in GN 02602.070C, Procedure for Resolving Death Alerts & Exceptions.

You may also receive requests from the Teleservice Center (TSC) via an Modernized Development Worksheet (MDW) to verify a report of death on a beneficiary received over the phone from a third party. Since third-party reports of death for beneficiaries need to be verified before posting the death, follow the steps in GN 02602.070C, Procedure for Resolving Death Alerts & Exceptions to verify the death and process the TSC request.

E. Reports of death for non-beneficiaries

You should accept and post death reports for non-beneficiaries without further verification. However, the reporter must supply the following pertinent information to establish his or her identity, as well as to establish the identity of the deceased before you can accept the report of death:

  • First and last name of the non-beneficiary,

  • Date of birth of the non-beneficiary

  • SSN of the non-beneficiary,

  • Date of death of the non-beneficiary,

  • the name, address, and phone number of the person making the report, and

  • the relationship of the reporter to the non-beneficiary.

Verify the non-beneficiary’s information in the Death Information Processing System (DIPS) before adding the death information into DIPS (See GN 02602.051, Processing Reports of Death Using the Death Information Processing System (DIPS) and the DIPS User Guide for instructions on using DIPS). Record the reporter’s information in EVID.

NOTE: If the reporter refuses to identify himself or herself, do not accept the report of death. If the reporter is unable to provide the required identifying information for the deceased, advise the reporter that if he or she can obtain the necessary information, we can accept the report of death. If the reporter does not provide, or is unable to provide the pertinent information, do not process the report.

F. Additional Actions

The following are possible additional actions you may need to take once you receive and process a report of death.

  • Advise the reporter not to cash the check for the month of death (and any later months) and to return the check. if appropriate. If the reporter cashed the check for the month of death (and any later months), do not ask for a refund. Advise the reporter that the Treasury Department (TD) may request the funds back from the bank that cashed the check for a period of up to 12 months from the month that SSA learns of the death. Do not accept a repayment agreement.

  • If the reporter asks if he or she should make a refund, or how to make a refund, advise the person that he or she must first inform the financial institution (FI) of the death as soon as possible. We will then debit any incorrect payments from the person’s account. The FI will return the payment to us as soon as they are informed of the death or upon the request of the TD via the Notice of Reclamation.

  • If the case meets the overpayment criteria in GN 02201.001, advise the reporter that there is an overpayment and that we will notify the overpaid person.

  • Initiate “Living in Same Household” (LISH) and “Child in Care” development if appropriate. For more information LISH, see RS 00210.035B and for conditions for Entitlement and Definitions, see RS 01310.001.

    Note: Remember to develop leads for surviving (spouse and children) claims.

  • Check for multiple or dual entitlement. For procedure on checking for multiple, dual, or other entitlement, see GN 02602.065D.

  • Check eRPS to see if the decedent was a representative payee for another beneficiary.

G. References

GN 00304.000 Proof of Death

GN 02201.001 What is a Title II Overpayment

GN 02602.051 Processing Reports of Death Using the Death Information Processing System (DIPS)

GN 02602.065 Types of Death Alerts

GN 02602.070 Procedure for Resolving Death Alerts

RS 00210.035 LSDP for a Surviving Spouse Living in the Same Household (LISH)

RS 01310.001 Conditions for Entitlement and Definitions

RS 00210.005 Evidence Requirements for the Lump-Sum Death Payment (LSDP)

RS 00207.004 Widow(er)'s Benefits - Table of Proofs and Development - Policy

DIPS User Guide

GN 02602.065 Types of Death Alerts

This section defines the alerts you may encounter when processing death information. For instructions on how to resolve death alerts, see GN 02602.070.

A. What is an alert?

A death alert is a notification to the field that action is required to resolve an issue related to a death report. Alerts are generated to the field office (FO), and displayed on the Death Alerts Tracking System (DATS). DATS is an Intranet application that provides daily listings of death alerts at the FO, district, or area level.

B. Types of alerts

1. Third-party verification

Third-party verification alerts are death reports for beneficiaries from third parties that we must verify by following the steps in GN 02602.050 before we can post death to the Numident. We consider a death report from a third party as verified when a first-party reporter agrees the person died. These are the types of third-party alerts:

  1. a. 

    CMS – Third-party death verification required for beneficiary (DM subcode CM)

    This is a report from the Centers for Medicare & Medicaid Services.

  2. b. 

    VA – Third-party death verification required for beneficiary (DM subcode VA)

    This is a report from the Department of Veterans Affairs.

  3. c. 

    State Agency – Third-party death verification required for beneficiary (DM subcode BX)

    This is a report from a state agency, other than the State Bureau of Vital Statistics.

2. Name does not match

You will receive this alert if the name entered through Title 2, does not match the Numident name:

T2 – DIPS Input Required – Additional Development For Identity Mismatch (DM subcode DN).

3. DIPS not used

If we add death to Title 2 first, instead of through DIPS, the following alert will be generated:

T2 – DIPS Input Required (DM subcode DX).

Resolve this alert by making a DIPS transaction; no further development is necessary.

REMINDER: To avoid getting this type of alert, always enter death information into DIPS first, before entering death into the T2 payment systems.

4. Numident Death Alerts

When death data is present on the Numident, but there is no corresponding death data on the payment records for an individual on the Master Beneficiary Record (MBR) and Supplemental Security Record (SSR), the system produces a Numident Death Alert. We perform this match for the following reasons:

  • Reduce improper payments (if death does not make it to the payment records, the person remains in current pay, receiving benefits, until these alerts are resolved);

  • Remove personally identifiable information from the Death Master File if an individual is alive;

  • Allow proper posting of earnings;

  • Identify cases where death information is posted to the Numident, but not all active payment records have been terminated for the deceased; and

  • Identify cases where benefits or payments were reinstated following an erroneous death termination action, but death information was not removed from the Numident.

For instructions to process these alerts see GN 02602.070 (for ETC: D cases, see RM 10220.415).

C. References

GN 02602.070 Procedure for Resolving Death Alerts

A. Alerts that do not require additional development or verification

Not all alerts require additional development or verification. If you make entries into the Social Security Administration (SSA) systems out of sequence, an alert may result. Because the records for the individual are incomplete, you must take action to enter death information to all records. We define alerts in GN 02602.065.

DIPS not used

This alert shows on the Death Alerts Tracking System (DATS) because you entered a death transaction through the payment record(s) instead of through the Death Information Processing System (DIPS). No further development of the death report is required to resolve this alert. However, you must enter the death information into DIPS and wait for the death report to process overnight to resolve this alert. For information about processing death reports through DIPS, see GN 02602.051.

B. Alerts requiring verification

The following alert types, defined in subsection GN 02602.065B, require verification to resolve the alert and remove it from DATS:

  1. 1. 

    Third-party verification;

  2. 2. 

    Name does not match; and

  3. 3. 

    Numident Death Alerts (for ETC: D cases, see RM 10220.415).

The steps to verify these alerts are listed in GN 02602.070C in this section.

C. Steps to verify alerts

Step

Action

1

Check the Numident, MBR, SSR, HIQR, PHUS, THIS, PCACS, Paperless or Paperless Read Only Query System (PPL ROQS) query as well as EVID, and MDW to see if we received pending death development.

If we received pending death development, go to step 7.

If we did not receive pending death development, go to step 2.

2

Check the Numident, MBR, SSR, HIQR, PHUS, THIS, PCACS, Paperless or Paperless Read Only Query System (PPL ROQS) query as well as EVID, and MDW to see if this is SSA’s first indication of death.

If this alert is SSA’s first indication of death, go to step 3.

If this alert is not SSA’s first indication of death, go to step 5.

3

Attempt to contact the alleged deceased, or family of the deceased, by phone. The individual must be able to provide status of the decedent.

If you were able to make contact, go to step 7.

If you were not able to make contact, go to step 4.

4

Send a come-in letter, SSA-L-2708, SSA-L-2751, or SSA-L-2752 ; record your development and set a diary date to follow-up on the alert in 45 days. When your diary elapses, go to step 7.

5

Determine if we reinstated payments due to an incorrect death, but the death information was not removed from the Numident.

  • If we reinstated benefits, but death was not removed from the Numident, do no further development and go to step 11.

  • If benefits were not reinstated and death is not on the Numident, go to step 6.

  • If benefits were not reinstated and death is on the Numident but not on the payment records, and the report of death on the Numident does not show EDR: Y, go to step 3.

  • If benefits were not reinstated and death is on the Numident but not on the payment records, and the Numident death record shows EDR: Y, utilize the date of death associated with the EDR: Y to terminate benefits on the payment records using POS.

6

If we did not reinstate benefits, there is no death on the Numident, and no development is pending, return to step 3.

You must determine the status of the individual (alive or deceased) and ensure it is correct on the Numident.

7

Have you determined the person is deceased?

If yes, go to step 11.

If no, go to step 8.

8

Is the date of the come-in letter greater than 45 days?

If yes, go to step 10.

If no, go to step 9.

9

Set a diary date to follow-up on the come-in letter, and other pending development, from the date of the come-in letter plus 45 days. If we did not send a come-in letter, send a come-in letter and diary for 45 days, as explained in step 4.

10

Consider the person deceased using the date on the alert if we did not receive a response to the come-in letter after 45 days. Go to step 11.

11

Add, correct, or remove the death information on the Numident in accordance with Processing Reports of Death Using DIPS, in GN 02602.051. For erroneous deaths and the exceptions to the face-to-face interview, see GN 02602.055.

D. References


GN 02602 TN 62 - Continuing Eligibility - 7/25/2019