Menu Help & How To Video Simulation Game Document & Resources Training Link Tag Search clock thumbs-up angle-up

Implemented Bright Ideas for Last Quarter (October – December) 2019

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.

December 2019

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.

Current Situation:

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:

  1. whether a multi-mod has been completed or is pending,
  2. the office who is doing (or has done) the multi-mod (not always the office who owns the case), and
  3. 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.

Modified Transactions:

OBLRV, as is:

Image of the prior version of the OBLRV screen.

OBLRV, New Display

Image of the modified OBLRV screen with MULTI-MOD and OFC fields highlighted.

CIRI Screen, New Display on page 3

Image of the modified CIRI screen with MULTI-MOD, OFC, and COMPLETE fields highlighted.


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.

Current Situation:

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.

Modified Transactions: 


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.

Image of the Invalid SSN List for OSIS which shows a list of SSN’s that are invalid.

Below is the logic for assigning SSN.  This logic was provided by the Social Security Administration in 2011.

Image of the DCNSSN Element list from OSIS showing the values for the field and what that value indicates.

DCNV0014 – DCN SSN Table in OSIS:

The table below is the current list of invalid SSNs.

Image of the Invalid SSN List for OSIS which shows a list of SSN’s that are invalid.

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.

Image of the DCHG screen, Client Data Update menu showing where to go for SSN information. A person may select Basic Client Data or SSN Data.

November 2019

No Bright Ideas were implemented for November 2019.

October 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.

Current Situation:

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.


Current Situation:

We need more codes to update the REV/ADJ Results:  Right now we have:

Image of list of prior codes for REV/ADJ Results field.

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:

Image of list of codes to be added for REV/ADJ Results field.


Modified Transactions:

OBLRV Transaction:

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.

Image of the modified OBLRV screen with REV/ADJ RESULTS field highlighted.


The full list of available codes, and their definitions, to enter in the REV/ADJ RESULTS: field on OBLRV are below:

Image of list of all codes (prior and added) for REV/ADJ Results field.


Bright Idea#0319-05:

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.

Current Situation:

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.

Modified Transactions:

As Is Version of OBLRH:

Image of the prior version of the OBLRH screen.



Image of the new version of the OBLRH screen with Description field added.


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.

Current Situation:

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.


Modified Transactions:

OBLU Transaction:

Image of the modified OBLU screen showing where the MORE JDG field was moved, and where the fields CONT OF SUPT (Y/N), AMT, and START DT are now located on the screen.


The available codes for the CONT OF SUPT Indicator on OBLU are:

Image of the available codes for the Cont of Supt field on OBLU – Y or N.