Redesign EducationOrganizationID system to resolve and remove ambiguity and allow the ID system to support non-state/SEA use cases more easily.

Summary of outcomes for Data Standard 2.1

• Problem Addressed: The annotation of the EducationOrganizationId properties in the various EducationOrganizations restrict implementations from using non-state-issued identifiers. Additionally, the field EducationOrganization.StateOrganizationId is unnecessary because this information can be accommodated using the existing EducationOrganizationIdentificationCode common type.
• High-level Reasoning: The identifiers of various EducationOrganizations are all annotated to indicate that they should be populated with state-issued identification codes. However, some implementations may wish to use identifiers for EducationOranizations that are assigned by other entities than the state. Additionally, the field EducationOrganization.StateOrganizationId is unnecessary because this information can be accommodated using the existing common type EducationOrganizationIdentificationCode.
• Changes Made: Removed the text "by the State Education Agency (SEA)" from the annotation of the EducationOrganizationId field in EducationOrganization and all EducationOrganization subclasses (including School, LocalEducationAgency, StateEducationAgency, EducationServiceCenter, and EducationOrganizationNetwork); Removed the shared string IdentificationCode named StateOrganizationId from EducationOrganization domain entity

Original ticket description follows:

There seem to be two issues with the current EdOrgID system: 1) a fair amount of cruft and potentially confusing design features left over from earlier iterations of the data standard, and 2) a limited ability to support LEA or other implementations that may not want to use SEA/state identifiers.

Ambiguity Problem

From what I can reconstruct from interviews and by looking at field work, the current system is designed to function based on IDs issues by state education agencies: EdOrg.StateEducationOrganizationID is the intended ID, and that ID is then supposed to flow to (that is, to be) the concrete ID in subclasses of EdOrg, following the pattern [EdOrg subclass name].[EdOrg subclass name]ID. So you get:

• School.SchoolID
• LocalEducationAgency.LocalEducationAgencyID
• etc.

These IDs are also the natural keys for the entity.

There are several apparent problems here:

• First, the datatypes for EdOrgs.StateOrganizationID and its subclass IDs (e.g. School.SchoolID) don't match: string vs int. In practice, implementations can work around this, as the ID can be transformed from int to string, as needed, but the model is fundamentally confusing to understand, and should NOT require transformation of IDs in any case. The datatypes should match.
• Second, the model confusingly ALSO puts a StateOrganizationID onto the subclasses, as in School.StateOrganizationID This raises a lot of questions, such as "should this ID match the natural key ID, and what happens if it does not?" This field is bound to confuse implementations as to how they should function.

Use Case Problem

The definition of the EdOrgIDs as "The identifier assigned to an education organization by the StateEducationAgency (SEA)." will make implementations that are not SEA-focused more difficult. For example, to populate EdOrgs in the LEA model (say for an out-of-state transfer student whose transcript needs to be ingested) will require finding state school identifiers for another state. In practice, these IDs are often hard to find.

At the least, it seems that the model should be open to other ID systems, such as that defined by NCES, which maintains a clearinghouse of school and district IDs. To enforce usage of state IDs seems likely to cause problems in use cases that cross states.