| Attribut | 0..N | Bezeichnung |
|---|---|---|
Identifikatoren |
||
1..1 |
Telematik-ID |
|
1..N |
Sektor-ID |
|
Namen |
||
1..1 |
Anzeigename |
|
1..1 |
Name |
|
0..1 |
Alternativer Name |
|
0..1 |
Organisation |
|
0..1 |
Vorname |
|
0..1 |
Nachname |
|
0..1 |
Titel |
|
Adressdaten |
||
1..1 |
Straße und Hausnummer |
|
1..1 |
PLZ |
|
1..1 |
Ort |
|
1..1 |
Bundesland oder Region |
|
1..1 |
Landeskürzel |
|
Berufliche Informationen |
||
1..N |
Berufsgruppe |
|
1..N |
Fachgebiet |
|
1..1 |
Typ des Eintags |
|
0..N |
Lebenslange Arztnummer |
|
Anwendungsdaten |
||
0..N |
KIM-Adresse |
|
0..N |
KIM-Adresse mit Version |
|
0..N |
KIM-Adresse mit Version |
|
0..1 |
Maximale Anzahl von KIM-Adressen in den KOM-LE-Fachdaten |
|
Zertifikate |
||
0..N |
Zertifikat |
|
0..1 |
Gültigkeitsbeginn Zertifikat |
|
0..1 |
Zertifikat gültig? |
|
0..1 |
Gültigkeitsende Zertifikat |
|
0..1 |
Seriennummer des Zertifikats |
|
0..1 |
Zertifikatsaussteller |
|
0..1 |
Verschlüsselungsalgorithmus des Zertifikats |
|
Systemdaten |
||
1..1 |
Verwaltet durch Kartenherausgeber? |
|
1..1 |
Eintrag einer natürlichen Person? |
|
1..1 |
Geändert am |
|
1..1 |
Eintrag aktiv? |
|
0..100 |
Abstimmung zwischen TSP und Kartenherausgeber |
|
Telematik-ID ist ein eindeutiger Identifikator einer Institution oder einer Person in der TI. Spezifiziert in gemSpec_PKI, Kapitel 4.7.
Die sektorspezifische Kennung einer Institution oder einer Person.
Per Eintag können mehrere Kennungen angeben werden. Im Gegensatz zu TelematikID sind die domainID nicht eindeutig können in mehreren Einträgen gleichzeitig vorkommen.
Die Nutzung für die Sektoren wird in Kapitel Attributtabellen von Dokument gemILF_Pflege_VZD beschrieben.
-
Kassenärztliche Vereinigungen (SMC-B-Eintrag): Betriebsstättennummer der Praxis
-
Kassenzahnärztliche Vereinigungen (SMC-B Eintrag): Abrechnungsnummer
-
SMC-B-Eintrag für Apotheken: Nicht verwendet
-
HBA-Eintrag für Apotheker: Spezifisches Kennzeichen der Apotheker. Kann mehrfach vorkommen (0..100).
-
Krankenhäuser (SMC-B-Eintrag): Betriebsstättennummer des Krankenhauses
-
Psychotherapeuten (HBA-Eintrag): Spezifisches Kennzeichen der Psychotherapeuten. Kann mehrfach vorkommen (0..100).
-
Ärzte (HBA-Eintrag): Spezifisches Kennzeichen der Ärzte. Kann mehrfach vorkommen (0..100).
-
Zahnärzte (HBA-Eintrag): Spezifisches Kennzeichen der Zahnärzte. Kann mehrfach vorkommen (0..100).
-
Gesetzlichen Krankenkassen (SMC-B-Eintrag): Institutionskennzeichen. Kann mehrfach vorkommen (0..100).
Dieses Attribut wird verwendet um vollen Namen einer Institution oder Person in GUI anzuzeigen.
Spezifiziert in RFC2798 Section 2.3
Bei Personen wird displayName genutzt, um vollen Namen einer Person gegenüber dem Anwender darzustellen. Es wird empfohlen den Namen wie folgt anzugeben (Nachname, Vorname):
Dr. Mustermann, Manfred
Eindeutiger Name einer Person oder Institution.
LDAP unterstützt grundsätzlich mehrere Namen eines Objekts, in der TI wird jedoch meistens nur ein cn-Attribut verwendet, daher ist cn in der Regel identisch mit displayName.
Spezifiziert in RFC2256 Section 5.4
Optionaler Name einer Organisation zu welcher diese Eintrag gehört.
Spezifiziert in RFC2256 Section 5.11
Alle Vornamen einer natürlicher Person. Vornamen sollen nur bei natürlichen Personen befüllt sein, bei Institutionen muss givenName leer bleiben.
Spezifiziert in RFC2256 Section 5.43
Nachname eine natürlichen Person. Nachnamen sollen nur bei natürlichen Personen befüllt sein, bei Institutionen muss sn leer bleiben.
Spezifiziert in RFC2256 Section 5.5
Akademischer oder Adelstitel einer natürlichen Person.
Spezifiziert in RFC2256 Section 5.13
| Beispiel | Attribute |
|---|---|
Hallesches Ufer 21 |
|
Postleitzahl Spezifiziert in RFC2256 Section 5.18
Bundesland oder Region
Spezifiziert ib RFC2256 Section 5.9
Kann als st abgekürzt werden
-
Baden-Württemberg
-
Bayern
-
Berlin
-
Brandenburg
-
Bremen
-
Hamburg
-
Hessen
-
Mecklenburg-Vorpommern
-
Niedersachsen
-
Nordrhein-Westfalen
-
Rheinland-Pfalz
-
Saarland
-
Sachsen
-
Sachsen-Anhalt
-
Schleswig-Holstein
-
Thüringen
-
Nordrhein
-
Westfalen-Lippe
Zweistelliger Landeskürzel aus dem Wertebereich ISO 3166-1 alpha-2
Berufsgruppe oder Betriebsstätten-Typ innerhalb der Telematikinfrastruktur.
Spezifiziert in gemSpec_OID
Wertebereiche:
Der Wertebereich für specialization entspricht den in HL7 definierten und für ePA festgelegten Werten.
Bildungsregel:
urn:as:{OID Codesystem}:{Code}
Beispiel für Facharzt Allgemeinmedizin:
urn:as:1.2.276.0.76.5.114:010
Weitere Ressourcen:
Bildungsregel:
urn:psc:{OID Codesystem}:{Code}
Beispiel für Allgemeinmedizin:
urn:psc:1.3.6.1.4.1.19376.3.276.1.5.4:ALLG
Das Attribut wird automatisch aus professionOID berechnet. Werte werden primär durch ePA verwendet.
Liste aller KIM-Adressen einer Person oder einer Institution. Zur Kompatibilität bleibt die KIM Mail Adresse in diesem Attribut zusätzlich zum Attribut komLeData erhalten.
mail: adresse1@anbieter.kim.telematik mail: adresse2@anbieter.kim.telematik
Enthält die KOM‑LE-Version des Clientmoduls der angegebenen "mail"-Adresse im Attribut "version". Anhand dieser Version erkennt das sendende Clientmodul, welche KOM‑LE-Version vom Empfänger-Clientmodul unterstützt wird und in welchem Format die Mail an diesen Empfänger versandt wird.
Wenn zu einer KOM‑LE-Mail-Adresse aus Attribut "mail" kein korrespondierender Eintrag im Attribut "komLeData" vorhanden ist, muss automatisch die KOM‑LE-Version 1.0 angenommen werden.
Jeder Datensatz muss vollständig sein und besteht aus:
* der KOM‑LE-Mail-Adresse (Attribut mail)
* der zugehörigen KOM‑LE-Version (Attribut version)
Zu beachten ist bei der Auswertung bzw. Pflege dieser Daten:
-
Ein komLeData‑Eintrag besteht aus:
-
der Mail-Adresse (Attribut
mail) -
der zugehörigen KOM‑LE-Version (Attribut
version)
-
-
Für jede Mail-Adresse gilt:
-
Pro Mail-Adresse darf es genau einen Eintrag in der Datenstruktur
komLeDatageben
-
-
Konsistenzregeln:
-
Es dürfen nur Mail-Adressen referenziert werden, die im übergeordneten Attribut
mailenthalten sind -
Wenn zu einer Mail-Adresse kein Eintrag existiert,
-
muss KOM‑LE-Version
1.0angenommen werden
-
-
-
Wird eine Mail-Adresse gelöscht:
-
muss auch der zugehörige komLeData‑Eintrag gelöscht werden
-
-
Beim Schreiben der Daten:
-
wird immer die gesamte Liste geschrieben
-
-
Für Änderungen gilt:
-
zuerst den aktuellen Eintrag lesen
-
anschließend die Änderungen in der Liste vornehmen
-
danach die komplette Liste wieder zurückschreiben
-
komLeData: 1.0,mc_smcb_za@dom1.komle.telematik-test komLeData: 1.0,mz_smcb_za@dom2.kim.telematik-test komLeData: 1.0,mz_smcb_za@dom1.kim.telematik-test komLeData: 1.0,mb_secu_sm@dom3.kim.telematik-test komLeData: 1.0,mb_secu_sm@dom4.kim.telematik-test komLeData: 1.5,ak_secu_102@dom5.kim.telematik-test
Enthält die KOM‑LE-Version des Clientmoduls der angegebenen "mail"-Adresse im Attribut "version".
Zusätzlich kann zur KOM‑LE-Version ein + angegeben sein.
Anhand dieser Version erkennt das sendende Clientmodul: * welche KOM‑LE-Version vom Empfänger-Clientmodul unterstützt wird * in welchem Format die Mail an diesen Empfänger versandt wird
Wenn ein zusätzliches + angegeben ist:
* können mit dieser "mail"-Adresse Nachrichten größer 15 MiB verarbeitet werden
Wenn noch keine Version zu einer KOM‑LE-Mail-Adresse angegeben wurde:
* wird vom VZD automatisch die Version 1.0 eingetragen
Jeder Datensatz muss vollständig sein und enthält:
* die KOM‑LE-Mail-Adresse (Attribut mail)
* die KOM‑LE-Version (Attribut version)
Zusätzlich kann ein Datensatz enthalten:
* ein oder mehrere Anwendungskennzeichen (Attribut appTags)
Dabei gilt:
* Das Attribut appTags ist optional
* Wenn kein Anwendungskennzeichen vorhanden ist,
** können alle KIM-Anwendungen an diesen Empfänger versendet werden
Die Kodierung eines Eintrags erfolgt wie folgt:
* Bestandteile werden durch , getrennt
Mail-Adresse
KOM‑LE-Version
** optional: Anwendungskennzeichen
-
Mehrere Anwendungskennzeichen werden durch
|getrennt
Zu beachten ist bei der Auswertung bzw. Pflege dieser Daten:
-
Ein kimData‑Eintrag besteht aus:
-
der Mail-Adresse (Attribut
mail) -
der zugehörigen KOM‑LE-Version (Attribut
version) -
optional einem
+hinter der Version -
optional einem oder mehreren Anwendungskennzeichen (Attribut
appTags)
-
-
Wenn mehrere Anwendungskennzeichen angegeben sind:
-
werden sie im LDAP-Attribut durch das Zeichen
|getrennt
-
-
Für jede Mail-Adresse gilt:
-
Es darf nur einen kimData‑Eintrag geben
-
-
Wird eine Mail-Adresse gelöscht:
-
muss auch der zugehörige kimData‑Eintrag gelöscht werden
-
-
Beim Schreiben der Daten:
-
wird immer der gesamte kimData‑Eintrag geschrieben
-
inklusive aller enthaltenen Attribute und Werte (für alle Mail-Adressen)
-
-
Für Änderungen gilt:
-
zuerst den aktuellen Eintrag lesen
-
anschließend Änderungen vornehmen
-
danach den kompletten Eintrag wieder zurückschreiben
-
kimData: mc_smcb_za@dom1.komle.telematik-test,1.0,eEB kimData: mz_smcb_za@dom2.kim.telematik-test,1.0,DALE-UV|eEB kimData: mz_smcb_za@dom1.kim.telematik-test,1.0 kimData: mb_secu_sm@dom3.kim.telematik-test,1.0 kimData: mb_secu_sm@dom4.kim.telematik-test,1.0 kimData: ak_secu_102@dom5.kim.telematik-test,1.5
|
ℹ️
|
Aktuell werden keine appTags bzw. Anwendungskennzeichen verwendet. |
Maximale Anzahl von mail Adressen in den KOM-LE-Fachdaten. Falls kein Wert eingetragen wurde, können beliebig viele mail Adressen in den KOM-LE Fachdaten eingetragen werden. Falls ein Wert eingetragen wurde, können maximal so viele mail Adressen in den KOM-LE Fachdaten eingetragen werden.
X509-Zertifikate werden für Verschlüsselung der KIM-Nachrichten sowie bei der Berechtigungserteilung in der ePA verwendet.
Zertifikate werden als DER-kodierte Binary transportiert.
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. Wird vom VZD zur Ermittlung der zeitlich gültigen Zertifikate genutzt. Dieses Attribut ist nicht in der flachen Liste enthalten.
Wird vom VZD eingetragen. Wert == TRUE, wenn das userCertificate gemäß OCSP gültig ist (OCSP Response Status "good"), Wert == FALSE bei Zertifikaten von noch nicht freigeschalteten Karten (OCSP Response Status "unknown"). Wenn das Attribut den Wert FALSE enthält, wird der Zertifikatseintrag nicht in die flache Liste übernommen.
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. Wird vom VZD zur Ermittlung der zeitlich gültigen Zertifikate genutzt. Dieses Attribut ist nicht in der flachen Liste enthalten.
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. Kann zur Suche nach Zertifikaten genutzt werden. Dieses Attribut ist nicht in der flachen Liste enthalten.
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. Kann zur Suche nach Zertifikaten genutzt werden. Dieses Attribut ist nicht in der flachen Liste enthalten.
Enthält eine Liste von Organisationen, die für die Administration dieses Datensatzes berechtigt sind.
Enthält TRUE wenn die Daten durch einen Kartenherausgeber eingestellt wurden.
Enthält TRUE wenn Eintrag eine natürliche Person beschreibt (einen Leistungsebringer) - d.h. einen HBA Empfänger. Enthält FALSE wenn es um einen Eintrag einer Institution handelt, d.h. SMC-B Empfänger.
Zeitstempel der letzten Änderung. Wert wird bei jeder Aktualisierung durch VZD auf aktuelle Systemzeit gesetzt.
Mit diesem Attribut im Basiseintrag (Verzeichnisdienst_Eintrag in Abb_VZD_logisches_Datenmodell) kann der Client (Kartenherausgeber, TSP) die Aufnahme des VZD-Eintrags in die flache Liste steuern. Wenn das Attribut beim Anlegen eines VZD-Eintrags mit Zertifikat nicht angegeben wird, setzt der VZD das Attribut active auf TRUE (Default-Wert). Bei FALSE wird der Eintrag vom VZD aus der flachen Liste entfernt bzw. nicht übertragen. Dieses Attribut ist nicht in der flachen Liste enthalten. Wenn der VZD beim zeitlichen Ablauf des letzten Zertifikats einen VZD-Eintrag aus der flachen Liste entfernt, bleibt das Attribut active unverändert. Beim erneuten Hinzufügen eines Zertifikats wird der VZD-Eintrag also wieder in die flache Liste übernommen, wenn dieses Attribut den Wert "true" enthält.
Kann von den pflegenden Clients zur Abstimmung der Prozesse zwischen z. B. Kartenherausgeber und TSP genutzt werden. Dieses Attribut wird durch den VZD nicht ausgewertet. Die Werte für dieses Attribut müssen von den pflegenden Organisationen festgelegt und abgestimmt werden. Array von Strings (wird in LDAP auf <String, String> gemappt). Dieses Attribut ist nicht in der flachen Liste enthalten. Kann mehrfach vorkommen (0..100).
| Typ | Name | Nachname | Vorname | Adresse | PLZ | Ort |
|---|---|---|---|---|---|---|
🏥 |
Praxis Helga Freifrau Mondwürfel |
Bahnhof Str. 13 |
91234 |
Nürnberg |
||
👩⚕️ |
Oldenburg, Petra |
Oldenburg |
Petra |
Hallesches Ufer 21 |
88451 |
Dettingen |
|
|
|
|
|
|
|
| LDAP-Directory Attribut | Zertifikat | Client | KIM Anbieter | |
|---|---|---|---|---|
givenName |
HBA |
x |
||
SMC-B |
nicht verwendet |
|||
sn |
HBA |
x |
||
SMC-B |
Vom VZD als Kopie des Attributs displayName eingetragen |
|||
cn |
HBA |
Vom VZD als Kopie des Attributs displayName eingetragen |
||
SMC-B |
Vom VZD als Kopie des Attributs displayName eingetragen |
|||
displayName |
HBA |
x |
||
SMC-B |
x |
|||
streetAddress |
HBA |
x |
||
SMC-B |
x |
|||
postalCode |
HBA |
x |
||
SMC-B |
x |
|||
countryCode |
HBA |
x |
||
SMC-B |
x |
|||
localityName |
HBA |
x |
||
SMC-B |
x |
|||
stateOrProvinceName |
HBA |
x |
||
SMC-B |
x |
|||
title |
HBA |
x |
||
SMC-B |
nicht verwendet |
|||
organization |
HBA |
x |
||
SMC-B |
x |
|||
otherName |
HBA |
x |
||
SMC-B |
x |
|||
specialization |
HBA |
x |
||
SMC-B |
x |
|||
domainID |
HBA |
x |
||
SMC-B |
x |
|||
holder |
HBA |
x |
||
SMC-B |
x |
|||
maxKOMLEadr |
HBA |
x |
||
SMC-B |
x |
|||
personalEntry |
HBA |
x |
||
SMC-B |
x |
|||
dataFromAuthority |
HBA |
wird vom VZD eingetragen |
||
SMC-B |
wird vom VZD eingetragen |
|||
userCertificate |
HBA |
x |
||
SMC-B |
x |
|||
entryType |
HBA |
x |
||
SMC-B |
x |
|||
telematikID |
HBA |
x |
x |
|
SMC-B |
x |
x |
||
professionOID |
HBA |
x |
||
SMC-B |
x |
|||
usage |
HBA |
x |
||
SMC-B |
x |
|||
description |
HBA |
x |
||
SMC-B |
x |
|||
HBA |
x |
|||
SMC-B |
x |
|||
komLeData |
HBA |
x |
||
SMC-B |
x |
|||
kimData |
HBA |
x |
||
SMC-B |
x |
|||
changeDateTime |
HBA |
wird vom VZD eingetragen |
||
SMC-B |
wird vom VZD eingetragen |
|||
Erläuterungen zu den Spalten:
-
Zertifikat
-
Der Wert für das LDAP Attribut wird dem Zertifikat entnommen.
-
Bei Hinzufügen eines Zertifikats wird das LDAP Attribut aktualisiert.
-
-
Client
-
Der Wert für das LDAP Attribut wird durch den Client des Kartenherausgebers gepflegt.
-
-
KIM Anbieter
-
Der Wert für das LDAP Attribut wird durch den KIM-Abieter gepflegt.
-
Erläuterungen für spezielle Attribute:
-
personalEntry: Beim Löschen von Zertifikaten wird der Wert neu berechnet. Wenn alle Zertifikate gelöscht wurden, wird der Wert auf "FALSE" gesetzt.
-
Aus den Zertifikaten befüllte Attribute entryType, professionOID: Beim Löschen eines Zertifikats wird der Wert auf Basis aller verbleibender Zertifikate neu berechnet und gesetzt.
-
Alle aus den Zertifikaten befüllte Attribute (givenName, sn, personalEntry, telematikID, professionOID, entryType) werden beim Hinzufügen eines neuen Zertifikats aktualisiert bzw. ergänzt.
-
telematikID im VZD Basiseintrag: Wird aus dem Zertifikat befüllt. Kann in dem REST Interface zwar angegeben, aber nicht auf einen anderen Wert geändert werden.