The Bright Ideas program gives CSS Staff a voice to offer suggestions of opportunity for all improvements – OSIS and other systems improvements, as well as ideas regarding budget savings and program efficiency.
If you have a great idea to improve child support performance, budget savings, or program efficiency, please email your idea to *OCSS.BrightIdeas.
There will be an article for each quarter of the year for implemented Bright Ideas. The most recent month will be listed in the article first. Each article will be published no later than the month following the quarter in which the Bright Ideas were implemented.
Bright Idea #1014-01:
We would like to thank the Center for Business Excellence and Customer Service for submitting the following Bright Idea that has been accepted, developed, and now implemented. This Bright Idea is in production as of Friday, 12/20/2019.
The situation was discussed with the Right Sizing Order workgroup. It would be nice to have a multi-mod indicator on some screen that CARE has access to which can show:
- whether a multi-mod has been completed or is pending,
- the office who is doing (or has done) the multi-mod (not always the office who owns the case), and
- the completion date of the multi-mod, if one has been done.
This could be just a line that looks like….
This would be helpful when a multi-mod is pending so CARE can see which office is working the multi-mod action, since it will often be an office other than the office that owns the case. It would also be helpful for State Office Finance so they can run reports and track which cases have had multi-mods and analyze the pay history of those cases and the impact the multi-mod may have had on collections for the particular cases.
CBECS analysts made changes to the OBLRV screen to add a field for the multi-mod indicator. The new fields include the multi-mod indicator (y/n field) and the multi-mod office code. The CIRI screen was changed to display a new multi-mod field. These new fields on OBLRV are user updated, and the CIRI transaction pulls this data over and displays it on page 3 of CIRI.
For OBLRVs that are currently open, the multi-mod indicator and multi-mod office fields will be protected, and the user will not be able to update those two fields. For new OBLRVs that are opened beginning 12/20/19, the multi-mod indicator will default to spaces (blanks), and the user will be required to enter either a Y or N. An entry of Y indicates that this FGN is part of an ongoing multi-mod action, and an entry of N will indicate that this FGN is not part of a multi-mod action.
When a Y is entered in the MULTI-MOD field on the OBLRV screen, the MULTI-MOD indicator on the CIRI screen, page 3, will display as either P or C. A display of P indicates that the modification is currently pending, and a C will indicate that the modification has been completed and closed out on the OBLRV. The date will only display if the modification has been completed and closed out on the OBLRV, and it will be the date the modification was completed.
OBLRV, as is:
OBLRV, New Display
CIRI Screen, New Display on page 3
Bright Idea #0118-06:
We would like to thank the Center for Coordinated Programs for submitting the following Bright Idea that has been accepted, developed and now implemented. This Bright Idea is in production as of Friday, 12/6/2019.
We would like the sequential SSN of 123456789 to be declined if entered on DCHG. It appears that phony SSNs have been added to DCNs so that IWOs and eIWOs would generate. Further, in 2011, the Social Security Administration changed the way they assigned SSNs. With the additional possibilities for SSN combinations being assigned, the greater the possibility of what appears to be a phony SSN to be in fact an actual SSN tied to someone that is not an obligor or obligee in the child support program.
CBECS developers have modified the DCHG transaction to prevent the entry of SSNs designated as phony/invalid. This includes 123-45-6789, as well as others identified as problematic. If a SSN is included in the OSIS table that is later determined to in fact be a valid SSN, CSS staff should email *OCSS.OSIS.Q-A with the information. Finally, since DCHG is an enterprise screen that is used by CSS, AFS and CWS, the other Divisions’ approved this project to go forward. AFS recently completed a similar project on FACS and PS2 systems that also prevents invalid SSNs from being entered onto our system.
The SSA is currently not issuing SSNs that begin with 666 or 000. Users will no longer be able to enter invalid SSNs such as these on DCHG.
Below is the logic for assigning SSN. This logic was provided by the Social Security Administration in 2011.
DCNV0014 – DCN SSN Table in OSIS:
The table below is the current list of invalid SSNs.
Client Numbering has been modified to validate SSNs against a table with SSNs that should be prevented from being entered on DCHG. Entering one of these invalid SSNs from the table above will result in an error message being displayed on DCHG – BASIC CLIENT DATA and SSN DATA sub-screens.
No Bright Ideas were implemented for November 2019.
Bright Idea #1018-03:
We would like to thank the Center for Coordinated Programs for submitting the following Bright Idea that has been accepted, developed and now implemented. This Bright Idea is in production as of Friday, 10/25/2019.
In an effort to improve the data quality on OSIS, Center for Coordinated Programs would like to start sending Status 01 AOP cases, as well as Non IV-D Pass Thru cases, to FCR for SSN verification.
Every AOP case establishes paternity for a child, and every Non IV-D Pass Thru case establishes a child support order. Under both UIFSA and the Full Faith and Credit for Child Support Orders Act, states are mandated to give full faith and credit to another state’s Paternity and Child Support Orders. However, oftentimes another state is not aware that paternity and/or a child support order has already been issued by another state. By transmitting this case data to the Federal Case Registry, it will be available to all other state IV-D programs, helping to prevent the establishment of an improper and legally void second order.
In addition, one of the big issues for AFS is that CSS processes AOPs, and builds FGNs and the DCN for the child, without a SSN. Then, at a later date, the child certifies for state services, and a second or duplicate DCN is built for the child. The DHS legacy computer systems, namely OSIS and PS2, rely on each person, including children, having unique identifiers, which are part and parcel to the DCN.
If we send these cases up to FCR, it will return the child’s SSN to CSS, and IMS will add the SSN to the DCN automatically. This will in turn lessen the chances of the child and the parents being assigned a duplicate DCN when a subsequent DHS case is created.
CBECS developers modified the program that controls the FCR transaction to allow FGNS in Status 01 to be sent up to the Federal Case Registry for SSN matching. Both historical (already built) FGNs in Status 01, and newly built FGNs, will be transmitted up to the Federal Case Registry for SSN matching. The historical load of FGNs will be sent to the Federal Case Registry in a staggered fashion, so as not to overwhelm the Federal system. Prior to the implementation of this project, only Status 01 cases with an active obligation would transmit to the Federal Case Registry, meaning that Non IV-D Pass Thru Cases already are already being transmitted to OCSE.
For a Status 01 case to be sent to the Federal Case Registry for SSN matching, the following criteria must be met:
- Case Status equals 01;
- Case Office equals ‘STO’; and
- Child Legal Status equals ‘P’ (for any of the children on the case.
No OSIS transactions were modified for this project. This will be a seamless process for district offices and the Case Initiation Center. As a final note, sending Status 01 AOP cases to the Federal Case Registry ensures that paternity information will display on the QUICK system.
Bright Idea #0518-04:
We would like to thank Lawton Child Support Office for submitting the following Bright Idea that has been accepted, developed and now implemented. This Bright Idea is in production as of today, 10/22/2019.
We need more codes to update the REV/ADJ Results: Right now we have:
We need a code for order not a year old. Right now we have to use NOCHANGE, but technically that is not correct. NOTYEAR is a code we could use.
Another problem is when the NCP/CP is out of country, we need to update that NCP/CP are out of country and we cannot update with a proper code. We could use APNOCNTRY OR CPNOCNTRY.
The OBLRV Transaction was modified to allow for four additional codes in the REV/ADJ Results field:
The REV/ADJ RESULTS: field is updated with the results of the Review and Adjust process when results have been completed. Depending on the circumstances of the case, these updates could be made before or after the hearing.
The full list of available codes, and their definitions, to enter in the REV/ADJ RESULTS: field on OBLRV are below:
We would like to thank The Child Support Quadrennial Review Subgroup, for submitting the following Bright Idea that has been accepted, developed and now implemented. This Bright Idea is in production as of today, 10/22/2019.
While completing an ad hoc report request for the Center for Operations connected to the 2020 Quadrennial Review of the Child Support Guidelines, CBECS was asked to gather information about the number of deviations from the GLS that we enter per year. We discovered that the OBLRVH transaction did not store information regarding deviations. The extract that was written showed on FGN xxxxxxxxxx that a modification occurred on the case that resulted in a decrease in the GLS. However, OBLRVH showed the Guidelines Followed? Field as blank, and the Deviation Reason field as blank. We think it would be a good idea for a worker to be able to see if deviations occurred, and why, in past review and adjustment actions without having to research what could be several pages of case log entries.
Programming was completed to the OBLRH display to include the description for the deviation and the date the review was updated.
As Is Version of OBLRH:
Bright Idea #0519-04:
We would like to thank the Center for Coordinated Programs, for submitting the following Bright Ideas that have been accepted, developed and now implemented.
Currently, the Center for Coordinated Programs is updating continuation of support cases, and will continue to do so for future cases. However, at this time there is no way to indicate on the obligation screen if there is NO continuation of support clause in the latest order that was taken. While that clause is currently in all of our orders, there are older orders that we are updating where the clause was not present, or the district office chose not to use continuation of support. While this doesn’t really effect cases where the child is set to emancipate in the next month or two, with us updating future cases of emancipation, these cases will keep coming onto our report saying they need to be updated. Therefore, we are suggesting that there be an option on continuation of support to be able to put a “Y or N” indicator, dependent on whether or not continuation of support exists on the case. And if it does not exist on the case, once we update to “Y or N” it would fall off of our report, because it has been updated accordingly.
Programming was completed to add a new data element to the OBL series of screens (OBLU/OBLC/OBLI/OBLHI) to store the Continuation of Support Indicator. If the Continuation of Support Indicator is set to “Y” on an FGN, the CS227M01 and CS227M02 reports will bypass those cases, as they will not need further review by either district office staff, or the new Centralized Services section of Coordinated Programs. For those of us who have been part of the child support program for more than ten years – the intention of this new field on OBL is much like the BVD (Balance Verify Date) push in the early 2000s. If a child support worker touches an FGN with an obligation, they should review the underlying order for continuation of support language. If the order includes the language, the Continuation of Support Indicator should be updated.
The available codes for the CONT OF SUPT Indicator on OBLU are: