Alternative and Supplemental Services Domain - Best Practices

Definitions and Key Concepts

The Alternative and Supplemental Services domain covers a variety of program service offerings by educational institutions. A program refers to a school sponsored or approved recurring activity, event or function, on- or off-school premises, where students are under the jurisdiction of the local education agency (LEA) or are supervised by school staff. Programs may provide supplemental instruction, training, services, or benefits. Programs may also include organized extracurricular activities for students.

The intent of the domain is to support the common federally-sponsored programs, such as special education, language instruction for English language learners (ELL), or career and technical education (CTE); as well as to provide a common pattern that can be used for any other federal, state, or local programs. Key characteristics of a program are as follows:

• Programs are officially designated by a sponsoring education organization and given a unique name.
• Programs often have eligibility requirements that must be met by participating students.
• Students are assigned or enrolled in a program for a period of time, with an explicit BeginDate and EndDate.
• Instructional or non-instructional service(s) are typically provided to a student in the context of a program.
• Staff are assigned to a program for a period of time.

Students explicitly are enrolled or assigned to a program. Eligibility may be a simple determination, may require expert opinion, or may require a formal assessment. Assignments to a program may occur as part of the school enrollment process or may occur anytime during the school year.

Most students’ participation in programs occurs in the school where the student is primarily enrolled, Sometimes to receive services not offered in the student’s primary enrollment school, a student may be assigned to participate in a program at another school or education organization. By policy, these situations may or may not require secondary enrollment in the school where the student is receiving services. The Ed-Fi security model supports both cases, with or without secondary enrollment.

Program information may be collected, stored and loaded into the API/ODS from different sources:

• Student information systems(s) may capture and manage students’ participation in designated programs
• Specialized applications exist for specific programs, most notably special education, language instruction, and school food service.
• In some cases, program participation is maintained in files and spreadsheets that must be manually uploaded.

Alternative and Supplemental Services Use Cases

The various use cases associated with student enrollment process span several Ed-Fi domains as shown below.

Primary Use Cases	Ed-Fi Domains Needed to be Utilized for the Use Case
Education organization designation of the program(s) to be offered to students	Alternative and Supplemental Services
Student evaluation for participation in a program Student selection and enrollment for participation in a program based upon evaluation of eligibility	Student Program Evaluation Alternative and Supplemental Services
Student enrollment for participation in program in the same school primarily enrolled Student enrollment in a program in a school different from the student’s primary enrollment Student transfer to a program offered in another school as part of transferring schools Student exit or withdrawal from a program	Alternative and Supplemental Services
Student secondary registration for a school to participate in a program Exit or withdrawal from school and associated programs	Student Identification and Demographics Student Health Enrollment Alternative and Supplemental Services
Staff assignment to a program Staff exit from a program	Alternative and Supplemental Services
Attendance for a program and/or receipt of services	Student Attendance Alternative and Supplemental Services
Participation in a program as part of section instruction	Teaching and Learning Alternative and Supplemental Services

These best practices focus on the Alternative and Supplemental Services domain, consisting of the following entities and associations:

• A Program entity, which defines programs with services offered by an education organization.

• A StaffProgramAssociation which links Program entities to assigned staff.

• A StudentProgramAssociation (SPA) entity, which links Program entities to participating students – when a subclass is not used and minimal information is needed.

• GeneralStudentProgamAssociation with predefined subclasses for major US K–12 federal program areas, as follows:

  • StudentCTEProgramAssociation
  • StudentHomelessProgramAssociation
  • StudentLanguageInstructionProgramAssociation
  • StudentMigrantEducationProgramAssociation
  • StudentNeglectedOrDelinquentProgramAssociation
  • StudentSchoolFoodServiceProgramAssociation
  • StudentSection504ProgramAssociation
  • StudentSpecialEducationProgramAssociation
  • StudentTitleIPartAProgramAssociation

  New subclasses of the GeneralStudentProgramAssociation may be defined using the Ed-Fi extension mechanism. Subclasses of the GeneralStudentProgramAssociation are generically referred to as StudentXxxProgramAssociations (SXPA) (where “Xxx” represents the name of the program).

Please consult the other related domains above for best practices on entities in those domains. As summarized above, the Alternative and Supplemental Services domain addresses student program participation and receipt of services, as part of the following primary use cases:

Ed-Fi Prerequisites for Writing Alternative and Supplemental Services Domain Entities

The Alternative and Supplemental Services domain has dependencies on other data that should be entered into the Ed-Fi API/ODS prior to entering program definition and student program enrollment information, as follows:

• Yearly API/ODS setup. The best practice convention has a separate API/ODS for each school year. This means that program enrollments and participation recorded in the StudentProgramAssociation or the StudentXxxProgramAssociation must be written for each school year.

• Descriptor values need to be loaded. The Alternative and Supplemental Services domain has dependency on several sets of descriptors. Many of these will be custom descriptors that need to map to current operational program practices and reporting. Default descriptors for the Federally defined programs are provided that are based upon the reporting code for those programs.

  • Program
    • ProgramCharacteristic
    • ProgramSponsor
    • ProgramType
  • StudentProgramAssociation
    • Service
  • GeneralStudentProgramAssociation and inherited by all subclasses
    • ParticipationStatus
    • ReasonExited
  • StudentCTEProgramAssociation
    • CTEProgramService
    • TechnicalSkillsAssessment
  • StudentHomelessProgramAssociation
    • HomelessPrimaryNighttimeResidence
    • HomelessProgramService
  • StudentLanguageInstructionProgramAssociation
    • LanguageInstructionProgramService
    • Monitored
    • Participation
    • Proficiency
    • Progress
  • StudentMigrantEducationProgramAssociation
    • ContinuationOfServicesReason
    • MigrantEducationProgramService
  • StudentNeglectedOrDelinquentProgramAssociation
    • NeglectedOrDelinquentProgram
    • NeglectedOrDelinquentProgramService
    • ELAProgressLevel
    • MathematicsProgressLevel
  • StudentSchoolFoodServiceProgramAssociation
    • SchoolFoodServiceProgramService
  • StudentSection504ProgramAssociation
    • Section504Disability
  • StudentSpecialEducationProgramAssociation
    • SpecialEducationSetting
    • Disability
    • SpecialEducationProgramService
    • SpecialEducationExitReason
  • StudentTitleIPartAProgramAssociation
    • TitleIPartAParticipant
    • TitleIPartAProgramService

• EducationOrganizations, minimally Schools and LocalEducationAgency(s), need to be created for the scope of the ODS.

• As being part of the key for SPA or SXPA entities, a Student record needs to be written before program assignment associations.

• Depending on policy, a StudentSchoolAssociation (SSA) may or may not be required prior to a SPA or SXPA being written for a specific student and school.

Alternative Patterns for the Alternative and Supplemental Services Domain

There are three alternative patterns for using the Alternative and Supplemental Services domain, as follows:

1. Use of a pre-defined StudentXxxProgramAssociation (SXPA) for Federal programs, specifically for CTE, Homeless, Language Instruction, Migrant Education, Neglected Or Delinquent, School Food Service, Special Education, and Title I Part A programs. The attributes of these programs have been defined to map to federal reporting requirements.
2. Use the Ed-Fi extension mechanism to define a new SXPA as a subclass of the GeneralStudentProgramAssociation and add attributes appropriate for that program.
3. For simple programs not requiring program-specific attributes, use the StudentProgramAssociation (SPA) to denote the assignment of students to the program.

For a specific Program, only one of these patterns is used, depending on the requirements. Alternatives 1 and 2 use the extension pattern shown in the figure below. Note the diagram is expanded to depict selective multi-valued commons defined in the entities.

Alternative and Supplemental Services Domain Anti-Patterns

An anti-pattern is an observed practice for a recurring situation that is not recommended.

Misuse of the StudentProgramAssociation

As noted above, the use of the StudentProgramAssociation (SPA) is meant to associate students via a simple assignment to programs (not requiring program-specific attributes). An anti-pattern has been observed where both the SPA and an SXPA (subclasses of the GeneralStudentProgramAssociation) are written for the same program assignment to a student. This pattern is incorrect and should not be used. The intent is that there is only one SPA or one SXPA for each assignment of a student to a specific program.

Multi-Year StudentProgramAssociations or StudentXxxProgramAssociations

Public schools operate on a school year basis that defines the typical increment of grade-level instruction. Alternative or supplemental programs are offered within the context of school years, and a student’s assignment to a program occurs in the context of a school enrollment.

An anti-pattern is observed where student assignments to programs using the SPA or SXPA span multiple school years. In these cases, the BeginDate reflects the first assignment to the Program and the EndDate reflects the last day of assignment, even if it ends several school years later.

The recommended best practice for multi-year participation in a program is to end the SPA or SXPA at the end of each school year and create another for the next school year. A student should have minimally one SPA or SXPA per program per school year.

Alternative and Supplemental Services Domain Best Practices

The following best practices are organized by entity and association in the Alternative and Supplemental Services domain.

Program

The Program entity defines the programs which provide supplemental instruction, training, services, or benefits to students by an education organization. The following table summarizes the best practice use of the Program attributes.

Required	Must Have	Recommended	As Needed
ProgramName (key) ProgramType (key) EntrEducationOrganization Date (key)		ProgramId ProgramSponsor	ProgramCharacteristic LearningStandard

Keys in reading the table and following ones:

• Required attributes in Ed-Fi are hard constraints, meaning that a record or API payload will be rejected if the attribute is not present. These necessarily include key values.
• Must Have attributes are those whose intended use of the entity requires them to be used, even if, upon creation, they may not be present.
• Recommended attributes are those whose best practices encourage their use.
• As Needed attributes are those that should be used when appropriate, based upon policy.

Business Rules that considered as best practices for the usage of the Program are as follows

info

• A Program is created for each designated program offered at an education organization.
• The ProgramName, as part of key, should be descriptive, popularly used and recognized, as well as unique. Assigned identifiers should be stored in the ProgramId attribute.
• Program.EducationOrganization should be set to the education organization at the right level of granularity for each program offering. Typically, the Program.EducationOrganization is at the LocalEducationAgency (LEA) level for programs offered across the district. For Programs that are only offered by a school, the Program.EducationOrganization references the School. For Programs that are offered by an EducationServiceCenter (ESC), the Program.EducationOrganization references that ESC.

StaffProgramAssociation

The StaffProgramAssociation indicates the staff assigned to a program, including those providing services directly to students as part of the program. An active staff program assignment is one with a BeginDate and no EndDate, meaning the staff is still assigned to the program. The following table summarizes the best practice use of the StaffProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Staf (key) Program (key) BeginDate (key)	EndDate		StudentRecordAccess

Business Rules that considered as best practices for the usage of the StaffProgramAssociation are as follows

info

• A StaffProgramAssociation is created for each staff assignment to a program.
• Minimally, one StaffProgramAssociation is created for each assigned staff per school year.
• At any point in time, a staff should have no more than one active StaffProgramAssociation for a single program associated with an education organization.
• The EndDate of a StaffProgramAssociation must be equal or after the BeginDate.

GeneralStudentProgramAssociation

The GeneralStudentProgramAssociation is the base abstract class for the subclasses StudentProgramAssociation (SPA) and all StudentXxxProgramAssociations (SXPAs), including those defined for the Federal programs and any custom extensions. As such, the GeneralStudentProgamAssociation defines the keys and common attributes for the SPA and all predefined or extended SXPAs.

The following table summarizes the best practice use of the GeneralStudentProgramAssociation attributes that are inherited by the SPA and the SXPA. The following table summarizes the best practice use of the GeneralStudentProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student (key) Program (key) BeginDate (key) EducationOrganization (key)	EndDate ReasonExited		ServedOutsideOfRegularSession ProgramParticipationStatus

Business Rules that considered as best practices for the usage of the GeneralStudentProgamAssociation are as follows

info

• An SPA or an SXPA is created for each student assignment to a program.
• Minimally, one SPA or SXPA is created for each assigned student per school year.
• At any point in time, a student should have no more than one active SPA or SXPA for a single program associated with an education organization.
• It is possible for a student to be assigned to a program in a school different than the student's primary school enrollment. Depending on policy, a secondary enrollment StudentSchoolAssociation (SSA) may be required.

For the SPA or SXPA, the BeginDate and the EndDate define the period of assignment or participation in the program. As part of the key inherited from the GeneralStudentProgamAssociation each SPA or SXPA for a student must have a BeginDate. An active program assignment is one with a BeginDate and no EndDate, meaning the student is still assigned and participating in the program.

info

• The EndDate of a SPA or SXPA must be equal or after the BeginDate.
• If a student exits from a program during the school year and then is reassigned in the same program, multiple SPA or SXPA records are created, one for each period of assignment and participation.
• Active program assignments at the same education organization should not overlap, meaning that prior enrollments should have an EndDate equal to or before the BeginDate of the next.
• Multiple SPA or SXPA records for a student assigned to a program with the same education organization should not be combined, even if the EndDate of one is the same as the BeginDate of the next.
• If a SPA or SXPA has an EndDate, it should have ReasonExited value.

The ProgramParticipationStatus common is used to track the student's participation in the program, such as whether the student is deemed eligible, not eligible, or is active in the program, or not. The ParticipationStatus descriptor should be customized to reflect the program statuses that are important to track. The dates of student's ParticipationStatus are reflected by a StatusBeginDate and a StatusEndDate. There is no requirement that a student only be designated a single ParticipationStatus at a time, allowing flexibility in the use. A ParticipationStatus with a StatusBeginDate and no StatusEndDate means the status is still active for that student.

info

• The ProgramParticipationStatus.StatusEndDate of a SPA or SXPA must be equal or after the ProgramParticipationStatus.StatusBeginDate.
• The ProgramParticipationStatus.StatusBeginDate and ProgramParticipationStatus.StatusEndDate may need to be contained within the BeginDate and EndDate of a SPA or SXPA when the ParticipationStatus descriptor value is associated with a student's status during assignment to the program. The exception is when the ParticipationStatus descriptor value is associated with preceding activities such as evaluation or eligibility.

StudentProgramAssociation (SPA)

For simple program assignments not requiring program-specific attributes, the SPA is used to denote the assignment of students to the program. By referring to different programs, the SPA may be used to denote assignment to many different programs. Caution should be noted in the use of the StudentProgramAssociation.Service because the descriptor values must cover all of the programs that use this pattern. The following table summarizes the best practice use of the SPA attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited**	ProgramParticipationStatus**	ServedOutsideOfRegularSession** Service

** Indicates attributes inherited from the GeneralStudentProgramAssociation

info

• Since the Services descriptor must cover all uses of the SPA, the best practice is not to use the Services attribute of the SPA. An SXPA (either in core or by extension) is typically used when the services provided to a student are specified.

StudentCTEProgramAssociation

The StudentCTEProgramAssociation denotes the career and technical education (CTE) program(s) that a student participates in. The association supports the implementation of the Perkins Career and Technical Education Act.

The StudentCTEProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply. The following table summarizes the best practice use of the StudentCTEProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** TechnicalSkillsAssessment CTEProgramService	ProgramParticipationStatus** PrivateCTEProgram	ServedOutsideOfRegularSession** NonTraditionalGenderStatus

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentCTEProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentCTEProgramAssociation to support the implementation of the program.

info

• The CTEProgramService.ServiceEndDate must be equal or after the CTEProgramService.ServiceBeginDate for a specific CTEProgramService.
• The CTEProgramService.ServiceBeginDate and CTEProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentCTEProgramAssociation.

StudentHomelessProgramAssociation

The StudentHomelessProgramAssociation indicates the homeless program(s) that a student from which the student receives services. The association supports the implementation of the McKinney-Vento Homeless Assistance Act.

The StudentHomelessProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** HomelessPrimaryNighttimeResidence HomelessUnaccompaniedYouth HomelessProgramService	ProgramParticipationStatus** PrivateCTEProgram	ServedOutsideOfRegularSession** AwaitingFosterCare

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentHomelessProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentHomelessProgramAssociation to support the implementation of the program.

info

• The HomelessProgramService.ServiceEndDate must be equal or after the HomelessProgramService.ServiceBeginDate for a specific HomelessProgramService.
• The HomelessProgramService.ServiceBeginDate and HomelessProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentHomelessProgramAssociation.

StudentLanguageInstructionProgramAssociation

The StudentLanguageInstructionProgramAssociation indicates the language instruction program(s) for English learners and immigrant students from which the student receives services. The association supports implementation of Title III Language Instruction for Limited English Proficient and Immigrant Students.

The StudentLanguageInstructionProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply. The following table summarizes the best practice use of the StudentLanguageInstructionProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** EnglishLanguageProficiencyAssessment EnglishLearnerParticipation LanguageInstructionProgramService	ProgramParticipationStatus** Dosage	ServedOutsideOfRegularSession**

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentLanguageInstructionProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentLanguageInstructionProgramAssociation to support the implementation of the program.

info

• The LanguageInstructionProgramService.ServiceEndDate must be equal or after the LanguageInstructionProgramService.ServiceBeginDate for a specific LanguageInstructionProgramService.
• The LanguageInstructionProgramService.ServiceBeginDate and LanguageInstructionProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentLanguageInstructionProgramAssociation.

StudentMigrantEducationProgramAssociation

The StudentMigrantEducationProgramAssociation indicates the migrant instruction program(s) from which the student receives services. The association supports implementation of the Title I, Part C: Migrant Education Program (MEP).

The StudentMigrantEducationProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** PriorityForServices QualifyingArrivalDate EligibilityExpirationDate ContinuationOfServicesReason MigrantEducationProgramService	ProgramParticipationStatus** LastQualifyingMove USInitialEntry USMostRecentEntry USInitialSchoolEntry StateResidencyDate	ServedOutsideOfRegularSession**

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentMigrantEducationProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentMigrantEducationProgramAssociation to support the implementation of the program.

info

• The MigrantEducationProgramService.ServiceEndDate must be equal or after the MigrantEducationProgramService.ServiceBeginDate for a specific MigrantEducationProgramService.
• The MigrantEducationProgramService.ServiceBeginDate and MigrantEducationProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentMigrantEducationProgramAssociation.

StudentNeglectedOrDelinquentProgramAssociation

This StudentNeglectedOrDelinquentProgramAssociation indicates the Neglected or program(s) from which the student receives services. The association supports the implementation of the Title I, Part D program for the Prevention and Intervention Programs for Children and Youth Who Are Neglected, Delinquent or At Risk.

The StudentNeglectedOrDelinquentProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply. The following table summarizes the best practice use of the StudentNeglectedOrDelinquentProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** NeglectedOrDelinquentProgram ELAProgressLevel MathematicsProgressLevel NeglectedOrDelinquentProgramService	ProgramParticipationStatus**	ServedOutsideOfRegularSession**

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentNeglectedOrDelinquentProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentNeglectedOrDelinquentProgramAssociation to support the implementation of the program

info

• The NeglectedOrDelinquentProgramService.ServiceEndDate must be equal or after the NeglectedOrDelinquentProgramService.ServiceBeginDate for a specific NeglectedOrDelinquentProgramService.

• The NeglectedOrDelinquentProgramService.ServiceBeginDate and NeglectedOrDelinquentProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentNeglectedOrDelinquentProgramAssociation.

StudentSchoolFoodServiceProgramAssociation

The StudentSchoolFoodServiceProgramAssociation indicates the school food service program from which the student may receive free or reduced food services. The association supports the implementation of the National School Lunch Program, School Breakfast Program, and Special Milk Program.

The StudentSchoolFoodServiceProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply. The following table summarizes the best practice use of the StudentSchoolFoodServiceProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** DirectCertification SchoolFoodServiceProgramService	ProgramParticipationStatus**	ServedOutsideOfRegularSession**

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentSchoolFoodServiceProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentSchoolFoodServiceProgramAssociation to support the implementation of the program.

info

• The SchoolFoodServiceProgramService.ServiceEndDate must be equal or after the SchoolFoodServiceProgramService.ServiceBeginDate for a specific SchoolFoodServiceProgramService.

• The SchoolFoodServiceProgramService.ServiceBeginDate and SchoolFoodServiceProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentSchoolFoodServiceProgramAssociation.

StudentSection504ProgramAssociation

The StudentSection504ProgramAssociation indicates the students that qualify for special disability accommodation per Section 504 of the Rehabilitation Act of 1973.

The StudentSection504ProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply. The following table summarizes the best practice use of the StudentSection504ProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key) Section504Eligibility	EndDate** ReasonExited** Section504DisabilityType	ProgramParticipationStatus** AccommodationPlan Section504MeetingDate Section504EligibilityDecisionDate	ServedOutsideOfRegularSession**

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentSection504ProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Section 504 Federal regulations but relate to the use of the StudentSection504ProgramAssociation to support the implementation of the program.

info

• If the StudentSection504ProgramAssociation.AccommodationPlan is TRUE the StudentSection504ProgramAssociation.Section504Eligibility must be TRUE.
• The StudentSection504ProgramAssociation.Section504MeetingDate or the StudentSection504ProgramAssociation.Section504EligibilityDate may precede, equal or follow the StudentSection504ProgramAssociation.BeginDate.

StudentSpecialEducationProgramAssociation

The StudentSpecialEducationProgramAssociation indicates the special education program(s) from which students with disabilities receive services. The association supports the implementation of the Individuals with Disabilities Education Act (IDEA).

The StudentSpecialEducationProgramAssociation (SSEPA) inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply. The following table summarizes the best practice use of the StudentSpecialEducationProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** IdeaEligibility SpecialEducationSetting Disability MultiplyDisabled SpecialEducationExitDate SpecialEducationExitReason SpecialEducationProgramService SpecialEducationHours PerWeek SchoolHoursPerWeek LastEvaluationDate IEPReviewDate IEPBeginDate IEPEndDate	ProgramParticipationStatus** MedicallyFragile ServiceProvider	ServedOutsideOfRegularSession** SpecialEducationExitExplained

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentSpecialEducationProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentSpecialEducationProgramAssociation to support the implementation of the program.

info

• The SpecialEducationProgramService.ServiceEndDate must be equal or after the SpecialEducationProgramService.ServiceBeginDate for a specific SpecialEducationProgramService.
• The SpecialEducationProgramService.ServiceBeginDate and SpecialEducationProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentSpecialEducationProgramAssociation.

A separate StudentSpecialEducationProgramAssociation (SSEPA) should be created when the student’s participation in the Special Education program fundamentally changes. This can occur when the student is diagnosed with a different or additional disability, when the special education services setting or dosage change, and/or when a new Individualized Education Program (IEP) is defined. This is accomplished by writing an EndDate and an associated ReasonExited to indicate a change in program attributes. A new StudentSpecialEducationProgramAssociation is created with the new attribute values and with the same BeginDate.

info

• Recommended attributes whose change triggers a new StudentSpecialEducationProgramAssociation are: IdeaEligibility, SpecialEducationSetting, Disability, SpecialEducationHoursPerWeek, or IEPBeginDate.

Note that a new SSEPA is not needed when only the services that the student receives change, because these can be indicated using the SpecialEducationProgramService collection. However, when the services change, it often occurs when related special education program characteristics may change and trigger a new SSEPA.

The SSEPA attribute SpecialEducationExitDate, denotes the date the student exited the special education program and stopped receiving special education services altogether. Contrast this with the (inherited) EndDate of the SSEPA which denotes the end of the SSEPA which may the same as exiting the special education program or may be the end of an SSEPA where the student’s situation has changed or at the end of a school year, and be followed with a new SSEPA. An SSEPA with an EndDate but a null SpecialEducationExitDate means the SSEPA record is closed, but the student is still participating in the special education program.

info

• The EndDate of the SSEPA must be before or equal to the SpecialEducationExitDate, if it exists in the SSEPA.
• The attribute SpecialEducationExitReason descriptor value must be entered if there is a SpecialEducationExitDate.

The SSEPA attributes for IEPReviewDate, IEPBeginDate, and IEPEndDate relate to the dates associated with the most recent IEP. The semantics of an IEPBeginDate with a null IEPEndDate means that the IEP is still active. When a new IEP is created, the EndDate and the IEPEndDate of the current SSEPA is written and the ServiceEndDate set for any active services. A new SSEPA is created with new BeginDate, IEPBeginDate, and ServiceBeginDates, as appropriate.

info

• The IEPEndDate must be equal or after the IEPBeginDate.
• The SpecialEducationProgramService.ServiceEndDate must be before or equal to the EndDate and the SpecialEducationExitDate, if present.

StudentTitleIPartAProgramAssociation

The StudentTitleIPartAProgramAssociation indicates the type of Title I Part A programs and services that a student receives. The association supports the implementation of Title I, Part A: Improving Basic Programs Operated By Local Educational Agencies.

The StudentTitleIPartAProgramAssociation inherits the attributes and associations of the GeneralStudentProgramAssociation; as a result, the business rules above for the GeneralStudentProgramAssociation also apply. The following table summarizes the best practice use of the StudentTitleIPartAProgramAssociation attributes.

Required	Must Have	Recommended	As Needed
Student**(key) Program** (key) BeginDate**(key) EducationOrganization** (key)	EndDate** ReasonExited** TitleIPartAParticipant TitleIPartAProgramService	ProgramParticipationStatus**	ServedOutsideOfRegularSession**

** Indicates attributes inherited from the GeneralStudentProgramAssociation

Business rules that considered as best practices for the usage of the StudentTitleIPartAProgramAssociation are shown below. Note that the business rules do not deal with the specific rules of the Federal program but relate to the use of the StudentTitleIPartAProgramAssociation to support the implementation of the program.

info

• The TitleIPartAProgramService.ServiceEndDate must be equal or after the TitleIPartAProgramService.ServiceBeginDate for a specific TitleIPartAProgramService.
• The TitleIPartAProgramService.ServiceBeginDate and TitleIPartAProgramService.ServiceEndDate must be contained within the BeginDate and EndDate of a StudentTitleIPartAProgramAssociation.

A separate StudentTitleIPartAProgramAssociation should be created when the student’s participation in the type of Title I Part A program changes as denoted by the TitleIPartAParticipant descriptor value. This is accomplished by writing an EndDate and an associated ReasonExited to indicate a change in program attributes. A new StudentTitleIPartAProgramAssociation is created with the new attribute values and with the same BeginDate.

info

• Recommended attributes whose change triggers a new StudentTitleIPartAProgramAssociation is TitleIPartAParticipant.

Note that a new StudentTitleIPartAProgramAssociation is not needed when the services that the student receives change, because these can be indicated using the TitleIPartAProgramService collection.