Last update: September 25, 2019
The Ed-Fi Assessment Outcomes API v2 Certification for Providers verifies that a source system (the provider) can manage a core set of assessment data on a target system (the consumer) using the RESTful APIs defined by the ED-FI RFC 15 - ASSESSMENT OUTCOMES API.
In this data exchange architecture, the provider implements an API client which uses HTTP/S requests and RESTful patterns to manage API resources on the consumer system, which implements the API definition itself (see Figure 1).
Figure 1. Conceptual data exchange architecture
The certification further aggregates normative requirements that have been found by the Ed-Fi community to be critical to "real world" data exchange and interoperability. These includes requirements around error handling and recovery, roster configurability, and others.
This conformance specification covers the provider certification — that is, the responsibilities of the API client implementer and not the API consumer. The Alliance intends to publish a consumer conformance specification as well. Both certifications will use the same technical API specifications provided as part of the ED-FI RFC 15 - ASSESSMENT OUTCOMES API standard.
Overview of Requirements
This section provides an overview only; detailed, step-by-step requirements are available in the Assessment Outcomes API Certification for Suite 2 - Steps].
Required Fields on API Resources
All fields marked as "required" in the API specification are required, and in addition the data submitted must offer parity of data with score reports the vendor currently publishes to its users. Those score reports as published in the provider certification record.
This may seem an odd requirement, but it is meant to address the inherent diversity of assessment data provided as part of score reporting across the K12 ecosystem. This diversity makes it difficult to define exactly which fields in the API resources should be required or not. This certification handles this diversity in part by testing parity with score reports the vendor currently publishes.
Student ID Configuration
If the product uses a rostering standard or a similar de facto industry roster specification (such as the Clever roster) and that standard contains multiple possible student IDs, the certifying product must demonstrate the ability to allow a user of the product to configure which student identifier to be used within transactions for an education agency (configurability can be more granular than education agency-level, but this level is the minimum required).
Such a capability has proven important in field work to date; for example, some districts may align on state identifiers for carious reasons (e..g as they are part of school district collaboratives) or use "student numbers" on occasion.
If the product uses multiple roster standards, it is only required to demonstrate this capability with one standard.
The provider must demonstrate the ability to perform create, update and delete operations on API resources. For update, HTTP POST or PUT are both accepted.
In field work, the ability to capture, display errors, and offer facilities to re-try after error conditions are found, have been proven to be essential to interoperability. The certification testing ensures a basic level of such functionality is in place.
The Assessment API model contains a number of controlled vocabularies.
For some enumerations, a vendor is allowed to supply their own additional values if an Ed-Fi value fails to match the semantics needed. These enumerations are:
The certification captures and publishes vendor-specific enumerations (in the provider entry in the Registry of Ed-Fi Certified Products), and tests that enumerations used during testing are within the allowed enumeration sets.
- No labels