- Einführung und Ziele
- Aufgabenstellung
- User Stories
- TI-Messenger Nutzer sucht im FHIR-Directory
- Eintrag im Personenverzeichnis für LE
- Organisation des Gesundheitswesens verwaltet ihren Eintrag im Organisationsverzeichnis
- Kartenherausgeber pflegen Daten im FHIR-Directory
- TI-Messenger-Anbieter verwaltet TI-Messenger-Föderations-Domains
- Sicherung der Datenqualität durch die gematik
- User Stories
- Qualitätsziele
- Stakeholder
- Randbedingungen
- Fachlicher Kontext
Das FHIR-Directory der Telematikinfrastruktur (TI) ist ein Verzeichnis von Organisationen des Gesundheitswesens und ein Verzeichnis von Leistungserbringern (LE). Es ist ein wesentlicher Bestandteil der TI 2.0 und ermöglicht den Nutzern und Anbietern von Fachanwendungen der TI, wie z.B. dem TI-Messenger, ihre Einträge im FHIR-Directory um Informationen zu erweitern sowie nach Organisationen und Personen zu suchen. Eine Datenbasis für die Einträge der Organisationen und LE wird durch die Kartenherausgeber gepflegt. Die Einträge der Organisationen und LE werden im FHIR-Format gepflegt und abgefragt.
Das FHIR-Directory ist das zentrale Adressbuch für die Organisationen des Gesundheitswesens und LE. Alle Fachanwendungen der TI, die Adressdaten und fachliche Daten der Organisationen und LE benötigen finden die Daten im FHIR-Directory. Dabei wird unterschieden zwischen einem Organisationsverzeichnis und einem Personenverzeichnis. Um dies zu erreichen besitzt das FHIR-Directory Schnittstellen
-
zur Pflege der Daten durch Kartenherausgeber und durch die Eigentümer der Einträge
-
zur Suche nach Einträgen durch Nutzer der TI
-
Als TI-Messenger-Nutzer möchte ich komfortabel aus meiner TI-Messenger App nach Kontakten im FHIR-Directory suchen können, sodass ich einen geeigneten TI-Messenger-Kommunikationspartner finden kann. Komfortabel suchen heißt, dass verschiedene Suchoptionen unterstützt werden, wie Volltextsuche, genaue Angabe von Suchparametern und unscharfe Suche. Ich möchte auch in meiner App verschiedene Such- und Filterfunktionen kombinieren können wie z.B. die Ortungsfunktion und die Filterung nach Öffnungszeiten, um eine Organisation zu finden.
-
Als TI-Messenger-Nutzer möchte ich die Ortungsfunktion meines Geräts nutzen können, um nahegelegene Organisationen finden zu können, so dass ich spontan die für mich bestgelegene Organisation auswählen kann.
-
Als TI-Messenger-Nutzer möchte ich in der Lage sein, Organisationen herauszufiltern, die gerade geöffnet haben oder die bald öffnen werden, so dass ich nicht vor verschlossenen Türen stehe, wenn ich die Organisation aufsuchen will.
-
Als TI-Messenger-Nutzer möchte ich zu den gefundenen Organisationen zusätzliche Informationen erhalten, um mich mit ihnen in Verbindung setzen bzw. um mich über sie informieren zu können (z.B. Webseite, E-Mail-Adresse, Telefonnummer, unterstützte Sprachen).
-
Als TI-Messenger-Nutzer und Leistungserbringer (LE) möchte ich im Personenverzeichnis komfortabel (siehe User Story (1)) nach anderen LE suchen können, um mit ihnen auf unkomplizierte Weise kommunizieren zu können.
Die Authentifizierung der TI-Messenger-Nutzer am FHIR-Directory erfolgt durch Nachweis der Zugehörigkeit zu einem TI-Messenger-Service. Die Zugehörigkeit zu einem TI-Messenger-Service wird durch eine sichere Überprüfung durch das FHIR-Directory beim Messenger-Service erreicht. Der Vorgang erfolgt ohne Nutzerinteraktion. Als Ergebnis der Authentifizierung erhält der TI-Messenger-Client ein tim-search-accesstoken, dass für die Zugriffe auf das FHIR-Directory, ohne erneute Überprüfung beim TI-Messenger-Service, verwendet werden kann. Das accesstoken enthält die TI-Messenger-Adresse des TI-Messenger-Nutzers und, ob es sich beim Nutzer um einen Leistungserbringer (LE) handelt, der eine TI-Messenger-Adresse im Personenverzeichnis hat. TI-Messenger-Nutzer dürfen grundsätzlich immer im Organisationsverzeichnis suchen. Wenn der Nutzer zusätzlich ein LE ist und seine TI-Messenger-Adresse im Personenverzeichnis eingetragen ist, dann kann der Nutzer auch im Personenverzeichnis nach Kontakten suchen.
Als TI-Messenger-Nutzer und LE habe ich die Möglichkeit meine TI-Messenger-Adresse in das Personenverzeichnis einzutragen. Dadurch habe ich die Kontrolle, ob ich über den TI-Messenger im Personenverzeichnis erreichbar bin.
Um die TI-Messenger-Adresse im eigenen Eintrag im Personenverzeichnis speichern zu können, ist es erforderlich, dass der TI-Messenger-Nutzer sicher authentifiziert wird. Durch Anfrage des TI-Messenger-Clients beim FHIR-Directory wird ein OpenID Connect Authorization Code Flow ausgelöst. Mithilfe eines IDPs aus der TI-IDP-Föderation und eines Authenticators für diesen IDP authentifiziert sich der Nutzer. Am Ende erhält der Nutzer ein owner-accesstoken, dass ihn berechtigt seine TI-Messenger-Adresse im Personenverzeichnis des FHIR-Directories einzutragen oder zu löschen. Die Eintragung der eigenen TI-Messenger-Adresse in den eigenen Eintrag im Personenverzeichnis ist die Voraussetzung, um selbst im Personenverzeichnis nach anderen LE suchen und von anderen LE gefunden werden zu können.
Als Administrator einer Organisation des Gesundheitswesens möchte ich konfigurieren können, wie meine TI-Messenger-Kontaktdaten im Organisationsverzeichnis gefunden werden, damit die Arbeitsabläufe in meiner Organisation sinnvoll durch den TI-Messenger unterstützt werden.
Um die TI-Messenger-Kontaktdaten im eigenen Eintrag im Organisationszeichnis speichern zu können und Unterstukturen von TI-Organization-Einträgen anzulegen und zu verwalten, ist es erforderlich, dass der Administrator einer Organisation sicher authentifiziert wird. Durch Anfrage des Org-Admin-Clients oder TI-Messenger-Clients beim FHIR-Directory wird ein OpenID Connect Authorization Code Flow ausgelöst. Mithilfe eines IDPs aus der TI-IDP-Föderation und eines Authenticators auf dem Gerät des Org-Admin-Clients/TI-Messenger-Clients authentifiziert sich der Administrator. Am Ende erhält der Administrator ein owner-accesstoken, dass ihn berechtigt seine Daten im Organisationszeichnis des FHIR-Directories einzutragen oder zu löschen. Vom Kartenherausgeber verwaltete Daten können nicht durch den Administrator einer Organisation geändert werden.
-
Als Kartenherausgeber brauche ich eine einfache (technische) Möglichkeit, die Daten für die ich verantwortlich bin, im VZD-FHIR-Directory editieren zu können (einstellen, lesen, verändern, löschen).
-
Als Kartenherausgeber möchte ich, dass ich bei einem Ausfall oder Störungen des FHIR-Directory entsprechendes Feedback und Support erhalte.
Die Kartenherausgeber pflegen die Daten ihrer Mitglieder im FHIR-Directory. Das erfolgt zur Zeit noch nicht direkt, sondern über die Pflege der Einträge im LDAP-Directory, die in das FHIR-Directory regelmäßig automatisch synchronisiert werden. Damit ein Kartenherausgeber Einträge pflegen kann, muss er sich beim Anbieter des Verzeichnisdienstes registrieren. Als Ergebnis der Registrierung erhält der Kartenherausgeber Credentials, mit denen er sich authentisieren kann und so die Berechtigung zur Pflege der Einträge in Form eines accesstokens erhält.
Als TI-Messenger-Anbieter möchte ich einfach und effizient die Föderationsliste des TI-Messengers herunterladen und die Domains der von mir betriebenen Messenger-Services verwalten können.
Die TI-Messenger-Anbieter pflegen die TI-Messenger-Domains der von ihnen betriebenen Messenger-Services im FHIR-Directory. Zusätzlich benötigt der TI-Messenger-Anbieter die Föderationsliste vom FHIR-Directory. Das FHIR-Directory stellt für diese Operationen eine Schnittstelle bereit. Damit ein TI-Messenger-Anbieter die Schnittstelle nutzen kann, muss er sich beim Anbieter des Verzeichnisdienstes registrieren. Als Ergebnis der Registrierung erhält der TI-Messenger-Anbieter Credentials, mit denen er sich authentisieren kann und so die Berechtigung zur Nutzung der Schnittstelle in Form eines accesstokens erhält.
Als gematik möchte ich die Daten-Qualität der Einträge im FHIR-Directory prüfen können, damit alle Nutzer die benötigten Daten im FHIR-Directory finden können.
Zur Sicherung der Datenqualität nutzt die gematik
-
periodische, datenschutzkonforme Reports, welche durch den VZD-FHIR-Directory Anbieter erstellt werden
-
die Suchfunktion im VZD-FHIR-Directory zum Auffinden von Datensätzen mit geringer Qualität bzw. Fehlern.
Die Suchfunktion im VZD-FHIR-Directory erfolgt durch die gematik analog zu der Suche durch TI-Messenger-Anbieter:
Damit die gematik die Schnittstelle nutzen kann, muss sie sich beim Anbieter des Verzeichnisdienstes registrieren. Als Ergebnis der Registrierung erhält die gematik Credentials, mit denen sie sich authentisieren kann und so die Berechtigung zur lesenden Nutzung der Schnittstelle in Form eines accesstokens erhält. gematik-Nutzer dürfen im Organisationsverzeichnis und im Personenverzeichnis nach Datensätzen suchen.
-
Funktionale Eignung
Über den VZD-FHIR-Directory müssen Einträge von Organisationen und Leistungserbringern inklusive ihrer Kontaktdaten auffindbar sein. Dazu bietet der VZD-FHIR-Directory folgende Schnittstellen an:
-
FHIR Schnittstelle zur Suche /search
-
FHIR Schnittstelle zur Pflege eigener Einträge /owner
-
REST Schnittstelle zur Pflege eigener TIM Provider Einträge und selbst betriebener TI-Messenger-Domänen der Oragnisationen /tim-provide-services
-
-
Zuverlässigkeit
TI Anwendungen wie der TI Messenger benötigen die Suchfunktion vom dem VZD-FHIR-Directory. Die Suchfunktion vom dem VZD-FHIR-Directory muss deshalb mit einer hohen Verfügbarkeit bereitgestellt werden.
-
Sicherheit
Einzelne Organisations- und Leistungserbringer-Einträge aus dem VZD-FHIR-Directory werden allen Clients zur Verfügung gestellt. Geschützt werden müssen
-
Schreibzugriffe auf VZD-FHIR-Directory Einträge
-
Der VZD-FHIR-Directory Datenbestand als gesamter Datenbestand (einzelne Einträge sind für alle Clients lesbar, der gesamte Datenbestand nur für berechtigte Clients)
-
-
Wartbarkeit und Betreibbarkeit
Die Wartbarkeit und Betreibbarkeit von dem VZD-FHIR-Directory muss gewährleistet werden durch:
-
die Dokumentation,
-
Spezifikation von Schnittstellen,
-
eine skalierbare und erweiterbare Architektur auf Basis von Standardkomponenten (FHIR Server, Datenbanken,…),
-
ein übersichtliches Design,
-
die Konfigurierbarkeit wichtiger Variablen,
-
eine hohe Kohäsion und lose Kopplung der Module,
-
automatisierte Tests.
-
-
Performance und Skalierbarkeit
Die Performanceanforderungen berücksichtigen den Bedarf der Fachanwendungen, welche das VZD-FHIR-Directory nutzen. Die Performance-Kenngrößen decken drei Dimensionen ab:
-
Durchsatz, die Anzahl an Funktionsaufrufen oder die Datenmenge, die pro Zeiteinheit durch das System oder eine seiner Komponenten abgearbeitet werden,
-
die erlaubte Bearbeitungszeit je Funktionsaufruf und die
-
Verfügbarkeit über die gesamte Betriebszeit.
Die Skalierbarkeit stellt die Anpassbarkeit des VZD-FHIR-Directory an sich ändernde Performanceanforderungen der Fachanwendungen sicher.
-
-
Kompatibilität (FHIR, OIDC, OAuth)
Das VZD-FHIR-Directory basiert - zur Gewährleistung der Kompatibilität mit möglichst vielen Fachanwendungen - auf Standards. Dazu gehören
-
FHIR (Fast Healthcare Interoperability Resources): Der Standard unterstützt den Datenaustausch zwischen Softwaresystemen im Gesundheitswesen.
-
OpenID Connect (OIDC) als Authentifizierungsschicht (basiert auf dem Autorisierungsframework OAuth 2.0) gewährleistet die Kompatibilität zu Authentifizierungslösungen.
-
OAuth (Open Authorization) ermöglicht die standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Anwendungen.
-
Übertragbarkeit
Mit der Übertragbarkeit (oder Portabilität) kann die Software von einer Hardware- oder Softwareumgebung in eine andere ‚übertragen‘ werden.
Motivation
Weil Qualitätsziele grundlegende Architekturentscheidungen oft maßgeblich beeinflussen, sollten Sie die für Ihre Stakeholder relevanten Qualitätsziele kennen, möglichst konkret und operationalisierbar.
Form
Tabellarische Darstellung der Qualitätsziele mit möglichst konkreten Szenarien, geordnet nach Prioritäten.
| Stakeholder | Erwartung |
|---|---|
Hersteller von TI-Messenger Clients |
Die Hersteller müssen wissen, welche FHIR-Ressourcen im FHIR-Directory gespeichert werden und welche Attribute von Clients für die Suche nach Einträgen und für die Darstellung von Ergebnissen unterstützt werden müssen. |
Hersteller von Org-Admin Clients |
Die Hersteller müssen wissen, welche FHIR-Ressourcen im FHIR-Directory gespeichert werden, welche FHIR-Ressourcen angelegt werden dürfen, wie die Beziehungen zwischen den FHIR Ressourcen sind und welche Attribute geändert werden dürfen. |
Kartenherausgeber |
Die Kartenherausgeber müssen wissen, welche FHIR-Ressourcen im FHIR-Directory gespeichert werden, welche FHIR-Ressourcen angelegt werden dürfen, wie die Beziehungen zwischen den FHIR Ressourcen sind und welche Attribute geändert werden dürfen. |
Hersteller von TI-Messenger Fachdiensten |
Die Hersteller müssen wissen, welche FHIR-Ressourcen sie erzeugen und ändern dürfen und welche Attribute sie pflegen müssen. |
gematik |
Die gematik muss in der Lage sein die Daten-Qualität im FHIR-Directory zu prüfen. |
Das VZD-FHIR-Directory muss mit dem VZD-LDAP-Directory [gemSpec_VZD] koexistieren. Die Daten aus dem VZD-LDAP-Directory werden in das VZD-FHIR-Directory synchronisiert und können dort ergänzt werden. Das VZD-FHIR-Directory muss die nötigen Services für den TI-Messenger bereitstellen [gemSpec_TI-Messenger-Client][gemSpec_TI-Messenger-Dienst][gemSpec_TI-Messenger-FD].
Die Abbildung zeigt das FHIR-Directory mit seinen Außen-Schnittstellen und Nutzern.
| Nutzer und Rolle | Beschreibung |
|---|---|
Nutzer |
TI-Messenger Nutzer können zwei Rollen einnehmen. Alle TI-Messenger Nutzer können im FHIR-Directory über die Schnittstelle (1) nach Einträgen im Organisationsverzeichnis suchen. |
TI-Messenger Nutzer LE |
TI-Messenger Nutzer, die auch LE sind, können zusätzlich im Personenverzeichnis nach Einträgen suchen, wenn sie ihre Matrix Adresse über die Schnittstelle (2) in ihrem Eintrag gespeichert haben. |
Org-Admin |
Administratoren der Organisationen können im FHIR-Directory über die Schnittstelle (2) ihren Eintrag im Organisationsverzeichnis ändern und um zusätzliche Ressourcen erweitern. |
| IT-Systeme | Beschreibung |
|---|---|
Kartenherausgeber |
Die Kartenherausgeber nutzen die Schnittstelle (3) um die Einträge ihrer Mitglieder im LDAP-Directory und zukünftig im FHIR-Directory zu pflegen. |
TI-Messenger Anbieter |
Die TI-Messenger Anbieter nutzen die Schnittstelle (4) um die Föderationsliste des TI-Messengers abzufragen und um die Domains der von ihnen betriebenen Messenger-Services als Teil der TI-Messenger Föderation zu verwalten. |
gematik |
Die gematik kann über die Schnittstelle (5) lesend auf die Einträge im FHIR-Directory und im LDAP-Directory zugreifen um die Daten-Qualität der Einträge zu prüfen und um Fehler zu analysieren. |
LDAP-Directory |
Die Schnittstelle (6) zwischen FHIR-Directory und LDAP-Directory wird vom Verzeichnisdienst genutzt, um die Einträge zu synchronisieren. |
Alle Schnittstellen mit Ausnahme (6) sind über das Internet erreichbar. Die Schnittstellen stellen folgende Funktionen bereit:
-
Für Nutzer des TI-Messengers gibt es eine Schnittstelle zur Suche nach Einträgen im Organisationsverzeichnis und für LE zusätzlich zur Suche im Personenverzeichnis. Die Schnittstelle kann nur nach erfolgreicher Authentisierung genutzt werden. Alle TI-Messenger Nutzer können sich authentisieren und bekommen vom FHIR-Directory ein Accesstoken ausgestellt, dass für die Suchanfragen verwendet wird. Die Suche ermöglicht es komfortabel nach Volltext oder nach bestimmten Werten der einzelnen Attribute über die verlinkten Ressourcen zu suchen. Gefundene Ressourcen werden in einem Bundle von FHIR Ressourcen zurückgeliefert. Das FHIR-Directory ergänzt zu gefundenen TI-Messenger Adressen automatisch ein PASSporT. Es wird Paging unterstützt. Das Datenformat ist json.
-
Für Administratoren der Organisationen des Gesundheitswesens gibt es eine Schnittstelle zur Änderung Ihres Eintrags im Organisationsverzeichnis. Zur Nutzung der Schnittstelle ist eine Authentifizierung mit OIDC Authorization Code Flow erforderlich. Über diese Schnittstelle kann der eigene Eintrag der Organisation über eine Verlinkung um zusätzliche Einträge erweitert werden. TI-Messenger Nutzer die auch LE sind, können diese Schnittstelle nutzen, um ihre TI-Messenger-Adresse in ihrem Eintrag im Personenverzeichnis zu speichern, sodass sie von anderen LE gefunden werden können. Auch hier erfolgt die Authnetifizierung über OIDC. Das FHIR-Datenformat ist json.
-
Für Kartenherausgeber gibt es eine Schnittstelle um Einträge im LDAP-Directory anzulegen und zu pflegen. Das Datenformat ist json und ist in einer OpenAPI yaml Datei festgelegt. Zukünftig ist vorgesehen, dass die Kartenherausgeber auch direkt die Schnittstelle zum FHIR-Directory nutzen können. Dann ist das Datenformat FHIR in der Ausprägung json. Die Authentifizierung der Kartenherausgber erfolgt mit OAuth Client Credential Flow.
-
TI-Messenger-Anbieter pflegen im FHIR-Directory für die von ihnen angebotenen Messenger-Services die TI-Messenger Domänen und verlinken sie zu den Einträgen der Organisationen, für die die Messenger-Services angeboten werden. Das Datenformat ist FHIR in der Ausprägung json. Zusätzlich können die TI-Messenger Anbieter die Föderationsliste abfragen. Sie beinhaltet alle an der Föderation des TI-Messengers beteiligten Domains. Die Authentifizierung der TI-Messenger-Anbieter erfolgt mit OAuth Client Credential Flow.
-
Die gematik hat Schnittstellen um die Daten-Qualität der Einträge zu prüfen. Dazu wird die Schnittstelle der Kartenherausgeber genutzt. Die gematik hat aber nur Leserechte.
-
Die Einträge im LDAP-Directory werden in das FHIR-Directory Organisations- und Personenverzeichnis synchronisiert. Es handelt sich um eine interne Schnittstelle des Verzeichnisdienstes der TI. Für Einträge, die von den Kartenherausgebern schon direkt im FHIR-Directory gepflegt werden erfolgt die Synchronisation umgekehrt in das LDAP-Directory. Die Einträge erhalten dazu im FHIR-Directory eine spezielle Kennung, die angibt, ob die Pflege schon direkt im FHIR-Directory erfolgt ist.
Im FHIR-Directory werden FHIR-Ressourcen nach der HL7 FHIR Spezifikation gespeichert.
Die Einträge im Organisationsverzeichnis beginnen immer mit einer HealthcareService Ressource (Bezeichner des Service und Verfügbarkeitszeiten) mit Links zu einer Organization Ressource (Name der Organisation) sowie einer Location Ressource (postalische Adresse und Geodaten sowie Öffnungszeiten). Die Endpoint Ressource ist optional und enthält fachliche Daten der Anwendungen wie z. B. Adressdaten des TI-Messengers.
Das Objektdiagramm zeigt mögliche Verlinkungen der Ressourcen. Ein HealthcareService ist immer mit einer Organisation verlinkt.
| Attribut | Fachlicher Wert | Kardinalität | Bemerkung | Sync mit LDAP-Directory | Kann vom Besitzer geändert werden |
|---|---|---|---|---|---|
identifier |
n/a |
0..* |
Aktuell kein Identifier vorgesehen |
nein |
nein |
providedBy |
Reference der Organization Ressource |
1..1 |
Es gibt immer einen HealthcareService, der von den Kartenherausgebern erzeugt wird. Der Besitzer des Eintrags kann weitere Healthcareservices erzeugen, die immer eine Referenz auf die eigene Organization Ressource haben müssen. |
ja |
ja (für selbst angelegte healtcareServices) |
speciality |
Fachrichtung |
0..* |
ja |
ja (für selbst angelegte healtcareServices) |
|
location |
Reference der Location Ressource |
0..* |
ja |
ja (für selbst angelegte healtcareServices) |
|
name |
Name des HealthcareService |
0..* |
nein |
ja (für selbst angelegte healtcareServices) |
|
telecom |
Kontaktdaten des HealthcareService |
0..* |
nein |
ja (für selbst angelegte healtcareServices) |
|
serviceProvisionCode |
Service-Konditionen |
0..* |
Bedingungen unter denen der Service angeboten wird oder genutzt werden kann (z. B. kostenpflichtig) |
nein |
ja (für selbst angelegte healtcareServices) |
communication |
Sprache |
0..* |
Sprache, in der der Service angeboten wird |
nein |
ja (für selbst angelegte healtcareServices) |
appointmentRequired |
Termin erforderlich? |
0..1 |
Ob ein Termin erforderlich ist |
nein |
ja (für selbst angelegte healtcareServices) |
availableTime |
Verfügbarkeit des Service |
0..* |
Wann der Service verfügbar ist |
nein |
ja (für selbst angelegte healtcareServices) |
availabilityExceptions |
Ausnahmen der Verfügbarkeit |
0..* |
Beschreibung der Verfügbarkeitsausnahmen |
nein |
ja (für selbst angelegte healtcareServices) |
endpoint |
Referenz zur Endpoint Ressource |
0..* |
nein |
ja |
| Attribut | Fachlicher Wert | Kardinalität | Bemerkung | Sync mit LDAP-Directory | Kann vom Besitzer geändert werden |
|---|---|---|---|---|---|
identifier |
telematikID |
1..* |
Aktuell gibt es nur eine telematikID je Eintrag |
ja |
nein |
identifier |
Betriebsstättennummer |
0..* |
Wird von Arztpraxen verwendet |
ja |
nein |
identifier |
Abrechnungsnummer |
0..* |
Wird von Zahnarztpraxen verwendet |
ja |
nein |
identifier |
IK-Nummer |
0..* |
Wird von Krankenkassen und Krankenhäusern verwendet |
ja |
nein |
type |
Institutions-Typ |
0..1 |
Gemäß professionOID (Pflicht, wenn Organisation kein Provider ist) |
ja |
nein |
type |
Provider-Typ |
0..1 |
Gemäß TIProviderType Pflicht, wenn Organisation ein Provider ist |
nein |
nein |
name |
Name der Organisation |
1..1 |
Kann nur vom Kartenherausgeber geändert werden |
ja |
nein |
alias |
Alias Name der Organisation |
0..* |
Hat den Wert des LDAP-Attributs organization, wenn vorhanden. |
ja |
nein |
telecom |
Kontaktdaten der Organisation |
0..* |
nein |
nein |
|
contact |
Kontakt-Personen der Organisation |
0..* |
nein |
nein |
|
active |
Status des Eintrags |
1..1 |
Gibt die Sichtbarkeit des Eintrags für Nutzer an. |
ja |
nein |
| Attribut | Fachlicher Wert | Kardinalität | Bemerkung | Sync mit LDAP-Directory | Kann vom Besitzer geändert werden |
|---|---|---|---|---|---|
identifier |
n/a |
0..* |
Aktuell kein Identifier vorgesehen |
nein |
nein |
status |
active, suspended, inactive |
0..1 |
nein |
nein |
|
name |
Name der Location |
0..* |
nein |
nein |
|
description |
Beschreibung der Location |
0..* |
nein |
nein |
|
telecom |
Kontaktdaten der Location |
0..* |
nein |
nein |
|
address |
Postalische Adresse der Location |
0..* |
Wenn vom Kartenherausgeber angelegt, dann kann die Adresse nur durch den Kartenherausgeber geändert werden. Wenn durch die Organisation angelegt, dann kann die Adresse nur durch die Organisation geändert werden. |
ja |
nein |
position |
Geographische Position der Location |
0..* |
Wenn vom Kartenherausgeber angelegt, dann kann die Position nur durch den Kartenherausgeber geändert werden. |
nein |
nein |
hoursOfOperation |
Öffnungszeiten |
0..* |
nein |
nein |
|
availabilityExceptions |
Ausnahmen der Öffnungszeiten |
0..* |
nein |
nein |
| Attribut | Fachlicher Wert | Kardinalität | Bemerkung | Sync mit LDAP-Directory | Kann vom Besitzer geändert werden |
|---|---|---|---|---|---|
identifier |
n/a |
0..* |
Aktuell kein Identifier vorgesehen |
nein |
ja |
status |
Status |
1..1 |
nein |
ja |
|
connectionType |
Verbindungstyp |
1..1 |
Gültige Werte werden in einem ValueSet vorgegeben. |
nein |
ja |
name |
Name der Endpoint Ressource |
1..1 |
nein |
ja |
|
managingOrganization |
Referenz der Organisation, zu der der Endpoint gehört. |
0..1 |
Wird nicht genutzt |
nein |
nein |
payloadType |
Prozessbezeichner |
1..* |
Bezeichnet den vom Endpoint unterstützten Prozess. |
nein |
ja |
address |
Adresse des Endpoints |
1..1 |
Adresse des Endpoints in URL Notation |
nein |
ja |
Die Einträge im Personenverzeichnis beginnen immer mit einer PractitionerRole Ressource (Rolle des LE) mit Links zu einer Practitioner Ressource (Name des LE) sowie optional einer Location Ressource (postalische Adresse und Geodaten sowie Öffnungszeiten). Die Endpoint Ressource ist optional und enthält fachliche Daten der Anwendungen wie z. B. Adressdaten des TI-Messengers.
Das Objektdiagramm zeigt mögliche Verlinkungen der Ressourcen. Eine PractitionerRole ist immer mit einem Practitioner verlinkt.
| Attribut | Fachlicher Wert | Kardinalität | Bemerkung | Sync mit LDAP-Directory | Kann vom Besitzer geändert werden |
|---|---|---|---|---|---|
identifier |
Kein Identifier vorgeschrieben |
0..* |
nein |
nein |
|
practitioner |
Reference zur Practitioner Ressource |
1..1 |
Wenn vom Kartenherausgeber angelegt, dann wird die Reference auch vom Kartenherausgeber gesetzt. |
ja |
nein |
speciality |
0..* |
ja |
nein |
||
location |
Reference zur Location Ressource |
0..* |
Wenn vom Kartenherausgeber angelegt, dann wird die Reference auch vom Kartenherausgeber gesetzt. |
ja |
ja |
endpoint |
Reference zur Endpoint Ressource |
0..* |
nein |
ja (indirekt, über Anlegen eines Endpoints) |
| Attribut | Fachlicher Wert | Kardinalität | Bemerkung | Sync mit LDAP-Directory | Kann vom Besitzer geändert werden |
|---|---|---|---|---|---|
identifier |
telematikID |
1..* |
Aktuell gibt es nur eine telematikID je Eintrag |
ja |
nein |
active |
Status des Eintrags |
1..1 |
ja |
nein |
|
name |
Name des Practitioners |
1..* |
ja |
nein |
|
telecom |
Kontaktdaten des Practitioners |
0..* |
nein |
nein |
|
gender |
Geschlecht |
0..1 |
nein |
nein |
|
birthDate |
Geburtsdatum |
0..1 |
nein |
nein |
|
photo |
Foto |
0..* |
nein |
nein |
|
qualification |
0..* |
ja |
nein |
||
communication |
Unterstützte Sprachen |
0..* |
nein |
nein |
Die Ressourcen [Location] und [Endpoint] werden wie im Organisationsverzeichnis verwendet.
Die FHIR Ressourcen sind im Simplifier Projekt VZD-FHIR-Directory beschrieben.