3.1 Changes to Student Data Violate UDM Principles

The 3.1 model made drastic changes to the attributes of Student.  Apparently motivated by DATASTD-1183, these changes seriously violate UDM principles.

The UDM is an enterprise data model for the business of K12 education, independent of implementation concerns.  As such, it reflects a data model that “makes sense” in terms of its entities, attributes and relationships.  The UDM is strength of Ed-Fi because it provides a resiliency that guides the rest of the models.  The new 3.1 violates this in many ways, per the points below.

Specifically, the problem lies with the StudentEducationOrgAssociation that was introduced.

1. The following attributes exist solely in the context of the Student and not in the context of the Association. The test is whether these attributes only exist when a student is associated with that EdOrg (the answer is No).  These attributes need to remain with Student.
   1. Sex
   2. HispanicLatinoEthnicity
   3. Race
   4. TribalAffiliation

           Note that adding an AsOfDate attribute to Student should be considered.

1. Similarly Contact information exists apart from any education organization. However, because updates to contact information can come from many sources, it makes sense to split it out into its own entity Contact which contains:
   1. Address
   2. InternationalAddress
   3. Telephone
   4. ElectronicMail

            Note that the pattern should probably be replicated for Parent and Staff.

1. The following attributes are associated with the student as part of enrollment in a School and therefore should be included as part of the StudentSchoolAssociation. They do not exist as part of an arbitrary EducationOrganization association, by with the association relating to the enrollment: the StudentSchoolAssociation.
   1. StudentCharacteristic (probably should be renamed StudentDesignation)
   2. LimitedEnglishProficiency
   3. ProgramParticipation
   4. CohortYear
   5. LoginId

1. Disability and Language are tricky with the following alternatives.
   1. The argument can be made that conceptually, both are attributes of a student that exist apart from any association to a school or any EdOrg.
   2. However, both are typically associated with an assessment or diagnosis that is made by or on behalf of the school. If moved to the StudentSchoolAssociation, we should consider renaming, for example DisabilityDiagnosis, and LanguageDetermination. 
   3. The other alternative is to place these with the StudentSpecialEducationProgramAssociation, and the StudentEnglishLanguageLearnerProgramAssociation.

1. StudentIdentificationCode exists when a student is associated with some organization that assigns the identifier. Each identifier may be issued under the authority of different organizations: SEA, LEA, School, a government entity (e.g., SSN, Drivers License, Passport), or even a vendor application (e.g., SIS, security badging system). The alternatives are:
   1. Place the identifiers in associations to the various organizations. This has the disadvantage of scattering identifiers across many different associations and may require defining organizations that would not normally be included in the model.
   2. To support searching for a specific identifier, the Identifiers could be broken out into its own entity. However, today the IdentificationSystem descriptor semantics are too loose to support the important matter of unique identifiers.  Geoff has suggested a URI scheme that would be more precise with the proper guidance.

 In all cases, these attributes belong elsewhere other than the StudentEducationOrganizationAssociation that was introduced.