CALPADS Know-It-All

CALPADS has adopted a new exit code E150 that is to be used in the event that a student enrollment has a grade level change.  So for example, a student who started the 14-15 year enrolled in 5th grade, after three weeks was assessed and determined to go back down to 4th grade, and the "Change Grade/Program" tool used to make that grade level change.

As you know, the "Change Grade/Program is one tool, but does two different functions (change Grade and/or change program).  Regardless of which option the user chooses, we always exit that enrollment record with an IRIS-1 exit code.

1. Change Grade Level:  In the described example above, let's say that the user has change grade level from 5th back to 4th.  The tool will exit the 5th grade enrollment on X date with an IRIS-1 and start a new row/record for 4th grade effective the next available in-session date.
   • Problem:  Yes, if you leave the IRIS-1 exit code, the tool will not export the expected E150 code.  CALPADS expects an E150 here.
   • Solution:  Edit the enrollment record to adjust the IRIS-1 to the E150.  The export script isn't set up to automatically pull the E150 in the event that a grade level change has occurred with an IRIS-1 exit code.  We may have an automated solution at a later time.
2. Change enrollment attendance program:  This is the other path that the tool can take the user.  In this scenario, CALPADS does not care to report on program changes.
   • Problem:  No.
   • Solution:  Do nothing and leave the IRIS-1 exit code.  Please DO NOT replace the IRIS-1 with some other exit code or blank the exit code, because it will break our backend logic.  The IRIS-1 exit is a special code we've designed that needs to be in place so that we know that although the enrollment is broken, it still is continuous.

NEW this year - CALPADS previously did not collect this data therefore many charter schools previously set up a "district" called Charter however this year actual districts should be populated.  These codes can be managed in Code Management table called "Transfer Districts."  Once this is complete the student transfer record can be edited in Illuminate through Students > Transfer Details.

There generally are two types of transfers: Intradistrict vs. Interdistrict.

a.  Interdistrict transfer (From outside your district/school, the student in District A is granted a transfer to enroll at one of your school):  When adding a transfer record for the student, you're required to add a "From" district.  At the very top of that drop-down list, you will find all those Transfer Districts to choose from (these are Transfer Districts from Code Management).  So for example, Jane Doe lives Alameda Unified, but is granted a transfer to go to your school John Adams Elementary.  This is a scenario where you will add Alameda Unified as the "From".  The "To' field will also yield the same list of transfer districts and your internal school list.  You can choose John Adams Elementary.

b. Intradistrict transfer (Within your district, student lives in a location where School A is the expected home school, but the student is granted permission/transfer to go to School B for whatever reason):  When adding a transfer record for the student, you're required to add a "From" district.  At the very bottom of that drop-down list, you will find your internal school(s) to choose from.  So for example, John Doe lives in the Lincoln Elementary boundaries, but is granted a transfer to go to Washington Elementary.  This is a scenario where you will add Lincoln Elementary as the "From".  You can choose Washington Elementary within the "To" field.

How this all translates to CALPADS and SENR District of Residence (1.32):

a. Interdistrict transfer:  Because Transfer Districts are from code management, please review your Transfer District code set.  Please ensure that the Transfer District code has a the 7 digit County-District code for in the State ID Mapping area, for the academic year of concern.

b. Intradistrict transfer:  In the event that the From school is your internal school, the 7 digit County-District code from the "From" school will export.  Please ensure that your From school has a complete 14 digit CDS code for the "State Site ID" field.

Illuminate does have a field on the demographic details page (Met A-G Requirement: Y/N).  However, this field does NOT export into SENR 1.30.  It is possible that one day we may change to point field 1.30 to this field.  Until then, we do not use this field.

To successfully flag SENR field 1.30 (identifying if a student has met A-G) per student, the export is dependent on three things:

1. On the demographic details page, all students must have the Graduation Requirement Year populated.
2. "Met A-G Requirements" Y/N override is applied on Demographic Details page. If no override has been applied, then #3.
3. A Course Requirement must be created for the academic year in which that student is graduating.  In addition, the course requirement name must start with "CSU/UC Requirements".  We're very specific on the name and so anything else (ie. UC/CSU....) will not work.
   Within this requirement from step 1, you can create categories.  You should create a category for each letter (A-G).  If you're not sure about what each letter/subject means, please review the following link to the University of California A-G Requirements page (http://www.ucop.edu/agguide/a-g-requirements/).  Once your categories are created, within each category, you affiliate those CSU/UC courses from your course catalog that apply to that category.  For example, within your "A" category (History/Social Science), you'd want to affiliate all UC/CSU approved History/SS courses from your catalog.

The student based on their Graduation Requirement Year, will be applied to the matching CSU/UC requirement.  If the student has met all categories (A-G), then the export will produce the Y for field 1.30.  Otherwise, the student defaults to N for field 1.30.

Currently, only 2 attributes are being tied to a student to assign a SED status in Illuminate. California disaggreates the data with addtional attributes that then affiliate the SED status to the student, thus giving a different number than what you see in Illuminate.

After Census date, you have two options:

• Import into a Summary Assessment to use the information in custom reports, or
• Download 8.1
• Update and match the information to the programs.txt as necessary
• Submit to help to merge and update the existing program to match the most up to date information

Academic year specific programs:  Some programs are specific to only that academic year of reporting.  For example, Lunch program (free or reduced) data is one of those that CALPADS expects to start & end within each year and they don't want the data to overlap many years.  Makes sense because F/R lunch generally requires re-evaluation, etc.  So for this reason, the F/R lunch program export script to pull a lunch record only based on the current year's enrollment dates. 

• The following programs are academic-year specific programs: Free Lunch Program (181), Reduced Lunch Program (182), Transitional Kindergarten Program (185)

1. For example, the screenshot above shows student 61042 with a Free Lunch program starting on 10/03/2011.
2. When generating an SPRG for the 14-15 year, the export produces the Free Lunch program (181) with the Start Date (7/01/2014) to End Date (6/30/2015).
3. When you cross reference enrollment, the export is exporting the 2014-2015 enrollment Entry Date for the program Start Date and assumed Term End Date for the program End Date.

Continuous Programs:  Contrary to academic-year specific programs, you have for example the 504 program (101) that is continuous and doesn't necessarily need to be closed out every year.  CALPADS expects that as soon as a student leaves a school and starts a new school, then the program should also reflect that change.  So when you generate an SPRG today, we make an attempt to pull Start/End dates as far back as possible, comparing the program dates with enrollment.

• The following programs are continuous:  Special Ed Program (144), Migrant Ed Program (135), Title I Part A Basic (122), GATE (127), 504 Program (101), Homeless Program (191).

1. If you reference the student 62064 who has a current GATE program effective 8/11/2010.
2. When generating the SPRG for 14-15, the GATE program record exports a Start Date of 8/8/2012.
3. Comparing this Start Date with the student's enrollment and based on the student's current school, the student was continuously enrolled in that school back to 8/8/2012.  Although the student started GATE while enrolled in Elementary, the export will not pull the exact Start Date from the program record.  This rule is to adhere to CALPADS current way of storing program data (School > Program > Start Date > End Date).

• Because enrollment is closely tied to programs, exit codes make a big impact on whether a program is continuous or true break.  If a valid CALPADS exit code (other than IRIS-1, E155) is used to end/close an enrollment record, the exit code breaks the enrollment and the program Start Date may be different.  Only those two exit codes (IRIS-1, E155) are the ones to determine that an enrollment/program is continuous and possibly goes back further.

You uploaded your SPRG data to CALPADS and WHAM!  You received hundreds of errors back from CALPADS complaining about an "Open Education Program record exists with Different Membership Start Date".  In looking closer, Illuminate is producing a program start date for the student(s) that is doesn't match the current open program record in CALPADS.

1. If you've got a small number of errors, you can make manual edit of the students' current program in CALPADS.  However, please be extremely careful that you edit the program to End Date accordingly.
2. There's no way that you will be able to manually correct all those mismatching discrepancies?  Who you gonna call?  Does Illuminate have any reconciliation tool to help out?   Yes, indeed Illuminate does.  Please follow this link here to review and understand our SPRG Reconciliation Tool.

Special Ed historical data is not stored in Illuminate. If a student disability changes, you would go to the Student Special Ed page and change the start date to reflect the start date of the new disability.  We encourage our clients who are not using our SPED product to store historical special ed data in the system they are using, such as SEIS for example.



If you need to track disability changes for special ed students in Illuminate, you can use Student Programs to track that information. Student Programs would reflect historical start/end dates for all disability changes for a student. Please NOTE that student programs does not report special ed data to CALPADS. Only the data on the special ed student page is reported to CALPADS. 

Because SPED 144 program is auto-derived based on the primary disability that is in Spec Ed tab, we don’t have historical tracking if a student should end an IEP and start a new. Best practice is recommended to be the following:

1. To put the original Disability and start date & End Date in the Spec Ed tab for that student.
2. Export an SPRG, which should contain that data.
3. The SPRG export should now contain that SPED program record that is reflected in Spec Ed tab. This data should upload into CALPADS and close off the existing program record in CALPADS.
4. In Illuminate, come back and enter the new IEP/Disability in the Spec Ed tab.

In the event that a student's English Prof. = EO, then we will export the following dates (whichever comes first, and we will use that date to compare).

1. State School Entry Date (Language details page)
2. US Entry Date (Language details page)
3. US School Entry Date (Language details page)
4. District Enter Date (demographic details page)
5. School Enter Date (demographic details page)

So for example, if you generate a SELA report using the dates of 8/15/2014 - 11/17/2014.

1. Does the student have a State School Entry Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and State School Entry Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

2. Does the student have a US Entry Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and US Entry Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

3. Does the student have a US School Entry Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and US School Entry Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

4. Does the student have a District Enter Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and District Enter Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

5. Does the student have a School Enter Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and School Enter Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

Concern 1: This will mean that the exports will not include an EO student who has a State School Entry Date of, for example 8/1/2005.  This student is new to my district this year and I need to submit the student's EO status.

Basically, if the student truly has a State School Entry Date of 8/1/2005, that first CA district who enrolled that student in 2005, should have added the status for the student.  If not and the student somehow never had a status reported, then please ensure that the student has a State School Entry Date populated in Illuminate, that falls within your report date range.

Concern 2:  I see within CALPADS, that the student currently has an EO status effective X date that is owned by District 1.  But doesn't CALPADS require/need that I add an EO record for my district/LEA, with a new effective date?

CALPADS currently only allows for one EO status, regardless of which LEA owns that EO record in CALPADS.  CALPADS will NOT allow you to add a new EO record that is owned by you, if that status already is present.  Oddly, CALPADS is a bit buggy too in that you may actually find some student scenarios where there are overlapping same status, from different districts/owners.

Concern 3: So it seems that this logic should only pull new EO students, such as TKs and Kinders?

That's correct.  If you think about it for example, a new Kinder student should have a State School Entry Date that is pretty recent.  If the student started Kinder with you on 8/25/2014, then most definitely the State School Entry Date should be equal to that (or somewhere within range).  Having a State School Entry Date of 8/25/2014 and assuming you generate your report from 8/25/2014 - 11/1/2014, the export will find this student and export.

Concern 4: It seems that the State School Entry Date is the best match.  Why do I need to bother with all those other fields (US Entry Date, US School Enter Date, etc)?

If you do have the State School Entry Date populated for all your students, you're definitely correct that you don't have to deal with our logic of looking at those other fields.  Those fields were added into the formula as backups, in case you don't have a State School Entry Date populated.  We have plans to take away those other fields and making State School Entry Date the only field to compare against the report dates.

Recommendation:

For students new to the district but not new to CA, there should only be one initial Home Language Survey.  If a new Home Language Survey is collected by the new district  and the student is incoming from another CA school district, then the EL status should be verified with the previous district or by looking up the EL status in CALPADS to ensure the data is consistent from district to district.

CALPADS expects that Illuminate export only students who have changes in English Proficiency status going forward.  Illuminate will search for all students who matches the following logic, using the sample dates of 8/15/2014 - 11/17/2014:

• When the student's English Proficiency = (EL or TBD) and the LEP Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the EL/TBD status, and LEP Date as the SELA Effective Start Date.
• When the student's English Proficiency = IFEP and the FEP Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the IFEP status, and FEP Date as the SELA Effective Start Date.
• When the student's English Proficiency = RFEP and LEP Date is not blank and the Reclassification Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the RFEP status, and Reclassification Date as the SELA Effective Start Date.

Behind the scenes, the 3 fields above are tracked per academic year.  If you toggle your Control Panel to the 2014-2015 year, then these 3 fields will yield the data per that year.  While in that academic year, these 3 data elements should reflect what the user is/should be for that year of reporting.  If this data is missing for YYYY academic year, then that year's SDEM export will be missing these 3 data elements.  So please ensure that your control panel is set to the correct academic year (doesn't matter what school/district) prior to adjusting this data.

• Previous clients:  If you used Illuminate the previous year and assuming you did submit this data then to CALPADS, logging into the new year will not copy this data over for all your users (ie. same Position Status, +1 to Yrs Service, +1 to Yrs District).  There is no process that will populate your new year with this new data.  Our developers have created a script that will copy (same Position Status, +1 to Yrs Service, +1 to Yrs District) from the previous year to current.  The script will only rollover this info if the user has the data in the previous year.  This will be a one time request and if this is your scenario, please email help@illuminateed.com to make this request.

• Start Date:  Please ensure that you enter (at best), the date of when the user began this Job Classification and/or Assignment at the Site specified.
• End Date: For this Job Class/Assignment and user, if the user is expected to end on a certain date, please input the date.  Otherwise, if the user is expected to continue with this same Job Class/Assignment from one year to next, please leave the End Date blank.  A blank date is interpreted as continuous and will yield the same Job Class/Assignment next year for the user.  This will avoid having to rollover or re-enter the same data.

To successfully flag CRSE/CRSC field 9.13 (identifying a course as CSU/UC compliant), the export is dependent on one thing.  This same logic is also applied to SENR field 1.30.

1. A Course Requirement must be created for the academic year in which you are generating/submitting.  In addition, the course requirement name must start with "CSU/UC Requirements".  We're very specific on the name and so anything else (ie. UC/CSU....) will not work.
   Within this requirement from step 1, you can create categories.  You should create a category for each letter (A-G).  If you're not sure about what each letter/subject means, please review the following link to the University of California A-G Requirements page (http://www.ucop.edu/agguide/a-g-requirements/).  Once your categories are created, within each category, you affiliate those CSU/UC courses from your course catalog that apply to that category.  For example, within your "A" category (History/Social Science), you'd want to affiliate all UC/CSU approved History/SS courses from your catalog.

If the course is assigned to one or more categories within this requirement, this field will export a "Y".  Otherwise, "N".

• If you generate an SDIS report and you get no results, more than likely the problem/solution may be the following.  Pay special attention to rules #5 and #6 above.  If there should be any Violation or Consequence codes that do not have State ID Mappings for the given academic year, will filter out those behavior/participant records that tie to that Violation or Consequence.
  • For example, within an incident a student received X consequence (ie. After School).  The consequence value does not have a State ID Mapping for the year.  Per our report filters, this consequence for this student will not export on the SDIS.
• While you are not required to report summer school enrollments, you are required to report out summer school behavior incidents as you would in the normal school year. On the May 14 EOY calpads call they recommended that you manually add a secondary enrollment for the student(s) involved for the day of the incident and use a T160 exit code. All behavior incidents that happen between July 1, 2014 and June 30, 2015 will need to be reported in the 2015 school year. All behavior incidents that happens between July 1, 2015 and June 30, 2016 will be reported in the 2016 school year.
• The logic for field 4.21 is as follows: If, on Disciplinary Incident Occurrence Date, Education Program Code = 144 (Special Education) and Incident Disciplinary Action Taken Code is not equal to 300 (No Suspension or Expulsion) Then Y; Else N. This logic is being applied in the script and should return a Y or N where appropriate.
• Illuminate allows for multiple Consequences to be entered. However, CALPADS requires that only the most recent (latest) reportable Consequence to be submitted. For this reason, Illuminate will be pulling only the latest reportable Consequence record. If there are multiple consequences and they ALL have the same 'Date Assigned', the system will pick one at random to include in the extract. The consequence with the later date assigned will populate in the extract.

CALPADS requires that all 11th or 12th grade students enrolled in CTE courses be designated as CTE participants, concentrators, or completors for a given pathway.

• Participants are 11th or 12th grade students enrolled in any CTE designated course.
• Concentrators are 11th or 12th grade students who have completed at least 50% of the required courses for a particular CTE pathway, and are enrolled in the next course.
• Completers are 11th or 12th grade students who have completed all of the required courses for a particular CTE pathway.

These can be designated in Illuminate as follows:

1. Navigate to Students > General > CTE Pathways.
2. Search for and select the student for which you would like to add a pathway.
3. Select "Add CTE Pathway"
4. This will return a "Student CTE Pathways" form with two fields. Please fill these out as follows:
   • To designate the student as a Participant, you do not need to do anything. This information is pulled from the course information.
   • To designate the student as a Concentrator, select the pathway from the pathway dropdown, and click the save button. The Academic Year field should be left blank.
   • To designate the student as a Completer, select the pathway from the pathway dropdown, and select the academic year from the Academic Year dropdown. This should be the academic year during which the pathway was completed. Once both fields are populated, click the save button.

Additional Notes:

• A student can be participating in multiple CTE pathways at one time, and be in different stages in each one.