Nutzung der Nutzerdatenschnittstelle

Mit der Verwendung der Nutzerdatenschnittstelle akzeptieren edTech-Partner die folgenden Policies, die über die gesetzlich gebotenen Richtlinien der DSGVO hinausgehen:

Verarbeitungsgrundlagen und Informationspflichten

Das BMB erteilt die Genehmigung zum Abruf bestimmter Informationen von Nutzer/innen unter Vorlage von jenen Zwecken der Datennutzung, die der edTech-Partner dem BMB im Zuge des Abschlusses der edTech Vereinbarung beschreibt. Der edTech-Partner ist verpflichtet Änderungen der Zwecke unverzüglich dem BMB zu melden und die diesbezüglichen Informationen im Bildungsportal zu adaptieren. Das BMB kann die Ausweitung der Zwecke ohne Angabe von Gründen verweigern.

Datenminimierung

Eine edTech-Anwendung erhält Zugriff auf ein bestimmtes Set an Daten jener Schulen, an denen die Anwendung aktiviert wurde. Diese Ausstattung stellt daher das Maximum an Daten dar, für deren Verarbeitung der edTech-Partner berechtigt wurde. Wenn davon ausgegangen werden muss, dass zur Leistungserbringung der Anwendung nicht alle Daten von einer Schule genutzt werden müssen (bspw. wenn eine Schule für einzelne Funktionen einer Anwendung keine Lizenz hat oder diese nicht aktiviert), dürfen nur jene Daten gespeichert werden, die für den Betrieb an der jeweiligen Schule erforderlich sind.

Beispiel: Schule A nutzt in einer Anwendung ein Formularservice, das postalische Zustellungen erlaubt. Daher wird der Zugriff auf Adressdaten seitens der Anwendung erbeten und vom BMB genehmigt. Schule B nutzt zwar die Anwendung, hat aber das Formularservice nicht aktiviert. Daher sollten nur Adressdaten an Schule A gespeichert werden, an Schule B nicht.

Personenmerkmale und Quellen

Unterschieden wird zwischen globalen und schulbezogenen Personenmerkmalen.

Globale Personenmerkmale

Bei globalen Personenmerkmalen wird davon ausgegangen, dass diese aus unterschiedlichen Quellen aggregiert / ergänzt werden können, aber pro Person nur ein gültiger Datensatz bestehen kann. Solche Merkmale werden in der Nutzerdatenschnittstelle ohne Quellenangabe ausgeliefert.

Diese sind:

Vorname, offizieller Vorname, mittlerer Name, Nachname
Amts- und Berufstitel
Geschlecht
Geburtsdatum
Profilbild und Passfoto
Beziehungen zu anderen Personen (Erziehungsberechtigung)

Hinweis: Das Bildungsportal speichert im Feld firstname_official (= offizieller Vorname) den Vornamen exakt so, wie er in den behördlichen Registern vorgesehen ist. Nachdem es eher unüblich ist im Alltag mehrere Vornamen anzuführen dürfen Nutzer/innen im Bildungsportal jene Namensbestandteile festlegen, die zur Anzeige des Vornamens in Anwendungen genutzt werden sollen. In der Regel nutzen Anwendungen daher das Attribut firstname (Anzeige-Vorname). Das Attribut firstname_official wird nur in seltenen Fällen, bspw. bei der Zeugniserstellung, benötigt.

Quellenbezogene Personenmerkmale

Bei quellenbezogenen Personenmerkmalen handelt es sich um Informationen, die von einer bestimmten Quelle, bspw. Personal- oder Schulverwaltung stammen und mit einer Tätigkeit/Rolle einer Person an einer bestimmten Schule zusammenhängen. Diese werden daher in der Nutzerdatenschnittstelle gemeinsam mit der Schulkennzahl ausgeliefert, von der der Datensatz stammt.

EdTech-Anwendungen dürfen keinesfalls die Daten verschiedener Schulen vermischen, es sei denn dies ist explizit durch die Art der Anwendung begründbar.

Quellenbezogene Merkmale sind:

Telefonnummern
E-Mailadressen
Postadressen
Rollen
Klassen- und Abteilungszugehörigkeiten

Zusätzliche Identifikationsmerkmale

Zu Zwecken der Anreicherung von bPKs bei bestehenden Nutzerdatenständen werden Personalnummern (sapid) und IDs der Schülerverwaltungen (sokratesid, esaid, wisionid, ...) ausgeliefert. Diese Merkmale sind nicht dafür gedacht in lokale Bestände übernommen zu werden, sondern dienen ausschließlich der Ausstattung mit bPKs!

Quellen

Adressdaten

Bei Adressdaten wird die Schulkennzahl einer Schule als Quelle angegeben, wenn die Daten aus der jeweiligen Schülerverwaltung stammen. Eine Schulkennzahl 0 bedeutet, dass der Adressdatensatz aus einem behördlichen Register stammt (bspw. Zentrales Melderegister).

Kontaktdaten

Bei Kontaktdaten (E-Mailadressen und Telefonnummern) wird die Schulkennzahl einer Schule als Quelle angegeben, wenn die Daten aus der jeweiligen Schülerverwaltung stammen. Eine Schulkennzahl 0 bedeutet, dass die Information von der Person selbst im Bildungsportal-Profil angelegt wurde (Self Service). Schulkennzahl 10000 bedeutet, dass der Datensatz aus PM-SAP (Personalverwaltung) hervorgeht.

Besonderes Augenmerk gilt der Verarbeitung von Kontaktdaten, da hier strikt zwischen dienstlichen und privaten Daten zu trennen ist. Es gilt:

Wenn Nutzer/innen die Anwendung im Zuge ihrer dienstlichen Tätigkeit verwenden, sind nur Dienstemailadressen (Flag official = 1) zu übernehmen
Wenn Nutzer/innen die Anwendung als Schüler/innen oder Erziehungsberechtigte verwenden, sind jene E-Mailadressen zu übernehmen, die die Schulkennzahl der Schule oder Schulkennzahl 0 aufweisen.
Innerhalb des Sets an abgerufenen E-Mailadressen kann optional eine Adresse als bevorzugte Adresse markiert sein (Flag preferred = 1). In diesem Fall kann diese E-Mailadresse als primäre Benachrichtigungsadresse gespeichert werden. Eine ausschließlich für den Zweck der Benachrichtigung übernommene E-Mailadresse darf aber anderen Nutzer/innen nicht angezeigt werden!

Beispiel: Person A ist an einer Schule X Erziehungsberechtigter und an Schule Y Lehrperson. Als bevorzugte E-Mailadresse wurde eine dienstliche Adresse gewählt. An Schule X wird vom Elternverein eine Anwendung angeboten. A stimmt der Verarbeitung seiner Daten zu, um sich in der Anwendung mit anderen Eltern zu vernetzen. A möchte aber nicht, dass andere Eltern sehen, das A auch Lehrperson an Schule Y ist. Daher ist es wichtig, dass die Anwendung für diese "private" Nutzung anderen Nutzer/innen auch nur die private E-Mailadresse zeigt. A hat aber seine dienstliche Adresse als Präferenz für Zustellungen eingestellt. Die Anwendung könnte (muss aber nicht) daher die Möglichkeit bieten, dass Benachrichtigungen an diese bevorzugte Adresse geschickt werden, ohne aber diese Adresse anderen Nutzer/innen zu zeigen.

Trennung der Nutzerkontexte

Nutzer/innen können Anwendungen in verschiedenen Kontexten verwenden. Der Kontext ergibt sich aus der Rolle einer Person an deiner bestimmten Organisationseinheit, bspw. "als Lehrperson an Schule A" oder "als Erziehungsberechtigter an Schule A". Je nach Kontext steht also eine dienstliche oder private Verwendung der Daten im Vordergrund.

Der edTech-Partner nimmt zur Kenntnis, dass bei der Übernahme von Daten Vorkehrungen getroffen werden, die eine Vermischung von Daten unterschiedlicher Schulen sowie privater und dienstlicher Kontaktdaten verhindern. Die Nutzerdatenschnittstelle liefert zu jedem Personendatensatz sowohl die Schulkennzahlen und Rollen, die eine Person innehat, als auch bei den Kontakt- und Adressdaten die Information, ob diese privat oder dienstliche Daten darstellen.

Beispiel: Person A ist an der Schule X sowohl Lehrperson als auch Erziehungsberechtigter. Der Datensatz von A beinhaltet drei E-Mailadressen. Zwei davon weisen als Quelle die Schulkennzahl von Schule X auf. Eine der E-Mailadressen wurde zur dienstlichen Verwendung markiert (official = 1) und der andere Datensatz als privater Kontakt (official = 0). Zusätzlich hat A eine dienstliche E-mailadresse des Bundes erhalten, die in der Personalverwaltung erfasst wurde. Diese ist im Datensatz mit der Schulkennzahl 10000 (= Bundesministerium für Bildung) und dem Flag official = 1 ersichtlich. Es muss daher bei der Verarbeitung dieser E-Mailadressen der Kontext des Nutzers in der Anwendung berücksichtigt werden.

Personen können außerdem eine E-Mailadresse als "bevorzugte Kontaktadresse" festlegen (preferred = 1). Diese Information sollte aber nicht als Entscheidungskriterium darüber herangezogen werden, welche E-Mailadresse verarbeitet wird, sondern gibt tatsächlich nur darüber Aufschluss, dass die Person an diese E-Mailadresse Benachrichtigungen erhalten möchte. Diese Adresse kann also in zwei Fällen herangezogen werden:

wenn eine separate Benachrichtigungsadresse gespeichert werden kann, die für andere Nutzer nicht sichtbar ist oder
als Fallback-Adresse, wenn keine andere Quelle in Frage kommt.

Zu unterscheiden ist daher je nach Art der Anwendung zwischen folgenden Use Cases:

Kategorie A - Getrennte Konten für dienstliche/private Nutzung

Anwendungen dieser Kategorie bieten Nutzer/innen je nach Kontext (dienstlich/privat) eigene Nutzerkonten. In diesem Fall ist die Vorgehensweise bei der Synchronisation:

Priorität	Dienstliches Konto	Privates Konto
1	SKZ der Schule + `official` = 1	SKZ der Schule + `official` = 0
2	SKZ 10000 + `official` = 1	`preferred` = 1
3	`preferred` = 1	SKZ = 0 (Self Service Record)
4	SKZ = 0 (Self Service Record)

Hinweis: beim SSO ist daher ggfs. auf die Nutzerkontextauswahl des Bildungsportals zurückzugreifen, damit beim SSO ein Routing in das dienstliche oder private Konto gewährleistet wird!

Kategorie B - Gemeinsame Konten für dienstliche/private Nutzung

Anwendungen dieser Kategorie haben nur ein einziges Nutzerkonto pro Person, das für dienstliche und private Zwecke genutzt wird. In diesem Fall ist die Vorgehensweise bei der Synchronisation:

Priorität	Quelle	Notiz
1	`preferred` = 1	Bevorzugte Adresse wählen
2	SKZ != 10000 oder 0 + `official` = 1	Dienstliche Adresse der Schule wählen
3	SKZ = 10000 + `official` = 1	Dienstliche Adresse des BMB wählen
4	SKZ = 0	Vom User selbst angelegte Adresse
5	erste andere SKZ	Erste gefundene Adresse wählen

Technische Aspekte

Die Nutzerdatenschnittstelle ist darauf optimiert, nur Änderungen seit einem bestimmten Zeitpunkt abzufragen. Komplettabfragen aller Personen, auf die eine Anwendung Zugriff hat, sind daher nur in Ausnahmefällen (bspw. Verdacht auf Fehler) und soweit als möglich am Wochenende oder in Ferienzeiten durchzuführen.

Die Abfrage der Änderung erfolgt über die Übermittlung des Parameters cursor. Am Ende jeder Abfrage wird der letzte Cursor-Wert ausgegeben und kann für die nächste Abfrage herangezogen werden. Über den cursor eingeschränkte Abfragen können laufend (bspw. stündlich) erfolgen.

Hinweis: aus Gründen der Abwärtskompatibilität wird derzeit noch der Parameter timechanged angeboten, dieser sollte aber mittelfristig nicht mehr genutzt werden.

Zur Sicherstellung der Korrektheit aller Daten müssen edTech-Anwendungen mindestens einmal pro Tag die Nutzerdatenschnittstelle abrufen und etwaige Datenänderungen automatisch übernehmen.