Automated Solutions

Page updated on November 4, 2024

‍

Developmental Disabilities Administration (DDA) - Moving from a manual review of applications and creating a solution that automates the process for thousands of applications.

The Developmental Disabilities Administration is transforming lives by providing support and fostering partnerships that empower people to live the lives they want. The 2023-2025 DDA Strategic Plan describes our work and expected outcomes to accomplish the mission. People with developmental disabilities and their families are valued citizens of the state of Washington. The Developmental Disabilities Administration strives to develop and implement public policies that will promote individual worth, self-respect, and dignity such that each individual is valued as a contributing member of the community.

‍

Vision

Automating the extraction of information from printed, digital, image, and other file types to reduce worker touch points resulting in quicker decisions and improved accuracy.

‍

Key Challenge

If a child is eligible for Early Support for Infants & Toddlers (ESIT), then they meet eligibility for DDA. Thousands of applications (paper, scanned, or typed-in Word documents) must be manually reviewed and entered by DDA staff. Applications are largely manual, i.e. paper documents submitted by Family Resource Centers (FRCs), hospitals, and Department of Children, Youth & Families (DCYF). Possible solutions include populating DD eligibility in CARE (for worker final determination) through process automation, Datafeed from ESIT, and/or Automated CSAs. The Disability Determination is completed in the case management / client admin system CARE manually by the DDA worker.

‍

Existing Fraud Prevention Products & Processes

The agency's fraud prevention unit has criminal actor fact patterns identified through the use of data analytics they are currently following. These fact patterns continue to evolve and change over time. The relative fraud rate remains low in perspective to public benefit caseload data.

‍

Primary Customer/Users

• DDA I&E staff – less than 100 agents or fulfillers

• Technical staff

• Hospitals

• Family Resource Centers (FRCs)

• The Department of Children, Youth & Families (DCYF)

‍

Existing Eligibility Criteria

Currently, the rule allows DDA to make children aged 0-3 eligible under any condition in the WAC chapter 388-823. We use the DDA application to see what condition was selected and can make determinations about additional records we might seek for longer eligibility that won’t expire at age 4.

‍

Existing Processes

• The DDA Application consists of an application form (DSHS 14-151), a consent form (DSHS 14-012), Privacy Practices form (DSHS 03-387) and, when applicable, documents authorizing authority to sign, such as guardianship. For applicants aged 0-3, packets may also include the ESIT form (DSHS 15-435).  

• The DSHS Form 15-435 is always submitted by FRCs and other hospitals in English. DDA does not translate any part of the ESIT process, but they do need to translate their notice to the individual and their representative of their decisions if they require translation. DDA also needs to translate any correspondence to the individual for follow-up contact for incomplete documents.

• DDA Application form (DSHS 14-151), a consent form (DSHS 14-012), and Privacy Practices form (DSHS 03-387 may be submitted in any language.

• Currently ESIT forms are sent to DDA, DDA does not have to seek to retrieve them. If DDA was to implement a data feed, perhaps DDA would need an MOU or DSA outlining data elements, but FRCs are contracted through the counties, and DDA can share this data.

• The current process for applicants is: DDA will refer the individual to FRC who will then complete the ESIT form or the individual will be served through a hospital, DCYF, or FRC and they will submit the ESIT form and sometimes an application on behalf of an individual.

• There is frequently incomplete or missing information on the form 15-435, like date or no box checked. When submitted in conjunction with an application, the application itself may be missing documentation or signature. DDA staff will review and follow up with FRC or other source directly if information is missing or inaccurate.

• Workers must manually create a CARE record for new clients, follow up on any missing or inaccurate information, and send notices of decisions, including but not limited to approval and expiration Planned Action Notices.
• Currently, status updates to applicants happen manually by the case worker through a CARE generated Planned Action Notice. Status updates to case workers happen manually by receiving documents on paper and email formats from FRCs, hospitals, and DCYF. We are hoping that the solution may address this business problem.
• CARE permissions are managed through Azure AD groups. Hospitals, FRCs, and DCYF currently communicate with us through paper and email processes, and we are hoping that the solution may address this business problem.

‍

Potential Benefits

• Automation

• Automate eligibility for children connected to ESIT (Early Support for Infants & Toddlers)

• Provide efficiencies for applicants and staff

• Equity for applicants

• Fewer touch points for staff

• Reduced cycle time to process and reach decision

• Less paper

• Improved accuracy-quality control with data entry, fewer mistakes

• Automated notification to client and DDA eligibility worker of decision  

‍

Security Requirements

• Meets Washington state security standards and is compliant with requirements for PHI (protected health information)

• A Security Design Review will be initiated before acceptance

‍

Required Technology (Compatibility)

• Real-time connection with multiple internal and external data sources. Data sources include ESIT (Early Support for Infants and Toddlers) information from county providers. Additional requirements should be collected during business analytics. The ESIT form that DDA receives from Family Resource Centers (FRCs), hospitals, and Department of Children, Youth & Families (DCYF) is DSHS 15-435.

• Ability to quickly process data in a real-time environment to quickly identify anomalies 

• System competency assessment for accuracy, efficacy and EDI-compliance outcomes. Details on System Compliance will be shared with the successful vendor. Review this page for more information.

• Integrate with homegrown CARE application (Comprehensive Assessment Reporting Evaluation), with Barcode integration, other DSHS software (Microsoft, SAW, IE&E, document management system), and probably ACES (Automated Client Eligibility System). In regard to document management, DDA would need to upload and index any client documentation, such as DSHS forms, if they still exist in the solution, to the Hyland Perceptive Content Records management tool. Note that CARE technical resources operate on quarterly release schedules.
• Maintenance & Operations (M&O) costs must be identified

‍

Proposed or Preferred Capabilities

• “Cognitive Data capture:” Automating the extraction of information from printed, digital, image, and other file types can deliver information at a speed that is impossible for humans to achieve. Capabilities could include converting unstructured data to structured data. Data could be in the form of a data feed, text, or pdf documents.
• SSO using existing Azure AD Groups, if login credentials are needed. DDA uses Azure AD Groups for permissions, we will not be using SAW, but it’s unknown if this will be needed in the solution.
• Meaningful integration with client management system and records management
• Reporting capabilities to allow for quality control
• Configurable to allow for change in decision making criteria
• If the solution has a public facing site:

• Open source is preferred
• API integration is preferred
• Cloud based solutions are preferred
• Software as a solution is preferred
• Low code/No Code is preferred
• Integration with the homegrown system Barcode. The solution will not replace Barcode.
• We have CARE database reporting through homegrown DataMart and SQL query. We are hoping that the solution may include reporting on the functions it touches if not otherwise covered by these methods.

Additional information will be provided through the requirements gathering sessions with the vendor. Recommendations for how best to support a given solution should be included in proposals.