# Presentation: 261091

## Analyze and Clean Up Your State Client File Using SSA Matching Systems

- Nelson Wetmore
- NC DHHS / DIRM

## North Carolina Overview

- 11th largest state – about 8.4 million people
- 1.6 million unique individuals tracked on state public assistance systems
- State supervised, county administered structure
- 100 counties, about 4,000 income maintenance workers, about 10,000 workers with access to state systems.
- Fun fact: it would take about 12 hours to drive 550 miles across the state from Murphy in the west to Manteo in the east.

## NC DHHS Organization

- Social Services, Medical Assistance and Information Resource Management are separate divisions in the same overall department, reporting to one Secretary
- Most state offices are centralized in Raleigh
- Less than a dozen state employees support and operate the PARIS and SSA interface systems.

## NC PARIS Background

- One of the early participants in PARIS...because it was easy to do for our state (we have a central client file)
- We are passive users of the interstate and VA match, not using PARIS federal match
- Usually 3rd or 4th largest file submitted to PARIS
- About 5,000 possible matches identified in our last PARIS match
- We filter our results to include active people only
- We estimate half of our interstate match hits are due to data errors somewhere

## NC Data Integrity

- About 60,000 people at any one time with no known SSN – mostly newborns
- About 93,000 people at any one time with SSN verification problem waiting to be fixed (SSN, name, or birth date error)
- County workers responsible for resolving problems – some do, some don’t.

## What’s the need for PARIS?

- “If only there was a nationwide database of people that we could use to verify that our clients are not double-dipping somewhere else!”

## But isn’t there a federal system?

- SSA State Data Exchange (SDX) has everyone who gets supplemental security insurance (SSI disability payments)
- SSA Beneficiary Earnings and Data Exchange (BENDEX) has everyone who gets social security payments
- SSA State Verification and Exchange System (SVES) has access to every SSN
- Various Federal regulations require states to use these systems

## So why not use their data?

- You can usually only see data from your own state
- SSA systems have too many fields but lack some important fields, follow confusing rules, use different timeframes, are not always synchronized, and have been historically misunderstood by some states that use them
- And.................

- The SSA
- Makes Mistakes!

## Our Goal This Afternoon:

- Identify ways we can use SSA systems to clean up our data and resolve a few interstate conflicts before we send our files off to PARIS

## SDX out of state

- NC is a 1634 state, with about 200,000 SSI recipients
- NC SSI people automatically qualify for Medicaid
- SDX data feeds directly into our client systems to automatically create cases – the SSA is in charge of about 1 in 8 NC clients
- County workers cannot change SDX cases!

## Out of State Error

- SSA rules say when a person moves, you will get one final “05” transaction...but it doesn’t always happen.
- You can also get an “06” or other out of sequence transaction after the “05” transaction, which in NC causes the person to reactivate.
- The result is an active case for someone no longer in your state, with no further updates from the SSA!
- We get about 5-10 a month like this – 500 a year

## From the SDX manual:

- “When an SSI/State Supplementation applicant/recipient moves from one State to another, two transactions are generated:
- 	*	a record with a Transaction Code of "03" or "04" goes to the new State of residence, and
- 	*	a record with a Transaction Code of "05" goes to the old State.
- Data reported to the old State will be in a Transaction Code of "05" record, which is the last record the old State will receive concerning the recipient. That record contains all data as they were previously reported to the State.”

## SDX Fall Through the Crack Error

- Not the same as the SDX out of state error
- For unknown reasons, the SSA just stops sending SDX data for a client.  It may be due to a death, an out of state move, or a keypunch error – no one knows.
- Not as many of these – maybe 50-100 a year

## SSN changed error

- This happens when the SSA changes the SSN assigned to a person, either due to data entry error or a valid need to change
- You stop getting updates on the old, and start getting updates on the new
- The result can be a lingering active case for the old SSN if your systems don’t recognize the activity as a SSN change
- We get about 200 a year like this

## SDX solution

- Do an SVES refresh on stale records every month!
- “Look at my SDX master file and find every person who is in a current payment status but hasn’t been updated in more than 120 days.  Create an SVES SDX refresh request for them”

## SDX Refresh follow-up

- SVES response the next day, SDX response in two days.
- If the SDX response is OK, then no further action needed – you have fresh data.
- If the SDX response is not OK, look for a record ID code of “X”, a transaction code of “80, and an “E” in column 982.  This means the SSA thinks the person now belongs to another state, and you can’t see them any longer!

## Your Action

- Treat an SDX X80 transaction with an E in column 982 the same as you would an 05 out of state transaction – they are not your client any longer.

## Bendex

- Beneficiary Earnings and Data Exchange system
- Has demographic info, social security payment info, HI and SMI insurance info
- Data is organized by claim id
- Major upgrade in February 2007, now a daily response system

## Bendex Residence

- Bendex works by states asking for info on their clients, and the SSA keeps track of which state to send the info to
- Bendex has a residence state and county that is separate from the agency code they use to distribute records to states

## Bendex Solution #1

- “Look at my Bendex master file and find every person with a resident state code that isn’t mine.  Investigate these people, and get the SSA to fix it if it is wrong.”

## Bendex Communication Code

- Every Bendex response comes with a communication code that is described in the Bendex manual – there are a lot of them.
- The SSA keeps track of who wants to know about each person.  If one state ‘steals’ a person away from another, the first state is sent a CF “last one” conflict record.

## From the Bendex manual:

-     This is the last BENDEX record you will receive for this individual. BENDEX exchange was transferred to agency XXX (XXX = state code from BENDATA file). If there is a conflict, case should be reviewed for investigation of possible fraud. (Remark sent to the old data exchange agency on the MBR) This code is generated where:
- A direct input and a buy-in accretion are received from different States. The buy-in State will receive the CF record.
- Two direct input accretions are received from different States. The nonresident State will receive the CF record. Residency is determined by positions 232-236 below.
- A single direct input accretion is received from another State.     BENDEX exchange was transferred to agency XXX. (Positions 232-236 were not checked in this situation.) Conflict may be the result of address change, split household or possible fraud.”

## Bendex Solution #2

- “Look at my Bendex master file and find every person who has a CF communication code.  Investigate to see if they are an out of state person on our files”

## Bendex Insurance Payer

- Every Bendex response comes with optional HI and SMI insurance fields, which also have optional premium payer fields.
- The premium payer can be a state or some other third party, like maybe another federal agency
- If you have person in your state with another state paying their premium, you should investigate why they are doing that!

## Bendex Solution #3

- “Look at my Bendex master file and find every person who has an HI or SMI premium payer code that isn’t my state code. Investigate to see if they are an out of state person on our files”

## Bendex Transposed SSNs

- Unlike SVES or SDX, a Bendex request will result in a response if the SSN is not right, as long as the name and date of birth are close.
- This means Bendex responses can alert you to SSNs on your system that are 1 or 2 positions off what they should be – giving you another way to find data that needs to be fixed so it will verify

## Bendex Solution #4

- “Look at my Bendex response file and find every response where the SSN that comes back does not agree with the one I sent, and the difference is 1 or 2 positions don’t match but 7 do. Investigate to see if our worker transposed the SSN”

## NC PARIS submission file

- 000000000SUMRELL     WAYNE    20040724M200611NC
- 001028677SMITH           JOHN       20040810S200611NC
- 001030681ROBERTS     DAVID     20051007M200611NC
- 001031800WILLIAMS     ROBERT  20051114S200611NC
- 001032781WOODS        JOE          20060101F200611NC

- What’s wrong with this file?

## Verify your data with SVES

*Nag! Nag! Nag!*
- PARIS does not *require* verified SSNs, but you should consider only sending verified SSNs.
- SSA website for released SSN prefixes:
- http://www.ssa.gov/employer/ssnvhighgroup.htm
- SSNs never start with 000, 666, or higher than 772999999

## Non-verified SSN example

-            FIRST           LAST
- STATE              NAME           NAME             SSN              SEX  BIRTHDATE  PGM
- ---------------------------------------------------------------------------------------------------------------
- NC                ROGER            JONES           115-09-7703V   M     12/06/2001  FS
- NY                SARAH            SMITH             115-09-7703*   F      12/07/2001  AAF
- NY                SARAH            SMITH             115-09-7703*   F      12/07/2001  FS
- NY                SARAH            SMITH             115-09-7703*   F      12/07/2001  MED
- --------------------------------------------------------------------------------------------------------------

## Missing Verification Example

-            FIRST           LAST
- STATE              NAME           NAME             SSN              SEX  BIRTHDATE  PGM
- ---------------------------------------------------------------------------------------------------------------
- NC                   MARY              ALLEN          333-22-1305V   F      05/13/1990  FS
- FL                    MARY             ALLEN           333-22-1305     F      05/13/1990  AAF
- FL                    MARY             ALLEN           333-22-1305     F      05/13/1990  FS
- --------------------------------------------------------------------------------------------------------------

## Summary: a clean file is a happy file!

- “Look at my SDX master file and find every person who is in a current payment status but hasn’t been updated in more than 120 days.  Create an SVES SDX refresh request for them”
- Treat an SDX X80 transaction with an E in column 982 the same as you would an 05 out of state transaction – they are not your client any longer.
- “Look at my Bendex master file and find every person with a resident state code that isn’t mine.  Investigate these people, and get the SSA to fix it if it is wrong.”
- “Look at my Bendex master file and find every person who has a CF communication code.  Investigate to see if they are an out of state person on our files”
- “Look at my Bendex master file and find every person who has an HI or SMI premium payer code that isn’t my state code. Investigate to see if they are an out of state person on our files”
- “Look at my Bendex response file and find every response where the SSN that comes back does not agree with the one I sent, and the difference is 1 or 2 positions don’t match but 7 do. Investigate to see if our worker transposed the SSN”
- Verify your client files with SVES, and get someone to fix the discrepancies
- Spend 5 minutes to browse through your PARIS file before releasing it, looking for SSNs or other things that might be way out of whack.