DCYF SSPS Unisys System Assessment.pdf

1. SYSTEM

ASSESSMENT

DOCUMENT FOR SSPS

State of Washington - Department of Child, Youth and

Families

ABSTRACT

This document provides the current state of the system for the Social Services Payment System (SSPS) and the associated business processes that run on the Unisys Mainframe with some UI/UX information about the key windows server apps such as SSPS Portal.

Alagarsamy, Indu Version 0.9

Prepared by Unisys Page 1

SYSTEM ASSESSMENT DOCUMENT FOR SSPS

EXECUTIVE SUMMARY 3

CURRENT PAIN POINTS 3

PROJECT APPROACH 3

OBJECTIVES 3

SYSTEM OVERVIEW – AS IS ARCHITECTURE 4

UNISYS MAINFRAME 5

IBM MAINFRAME 5

WINDOWS SERVERS 5

INTEGRATIONS (BOTH INTERNAL & EXTERNAL SYSTEMS) 6

EXTERNAL SYSTEMS THAT SSPS EXCHANGES DATA AND HAVE AGREEMENTS DEALS WITH ON A DAILY BASIS: 7

SYSTEMS OWNED AND OPERATED BY THE STATE OF WASHINGTON: 7

BUSINESS PROCESSES 7

GLOSSARY OF TERMS 7

SERVICE AUTHORIZATIONS 8

PAYMENTS 9

ONE-TIME PAYMENT: 10

REPETITIVE PAYMENT: 10

INVOICED PAYMENT 11

ONE-TIME INVOICE: 12

INVOICE CREATION 12

CLAIMS PROCESSING 13

PAYMENT REPORTING 16

BATCH PROCESSES 17

SAMPLE DEPENDENCIES FOR BATCH JOBS SET IN OPCON 18

DAILY BATCH PROCESSES 19

WEEKLY BATCH PROCESSES 19

TWICE A MONTH BATCH PROCESSES 19

ONCE A MONTH BATCH PROCESSES 20

UNISYS DATABASES 20

APPLICATION DEVELOPMENT, TESTING & DEPLOYMENT PROCESS 21

BUG TRIAGE PROCESS 21

Prepared by Unisys Page 2

IDENTIFIED IMPROVEMENT 22

PILOT PROJECTS & ENHANCEMENTS 22

RECENT ENHANCEMENTS 22

ENVIRONMENTS 23

DISASTER RECOVERY 23

Prepared by Unisys Page 3

Executive Summary The intent of the SSPS Assessment project is to identify the current state architecture and business processes of the various capabilities that are involved in the payment of social services to families. The end goal is to document these in a manner that facilitates future modernization of the system.

Current Pain Points The SSPS systems business processes such as invoice generation, payments and claims are processed on the Unisys Mainframe using OS2200 COBOL. The team currently has only one COBOL programmer as the other two members have retired.

While it is easy to get people with .NET skillset, COBOL skillset is much harder to find.

This puts the system at risk. Understanding the current system as it stands with the Unisys mainframe will help with the application modernization.

The specific objectives of this assessment include:

• A one-time assessment of the architecture and code analysis

• Deliver an Application Discovery Report which typically includes o Architectural diagrams o Business rules identified and documented o Service identification o Data dictionary o Diagram of the application environment and its interaction with other applications o Message flow diagrams o Sequence diagrams o Executive summary with next steps and recommendations

The output of this initiative will serve as the foundation for the overall architecture modernization.

Project Approach To deliver the objectives mentioned above, the team has taken a two-phased approach.

The initial phase included gathering of data, mostly through interviews with senior representatives, demos as well as through the assembly of existing documentation of relevance to this initiative.

Mural, an online tool was used to collaborate between the Unisys team and the SSPS team to collaborate and understand the business processes. The second phase to document these to facilitate understanding of the system as it stands today and to help with modernization efforts for the future.

Objectives

This document provides the current state assessment of the Social Service Payment System (SSPS) for the State of Washington’s Department of Child and Youth Families

(DCYF).

Prepared by Unisys Page 4

SSPS calculates/processes payment for the delivery and/or purchase of social services for service recipients, collects required state and federal statistical and management data, and initiates the payment process for purchased services. SSPS provides the State of Washington with the ability to pay over 23,000 social service providers about $1 billion $1.7 billion annually.

The SSPS system oversees the following capabilities:

▪ Generate invoices and payments to service providers and payees.

▪ Make one-time and repetitive payments.

▪ Generate letters and documents of notification to payee.

▪ Provide metrics on and stores statistical data on SQL.

o Generate reports detailing the number of services delivered, unduplicated counts of clients, payments by service, etc.

o Create reports on a regular schedule for use at different administrative levels, i.e., at the local level (for workers/administrators), the regional level, and the statewide level.

▪ Create the social services notices from payment authorization input from case management or upstream systems (FamLink and Barcode).

System Overview – As Is Architecture

The following frameworks constitute the successful working of SSPS and processing of payments.

- Unisys Mainframe

- IBM Mainframe

- Windows Servers

- Integrations (both internal and external systems)

Prepared by Unisys Page 5

Unisys Mainframe

- Provider Database – This is where all the providers are registered with SSPS to be paid by SSPS.

- Payments, Invoice Claims, Invoice Creation, Authorizations are all COBOL code and TIP programming that facilitate the SSPS capabilities.

IBM Mainframe The main purpose of the IBM mainframe is for printing. IBM has a contract with the Postal Service and has an address scrubbing/correction capability which offers postal discounts for the State of Washington. It reduces the postage rates.

- OFM (AFRS) – Office of Financial Management. It is where all the payments are recorded for Fiscal Reporting System. It is planned to be replaced by a Workday solution called One Washington.

Windows Servers

The following are some of the common, frequently referenced applications in SSPS that reside on Windows Servers. They are mostly .NET applications.

Prepared by Unisys Page 6

- SQL Reporting – The internal SSPS website contains many reports that can be accessed by DCYF staff. They are SSRS reports. There’s also ad hoc reporting from the SQL server on an as-needed basis.

- A 19 Payment – Payment Adjustment Process. Used by customer service desk when a form comes from Child Welfare or Child Subsidy staff via Provider File email inbox. For example, a provider when claiming their invoice accidentally claims the wrong number of days, for example instead of claiming 22 days, only claims 2. They report that error to the program. Then the program initiates the adjustment.

- Verification of Employment and/or Wage – This is an application in the SSPS suite that is used by Customer Service Desk in DCYF. Using this feature, Providers can request documentation for their personal needs where they need to provide documentation. It provides details such as the nature of employment, the term, the amount, etc.

- SSPS Menu – This is an internal website. It has information on reports, taxonomy, and payments made. The website has links that provide access to view the authorizations that reside in the Unisys mainframe. It has links to calendars, cut-off dates, description of services, etc. (read only)

- Provider Portal – The providers use the Provider portal through SAW (WaTech Secure Access). It is an SSPS application where the Providers can view all of their invoices and can claim their payments online, they can view any published announcements from SSPS, and to see a copy of their remittance advice, etc.

The provider can only view their profile information and cannot update. The provider can initiate an email from the provider regarding any support they need, and the portal then redirects it to the appropriate personnel who can take care of this need. (internal and external facing.)

o Data Entry Portal – This is a subset of the Provider Portal. The Data entry portal is used by the DCYF Customer Service staff to enter claims for those invoices that are received by mail so that the claims for the provider can be processed for payments.

- WebConnectPlus – Is the interface to the Unisys Mainframe. This is not used by BARCode and FAMLink. It allows state agencies’ staff to see the authorizations and other data that is stored in the Unisys Mainframe in a user friendly manner. It allows also a certain subset of employees who have the requisite authorizations to perform Create, Update and Delete functionality on the data that is stored in the Unisys Mainframe.

Integrations (both internal & external systems) There are over 75 to 100 daily data exchanges. All of them are unique. The vast majority are of fixed length text format.

FTP as a data exchange mechanism:

From Windows to Unisys: Any important updates from the Windows Server side or the Unisys mainframe side are facilitated via the use of files on the FTP server. For example, whenever a new service code is added, removed or updated on the Windows server database, an event is raised. Certain events occur every 5 minutes, certain

Prepared by Unisys Page 7 events every 15 minutes, some once a day, etc. Service code updates are run once every day at 4:15pm. These updates are then sent through the FTP. The Unisys system will pick up these files and will perform the necessary updates so that this data is now reflected on the Unisys side as well.

When claims are received on the SSPS portal, they are FTPed to the Unisys side.

From Unisys to Windows: The Unisys mainframe system will pick up the files from the FTP server. The Unisys business process for claims will determine the status of the claim, apply the business rules, and then pushes a file back on the FTP Server. This file picks up the File watcher component which will then take appropriate action for the data to be updated on the SQL server databases on the windows server side, so that the correct status will be reflected on the portal.

From Unisys to IBM: Any files that require to be printed will be sent to the IBM Mainframe, also via the FTP. In some cases, the files are transferred directly to the IBM mainframe as well.

External Systems that SSPS exchanges data and have agreements deals with on a daily basis:

- SEIU 925 – It’s the childcare provider Union that some of the childcare providers belong to.

- MagnaCare – Is the external entity that handles enrollment into a health care plan for qualified Union providers.

Systems owned and operated by the State of Washington:

- Case Management Systems (FAM Link and BarCode). FAM Link and BarCode connects with SSPS through a Unisys Mainframe Interface

- Tax Reporting – When the payment processing is completed on the Unisys side, every business day, the data file will be dropped on the FTP Server, which will be picked up the Tax reporting application.

- Research & Development Administration

- Garnishments – app used by Fiscal to garnish checks.

Business Processes

Glossary of terms

- Client or Primary Recipient – Typically, the parent of the child who needs assistance with childcare cost or the person who signed up for it. The primary recipient is the one identified in the tax documents.

- Service Recipient – The child that’s receiving the service, such as day care.

- Service Provider – Could be a day care facility or a physician who is providing the care for the child.

Prepared by Unisys Page 8

- Client Participation or Copay – When the client is deemed eligible for some help and has funds to pay for a portion of it. This line appears on the invoice. The State will not pay this amount, the client will pay the provider.

- Union – The provider may be part of a Childcare Union. Each provider may choose whether or not to pay dues to the Union.

Service Authorizations

Prepared by Unisys Page 9

Various front-end systems, i.e., web interfaces, provide the authorization to pay service providers to SSPS. These front-end systems include FAMLINK and BARCODE. The authorizations are sent to the Unisys system via FAMLINK and BARCODE.

Each authorized service contains identifying information about the client, service provider, and service descriptors including the starting/ending date, number of hours/days, and the service code. Only 1 service code is permitted per service authorization, however up to 4 service authorization “lines” for the same client and service provider can be grouped onto a single authorization. For example, if the client and provider remain the same, the authorization can list up to 4 service codes such as direct client care (various types), and/or fees and reimbursements.

Service codes may (at the discretion of the program area to which the service belongs) be further identified by Reason Codes, Source of Funds Codes, and/or Objective Codes.

Service providers are enrolled into SSPS and must be present (enrolled) to be identified on an authorization for service. Service providers may perform union and/or non-union services. They may perform services that have differing taxonomy.

The service code determines what type of payment is to be produced, how it is to be paid, and its taxonomy.

The TIP Transaction connecting us to BARCode or FAMLink has a series of Edits in it. It looks for certain rules and data validations, and if so, the transaction is placed in the queue to be processed for the Batch Run. The batch run itself that loads the authorization has additional edits and at that point, if the transaction passes all that, then the authorization is loaded on to the Authorization database on Unisys.

Changes can be made to the authorizations after the invoice is produced and that can impact claims and payment.

Payments

Payment processing occurs every business night, i.e. Monday through Friday not including holidays and weekends.

Only data that is entered into the current month or actively viable for payments is stored on the Unisys mainframe. Data is periodically purged on the Unisys mainframe based on a scheduled job.

Every night, all the data, such as claims, new authorizations, updates, payments, invoices are moved to the SQL database. This is done by the Unisys system posting data files on the FTP site, which is picked up by FileWatcher and the SQL data on the

Prepared by Unisys Page 10

Windows servers are updated. The SQL server holds all the SSPS related data for historical purposes.

There are 4 types of payment:

One-time payment:

• Issued after the service is completed

• Can be authorized for prior months of service, back to the starting/effective date of the service code

• Non-union

• Not W2 reportable. Can be 1099 reportable or non-tax (mutually exclusive)

• No claim necessary – payment is issued once the service end date is in the past and the service authorization has been terminated (closed) with a valid termination code

• Service begins and end dates may be in different months. The month of service for recording/accounting purposes is the month of the service end date.

Repetitive payment:

• Issued prior to the month of service

• Can be authorized for up to 3 prior months of service

• Non-union

• Not W2 reportable, not 1099 reportable. Only non-tax.

• No claim necessary – payment is automatically issued monthly from the indicated starting through ending dates

Prepared by Unisys Page 11

• Payment is for a single month of service; multiple months of service can be paid on the same date

Invoiced payment

Prepared by Unisys Page 12

• Issued after the service month is completed

• Can be authorized for prior months of service, back to the starting/effective date of the service code, however only the most recent 12 months will produce an invoice. Older months of service must be paid through the SSPS payment adjustment process.

• Can be unionized service

• Can be W2 reportable or 1099 reportable or non-tax (mutually exclusive)

• Monthly, from the indicated starting through ending dates, SSPS produces an invoice that is mailed to the service provider. The invoice is also available on the SSPS Provider Portal. The provider must claim the invoice (to validate service was provided), thereby initiating the payment process.

• Payment is for a single month of service; multiple months of service can be paid on the same date; multiple adjustments to rate/units can be paid for the same service month on the same date.

One-time invoice:

• Issued after the service month is completed

• Can be authorized for prior months of service, back to the starting/effective date of the service code, however only the most recent 12 months will produce an invoice. Older months of service must be paid through the SSPS payment adjustment process.

• Can be unionized service

• Can be W2 reportable or 1099 reportable or non-tax (mutually exclusive)

• Once, based upon the service completion, SSPS produces an invoice that is mailed to the service provider. The invoice is also available on the SSPS Provider Portal. The provider must claim the invoice (to validate service was provided), thereby initiating the payment process.

• Payment is for a single month of service

Invoice Creation

Prepared by Unisys Page 13

Invoice creation is a scheduled event. Once the invoice creation job is run, it produces the invoice based on the information that is available in the Authorizations database.

For example, if the batch job is run on July 20th, 2021, to create the invoices for July services, and if the Authorization database says that the provider may provide service up to 20 days of service at the rate of $10 a day. This will be shown on the invoice. Note that the invoice is not payable for July until the month of July is completed.

During this period, the case worker may make adjustments to the authorization. For example, if the child has moved and no longer visits the provider, the caseworker may terminate or close the authorization effective for the provided date, e.g. July 1st.

Invoices generated may not reflect these changes based on when the invoice was created. Based on the invoice, the provider may still claim the 20 days, however during payment processing, the authorizations are checked and will only be paid for the authorized number of days.

The invoice will also contain the line item for Copay that the client must pay.

Claims Processing

Prepared by Unisys Page 14

Invoiced and One-time invoice services are processed for payment after the provider submits the claim for the invoice.

• The provider can claim each invoiced item only once.

• If all the services on the invoice are non-union the provider has up to a year following the creation of the invoice to initiate their claim.

• If one or more of the services on the invoice are union services the provider (as of 7/1/2021) has three months following creation of the invoice to initiate their claim.

• Claims are submitted on paper batch, through interactive voice response (IVR), or through the SSPS Provider Portal.

• If the provider is receiving electronic payment, the claim is processed on the business day the claim is received, or on the next business day if the claim is received on a non-business day

• If the provider is receiving paper check payment and the claimed invoice does not contain any union services, the claim is processed on the business day the claim is received, or on the next business day if the claim is received on a non-business day

• If the provider is receiving paper check payment and the claimed invoice contains 1 or more union services, the claim is processed according to the twice-per-month schedule for unionized service paper check payments.

• Updates to the service authorization can be made through the front-end systems after the invoice is created, reducing or disallowing the service.

o Should the update increase the amount of care for the client, a retroactive invoice will be created for

• Individual invoiced service items can be identified to process as a zero claim.

• SSPS will pay the lesser of the invoiced value, the authorized value, or the provider claim when the claim is processed for payment

• Some service codes allow ‘Client Participation’ (aka Copay). When the invoiced service authorization contains a Copay, the Copay amount is deducted from the claim.

Specific invoiced services for childcare allows claim of additional units of care during the school year to offset additional care provided during school closures and holidays.

• When the unit type of service is hourly, the claim of additional units is limited to the maximum value identified for that month of service.

• When the unit type of service is half-day, the claim of additional units is limited based on the number of regular half-day units claimed.

If after the service payment has been processed, in the event a provider makes a mistake in their claim, or if an adjustment is deemed appropriate by the program area, additional payment can be issued by the SSPS payment adjustment process.

SSPS calculates and deducts the monies listed below from the providers claimed invoice services when all the requirements for the deduction are met. Deductions are not taken from non-invoiced service payments.

Prepared by Unisys Page 15

Service payment is tax reportable

Service is unionized and CBA supports this activity

Provider Enrolled for this option

Client’s share towards service (client co-payment)

Copay can be deducted from all taxonomy types

Copay can be deducted from unionized services

Copay is the client responsibility;

Copay is paid to the Provider by the Client

OASI (FICA) W2 reportable – if IRS deems FICA is to be withheld

FICA can be deducted from union and non-union services

FICA is withheld from services deemed W2 reportable by the

IRS

Union Dues or Fair Share Fees

W2 or 1099 reportable

Yes Yes

Providers share of Health Care Premium

1099 reportable Yes Yes

Voluntary Deduction

W2 or 1099 reportable

Yes Yes

Once the provider payment has been calculated – from both the standard and from the adjustment payment processes:

1) SSPS forwards the provider information and net payment amount to AFRS (for direct deposit activity, and/or paper warrant/check activity) or to the Vendor Payment System (for paper warrant/check activity). Where the data is sent for payment issuance depends on whether it is a standard or adjustment payment and on the provider payment status.

2) SSPS forwards the paid service data, including the client, provider, service code, gross payment amount, all deductions taken, net payment amount, and taxonomy of the payment to the Tax Reporting Database (TRDb). This system performs the quarterly and annual filing requirements for the various payment and tax reporting types.

3) SSPS tabulates the union deductions and DCYF fiscal services remits payment to the union on a scheduled basis.

4) Providers enrolled for the health care benefit have part of the health care premium deducted from their unionized service payment. The DCYF portion of the health care premium and the deducted share from the providers is remitted to MagnaCare on a scheduled basis.

Prepared by Unisys Page 16

Payment Reporting

• An authorization for service must have a beginning and ending date when it is created but the ending date can be pushed into the future many times, extending the life of the service authorization.

• A provider can receive both 1099 and W2 documents for similar services.

One example is when grandma goes to her child’s home in the morning and readies the children for school (W2), then after school the grandchildren go to grandma’s house for after school care (1099).

• Client participation can reduce the DCYF gross payment amount, if participation is allowed for the service being provided, and if the client is deemed eligible (by the program area creating the service authorization) to participate in the cost of their care.

• Monthly, each union sends a file of updates to provider status for dues and voluntary deduction enrollment.

• SSPS produces a detailed Remittance Advice (RA), identifying each payment for service included on a paper warrant/EFT, and the associated deductions taken along with information mandated by the CBA (if the paid services are unionized services). The RA is also available on the SSPS Provider Portal.

• W2 reportable services are the IRS Household W2 definition. To handle the 3 FICA/FUTA designations for IRS Household employees, W2 service codes are created in sets of 3 to readily allow processing for:

o Non-relative provider/client relationship. Provider is eligible to earn FICA/FUTA credit.

o Parent/child provider/client relationship. Provider is not eligible to earn FICA/FUTA credit. An example would be grandma as the childcare provider for her grandchildren.

o Limited relative type provider/client relationship. Provider is eligible to earn FICA credit but not eligible for FUTA.

o The IRS Household FICA threshold can change each tax year. If the W2 wages for the tax year are not equal or greater than the threshold then all FICA withheld must be refunded to the service provider.

• W2 reporting is done for each client/provider relationship.

• 1099 reporting is done for each provider.

• After a service invoice is created, the case worker can modify the service authorization.

o If the case worker reduces the hours and/or rate, when the invoice is claimed SSPS will pay the lesser of the claim, invoice, or authorization.

o If the case worker increases the hours and/or rate, the next invoicing process will produce an invoice for the increased amount.

Prepared by Unisys Page 17

Batch Processes DSHS Staging team is responsible for the scheduling and monitoring of the SSPS Unisys jobs. This team creates a document (contains the monthly detailed list of each SSPS Unisys job schedule run date and time) before the processing month.

The main batch processes are for authorization, payment, invoice creation and invoice claims. Payments are made on every business day. Invoice claims are received every business day. Invoices are created on a schedule. Authorizations are received every business day.

The batch processes are stand alone jobs. Some batch processes depend on other batch jobs to complete successfully before they can execute. These dependencies are set and run via the OpCon Enterprise Manager, a scheduler tool for batch jobs from Unisys.

Prepared by Unisys Page 18

Sample Dependencies for Batch Jobs set in OpCon

Prepared by Unisys Page 19

Daily batch processes The following batch processes run on every working day of the week (i.e. Monday through Friday)

Run-Id Batch Process Time

SAFRJ0 DAILY TAB OF INPUT TO AFRS 9:00

SAFRJ2 AFRS DAILY INTERFACE (CACSH300) 9:00

SITSB1 SSPS - EXTRACT DAILY SSPS RECORD 18:00

SOPS41 ACCUMULATE IVR INVOICES - Transfers the invoice claims prep by IVR to Unisys 17:25

SOPS45 TRANSFER PROVIDER PAPERLESS OPTIONS 17:00

SOPS53 ACCUMULATE IVR INVOICES – Back to IVR, the ack 17:30

SOPS54 SSPS DAILY PROCESS 18:30

SOPS59 TRANSFER EFT CONTROL FILE TO SFT FOR FSA (JIM SCHEIBE). 18:30

SSPS33 IPBP LOAD SERVER DATA TO MAINFRAME 16:30

SSPS34 IPBP SEND SSPS99 DATA TO SERVER 18:30

SSPS66 ACCUMULATE IVR INVOICES – bundles the invoices with the rest of the claims 17:30

SSPS77 SSPS DATA EXTRACTION FOR WEB 18:30

SSPS78 DAILY AUTH INDEX SDF FILE EXTRACT & REBUILD 18:30

SSPS90 CREATE DAILY FILES FOR PROGRAM AREAS 18:30

SSPSDA AUTHORIZATIONS, SOCIAL SERVICE NOTICES 18:30

SSPSDB BILLING AND ONE-TIME PAYMENT PROCESSING 18:30

SSPSDI INVOICE CLAIMS, INVOICE PAYMENTS AND DEDUCTIONS PROCESSING 18:30

SSPSDM DAILY MAINTENANCE - ORG TABLE, SVC TABLE, UNION DEDUCTIONS 18:30

SSPSDP COMBINE PAYMENT TYPES/SEND WARRANTS AND EFT REQUESTS TO VPS/AFRS 18:30

SSPSDW EFT/WARRANT WRAP-BACK PROCESSING 18:30

SVPSD1 (J.T.) VENDOR PAYMENT SYSTEM DAILY 18:30

Weekly Batch Processes The following batch processes run every Friday at 02:00

SSPSMM WEEKLY BACKUP OF SSPS Y2K LIBRARY FILES ON DEV 2:00

Twice a month Batch Processes The following batch processes run twice every month (on the 5th and 20th based on August schedule). The days that these processes run on can be different every month.

SSPSBU SOCIAL SERVICE PAYMENT SYSTEM - FILE BACKUP 17:00

The following batch processes run twice every month (on the 6th and 21st based on August schedule) The days that these processes run on can be different every month.

Prepared by Unisys Page 20

SSPS24 INVOICING SUPPORT PROCESS 20:00

SSPS24A SSPS24 2ND ONE FOR THE MONTH INVOICING SUPPORT PROCESS 00:15

Once a month Batch Processes The following batch processes run once a month based on the August Schedule. The days that these processes run on can be different every month.

Run-Id Batch Process Time

SOPS51 SSPS INVOICING PROCESS 20:00 (1st Friday)

SSPS19 SOCIAL SERVICE PAYMENT SYSTEM - TABLE FILES BACKUP 13:00 (1st Friday)

SSPS40 SSPS PAYMENT HISTORY 00:30 (1st Saturday)

SSPS42 (J.T.) SSPS PAYMENT REPORTS & FILES (FEEDS ACES G5910300) 00:30 (1st Saturday)

SSPS43 SSPS PAYMENT REPORTS & FILES 00:30 (1st Saturday)

SSPS54 (J.T.) MONTHLY PAYMENT HISTORY SUBSET & 1099 FILE 03:35 (1st Saturday)

SSPSXR SSPS CROSS REFERENCE REPORTS 06:00 (1st Sunday)

SSPS22 SSPS DATABASE PURGE 20:00 (2nd Tuesday)

SPS14E SSPS INVOICING PROCESS 20:00 (3rd Thursday)

SPS24E SSPS INVOICING PROCESS 20:00 (3rd Thursday)

SPS14A SSPS14 2ND RUN OF MONTH SSPS INVOICING PROCESS 00:15 (3rd Saturday)

SOPS52 TRANSFER INVOICES TO PROVIDER PORTAL 20:00 (3rd Thursday)

SSPS13 SSPS REPETITIVE PAYMENTS 18:30 (3rd Friday)

SVPSM1 MONTHLY AUDITORS 18:30 (Aug 30th – 2 days before end of month?)

SSPS35 MODIFICATION HISTORY 17:00 (Aug 31st – last working day of month?)

SSPSE1 (J.T.) MONTHLY FILE EXTRACT AND ERROR REPORT 00:05 (1st day of month)

SSPSE2 MONTHEND ADMINISTRATIVE REPORTS AND FILE BACKUPS 01:00 (1st day of month)

SSPSR1 (J.T.) SSPS REPORT FILE EXTRACT 03:35 (1st day of month)

Unisys Databases Unisys has one database with areas for Authorization, Payments, Providers, Worker and numerous flat files that accompany the database.

Prepared by Unisys Page 21

Application Development, Testing & Deployment Process

DCYF has a standard defined for the Software Development Life Cycle – Team Foundation Software (TFS) for Source Control, Release pipelines automated using Octopus, Redgate for database side automation, varying degrees of automation testing in the various applications, iterative development (releases every week or every month), AxoSoft for incident tracking. DevOps is being managed by just one associate;

vacancies are yet to be filled. But SSPS hasn’t yet adopted this standard completely.

Some SSPS applications use TFS Release Management for server applications and eventually will use Octopus. 97% of testing and deployment are manual. Unisys and IBM use other tools for release management.

Child Welfare and Child Subsidy decides business process changes. SSPS team (not end user) raises incidents in AxoSoft. Design must be documented, reviewed, and approved. Code review is done, even on one-time requests. Test cases are documented manually. Most testing is done by the development team. Only a presentation to business, for review, if there are any UI changes. DSHS does the move to Production for non-mainframe applications as well as IBM and Unisys. Agile methodology is followed when possible. There is no designated Scrum Master.

There are no SLA type agreements with business. Currently there is a backlog on enhancements but not on bugs. The system has been very stable, and bugs are rare.

Bug Triage Process

Bugs are uncommon in SSPS. Any type of bug especially in the world of Payments is a priority that needs to be addressed. The current backlog is on enhancements.

Prepared by Unisys Page 22

Identified Improvement

If the move is made to AxoSoft, then Customer Service can open the tickets automatically improving the process and the time on Glenda and team.

Pilot Projects & Enhancements Sometimes there can be study that gets limited funding for a period of time for which a change is made in the system and then it can get turned off after the period is complete.

There are also new enhancements due to the recent COVID pandemic, where the government has issued funds to Child Care centers, incentivizing them to stay open.

Recent Enhancements The new collective bargaining began on Jul 1, 2021. As part of the collective bargaining agreement, the client co-payment is being waived for July, August and September.

Client Copayment is a service line, an authorized service, that comes to SSPS via BARCODE. The process is not changed. They still send the client co-payment that ranges anywhere from $15 to $800. The change is on the Unisys Invoice creation part, where it adds a line called, “Copay Waived” to the invoice. This is also made visible on the SSPS portal when the invoices are claimed. The Co-Pay waived change was done in the past as well.

Another change that was implemented recently was to change the number of units for childcare. When children are in school, they have reduced need for childcare. However, during the summer months, the number of units are increased to accommodate childcare. A global update (called a Transaction Generator) was done, changing all of the half day services authorized at 30 half days to be 46 half days instead for July and August, to increase the allowable number of units of care. In September, this is set back to the original value of 30.

Prepared by Unisys Page 23

Environments Unisys mainframe has two environments, Production and Dev. They are 100% separate. When doing any development or test, a current copy of everything is loaded over in the dev environment.

Every night, when the batch processes are completed, and the Unisys databases are updated, a “Backup” process is done. This is a snapshot of how things look like when everything completes successfully. As more and more processes are done and if any of them fail, it is rolled back to the last TipOut. When there is a need to test or do any development, a “TipIn” is done. A valid copy of the production database is Tipped in to the development environment.

Disaster Recovery

Currently, there is no disaster recovery. The mechanisms are currently based on backup and restore of data.