Detail System Design - DED



Use Cases

This section documents any further clarifications made to the details of specific use cases since the General System Design (GSD). Any use cases that have been modified or added during the detailed system design phase are elaborated in this section. Each newly added use case is uniquely numbered in order to facilitate requirements traceability.

Requirements traceability is necessary to help ensure that each identified requirement has an associated design and that test cases are written to validate that the implementation meets the requirement. As part of the detailed design phase of this project, use cases have been mapped to screen shots, reports, interfaces and other design artifacts, as applicable, to help identify the associated design.

1 CCMS-USE-ELI-001 Validate Application Data

| | |

|Use Case ID: |CCMS-USE-ELI-001 |

|Name: |Validate Application Data |

| | |

|Description: |When a client sends in an application, the eligibility workers review the application information |

| |and supporting documentation. Based on this, they determine whether they have the required |

| |documentation to make an eligibility determination or whether they need to request additional |

| |information. |

|Frequency: |The application form is typically entered by families applying for the CCAP for the first time. In |

| |FY10, a total of 82,983 applications were submitted. |

| | |

|Primary Actor: |BCCD/CCR&R/Site Eligibility Staff |

|Secondary Actors: |CCMS |

|Trigger: |An eligibility worker receives a task indicating that there is an application to process. |

|Entry Criteria/Preconditions: |Application data has been extracted from an application form. |

| |Application form and supporting documents were indexed and a task was generated and routed to |

| |appropriate worker. |

|Exit Criteria/Post-Conditions: |All information and supporting documents needed to assess eligibility are available. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |Worker creates case in CCMS. Worker accesses link to IPACS and City of Chicago to search for an existing case. If a match is |

| |found, worker links CCMS case to IPACS case. |

|2 |Worker completes schedule to include dates and times when parent is at work and/or studying, and enters GPA. |

|3 |CCMS calculates number of cases that have been enrolled at provider for selected months and compares to provider capacity. |

|4 |Worker confirms the information on application form and reviews CCMS generated checklist with supporting information available.|

|5 |Worker identifies missing documentation and requests the generation of the first Request for Additional Information (RAI). |

|6 |CCMS generates the 1st RAI and sends it to client and each provider. |

|7 |Client responds to RAI and sends additional documentation within 10 business days of RAI being sent. Refer to use case for |

| |scanning a document. |

|8 |Documents are scanned in and task is generated for eligibility worker to review. |

|9 |Eligibility worker reviews information and deems that application is complete. |

|10 |Worker can check the number of grace periods a client has been granted and if they have used a grace period to increase their |

| |GPA. |

|11 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2a1.1 |Worker identifies application as a shared case application and indicates case identifier for |

| | |corresponding existing shared case. |

| |2a1.2 |CCMS generates alert for corresponding case’s CCR&R/Site and BCCD shared case staff. |

| |2a1.3 |Go to use case Process a Shared Case. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|4 |4a1.1 |For the selected provider, CCMS determines the provider may be overcapacity for selected months when |

| | |parent is at work and/or studying. |

| |4a1.2 |CCMS alerts worker that the provider may be overcapacity. Refer to use case CCMS-USE-GEN-001. |

| |4a1.3 |Worker adds Change of Provider Form to list of necessary documents in RAI. |

| |4a1.4 |Return to step 5 of the normal flow. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|5 |5a1.1 |The worker determines that there is no additional information/documentation needed. |

| |5a1.2 |Return to step 8 of the normal flow. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|7 |7a2.1 |CCMS generates an alert after an agency defined number of days for worker to cancel case. |

| |7a2.2 |Worker cancels case. |

| |7a2.3 |Use case ends. |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|9 |9a1.1 |Worker determines that additional information is required. |

| |9a.1.2 |Worker generates a 2nd RAI and sends it to client (cannot generate a 3rd RAI). |

| |9a1.3 |Return to step 7 of the normal flow. |

| |

2 CCMS-USE-ELI-002 View Eligibility Determination

| | |

|Use Case ID: |CCMS-USE-ELI-002 |

|Name: |View Eligibility Determination |

| | |

|Description: |CCMS users are able to see eligibility results once CCAP eligibility has been determined. |

|Frequency: |Number of applications per year. |

| |Number of redeterminations per year. |

| |Number of changes of information per year. |

| | |

|Primary Actor: |BCCD/CCR&R/Site Eligibility Worker |

|Secondary Actors: |CCMS |

|Trigger: |BCCD, CCR&R, or Site eligibility staff requests approval, denial, or cancellation notice. |

|Entry Criteria/Preconditions: |Eligibility worker determines case eligibility and requests approval, denial, or cancellation |

| |notice. |

|Exit Criteria/Post-Conditions: |BCCD, CCR&R, or Site eligibility staff views approval, denial, or cancellation notice. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |CCMS generates approval, denial or cancellation notice and sends to client. |

|2 |CCMS uploads and indexes notice. |

|3 |Eligibility worker accesses case and is able to view and print approval, denial, or cancellation notice. |

|4 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|3 |3a1.1 |Case has been identified as a shared case. CCMS generates alert for corresponding CCR&R, Site, and BCCD |

| | |shared case staff. |

| |3a1.2 |CCR&R, Site, and BCCD shared case staff accesses case and are able to view and print approval, denial, or|

| | |cancellation notice. |

| |3a1.3 |Go to use case Process an Eligible Shared Case. |

| | |

3 CCMS-USE-ELI-003 Enter Redetermination Data

| | |

|Use Case ID: |CCMS-USE-ELI-003 |

|Name: |Enter Redetermination Data |

| | |

|Description: |This use case documents the redetermination data entry process from the time it is deemed necessary |

| |to have a redetermination until the redetermination form and documentation is entered into the |

| |system. |

|Frequency: |The redetermination process can happen in increments between 30 days - six months or twelve months. |

| |In FY10, a total of 177,141 redeterminations were submitted. |

| | |

|Primary Actor: |BCCD/CCR&R/Site Eligibility Worker |

|Secondary Actors: |CCMS |

|Trigger: |A client’s eligibility is about to expire. |

|Entry Criteria/Preconditions: |A client’s eligibility is about to expire. |

| |Eligibility worker has access to CCMS. |

|Exit Criteria/Post-Conditions: |Information available within redetermination form has been entered into the system. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |CCMS determines that a redetermination is needed. |

|2 |CCMS pre-populates and generates redetermination form and sends it to the client. |

|3 |Client receives redetermination form, completes it, and sends it back to CCR&R, site or BCCD. |

|4 |CCR&R, site, or BCCD receives the redetermination. |

|5 |Redetermination form and supporting documentation is scanned into system, information extracted, indexed, and a task is |

| |assigned to an eligibility worker. Refer to use case CCMS-USE-DOC-001. |

|6 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|3 |3a1.1 |Client does not send completed redetermination form prior to the end of the eligibility period. |

| |3a1.2 |CCMS cancels case and sends notice if new eligibility period is not approved by the last day of month |

| | |prior to eligibility ending, with an effective day for the end of that same edibility period. |

| |3a1.3 |CCMS generates a cancellation notice and sends it to client and each provider. |

| |3a1.4 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|6 |6a1.1 |Case has been identified as a shared case. CCMS generates alert to CCR&R/Site of corresponding shared |

| | |case and BCCD shared case staff. |

| |6a1.2 |Use case ends. |

| | |

4 CCMS-USE-ELI-004 Validate Redetermination Data

| | |

|Use Case ID: |CCMS-USE-ELI-004 |

|Name: |Validate Redetermination Data |

| | |

|Description: |When a client sends in a redetermination, the eligibility workers review the redetermination |

| |information and supporting documentation. Based on this, they determine whether they have the |

| |required documentation to make an eligibility determination or whether they need to request |

| |additional information. |

|Frequency: |The redetermination process can happen in increments between 30 days - six months or twelve months. |

| |In FY10, a total of 177,141 redeterminations were submitted. |

| | |

|Primary Actor: |BCCD/CCR&R/Site Eligibility Worker |

|Secondary Actors: |CCMS |

|Trigger: |An eligibility worker receives a task in their queue indicating that there is a redetermination to |

| |process. |

|Entry Criteria/Preconditions: |Redetermination data was extracted from a redetermination form. |

| |Redetermination form and supporting documents were indexed and a task was generated and routed to |

| |appropriate worker. |

|Exit Criteria/Post-Conditions: |All information and supporting documents needed to assess eligibility are available. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |Worker completes schedule to include dates and times when parent is at approvable activities (work, studying, education, |

| |training, sleep time) during new eligibility period. |

|2 |CCMS calculates number of cases that have been enrolled at provider for selected months and compares to provider capacity. |

|3 |Worker reviews the information on redetermination form and completes CCMS generated checklist with supporting information |

| |available. |

|4 |Worker identifies missing documentation and requests the generation of the first Request for Additional Information (RAI). |

|5 |CCMS generates the 1st RAI and sends it to client. |

|6 |Client responds to RAI and sends additional documentation within 10 business days of RAI being sent. Refer to use case for |

| |scanning a document. |

|7 |Documents are scanned in and task is generated for eligibility worker to review. |

|8 |Eligibility worker reviews information and deems that redetermination packet is complete. |

|9 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2a1.1 |Case has been identified as a shared case. CCMS generates alert for corresponding case’s CCR&R/Site and |

| | |BCCD shared case staff. |

| |2a1.2 |Go to use case Process an Eligible Shared Case. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|3 |3a1.1 |For the selected provider, CCMS determines the provider may be overcapacity for selected months when |

| | |parent is at work and/or studying. |

| |3a1.2 |CCMS alerts worker that the provider may be overcapacity. Refer to use case CCMS-USE-GEN-001. |

| |3a1.3 |Worker adds Change of Provider Form to list of necessary documents in RAI. |

| |3a1.4 |Return to step 3 of the normal flow. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|5 |5a1.1 |The worker determines that there is no additional information/documentation needed. |

| |5a1.2 |Return to step 8 of the normal flow. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|7 |7a2.1 |CCMS generates an alert after an agency defined number of days for worker to cancel case. (However, if |

| | |parent turns in RAI info within 30 days after the first RAI, the case can be assessed for eligibility). |

| |7a2.2 |Worker cancels case. |

| |7a2.3 |Use case ends. |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|9 |9a1.1 |Worker determines that additional information is required. |

| |9a.1.2 |Worker generates a 2nd RAI and sends it to client. |

| |9a1.3 |Return to step 7 of the normal flow. |

| |

5 CCMS-USE-ELI-005 Process Eligible Shared Case

| | |

|Use Case ID: |CCMS-USE-ELI-005 |

|Name: |Process Eligible Shared Case |

| | |

|Description: |Once a shared case application, redetermination, or change of information has been deemed eligible, |

| |process the approval. |

|Frequency: |Number of shared case applications per year. |

| |Number of shared case redeterminations per year. |

| |Number of shared case changes of information per year. |

| | |

|Primary Actor: |CCR&R, site or BCCD eligibility worker |

|Secondary Actors: |CCMS |

| |BCCD Shared Case Staff |

|Trigger: |Application, redetermination, or change of information for was deemed eligible for child care. |

|Entry Criteria/Preconditions: |Application, redetermination, or change of information for shared case has been identified as |

| |eligible for child care. |

| |Case has been identified as a shared case. |

|Exit Criteria/Post-Conditions: |CCR&R, site or BCCD eligibility staff requests CCTS approval notice. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |CCR&R, site or BCCD eligibility staff indicates in CCMS that shared case has been deemed eligible based on CCAP policies. |

|2 |CCMS generates shared case forms. |

|3 |CCR&R, site or BCCD eligibility staff manually determines tentative income and service need for eligibility using an income |

| |calculation sheet. |

|4 |CCR&R, site or BCCD eligibility staff for shared case completes and signs shared case forms, and scan into CCMS. |

|5 |CCR&R, site or BCCD eligibility staff for corresponding shared case reviews and signs shared case forms. |

|6 |CCMS alerts BCCD shared case staff. |

|7 |BCCD shared case staff reviews shared case documents and deems them complete and accurate. |

|8 |CCR&R, site or BCCD eligibility staff requests approval notice. |

|9 |If incoming provider notices an item on previous eligibility that needs to be addressed, they will contact the outgoing |

| |provider. If outgoing provider does not have the information, incoming provider will send RAI to parent and case note file. |

| |10 business days allotted to act on a shared case then Shared Case Coordinators will receive an alert and send reminder |

| |notice to both providers. |

|10 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2a1.1 |Shared case was deemed eligible for a site application. |

| |2a1.2 |Return to step 3 of Normal Flow. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|4 |4a1.1 |CCR&R, site or BCCD eligibility staff do not complete shared case forms. |

| |4a1.2 |CCMS generates an alert for eligibility staff after an agency defined number of days. Refer to use case |

| | |CCMS-USE-GEN-001. |

| |4a1.3 |Return to step 4 of Normal Flow. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|7 |7a1.1 |BCCD Shared Case Coordinator receives alert, reviews shared case documents and indicates they are |

| | |incomplete and/or inaccurate. |

| |7a1.2 |CCMS generates an alert to CCR&R/Site staff. |

| |7a1.3 |CCR&R/Site staff of shared case update and sign shared case forms |

| |7a1.4 |Return to step 5 of Normal Flow. |

| | |

6 CCMS-USE-ELI-007 Validate Change of Information Data

| | |

|Use Case ID: |CCMS-USE-ELI-007 |

|Name: |Validate Change of Information |

| | |

|Description: |This use case documents the change of information data entry process. From the time it is deemed |

| |necessary to have a change of information until the change of information form and documentation is |

| |entered into the system. |

|Frequency: |Number of change of information processes per year |

| | |

|Primary Actor: |BCCD/CCR&R/Site Eligibility Worker |

|Secondary Actors: |CCMS |

|Trigger: |An eligibility worker receives a task in their queue indicating that there is a change of |

| |information to process. |

|Entry Criteria/Preconditions: |Change of information data was extracted from a change of information form. |

| |Change of information form and supporting documents were indexed and a task was generated and routed|

| |to appropriate worker. |

|Exit Criteria/Post-Conditions: |Client information that does not affect eligibility has been changed or all information needed to |

| |determine eligibility is available. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |Worker reviews the information on change of information form and determines change affects eligibility. CCMS generates change |

| |of information checklist. |

|2 |Worker completes CCMS generated checklist with supporting information available. |

|3 |Worker identifies missing documentation and requests the generation of the first Request for Additional Information (RAI). |

|4 |CCMS generates the 1st RAI and sends it to client. |

|5 |Client responds to RAI and sends additional documentation within 10 business days of RAI being sent. Refer to use case for |

| |scanning a document. |

|6 |Documents are scanned in and task is generated for eligibility worker to review. |

|7 |Eligibility worker reviews information and deems that packet is complete. The “complete” status is stored in the database. The|

| |worker is not responsible for sharing the information outside the system. |

|8 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|1 |1a1.1 |Worker reviews the information on change of information form and determines change does not affect |

| | |eligibility. |

| |1a1.2 |Worker applies change to case information. |

| |1a1.3 |Use case ends. |

|1 |1a2.1 |Worker reviews the information on change of information form and determines change does not affect |

| | |eligibility. |

| |1a2.2 |Worker applies change to case information. |

| |1a2.3 |Case is identified as a shared case. CCMS generates alert for corresponding CCR&R/site. |

| |1a2.4 |Go to use case Process an Eligible Shared Case. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|3 |3a1.1 |Case has been identified as a shared case. CCMS generates alert for corresponding case’s CCR&R/Site and |

| | |BCCD shared case staff. |

| |3a1.2 |Return to step 3 of the Normal Flow. |

|3 |3a2.1 |Case has been identified as a shared case. CCMS generates alert to CCR&R/Site for corresponding shared |

| | |case. |

| |3a2.2 |Provider needs to be added or changed. Use case to add/update a provider is executed. |

| |3a2.3 |Return to step 4 of Normal Flow. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|4 |4a1.1 |The worker determines that there is no additional information/documentation needed. |

| |4a1.2 |Return to step 7 of the normal flow. |

|4 |4a2.1 |CCMS generates an alert after an agency defined number of days for worker to cancel case. |

| |4a2.2 |Worker cancels case. |

| |4a2.3 |CCMS generates cancellation notice. |

| |4a2.4 |Use case ends. |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|7 |7a1.1 |Worker determines that additional information is required. |

| |7a.1.2 |Worker generates a 2nd RAI and sends it to client |

| |7a1.3 |Return to step 5 of the normal flow. |

| |

7 CCMS-USE-ELI-008 Transfer a Shared Case

| | |

|Use Case ID: |CCMS-USE-ELI-008 |

|Name: |Transfer a Shared Case |

| | |

|Description: |This Use Case describes the process of transferring a case from one organization to another |

|Frequency: |# of transfers requested |

| | |

|Primary Actor: |BCCD Shared Case Coordinator |

|Secondary Actors: |CCR&R staff |

|Trigger: |When a client wants to transfer to another CCR&R or Site |

|Entry Criteria/Preconditions: |Completion of a Transfer Request Form |

|Exit Criteria/Post-Conditions: |The new provider is accepted |

| |The old provider is cancelled |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |Client, CCR&R, Site or BCCD requests a transfer |

|2 |Staff receives and Time/Date stamps the transfer request |

|3 |Staff completes and scans Cancellation Form |

|4 |Staff completes and scans the Transfer Form |

|5 |Staff updates file in CCMS which alerts the BCCD Shared Case Coordinator |

|6 |CCR&R/Site reviews application |

|7 |BCCD reviews Transfer Form |

|8 |If they are accurate and complete, the they update the CCMS case file |

|9 |If the case is transferred, then it goes to CCTS for the Eligibility determination |

|10 |If CCTS approves Eligibility, then CCMS generates an Approval Notice and Notifies the Client |

|11 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow |Action |

|Steps |Step | |

|10 |10a1.1 |If the documents are not complete, then they are returned to the CCR&R staff from completion. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow |Action |

|Steps |Step | |

|11 |11a1.1 |If the case is not transferred, then CCMS generates a Denial to the Client. |

| | |

8 CCMS-USE-ELI-012 Submit Application Online

| | |

|Use Case ID: |CCMS-USE-ELI-012 |

|Name: |Submit Application Online |

| | |

|Description: |Parents and non-site based providers, i.e. individuals who do not have access to CCMS, have the |

| |option to submit an application online. A parent and provider fill out the application online |

| |together so that both of their portions get completed before submitting to an R&R or BCCD. They are |

| |given access to the application PDF form via the DHS website. Upon submitting the form, the form is |

| |sent to CCMS, automatically indexed, and stored in content manager. An alert is generated to the |

| |appropriate user to notify them that an application form has been submitted, similar to receiving a |

| |form via email or fax. Supporting documents cannot be submitted online. These must be mailed, |

| |dropped off, emailed or faxed. |

|Frequency: |It is unknown at this point the number of individuals who will enter applications online. |

| | |

|Primary Actor: |Parents |

| |Non-site based providers |

|Secondary Actors: |CCMS |

| |Worker |

|Trigger: |N/A |

|Entry Criteria/Preconditions: |N/A |

|Exit Criteria/Post-Conditions: |Application form is saved in content manager. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

| |The user accesses the DHS website and selects to fill out an application form online. |

| |The parent and provider together enter the application data, electronically sign the form, and click the submit button to |

| |submit the form. |

| |The form is sent to CCMS. |

| |CCMS determines the document is an application form. |

| |CCMS indexes the form based on Name, County, and Provider information on the form, if available. |

| |CCMS routes the form to the appropriate organization based on County, to the validation team for that organization, as a task.|

| |A worker from the validation team views the online application form task. |

| |The worker validates that the form was indexed correctly by CCMS. |

| |CCMS routes the form to the appropriate team based on the organization’s administration setup, as a task. |

| |A worker on the team to which the form was routed determines if a new or shared case should be created for the application |

| |form. |

| |The worker creates a new case. |

| |The worker selects to view the data entry screens. |

| |CCMS populates the data entry screens with the data on the form. |

| |See step 4 in the normal flow of use case CCMS-USE-ELI-001 Validate Application Data. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow |Action |

|Steps |Step | |

|11 |11a1.1 |The worker creates a shared case. |

| |11a1.2 |The worker selects to view the data entry screens. |

| |11a1.3 |CCMS does NOT populate the data entry screens with data from the form. |

| |11a1.4 |The worker views the existing case information on the data entry screens and makes updates based on the |

| | |information on the form. |

| |11a1.5 |Return to step 14 in the normal flow. |

| | |

9 CCMS-USE-ELI-013 Identify Duplicate Case

| | |

|Use Case ID: |CCMS-USE-ELI-013 |

|Name: |Identify Duplicate Case |

| | |

|Description: |During the application, redetermination, and COI processes, workers check to see if a duplicate case|

| |exists. If so, they must notify the Shared Case Coordinator to coordinate the cancellation |

| |processing of one the cases. |

|Frequency: |Unknown |

| | |

|Primary Actor: |BCCD/CCR&R/Site Eligibility Worker |

| |BCCD Shared Case Staff |

|Secondary Actors: |CCMS |

|Trigger: |N/A |

|Entry Criteria/Preconditions: |N/A |

|Exit Criteria/Post-Conditions: |One case is cancelled and referred to PIQA. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

| |Worker determines that a case may be potentially a duplicate case. |

| |Worker creates a duplicate case work item and assigns to the BCCD Shared Case Coordinator. |

| |BCCD Shared Case Coordinator will check to see which of the providers had the case first, and issue a cancellation notice and |

| |provider closeout for the 2nd provider. |

| |BCCD will add a cancellation reason code for duplicate cases to the Cancellation form and to the Provider Close Out Form. |

| |If a duplicate case w/DFSS is found on rede or COI, both Sites/R&R and Shared Case Coordinator will receive an alert. |

| |Case will be referred to PIQA and/or Customer Service for review. |

| |The use case ends. |

| | |

10 CCMS-USE-PIQA-001 Schedule Field Review

| | |

|Use Case ID: |CCMS-USE-PIQA-001 |

|Name: |Schedule a Field Review |

| | |

|Description: |This use case describes the process of scheduling a field review of a provider and assigning a PIQA |

| |monitor to conduct that field review. BCCD PIQA conducts a field review of every provider according |

| |to a schedule established by CCMS BCCD policy. |

|Frequency: |PIQA Supervisor would be scheduling on a weekly basis. |

| | |

|Primary Actor: |DHS BCCD PIQA Supervisor and PIQA Field Monitor |

|Secondary Actors: |CCAP Providers |

|Trigger: |A Provider is due to have a field review conducted. |

|Entry Criteria/Preconditions: |The PIQA supervisor has identified a target provider. |

| |The Target Provider is captured in the CCMS. |

| |The PIQA supervisor has identified the monitor to whom he will assign the Field Review. |

| |The PIQA supervisor determines the review period. |

|Exit Criteria/Post-Conditions: |A Field review is scheduled. |

| |A Field Monitoring Packet is generated. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

| |PIQA Supervisor selects provider for which a field review will be conducted. |

| |PIQA Supervisor assigns a PIQA Field Monitor the task of conducting a field review of that Provider. |

| |The PIQA Supervisor selects the review period and the number of cases to review (the Sample Size). |

| |CCMS generates a Child List by Provider by Period. |

| |PIQA Field Monitor manually contacts Provider to schedule a field review. |

| |PIQA Field Monitor requests CCMS to generate a Case list and copies and pastes it into Report Worksheet. |

| |PIQA Field monitor manually sends (via mail/email/fax) a Field Monitoring Packet. |

| |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow |Action |

|Steps |Step | |

|6 |6.1 |PIQA Field monitor obtains Case List from MERS and copies and pastes into Report Worksheet |

| | |

11 CCMS-USE-CS-006 Process a CCR&R/Site Customer Service Request

| | |

|Use Case ID: |CCMS-USE-CS-006 |

|Name: |Process a CCR&R/Site Customer Service Request |

| | |

|Description: |CCR&R or Site staff can keep track of questions or requests received from clients and providers in |

| |CCMS. They enter the information in a customer service request data entry form. The staff then |

| |researches the request and prepares a response. The research and response details are then entered |

| |into the data entry form and submitted to the requestor. Alternatively, CCR&R or Site staff with |

| |access to CCMS may create a customer service request and route to BCCD staff. This could be for |

| |policy clarifications, payment questions, or training requests. |

|Frequency: |# of provider questions/requests per week |

| |# of client questions/requests per week |

| |# of CCR&R/Site policy clarifications per week |

| |# of CCR&R/Site payment questions per week |

| |# of CCR&R/Site training requests per week |

| | |

|Primary Actor: |CCR&R/Site staff |

|Secondary Actors: |CCMS |

| |Clients or providers |

|Trigger: |CCR&R/Site staff receives a question/request from client or provider. |

| |CCR&R/Site staff has a policy clarification, payment question or training request. |

|Entry Criteria/Preconditions: |The CCR&R/Site staff has logged into CCMS. |

|Exit Criteria/Post-Conditions: |Service request is closed or request is routed to BCCD customer service, payments, or training |

| |staff. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |Client/Provider puts in customer service request to CCR&R or Site via mail, fax, call, or email. |

|2 |CCR&R/Site staff scans documents into CCMS if available. Please refer to use case CCMS-USE-DOC-001 for further details. |

|3 |CCMS generates a customer service request file. |

|4 |CCR&R/Site staff enters request details into the work item details screen. |

|5 |CCR&R/Site staff performs research for request. |

|6 |CCR&R/Site staff prepares response for requestor. |

|7 |CCR&R/Site staff scans related documents into CCMS, updates work item, and closes request. |

|8 |CCR&R/Site staff sends response to requestor. |

|9 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|1 |1a1.1 |CCR&R/Site staff has customer service, payment, or training request. |

| |1a1.2 |Return to step 2 in Normal Flow. |

|6 |6a1.1 |CCR&R/Site staff indicate request need to be routed to BCCD customer service, payment, or training staff.|

| |6a1.2 |CCMS routes request to customer service, payment, or training staff. Refer to use case CCMS-USE-CS-001 |

| | |for additional details. |

| |6a1.3 |Use Case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|8 |8a1.1 |CCR&R/Site staff takes more than agency defined number of days to respond to request. |

| |8a1.2 |CCMS generates alert to remind CCR&R/Site staff that request is still open. |

| |8a1.3 |Return to step 8 in the normal flow. |

| | |

12 CCMS-USE-DOC-001 Prepare Documents for Scanning

| | |

|Use Case ID: |CCMS-USE-DOC-001 |

|Name: |Prepare documents for Scanning |

| | |

|Description: |This use case describes the process for triaging a set of documents to prepare them for scanning. |

| |There are three different types of documents to scan: |

| |1) Bar coded system-recognizable forms with supporting documents. A single-page or multi-page |

| |document that was generated out of CCMS that Kofax capture can automatically index via optical |

| |character recognition and zoning or LiveCycle can recognize using bar codes. These types of |

| |documents are accompanied by one or more single-page or multi-page supporting documents. Example, |

| |Rede or Request for Additional Information (RAI) form generated from CCMS and sent to the customer. |

| |2) System-recognizable forms with supporting documents. These documents are not generated from |

| |within CCMS and will not have bar codes. These documents are accessible via web links. Example, |

| |Appeal Form, W-9 etc. |

| |3) Unindexed document image. These documents are not generated out of CCMS and do not accompany any|

| |of the document sets identified above. These are loose sheets of single-page or multi-page |

| |documents that must be manually indexed by the user. Example, drivers license, passport pages, pay |

| |stub etc. |

|Frequency: |# of documents mailed or dropped off |

| | |

|Primary Actor: |BCCD/ R&R/ Site Staff |

|Secondary Actors: | |

|Trigger: |Staff person has to triage documents |

|Entry Criteria/Preconditions: |N/A |

|Exit Criteria/Post-Conditions: |Document sets are ready for scanning |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |Staff picks up several packets of mail. Note: BCCD has two geographical locations where scanning will be performed. R&Rs |

| |and some sites will have one mail room per agency that caters to several geographical locations. Staff should have mobility |

| |to work from several geographical locations. For example, Skip-A-Long and One Hope United have multiple locations. |

|2 |Staff groups the documents by document type: |

| |System-recognizable document plus supporting documents |

| |Bar coded system-recognizable documents plus supporting documents |

| |Independent unindexed document images |

|3 |Staff adds separator sheet on top of each of the supporting documents. A separator sheet is not required on top of |

| |system-recognizable documents. |

|4 |Staff creates a pile of documents as follows: |

| |All system-recognizable documents of one type, each followed by separator sheet and then supporting document (e.g., |

| |recognizable document 1 of type A – separator sheet – supporting document 1 – separator sheet – supporting document 2 – |

| |recognizable document 2 of type A – separator sheet – supporting document 1) |

| |All bar coded recognizable documents of one type, each followed by separator sheet and then supporting document (e.g., bar |

| |coded recognizable document 1 of type A – separator sheet – supporting document 1 – separator sheet – supporting document 2 |

| |– bar coded recognizable document 2 of type A – separator sheet – supporting document 1) |

| |All independent documents with separator sheets |

|5 |At this point, each pile of document organized by document type is ready for scanning |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

| | |None |

| | |

| | |

|Exception Flow | |

| | |

|Normal Flow |Alternative Flow |Exception Flow |Action |

|Steps |Step |Step | |

| | | |None |

| | |

13 CCMS-USE-DOC-001 Scan and Release Document

| | |

|Use Case ID: |CCMS-USE-DOC-002 |

|Name: |Scan Documents |

| | |

|Description: |This use case describes the process of scanning, recognizing, indexing, validating and releasing a |

| |document into IBM Content Manager. |

|Frequency: |# of documents mailed or dropped off. |

| | |

|Primary Actor: |BCCD/ R&R/ Site Staff |

|Secondary Actors: |CCMS (Scanner, Kofax Scan Station/Kofax Capture, IBM Content Manager) |

|Trigger: |Staff person has to scan each set of document created in the previous use case, index, validate and |

| |release them into IBM Content Manager. |

|Entry Criteria/Preconditions: |N/A |

|Exit Criteria/Post-Conditions: |Document is stored in IBM content manager. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |The scanning staff scans a document set by document type – scanner places a post-scanning imprint on the document that |

| |consists of date and time stamp and page count. |

|2 |Kofax Capture prepares each document followed by supporting document for indexing. |

|3 |If the first document is recognized as a “system-recognizable document without bar code” (example, appeal with supporting |

| |documentation) or “system-recognizable document with bar code” (example, Rede with supporting documentation): |

| |Recognize each page as part of one document until a separator sheet or another recognizable document of the same type is |

| |recognized |

| |If a separator sheet is hit then recognize the pages that follow as one supporting document |

| |Repeat 2 until a recognizable document is hit or it is the end of the document pile |

| |If a recognizable document of the same type is hit then go through steps 1), 2) and 3) |

| | |

| |Note: documents and document types are identified in Appendix F. |

|4 |Using zoning and OCR, recognize index information from the main recognizable document and apply the same information to each|

| |corresponding supporting document. Remove blank pages, if any. |

|5 |Scanning staff validates indexing information and provides the document type for each supporting document. |

|6 |Scanning staff releases the document to IBM content manager. |

|7 |Document gets stored in IBM content manager along with the index information. |

|8 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|3 |3a1.1 |If the first document is recognized as neither a “bar coded recognizable document” nor a “recognizable |

| | |document without bar code” then it is an unindexed image document and is processed as follows: |

| | |Recognize each page as part of one document until a separator sheet or end of the pile is reached |

| | |If a separator sheet is hit then recognize the pages that follow as one document |

| | |Repeat 1) and 2) until the end of the document pile |

| | | |

| | |Note: documents and document types are identified in Appendix F. |

| |3a1.2 |Go to Step 6) of the normal flow. |

| | |

|Exception Flow | |

| | |

|Normal Flow |Alternative Flow |Exception Flow |Action |

|Steps |Step |Step | |

|3 |N/A |3e1.1 |If the document has not been scanned in correctly then it is routed to a quality control|

| | | |queue within Kofax Capture software for further action. |

| | |

14 CCMS-USE-DOC-003 Create “Validate Document” Task

| | |

|Use Case ID: |CCMS-USE-DOC-003 |

|Name: |Validate Document task based on Scanned Document |

| | |

|Description: |This use case describes the process of creating a task for a validation team to validate a document |

| |that has been scanned into Content Manager. |

|Frequency: |# of documents mailed or dropped off. |

| | |

|Primary Actor: |BCCD/ R&R/ Site Staff |

|Secondary Actors: |CCMS |

|Trigger: |CCMS system creates a task and routes task based on routing rules to a team for validating |

| |documents. |

|Entry Criteria/Preconditions: |Documents have been scanned and stored in IBM Content Manager. |

|Exit Criteria/Post-Conditions: |Document validation is complete and the document is associated with the right case within CCMS. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |The CCMS System (Adobe LiveCycle process) polls IBM Content Manager for new documents |

|2 | “Validate Document” task is created for the new document and routed based on routing rules provided that enough index |

| |information is available for correct routing |

|3 |A person belonging to the task recipient team opens the task and validates the document by confirming the case assignment |

| |and assigning the document to an existing work item. Where necessary, the user searches CCMS using data elements from the |

| |form to identify the right case, work item and other index information and assigns the information to the document. |

|4 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2a1.1 |If insufficient index information is available for the scanned document then CCMS routes the document to|

| | |the site’s non-indexed document validation team by using the site information captured during the |

| | |scanning process. An example of this kind of document is a new application form that may not have an |

| | |associated person or case in CCMS. |

| |2a1.2 |Site-specific non-indexed document validation team member indexes the document by assigning the right |

| | |case number and work item to the document. The user looks up the associated case information from CCMS |

| | |by entering data available on the form into CCMS and then associates the right index information to the |

| | |document. If the scanned document is a new application form with no person or case information within |

| | |CCMS then an application processing work item is created to move the application to the next processing |

| | |step. |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2a1.1 |If insufficient index information is available for the scanned document and the site information is not |

| | |available either then CCMS routes the document to a central non-indexed document validation team. The |

| | |central non-indexed validation queue is visible to all site-specific non-indexed document validation |

| | |teams. |

| |2a1.2 |The central non-indexed validation team member routes the document to the correct site after completing |

| | |some research based on visual document inspection and using CCMS to find related information. |

|Exception Flow | |

| | |

|Normal Flow |Alternative Flow |Exception Flow |Action |

|Steps |Step |Step | |

|3 |N/A |3e1.1 |Standard exception conditions for interaction between LiveCycle and Content Manager |

| | | |apply. |

| | |

15 CCMS-USE-DOC-004 Box Document

| | |

|Use Case ID: |CCMS-USE-DOC-004 |

|Name: |Place scanned document set in a box. |

| | |

|Description: |This use case describes the process of placing scanned documents into a box for archiving. Filled |

| |boxes become part of a pallet for long term archival. |

|Frequency: |# of documents mailed or dropped off. |

| | |

|Primary Actor: |BCCD/ R&R/ Site Staff |

|Secondary Actors: | |

|Trigger: |Scanning of a document set based on document type has been completed. |

|Entry Criteria/Preconditions: |N/A |

|Exit Criteria/Post-Conditions: |Scanned document set has been placed in a box. |

| | |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |Upon scanning a document set, the Scanning staff prepares to place the documents in a box for archiving. |

|2 |If this is the first document set being placed in the box then the scanning staff prepares a box label with key information |

| |such as pallet number, box number, start imprinter data and box name. |

|3 |Scanning staff places the document in the box. |

|4 |Use case ends. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2a1.1 |If this is the last document set to be placed in the box then the scanning staff completes the label |

| | |information by writing down the end imprinter data and pallet number. See “Box Management” screen for |

| | |details on how information about the storage box is maintained in CCMS for future reference. |

16 CCMS-USE-DOC-005 Email/Fax Document

| | |

|Use Case ID: |CCMS-USE-DOC-005 |

|Name: |Email/Fax Document |

| | |

|Description: |This use case describes the process for when any document is emailed or faxed to the system. At a |

| |high-level there are three different types of documents to email/fax: |

| |1) Bar coded system-recognizable forms with supporting documents. A single-page or multi-page |

| |document that was generated out of CCMS that Kofax capture can automatically index via optical |

| |character recognition and zoning or LiveCycle can recognize using bar codes. These types of |

| |documents are accompanied by one or more single-page or multi-page supporting documents. Example, |

| |Rede or Request for Additional Information (RAI) form generated from CCMS and sent to the customer. |

| |2) System-recognizable forms with supporting documents. These documents are not generated from |

| |within CCMS and will not have bar codes. These documents are accessible via web links. Example: |

| |Appeal Form, W-9 etc. This also includes fillable PDF forms like the Application Form. |

| |3) Unindexed document image. These documents are not generated out of CCMS and do not accompany any|

| |of the document sets identified above. These are loose sheets of single-page or multi-page |

| |documents that must be manually indexed by the user. Example: drivers license, passport pages, pay |

| |stub etc. Another example of unindexed documents is when case workers and providers have documents |

| |to attach to a case file then they could email the document. |

|Frequency: |# of documents emailed or faxed. |

| | |

|Primary Actor: |BCCD/ R&R/ Site Staff |

|Secondary Actors: |CCMS |

|Trigger: |An email is received by a central email or a fax is received by a central fax. |

|Entry Criteria/Preconditions: |N/A |

|Exit Criteria/Post-Conditions: |Document is stored in content manager. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |An individual emails or faxes a document to CCMS. |

|2 |If an email, CCMS (LiveCycle) pulls the attachments from the email. |

|3 |If a bar coded document then the bar code is decoded for index information. Bar code needs to contain county of residence |

| |and R&R information. |

| |If fillable PDF, pull index data (does not apply to fax) |

| |If flattened PDF, then the system has no index – go to central validation team |

|4 |If a non-bar coded fillable PDF then the index data is extracted from the document. |

|5 |If the document is neither bar coded nor fillable PDF then no index information is extracted. |

|6 |The document is placed in Content Manager with available index information. |

|7 |Go to “Create Validate Document Task” use case. |

| | |

| | |

|Alternative Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2a1.1 |If the document is faxed to the central fax number then the document is sent to IBM Content Manager via |

| | |Kofax. The document gets released with as much index information as possible. |

| |2a1.2 |Go to Create “Validate Document” task use case. |

| | |

|Exception Flow | |

| | |

|Normal Flow |Alternative Flow Step|Action |

|Steps | | |

|2 |2e1.1 |If a faxed or emailed document cannot be appropriately processed then an email is sent to designated |

| | |administrators. |

| | |

17 CCMS-USE-GEN-001 Create Work Item

| | |

|Use Case ID: |CCMS-USE-GEN-001 |

|Name: |Create Work Item |

| | |

|Description: |Work Items are used to track process. This allows BCCD/CCR&R/Site to track the progress of a |

| |request. |

|Frequency: |As needed. |

| | |

|Primary Actor: |BCCD Staff (Eligibility, Customer Service and PIQA) |

|Secondary Actors: |CCR&R/Site Staff |

|Trigger: |A Work Item process step is completed. |

|Entry Criteria/Preconditions: |NA |

|Exit Criteria/Post-Conditions: |The Work Item is created. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |The worker gets a client request via email, fax, scan or phone call. |

|2 |The worker goes to the appropriate tab to create the work item (Eligibility, Customer Service or PIQA). |

|3 |The worker then clicks on the Work Item Search button. |

|4 |The worker then clicks on the create work item button. |

|5 |The worker enters the appropriate work item details. |

|8 |The worker then clicks the create button. |

|9 |The use case ends. |

18 CCMS-USE-GEN-002 Update Work Item

| | |

|Use Case ID: |CCMS-USE-GEN-002 |

|Name: |Update Work Item |

| | |

|Description: |Work Items are used to track the progress of a Child Care process. Every time a task is completed, |

| |the work item status is updated. |

|Frequency: |As needed. |

| | |

|Primary Actor: |BCCD Staff (Eligibility, Customer Service and PIQA) |

|Secondary Actors: |CCR&R Staff |

|Trigger: |A task is completed. |

|Entry Criteria/Preconditions: |NA |

|Exit Criteria/Post-Conditions: |The Work Item status is updated. |

| | |

| | |

|Normal Flow | |

| | |

|Normal Flow |Action |

|Steps | |

|1 |The worker completes a task. |

|2 |The worker opens the appropriate tab to view the Work Item (Eligibility, Customer Service or PIQA). |

|3 |The worker then clicks on the Work Item Search button. |

|4 |The worker searches for the Work Item. |

|5 |The worker opens the Work Item. |

|6 |The worker updates the workflow status and work item status (if applicable) of the work item. |

|8 |The worker then clicks the save button to update the work item. |

|9 |The use case ends. |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download