What's New - Additions

This section describes additions to the data model new to v2.1. Additions to the model are generally non-breaking, but worth review because they often address field use cases.

Additions to the Data Model

Discussed in this section:

Detail on each follows.

Addition of a New Staff Education Organization Contact Association (DATASTD-946)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

This change delivers on two unmet needs in the Ed-Fi Data Standard v2.0: it resolves a technical limitation and also expands the staff domain model to address new use cases.

On the first need, in Ed-Fi Data Standard v2.0, e-mail addresses for staff members were modeled with the ElectronicMail entity directly attached to the Staff entity. While the abstract UDM and XSD allow multiple e-mail addresses, in implementations the ElectronicMail.Type field becomes the obvious choice for determining identity (e.g., an e-mail address can be entered into a system in error). However, that model allows at most one of each type of e-mail address to be stored for a Staff. This causes problems when staff members are associated with more than one school or district, which often results in multiple valid "work" addresses.

On the second need, modeling the ElectronicMail entity directly on Staff entity leaves unclear which e-mail address is associated with which education organization. That causes a logical ambiguity, but also causes practical problems when the data is used as a basis for roster or login IDs at an education organization. Further, field work has shown that there is also a parallel need to identify contacts for specific roles (often externally) within an organization, as in "Help Desk Contact" or "Civil Rights Data Coordinator".

This change enables contact information such as e-mail address to be specified on a per-education-organization basis. Note that the ElectronicMail entity will remain on the Staff entity as well.

Change Detail

This change adds a new StaffEducationOrganizationContactAssociation entity to the Ed-Fi Handbook, the Ed-Fi UDM, and core data artifacts. This new association connects a staff person to an education organization and stores contact information specific to that relationship, allowing staff members to have e-mail addresses associated with a particular school, district, or other education organization.

For completeness (and consistency with other parts of the Ed-Fi model), the new association will use the existing StaffReferenceType, which contains the required association data, e-mail, and other association-specific information such as telephone and address information.

A few characteristics worth noting: 

• The model uses the ElectronicMailAddress element (and not the ElectronicMail entity) because the association contains the context normally provided by the e-mail type information.
• ContactType is required. It maps to a ContactType Descriptor, and uses a default value of "Other". 

The following snippet illustrates the model expressed in the Ed-Fi Core XSD:

... 
<xs:complexType name="StaffEducationOrganizationContactAssociation">
	<xs:annotation>
		<xs:documentation>This association provides the contact information of the staff associated with the education organization.</xs:documentation>
		<xs:appinfo>
			<ann:TypeGroup>Association</ann:TypeGroup>
		</xs:appinfo>
	</xs:annotation>
	<xs:complexContent>
		<xs:extension base="ComplexObjectType">
			<xs:sequence>
				<xs:element name="StaffReference" type="StaffReferenceType">
					<xs:annotation>
						<xs:documentation>The Staff assigned to the EducationOrganization.</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="EducationOrganizationReference" type="EducationOrganizationReferenceType">
					<xs:annotation>
						<xs:documentation>The EducationalOrganization to which the Staff member provides services.</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="Address" type="Address" minOccurs="0">
					<xs:annotation>
						<xs:documentation>The optional address for the contact associated with the EducationOrganization.</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="ContactTitle" type="ContactTitle">
					<xs:annotation>
						<xs:documentation>The title of the contact in the context of the EducationOrganization.</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="ContactType" type="ContactTypeDescriptorReferenceType" minOccurs="0">
					<xs:annotation>
						<xs:documentation>Indicates the type for the contact information.</xs:documentation>
						<xs:appinfo>
							<ann:Descriptor>ContactTypeDescriptor</ann:Descriptor>
						</xs:appinfo>
					</xs:annotation>
				</xs:element>
				<xs:element name="ElectronicMailAddress" type="ElectronicMailAddress">
					<xs:annotation>
						<xs:documentation>The email for the contact associated with the EducationOrganization.</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="Telephone" type="Telephone" minOccurs="0" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>The optional telephone for the contact associated with the EducationOrganization.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
...

 A typical use of the StaffEducationOrganizationContactAssociation would look like the following XML data file snippet:

...
<StaffEducationOrganizationContactAssociation>
	<StaffReference>
		<StaffIdentity>
			<StaffUniqueId>307308</StaffUniqueId>
		</StaffIdentity>
		<StaffLookup>
			<StaffUniqueId>307308</StaffUniqueId>
		</StaffLookup>
	</StaffReference>
	<EducationOrganizationReference>
		<EducationOrganizationIdentity>
			<EducationOrganizationIdentifier>255901044</EducationOrganizationIdentifier>
		</EducationOrganizationIdentity>
	</EducationOrganizationReference>
	<Address>
		<StreetNumberName>1234 Education Ave.</StreetNumberName>
		<BuildingSiteNumber>Building 3</BuildingSiteNumber>
		<City>Austin</City>
		<StateAbbreviation>TX</StateAbbreviation>
		<PostalCode>78701</PostalCode>
		<AddressType>Physical</AddressType>
	</Address>
	<ContactTitle>Guidance Counselor</ContactTitle>
	<ContactType>
		<CodeValue>Other</CodeValue>
		<Namespace>http://www.ed-fi.org/Descriptor/ContactType.xml</Namespace>
	</ContactType>
	<ElectronicMailAddress>james.mctestman@example.com</ElectronicMailAddress>
	<Telephone>
		<TelephoneNumber>512-555-1212</TelephoneNumber>
		<TelephoneNumberType>Work</TelephoneNumberType>
	</Telephone>
</StaffEducationOrganizationContactAssociation>
...

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-946).

Added EducationOrganization Subclasses to Support Representation of Community Providers (DATASTD-329)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

In practice, school districts often rely on external providers for instructional services, and these organizations do not fit in any of the existing EducationOrganization subclasses under the Ed-Fi Data Standard v2.0. Such organizations are logically distinct from school districts, schools, and regional education service centers in that they have specific processes and requirements (e.g., specific licensure requirements). 

v2.1 picks up some models from field work in Delaware and elsewhere to address this need.

Change Detail

The following changes were made in Ed-Fi Data Standard v2.1:

• Created CommunityOrganization and CommunityProvider domain entities (both subclasses of EducationOrganization).
• Added CommunityProviderLicense domain entity to track credentialing of such entities, which was a demonstrated use case in field work.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-329).