Enrollment Domain - Best Practices
Content
Definitions and Key Concepts
Enrollment is the process of officially signing a student to attend and receive instruction in a school. Enrollment is a mature, well-documented process in schools that is well supported by Student Information Systems (SIS’s).
Enrollment processes differ from state to state, and even across local education agencies (LEAs), as laws, policies and procedures are tailored to meet local operational needs. These differences are accommodated by a SIS through the entry of different information, with customizable "codes" (termed "descriptors" in Ed-Fi), and with different workflows and business rules.
Ed-Fi provides a standard set of entities with attributes and associations that model the most common and most pertinent data associated with student enrollment. In Ed-Fi, customization of the enrollment data to match the local conventions in the SIS is accomplished through selective use of optional attributes and associations; customization of the set of allowable descriptor values; extensions to the enrollment model; and usage conventions and best practices like this documentation.
Necessarily, the enrollment process also includes the exit or withdrawal of a student from a school, grade level, and for a school year because there are many different situations where a student ends an enrollment. It is important to capture the appropriate reasons for exit/withdrawal.
Enrollment Process 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 |
---|---|
Application process requiring acceptance | Currently not supported in the core model. Applications are part of the Educator Preparation domain which is an extension created and shared by Ed-Fi Alliance. |
|
|
Evaluation for participation in a program | Student Program Evaluation |
| Alternative and Supplemental Services |
| Teaching and Learning |
Â
This article on the best practices relating the Enrollment domain has specific focus on the following entities as parts of the domain
The StudentSchoolAssociation (SSA) entity, which represents a student's enrollment in a school.
The StudentEducationOrganizationResponsibilityAssociation (SEORA) entity, which represents an EducationOrganization's responsibility for a student.
Please refer the best practices documentation of related domains for use cases listed above that will require Ed-Fi domains other than Enrollment domain.
Ed-Fi Prerequisites for Writing Enrollment Domain Entities
The Enrollment domain has dependencies on other data that should be entered into the Ed-Fi API/ODS prior to entering enrollment information, as follows:
ODS/API setup needed for each school year. The best practice convention suggests that enrollments recorded in the SSA must be written for each school year.
Descriptor values need to be loaded. The Enrollment domain has dependency on several sets of descriptors. Most of these will be custom descriptors that are mapped to current operational enrollment practices and reporting. In most cases they will match the code lists already set up in the SIS. Followings are the list of these descriptors.
StudentSchoolAssociation: EntryType, EntryGradeLevel, EntryGradeLevelReason, ResidencyStatus, ExitWithdrawType, EducationPlan, GraduationPlanType
StudentEducationOrganizationResponsibilityAssociation:Â Responsibility
StudentTransportation: TransportationPublicExpenseEligibilityType, TransportationType, BusRoute, TravelDaysofWeek, TravelDirection (DS v5.x and after)
CrisisEvent:Â CrisisType (DS v5.x and after)
EducationOrganizations, minimally Schools and LocalEducationAgency(s), need to be created for the scope of the ODS.
Calendar(s) for the various Schools and GradeLevel(s) needs to be created.
Graduation Plan(s)Â for the various tracks for graduation needs to be created.
A Student record needs to be written before enrollment data in the StudentSchoolAssociation
Enrollment Domain Anti-Patterns
An anti-pattern is a practice Ed-Fi Alliance has observed for a recurring situation that is not recommended.
Fictitious Schools
NCES defines a public school as an institution that provides educational services and...
has one or more grade groups (pre-kindergarten through grade 12) or is ungraded;
has one or more teachers to give instruction;
is located in one or more buildings or sites;
has an assigned administrator;
receives public funds as primary support; and
is operated by an education agency.
This definition does not exclude virtual schools (even though it is in conflict with the third criteria), nor does it exclude specialized schools such as career and technical education (CTE) schools, special education schools, or alternative education schools.
However, a common anti-pattern is observed where fictitious schools are created to track students’ participation in a specialized program that is administered as part of a recognized school. These fictitious schools do not have the totality of administration that is necessary for recognized schools. While there are gray areas, these are better characterized in Ed-Fi as a Program.
A confusing factor is that there exist legitimate virtual schools, but also specialized virtual programs. There are special education schools and there are special education programs. There are CTE schools and CTE programs; and so forth.
An acid test evaluating whether to characterize as a School or a Program is whether the school is recognized by the state as a school (and appears in state directories) and is reported for Federal accountability as a school. If not, it is better characterized in Ed-Fi as a Program. A school identifier being assigned is not sufficient evidence of a legitimate school.
Multi-Year Enrollments
Public schools operate on a school year basis that defines the typical increment of grade-level instruction.
An anti-pattern is observed where the StudentSchoolAssociation reflects student enrollments that span multiple school years. This practice does not capture the proper EntryDate. For example, if a student enrolled in 9th grade in 2020, their 11th grade 2022 enrollment would still report their original 2020 9th grade EntryDate. A student should have minimally one enrollment SSA per SchoolYear and minimally one SSA per GradeLevel.
Â
Best Practices in Using the Enrollment Domain
The following best practices are organized by entity in the enrollment domain.
Best Practices Related to the StudentSchoolAssociation (SSA)
The SSAÂ is the primary entity associated with school enrollment, associating the student with the school in which a student is enrolled. Note that attributes of Student and the StudentEducationOrganization are also typically written at the time of enrollment.
Best Practices for the use of the SSA Attributes
Required | Must Have | Recommended | As Needed |
---|---|---|---|
Student (key) School (key) EntryDate (key) EntryGradeLevel | EntryType PrimarySchool SchoolYear EnrollmentType ResidencyStatus ExitWithdrawDate ExitWithdrawType Calendar FullTimeEquivalency | EntryGradeLevelReason RepeatGradeIndicator ClassOfSchoolYear GraduationPlan | EducationPlan AlternativeGraduationPlan EmployedWhileEnrolled SchoolChoice SchoolChoiceBasis TermCompletionIndicator NextYearSchool NextYearGradeLevel |
Keys in reading the table:
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 SSAÂ as follows
Â
→ SSAs are created for each student enrollment per school.
→ Minimally, one SSA is created for each enrolled student per school year.
→ At any point in time, a student should have no more than one active SSA for a single school.
→ If a student may be enrolled in multiple schools at the same time, the student will multiple SSA, one with each school. In these cases, the PrimarySchool attribute should indicate the primary enrollment.
→ A student should not have more than one PrimarySchool enrollment at any point in time.
→ A separate SSA should be created when a student’s enrollment status fundamentally The recommended attributes whose change would trigger a new SSA are SchoolYear, GradeLevel, PrimarySchool, ResidencyStatus, EnrollmentType. FullTimeEquivalency, EntryType, and Calendar reference.
→ An SSA should only be deleted if it is mistake. Deletion of the SSA should not be used for no shows (see below).
Â
For the StudentSchoolAssociation, the EntryDate and the ExitWithdrawDate define the period of enrollment. As part of the key for the SSA, each SSA for a student and school must have an EntryDate. An active enrollment SSA is one with an EntryDate and no ExitWithdrawDate, meaning the student is still enrolled.
Â
→ The ExitWithdrawDate must be equal or after the EntryDate of an SSA.
→ If a student withdraws from a school during the school year and then re-enrolls in the same school, multiple SSA records are created, one for each period of enrollment.
→ Active enrollments at the same school should not overlap, meaning that prior enrollments should have an ExitWithdrawDate equal to or before the EntryDate of the next.
→ Multiple SSA records for a student at a school should not be combined, even if the ExitWithdrawDate of one SSA is the same as the EntryDate of the next SSA.
Â
The EntryType and ExitWithdrawType descriptors are used to capture the important circumstances for a student’s enrollment entry and exit. The set of descriptor values should reflect operationally the codes captured at the time enrollment entry and exit.
Â
→ Every SSA should have an EntryDate and an EntryType value.
→ If the SSA has an ExitWithdrawDate, it should have an ExitWithdrawType value.
→ If an enrollment is a no show, meaning that the student enrolled and then never attended the school, the SSA should be updated with an ExitWithdrawDate of when the no show was realized according to policy, and the ExitWithdrawType reflect an appropriate descriptor value indicating a no show.
→ School year completers, who were enrolled through the last day of the school year, should have their SSA updated with an ExitWithdrawDate as the last day of school, and an appropriate ExitWithdrawType descriptor value indicating successful (or unsuccessful) completion of the grade, graduation, etc.
→ After all the updates to the Ed-Fi API/ODS are made for the end of the school year, there should be no SSA without an ExitWithdrawDate and an ExitWithdrawType.
Â
There are additional attributes of the SSAÂ where best practices indicate the attribute must be used, as follows.
Â
The Student and SEOAÂ are important companions to the SSA. The Student entity captures identity information and the SEAO holds important demographics and student characteristics.
Â
Best Practices Related to the StudentEducationOrganizationResponsibilityAssociation (SEORA)
The StudentEducationOrganizationResponsibilityAssociation (SEORA) indicates a relationship between a student and an education organization other than an enrollment relationship, and generally indicates some kind of accountability or responsibility of the education organization for the student. The kind of responsibility is specified in the Responsibility descriptor value according to policy.
Best Practices for the use of the StudentEducationOrganizationResponsibilityAssociation Attributes
Required | Must Have | Recommended | As Needed |
---|---|---|---|
Student (key) EducationOrganization (key) Responsibility BeginDate | EndDate | Â | Â |
Â
Business Rules that considered as best practices for the usage of the SEORAÂ as follows