Student Health Domain - Model Diagrams
- Muriel Marable
- Mustafa Yilmaz
Student Health Model UML Diagram
The Student Health data model provides for recording the immunization history of students. It does not include information about the specific requirements for immunization since this information likely lives outside the likely source of student immunization systems. Analysis and reporting of whether students satisfy the immunization requirements will need to access the definition of requirements outside the ODS.
A new entity StudentHealth is defined to enable separate access control in the Ed-Fi API claimsets and in the ODS tables suitable for health data according to policy. The StudentHealth entity has the following key:
- Student reference
- EducationOrganization reference
The referenced EducationOrganization should reflect the level (i.e., SEA, LEA, School) of organization that is responsible for maintaining the student health data in the ODS.
Because the content of the StudentHealth entity is cumulatively historical, the required AsOfDate is not a key, but is used to reflect the date the record was last updated.
The data model UML diagram is shown below.
Student Health Domain (click to enlarge)
The StudentHealth entity organizes immunization records with the following attributes:
- RequiredImmunization common – optional collection consisting of attributes:
- ImmunizationType descriptor
- ImmunizationDate optional collection
- MedicalExemption string optional
- MedicalExemptionDate optional
- AdditionalImmunization common – optional collection consisting of attributes:
- ImmunizationName string
- ImmunizationDate optional collection
- NonMedicalImmunizationExemption descriptor optional
- NonMedicalImmunizationExemptionDate optional
The RequiredImmunization set are meant to be those that are specifically tracked against a controlled list (i.e., the ImmunizationType descriptor set). The semantics are not meant to infer that the student has all the required immunizations (which often vary by age) – but to provide the raw data to allow that determination during reporting if desired. The education organization may include immunizations in the ImmunizationType that may not be explicitly required but are desired to be tracked with the controlled vocabulary of the descriptor.
The AdditionalImmunization set are not controlled by a descriptor set (just an ImmunizationName string) and are meant to capture any others not part of the controlled list ImmunizationType.
For both the RequiredImmunization and AdditionalImmunization, the attribute ImmunizationDate is a collection to support multiple doses of the immunization that were received.
The data model supports recording of both a MedicalExemption and a NonMedicalImmunizationExemption.
The MedicalExemption is part of the RequiredImmunization common since medical exemptions are typically offered against specific immunizations. The MedicalExemptionDate is used to reflect that date it was granted by a doctor.
The NonMedicalImmunizationExemption is an attribute of StudentHealth to support “blanket” exemptions for all immunizations. The NonMedicalImmunizationExemptionDate is used to reflect the date the exemption was claimed by the parent or guardian. If the nonmedical exemption only applies to some immunizations, data for those immunizations received (and thus without exemption) should be provided in the RequiredImmunization set. The semantics in this case would be that the nonmedical exemption applies to those not received.
- Ed-Fi Unifying Data Model (UDM) Handbook (Latest version)
- Ed-Fi UDM Diagram (Latest version) (Visio format, on GitHub)