Internationalization Work Group - Initial Scope Questions

Owned by Eric Jansson
Last updated: Nov 22, 2019
2 min read

Below are a number of initial issues which are likely overall concerns for an internationalized Ed-Fi data model and APIs. Resolving these is likely as an important early step in the work

Education Organization Hierarchy

The current organizational hierarchy is tightly bound to US K12 education, and likely needs considerable flexibility for international deployment and usage.

Also, based on experience in the US K12 market, it is likely this model can be simplified (e.g. organizations with “roles”) as a strongly domain-centric capture of organization has not often proven important (e.g. the Ed-Fi model is student-centric and centered on student insights).

Ideas: single org with reflexive relationship, with org type

Person and Roles

It seems likely that some representation of “person” with “roles” is needed as opposed to the current model where the role/person is combined. This only seems prudent to be able to capture alternative international structures, but this has also been emerging as a need in the US K12 market.

However, it is important that in doing this we keep a practical focus on the difficulties in uniquely identifying and tracking generic people (e.g. it is one thing to assert a person in a data model, but quite another to make it work in the real world).

Key Structure

The Ed-Fi data model key natural structure tightly binds the model to US K12 education structures in some places. In addition, while the system has been very helpful for enforcing data quality, the natural key structure has not been widely adopted by vendor systems even in US K12 (the standard practice is to use the REST resource ID); it has also not implemented by early field API implementations.

The current key structure also makes data model evolution tricky, which is especially a concern in the current context.

Use of Abstract Entities and Inheritance

The current Ed-Fi model makes sparing use of abstraction and inheritance, but even those areas have generated the most significant complexity in terms of API implementation.  We should consider if and when this complexity is necessary.

Entity Names and Definitions

Some entity names may not work well internationally. In addition, we might take the opportunity some systematic problems in the current model with entity naming (e.g. non-qualified associations, as in “StudentSchoolAssociation” might better be “StudentSchoolMembershipAssociation”; "Parent" might be better captured as "Guardian"; etc.)

Option Sets

Option sets are an important part of standardization, but which sets of values apply across national (or other broad) contexts and which do not. How should these be managed and standardized.

Internationalized Elements

  • Person names
  • Addresses
  • Demographic and program participation indicator
  • Multi-region support

"Openness" and flexibility of model

Make it easy to land the data; favor downstream rules for consistency. Perhaps hiding some of this behind an interface that talks in more domain-specific objects.

Scope

Start with limited scope and grow it.

Idea: start with core rostering, expand from there

FHIR Patterns

It is likely useful to look at the patterns for FHIR. These overlaps with some of the above areas. Documents of note: