Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

TI-Messenger ePA

    

     

      
Version
      
1.1.0_CC
     
     

      
Revision
      
1003361
     
     

      
Stand
      
30.09.2024
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemSpec_TI-M_ePA
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Zulassung der Produkttypen TI-M_Client_ePA und TI-M_FD_ePA. Dieses Dokument erweitert die Basisspezifikation [gemSpec_TI-M_Basis] um die für die genannten Produkttypen notwendigen Anpassungen. Für die Produkte gelten weiterhin die in der Basisspezifikation beschriebenen Funktionalitäten, sofern Sie nicht in diesem Dokument erweitert oder eingeschränkt werden.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller von Frontends für Versicherte (FdV) mit integriertem TI-M Client ePA, an Hersteller von TI-M FD ePA und an Anbieter, welche die beschriebenen Produkttypen betreiben.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekanntgegeben.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang ).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten. Diese sind in den Produkttypsteckbriefen der Produkttypen TI-M_Client_ePA und TI-M_FD_ePA verzeichnet.

1.5 Methodik

Anwendungsfälle und Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID, Anforderungen zusätzlich durch die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anwendungsfälle und Anforderungen werden im Dokument wie folgt dargestellt:
<AF-ID> - <Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

bzw.

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst der Anwendungsfall bzw. die Anforderung sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

2 Systemüberblick

Für die Einbindung der Versicherten werden basierend auf der Basisspezifikation [gemSpec_TI-M_Basis] Anpassungen vorgenommen, die auf Clientseite im Produkt TI-M Client ePA und auf Serverseite im Produkt TI-M FD ePA aufgehen.

2.1 Akteure und Rollen

Mit dieser Spezifikation werden die Versicherten als Akteure in die TI-Messenger Föderation eingebunden. Versicherte können zukünftig über einen TI-Messenger Client im Frontend des Versicherten der ePA (TI-M Client ePA) sicher und schnell Inhalte austauschen.

Der Messenger-Service wird für den Versicherten immer von der jeweiligen Krankenkasse bereitgestellt.

2.1.1 Rolle: "Versicherter"

Der TI-M ePA führt die Rolle "Versicherter" ein. Versicherten stehen die gleichen Funktionalitäten zur Verfügung wie einem Akteur in der Rolle "User" der Spezifikation [gemSpec_TI-M_Basis]. Diese Funktionalitäten können durch die Inhalte dieser Spezifikation erweitert oder eingeschränkt werden.

2.2 Nachbarsysteme

Die folgende Grafik zeigt die Schnittstellen zu Nachbarsysteme für den TI-M Client ePA und den TI-M FD ePA.

Abbildung 1: Kontextabgrenzung

Der TI-M Client ePA hat Schnittstellen

• zu anderen TI-M Clients zum Austausch von Kontaktinformationen (z.B. via QR-Code Scan),
• zum sektoralen IDP. Es werden die gleichen Verfahren wie beim ePA FdV (mit Single Sign On, wenn vorhanden (siehe [gemSpec_IDP_Frontend]) verwendet,
• zum VZD-FHIR-Directory zur Suche nach Kontakten in Organisationen oder im Verzeichnis der Practitioner,
• zum externen Push Provider um Benachrichtigungen zu erhalten und
• zum TI-M FD ePA für Versicherte.

Der TI-M FD ePA hat Schnittstellen

• zum TI-M Client ePA für Versicherte,
• zum Org-Admin Client des Kostenträgers (KTR) zur Verwaltung der Akteure,
• zum sektoralen IDP. Es werden die gleichen Verfahren wie beim ePA FdV mit Single-Sign-On verwendet, wenn vorhanden (siehe [gemSpec_IDP_Sek]),
• zum FHIR-Verzeichnisdienst zur Pflege und zum Bezug der Föderationsliste,
• zur Komponenten PKI für die Erzeugung und Prüfung von Zertifikaten aus dem Vertrauensraum der TI,
• zu anderen TI-M FD, um innerhalb der TI-Messenger Föderation die Kommunikation mit Nutzern anderer TI-M FD zu ermöglichen und
• zum Push Gateway, um Benachrichtigungen für Nutzer zu versenden.

2.2.1 Authentifizierungs-Dienst für Akteure in der Rolle "Versicherter"

Für die Verwaltung der Identitäten der Akteure in der Rolle "Versicherter" stellen die Krankenkassen einen sektoralen IDP bereit. Die Spezifikation für den sektoralen IDP ist unter [gemSpec_IDP_Sek] zu finden. Für den TI-M ePA bindend sind Anforderungen aus dem Dokument [gemSpec_IDP_Frontend] für den Client und Anforderungen aus [gemSpec_IDP_FD] für den Fachdienst, die den jeweiligen Produkttypsteckbriefen zu entnehmen sind und deren Inhalte zusätzlich in den Kapiteln zum Client (3.1.2 Auth Modul) und zum Fachdienst (3.2.2.1 Schnittstelle für Authentifizierungsverfahren) aufgeführt werden.

2.2.2 VZD-FHIR-Directory

Beim VZD-FHIR-Directory gibt es gegenüber der Basisspezifikation nur minimale Anpassungen.

• Nach der Authentisierung wird für die Akteure ein individueller searchaccess-token bereitgestellt.
• Für die Suche der Akteure in der Rolle "Versicherter" wurde ein eigener Endpunkt bereitgestellt (3.1.1 VZD-FHIR-Directory).
  

3 Zerlegung des Produkttyps (Systemkomponenten)

In den folgenden Kapiteln werden die Komponenten des Clients und der Services in einer Bausteinansicht visualisiert.

3.1 TI-M Client ePA

Die folgende Grafik zeigt die Komponenten eines TI-M Clients ePA. Farblich hervorgehoben sind diejenigen Komponenten gegenüber der Basisspezifikation [gemSpec_TI-M_Basis], die im Rahmen der in dieser Spezifikation vorgestellten Features angepasst werden müssen (blau) und Komponenten, die neu hinzugekommen sind (grün).

Abbildung 2: TI-M Client ePA Komponentendiagramm

Neu hinzugekommen ist für die Nutzerauthentifizierung der sektorale IDP auf den in Kapitel 2.2.1 Authentifizierungs-Dienst für Akteure in der Rolle "Versicherter" eingegangen wird. Am VZD-FHIR-Directory ändert sich lediglich der Endpunkt für die Suche, da für Akteure in der Rolle "Versicherter" ein neuer Endpunkt bereitgestellt wird.

3.1.1 VZD-FHIR-Directory

3.1.2 Auth Modul

Für die Interaktion mit dem sektoralen IDP wird auf Clientseite ein Authenticator-Modul bereitgestellt, dessen Anforderungen in [gemSpec_IDP_Sek] definiert sind. Für den TI-M Client ePA sind die Anforderungen an Clients aus der Spezifikation Identity Provider - Frontend ([gemSpec_IDP_Frontend] zu beachten und werden im Produktypsteckbrief aufgeführt.

3.1.3 Weitere Ergänzungen/Einschränkungen zur Matrix-Spezifikation

3.2 TI-M FD ePA

Die folgende Grafik visualisiert die Komponenten eines TI-M FD ePA auf Serverseite , die im Rahmen der in diesem Dokument beschriebenen Features hinzukommen oder angepasst werden müssen. Farblich hervorgehoben sind diejenigen Komponenten gegenüber der Basisspezifikation [gemSpec_TI-M_Basis], die im Rahmen der in dieser Spezifikation vorgestellten Features angepasst werden müssen (blau) und Komponenten, die neu hinzugekommen sind (grün).

Abbildung 3: TI-Messenger-Service Komponentendiagramm

3.2.1 Registrierungs-Dienst

Der Registrierungs-Dienst wird angepasst, da nur Kostenträger in die Lage versetzt werden sollen, Messenger-Services für Akteure in der Rolle "Versicherter" zu bestellen (siehe 5.1 Einschränkung zu Anwendungsfall AF_10060 - Bereitstellung eines Messenger-Service für eine Organisation).

3.2.2 Messenger-Service

3.2.2.1 Schnittstelle für Authentifizierungsverfahren

Der Messenger-Service muss für die Authentifizierung der Akteure in der Rolle "Versicherter" an den sektoralen IDP angeschlossen werden.  Anschließend können Inhalte des vom sektoralen IDP ausgestellten ID_TOKEN bei der Account Anlage verwendet werden (siehe A_25706 - AF_10234 - Erzeugung der MXID (Bei Registrierung) & A_25707 - AF_10234 - Erzeugung des Display Name). Für den TI-M FD ePA sind damit die Fachdienstanforderungen aus der Spezifikation Identity Provider – Nutzungsspezifikation für Fachdienste ([gemSpec_IDP_FD] entsprechend bindend und im Produktypsteckbrief aufgeführt.

Hinweis: Die vom sektoralen IDP grundsätzlich unterstützten Authentifizierungsverfahren sind in [gemSpec_IDP_Sek#Authentifizierungsverfahren] beschrieben.

3.2.2.2 Messenger-Proxy

Das Berechtigungsmanagement des Messenger-Proxy wird erweitert, um die direkte Versicherten-zu-Versicherte Kommunikation zu unterbinden (siehe 5.3 Berechtigungsmanagement - Anpassungen). Zusätzlich kann der Proxy noch angepasst werden, um Pushed Authorization Requests gegenüber dem Sektoralen IDP zu realisieren (siehe 5.2 Feature Identifikation und Login eines Benutzers ).

3.2.2.3 Ergänzungen zur Matrix-Spezifikation

4 Übergreifende Festlegungen

4.1 Betrieb

Im Betrieb verantwortet ein Anbieter des TI-Messengers das Produkt:

• TI-M Fachdienst ePA

Abbildung 4 Betriebsmodell TI-M ePA

Hinweis zur Abbildung:
Die Abbildung bildet die organisatorischen Kommunikationsbeziehungen aus Sicht des TI-ITSM-Systems zwischen den jeweiligen Entitäten/Anbieterrollen ab. Die Produktverantwortung für das Produkt TI-M Client ePA, welches im ePA FdV integriert ist, liegt beim Hersteller des Versicherten Frontends (siehe auch [gemKPT_Betr]).

Tabelle 1: Berichtsformat_TI-Messenger-Fachdienst ePA

Hinweis:

Für die gelb-markierten Anwendungsfälle sollen entsprechend A_24464-* nur die Fehlerfälle in den Rohdaten übertragen werden (siehe A_24464).

5 Funktionsmerkmale

5.1 Einschränkung zu Anwendungsfall AF_10060 - Bereitstellung eines Messenger-Service für eine Organisation

Der nachfolgende Anwendungsfall beschreibt die Ergänzungen zur Einschränkung an "AF_10060 - Bereitstellung eines Messenger-Service für eine Organisation".

Tabelle 2: Einschränkung zu Anwendungsfall AF_10060

5.2 Feature Identifikation und Login eines Benutzers

Versicherte erhalten von ihrer Krankenkasse eine App, die es ihnen ermöglicht, den TI-Messenger innerhalb des ePA FdV zu nutzen. Die Krankenkasse stellt den Versicherten Identifizierungsmöglichkeiten gemäß [gemSpec_IDP_Sek#Identifizierung und Authentifizierung des Nutzers] und einen IDP bereit, der es ermöglicht, die Versicherten der Krankenkasse zu authentifizieren und Identitätsinformationen der Versicherten in den Diensten der TI (wie hier am TI-Messenger Service) zu nutzen.

5.2.1 Anwendungsfall

AF_10234 - Identifikation und Login eines Benutzers

Damit Versicherte die Messenger-Funktion der ePA-App ihrer Krankenkasse nutzen können, müssen sich diese am IDP ihrer Krankenkasse identifizieren und erhalten damit Zugang zu deren TI-Messenger Service. Die Authentifizierung von Versicherten für die Registrierung von TI-Messenger Accounts und für das Login am Homeserver erfolgt am sektoralen IDP mittels OIDC.

Tabelle 3: AF - Identifikation und Login eines Benutzers

Attribute	Bemerkung
Akteur	Versicherter, welcher gleichzeitig auch das ePA-FdV benutzt.
Auslöser	Der Akteur benutzt die Login- oder Registrierungs-Funktion seines TI-M Clients
Komponenten	TI-M Client im ePA-FdV Messenger-Proxy Matrix-Homeserver (als Relying Party des sektoralen IDP) Sektoraler IDP
Eingangsdaten	Login-Call am aufgerufenen Client des Akteurs
Ergebnis	Der Akteur erhält einen nutzbaren Zugang zum TI-Messenger Service seiner Krankenkasse (bei Nutzung der Registrierungsfunktion). Akteur ist mit seinem Client am Matrix Homeserver eingeloggt und kann anschließend über diesen kommunizieren.
Ausgangsdaten	Neuer Nutzeraccount auf dem Homeserver (bei Nutzung der Registrierungsfunktion) aktive User-Session im TI-M Client unter Benutzung eines gültigen access token
Diagrammvariablen	{homeserver_client_api_url}: Hostname des Matrix-Homeserver, z.B. https://myprovider.homeserver-tim.de, zzgl. Basispfad zum gültigen Client-API /_matrix/client/v3 {sidp}: ID des sektoralen IDPs, die vom Homeserver beauskunftet wird {sektoraler_idp_url}: Der am Homeserver konfigurierte FQDN des sektoralen IDP als OIDC IDP {redirect_uri}: Die vollständige Callback-Adresse für den OIDC Flow {client_url}: URL der TI-M Clients

Die Laufzeitsicht zeigt sowohl die Registrierung eines Benutzer-Accounts als auch den Login eines Akteurs am Homeserver des TI-Messengers Service. Die in der Box "Verhaltensänderung, ..." dargestellte Änderung betrifft notwendige Anpassungen am Messenger-Proxy, um damit Redirects vom Homeserver aufzufangen, auszuwerten und anhand der Auswertung über einen entsprechende Endpoint am sektoralen IDP einen PAR (ein Pushed Authorization Request) nach dessen Vorgaben zu erstellen.

Abbildung 5 : Laufzeitsicht - Identifikation und Login eines Benutzers 

[<=]

5.3 Berechtigungsmanagement - Anpassungen

5.3.1 Unterbindung der Versicherteneinladung

Der TI-M FD ePA soll verhindern, dass ein Versicherter einen anderen Versicherten einladen kann. Die folgende Grafik zeigt, welche Komponenten der Fachdienste, die zusätzliche Prüflogik übernehmen müssen. Die Versichertenprüfung soll an der Matrix-Client-Server-API durchgeführt werden sowie zur weiteren Absicherung ebenfalls an der Matrix-Server-Server-API zwischen den TI-M FD.

Abbildung 6: Prüfung auf Versichertenbeteiligung

Die Anpassungen an der Prüflogik des Messenger-Proxy werden in den folgenden Kapiteln näher erläutert.

Hinweis: Sofern ein Akteur, der nicht Versicherter ist, die Einladung(en) ausspricht, können auch mehrere Versicherte Teilnehmer eines Raumes sein und Nachrichten austauschen.

5.3.1.1 Client-Server Prüfungen

In der Funktion als Client-Server Proxy prüft der Messenger-Proxy, wie in der TI-M Basis beschrieben, eingehende Invite- Events der TI-M Clients (in der Abbildung 6 rot dargestellt) und fungiert so als Reverse-Proxy. Für den TI-M ePA muss der Messenger-Proxy zusätzlich zur in der TI-M Basis geforderten Föderationszugehörigkeit die Versicherteneinladung nach AF_10233 - AF_10233 Versicherteneinladung unterbinden verhindern.

5.3.1.2 Server-Server Prüfungen

In der Funktion als Server-Server Proxy prüft der Messenger-Proxy, wie in der TI-M Basis beschrieben, alle ausgehenden sowie eingehenden Events auf Föderationszugehörigkeit. Für den TI-M ePA muss die Prüfung zusätzlich die Versicherteneinladung nach AF_10233 - AF_10233 Versicherteneinladung unterbinden verhindern.

AF_10233 - AF_10233 Versicherteneinladung unterbinden

Dieser Anwendungsfall erweitert die in der TI-M Basis definierte Prüflogik für den Messenger-Proxy, neben der Föderationsprüfung ist zusätzlich zu prüfen, dass der Einladende und der Eingeladene nicht der Gruppe Versicherte zuzuordnen sind. Für die Prüfung der Zugehörigkeit verwendet der Messenger-Proxy die Information isInsurance aus der Föderationsliste.

Tabelle 4: AF - Versicherteneinladung unterbinden

Attribute	Bemerkung
Auslöser	Anfrage am Messenger Proxy
Komponenten	Messenger-Proxy
Vorbedingung	Szenario 1: Beide Kommunikationspartner haben einen Benutzeraccount mit einer Domain, welche in der Föderationsliste als "isInsurance" gekennzeichnet wurde (Kennzeichen für eine Versichertendomain). Szenario 2: Mind. einer der Kommunikationspartner hat einen Benutzeraccount mit einer Domain, welche in der Föderationsliste NICHT als "isInsurance" gekennzeichnet wurde.
Eingangsdaten	Matrix Invite Event
Ergebnis	Szenario 1: Ablehnung der Einladung, wenn der Sender und der Empfänger beides Akteure in der Rolle Versicherter sind. Szenario 2: Weiterleitung der Einladung, wenn der Sender oder der Empfänger kein Akteur in der Rolle Versicherter ist.

Abbildung 7: Versicherteneinladung unterbinden 

[<=]

5.3.1.3 Berechtigungsprüfung

Die folgende Grafik zeigt in der Zusammenfassung die für den TI-M ePA anzuwendenden Prüfregeln, am Beispiel der Verarbeitung eines Invite Events auf Seiten des Messenger-Service des eingeladenen Akteurs.

Abbildung 8: Berechtigungsprüfung TI-M_ePA

5.3.2 Weitere Anpassungen

5.4 Push-Benachrichtigung im FdV

Eine besondere Herausforderung beim Frontend des Versicherten (FdV) besteht darin, dass eine App (das FdV) die Client-Logik zur Kommunikation mit drei unterschiedlichen Fachdiensten (ePA, E-Rezept, TI-M) sicherstellen muss. Um die Flexibilität hinsichtlich multipler Fachdienste und unterschiedlicher Clients sicherzustellen, muss das Push-Gateway für andere Fachdienste entsprechend separate Endpunkte zur Verfügung zu stellen, deren Ausgestaltung über die kommenden Spezifikationsreleases zum ePA-FdV oder dem E-Rezept im ePA-FdV erfolgen wird.

Die nachfolgende Grafik illustriert exemplarisch das zukünftige Szenario. Hier existiert bereits ein E-Rezept-Fachdienst, der über ein Push-Gateway die Push-Dienste von Google und Apple angebunden hat, um die E-Rezept-App sowohl unter Android als auch unter iOS mit Push-Benachrichtigungen zu versorgen. In diesem Szenario möchte eine Beispiel-Krankenkasse dem Versicherten eine App ("FdV App") zur Verfügung stellen, die Push-Benachrichtigungen der integrierten Fachdienste ePA, E-Rezept und TI-Messenger verarbeiten kann. Hierzu ist es notwendig, den bereits existierenden E-Rezept-Fachdienst anzubinden sowie auf Seiten des Versicherten (in der "FdV App") die Benachrichtigungen technisch von einander zu trennen.

Abbildung 9: Push-Gateway

Wie die Abbildung zeigt, stellt die Beispiel-Krankenkasse ein Push-Gateway für ihre FdV-App zur Verfügung und registriert die App beim Push-Anbieter. Durch die Registrierung erhält die App vom Anbieter ein Token, über welches die Anwendung beim Senden von Push-Benachrichtigungen eindeutig identifiziert werden kann. Dieses Token und die Information, welches Gateway zu verwenden ist, stellt die App den von ihr genutzten Fachdiensten zur Verfügung. Dazu ist es notwendig, dass die in der Grafik gelb markierten Schnittstellen öffentlich verfügbar und für beliebige Clients nutzbar sein müssen. Die Schnittstellen erlauben einem Client dem Fachdienst das zu nutzende Push-Gateway und den zu verwendenden Provider zu definieren.

Zusätzlich muss der Client über die Schnittstelle den Token bereitstellen können, über den die App vom Push-Provider eindeutig zu identifizieren ist (Bsp.: [Client-Server API/#post_matrixclientv3pushersset]). Ebenfalls müssen die Schnittstellen der Fachdienste zu den Gateways öffentlich einsehbar sein, damit die gematiker Krankenkasse an ihrem Push-Gateway eine Schnittstelle bereitstellen kann, die vom E-Rezept-Fachdienst auch verstanden wird (Bsp.: [Push Gateway API/#post_matrixpushv1notify]). Die beiden deckungsgleichen Schnittstellen sind rot markiert. Die grün markierten Schnittstellen am Push Gateway der gematiker Krankenkasse werden im Beispielszenario nicht von anderen Apps genutzt, müssen jedoch auch öffentlich verfügbar sein, damit andere App-Entwickler für ihre Anwendungen ein Push-Gateway mit identischen Schnittstellen bereitstellen können.

Das vorgestellte Szenario hat den Vorteil, dass die Push-Anbieter spezifischen Credentials beim Push-Gateway des App-Anbieters verbleiben können und dass es dem App-Anbieter überlassen ist zu entscheiden, wie er die Trennung der Inhalte übernimmt. Z.B. kann die gematiker Krankenkasse selbst in der Logik ihres Gateways entscheiden, ob sie in den Inhalt der Benachrichtigung einen Indikator aufnimmt, welcher Fachdienst die Benachrichtigung gesendet hat oder z.B. bei Nutzung von FCM diese Unterscheidung über eigene Topics für die verschiedenen Fachdienste realisiert.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

Tabelle 5: Im Dokument verwendete Abkürzungen

6.2 Glossar

Tabelle 6: Im Dokument verwendete Begriffe

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

Tabelle 7: Referenzierte Dokumente der gematik

6.5.2 Weitere Dokumente

Tabelle 8: Weitere Dokumente