1. CCSAS and the IVA Interface Readout on CCSAS/SAWS IVA/IVD Interface “Summits” CSDA Training Conference – 10/4/06

2. 2 Welcome Today’s Speakers Brooks Measures, San Luis Obispo LCSA Michele Murphy, DCSS Stephen Baltikauskas, CCSAS BP Implementation Dan Green, CCSAS BP Implementation Additional “core working group” staff ISAWS/CASES County IVA and IVD: El Dorado, Humboldt, Shasta, and Sutter CalWIN/CASES County IVA and IVD: Alameda, Sacramento, San Luis Obispo, Sonoma and Yolo ISAWS, CalWIN and CASES system consortia CDSS, DCSS, OSI, CSDA, CWDA CCSAS BP Application Development and Implementation teams Extended “Summit” community All 51 ISAWS/CASES and CalWIN/CASES counties

3. 3 Today’s Objectives Recap the “Summit Process” Highlight “key feedback” System differences Business practice impacts Outline next steps

4. 4 Summit Process Recap CSE v2.1 Development Requirements Working sessions to develop CSE v2.1 Use Cases started in early summer 2004 Use Cases approved by DCSS and LCSA representatives in spring 2005 Design and Development Design first memorialized in August 2005 –Interface Design Document (IDD) is the ‘contract’ across DCSS, CDSS, CCSAS/CSE, ISAWS, CalWIN and CIV First wave of technical development completed in late 2005 Testing File exchange testing with IVA consortia –CIV: Oct 05 – Feb 06, re-initiated tentative Jan 07 –ISAWS: Jan 06 – Jul 06 –CalWIN: Mar 06 – Aug 06 Formal CCSAS System Test (ST): Dec 05 – Sep 06 Formal System Verification Test (SVT) for IVA components –Sep 06 – Oct 06 –Using converted IVD data

5. 5 Summit Process Recap CSE v2.1 Implementation Plan (Mar 2006) 6-Step “Summit Process” defined CSE v2.1 pilots prioritized –ARS/CalWIN starts Nov 06 with Orange and San Diego –CASES/CIV tentatively starts Jan ‘07 (CR-2-290) –ARS/LEADER/LA Foster Care tentatively starts Dec07 (CR-2-291) Step 1 (Apr-May) Develop CSE v2.1 “to be” data flows –Target “pre-training” documentation Steps 2 and 3 (Jun-Aug) Identify “key” system differences and business practice impacts unique to each IVA/IVD interface –CSE v2.1 “financials” were not analyzed in Step 2 and 3 due to the wide variety of scenarios – financials will be addressed through BP CM business process models and dedicated CCSAS training

6. 6 Summit Process Recap CSE v2.1 Implementation Step 4 (Sep) Schedule “mini-summits” with county IVA and IVD ‘management-level’ staff together at the same session Step 5 (Now forward) Conduct coordinated outreach Define and execute a “game plan” for dealing with feedback Conduct “summit processes” for remaining legacy exchanges Step 6 (Now forward) BP Local Interface (LI) discipline activities “kickoff” in CSE v2.1 pilot

7. 7 Feedback Mini agenda

8. 8 Feedback Context

9. 9 4 Key Drivers Shared program incentives CDSS and DCSS mission statement have significant parallels Significant, personal incentives at worker levels “Their case, our case = state case” Automated systems in consistent transition CCSAS/CSE brings “statewide-ness” and SAWS systems continue to evolve Data relationships are critical CCSAS/SAWS will operate exchanges from 3 IVD systems to 5 IVA/IVE systems CCSAS/SAWS will not be conducting a separate ‘data reconciliation’ project prior to 2009 –CSE v2.1 has been built to at least partially address potential data discrepancies

10. 10 Summit Objectives Requests made of attendees Absorb “preview” information –“How might my job impacted?” –“What will it take for me and the county to get there?” Understand “asks” –IVA = Asked to help craft IVA business practice revisions without significant system changes and without global policy directives –IVD = support unique pre-cutover prep and post- cutover processing around the IVA/IVD interface Take information back to your county –Begin to think about and share previews and asks for possible changes to business practices

11. 11 Feedback Overarching Concepts

12. 12 CASE Records Feedback = IVA and IVD “think about” cases differently IVD must move to the federal IVD case construct of 1 CP, 1 NCP and DPs in common CSE v2.1 will not use the CASE-level record

13. 13 MEMB Records Feedback = almost all key differences can be summed up in member-based processing Persons “stand alone” and are secondarily associated with a case in either program CSE v2.1 “derives” what it needs from member records

14. 14 Feedback IVA Triggers

15. 15 IVA Triggers Feedback = impact of the member transition will vary widely from county-to-county ISAWS/CASES counties – CSE v2.1 will “feel” like a whole new interface CalWIN/CASES counties - inbound IVA data will “touch” more cases and participants Feedback = impact of the financial transition will not be as significant IVA system “sends” are similar CSE v2.1 and CASES financials are very different, but interface-specific UAP updates are similar

16. 16 Feedback CSE Inbound Edits

17. 17 CSE Inbound Edits Feedback = CASES generally “whacks” more records CASES processing across ISAWS and CalWIN varies widely, but “working the reports” is significant IVD effort CSE v2.1 allows all aid codes (no county-defined table) Feedback = CSE v2.1 storage of records is key Transaction Detail page = shows all MEMB and ASST records “as received” from IVA Referral Overview page = shows all “referrals” processed by CSE “as derived” from IVA records

18. 18 Feedback CSE Person Matching

19. 19 “As Is” Considerations Feedback = CCSAS/SAWS ‘enterprise’ must beware the risk of “blending” matching structures IVA Person Number is key to most matching, and is known to be non-unique 3 IVD and 5 IVA/IVE systems all have varying identifiers and matching protocols

20. 20 “To Be” Handshake

21. 21 “As Is” to the “To Be” Transition will require effort County IVA/IVD focus = Name, DOB and SSN –Rules make “cleanup” process challenging MEMB records will come in over time –‘Unmatched’ participants may be higher at the beginning, then reduce as the handshake is made –Focusing on ‘little r’ referrals will be key

22. 22 Feedback CSE “Referrals”

23. 23 Key Concepts CSE Service Requests… Are the outcome of “referral analysis” – all referrals comes as CSE Service Requests Are work requests used for walk-ins, CSENet interstate referrals and IVA referrals Will go to users via a configurable task Will populate data from the inbound record and all possible matches in a “driver”

24. 24 CSE “To Be”

25. 25 CW2.1(Q) Feedback Feedback: role identification and acronyms are critical CP = should refer only to the IVD-side Custodial Party –Physical person who provides custodial responsibilities for the dependent according to child support PA/HOH/Recipient/Payee = should refer to the IVA- side Primary Applicant –PA = primary applicant? –HOH = head of household? –Recipient = person receiving benefits? –Payee = person receiving benefits?

26. 26 CW2.1(Q) Feedback Feedback = the IVD CP is NOT necessarily the IVA PA/HOH/Recipient/Payee IVA users and systems must identify the physical person who would have filled out Section 1: About Yourself of the CW2.1(Q) –If the biological or adoptive parent is in the home (either Mom or Dad), then that physical person is the IVD CP –If Foster Care, then the County Agency will be the IVD CP IVA-side ‘care and control’ is NOT necessarily the IVD CP IVA-side PA/HOH/Recipient/Payee is NOT necessarily the IVD CP

27. 27 CW2.1(Q) Feedback Feedback: Outcome of “summit process” must include specific training points ISAWS –AEDEP1 Caretaker Relative field should have the IVA Person Number of the physical person who would be the IVD CP CalWIN –APs = Name field on the Collect Absent Parent window should have the name of the physical person who would have provided information about the AP –DPs = Relationship field on the Collect Household Relationship window should have the ID# for the person who would be the IVD-side CP »If FC, then = blank »If KinGAP, then = PA/HOH ID# »If biological parent is in the home (either Mom or Dad), then = biological parent in the home ID# »If adoptive parent is in the home, then = adoptive parent in the home ID# »“Last line” default = PA/HOH

28. 28 Feedback CSE Updates

29. 29 Demographics Feedback = APs are people too…and IVA users should treat AP updates with the same care as CP and DP updates IVA ‘core identifiers’ for APs (Name, DOB and SSN) should receive same research as CPs and DPs IVA AP employment updates will insert into the CSE Employer table and will mark employment active Feedback = Clarification of non-cooperation and good cause lifecycle is key

30. 30 Aid History Feedback – CASES and CSE v2.1 processing are substantially different in all aspects CSE accepts all aid codes sent, including back/current/future dates for aid history updates –CSE only “uses” referable/recoupable codes from the DCSS Master List of aid codes in financial processes CSE processes aid code updates as a “new referral” if the “right now” aid history shows ineligible –IVA users should, to the extent feasible, reduce or eliminate the practice of “break in aid” conditions that are not likely to be permanent.

31. 31 Assistance Updates CSE v2.1 UAP updates do not differ substantially CSE v2.1 will update the UAP at the aid code level CSE v2.1 will process ASST records “as received” and the UAP will always reflect the most recent updates –CSE v2.1 does not “hold” or “net” ASST updates More CSE financial information coming… CCSAS CSE training has developed a substantial curriculum for CSE financials BP Change Management will address CSE financial business models with each LCSA

32. 32 Feedback Updates from CSE

33. 33 Next Steps

34. 34 Feedback Short-term Feedback – Summit feedback must be translated into practical outcomes and coordinated communication Provide detail information about CRs-in-progress –CR-2-280 – Reports for ISAWS IVA Partners –CR-2-287 – CCSAS Edit Error Reporting Translate ‘asks’ into a CDSS All-County Letter and IVA system documentation Demonstrate consistent activity and communication in other areas of feedback Continue Step 5 outreach Initiate Step 6 in pilot LCSAs Verify completion of CSE v2.1 System Verification Test

35. 35 Feedback Each LCSA Roadmap Baseline Plan for each LCSA Hold a “kickoff” with LCSA and County IVA Conduct an “As Is/To Be” analysis to identify “key” county- specific business practice impacts Execute a ~2 week validation cycle with converted LCSA data and “live” IVA data Planning Steps Remaining Confirm resources with ISAWS and CalWIN Communicate the high-level schedule Initiate county-specific discussions along each LCSA Roadmap

36. 36 DONE! Thank you for your time and attention