General System Design - Illinois Department of Human Services
[pic] [pic]
General System Design
Child Care Management System
|Client: |Illinois Department of Human Services |
|Author: |Deloitte |
|Version: |2.1 |
|Date: |4 January 2011 |
|File Name: |CCMS-Del-GSD v2 1.doc |
Document Control Information
|Document Name: |General System Design |
|Project Name: |Child Care Management System |
|Client: |Illinois Department of Human Services |
|Document Author: |Deloitte |
|Document Version: |2.1 |
|Template Version: |3.0 |
|Status: |Final |
|Date Released: |1/04/2011 |
|Electronic File Name: |CCMS-Del-Des-GSD v2.1.doc |
Document History
|Version |Date |Additions/Modifications |Prepared/Revised by |
|1.0 |12/03/2010 |Initial deliverable submitted to client |Deloitte |
|2.0 |12/28/2010 |Final deliverable submitted to client |Deloitte |
|2.1 |01/04/2011 |Minor modifications to the final deliverable submitted to client |Deloitte |
Table of Contents
1 Executive summary 6
1.1 Document Navigation Guide 10
2 Session Schedule 12
3 Proposed Processes 13
3.1 CCMS-BP-ELI-001 Process an Application 15
3.2 CCMS-BP-ELI-002 Process a Redetermination 16
3.3 CCMS-BP-ELI-003 Process a Change of Information 17
3.4 CCMS-BP-ELI-004 Process an Application for a Shared Case 18
3.5 CCMS-BP-ELI-005 Process a Redetermination for a Shared Case 20
3.6 CCMS-BP-ELI-006 Process a Change of Information (COI) for a Shared Case 21
3.7 CCMS-BP-ELI-007 Transfer a Shared Case 22
3.8 CCMS-BP-ELI-008 Add/Update a Provider 23
3.9 CCMS-BP-CS-001 Process a Customer Service Request 24
3.10 CCMS-BP-CS-002 Process a Provider Overpayment 25
3.11 CCMS-BP-CS-003 Process a Client Overpayment 26
3.12 CCMS-BP-CS-004 Process an Appeal 27
3.13 CCMS-BP-CS-005 Process an Attendance Exemption 28
3.14 CCMS-BP-CS-006 Process a CCR&R/Site Customer Service Request 29
3.15 CCMS-BP-CS-007 Process a W9 30
3.16 CCMS-BP-PIQA-001 Schedule a Field Review 31
3.17 CCMS-BP-PIQA-002 Conduct a Field Review 32
3.18 CCMS-BP-PIQA-003 Prepare a Final Report 33
3.19 CCMS-BP-PIQA-004 Process a CCR&R Suspected Program Violation 34
3.20 CCMS-BP-PIQA-005 Process a Suspected Intentional Program Violation Referral 35
3.21 CCMS-BP-DOC-001 Scan/Email/Fax/Route Document 36
4 Use Cases 37
4.1 CCMS-USE-ELI-001 Validate Application Data 37
4.2 CCMS-USE-ELI-002 View Eligibility Determination 41
4.3 CCMS-USE-ELI-003 Enter Redetermination Data 43
4.4 CCMS-USE-ELI-004 Validate Redetermination Data 45
4.5 CCMS-USE-ELI-005 Process Eligible Shared Case 49
4.6 CCMS-USE-ELI-006 Enter Data for Change of Information 52
4.7 CCMS-USE-ELI-007 Validate Change of Information Data 54
4.8 CCMS-USE-ELI-008 Transfer a Shared Case 58
4.9 CCMS-USE-ELI-009 Add/Update a Provider 60
4.10 CCMS-USE-ELI-012 Submit Application Online 62
4.11 CCMS-USE-CS-001 Process a Customer Service Request 64
4.12 CCMS-USE-CS-002 Process a Provider Overpayment 67
4.13 CCMS-USE-CS-003 Process a Client Overpayment 72
4.14 CCMS-USE-CS-004 Process an Appeal 77
4.15 CCMS-USE-CS-005 Process an Attendance Exemption 80
4.16 CCMS-USE-CS-006 Process a CCR&R/Site Customer Service Request 83
4.17 CCMS-USE-CS-007 Process a W9 Form 86
4.18 CCMS-USE-PIQA-001 Schedule Field Review 90
4.19 CCMS-USE-PIQA-002 Conduct Field Review 92
4.20 CCMS-USE-PIQA-003 Prepare a Final Report 94
4.21 CCMS-USE-PIQA-004 Process a CCR&R Program Violation Referral 97
4.22 CCMS-USE-PIQA-005 Process a PIQA Program Violation Referral 99
4.23 CCMS-USE-DOC-001 Scan Document 102
4.24 CCMS-USE-DOC-002 Email/Fax Document 104
4.25 CCMS-USE-DOC-003 Route Document 106
4.26 CCMS-USE-GEN-001 Generate Alert/Task 107
5 Entities 109
6 Other Design Components 116
6.1 Reports 116
6.2 Interfaces 120
7 Final development configuration and Initial Training, Test and Production considerations 127
7.1 CCMS System Components 127
7.2 State of Illinois Information Technology Standards Compliance 129
7.3 Initial Training, Test, QA and Production Environment Considerations 140
8 Requirements List 141
9 initial Key Considerations 142
10 knowledge Transfer 144
11 Assumptions and Dependencies 148
11.1 Assumptions 148
11.1.1 Document Capture and Processing 148
11.1.2 Security and Audit 148
11.1.3 Technical Environment 149
11.1.4 General 149
11.2 Dependencies 150
11.2.1 Document Capture and Processing 150
11.2.2 Security and Audit 150
11.2.3 Technical Environments 150
Appendix A – GSD Related Outstanding Action Items 151
Appendix B – Forms and Alerts 153
Executive summary
Deloitte has collaborated with the State of Illinois, Department of Human Services (DHS) Bureau of Child Care Development (BCCD) and Management Information System (MIS), to prepare the General System Design (GSD) for the Child Care Management System (CMMS). This document is the product of careful requirements analysis, formulation of business processes and use cases and execution of joint GSD sessions for the purpose of confirming and documenting business processes and use cases, clarifying requirements and capturing missing requirements, if any. The document will act as the basis for developing detailed system design during the next phase of the project.
Deloitte has undertaken the effort of preparing the GSD as a first step in assisting the State with the transformation effort to change the way Child Care activities are tracked and managed in Illinois. The BCCD has developed an innovative and fiscally responsible approach to better use available technologies to achieve its mission. Through the deployment of an Internet based solution, BCCD will be able to reduce manual, paper-intensive processes to allow for faster payments, ease of access, and improved quality of care. Integrating a document management and workflow system with the existing Child Care Tracking System (CCTS) will enable IDHS to deliver services more efficiently.
[pic]
Figure 1-1: CMMS Project Outcomes
This deliverable contains a high-level description of processes, associated use cases, clarification of base requirements, and the traceability of requirements to use cases which will form the foundation for subsequent phases of this project.
CCMS consists of several key components:
[pic]
Figure 1-2: CCMS Functional Components
Electronic Document Workflow – Our proposed solution for the Electronic Document Workflow requirements meet DHS’ mandatory requirements, as well as a large percentage of desirable requirements with configuration techniques and relatively minimal custom J2EE or Flex development. This provides DHS with a solution that is maintainable, upgradeable, and scalable as the needs of the organization evolve and expand over time.
Content Management – The Content Management function of the CCMS solution provides the means by which users interact with the CCMS. The other functions leverage the Content Management and Electronic Document Workflow solution to execute the related business processes supporting the Child Care program.
Customer Service – Deloitte’s approach to empowering and enabling DHS users through an effective Customer Service function is achieved through access to relevant and appropriate information via the CCMS user interface. Customer Service will be greatly enhanced as information will be electronically available at the user’s fingertips. Common delays currently experienced due to the need to contact various entities to track down information, or wait for their manual look up in paper documents spread across the state are significantly reduced and potentially eliminated. Finally, the ability to centrally manage and track the Customer Service inquiries currently in progress provides an advantageous view and insight of interactions between the organization and the people that are served.
Program Integrity and Quality Assurance – The Program Integrity and Quality Assurance (PIQA) functional requirement area of the solution manages the Quality Assurance Reviews and Fraud Investigation & Non-Compliance business processes. Coordinated through Tasks in CCMS, stakeholders are electronically engaged in data sharing and investigative discovery of information supporting these two business functions.
Reporting and Historical Data – CCMS provides a rich set of search capabilities to locate specific tasks, applications, However, it is through summarized and detailed reports that management and field staff monitor and refine business process operations. Supported by Business Objects’ Crystal Reports, the solution will produce a set of static reports available on-demand, and will use CCMS tasks to notify specific users of the availability of reports requiring their immediate attention and review.
Deloitte and BCCD agreed to consider a collaborative approach to analyzing Child Care Eligibility rules, formulate recommendations, reach scope agreement, and finalize architecture. This approach has been documented for consideration as Change Request #47061 – “Analyze Child Care Eligibility Rules and make recommendations.”
By approving this deliverable, DHS is approving clarifications of the base requirements in the RFP and the fact that new requirements have been identified during this phase. The new requirements will be discussed as part of the Change Control Process to facilitate DHS’s decision to include or exclude them from the initial implementation of the system.
The development environment specifications have also been identified in this document. By approval of this document, DHS agrees to make the development environment ready for use per the requested date in the project work plan included in the Project Plan Deliverable.
1 Document Navigation Guide
To articulate the CCMS GSD, the document has been segmented into ten sections.
|Table 1-1. Document Navigation Guide |
|Section/Name |Description |
|Section 1. Executive Summary |This is the current section and provides an overview of the goals, objectives and anticipated|
| |outcomes of the CCMS and includes an overview of the CCMS business process. |
|Section 2. Session Schedule |This section captures the schedule of GSD sessions and attendees that helped provide the |
| |clarification and insight necessary to formulate the content for this document. |
|Section 3. Proposed Processes |This section includes a description of the business processes that the new system is expected|
| |to automate. Each business process has been uniquely numbered in order to facilitate |
| |traceability of requirements to each process. |
|Section 4. Use Cases |Use cases elaborate the requirements of the system from a user’s point of view or the point |
| |of view of the system, where applicable. Each use case has been uniquely numbered in order |
| |to facilitate requirements traceability. |
|Section 5. Entities |The list of entities includes a preliminary identification of entities that will provide a |
| |basis for further elaboration during the detailed design phase. |
|Section 6. Other Design Components |Reports - A description of anticipated reports from the system that includes data extracts |
| |for the purpose of federal reporting. |
| |Interfaces - A description of incoming and outgoing interfaces including the identification |
| |of source and destination systems, mode (e.g., real-time vs. batch), frequency of execution, |
| |anticipated number of records, initial list of data elements, and a high-level description of|
| |anticipated interface data format. |
|Section 7. Final Development |Specifications for the development environment and key considerations for developing |
|Configuration and Initial Training, |specifications for other technical environments during the detailed design phase. |
|Test, Quality Assurance (QA) and | |
|Production Considerations | |
|Section 8. Requirements Traceability |Describes the cumulative list of requirements confirmed during this phase of the project. |
| |Requirements that have been added, modified or deleted are also noted. Furthermore, |
| |requirements are mapped to use cases and business processes for the purpose of providing |
| |traceability through the software development life cycle process. |
|Section 9. Initial Key Considerations |This section documents key considerations, if any, as they pertain to system domains such as |
| |platform, security, operations and support, etc. |
|Section 10. Knowledge Transfer. |The Deloitte Project Team worked closely and collaboratively with the DHS Project Team |
| |through the GSD phase activities that culminated in the development of this document. This |
| |section provides a documentation of these activities. |
|Section 11. Assumptions and dependencies| System assumptions and dependencies that arose out of the clarification provided during the |
| |GSD phase have been documented in this section. |
Session Schedule
The approach to developing the GSD is a collaborative effort between Deloitte and DHS and involved the following activities:
a) Preparing for GSD Sessions – During this activity the Deloitte team analyzed, categorized and grouped requirements. DHS arranged for and conducted demonstrations of existing processes and systems. Requirements were clarified, as necessary, during this process. The Deloitte team also prepared draft versions of the “to-be” business process flow diagrams, mapped requirements to these business processes, created use cases where appropriate, and defined the development environment technical specifications while scheduling sessions, as appropriate, with BCCD and MIS staff.
b) Conducting GSD Sessions – Prior to the first GSD session the approach was confirmed with participants to enable clear understanding of session goals and outcomes. During the GSD sessions, a walkthrough of appropriate business processes, use cases and requirements was conducted to confirm and validate them. Missing requirements, if any, were captured.
The following table provides a schedule of GSD session events.
|DATE |MEETING NAME |PLACE |TIME |
|Tue |KICK OFF |ORS Training, Spfld. & |10-11:30 |
|26-Oct | |Murdock (Suite 5-300), Chicago | |
|Mon |JAD - Eligibility |Suter, Spfld. & |1-4 |
|1-Nov | |Murdock (Suite 5-300), Chicago | |
|Thu |JAD – Eligibility |Springfield, Harris Building, 100 South Grand East, Conference|10-3 |
| | |Room 2A | |
|4-Nov | | | |
|Fri |JAD – Eligibility |Springfield, Harris Building, 100 South Grand East, Conference|9-12 |
| | |Room 2A | |
|5-Nov | | | |
|Tue |JAD – Eligibility |Springfield, Harris Building, 100 South Grand East, Conference|10-3 |
| | |Room 2A | |
|9-Nov | | | |
|Wed |JAD – Customer Service |Springfield, Harris Building, 100 South Grand East, Conference|9-2 |
| | |Room 2A | |
|10-Nov | | | |
|Fri |JAD – Technical 1 |Springfield, Harris Building, 100 South Grand East, Conference|9-12 |
| | |Room HCD | |
|12-Nov | | | |
|Tue |JAD – PIQA |Deloitte Chicago Office,111 S. Wacker Dr. Conference Room |10-3 |
| | |NE-22 | |
|16-Nov | |Springfield, Harris Building, 100 South Grand East, Conference| |
| | |Room HCD | |
|Fri |JAD – Technical 2 |Springfield, Harris Building, 100 South Grand East, Conference|9-3 |
| | |Room HCD | |
|19-Nov | | | |
|Mon |JAD – Wrap Up |Conference Call |9-12 |
|22-Nov | | | |
Proposed Processes
This section contains descriptions of the business processes that the new system is expected to automate. Each business process will be uniquely numbered in order to facilitate traceability of requirements to each process.
|Table 4-1. List of use cases associated with CCMS business processes |
|# |Business Processes |Corresponding Use Case(s) |
|1 |CCMS-BP-ELI-001 Process an Application |CCMS-USE-ELI-001 Validate Application Data |
| | |CCMS–USE-ELI-002 View Eligibility Determination |
|2 |CCMS-BP-ELI-002 Process a Redetermination |CCMS-USE-ELI-003 Enter Redetermination Data |
| | |CCMS-USE-ELI-004 Validate Redetermination Data |
|3 |CCMS-BP-ELI-003 Process a Change of |CCMS-USE-ELI-006 Enter Data for Change of Information |
| |Information |CCMS-USE-ELI-007 Validate Change of Information Data |
|4 |CCMS-BP-ELI-004 Process an Application for a |CCMS-USE-ELI-005 Process Eligible Shared Case |
| |Shared Case | |
|5 |CCMS-BP-ELI-005 Process a Redetermination for|CCMS-USE-ELI-005 Process Eligible Shared Case |
| |a Shared Case | |
|6 |CCMS-BP-ELI-006 Process a Change of |CCMS-USE-ELI-005 Process Eligible Shared Case |
| |Information (COI) for a Shared Case | |
|7 |CCMS-BP-ELI-007 Transfer a Shared Case |CCMS-USE-ELI-008 Transfer a Shared Case |
|8 |CCMS-BP-ELI-008 Add/Update a Provider |CCMS-USE-ELI-009 Add/Update a Provider |
|9 |CCMS-BP-ELI-010 Process a W9 Form |CCMS-USE-ELI-011 Process a W9 Form |
|10 |CCMS-BP-CS-001 Process a Customer Service |CCMS-USE-CS-001 Process a Customer Service Request |
| |Request | |
|11 |CCMS-BP-CS-002 Process a Provider Overpayment|CCMS-USE-CS-002 Process a Provider Overpayment |
|12 |CCMS-BP-CS-003 Process a Client Overpayment |CCMS-USE-CS-003 Process a Client Overpayment |
|13 |CCMS-BP-CS-004 Process an Appeal |CCMS-USE-CS-004 Process an Appeal |
|14 |CCMS-BP-CS-005 Process an Attendance |CCMS-USE-CS-005 Process an Attendance Exemption |
| |Exemption | |
|15 |CCMS-BP-CS-006 Process a CCR&R/Site Customer |CCMS-USE-CS-006 Process a CCR&R/Site Customer Service Request |
| |Service Request | |
|16 |CCMS-BP-PIQA-001 |CCMS-USE-PIQA-001 Schedule a Field Review |
| |Schedule a Field Review | |
|17 |CCMS-BP-PIQA-002 |CCMS-USE-PIQA-002 Conduct a Field Review |
| |Conduct a Field Review | |
|18 |CCMS-BP-PIQA-003 |CCMS-USE-PIQA-003 Prepare a Final Report |
| |Prepare a Final Report | |
|19 |CCMS-BP-PIQA-004 |CCMS-USE-PIQA-004 Process a CCR&R Program violation Referral |
| |Process a CCR&R Program Violation | |
|20 |CCMS-BP-PIQA-005 |CCMS-USE-PIQA-005 Process a PIQA Program Violation Referral |
| |Process a PIQA Program Violation | |
2 CCMS-BP-ELI-001 Process an Application
This process defines the steps for when a client applies for the Child Care Assistance Program (CCAP). This business process documents the steps needed from the time an application form is received until the client’s program eligibility is determined. The system will generate alerts to the eligibility workers after a certain amount of time to inform them that follow-up actions are needed on the case and to cancel it if the client has not returned the required information.
[pic]
Figure 3-1. Process an Application
3 CCMS-BP-ELI-002 Process a Redetermination
This process defines the steps needed to complete a redetermination of eligibility for the CCAP. Two months before the end of a client’s eligibility period, a redetermination form is sent out for the client to complete. Once the completed form is received, an eligibility worker may request the client to submit additional information to process the case. This could include paystubs, grades, or other supporting documentation. Once all the required information has been received and validated, eligibility is determined and the client’s child care services are either approved for a new eligibility period or the services are cancelled.
[pic]
Figure 3-2. Process a Redetermination
4 CCMS-BP-ELI-003 Process a Change of Information
This business process documents the steps needed to change a client’s information without affecting client’s eligibility dates. Some examples of the information that may change include name changes, change of address, and the birth of a child. Once it is determined that there is a change of information, an eligibility worker may request supporting documentation to substantiate the change. Once the required information is available, eligibility is determined and the change may be approved or the case may be cancelled if the change results in discontinued eligibility.
[pic]
Figure 3-3. Process a Change of Information
5 CCMS-BP-ELI-004 Process an Application for a Shared Case
This process defines the steps for when a client with a shared case applies for the Child Care Assistance Program (CCAP). A shared case is an instance where one family’s child care assistance is managed by more than one entity. This could be two sites or a CCR&R and a site. This business process is similar to the one used to process a regular application, with approval and communication steps between the sites or R&R and site. This process documents the steps needed from the time an application form is received until the client’s program eligibility is determined. The system will generate alerts to the eligibility workers after a certain amount of time to inform them that actions are needed in the case and to cancel it if the client has not returned the required information.
[pic]
Figure 3-4. Process an Application for a Shared Case
[pic]
Figure 3-5. Process an Application for a Shared Case (Continued)
6 CCMS-BP-ELI-005 Process a Redetermination for a Shared Case
This process defines the steps needed to complete a redetermination of eligibility for the CCAP for shared cases. A shared case is an instance where one family’s child care assistance is managed by more than one entity. This could be two sites or a CCR&R and a site. Preferably, the two cases have the same eligibility dates. Prior to the end of a client’s eligibility period, a redetermination form is sent out for him/her to complete. In a shared case, this is typically the Site provider. Once the completed form is received, an eligibility worker may request the client to submit additional information to process the case. This could include paystubs, grades, or other supporting documentation. Once all the required information has been received and validated, eligibility is determined and the client’s child care services are either approved for a new eligibility period or the services are cancelled.
[pic]
Figure 3-6. Process a Redetermination for a Shared Case
7 CCMS-BP-ELI-006 Process a Change of Information (COI) for a Shared Case
This process defines the steps needed to complete a redetermination of eligibility for the CCAP for shared cases. A shared case is an instance where one family’s child care assistance is managed by more than one entity. This could be two sites or a CCR&R and a site. Preferably, the two cases have the same eligibility dates. Two months before the end of a client’s eligibility period, a redetermination form is sent out for the client to complete. In a shared case, this is typically the Site provider. Once the completed form is received, an eligibility worker may request the client to submit additional information to process the case. This could include paystubs, grades, or other supporting documentation. Once all the required information has been received and validated, eligibility is determined and the client’s child care services are either approved for a new eligibility period or the services are cancelled.
[pic]
Figure 3-7. Process a Change of Information for a Shared Case
8 CCMS-BP-ELI-007 Transfer a Shared Case
This process describes the steps undertaken in transferring a Shared Case from one site to another. The process requires communication between the CCR&Rs and the BCCD Shared Case Coordinator. CCMS generates alerts to notify the coordinator when action is necessary.
[pic]
Figure 3-8. Transfer a Shared Case
9 CCMS-BP-ELI-008 Add/Update a Provider
This process defines the steps taken to Add a provider or Update a provider’s information. It includes validating the information submitted by the provider against data contained in other systems and databases currently used by BCCD. If the information submitted is accurate and complete, then the process includes a determination of the provider’s eligibility. If the provider is eligible, then the provider file is updated in CCTS. If the Provider is not eligible, then CCMS can generate a Change of Provider Form to the Client so the client can select a suitable provider.
[pic]Figure 3-9. Add/Update a Provider
10 CCMS-BP-CS-001 Process a Customer Service Request
This process defines the steps for handling a customer service request that reaches BCCD staff. The BCCD staff receiving this request may include Customer Service staff, Payments staff, and Training staff. The customer service requests covered by this process are: Mail Control, Web Bits, Legislative Inquiries, Complaints, Policy Clarifications, SEIU Grievances, Payment Questions, and Training Requests. A client or provider contacts BCCD with request details and send relevant documents. The BCCD staff enters the information in a customer service request data entry form. Alternatively, CCR&R or Site staff with access to CCMS may assign a customer service request to BCCD staff. The BCCD staff analyzes the request and prepares a response. The research and response details are then entered into the data entry form. A response is then submitted to the requestor. This may be done outside of CCMS for requestors that do not have access to the system or through CCMS for CCR&Rs and Sites.
[pic]
Figure 3-12. Process a Customer Service Request
11 CCMS-BP-CS-002 Process a Provider Overpayment
This process defines the steps for handling a provider overpayment. An overpayment can take place when a provider payment is higher than the cost of the services rendered due to provider or administrative error. The process begins with a provider overpayment being identified by the CCR&R, Site or BCCD staff. The CCR&R or site then completes the overpayment referral form with the overpayment details and provides supporting documentation. BCCD then reviews the documentation and determines whether there was an overpayment and whether other agencies need to be notified. If there is an overpayment, an overpayment packet is completed and is sent to the provider. The provider may then give additional documentation to reduce or rescind the overpayment. Otherwise, the provider is referred to the Bureau of Collections to settle the overpayment.
[pic]
Figure 3-13. Process a Provider Overpayment
12 CCMS-BP-CS-003 Process a Client Overpayment
This process defines the steps for handling a client overpayment. An overpayment can take place when the State pays more for services rendered than the client is entitled to, based on their eligibility details. This may be due to client or administrative error. The process begins with a client overpayment being identified by the CCR&R, Site or BCCD staff. The CCR&R or site then completes the overpayment referral form with the overpayment details and provides supporting documentation. BCCD then reviews the documentation and determines whether there was an overpayment or whether other agencies need to be notified. If there is an overpayment, an overpayment packet is completed and is sent to the client. The client may then give additional documentation to reduce or rescind the overpayment. Otherwise, the client is referred to the Bureau of Collections to settle the overpayment.
[pic]
Figure 3-14. Process a Client Overpayment
13 CCMS-BP-CS-004 Process an Appeal
This section defines the steps for processing an appeal. A client may appeal eligibility decisions taken by the agency administering their CCAP case. This includes eligibility decision, co-pay amount and dates for which they are eligible for services. The process begins with a client sending a completed appeal form to the Bureau of Assistance Hearings (BAH). BAH then sends a confirmation letter and hearing schedule to BCCD and corresponding R&R or site. The R&R or site then attempts to resolve the appeal through the Pre-Appeal process. If resolved, the client may chose to withdraw the appeal otherwise, the R&R or site completes the Statement of Facts in preparation for the hearing. The hearing is then conducted and a final decision is reached. If the appeal decision is reversed, BCCD monitors the implementation of the appeal decision and completes the implementation of appeal form once the R&R or site has implemented the decision.
[pic]
Figure 3-15. Process an Appeal
14 CCMS-BP-CS-005 Process an Attendance Exemption
This section defines the steps for processing an attendance exemption. An attendance exemption process is limited to licensed center providers (policy 261) only and can be requested when an extraordinary event is responsible for substantially less than normal attendance. Examples of this include heavy snowfall and natural disasters. Once the event occurs, the provider requests and completes an attendance exemption form. BCCD staff then reviews the request for completeness and determines whether to approve it. The provider and corresponding R&R are then notified of the decision.
[pic]
Figure 3-16. Process an Attendance Exemption
15 CCMS-BP-CS-006 Process a CCR&R/Site Customer Service Request
This process defines the steps for handling a customer service request that reaches CCR&R or Site staff. A client or provider contacts the CCR&R or Site with request details and send relevant documents. CCR&R or Site staff enters the information in a customer service request data entry form. 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. The staff will then research the request and prepares a response. The research and response details are then entered into the data entry form and submitted to the requestor.
[pic]
Figure 3-17. Process a CCR&R/Site Customer Service Request
16 CCMS-BP-CS-007 Process a W9
This process defines the steps needed to process a W9 form for new providers or for providers that have not received a payment from the state of Illinois in more than two years. The provider completes the W9 form and sends it to the CCR&R. The R&R staff sends it to the Illinois Office of the Comptroller (IOC) once it is deemed to be complete. IOC staff review the W9 form and certify it or return it with changes. If there are delays or issues with the form processing, the BCCD customer service staff may also get involved to check for errors and to facilitate communication with IOC.
[pic]
Figure 3-18. Process a W9
17 CCMS-BP-PIQA-001 Schedule a Field Review
BCCD PIQA conducts Field Reviews according to a three year cycle. Once a target is selected, the PIQA Supervisor associates that review with a PIQA Monitor. CCMS generates a task for that monitor. The Monitor then selects a review period, which is typically a month in duration. The monitor reviews records associated with clients who were provided service during the review period.
In CCMS, the Monitor can generate a list of clients who were provided service during that period. CCMS can also generate a Monitoring Checklist that identifies the documents that the Monitor should review to validate that service was provided.
The necessary supporting documents should be available in CCMS. The monitor can review these documents within CCMS. If the documents are not in CCMS, then the Monitor can request that the target produce the documents during the Field Visit by generating a monitoring packet.
[pic]
Figure 3-19. Schedule a Field Review
18 CCMS-BP-PIQA-002 Conduct a Field Review
This process defines the use of CCMS to enable the review of required Provider and Client documentation. Formerly, PIQA sent the monitoring packet detailing the clients and records that the monitor expected to review. Then the provider would have to pull all of those documents so that the monitor could review them.
Now, the necessary supporting documents should be available in CCMS. The monitor can review those documents within CCMS. If the documents are not in CCMS, then the Monitor can request that the target produce the documents during the Field Visit. When they are produced, CCR&R or PIQA can scan them into the CCMS system and update the provider file.
[pic]
Figure 3-20. Conduct a Field Review
19 CCMS-BP-PIQA-003 Prepare a Final Report
This process details the steps taken in preparing a final report based on PIQA’s Field Review. CCMS facilitates this process by generating tasks and alerts to the appropriate people at the proper time so that they can either complete their own work on a timely basis, or monitor the receipt of a provider’s response.
Generally, PIQA must issue its report within 60 days of the completion of its field review. Then the provider has 30 days to respond. CCMS will issue the corresponding alerts. Findings are referred with an Overpayment Referral Form to BCCD Customer Service, or in the case of a provider that does not respond to a report, to the Sanction Process.
[pic]
Figure 3-21. Prepare a Final Report
20 CCMS-BP-PIQA-004 Process a CCR&R Suspected Program Violation
The process describes the steps a CCR&R would take when it suspects that there might be a potential intentional program violation. The CCR&R conducts a preliminary review of the documentation, and compares the information to other information it has access to, including various State of Illinois databases and some outside search sites services.
If there is no proof of a potential violation, then the CCR&R closes the file. If there is proof of a violation, then the CCR&R identifies whether the occurrence is part of a Ring or Pattern. If it is, then the CCR&R sends the file to PIQA. If it is not part of a Ring or Pattern, it sends the file to BCCD Customer Service, along with an Overpayment Referral Form, for further processing.
[pic]
Figure 3-22. Process a CCR&R Suspected Program Violation
21 CCMS-BP-PIQA-005 Process a Suspected Intentional Program Violation Referral
This process describes the steps that PIQA undertakes if it receives a file that the CCR&R has identified as part of a Ring or Pattern, or if PIQA learns of a potential intentional program violation from another source.
PIQA undertakes a preliminary investigation. It then assembles a file with documents and screen shots from various sources, scans it into CCMS, and then refers the case it to the appropriate investigative agency.
If it determines that there is a Ring or Pattern, it notifies all other CCR&Rs of the potential abusing client or provider.
[pic]
Figure 3-23. Process a Suspected Intentional Program Violation Referral
23 CCMS-BP-DOC-001 Scan/Email/Fax/Route Document
Staff receive documents via mail, in-person, email, and fax. When a document is mailed or dropped off, staff scan that document into CCMS. Documents that are emailed or faxed are sent directly to CCMS. At a high-level there are three different types of documents that may be put into CCMS:
1) A document that was generated out of CCMS and the system can automatically index.
2) A document that was generated out of CCMS as an image with no pre-populated data and the system cannot automatically index.
3) A generic document that was not generated out of CCMS and must be manually indexed by the user.
Appropriate users are alerted with tasks when documents are scanned in or sent to CCMS. Documents may also be routed to a common queue instead of a specific worker, based on how an agency’s task assignment is configured.
In addition, if a document has been sent to the incorrect agency, the document can be routed to the appropriate agency. Whether a document is scanned, emailed or faxed into CCMS, staff can then choose to route the document. In doing so, CCMS adds the document to the correct queue and an alert is generated to the appropriate individual to take action.
[pic]
Figure 3-24. Scan/Email/Fax/Route Document
Use Cases
During the General System Design phase, high-level use cases will be defined using the template shown below. The high-level use cases will be further refined and elaborated, if necessary, during the Detailed Design phase. Each use case will be uniquely numbered in order to facilitate requirements traceability.
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 accesses link to IPACS and City of Chicago to search for an existing case number. If a match is found, worker assigns |
| |case number to application. |
|2 |Worker completes calendar to include dates and times when parent is at work and/or studying, and enters GPA. |
|3 |CCMS calculates number of cases that have requested care 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. |
|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 |Return to step 2 of the Normal Flow. |
| | |
| | |
|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. |
| |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 |
| |CCTS |
|Trigger: |BCCD, CCR&R, or Site eligibility staff requests CCTS 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 |CCTS 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 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 approval, denial, or |
| | |cancellation notice. |
| |3a1.3 |Return to step 4 of Normal Flow. |
| | |
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 happens around every six 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 |CCTS determines that a redetermination is needed. |
|2 |CCMS 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. |
| |3a1.2 |CCTS cancels case if new eligibility period is not approved by the last day of month. |
| |3a1.3 |CCTS generates a cancellation notice and sends it to client. |
| |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 happens around every six 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 calendar to include dates and times when parent is at work and/or studying during new eligibility period. |
|2 |CCMS calculates number of cases that have requested care 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 |Return to step 2 of the Normal Flow. |
| | |
| | |
|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. |
| |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. |
|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 CCTS approval notice. |
|9 |Use case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|2 |2a1.1 |Shared case was deemed eligible for a site application. CCMS generates Data Entry Form in addition to |
| | |shared case documents. |
| |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 staff 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-006 Enter Data for Change of Information
| | |
|Use Case ID: |CCMS-USE-ELI-006 |
|Name: |Enter data for 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: |A client contacts CCR&R/Site about a change in information. |
|Entry Criteria/Preconditions: |A client contacts CCR&R/Site about a change in information. |
| |A client has an active case within CCAP. |
| |Eligibility worker has log in access to the CCMS system. |
|Exit Criteria/Post-Conditions: |Information available within change of information form has been entered into the system. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |A client contacts CCR&R, Site, or BCCD about a change in information. |
|2 |CCR&R/Site/BCCD staff requests change of information form from CCMS and sends it to client. |
|3 |Client completes form and sends it to CCR&R, Site, or BCCD along with supporting documentation. |
|4 |CCR&R, site, or BCCD receives the change of information. |
|5 |Change of information 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 change of information form. |
| |3a1.2 |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. |
| | |
7 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. |
|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 |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 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 |CCTS 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. |
| |
8 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 CCR&R 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 provider served by another CCR&R |
|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 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 completes and scans DEF if applicable |
|6 |Staff updates file in CCMS which alerts the BCCD Shared Case Coordinator |
|7 |CCR&R/Site reviews application |
|8 |BCCD reviews Transfer Form and DEF (if applicable) |
|9 |If they are accurate and complete, the they update the CCMS case file |
|10 |If the case is transferred, then it goes to CCTS for the Eligibility determination |
|11 |If CCTS approves Eligibility, then it generates an Approval Notice and Notifies the Client |
|12 |Use case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|10 |10a1.1 |If they 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 |
| | |
9 CCMS-USE-ELI-009 Add/Update a Provider
|Use Case ID: |CCMS–USE-ELI-009 Add a Provider |
|Name: |Add/Update a Provider |
| | |
|Description: |This Use Case describes te process by which a Provider is added, or the providers information is |
| |Updated in CCMS |
|Frequency: |When a client requests a new provider |
| | |
|Primary Actor: |BCCD and CCR&R staff |
|Secondary Actors: |Client |
|Trigger: |A client identifies a new provider |
|Entry Criteria/Preconditions: |BCCD or CCR&R staff search for the provider in CCMS |
|Exit Criteria/Post-Conditions: |The new provider is accepted or rejected |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |Staff searches CCMS for Provider file |
|2 |If the Provider already exists, then Staff determines whether the Provider has other children in care |
|3 |If not, then staff corrects or verifies that the information in the file is correct. |
|4 |CCMS creates a Validation Checklist (includes Address/DOB; CANTS,SORS, ID or SSN or FEIN, SAMS, DCFS Licensing) |
|5 |Staff Scans any associated documents into CCMS and updates the file |
|6 |If no additional information is needed, Staff determines if the Provider is eligible |
|7 |If the Provider is eligible, then the file is sent to Provider Billing for further processing |
|8 |Use case ends |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|2 |2a1.1 |If the Provider does not already exist, then Staff creates a Provider File |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|6 |6a1.1 |If additional information is needed, then staff issues an RAI |
| |6a1.2 |The Provider responds to the RAI |
| |6a1.3 |Staff validates the information and scans any additional documents |
| | |
| | |
|Exception Flow | |
| | |
|Normal Flow |Alternative Flow |Exception Flow |Action |
|Steps |Step |Step | |
|6 | |e1 |If additional information is needed, then staff issues an RAI |
| | |e2 |The Provider does not respond to the RAI and the staff issues a Denial letter |
| | |e3 |CCMS generates a Change of Provider form and staff sends it to the client |
| | |
11 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 line 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 |
|Trigger: |N/A |
|Entry Criteria/Preconditions: |N/A |
|Exit Criteria/Post-Conditions: |Application form is saved in content manager and is available to process. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |The user accesses the DHS website and selects to fill out an application form online. |
|2 |The user enters the application data, electronically signs the form, and submits the form. |
|3 |CCMS determines the document is an application form. |
|4 |CCMS extracts the data. |
|5 |CCMS indexes the form. |
|6 |CCMS adds the form to a new or existing electronic file. |
|7 |CCMS stores the form in content manager. |
|8 |CCMS generates a task and assigns to the appropriate user, if necessary. |
|9 |Use case ends. |
| | |
12 CCMS-USE-CS-001 Process a Customer Service Request
| | |
|Use Case ID: |CCMS-USE-CS-001 |
|Name: |Process a Customer Service Request |
| | |
|Description: |A client or provider contacts BCCD with customer service request details and send relevant |
| |documents. BCCD enters the information in a customer service request data entry form. Alternatively,|
| |CCR&R or Site staff with access to CCMS may assign a customer service request to BCCD staff. The |
| |staff then researches the request and prepares a response. The staff enters the research and |
| |response details into the data entry form. The response is then submitted to the requestor. |
|Frequency: |# of Mail Control requests created per week |
| |# of Web Bits created per week |
| |# of Legislative Inquiries created per week |
| |# of Complaints created per week |
| |# of Policy Clarifications created per week |
| |# of SEIU Grievances created per week |
| |# of Payment Questions created per week |
| |# of Training Requests created per week |
| | |
|Primary Actor: |BCCD customer service, payment, and training staff |
|Secondary Actors: |CCMS |
|Trigger: |Client/Provider puts in customer service request via mail, fax, call, or email. |
| |CCR&R or site staff creates a customer service request and assigns it to BCCD customer service, |
| |payment, or training staff. |
|Entry Criteria/Preconditions: |BCCD staff has access to CCMS. |
| |CCR&R/site staff has access to CCMS. |
|Exit Criteria/Post-Conditions: |Response is sent to requestor and customer service data entry form is updated in CCMS. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |Client/Provider puts in customer service request to BCCD via mail, fax, call, or email. |
|2 |BCCD 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 |CCMS generates a customer service data entry form. |
|5 |BCCD staff enters request details into data entry form. |
|6 |BCCD staff performs research for request. |
|7 |BCCD staff prepares response for requestor. |
|8 |BCCD staff scans related documents into CCMS, updates data entry form, and closes request. |
|9 |BCCD staff sends response to requestor. |
|10 |Use case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|1 |1a1.1 |CCR&R/Site assigns Customer Service Request to BCCD Staff. |
| |1a1.2 |BCCD staff receives an alert that a customer service request has been assigned to them. |
| |1a1.3 |Return to step 6 of normal flow. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|8 |8a1.1 |BCCD staff takes more than agency defined number of days to respond to request. |
| |8a1.2 |CCMS generates alert to remind BCCD staff that request is still open. |
| |8a1.3 |Return to step 8 in the normal flow. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|9 |9a1.1 |CCR&R/Site originally assigned request to BCCD staff. Requestor receives alert that their request has |
| | |been closed. |
| |9a1.2 |Use case ends. |
| | |
13 CCMS-USE-CS-002 Process a Provider Overpayment
| | |
|Use Case ID: |CCMS-USE-CS-002 |
|Name: |Process a Provider Overpayment |
| | |
|Description: |A provider overpayment can take place when a provider payment is higher than the cost of the |
| |services rendered due to provider or administrative error. The process begins with a provider |
| |overpayment being identified by the CCR&R, Site or BCCD staff. The CCR&R or site then completes the |
| |overpayment referral form with the overpayment details and provides supporting documentation. BCCD |
| |then reviews the documentation and determines whether there was an overpayment or whether other |
| |agencies need to be notified. If there is an overpayment, an overpayment packet is completed and is |
| |sent to the provider. The provider may then give additional documentation to reduce or rescind the |
| |overpayment. Otherwise, the provider is referred to the Bureau of Collections to settle the |
| |overpayment. |
|Frequency: |# of provider overpayment referrals per week |
| | |
|Primary Actor: |BCCD Customer Service Staff |
|Secondary Actors: |CCMS |
| |CCR&R or Site staff |
| |Provider |
| |BCCD Customer Service supervisor |
|Trigger: |A CCR&R, site or BCCD identifies there has been a potential provider overpayment. |
|Entry Criteria/Preconditions: |N/A |
|Exit Criteria/Post-Conditions: |The overpayment is confirmed, rescinded, reduced, or denied. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |CCR&R or site staff identifies a potential provider overpayment. |
|2 |CCR&R or site staff requests an Overpayment Referral form from CCMS. |
|3 |CCMS generates Overpayment Referral form. |
|4 |CCR&R or site staff completes Overpayment Referral. |
|5 |CCR&R or site staff scans in supporting documents into CCMS. Refer to CCMS-USE-DOC-001 use case. |
|6 |CCMS updates provider file and flags it as an Overpayment file. |
|7 |CCMS generates an alert to BCCD customer service staff. Refer to Generate an Alert use case. |
|8 |CCMS generates overpayment checklist and overpayment packet (calculation sheet, provider letter, request to establish |
| |accounts receivable). |
|9 |BCCD customer service staff reviews referral and determines that there was an overpayment. |
|10 |BCCD customer service staff completes referral packet documents and marks existing CCMS documents that should be added to the|
| |packet. |
|11 |CCMS sends alert to supervisor to review overpayment packet. |
|12 |Supervisor reviews and signs off on packet. |
|13 |CCMS generates alert to BCCD customer service and CCR&R/Site staff that overpayment has been approved. |
|14 |BCCD customer service staff sends overpayment packet to provider and to Bureau of Collections. |
|15 |Staff have the option of creating a provider sanction with the appropriate sanction level, if needed. |
|16 |The Use Case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|9 |9a1.1 |BCCD customer service staff reviews referral and determines that there was no overpayment. |
| |9a1.2 |BCCD customer service staff clears overpayment flag to the provider file. |
| |9a1.3 |CCMS generates an alert to CCR&R\Site that overpayment referral was denied. |
| |9a1.4 |Return to step 15 of Normal Flow. |
|9 |9a2.1 |BCCD customer service staff determines that additional information is needed to process overpayment. |
| |9a2.2 |CCMS generates an alert to CCR&R/Site that additional information is needed. |
| |9a2.3 |If no update in 10 business days, CCMS generates an alert to CCR&R/site to act on overpayment. |
| |9a2.4 |CCR&R/Site staff compiles additional information needed and scan it into CCMS. Refer to CCMS-USE-DOC-001 |
| | |use case. |
| |9a2.5 |Return to step 6 in Normal Flow. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|10 |10a1.1 |BCCD customer service staff determines overpayment should be referred to Bureau of Investigations. |
| |10a1.2 |BCCD customer service staff sends referral documents to Bureau of Investigations. |
| |10a1.3 |Bureau of Investigations reviews documents and sends Decision Letter to BCCD. |
| |10a1.4 |BCCD receives decision letter and scans it into CCMS. Refer to use case CCMS-USE-DOC-001. |
| |10a1.5 |Bureau of Investigations decided to uphold overpayment. CCMS generates alert for CCR&R/Site for |
| | |overpayment approval. |
| |10a1.6 |Use case ends. |
|10 |10a2.1 |BCCD customer service staff determines overpayment should be referred to Bureau of Investigations. |
| |10a2.2 |BCCD customer service staff sends referral documents to Bureau of Investigations. |
| |10a2.3 |Bureau of Investigations reviews documents and sends Decision Letter to BCCD. |
| |10a2.4 |BCCD receives decision letter and scans it into CCMS. Refer to use case CCMS-USE-DOC-001. |
| |10a2.5 |Bureau of Investigations decided to rescind overpayment. BCCD customer service staff clears overpayment |
| | |flag to the provider file. |
| |10a2.6 |CCMS generates an alert to CCR&R\Site that overpayment referral was denied. |
| |10a2.7 |Return to step 15 of Normal Flow. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|16 |16a1.1 |Provider sends documentation to rescind overpayment. |
| |16a1.2 |BCCD customer service staff receives documentation and scans it into CCMS. Refer to use case |
| | |CCMS-USE-DOC-001. |
| |16a1.3 |BCCD determines that overpayment should be rescinded. BCCD customer service staff clears overpayment flag|
| | |to the provider file. |
| |16a1.4 |CCMS generates an alert to CCR&R\Site that overpayment referral was denied. |
| |16a1.5 |Return to step 16 of the Normal Flow. |
|16 |16a2.1 |Provider sends documentation to modify overpayment and requests an overpayment modification letter from |
| | |CCMS. |
| |16a2.2 |CCMS generates overpayment modification letter and generates an alert for CCR&R or Site. |
| |16a2.3 |Return to step 16 of the Normal Flow. |
|16 |16a3.1 |Provider sends documentation to modify or rescind overpayment. |
| |16a3.2 |BCCD customer service staff receives documentation and scans it into CCMS. Refer to use case |
| | |CCMS-USE-DOC-001. |
| |16a3.3 |BCCD determines that overpayment should not be modified. |
| |16a3.4 |Return to step 16 of the Normal Flow. |
14 CCMS-USE-CS-003 Process a Client Overpayment
| | |
|Use Case ID: |CCMS-USE-CS-003 |
|Name: |Process a Client Overpayment |
| | |
|Description: |A client overpayment can take place when the amount paid for child care services for a client is |
| |higher than the amount that client is entitled to based on the client’s eligibility details due to |
| |provider or administrative error. The process begins with a client overpayment being identified by |
| |the CCR&R, Site or BCCD staff. The CCR&R or site then completes the overpayment referral form with |
| |the overpayment details and provides supporting documentation. BCCD then reviews the documentation |
| |and determines whether there was an overpayment or whether other agencies need to be notified. If |
| |there is an overpayment, an overpayment packet is completed and is sent to the client. The client |
| |may then give additional documentation to reduce or rescind the overpayment. Otherwise, the client |
| |is referred to the Bureau of Collections to settle the overpayment. |
|Frequency: |# of provider overpayment referrals per week |
| | |
|Primary Actor: |BCCD Customer Service Staff |
|Secondary Actors: |CCMS |
| |CCR&R or Site staff |
| |Client |
| |BCCD Customer Service supervisor |
|Trigger: |A CCR&R, site or BCCD identifies there has been a potential provider overpayment. |
|Entry Criteria/Preconditions: |N/A |
|Exit Criteria/Post-Conditions: |The overpayment is confirmed, rescinded, reduced, or denied. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |CCR&R or site staff identifies a potential client overpayment. |
|2 |CCR&R or site staff requests an Overpayment Referral form from CCMS. |
|3 |CCMS generates Overpayment Referral form. |
|4 |CCR&R or site staff completes Overpayment Referral. |
|5 |CCR&R or site staff scans in supporting documents into CCMS. Refer to use case. |
|6 |CCMS updates case file and flags it as an Overpayment file. |
|7 |CCMS generates an alert to BCCD customer service staff. Refer to Generate an Alert use case. |
|8 |CCMS generates overpayment checklist and overpayment packet (calculation sheet, client letter, request to establish accounts |
| |receivable). |
|9 |BCCD customer service staff reviews referral and determines that there was an overpayment. |
|10 |BCCD customer service staff completes referral packet documents and marks existing CCMS documents that should be added to the|
| |packet. |
|11 |CCMS sends alert to supervisor to review overpayment packet. |
|12 |Supervisor reviews and signs off on packet. |
|13 |CCMS generates alert to BCCD customer service and CCR&R/Site staff that overpayment has been approved. |
|14 |BCCD customer service staff sends overpayment packet to client and to Bureau of Collections. |
|15 |The Use Case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|9 |9a1.1 |BCCD customer service staff reviews referral and determines that there was no overpayment. |
| |9a1.2 |BCCD customer service staff clears overpayment flag to the case file. |
| |9a1.3 |CCMS generates an alert to CCR&R\Site that overpayment referral was denied. |
| |9a1.4 |Return to step 15 of Normal Flow. |
|9 |9a2.1 |BCCD customer service staff determines that additional information is needed to process overpayment. |
| |9a2.2 |CCMS generates an alert to CCR&R/Site that additional information is needed. |
| |9a2.3 |If no update in 10 business days, CCMS generates an alert to CCR&R/site to act on overpayment. |
| |9a2.4 |CCR&R/Site staff compiles additional information needed and scans it into CCMS. Refer to use case |
| | |CCMS-USE-DOC-001. |
| |9a2.5 |Return to step 6 in Normal Flow. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|10 |10a1.1 |BCCD customer service staff determines overpayment should be referred to Bureau of Investigations. |
| |10a1.2 |BCCD customer service staff sends referral documents to Bureau of Investigations. |
| |10a1.3 |Bureau of Investigations reviews documents and sends Decision Letter to BCCD. |
| |10a1.4 |BCCD receives decision letter and scans it into CCMS. Refer to use case CCMS-USE-DOC-001. |
| |10a1.5 |Bureau of Investigations decided to uphold overpayment. CCMS generates alert for CCR&R/Site for |
| | |overpayment approval. |
| |10a1.6 |Use case ends. |
|10 |10a2.1 |BCCD customer service staff determines overpayment should be referred to Bureau of Investigations. |
| |10a2.2 |BCCD customer service staff sends referral documents to Bureau of Investigations. |
| |10a2.3 |Bureau of Investigations reviews documents and sends Decision Letter to BCCD. |
| |10a2.4 |BCCD receives decision letter and scans it into CCMS. Refer to use case CCMS-USE-DOC-001. |
| |10a2.5 |Bureau of Investigations decided to rescind overpayment. BCCD customer service staff clears overpayment |
| | |flag to the case file. |
| |10a2.6 |CCMS generates an alert to CCR&R\Site that overpayment referral was denied. |
| |10a2.7 |Return to step 15 of Normal Flow. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|15 |15a1.1 |Client sends documentation to rescind overpayment. |
| |15a1.2 |BCCD customer service staff receives documentation and scans it into CCMS. Refer to use case |
| | |CCMS-USE-DOC-001. |
| |15a1.3 |BCCD determines that overpayment should be rescinded. BCCD customer service staff clears overpayment flag|
| | |to the case file. |
| |15a1.4 |CCMS generates an alert to CCR&R\Site that overpayment referral was denied. |
| |15a1.5 |Return to step 15 of the Normal Flow. |
|15 |15a2.1 |Client sends documentation to modify overpayment and requests an overpayment modification letter from |
| | |CCMS. |
| |15a2.2 |CCMS generates overpayment modification letter and generates an alert for CCR&R or Site. |
| |15a2.3 |Return to step 15 of the Normal Flow. |
|15 |15a3.1 |Client sends documentation to modify or rescind overpayment. |
| |15a3.2 |BCCD customer service staff receives documentation and scans it into CCMS. Refer to use case |
| | |CCMS-USE-DOC-001. |
| |15a3.3 |BCCD determines that overpayment should not be modified. |
| |15a3.4 |Return to step 15 of the Normal Flow. |
| | |
15 CCMS-USE-CS-004 Process an Appeal
| | |
|Use Case ID: |CCMS-USE-CS-004 |
|Name: |Process an Appeal |
| | |
|Description: |A client may appeal eligibility decisions taken by the agency administering their CCAP case. This |
| |includes eligibility decision, co-pay amount and dates for which they are eligible for services. |
| |The process begins with a client sending a completed appeal form to the Bureau of Assistance |
| |Hearings (BAH). BAH then sends a confirmation letter and hearing schedule to BCCD and corresponding |
| |R&R or site. The R&R or site then attempts to resolve the appeal through the Pre-Appeal process. If |
| |resolved, the client may chose to withdraw the appeal, otherwise, the R&R or site completes the |
| |Statement of Facts in preparation for the hearing. The hearing is then conducted and a final |
| |decision is reached. If the appeal decision is reversed, BCCD monitors the implementation of the |
| |appeal decision and completes the implementation of appeal form once the R&R or site has implemented|
| |the decision. |
|Frequency: |Number of appeals per year |
| | |
|Primary Actor: |BCCD Customer Service Staff |
|Secondary Actors: |CCMS |
| |Client |
| |CCR&R/Site |
|Trigger: |BCCD and CCR&R/Site receive appeal notification and trip sheet from Bureau of Assistance Hearings |
| |(BAH). |
|Entry Criteria/Preconditions: |The User has logged into the CCMS. |
| |The Client has submitted an Appeal Request to BAH. |
| |The Client has received an appeal request confirmation letter from BAH. |
|Exit Criteria/Post-Conditions: |Appeal is implemented, upheld, or withdrawn by Client. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |The Client sends appeal form to BAH. |
|2 |BAH receives form and mails Client, BCCD, and CCR&R/Site an appeal request confirmation letter. BAH also mails trip sheet to |
| |BCCD and CCR&R/Site. |
|3 |BCCD receives appeal notification form and trip sheet and scans it into CCMS. Refer to scanning use case for additional |
| |details. |
|4 |CCMS generates an alert to CCR&R/Site serving the client and generates the Statement of Fact form. |
|5 |CCR&R or Site performs the Pre-Appeal Process with the Client. |
|6 |The Client chooses to not withdraw the appeal. CCR&R or Site completes the Statement of Fact form. |
|7 |BCCD sends the completed Statement of Fact form to Client and BAH. |
|8 |BCCD and client attend hearing. BAH decides to uphold appeal and mails final decision form with hearing decision. |
|9 |BCCD receives final decision form and scans it into CCMS. Refer to use case CCMS-USE-DOC-001 for additional details. |
|10 |CCMS generates an alert to the CCR&R or Site. |
|11 |The Use Case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|6 |6a1.1 |The Client decides to withdraw appeal. |
| |6a1.2 |The CCR&R or Site requests the Appeal Withdrawal form |
| |6a1.3 |CCMS generates the Appeal Withdrawal form and generates an alert to BCCD Appeals Coordination |
| |6a1.4 |Return to step 11 in the Normal Flow. |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|8 |8a1.1 |BCCD and client attend hearing. BAH decides to reverse appeal and mails final decision form with hearing |
| | |decision. |
|9 |9a1.1 |BCCD receives final decision form and scans it into CCMS. Refer to use case CCMS-USE-DOC-001 for |
| | |additional details. |
|10 |10a1.1 |CCMS generates an alert to the CCR&R or Site. |
| |10a1.2 |CCMS generates Implementation of Appeal Decision form. |
| |10a1.3 |BCCD contacts CCR&R or Site about appeal implementation. |
| |10a1.4 |Once appeal decision is implemented, BCCD completes the Implementation of Appeal Decision form and mails |
| | |form to BAH. |
| |10a1.5 |Return to step 11 in the Normal Flow. |
| | |
16 CCMS-USE-CS-005 Process an Attendance Exemption
| | |
|Use Case ID: |CCMS-USE-CS-005 |
|Name: |Process an Attendance Exemption |
| | |
|Description: |An attendance exemption process is limited to licensed center providers (as defined in policy 261) |
| |and can be requested when an extraordinary event is responsible for substantially less than normal |
| |attendance. Examples of this include heavy snowfall and natural disasters. Once the event occurs, |
| |the provider requests and completes an attendance exemption form. BCCD staff then reviews the |
| |request for completeness and determines whether to approve it. The provider and corresponding R&R |
| |are then notified of the decision. |
|Frequency: |Number of attendance exemptions per year |
| | |
|Primary Actor: |BCCD |
|Secondary Actors: |CCMS |
|Trigger: |A provider sends a completed Attendance Exemption form to BCCD. |
|Entry Criteria/Preconditions: |The provider applying for the exemption is a licensed center (as defined in policy 261). |
| |An extraordinary event is responsible for substantially less than normal attendance. |
| |Provider contacts BCCD within 5 business days of event occurring. |
|Exit Criteria/Post-Conditions: |An attendance exemption is approved or denied. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |Provider contacts BCCD about attendance exemption within 5 business days of extraordinary event resulted in substantially lower|
| |attendance than normal. |
|2 |BCCD directs provider to get Attendance Exemption form from DHS website or generates form from CCMS. |
|3 |Provider completes attendance exemption form and sends it to BCCD along with supporting documentation. |
|4 |BCCD scans form and supporting documentation. Refer to use case CCMS-USE-DOC-001 for additional details. |
|5 |CCMS generates an alert to CCR&R or site associated with provider. |
|6 |BCCD reviews the documentation for completeness and deems it complete. |
|7 |BCCD approves exemption form and scans it into CCMS. Refer to use case CCMS-USE-DOC-001 for additional details. |
|8 |BCCD sends approved form to provider. |
|9 |CCMS generates an alert for CCR&R or site with decision. |
|10 |Provider sends exemption approval for with billing form to CCR&R or Contracts/Payments. |
|11 |Use Case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|6 |6a1.1 |BCCD reviews the documentation for completeness and deems it incomplete. |
| |6a1.2 |BCCD contacts provider. |
| |6a1.3 |Return to step 3 of Normal Flow. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|7 |7a1.1 |BCCD denies exemption form and scans it into CCMS. Refer to use case CCMS-USE-DOC-001 for additional |
| | |details. |
|8 |8a1.1 |BCCD sends denied form to provider. |
|9 |9a1.1 |CCMS generates an alert for CCR&R or site with decision. |
| |9a1.2 |Return to step 11 of Normal Flow. |
| | |
17 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 |CCMS generates a customer service data entry form. |
|5 |CCR&R/Site staff enters request details into data entry form. |
|6 |CCR&R/Site staff performs research for request. |
|7 |CCR&R/Site staff prepares response for requestor. |
|8 |CCR&R/Site staff scans related documents into CCMS, updates data entry form, and closes request. |
|9 |CCR&R/Site staff sends response to requestor. |
|10 |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. |
| | |
18 CCMS-USE-CS-007 Process a W9 Form
| | |
|Use Case ID: |CCMS-USE-CS-007 |
|Name: |Process a W-9 |
| | |
|Description: |This process defines the steps needed to process a W9 form for new providers or for providers that |
| |have not received a payment from the state of Illinois in more than two years. The provider |
| |completes the W9 form and sends it to the CCR&R. The R&R staff sends it to the Illinois Office of |
| |the Comptroller (IOC) once it is deemed to be complete. IOC staff review the W9 form and certify it |
| |or return it with changes. If there are delays or issues with the form processing, the BCCD customer|
| |service staff may also get involved to check for errors and to facilitate communication with IOC. |
|Frequency: |# of new providers |
| |# of providers who have not been paid in two years |
| | |
|Primary Actor: |CCR&R, BCCD Contracts staff |
|Secondary Actors: |CCMS |
|Trigger: |Provider needs to be certified with a W_( to receive payments from the Comptroller |
|Entry Criteria/Preconditions: |Provider applies to CCAP to deliver services |
|Exit Criteria/Post-Conditions: |W9 is certified by IOC or client needs to change provider. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |CCMS provides link to IRS site which has downloadable W-9 form |
|2 |The CCR&R downloads the form and mails it to the Provider |
|3 |The provider completes the form and mails it back to the CCR&R |
|4 |The CCR&R scans the W-9 into CCMS |
|5 |The CCR&R reviews for completeness; if it is complete, it mails the form to the Comptroller |
|6 |The CCR&R updates the provider’ file in CCMS and in CCTS with date CCR&R sent W-9 to the Comptroller |
|7 |If the Comptroller approves the W-9, then it Updates SAMS, which updates CCTS |
|8 |CCTS updates CCMS |
|9 |CCMS updates generates an alert to the CCR&R that the provider has been certified |
|10 |Use case ends |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|4 |4a1.1 |If the form is not complete, the CCR&R directs the provider back to the IRS site to complete another W-9 |
| | |accurately |
| |4a1.2 |If the provider returns the form within ten days, the CCR&R scans it into CCMS and returns to Step 5 of |
| | |the Normal Flow. |
| | |
| | |
|Exception Flow | |
| | |
|Normal Flow |Alternative Flow |Exception Flow |Action |
|Steps |Step |Step | |
|4 |2 |4.2.e1 |If the Provider does not return the W-9 within ten days, then CCMS generates an alert to|
| | | |CCR&R staff |
| | |4.2.e.2 |CCR&R staff sends a W-9 notice to the provider |
| | |4.2.e.3 |If the provider does return the W-9 within ten days, then the CCR&R staff returns to |
| | | |Normal Process flow step 5 |
| | |4.2.e.4 |If the Provider still does not return the W-9, CCMS sends another alert and second |
| | | |notice |
| | |4.2.e.5 |If the Provider does not return the W-9 after the second notice, then the CCR&R |
| | | |generates a Provider Closeout Form and mails it the provider |
| | |4.2.e.6 |CCR&R staff also has CCMS send a Change of Provider form and mails it to the parent |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|6 |6.a.1.1 |In two weeks, the CCR&R checks status of W-9 Process in CCTS |
| |6.a.1.2 |IF the W-9 is not processed, then it sets an alert to itself and to BCCD to check again in 21 days |
| |6.a.1.3 |If in 21 days, the Comptroller still as not processed the W-9, then BCCD calls for status |
| |6.a.1.4 |If the W-9 has been approved, then return to Normal Flow step 7 above |
| |6.a.1.5 |If the W-9 has not been approved, then turn to Alternative Flow Step 8 |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|8 |8.a.1.1 |If the Comptroller does not approve the W-9, then it mails a copy of the disapproved W-9 to BCCD |
| |8.a 1.2 |It updates SAMS, which updates CCTS, which updates CCMS |
| |8.a.1.3 |BCCD scans the failed W-9 into CCMS and generates an alert to CCR&R that the W-9 was not approved and |
| | |indicates deficiencies |
| |8.a.1.4 |The CCR&R returns to Step 2 of the Normal Process Flow |
| | |
19 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. |
|Exit Criteria/Post-Conditions: |A Field review is scheduled. |
| |A Field Monitoring Packet is generated. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |PIQA Supervisor logs into CCMS |
|2 |PIQA Supervisor selects provider that will be field reviewed |
|3 |PIQA Supervisor assigns a PIQA Field Monitor the task of conducting a field review of that Provider |
|4 |The PIQA Field Monitor selects the review period |
|5 |The PIQA Field Monitor selects the clients to review |
|6 |CCMS generates a Child List by Provider by Period |
|7 |PIQA Field Monitor contacts Provider to schedule a field review |
|8 |PIQA Field Monitor requests CCMS to generate a Monitoring Checklist |
|9 |PIQA Field monitor sends (via mail/email/fax) a Field Monitoring Packet |
|10 |Use case ends. |
| | |
20 CCMS-USE-PIQA-002 Conduct Field Review
| | |
|Use Case ID: |CCMS-USE-PIQA-002 |
|Name: |Conduct a Field Review |
| | |
|Description: |This use case describes the process of using CCMS to enable the review of required Provider and |
| |Client documentation in CCMS and updating the CCMS Provider file with additional documents not |
| |already captured in the CCMS Provider file. |
|Frequency: |The PIQA Field Monitor would be conducting field reviews on a weekly basis. The full month prior to |
| |the month the review is scheduled is usually identified as the review period. |
| | |
|Primary Actor: |DH PIQA Field Monitor |
|Secondary Actors: |CCAP Providers |
|Trigger: |The Field Review is scheduled |
|Entry Criteria/Preconditions: |PIQA Field Monitor has identified the target period and clients, has scheduled a Field Review and |
| |has generated the Checklists and Monitoring Packet. |
| |CCMS BCCD will develop detailed processes for: |
| |The timing of CCMS Provider document review and |
| |The procedures and actors of any additional scanning required if new documents are found during the |
| |monitoring process. |
|Exit Criteria/Post-Conditions: |The CCMS Provider File is updated with any new records found during the field review. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |PIQA Field Monitor reviews the Provider’s CCMS Document Files |
|2 |PIQA Field Monitor reviews the Provider’s CCMS Client Document Files |
|3 |PIQA Field Monitor conducts entrance conference at Provider’s site |
|4 |PIQA Field Monitor conducts field review at Provider’s site |
|5 |PIQA Field Monitor identifies any documents that Provider has that are not part of Provider’s CCMS Provider file |
|6 |PIQA Field Monitor identifies any documents that Provider has that are not part of Provider’s CCMS Provider’s Client files |
|7 |PIQA Field Monitor/Provider staff scan any additional required documents found at Provider site |
|8 |PIQA Field Monitor updates Provider’s file |
|9 |Use case ends |
| | |
21 CCMS-USE-PIQA-003 Prepare a Final Report
| | |
|Use Case ID: |CCMS-USE-PIQA-001 |
|Name: |Prepare a Final Report |
| | |
|Description: |This use case describes the process of preparing, approving, and issuing a Final report based on the|
| |findings of the Field Review process. It also encompasses the Provider’s response and follow up |
| |actions necessitated by the report findings, if any, such as a referral to the overpayment or |
| |sanction process. |
| |PIQA currently uses an Excel form to provide the framework of the report. |
|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: |PIQA has conducted a field review |
|Entry Criteria/Preconditions: |The updating of the Provider file in CCMS |
| |The completion of a field review |
|Exit Criteria/Post-Conditions: |A disposition of the report by referral to |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |PIQA Field Monitor generates a report packet. |
|2 |CCMS generates an alert to be issued in 45 days to Field Monitor and PIQA Supervisor that report must be completed in 15 |
| |more days (total 60 days) |
|3 |CCMS generates a Task for the PIQA Supervisor to review the report. |
|4 |The PIQA Supervisor reviews the report. |
|5 |The PIQA Supervisor approves the report. |
|6 |PIQA sends the report to the Provider. |
|7 |CCMS generates an alert to be issued in 20 days to Field Monitor and PIQA Supervisor that the Provider’s response is due in |
| |10 more days (total 30 days) |
|8 |PIQA receives Provider’s response that indicates that there is a Overpayment |
|9 |The Provider response includes a repayment plan |
|10 |The Field Monitor completes an Overpayment Referral Form |
|11 |CCMS generates a Task for Customer Service to process and Overpayment Referral Form |
|12 |Use case ends |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|5 |5a1.1 |The PIQA Supervisor does not approve the report |
| |5a1.2 |The PIQA Supervisor returns the report back to the Filed Monitor |
| |5a1.3 |CCMS generates a task for the Filed Monitor to revise the report |
| |5a1.4 |The Field Monitor revises the report |
| |5a1.5 |The Field Monitor returns the report back to the PIQA Supervisor |
| |5a1.6 |CCMS generates a task for the PIQA Supervisor to review the report |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|6 |6a1.1 |If the Report requires no response from Provider then CCMS issues a Final Letter closing out Field Review.|
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|8 |8a1.1 |The Provider’s response indicates the need for an additional Field review |
| |8a1.2 |The Field Monitor reverts to the Scheduling a Field Visit process |
| | |
| | |
|Exception Flow | |
| | |
|Normal Flow |Alternative Flow |Exception Flow |Action |
|Steps |Step |Step | |
|8 |N/A |8e1 |If the Provider fails to respond within 30 days, then CCMS issues a non compliance |
| | | |letter |
| | |8e2 |CCMS issues an alert to PIQA Supervisor and Field Monitor that the Provider’s Response |
| | | |is due within 10 days |
| | |8e3 |If the Provider responds to the letter, then the process reverts to step fails to 8 |
| | |8e4 |If the Provider fails to respond to the non compliance letter, then the Provider is |
| | | |Sanctioned with the appropriate level |
| | |
22 CCMS-USE-PIQA-004 Process a CCR&R Program Violation Referral
| | |
|Use Case ID: |CCMS-USE-PIQA-004 |
|Name: |Process a CCR&R Program Violation Referral |
| | |
|Description: |This use case describes the process of the CCR&R suspects a Program Violation while services are |
| |being provided. The violator might be either a Provider or a Client. Such a violation typically |
| |results in an Overpayment. |
| |The Discovery of a Program Violation might occur during the client application process. In this |
| |case, the end result is that the Application is denies, unless the CCR&R staff suspects that the |
| |violator is part of a “pattern” or “ring,” in which case, the CCR&R staff refers the case to BCCD |
| |PIQA for further investigation and disposition. |
|Frequency: |Number of potential program violation referrals |
| | |
|Primary Actor: |CCR&R staff |
|Secondary Actors: |BCCD PIQA, BCCD Customer Service |
|Trigger: |The CCR&R learns that a Provider or a Client might be violating program policies |
|Entry Criteria/Preconditions: |CCR&R suspect there is a potential program violation. |
|Exit Criteria/Post-Conditions: |The Completion of an Overpayment Referral Form |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |The CCR&R Staff suspects a possible program violation by either a Provider or a Client |
|2 |The CCR&R staff reviews documents associated with the Provider and/or Client in CCMS |
|3 |The CCR&R staff checks other data sources to validate Provider or Client information |
|4 |The CCR&R staff determines that there is a potential Program Violation |
|5 |The CCR&R staff collects and scans into CCMS screen shots and other appropriate documentation |
|6 |The CCR&R staff issues a Cancellation Notice |
|7 |The CCR&R Staff completes an Overpayment Referral Form |
|8 |CCMS generates a Task for BCCD Customer Service to process and Overpayment Referral Form |
|9 |Use case ends |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|6 |6a1.1 |The CCR&R staff reviews additional data to determine whether the violator might be part of a pattern or a |
| | |ring |
| |6a1.2 |If it is part of a ring, the CCR&R enters a comment into the CCMS case file |
| |6a1.3 |The CCR&R staff sends the case file to BCCD PIQA for the PIQA referral process |
| |6a1.4 |CCMS generates a Task for the PIQA Supervisor to Process the file |
| | |
23 CCMS-USE-PIQA-005 Process a PIQA Program Violation Referral
| | |
|Use Case ID: |CCMS-USE-PIQA-005 |
|Name: |Process a PIQA Program Violation Referral |
| | |
|Description: |This process describes the steps that PIQA undertakes if it receives a file that the CCR&R has |
| |identified as part of a Ring or Pattern, or if PIQA learns of a potential intentional program |
| |violation from another source. |
| |PIQA undertakes a preliminary investigation. It then assembles a file with documents and screen |
| |shots from various sources, scans it into CCMS, and then refers the case it to the appropriate |
| |investigative agency. |
| |If it determines that there is a Ring or Pattern, it notifies all other CCR&Rs of the potential |
| |abusing client or provider |
|Frequency: |Number of PIQA program violation referrals |
| | |
|Primary Actor: |BCCD PIQA |
|Secondary Actors: |CCR&Rs, Outside Investigative Agencies |
|Trigger: |BCCD PIQA receives a Program Violation Referral from a CCR&R |
|Entry Criteria/Preconditions: |The referral of a file from a CCR&S |
|Exit Criteria/Post-Conditions: |The matter is referred to a outside agency for further investigation and disposition |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |The PIQA Supervisor receives a Task from CCMS that a CCR&R has referred a file to him for review |
|2 |The PIQA Supervisor accesses the identified referral file and researches the violation |
|3 |The PIQA Supervisor determines that there is a Program Violation |
|4 |The PIQA Supervisor Flags the file as an Investigation File which limits access to pre defined Security Roles |
|5 |The PIQA Supervisor collects the appropriate documents and scans them into a Referral File |
|6 |The PIQA Supervisor determines that the suspected program violator is a State Employee |
|7 |The PIQA Supervisor sends (mail/email/fax) the file matter to the Executive Inspector General |
|8 |The PIQA Supervisor creates an alert in CCMS to monitor the case in 180 days |
|9 |Use case ends |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|2 |2a1.1 |The PIQA Supervisor requests additional information from the CCR&R |
| |2a1.2 |CCMS generates a task to the CCR&R |
| |2a1.3 |The CR&R scans any additional documentation into CCMS and updates the case notes |
| |2a1.4 |CCMS generates a task to the PIQA Supervisor |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|3 |3a1.1 |The PIQA Supervisor determines that there is no violation |
| |3a1.2 |The PIQA Supervisor enters a case note into the CCMS File |
| |3a1.3 |CCMS notifies the CCR&R that the Case File was updated |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow |Action |
|Steps |Step | |
|6 |6a1.1 |The PIQA Supervisor determines that the suspected violator is not a state employee |
| |6a1.2 |The PIQA Supervisor sends (mail/email/fax) the file matter to the DHFS Bureau of Inspections or other |
| | |appropriate investigative agency |
| |6a1.3 |The PIQA Supervisor creates an alert in CCMS to monitor the case in 180 days |
| | |
24 CCMS-USE-DOC-001 Scan Document
| | |
|Use Case ID: |CCMS-USE-DOC-001 |
|Name: |Scan Document |
| | |
|Description: |This use case describes the process for when any document is scanned into the system. At a |
| |high-level there are three different types of documents to scan: 1) A document that was generated |
| |out of CCMS and the system can automatically index, 2) A document that was generated out of CCMS as |
| |an image with no pre-populated data and the system cannot automatically index, and 3) A generic |
| |document that was not generated out of CCMS and must be manually indexed by the user. |
|Frequency: |# of documents mailed or dropped off. |
| | |
|Primary Actor: |BCCD/ R&R/ Site Staff |
|Secondary Actors: |CCMS |
|Trigger: |Staff person has a document to scan into the system. |
|Entry Criteria/Preconditions: |N/A |
|Exit Criteria/Post-Conditions: |Document is stored in content manager. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |The user scans a document into CCMS. |
|2 |CCMS determines the document is a CCMS-generated document. |
|3 |CCMS determines whether it is a data extraction form or an image. |
|4 |CCMS identifies it is a data extraction form and attempts to extract the data. |
|5 |CCMS successfully extracts enough data to index the form. |
|6 |CCMS adds the form to a new or existing electronic file. |
|7 |CCMS stores the form in content manager. |
|8 |CCMS determines if a task needs to be generated based on the document type. |
|9 |CCMS generates a task and assigns to the appropriate user, if necessary. |
|10 |Use case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|4 |4a1.1 |CCMS identifies the form is a CCMS-generated image in which no data can be extracted. |
| |4a1.2 |The user enters a data element(s) from the form into CCMS to perform a search for the data element(s). |
| |4a1.3 |CCMS finds the data element. |
| |4a1.4 |The user selects to index the document using that data element(s). |
| |4a1.5 |Return to step 5 in the normal flow. |
|2 |2a1.1 |CCMS identifies the document is NOT a CCMS-generated document. |
| |2a1.2 |Go to step 4a1.2 in the alternative flow. |
| | |
| | |
|Exception Flow | |
| | |
|Normal Flow |Alternative Flow |Exception Flow |Action |
|Steps |Step |Step | |
|5 |N/A |5e1.1 |CCMS does not successfully extract enough data to index the form. |
| | |5e1.2 |Go to step 4a1.2 in the alternative flow. |
| | |
25 CCMS-USE-DOC-002 Email/Fax Document
| | |
|Use Case ID: |CCMS-USE-DOC-002 |
|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) A document that was |
| |generated out of CCMS and the system can automatically index, 2) A document that was generated out |
| |of CCMS as an image with no pre-populated data and the system cannot automatically index, and 3) A |
| |generic document that was not generated out of CCMS and must be manually indexed by the user. |
|Frequency: |# of documents emailed or faxed. |
| | |
|Primary Actor: |BCCD/ R&R/ Site Staff |
|Secondary Actors: |CCMS |
|Trigger: |Staff person has a document to scan into the system. |
|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 |CCMS determines the document is a CCMS-generated document. |
|3 |CCMS determines whether it is a data extraction form or an image. |
|4 |CCMS identifies it is a data extraction form and attempts to extract the data. |
|5 |CCMS successfully extracts enough data to index the form. |
|6 |CCMS adds the form to a new or existing electronic file. |
|7 |CCMS stores the form in content manager. |
|8 |CCMS determines if a task needs to be generated based on the document type. |
|9 |CCMS generates a task and assigns to the appropriate user, if necessary. |
|10 |Use case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|4 |4a1.1 |CCMS identifies the form is a CCMS-generated image in which no data can be extracted. |
| |4a1.2 |CCMS generates a task to the appropriate user role. |
| |4a1.3 |The user receives the task and views the document. |
| |4a1.4 |The user enters a data element(s) from the form into CCMS to perform a search for the data element(s). |
| |4a1.3 |CCMS finds the data element. |
| |4a1.4 |The user selects to index the document using that data element(s). |
| |4a1.5 |Return to step 6 in the normal flow. |
|2 |2a1.1 |CCMS identifies the document is NOT a CCMS-generated document. |
| |2a1.2 |Go to step 4a1.2 in the alternative flow. |
| | |
| | |
|Exception Flow | |
| | |
|Normal Flow |Alternative Flow |Exception Flow |Action |
|Steps |Step |Step | |
|5 |N/A |5e1.1 |CCMS does not successfully extract enough data to index the form. |
| | |5e1.2 |Go to step 4a1.2 in the alternative flow. |
| | |
26 CCMS-USE-DOC-003 Route Document
| | |
|Use Case ID: |CCMS-USE-DOC-003 |
|Name: |Route Document |
| | |
|Description: |This use case describes the process for when a document is sent to the wrong agency |
| |(BCCD/CCR&R/Site) and a worker needs to route that document to the correct agency. |
|Frequency: |# of documents emailed or faxed. |
| | |
|Primary Actor: |BCCD/ R&R/ Site Staff |
|Secondary Actors: |CCMS |
|Trigger: |Staff person has scanned a document into CCMS or it has been emailed/faxed and has been sent to the |
| |wrong agency. |
|Entry Criteria/Preconditions: |A document exists in CCMS. |
|Exit Criteria/Post-Conditions: |Document is sent to other agency’s queue. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |The user selects to route a document to another agency. |
|2 |CCMS removes the document from the original queue and adds to the other agency’s queue. |
|3 |CCMS generates an alert to the appropriate user within the agency to which the documented was routed. |
| | |
27 CCMS-USE-GEN-001 Generate Alert/Task
| | |
|Use Case ID: |CCMS-USE-GEN-001 |
|Name: |Generate Alert/Task |
| | |
|Description: |Alerts and tasks are generated and assigned to users when a person needs to take an action or for |
| |informational purposes. CCMS users may receive a task when a document is scanned into the system or |
| |when a change is detected in the system where action is need. When a task has been pending for a |
| |certain number of business days, a user may receive a reminder alert that the task is pending and |
| |they need to take action. In other instances, an action may be taken or a change occurs in the |
| |system where a user receives an informational alert. |
|Frequency: | |
| | |
|Primary Actor: |CCMS |
|Secondary Actors: |BCCD/CCR&R/Site Staff |
|Trigger: |A document is scanned/emailed/faxed. |
| |A task has been pending for X amount of days depending on the type of task and number of days |
| |defined for the user’s role. |
| |CCMS identifies a change or action taken in which an alert should be generated. |
|Entry Criteria/Preconditions: |N/A |
|Exit Criteria/Post-Conditions: |A task is saved in complete status or a reminder/information alert has been generated. |
| | |
| | |
|Normal Flow | |
| | |
|Normal Flow |Action |
|Steps | |
|1 |CCMS identifies that a document has been scanned and a user should receive a task. |
|2 |CCMS determines who should receive the task based on business rules. |
|3 |CCMS generates a task and assigns to the appropriate user. |
|4 |The user receives the task. |
|5 |The user takes the appropriate action. |
|6 |CCMS marks the task as complete. |
|7 |Use case ends. |
| | |
| | |
|Alternative Flow | |
| | |
|Normal Flow |Alternative Flow Step|Action |
|Steps | | |
|5 |5a1.1 |If X number of business days have passed (based on the type of task), and the task is still open, |
| | |generate a reminder alert to the task owner. |
| |4a1.2 |Return to step 5 in the normal flow. |
|5 |5a1.1.1 |If X number of business days have passed and the task is still open, CCMS generates an alert to the |
| | |appropriate supervisor role (based on the type of task). |
| |2a2.2 |Return to step 5 in the normal flow. |
|1 |1a1.1 |CCMS identifies that a change or action has occurred in the system. |
| |1a1.2 |Return to step 2 in the normal flow. |
|6 |6a1.1 |CCMS cannot identify the action taken. |
| |6a1.2 |The user marks the task as complete. |
|1 |1a1.2.1 |CCMS determines who should receive an informational alert. |
| |1a1.2.2 |CCMS generates an informational alert. |
| |1a1.2.3 |The user views the informational alert. |
| | |
Entities
The following is a preliminary list of entities and attributes which provide a basis for further elaboration during the detailed design phase.
1) Parent
a. First Name
b. Middle Name
c. Last Name
d. Date of Birth
e. Social Security Number (Optional)
f. Address1
g. Address2
h. City
i. State
j. ZIP
k. County
l. PostalAddress1
m. PostalAddress2
n. PostalCity
o. PostalState
p. PostalZIP
q. HomeTelephone
r. AltTelephone
s. EmailAddress
t. BestCallTime
u. Sex (M/F)
v. Language
i. English
ii. Spanish
iii. Chinese
iv. Polish
v. Other
2) Other Parent
a. First Name
b. Middle Name
c. Last Name
d. Date of Birth
e. Social Security Number (Optional)
f. Address1
g. Address2
h. City
i. State
j. ZIP
k. PostalAddress1
l. PostalAddress2
m. PostalCity
n. PostalState
o. PostalZIP
p. HomeTelephone
q. AltTelephone
r. EmailAddress
s. BestCallTime
t. Sex (M/F)
3) Employment (Parent/OtherParent)
a. Employer
b. JobTitle
c. EmployerAddress1
d. EmployerlAddress2
e. EmployerlCity
f. EmployerState
g. EmployerZIP
h. WorkTelephone
i. Extension
i. StartDate
j. EarningsHourly
k. EarningsMonthly
l. EarningsYearly
m. PayFrequency
i. Weekly
ii. EveryTwoWeeks
iii. TwiceMonthly
iv. Monthly
v. Other
4) WorkSchedule
a. Day1
i. StartTime
ii. EndTime
b. Day2
i. StartTime
ii. EndTime
c. Day3
i. StartTime
ii. EndTime
d. Day4
i. StartTime
ii. EndTime
e. Day5
i. StartTime
ii. EndTime
f. Day6
i. StartTime
ii. EndTime
g. Day7
i. StartTime
ii. EndTime
5) ScheduleVaryIncome
a. Applicant
i. Gross
ii. Tips
iii. Bonus
iv. SelfEmploy
v. ChildSupport
vi. TANF
vii. OtherCash
viii. OtherMonthly
ix. Subtotal
x. ChildSupportPaid
xi. TotalMonthly
xii. HousingAssistance
6) FamilyRelationships
a. Size
b. NumAdults
c. NumChildren
d. NumChildrenwCare
e. Child1
i. NameFirst
ii. NameLast
iii. DOB
iv. Sex
1. M
2. F
v. Ethnicity
vi. Citizen
1. Y
2. N
vii. SSN
viii. StateWard
1. Y
2. N
f. OtherFamily
i. NameFirst
ii. NameLast
iii. DOB
iv. RelationshipToApp
v. SSN
7) TANF
a. Y
b. N
c. 4003
d. 2151A
e. 3085
f. 2151
8) Education
a. HSGED
b. BelowPostSecondary
c. Vocational
d. College
i. TwoYear
ii. FourYear
iii. Degree
1. Y
2. N
3. Listing
e. SchoolName
f. SchoolPhone
g. SchoolAddress2
h. SchoolAddress2
i. SchoolCity
j. SchoolState
k. SchoolZIP
l. SchoolStartDate
m. SchoolEndDate
n. TravelTime
o. Day1
i. StartTime
ii. EndTime
p. Day2
i. StartTime
ii. EndTime
q. Day3
i. StartTime
ii. EndTime
r. Day4
i. StartTime
ii. EndTime
s. Day5
i. StartTime
ii. EndTime
t. Day6
i. StartTime
ii. EndTime
u. Day7
i. StartTime
ii. EndTime
v. ScheduleVary
i. Explain
w. Confirmation
i. Letter
ii. GradeReport
iii. Registration
9) Provider
a. Name
b. CorpName
c. ProviderAddress1
d. ProviderAddress2
e. ProviderCity
f. ProviderState
g. ProviderZIP
h. ProviderPostalAddress1
i. ProviderPostalAddress2
j. ProviderPostalCity
k. ProviderPostalState
l. ProviderPostalZIP
m. ProviderTelephone
n. ProviderAltTelephone
o. ProviderEmailAddress
p. ProviderCounty
q. ProviderDOB
r. ProviderGovID
i. SSN
ii. FIN
iii. GovUnitcode
s. DateCargivingStarted
t. MultifamilyDiscount
10) Arrangements
a. Child1
i. Name
ii. Age
iii. Rate
iv. Day1
1. StartTime
2. EndTime
v. Day2
1. StartTime
2. EndTime
vi. Day3
1. StartTime
2. EndTime
vii. Day4
1. StartTime
2. EndTime
viii. Day5
1. StartTime
2. EndTime
ix. Day6
1. StartTime
2. EndTime
x. Day7
1. StartTime
2. EndTime
b. School
i. Child1
ii. InSchool
1. Y
2. N
3. Yearround
4. SameasProvider
5. HoursVary
6. Day1
a. StartTime
b. EndTime
7. Day2
a. StartTime
b. EndTime
8. Day3
a. StartTime
b. EndTime
9. Day4
a. StartTime
b. EndTime
10. Day5
a. StartTime
b. EndTime
11. Day6
a. StartTime
b. EndTime
12. Day7
a. StartTime
b. EndTime
11) Collaborators
a. Approved
b. HeadStart
c. ISBE
d. Program Length
i. NineMonths
ii. TwelveMonths
iii. Other
1. Explain
e. LegalEntity
i. 760
ii. 761
iii. 762
iv. 763
v. 764
vi. 765
vii. 766
viii. 767
f. RelationshiptoChild
i. Explain
g. License
i. Number
ii. Capacity
1. Day
2. Night
iii. ExpiresDate
iv. OperatingHours
1. Starttime
2. Endtime
h. Conviction
i. Y
ii. N
iii. Explain
iv. Certification
12) Certification
a. ProviderSig
i. SigField
ii. SigDate
b. ApplicantSig
i. SigField
ii. SigDate
13) Case
a. Case Category
b. Case Number
c. RIN
d. Local Office Number
e. DHS Local Office Name
f. CaseNotes
g. RelatedCases
14) Caseworker
a. First name
b. Last name
15) PIQA
a. Sanctions
b. Status
16) PaymentInformation
a. Amount
b. Date
c. Owed
17) CustomerService
a. LastContact
b. ReasonCode
18) Documents
a. Forms
b. Letters
c. Notices
19) Reports
a. AdHoc
b. Standard
Other Design Components
1 Reports
The following section contains two lists. The first contains reports that will be produced in CCMS. The second contains reports that will remain in CCTS.
The following table lists the reports that are proposed to be generated by CCMS. The list includes ad Hoc and standard reports. It includes reports that are currently generated by CCTS as well as new reports that could be available in CCMS. The reports will be rationalized and confirmed during detailed design.
Table 6.1: CCMS Reports
|Title |Description |Frequency |
|Clients With System |This report lists active clients on the Child Care Tracking System with a system |First Friday |
|Assigned SSN |assigned SSN. | |
|RACF ID Production |This report lists the number of entries made on the Child Care Tracking System by RACF|First Friday, daily, |
|Report |ID during the report month for cases with your caseload code. |weekly, monthly |
|Child Care Application |This report lists applications entered during the report month. This report also lists|First Friday |
|Listing |the status of the application, whether approved, pending or denied. CCR&R staff are | |
| |to track pending applications listed on the report to be sure that either approval or | |
| |denial action is taken in a timely manner. | |
|Cases With Multiple |This report lists active cases with multiple providers who have total full-time |First Friday |
|Providers With Days |eligible days that are greater than the calendar days. | |
|Greater Than Calendar | | |
|Days | | |
|Clients W/ SSN Not |This report lists clients where their SSN and DOB in the system do not match. |First Friday |
|Matching Name/DOB | | |
|Report for Licensed |This report provides a listing of licensed centers (760) approved for active cases at |Monthly |
|Centers |the time the monthly certificates were run. CCR&R staff are to go through this report| |
| |to determine if the number of approved children exceeds the licensed capacity for any | |
| |of the providers. | |
|Report for |This report provides a listing of licensed-exempt centers (761) approved for active |Monthly |
|Licensed-Exempt Centers |cases at the time the monthly certificates were run. CCR&R staff are to go through | |
| |this report to verify that all the providers listed on the report fall under one the | |
| |licensing exceptions and do not require a license. | |
|Report for Licensed |This report provides a listing of licensed home providers (762) approved for active |Monthly |
|Homes |cases at the time the monthly certificates were run. CCR&R staff are to go through | |
| |this report to determine if the number of approved children exceeds the licensed | |
| |capacity for any of the providers. | |
|Report for Licensed |This report provides a listing of licensed group home providers (763) approved for |Monthly |
|Group Homes |active cases on the Child Care Tracking System at the time the monthly certificates | |
| |were run. CCR&R staff are to go through this report to determine if the number of | |
| |approved children exceeds the licensed capacity for any of the providers. | |
| New reports | Report Type |
|Case Report by Provider name, address, phone number, email, county, type of care, capacity, child age range, |Ad hoc |
|employer, level/reason for care | |
|Provider Report |Ad hoc |
|Tasks by assign date, due date, status, complete date, worker, date range, # completed |Ad hoc |
|# children in active cases in specific district - might not be able to determine - zip code/county instead |Ad hoc |
|Families by co-pay amount and size, type of case (self employed and what reason, e.g. tax return) |Ad hoc |
|Demographic info |Ad hoc |
|Eligibility activity, lowest income, highest co-pay |Ad hoc |
|Eligibility expiring in next 60 days (want alert too) or other period of time |Ad hoc |
|Actions taken |Ad hoc |
|Changes in name, case #, etc. |Ad hoc |
|New apps that are sent to wrong county |Ad hoc |
| Number of customer service requests by CCR&R/site/BCCD, by type (mail control, web bits, complaints, policy |Ad hoc |
|clarifications…), and by status (pending, closed). This would potentially be an ad hoc report. | |
|Number of policy clarifications by subtype (policy numbers) and by originator. |Ad hoc |
|For provider overpayments where the providers are covered by the union (762-767 type of care) provide a report |Ad hoc |
|with the union dues in the overpayment, month of dues (1st column on overpayment calculation sheet), and | |
|provider details. | |
|Number of overpayments, by type (client vs provider), by reason (administrative vs client/provider), by |Ad hoc |
|sub-reason (over income, etc), by dollar amount (can define ranges), by service month and by number of months of| |
|overpayment by CCR&R/site/statewide. This would potentially be an ad hoc report. | |
|Pending appeal status report. |Ad hoc |
|Case status report through process |Ad hoc |
|Reason for non compliance reports |Ad hoc |
|(Client, Spouse in household, Client over income limits, provider over capacity etc) |Ad hoc |
|Sanctions Report (Who is not compliant and What reason given) |Ad hoc |
|Flagged files report (by reason/cause) |Ad hoc |
|RACF id activity (looking at for audit, as well as productivity) |Ad hoc |
|Providers with parents with common employers |Standard/ Ad hoc |
The following reports are currently produced in CCTS and will continue to be produced by CCTS.
Table 6.2: Reports that will Continue in CCTS
|Title |
|List of Cases Sent Cancellation Forms For Eligibility Ending |
|TANF Payments/Type Care/Case/Children |
|Non-TANF Payments/Type Care/Case/Children |
|All Payments/Type Care/Case/Children |
|Active Child Care Case Listing |
|Payment Override Report |
|TANF Caseload/Program Activity Data |
|Other Caseload/Program Activity Data |
|Total Caseload/Program Activity Data |
|Active Clients Who Are Also CCR&R Employees |
|Active Headstart Cases |
|Active Shared (CCR&R and SITE) Cases |
|List of Cases Sent Redetermination Forms |
|Children Approved with Special Needs Indicator |
|New Approvals with Full-Day Non-Relative Care |
|Active Cases With Provider Changes Pending |
|Monthly Child Care Telephone Billing System Activity |
|Provider Overpayments |
|Monthly Certificate Summary Report |
|Number of Licensed Exempt Providers |
|Payments With LESSMIN or IVRDUP |
|Incomplete Payments (A5029E42 .txt comma-delimited version) |
2 Interfaces
System interfaces are required for the purpose of cross-checking, validating and monitoring CCMS data with other systems. Depending on the business need, these interfaces can be one-way or two-way and can be implemented as real-time or near real-time web services, batch based file transfers or web links.
It is expected that CCMS real time interfaces will operate only when the destination system is available. For example, if a CICS service is taken offline at 5 p.m., then CCMS will not have access to that system after 5 p.m. until the system becomes available again. To the extent possible and dictated by business need, real time data exchange will be formatted in XML or SQL. Batch data exchange will be implemented as flat files.
The specific CCMS interface characteristics such the purpose, mode of operation (real-time, near real-time or batch or web link), delivery method (web service or ftp or web link), data format, frequency, access level (read only or not), and direction (incoming or outgoing)are identified in the table below for each of the interfaces. The list is categorized into those interfaces that have been confirmed by CCMS and those that are pending confirmation.
|Table 6-1. List of Confirmed CCMS Interfaces |
|# |
|1 |
|Name/Version |
|IBM HTTP Server 7 | | |( |( |Based on Apache HTTP |
| | | | | |Server |
|IBM DB2 9.7 | | |( |( | |
|IBM WebSphere Application Server V9.1 | | |( |( | |
|SAP Business Objects Crystal Reports XI Server 3.1 | | |( |( | |
|Microsoft Windows Server 2008 | | |( |( | |
|Microsoft Windows Server 2008 Active Directory | | |( |( | |
|Adobe LiveCycle ES2 | | |( |( | |
|Adobe LiveCycle Data Services ES2 | | |( |( | |
|Adobe LiveCycle ES IBM Content Manager Connector | | |( |( | |
|IBM Content Manager Enterprise Edition Version 8.4 | | |( |( | |
|Kofax Capture 9.0, Service Pack 1 | |( | |( | |
|Kofax Rightfax Adapter V2 | |( | |( | |
|Right Fax Server 9.4 | |( | |( | |
|JDK 1.5 |( | | | |V 1.5 needed for |
| | | | | |WebSphere |
| | | | | |Compatibility |
|JDBC 4.0 | | |( |( | |
|IBM DB2 9.7 | | |( |( | |
|Software Development Tools | | |
|IBM Rational Application Developer 6.0.1 | | |( |( | |
|IBM Rational ClearCase 7.0.1.0 | | |( |( | |
|Adobe LiveCycle Workbench ES 2 | | |( |( | |
|IBM Rational ClearQuest 7.0.1.0 | | |( |( | |
|Eclipse 3.6 (Helios) |( | | | | |
|Microsoft Internet Explorer 6.0 or higher | | |( |( | |
|Mozilla FireFox 3.5 or higher | | |( |( | |
|SAP BusinessObjects Crystal Reports XI Development Suite, | | |( |( | |
|including InfoView | | | | | |
|Adobe Flash Builder 4 | | |( |( | |
|Adobe FlexUnit 4 | | |( |( | |
|Gorilla Logic FlexMonkey 4.1.2 |( |( | | |Flex UI Testing Tool |
|Adobe Acrobat 9.3.2 and Reader 9.3.2 or higher | | |( |( | |
|Adobe Flash Player 10.1 (latest version) or higher | | |( |( | |
|Adobe Flash Player 10.1 (debug version) or higher | | |( |( | |
|CA ERWIN Data Modeler r7.3 | | |( |( | |
|JUnit 4.5 |( | | | |( |
|Apache ANT 1.8.1 |( | | | |( |
|Rational Performance Tester | |( | |( | |
|Log4J |( | | | |( |
|VMWare Player 3.1.3 | |( | | |( |
|Altova xmlspy 2011 Standard Edition | |( | | | |
|JAWS 12 (or State standard) for Windows Screen Reading | |( | | |( |
|Fiddler Web Debugger |( |( | | |( |
|SQL Squirrel |( | | | | |
|Apache Log4J |( | | | | |
|Spring |( | | | | |
|Apache Struts |( | | | | |
|Hudson |( | | | |Testing software |
|Project Management |
|Microsoft Office 2007 – Word, Excel, PowerPoint | | |( |( | |
|Microsoft Visio 2007 | | |( |( | |
|Microsoft Project 2007 | | |( |( | |
|Training Development |
|Adobe Captivate 4 | |( | | |( |
|Adobe RoboHelp 8 | |( | | |( |
|Dragon Naturally Speaking | | |( | | |
a. Development Environment Configuration
The development environment will consist of the following segments that are connected over a Local Area Network (LAN):
• Developer desktops running Windows XP or higher hosted at DHS MIS,
• Core web/application/batch/LiveCycle server as well as database server hosted in a virtualized environment by CMS.
• Other required servers hosted in a virtualized environment by CMS as follows:
a. IBM Content Manager
b. Crystal Server
c. Kofax/RightFax
d. Active Directory
e. Clearquest
f. DB2 Server
• Scanner, Printer and Fax machine hosted by DHS MIS
A visual representation of the development environment is provided in Figure 7-2.
[pic]
Figure 7-2 CCMS Development Environment
The following table provides the specifications for the desktop environment, each of the servers as well as the scanner, printer and fax machine.
|Table 7-2. Development Environment Specifications |
|Hardware |Units |
|Web/Application Server |1 |
|DB2 Database Server |1 |
|IBM Content Manager |1 |
|Crystal Server |1 |
|Kofax/RightFax Server |1 |
|Version Control Server |1 |
|Active Directory Server |1 |
The following table provides the specifications for the development environment scanner.
|Table 7-3. Scanner Specifications |
|Model |Fujitsu FI-6130 with imprinter |PPM @300 DPI |30 PPM |
|Automatic Document Feeder |Yes |Sheetfed |Yes |
|Feeder Volume |50 |Daily Duty |2000 |
| | |Cycle | |
|VRS |Yes |Weight |9.25 lb |
|Footprint |11.8 x 6.4 x 6.2 in. |Units |1 |
The development environment printer is anticipated to be based on State standards and has already been made available. Therefore, detailed printer specifications are not being included in this document.
The table below shows the communication protocols planned for this project.
|Table 7-4. Communication Protocols |
|Communicating Parties |Protocol |
|Presentation Layer and LiveCycle ES2 |Action Message Format (AMF) |
|Client and Presentation Layer |HTTP |
|Client to Business Service via Presentation Layer |Simple Object Access Protocol (SOAP) |
|KOFAX and LiveCycle ES2 |Watched Folder |
|RightFax and LiveCycle ES2 |Watched Folder |
|LiveCycle ES2 and Email Server |Simple Mail Transfer Protocol (SMTP) and Post Office Protocol (POP)3 |
|LiveCycle ES2 and CCMS Database via Persistence Layer|Java Database Connectivity (JDBC) |
|Business Service Layer and Active Directory |Lightweight Directory Access Protocol (LDAP) |
The following diagram depicts the required connectivity and protocols among CMS development environment servers.
The following diagram depicts the required connectivity and protocols among CMS development environment servers.
[pic]Figure 7-3. CCMS Network Development Diagram
3 Initial Training, Test, QA and Production Environment Considerations
The CCMS system will use multiple logical environments to build, test, QA and deploy for operational use. These environments will be consistent with DHS MIS and CMS approach to promote software through Systems Integration Testing, User Acceptance Testing, QA and finally into Production. Additionally, an environment will be configured specifically to facilitate user and technical staff training.
The configuration of these environments will leverage CMS’ virtualized server strategy. The Systems Integration Test, UAT and QA environments will, at varying degrees and in a progression, closely mirror the production environment.
Planning for the capacity of these environments will take into consideration factors such as the anticipated number of transactions, size of transactions, transaction rate, performance expectations, peak loads, anticipated number of users or simulated users and document storage needs. Clustered configurations will be considered to obtain the needed capacity for these environments.
The CMS hardware/software procurement process timeline will be taken into consideration as well. As such, the specifications for these environments will be delivered at least one month in advance of the date each environment is required for the project.
Requirements List
The following section describes the cumulative list of requirements confirmed during the General Systems Design (GSD) phase of this project. Requirements that have been added, modified or deleted are also noted. The requirements are documented in the file below:
[pic]
initial Key Considerations
This section documents key considerations as they pertain to each of the following system domains:
1) Security Domain
a. Identification and authentication of the CCMS user will be accomplished using a “reverse proxy” to the DHS Microsoft Internet Security and Acceleration (ISA) server implemented/hosted/managed by CMS.
b. BCCD, R&R and Site Providers will each have different subsets of functionality available to them based on “need to know”. All of these participants will be in Active Directory. MIS will confirm if they will be in the internal Active Directory or External Active Directory.
c. MIS will discuss the feature of maintaining users in AD and follow-up.
d. By June 2011, all DHS personnel are expected to be on Active Directory.
e. Enrollment process is managed by CMS now but MIS will confirm if that functionality should be provided by CCMS for CCMS users. Optionally, MIS is researching enhancement of a separate Worker Admin for Active Directory to manage users.
f. For users on the internal Active Directory, CMS/DHS have the ability to provide single sign on to Business Objects. Otherwise, it will be a dual login.
g. CMS and DHS will discuss and resolve how citizens will be enrolled and registered into Active Directory.
h. CCMS will have to audit “who accessed what on content manager” since content manager will only provide a single user id and password and won’t support detailed audit logs.
i. RightFax and Kofax security will be configured to use Active Directory by CMS.
j. CCMS and CCTS security will be controlled through firewalls and infrastructural layer security. Single system-level user id and password will be provided by CMS.
k. DHS will provide specifications on securing other interfaces including City of Chicago.
l. Web links security – CCR&Rs, BCCD and Site Providers as well as Chicago participants who have RACF ID will be able to access. Once CCMS takes the participant to the website, the person is outside the CCMS security jurisdiction. Users will have to separately login.
m. CCMS will support a two-level security role hierarchy.
n. The System should have security that could limit what server has access is a functionality provided by the security infrastructure and not CCMS.
o. CCMS will provide two kinds of audit trails – who looks at certain things for very specific documents and information identified during detail design and keeping track of various versions of documents – for example, annotated documents. BCCD will very specifically identify the transactions and documents that require read audit during detail design.
2) Network Domain
a. CCMS will utilize the State’s existing network infrastructure.
b. R&Rs have at least T1 bandwidth if they go through the “century network”. MIS will confirm the availability of “century network” for use at each R&R location.
3) Application Domain
a. CCMS will provide an alternative simple way of clubbing case documents rather than using PDF Generator.
4) Platform Domain
a. DB2 database will reside on the z/OS platform.
b. IBM Content Manager will be hosted on Windows 2008 platform.
c. Adobe LiveCycle ES 2 will be hosted on Windows 2008 platform.
d. All other CCMS-related servers will be hosted on Windows 2008 or AIX platform as dictated by CMS standards and agreed-upon by Deloitte.
e. MIS is in the process of establishing this fax number. The fax number needs to be dedicated to the CCMS project.
5) Integration and Middleware Domain
a. The CCMS will use web services, JDBC drivers, flat files transferred in batch mode, Flex remoting and other mechanisms, as necessary and dictated by business need, to transfer data between systems.
b. Any read or write web service based interface from CCMS to an external system, including CCTS, that CCMS is required to interact with will be hosted and provided by that systems “owner” and not by CCMS.
6) Data Domain
a. The CCMS system will include a DB2 mainframe database for its exclusive use and not shared with any other system other than through interfaces.
b. DB2 will be used for LiveCycle, Content Manager and the CCMS mainframe database.
7) Operations and Support Domain
a. Any batch jobs developed for CCMS will need to appropriately consider the existing sequence and timing of batch jobs in the DHS environment.
b. For the number of technical environments, the CCMS strategy would be to comply with CMS standards for the number of technical environments. CMS uses at least the following types of environments: Development (DEV) Systems Integration Testing (SIT), User Acceptance Testing (UAT), and Production. In addition, CCMS will also need a separate training environment.
8) Access Domain
a. CCMS public users, if any, will have access based on authentication and authorization systems created and maintained by CMS and DHS MIS.
b. CCMS internal users will have access based on authentication and authorization systems created and maintained by CMS and DHS MIS.
knowledge Transfer
Our Deloitte Project Team worked closely and collaboratively with the DHS Project Team through the General System Design phase activities that led to the formulation of this deliverable. This approach was taken to provide DHS stakeholder visibility and foster participation to form the preliminary steps that position the agency for system adoption and operation of the solution once implemented. Specifically, these are the activities that we worked with agency personnel during this phase.
• Established General System Design session calendar
The Deloitte project team drafted a calendar of sessions and worked with DHS to solicit their input, feedback and approval. Although most of the sessions were laid out in advance on the calendar, additional sessions were jointly planned based on needs identified during these sessions. Establishment of this calendar in advance enabled DHS to plan for proper representation and participation during these sessions to help ensure common understanding of the business processes, use cases and requirements that constitute the envisioned system and thereby provide an early start the process of preparing the agency for system adoption.
• Obtained agreement on session approach
The approach to conducting the sessions was formulated in advance and reviewed with DHS and their feedback was incorporated into the approach. The approach was developed jointly to help clarify expectations and facilitate session participation.
• Identified session participants
For each of the planned sessions, DHS identified participants that represent the stakeholder groups to include: BCCD, policy, business functions, Management Information System (MIS) department, central office, providers, CCR&R and Child Care Sites. This process facilitated planning to have adequate representation during these sessions.
The following tables identify the GSD session participants.
|Eligibility 2 |Eligibility 3 |Eligibility 4 |Customer Service |
|Bock, Lisa |Campbell, Sherri |Ahern, Kevin |Bock, Lisa |
|Carls, Tracy |Casteel, Angela |Campbell, Sherri |Casteel, Angela |
|Casteel, Angela |Coffman, Cheri |Carls, Tracy |Davis, Loretta |
|Coffman, Cheri |Cox, Reva |Coffman, Cheri |Dortch, Jacqui |
|Cox, Reva |Davis, Loretta |Cox, Reva |Frazier, Teresa |
|Davis, Loretta |Dortch, Jacqui |Casteel, Angela |Gibson, Spring |
|Dortch, Jacqui |Gaffney, Phyllis |Davis, Loretta |Isham, Carolyn |
|Gaffney, Phyllis |Garner-Jones, Michael |Emerson, Amy |Jackson, Adriane |
|Garner-Jones, Michael |Goodman-Baker, Pattee |Gaffney, Phyllis |Karris, Roselyn |
|Gaul, Betty |Harris, Roselyn |Garner-Jones, Michael |Keefer, Leigh Ann |
|Goodman-Baker, Pattee |Hilligoss, Lesa |Goodman-Baker, Pattee |Kent, Tammy |
|Hanneman, Jeff |Jackson, Adriane |Harris, Roselyn |King, Lisa |
|Harris, Roselyn |Jarvis, Denise |Hilligoss, Lesa |Kollman, Suzanne |
|Hilligoss, Lesa |Johnson, Carlena |Jackson, Adriane |Krieger, Dena |
|Jackson, Adriane |Keefer, Leigh Ann |Jarvis, Denise |Levi, Deborah |
|Jarvis, Denise |King, Lisa |Johnson, Carlena |Lott, Ebone |
|Johnson, Carlena |Kloppenburg, Katthy |Keefer, Leigh Ann |Malloy, Rose |
|Keefer, Leigh Ann |Kollman, Suzi |Kelly, Serena |Marshall, Cary |
|Kelly, Serena |Krieger, Dena |King, Lisa |Marshall, Kim |
|King, Lisa |Lamothe, Kellene |Kloppenburg, Kathy |McCullough, Erica |
|Kloppenburg, Katthy |Lane, Kathy |Koeppel, Ryne |Milkovich, Rayette |
|Koeppel, Ryne |Levi, Deborah |Kollman, Suzi |Palmetier, Dave |
|Kollman, Suzanne |Lott, Ebone |Lamothe, Kellene |Payton, Jennifer |
|Krieger, Dena |Marshall, Cary |Lane, Kathy |Robinson, Grace |
|Lamothe, Kellene |Martin, Richard |Levi, Deborah |Saterfield, Linda |
|Levi, Deborah |Randle, Jan |Marshall, Cary |Skube, Tamara |
|Lott, Ebone |Rinehart, Brenda |Palmatier, Dave |Splain, Stacey |
|Marshall, Cary |Robinson, Grace |Randle, Jan |Vereen, Nancy |
|Marshall, Kim |Skube, Tamara |Robinson, Grace |Wiener, Jennifer |
|Martin, Richard |Smith, Brenda Lee |Rodriguez, Beatriz | |
|McCullough, Erica |Splain, Stacey |Saterfield, Linda | |
|Robinson, Grace |Taulbee, Lori |Skube, Tamara | |
|Rodriguez, Beatriz |Wiener, Jennifer |Slack, Chad | |
|Skube, Tamara | |Smith, Brenda Lee | |
|Slack, Chad | |Splain, Stacey | |
|Splain, Stacey | |Taulbee, Lori | |
|Taulbee, Lori | |Wiener, Jennifer | |
|Wiener, Jennifer | |Wilson, Dave | |
| | |Young, Karen | |
|PIQA |Technical 1 |Technical 2 |Reports/Forms/Alerts |
|Behle, Eric |Campbell, Sherri |Bishop, Mike |Behle , Eric |
|Campbell, Sherri |Carls, Tracy |Campbell, Carla |Brockhouse , Tranae |
|Carls, Tracy |Davis, Loretta |Carls, Tracy |Carls. Tracy |
|Casteel, Angela |Emerson, Amy |Davis, Loretta |Davis, Loretta |
|Dortch, Jacqui |Garner-Jones, Michael |Garner-Jones, Michael |Harris, Roselyn |
|Edison, Eric |Hilligoss, Lesa |Hanneman, Jeff |Jackson, Driane |
|Emerson, Amy |Holt, Joel |Haskins, Ned |Kent, Tammy |
|Garner-Jones, Michael |Keefer, Leigh Ann |Jackson, Adriane |Kloppenburg, Kathy |
|Hanneman, Jeff |King, Lisa |Keefer, Leigh Ann |Krieger, Dena |
|Huddleston, Mary Jo |Lane, Kathy |Kent, Tammy |Palmatier , Dave |
|Jackson, Adriane |Levi, Deborah |Levi, Deborah |Randle, Jan |
|Keefer, Leigh Ann |Marshall, Cary |Lott, Ebone |Robinson, Grace |
|Kent, Tammy |Merrill, Carol |Marshall, Cary |Ruther, Gina |
|King, Lisa |Palmatier, Dave |Merrill, Carol |Splain , Stacey |
|Knight, Beth |Prisner, Holly |Palmatier, Dave |Wiener, Jennifer |
|Koeppel, Ryne |Rinehart, Brenda |Prisner, Holly |Young, Karin |
|Kollman, Suzi |Robinson, Grace |Randle, Jan | |
|Kreiger, Dana |Slider, Gay |Rhinehart, Brenda | |
|Lane, Kathy |Smith, Brenda Lee |Skube, Tamara | |
|Levi, Deborah |Sullivan, Amanda |VanNattan, Fonda | |
|Lopez, Francisco |VanNattan, Fonda |Whitehead, Don | |
|Marshall, Cary |Young, Karen |Wiener, Jennifer | |
|Martin, Richard | | | |
|Palmatier, Dave | | | |
|Prisner, Holly | | | |
|Randle, Jan | | | |
|Robinson, Grace | | | |
|Rodriguez, Beatriz | | | |
|Ruther, Gina | | | |
|Scarborough, Crystal | | | |
|Serritella, Mari | | | |
|Skube, Tamara | | | |
|Slack, Chad | | | |
|Splain, Stacey | | | |
|Thakkar, Victor | | | |
|Whelan, Maria | | | |
• Collaboratively conducted sessions
The general system design sessions were structured to include preparatory materials in the form of presentations, templates, and documents that provided a meaningful starting point and promoted necessary discussion of each topic relevant to the session. Follow-on action items were identified and session outcomes documented.
• Completed follow-on activities
Additional discussions and follow-on actions were taken, as necessary, to obtain required clarification on the expected content of the General System Design document.
• Document deliverable for approval
Once documented, the General System Design is anticipated to reflect the clarification obtained through the joint sessions with DHS. The document review period will provide an additional opportunity for DHS to confirm and validate that their vision is encapsulated in the document and seek additional clarification, if necessary. DHS involvement in session planning and execution has facilitated assimilation of the General Design Document content and prepared the agency for the detailed design phase that builds on this content.
Through a collaborative approach to general system design development and active participation among DHS staff in the process, knowledge of the anticipated system functionality in terms of business processes and use cases along with requirements has been circulated to promote common understanding and enable preparation for the detailed design phase.
Assumptions and Dependencies
This section provides a documentation of assumptions and dependencies pertaining to the general system design.
1 Assumptions
1 Document Capture and Processing
• Faxes will be received by CMS provided and supported RightFax and then accessed by Kofax using the Kofax/RightFax connector.
• DHS is planning to use de-centralized scanning centers for scanning paper documents. It is assumed that DHS network has the capacity to handle the de-centralized approach.
• Some forms may need to be filled out when the users are offline but still on their computer. These forms may be printed with barcodes, faxed to an office and then decoded by CCMS.
2 Security and Audit
• For security reasons no documents or forms will be sent via e-mail outside of DHS by the system.
• Audit logs are primarily used by technical staff in response to auditors.
• CCMS data does not require encryption while in storage or while in transit.
• Enforcement of DHS password standards is accomplished by Microsoft ISA outside the CCMS domain.
• MIS and CMS will provide the security infrastructure, including PKI, for both the public and internal CCMS users as well as system-to-system interfaces.
• CMS will allow groups but not attributes in Active Directory.
• CMS will install and configure Kofax and RightFax to operate with Active Directory for all technical environments (i.e., development, System Integration Test, UAT, Training and Production).
• Security features such as number of password attempts, response to user id/password failure, session timeout, and inactivity parameters will be controlled by CMS using ISA.
• Providers and R&R employees will be expected to have Active Directory profile and password.
• CMS will provide a single user id and password access into the IBM Content Manager environment. This user id and password will be used by the Adobe LiveCycle IBM Content Manager connector to establish an authenticated connection. CMS will administer security of the IBM Content Manager using existing tools.
• Electronic signatures – Electronic signatures will be captured through signature pads provided by DHS.
• Providing for user authentication and maintaining a History/log of security adds, updates, and deletes is functionality provided by ISA and not CCMS.
3 Technical Environment
• The document repository will be IBM Content Manager. Documents in process may temporarily be held in Adobe LiveCycle.
• For the development environment, DHS will have a disk image for Microsoft products. Any product over and beyond the base image will need to be reinstalled if desktop recovery is required. The image will not include Adobe LiveCycle and other development applications. This requires additional configuration which will be performed by DHS MIS immediately after reimaging of the base system.
• CMS backup strategy will be sufficient to restore the CCMS technical environments including the development environment.
• The development environment requires both email capability. DHS and CMS will provide an Outlook-based environment for development purposes and subsequently for other environments such as Systems Integration Testing, UAT, QA and Production.
• Internal staff and external users will be stored in separate repositories. MIS will confirm this.
• CMS will provide separate Active Directory instances for development and production.
• The development environment Active Directory server is the domain controller for the development environment.
• CCMS DB will be a separate DB2 database on a mainframe platform accessible using JDBC. CMS/DHS will provide data administration.
• IDHS will provide an inventory of existing scanners for Deloitte to review. Based on that review Deloitte will create guidelines on producing scans for CCMS.
• DHS will not be considering digital certificates for electronic signatures because most customers do not have it or do not know how to use it. DHS will provide any infrastructure necessary to implement acceptable level of security.
• CMS will install and configure Kofax and RightFax to operate with Active Directory for all technical environments (i.e., development, System Integration Test, UAT, Training and Production).
• DHS has the required network bandwidth and throughput to support CCMS system performance expectations.
• IDHS will categorize each CCMS transaction and define response time on a case-by-case basis during detailed system design phase to clarify mandatory requirement number 64.
• CMS uses IBM Tivoli storage Manager for network server backups.
• MIS currently has 1 ERWIN license and will work with Deloitte to provision the additional required license.
•
4 General
• The State will be responsible for assistive technologies and will provide Deloitte the necessary licenses for testing. The CCMS project will not identify assistive technologies nor participate in their deployment.
• Information displayed in CCMS via interfaces or data-read will be transferrable to other applications such as word and email through the standard windows cut-and- paste process or screenshot creation process.
2 Dependencies
1 Document Capture and Processing
• DHS will complete installation and configuration of local office scanners and associated workstations in time for Pilot and Production implementation.
2 Security and Audit
• DHS and CMS will provide and support the mechanism for authenticating internal and external users.
3 Technical Environments
• CMS will provide the CCMS development, training, testing, QA and production environments fully configured to specifications in time to meet the project milestones. To facilitate the development process, CMS will provide Deloitte with a sandbox environment fully accessible to developers. Developers will have full administrative rights to the sandbox.
• All environments, including any sandbox installations, will match the software and protocol requirements for the production environment.
• CMS will promptly resolve any server or network issues.
• CMS will provide prompt support for deployment of software in the CMS environment.
• DHS will procure any licenses required for the project in time to meet project milestones.
Appendix A – GSD Related Outstanding Action Items
This Appendix identifies PMC action item entries associated with the GSD deliverable that require follow-up and resolution during the DSD phase of the project.
|Section # |Section Name |Action Item |Status |
|4.26 |Generate Alerts/Tasks |45534 |Open |
| | | | |
|3, 4 |Business Processes, Use Cases |45555 |Open |
|3, 4 |Business Processes, Use Cases |45557 |Open |
|3.1 – 3.8 |Eligibility Business Processes |45488 |Open |
|3 |Business Processes |45532 |Open |
|3.8, 4.9 |Add/Update Provider |45536 |Open |
|3.8, 4.9 |Add/Update Provider |45537 |Open |
|3.10, 4.11 |Process a W9 Form |45540 |Open |
|3, 4 |Business Processes, Use Cases |45542 |Linda Saterfield has contacted Legal to begin |
| | | |this discussion. |
|3.9, 4.10 |Process a Supplemental Certificate |45546 |Open |
|4.26 |Generate Alerts/Tasks |45550 |BCCD would like to keep this item open to allow |
| | | |for additional ideas. |
|3.10, 4.11, |Process a W9 Form, Process an Appeal |45553 |Open |
|3.14, 4.15 | | | |
|3.10, 4.11 |Process a W9 Form |45554 |Open |
|Appendix B |Forms |45562 |Open |
|Appendix B |Forms |45563 |This meeting has been scheduled. |
|3.8, 4.9 |Add/Update Provider |45771 |Open |
|6.2 |Interfaces |45779 |Open |
|6.2 |Interfaces |45781 |Open |
|6.2 |Interfaces |45782 |Open |
|6.2 |Interfaces |45783 |Open |
|6.2 |Interfaces |45784 |Open |
|6.2 |Interfaces |45785 |Open |
|9 |Initial Key Considerations |45786 |Open |
|9 |Initial Key Considerations |45787 |Open |
|9 |Initial Key Considerations |45788 |Open |
|6.2 |Interfaces |45789 |Open |
|9 |Initial Key Considerations |45791 |Open |
|6.2 |Interfaces |45952 |Open |
|6.2 |Interfaces |45966 |Open |
Appendix B – Forms and Alerts
This appendix contains two files:
1) All forms discussed during GSD and data/conclusions collected about each form for the CCMS project.
2) A list of desired alert, indicating those in scope based on the requirements specifications.
[pic][pic]
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- colorado department of human services child care
- department of human services colorado springs
- oklahoma department of human services forms
- department of human services intranet
- illinois department of human services
- department of human services medicaid
- department of human services oklahoma
- state of illinois department of professional regulation
- department of human services food stamp application
- department of human services wv
- georgia department of human services jobs
- department of human services maine