Use of the user data interface

By using the user data interface, edTech partners agree to the following policies, which go beyond the legal requirements of the GDPR:

Basis for Processing and Disclosure Requirements

The Federal Ministry of Education grants permission to access certain user information upon presentation of the purposes of data use, which the edTech partner describes to the ministry when concluding the edTech agreement. The edTech partner is required to immediately notify the ministry of any changes to these purposes and to update the relevant information on the education portal. The ministry may refuse to approve the expansion of these purposes without providing reasons...

Data minimization

An edTech application is granted access to a specific set of data from those schools where the application has been activated. This data set therefore represents the maximum amount of data that the edTech partner is authorized to process. If it must be assumed that not all data from a school is required for the application to function (e.g., if a school does not have a license for certain features of the application or has not activated them), only the data necessary for the application’s operation at that school may be stored.

Example: School A uses a form service in an application that allows for postal deliveries. Therefore, the application requests access to address data, which is approved by the BMB. School B uses the application but has not activated the form service. Therefore, address data should only be stored for School A, not for School B.

Personal characteristics and sources

A distinction is made between global and school-specific personal characteristics.

Global Person Attributes

For global personal attributes, it is assumed that these can be aggregated or supplemented from various sources, but that only one valid data record can exist per person. Such attributes are provided in the user data interface without a source reference.

These are:

First name, official first name, middle name, last name
Official and professional titles
Gender
Date of birth
Profile picture and passport photo
Relationships with other individuals (parental authority)

Attention: The education portal stores the first name in the field firstname_official (= official first name) exactly as it appears in official records. Since it is rather uncommon to use multiple first names in everyday life, users of the education portal may specify which parts of their name should be used to display their first name in applications. As a rule, applications therefore use the attribute firstname (display first name). The attribute firstname_official is only required in rare cases, such as when generating certificates.

Source-related personal characteristics

Source-based personal attributes are pieces of information that originate from a specific source, such as a human resources or school administration system, and are related to a person’s position or role at a specific school. These are therefore provided in the user data interface along with the school code from which the record originates.

EdTech applications must under no circumstances mix data from different schools, unless this is explicitly justified by the nature of the application.

Source-related attributes are:

Phone numbers
Email addresses
Mailing addresses
Roles
Class and department affiliations

Additional identifying characteristics

For the purpose of enriching existing user data sets with the national id, personnel numbers (sapid) and student administration IDs (sokratesid, esaid, wisionid, ...) are provided. These attributes are not intended to be transferred to local data sets, but are used exclusively for assigning national ids!

Sources

Address information

For address data, a school’s identification number is listed as the source if the data comes from the respective student administration system. A school identification number of 0 indicates that the address record comes from an official registry (e.g., the Central Register of Residents).

Contact information

For contact information (email addresses and phone numbers), a school’s identification number is listed as the source if the data comes from the respective student administration system. A school id of 0 means that the information was entered by the person themselves in the Education Portal profile (Self Service). A school id of 10000 means that the data record originates from PM-SAP (Personnel Administration).

Special attention must be paid to the handling of contact information, as a strict distinction must be made between work-related and personal data. The following applies:

If users are using the application as part of their work duties, only work email addresses (flag official = 1) should be accepted
If users are accessing the application as students or guardians, they must enter email addresses that include the school’s identification number or the identification number 0.
Within the set of retrieved email addresses, one address may optionally be marked as the preferred address (flag preferred = 1). In this case, this email address can be saved as the primary notification address. However, an email address collected solely for the purpose of notification must not be displayed to other users!

Example: Person A is a parent or guardian at School X and a teacher at School Y. A work email address was chosen as the preferred email address. At School X, the parent-teacher association offers an app. A consents to the processing of their data in order to connect with other parents through the app. However, A does not want other parents to see that A is also a teacher at School Y. Therefore, it is important that the application only displays the private email address to other users for this "private" use. However, A has set his work address as the preferred delivery address. The application could (but does not have to) therefore offer the option of sending notifications to this preferred address, without, however, showing this address to other users.

Separation of user contexts

Users can use applications in various contexts. The context is determined by a person’s role within your specific organizational unit, such as "as a teacher at School A" or "as a parent or guardian at School A". Depending on the context, the focus is therefore on either professional or personal use of the data.

The edTech partner acknowledges that, when data is transferred, precautions are taken to prevent the mixing of data from different schools, as well as of private and work-related contact information. For each personal data record, the user data interface provides both the school identifiers and roles held by a person, as well as, for contact and address data, information indicating whether such data is private or work-related data.

Example: Person A is both a teacher and a parent at School X. The record for A contains three email addresses. Two of them list School X’s school code as the source. One of the email addresses was marked for official use (official = 1) and the other record as a private contact (official = 0). In addition, A has been assigned a federal government work email address, which has been recorded in the personnel administration system. This is indicated in the data record by the school code 10000 (= Federal Ministry of Education) and the flag official = 1. Therefore, when processing these email addresses, the user’s context within the application must be taken into account.

Users can also set an email address as their "preferred contact address" (preferred = 1). However, this information should not be used as a criterion for deciding which email address is processed, but rather simply indicates that the person wishes to receive notifications at this email address. This address can therefore be used in two cases:

if a separate notification address can be saved that is not visible to other users, or
as a fallback address if no other source is available.

Depending on the type of application, a distinction must therefore be made between the following use cases:

Category A - Separate accounts for business and personal use

Apps in this category offer users separate accounts depending on the context (work/personal). In this case, the synchronization process is as follows:

Priority	Official context	Private context
1	school id + `official` = 1	school id + `official` = 0
2	school id 10000 + `official` = 1	`preferred` = 1
3	`preferred` = 1	school id = 0 (Self Service Record)
4	school id = 0 (Self Service Record)

Attention: When using SSO, you may need to use the user context selection on the education portal to ensure that SSO routes you to your work or personal account!

Category B - Joint accounts for business and personal use

Apps in this category have only one user account per person, which is used for both work-related and personal purposes. In this case, the synchronization procedure is as follows:

Priority	Source	Comment
1	`preferred` = 1	Select preferred address
2	school id != 10000 or 0 + `official` = 1	Select the school's official address
3	school id = 10000 + `official` = 1	Select the federal business address
4	school id = 0	An address created by the user
5	any other email address	Select the first address found

Technical aspects

The user data interface is designed to retrieve only changes made since a specific point in time. Full queries of all users to whom an application has access should therefore only be performed in exceptional cases (e.g., suspected errors) and, whenever possible, on weekends or during holiday periods.

The query is initiated by passing the parameter cursor. At the end of each query, the last cursor value is returned and can be used for the next query. Queries restricted by the cursor can be performed on a continuous basis (e.g., hourly).

Note: For backward compatibility reasons, the parameter timechanged is still available, but it should no longer be used in the medium term.

To ensure the accuracy of all data, edTech applications must retrieve the user data interface at least once a day and automatically update any changes to the data.