Synopsis

The Core Student Data API standard describes a REST API surface that covers the core data domains typically managed by student information systems in K–12 education. These standards can be used to drive analysis of student performance, both alone and in combination with data from other systems.

This API definition calls for the use of HTTP/S and RESTful patterns to expose a set of granular API resources that the source (or "provider") system uses to manage a copy of the data on a target (or "consumer") system that has implemented the API definition. These standards describe roles and requirements for both provider and consumer systems (see Figure 1).

Figure 1. Provider and consumer systems

While this architecture can be understood as the provider transferring data from its system to a consumer, the certification is described as "data management." In real-world field use within the Ed-Fi community, evidence suggests that using such an API includes a broader set of responsibilities on behalf of the vendor than that implied by the term "transfer." For example, the provider is also required to reconcile records following errors or transport problems, implement data quality checks, log and surface errors to the users of the provider system, and so on.

Data Elements

The data domains included in this standard have been defined by years of field work with a wide variety of student information systems in use within the K–12 enterprise. These data domains represent core data elements common to student information systems in K–12.

The Ed-Fi Unifying Data Model

Ed-Fi data exchange standards are concerned principally with data directly related to student performance and activity within the K–12 enterprise.

The elements in this standard — defined as API resources — derive from the Ed-Fi Unifying Data Model (UDM) v3.0, which captures a view of the student and related data elements focused on student performance. The UDM also exists to ensure that all standards published by the Ed-Fi Alliance share a common data model, and are therefore consistent with each other.

This standard describes the data definitions and structure (from the UDM), the formatting of the data (bindings and JSON serialization), and movement of that data (or transport). All are necessary for data to be efficiently exchanged between systems. This allows data to be combined with other indicators of student performance (such as assessment results) and used to inform instructional decision-making.

API Resources and API Interactions

The API standards described allow applications to read and write student data through a secure REST interface. 

API implementers and clients are expected to follow all guidelines in the Ed-Fi API Design and Implementation Guidelines. These include requirements relating to errors, authentication, security, and other aspects of API usage and implementation. Any MUSTs from that document should be considered required. If there are differences between the requirements included in this document and that one, the information provided in this document has precedence.

An Open API definition of the REST interface is provided in the Ed-Fi RFC 16 - Open API Spec section. Consumer implementations wishing to conform to this standard are expected to implement all paths and resources described in the specification. Providers wishing to conform to this standard are expected to be able to manage all API resources described, and accurately follow the semantics as described in the Ed-Fi UDM.

Use Cases

The architecture covered by this model of data exchange is intended to serve the following example use cases. Note that these are illustrative only: they are intended to highlight principal high-value use cases and do not cover all possible use cases.

• A local education agency (LEA) desires to extract a variety of data from its student information system in order to power student-performance dashboards it provides to teachers, counselors, and principals at all district schools. The data to be included from the student information system includes demographics, grades and transcript info, attendance, behavior, and student program participation data (e.g., Title I, SPED). The SIS is able to synchronize a copy of its data using the Core Student Data Management API into an intermediate operational data store that is used to feed downstream analytic data marts, including those that power the dashboards deployed by the LEA.
• A state education agency (SEA) needs to collect data on the performance of students and schools so that it can evaluate statewide needs and help manage improvement of education on a statewide level. These collections often include very granular student-level data (i.e., data on individual students) so that data can be aggregated into several other reports and data marts in flexible ways (e.g., calculate different kinds of aggregate metrics). The data needed for the reports generated by the SEA includes student and staff demographics, program participation, attendance, discipline, transcript data, and graduation progress information. The data needs to be synched in near-real time to support the ability of LEAs within the state to correct and fix data in source systems and have it re-communicated to the state by the SIS system within tight windows of time defined by the SEA.
• A local education agency has an Individualized Education Plan (IEP) case-management system that is used for managing special education student activity and reporting. That system incorporates a variety of data from a SIS system, typically more than the enrollment and basic demographics provided by standard roster exchange. For example, the case-management system needs information on past SPED and other program participation, parental information, plus attendance and discipline information. The LEA uses the Core Student Data Management APIs to connect data in near-real time to the IEP case-management system and thereby provide the system a rich set of information on students with IEPs.