8Interfaces
This section documents the specifications for interfaces between CCMS and various external systems. For each interface, the documentation includes the following:
a)Purpose – A brief description of the purpose of the requirement
b)Key interface decisions – A documentation of decisions that influence the implementation of the interface
c)Participating systems – Identification of the sending system and the receiving system
d)Functional requirements – A description of the functional need behind the interface including a definition of the trigger for an interface
e)Data requirements – This includes identification of data elements, source to destination system mapping, data formats, edits, translation, transformation and content
f)Service level expectations - batch/real-time, incoming/outgoing, delivery method – example, SQL insert or Flat File, schedule, volume and frequency
g)Interface dependencies – Identification of other processes that must precede or succeed the execution of an interface
h)Special processing – Documentation of any processing needs associated with the data that is being transmitted via the interface
i)Error handling – Identification of an approach to handle any error conditions that may result from executing an interface
j)Security – Identification of sensitivity and restrictions that apply
k)Integrity control – Processes for ensuring the receiving system’s data integrity
l)Procedures and operational considerations – Procedures for executing the interface and itemization of operational needs such as batch window constraints that must be considered for executing an interface
m)Data conversion considerations – A few interfaces may also involve conversion of data for one-time load into the CCMS. Conversion needs and considerations will be documented in this sub-section.
CCMS will be providing a web link to IPACS HATS Menu that provides access to AWVS, ACID, and KIDS systems. Access to these systems is not treated as system interfaces.
8.1City of Chicago Interface
8.1.1Purpose
The City of Chicago currently hosts three systems:
1)Child Care Management Information System (CCMIS) also known as the “billing system”
2)COPA - Integrated system for eligibility, recruitment, selection, enrollment and attendance
3)IMEDGE document management system
The City is in the process of consolidating CCMIS and COPA. The scope of the interface between CCMS and City of Chicago only includes a one-way daily batch transfer of COPA data into CCMS for search purposes. The three City of Chicago systems are only listed for providing overall context to the interface. The overall purpose of the interface is for CCMS users to be able to search City of Chicago data for duplicate customers so that further investigation can be conducted, if necessary.
As such, the “interface” consists of 5 application components:
1)Daily one-way batch transfer of COPA data for storage within CCMS in a separate searchable data structure. This section of the document focuses on the details related to this interface.
2)A search screen within the CCMS application for retrieving summary search results. The details for this search screen are provided in section 6.
3)A detailed PDF-based report on the case selected from the summary search results. The details are provided in section 7.
4)An City of Chicago data search integrated with the CCMS case search screen. The details are provided in section 6.
5)A Duplicate Child Report that outlines duplicates between COPA data and CCMS data. The details are provided in section 7.
8.1.2Key Interface Decision
BCCD, MIS and City of Chicago decided to use a batch approach (rather than a real-time approach) to obtaining City of Chicago data on a daily basis in XML format and storing the data in a separate data structure (as opposed to merging the data with CCMS data). The separate data structure will be housed within the CCMS database for search purposes.
8.1.3Participating Systems
The source system is COPA or a modernized and consolidated City of Chicago system that contains COPA data. The destination system is CCMS.
8.1.4Functional Design
COPA data is required within CCMS for duplicate data search purposes. The design keeps COPA data in a separate repository and there is no data or functional consolidation between COPA and CCMS.
8.1.5Data Requirements
The data elements required by CCMS from COPA are identified in the table below. It is intended that the source and destination structure will be similar so no translation or source to destination mapping are required.
Parent and 2nd Parent InformationFirst name
Middle name
Last name
Date of birth
SS# (optional)
Address 1
Address 2
City
State
Zip
County
Home phone
Sex (m/f)
Language
Employment (parent/other parent)
Employer
Job title
Employer address1
Employer address2
Employer city
Employer state
Employer zip
Work telephone
Start date
Earnings hourly/monthly/yearly
Pay frequency weekly/two weeks/twice monthly/monthly/other
Work schedule
Day 1 startTime/endTime
Day 2 start time/end time
Thru
Day 7
Schedule varies
Applicant income
Gross
Tips
Bonus
SelfEmployed
Family Relationships
Size
Number of adults
Number of children
Child 1: first name/last name/DOB/Sex/Citizen/SS#/State Ward
Other family member: first name/last name/DOB/relationship to applicant
Education
HSGED
BelowPostSecondary
Vocational
College 2-year/4-year/degree Y/N
School Name
School Phone
School Address1
School Address2
School City
School State
School Zip
School startdate/enddate
Schedule
Provider
Name
Corporation Name
Provider Address Line 1
Provider Address Line 2
Provider City
Provider State
Provider Zip
Provider Postal Address1
Provider Postal Address2
Provider Postal City
Provider Postal State
Provider Postal Zip
Provider Telephone
Provider County
ProviderDOB
ProviderGovid SSN/FEIN
Date Care Started
Date Care Ended
Arrangements
Child 1
Name/age/rate
Day 1 starttime/endtime through Day 7 start time/end time
School
Child1
Inschool Y/N
Year Round
Sameas Provider
Hours/vary
Day 1 start time/end time through Day 7 start time/end time
Case Information
Collaboration
Approved
Head Start
ISBE
Program length 9 months/12 months/other
Case and Individual Identifiers
Case
Category
Number
RIN
8.1.6Service Level Expectations
The transfer of data from COPA to CCMS will be daily, batch and in XML format. The data will be incoming to CCMS and there is no outgoing data from CCMS to COPA. The delivery method will be a flat file that can be imported into the CCMS data repository. The file transfer mechanism, the volume of initial data load and daily uploads are TBD. BCCD/MIS has designated 6AM-7AM CST as the window for the file transfer and upload.
8.1.7Interface Dependency
Implementation and operation of this interface depends on City of Chicago developing a mechanism to provide daily COPA data in the required XML format and meeting the service level expectations.
8.1.8Special Processing
Special processing needs are to be determined and require additional City of Chicago discussion after the data format has been confirmed and finalized.
8.1.9Error Handling
CCMS intends to import the daily COPA XML data into a data structure that closely mirrors the XML structure. CCMS operational staff will not fix data errors since they are not the data owners. These errors will be captured in a log file to facilitate error fixing by the City of Chicago. Error handling by CCMS will be limited to technical errors that will be captured in error log files. CCMS does not provide notification of these errors.
8.1.10Security
Security for the file transfer mechanism is to be determined.
8.1.11Integrity Control
a)Security – Identification of sensitivity and restrictions that apply
b)Integrity control – Processes for ensuring the receiving system’s data integrity
c)Procedures and operational considerations – Procedures for executing the interface and itemization of operational needs such as batch window constraints that must be considered for executing an interface
8.1.12Data conversion considerations
There are no data conversion needs for this interface.
8.2CCMS Mass Mailing
8.2.1Introduction
The purpose of the mass mailing functionality is to take advantage of the State’s central printing and mailing facility for sending documents to a large volume of customers and providers and thereby optimize costs.
Figure 8.1 Mass Mailing Process
Mass Mailing Modes
The CCMS system will support the following Mass Mailing Modes:
- On demand daily mode – Whena user indicates on demand mass mailing, this process involves capturing a transaction in a CCMS table. A nightly batch process picks up the transaction for processing. Additional required data is fetched by the batch process from other CCMS tables.
- Regular monthly or daily mode – Redetermination forms are mass mailed this way. In this case, a monthly or daily batch program looks for conditions in a case that cause documents of a certain type like Rede to be mass mailed to customers.
Batch mode address check with Finalist is completed when a document is picked for printing and before sorting by zip code (see the Finalist interface section for details). The sort order depends on each form but the default is zip+4. The batch process produces a flat file of print strings and anXML document per form type. The XML format is used to produce PDF files that are stored in IBM Content Manager. The print strings and XMLare stored in the database.
Send Document Copy to Document Management System
A copy of each of the documents sent to the client will need to be stored in document management as an image for future retrieval. All CCMS mass mailing batch programs (including the programs modified by MIS) will generate and store an XML,for each document. Upon completion of that process, these batch programs will trigger a Livecycle process that reads XML data and generates flattened PDF documents for storage in IBM Content Manager. All required metadata is stored along with the document for future retrieval purposes. Electronically stored documents will only have local print option when retrieved for reference.
Processing by Print Subsystem and Mobius
The print subsystem and Mobius are existing DHS/MIS software systems and will be leveraged by CCMS for mass printing (i.e., CCMS will provide input print line or print strings, where applicable, to the print subsystem for mass mailing purposes).
The batch process sends the variable content (or print lines or print strings) to Mobius that determines if the form has to be printed and mailed. Mobius sends documents to be printed and mailed to the print subsystem that merges the content with a runtime Xerox template for the form (PRN file), and the print information is a printer. The print strings may be passed along as a flat file or stored in the database for pickup by an MIS program.
A print string will need to include pointers to the PRN file and other macro information. Dynamic Job Descriptor Entries (DJDEs) point to the PRN file or Flash and are located in the print string at a place that the print subsystem can recognize. These bits of information are placed at the beginning or embedded if there are form changes mid stream. Additionally, “Marks” are used to advise the mailing process. For documents that do not have a corresponding Elixir template, DJDE is used to specify fonts, margins etc.
MIS staff develops the Xerox template using Elixir a WYSISWYG tool and the template contains fixed content with “fill in the blanks” variable content. A flag in the data informs Mobius whether a document is stored for viewing purposes and/or printed. The final print strings are sent by Mobius to the printer which puts together a PCL file for printing. Every printed copy has an electronic copy. By default, the flag is set to “view only”. The actual mass printing and mailing occurs at the Revenue Center.
The Mobius process gets a job name, form name, report id, and for that combination a flag specifying whether it should be printed and/or viewed. Report ID is a generated name based on certain format and several factors. One form name can be associated with more than one report ID. If printed, the “cc: to” information can also be included. Cover page is printed automatically. Multiple copies can be printed with a separate recipient. Mobius is manually setup for processing based on form name. The form name is also used by the DJDE to identify the Elixir template associated with the form.
A few forms have more than one report ID associated with it – one for file copy, one for customer copy, one provider copy. Customer and provider copies are sent to the Mail Room. File copy doesn’t get printed. All three copies are stored in Mobius. Report IDs are also based on number of pages. A report ID type distinguishes each Report ID.
The mail room cannot put more than 10 pages (2-sided) in an envelope. The printed document language will be restricted to English, Spanish or both based on the document recipient’s language preference.
Mail Processing
Mail Processing steps are existing DHS mass mailing steps and will be leveraged by CCMS. For the forms that are printed, the mail processing steps involve collating, sorting, envelope inserting and mailing.
For CCMS, “Processing by Print Subsystem and Mobius” and “Mail Processing” are black boxes developed and supported by DHS. Mass Mailing, therefore, is considered an interface between CCMS and this “black box”.
The following tables provide a list of CCMS mass mailed forms and characteristics pertaining to mass mailing.
Forms that require CCMS Mass Mailing functionalityForm Name / Currently Mass Mailed in CCTS / Requires MIS to change current process to point to CCMS database / Mass Mailing Trigger / Regular Monthly, Regular Daily or On demand Daily
Child Care Redeterminaton / Yes / Yes / Monthly - Create for every active case whose eligibility is ending not later than the end of next month. Few more rules are defined in the existing MIS batch program. Run Monthly on First Friday.To specify a daily on demand pick up for mass mailing the CCMS user would enter a short approval period (i.e., set eligibility to expire early and at the end of next month). / Monthly on First Friday and Daily On Demand
Request for Child Care Provider Change / No / No / Staff requests it by clicking on a button / On Demand Daily
Change of Information / No / No / Staff requests it by clicking on a button / On Demand Daily
Request for Additional Information / No / No / Staff requests it by clicking on a button / On Demand Daily
Authorization for Background Check1 / No / No / Staff requests it by clicking on a button / On Demand Daily
Relative Background Check Letter1 / No / No / Staff requests it by clicking on a button. Provider type of care 765 & 767 receive this cover letter. / On Demand Daily
Non-relative Background Check Letter1 / No / No / Staff requests it by clicking on a button. Provider type of care 764 & 766 receive this cover letter. / On Demand Daily
Approval / Yes / Yes / Staff requests it by clicking on a button / Daily on Demand
Denial / Yes / Yes / Staff requests it by clicking on a button / Daily on Demand
Cancellation / Yes / Yes / Monthly - Create for every active case whose eligibility is ending not later than the end of next month. Few more rules are defined in the existing MIS batch program. Run Monthly on First Friday.To specify a daily on demand pick up for mass mailing the CCMS user would enter a short approval period (i.e., set eligibility to expire early and at the end of next month). / Monthly on First Friday and Daily On Demand
Provider Closeout / Yes / Yes / Staff requests it by clicking on a button / Daily on Demand
Cancellation for child aged 13 / Yes / Yes / Monthly - Create for every active case whose eligibility is ending not later than the end of next month. Few more rules are defined in the existing MIS batch program. Run Monthly on First Friday.To specify a daily on demand pick up for mass mailing the CCMS user would enter a short approval period (i.e., set eligibility to expire early and at the end of next month). / Monthly on First Friday
1Authorization of Background Check plus Relative Background Check Letter is one Form; Authorization of Background Check plus Non-relative Background Check Letter is one Form
CCMS Mass Mailing Implementation RequirementsForm Name / Requires MIS to change current process to point to CCMS database / Requires MIS to change current Elixir template / Requires Deloitte to develop batch program to produce print strings that feed into MIS print subsystem / Requires MIS to enhance the print subsystem and Mobius
Child Care Redeterminaton / Yes / Yes / No / Yes
Request for Child Care Provider Change / No / No / Yes / Yes
Change of Information / No / No / Yes / Yes
Request for Additional Information / No / No / Yes / Yes
Authorization for Background Check / No / No / Yes / Yes
Relative Background Check Letter / No / No / Yes / Yes
Non-relative Background Check Letter / No / No / Yes / Yes
Approval / Yes / Yes / No / Yes
Denial / Yes / Yes / No / Yes
Cancellation / Yes / Yes / No / Yes
Provider Closeout / Yes / Yes / No / Yes
Cancellation for child aged 13 / Yes / Yes / No / Yes
Other Characteristics of Mass Mailed Forms
Form Name / Spanish Version? / Sort Order / Report ID / Form ID and Sequence Number / DJDE Info / Marks for Mailing / Printed or Viewed or Both? / Job #
Child Care Redeterminaton / Yes / Default: Zip+4
Other: TBD / Example: 2BPLM493
Actual: TBD / Form Number: IL444, Form ID: 3455E and 3455S; Sequence Number example: SEQ0001F; Actual: TBD / TBD / TBD / TBD / TBD
Request for Child Care Provider Change / No / Default: Zip+4
Other: TBD / TBD / Form Number: IL444, Form ID: 3455G / TBD / TBD / TBD / TBD
Change of Information / No / Default: Zip+4
Other: TBD / TBD / TBD / TBD / TBD / TBD
Request for Additional Information / Yes / Default: Zip+4
Other: TBD / TBD / Form Number: IL444, Form ID: 4480 / TBD / TBD / TBD / TBD
Authorization for Background Check / No / Default: Zip+4
Other: TBD / TBD / Form Number: IL444, Form ID: 4194 (R-1-11) / TBD / TBD / TBD / TBD
Relative Background Check Letter / No / Default: Zip+4
Other: TBD / TBD / TBD / TBD / TBD / TBD / TBD
Non-relative Background Check Letter / No / Default: Zip+4
Other: TBD / TBD / TBD / TBD / TBD / TBD / TBD
Approval / Yes / Default: Zip+4
Other: TBD / Example: 2BPLM493
Actual: TBD / TBD / TBD / TBD / TBD / TBD
Denial / Yes / Default: Zip+4
Other: TBD / Example: 2BPLM493
Actual: TBD / TBD / TBD / TBD / TBD / TBD
Cancellation / Yes / Default: Zip+4
Other: TBD / Example: 2BPLM493
Actual: TBD / TBD / TBD / TBD / TBD / TBD
Provider Closeout / Yes / Default: Zip+4
Other: TBD / Example: 2BPLM493
Actual: TBD / TBD / TBD / TBD / TBD / TBD
Cancellation for child aged 13 / Yes / Default: Zip+4
Other: TBD / Example: 2BPLM493
Actual: TBD / TBD / TBD / TBD / TBD / TBD
8.2.2Key Interface Decisions