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.

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.
• StudentTransporation entity recording the eligibility and bus route details assigned to a student for transport to/from school.
• CrisisEvent entity that holds data about each identified crisis that displaces impacted students into other schools.

Please refer the best practices documentation of related domains for use cases listed above that will require Ed-Fi domains other than Enrollment domain.

Crisis Event Related Use Cases

When a crisis event impacts students, the education agency, typically the State Education Agency (SEA), determines the requirement to track students who are displaced as a result.  This determination is accomplished at the time that policies and guidance are provided to schools to support displaced students associated with a specific crisis event.  Displaced students may be:

• From another state and newly enrolled in a school.
• Within the state but enrolling in a new school.
• Personally displaced but remaining in the same school may be included, as determined by SEA policies.

The determination that an enrolled student is displaced by a crisis event is recognized during the enrollment process at the new school.

Student Transportation Related Use Cases

The eligibility for a student to receive transportation services according to the criteria of the state and the district are typically determined at enrollment time (or pre-enrollments of they are used).  Depending on the location(s) for pickup and drop-off, the student is assigned to a bus and bus route.  The eligibility and bus route information for a student is typically captured in an automated system, such as:

• Bus routing and planning software
• Student information system with a transportation module
• Other application or web site

From these systems, the student transportation data will flow into the Ed-Fi API/ODS.  Depending on the source system, new API or batch interfaces may need to be developed.

There are several possible uses of student transportation data from the ODS that includes:

• Analyze eligibility criteria met by the student population.
• Average number of riders assigned to be transported as a percentage of total district membership.
• Riders assigned to be transported as a percentage of district membership by category or demographics.
• Combined with financial data for total expenditures for student transportation by student, or category.

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

CrisisEvent: CrisisType

• 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

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

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 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.

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

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

Best Practices Related to StudentTransportation

The StudentTransportation entity captures a student’s eligibility and specific transportation arrangements to/from school.

Best Practices for the use of the StudentTransportation Attributes

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

Best Practices Related to CrisisEvent

The crisis event data model is used to track displaced students that are educationally impacted by crises, such as natural disasters or emergencies. The CrisisEvent entity is created to hold data about each identified crisis that displaces impacted students. The identification of specific displaced students is made using the common DisplacedStudent in the StudentEducationOrganizationAssociation.

Best Practices for the use of the CrisisEvent Attributes

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