Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Federation Master

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
982728
     
     

      
Stand
      
05.04.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_IDP_FedMaster
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Federation Master. Der Federation Master basiert auf den Standards OpenID Connect (OIDC), Open Authorization 2.0 (OAuth 2) und JSON Web Token (JWT). Der Federation Master ist einerseits der Anker des Vertrauensbereichs der Föderation. Andererseits stellt der Federation Master Schnittstellen bereit, welche Auskunft über die in der Föderation registrierten sektoralen Identity Provider gibt. Die Kernaufgaben des Federation Master sind:

• Verwaltung der öffentlichen Schlüssel aller in der Föderation registrierten Teilnehmer (OpenID Provider (OP) und Relying Party (RP) gemäß Spezifikation [openid-connect-core])
• Validierung von Anfragen über Teilnehmer der Föderation
• Bereitstellung von Schnittstellen für:
• • die Auskunft zum Federation Master (Entity Statement)
  • die Auskunft über Teilnehmer der Föderation
  • die Auskunft über die Liste aller registrierten OpenID Provider (OP)
  • die Registrierung neuer OP und RP
  • das Löschen von nicht mehr benötigten OP und RP.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter, welche die Funktionen des Produkttyps Federation Master der gematik realisieren wollen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur (TI) 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 bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Nicht Bestandteil des vorliegenden Dokumentes sind die Verfahrensschritte zur Erstellung des notwendigen Schlüsselmaterials. Für die Signatur des Entity Statement wird angenommen, dass die OpenID Provider (OP) und Relying Parties (RP) der Föderation ihre innerhalb der TI zu verwendenden Zertifikate für die Transport Layer Security (TLS)-Sicherung über zentrale Plattformdienste der TI beziehen und diese dort auch geprüft werden können.

Als Umsetzungsleitlinie ist [OpenID Connect Core 1.0] und [OpenID Connect Federation1.0] heranzuziehen. Die TI-weit übergreifenden Festlegungen – insbesondere aus Dokumenten wie beispielsweise [gemSpec_Krypt] bezüglich Algorithmen und Schlüsselstärken sowie [gemSpec_PKI] bezüglich zu verwendender Zertifikatstypen und deren Attributausprägungen – haben Bestand, sind ebenso bindend und werden nicht in diesem Dokument beschrieben.

Für weitere Komponenten der TI-Föderation gelten eigene Spezifikationsdokumente:

• sektorale Identity Provider - [gemSpec_IDP_Sek]
• Fachdienste - [gemSpec_IDP_FD]
• Anwendungsfrontend der Fachdienste - [gemSpec_IDP_Frontend].

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

1.5.2 Anwendungsfälle und Akzeptanzkriterien

Anwendungsfälle und Akzeptanzkriterien als Ausdruck normativer Festlegungen werden als Grundlage für Erlangung der Zulassung durch Tests geprüft und nachgewiesen. Sie besitzen eine eindeutige, permanente ID, welche als Referenz verwendet werden SOLL. Die Tests werden gegen eine von der gematik gestellte Referenz-Implementierung durchgeführt. 

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

Die einzelnen Elemente beschreiben:

• ID: einen eindeutigen Identifier.
• • Bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
  • Der Identifier eines Akzeptanzkriteriums wird von System vergeben, z.B. die Zeichenfolge 'ML_' gefolgt von einer Zahl
• Titel des Anwendungsfalles / Akzeptanzkriteriums: Ein Titel, welcher zusammenfassend den Inhalt beschreibt
• Text / Beschreibung: Ausführliche Beschreibung des Inhalts. Kann neben Text Tabellen, Abbildungen und Modelle enthalten

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

Der für die Erlangung einer Zulassung notwendige  Nachweis der Erfüllung des Anwendungsfalls wird in den jeweiligen  Steckbriefen festgelegt, in denen jeweils der Anwendungsfall gelistet ist. Akzeptanzkriterien werden in der Regel nicht im Steckbrief gelistet.

1.5.3 Hinweise

Hinweis auf offene Punkte

2 Systemüberblick

2.1 Allgemeiner Überblick

Zentrales Merkmal des zukünftigen Identity Management der Telematikinfrastruktur ist das Prinzip der Föderation. Die Identitäten werden nicht von einem einzigen zentralen Dienst bereitgestellt, sondern „kollektiv“ durch eine Menge von Identity Providern, für die jeweils die entsprechenden identitätsbestätigenden Institutionen verantwortlich sind, welche auch für die jeweiligen Nutzergruppen zuständig sind.

Um eine Gesamtlösung sicherzustellen, bei der Anwendungen in möglichst einfacher Weise die verschiedenen sektoralen Identity Provider nutzen können, sind in bestimmten Bereichen einheitliche Vorgaben für die technische und organisatorische Umsetzung zu erstellen:

• Einheitliche Identitätsattribute für die Nutzergruppen (Minimal claim Sets, scopes)
• Grundstruktur der Vertrauensbeziehungen der Föderierung (IDP Federation/Trust Chains)
• Einheitliche Verfahren zum Auffinden von sektoralen Identity Providern (IDP Discovery)
• Einheitliche Vertrauensniveaus (Trust Framework).

Die Grundidee der Föderation ist die Erstellung eines Vertrauensraums, in dem verschiedene Anwendungen und Identity Provider abgesichert über Vertrauensketten (Trust chain) miteinander kommunizieren, ohne zuvor über organisatorische Prozesse miteinander verknüpft zu werden. Diese Anwendungen und Identity Provider werden im Folgenden als Teilnehmer der Föderation bezeichnet. Die TI-Föderation baut auf dem Standard [OpenID Connect Federation 1.0] auf. Die Autorisierung und Authentisierung von Anwendungen und Nutzern orientiert sich an den Standards zu OAuth 2.0 und OpenID Connect. Die für die TI zwingend notwendige Identifikation der Nutzer ist nicht Teil der Spezifikation.

Abbildung 1: Überblick TI-Föderation

2.2 Detaillierter Überblick

Die untere Abbildung beschreibt den Systemkontext aus Sicht des Federation Master. Alle sektoralen Identity Provider der Föderation müssen beim Federation Master registriert sein. Ebenso müssen alle Fachanwendungen, welche die bei den Identity Providern hinterlegten digitalen Identitäten nutzen möchten, beim Federation Master registriert sein. Jede teilnehmende Partei inklusive des Federation Master muss ein OpenID Connect spezifikationskonformes Entity Statement bereitstellen.

Die Identity Provider der Föderation stellen sicher, dass Nutzer anfragender Fachdienste identifiziert sind. Ebenso wird sichergestellt, dass die Nutzer den Anwendungen Zugriff auf eine Teilmenge ihrer Daten gewähren (Consent).

Die in der Föderation registrierten Fachdienste nutzen die sektoralen Identity Provider, um Nutzer ihrer Anwendungen über die Verfahren der sektoralen Identity Provider eindeutig zu authentifizieren und die Zustimmung der Datennutzung von den Nutzern einzuholen.

Abbildung 2: Systemkontext

Im Prozess der Autorisierung eines Nutzers für eine Anwendung ist der Federation Master als Vertrauensstelle eingebunden. Die Voraussetzung für die Kommunikation zwischen Fachdiensten und sektoralen Identity Providern ist deren Registrierung im Vertrauensbereich der Föderation. Diese initiale Registrierung erfolgt organisatorisch und unabhängig vom späteren Ablauf. 

Voraussetzungen für die Prüfung der beteiligten Komponenten im Kontext eines Nutzungsflows:

• Die aktuellen Signaturschlüssel der beteiligten sektoralen Identity Provider und Fachdienste wurden über einen vom Anbieter bereitgestellten organisatorischen Prozess beim Federation Master hinterlegt.
• Die Entity Statements der beteiligten sektoralen Identity Provider und Fachdienste entsprechen den Vorgaben [OpenID Connect Federation1.0]
• Der Identifier des Federation Master wurde vom Anbieter des Federation Master veröffentlicht.

Das folgende Übersichtsschaubild gibt einen Überblick über das Zusammenspiel der unterschiedlichen Komponenten der Föderation. Grau hinterlegte Schritte sind nicht Bestandteil des Nutzungsflows.

Die Kommunikation des Anwenders über das Anwendungsfrontend mit dem Fachdienst entspricht der OAuth-2.0-Spezifikation ([RFC6749]) mit PKCE ([RFC7636]) und wird hier nicht detailliert beschrieben.

Die Kommunikation zwischen dem Fachdienst (Relying Party) und dem sektoralen Identity Provider (OpenID-Provider) entspricht den Spezifikationen zu OpenID Connect (Final: OpenID Connect Core 1.0) und Pushed Authorization Request (https://datatracker.ietf.org/doc/html/rfc9126) und wird hier nicht detailliert beschrieben.

Abbildung 3: Übersichtsschaubild OIDC Federation

Erläuterungen zur obigen Abbildung:

Die grün dargestellten Komponenten und Schnittstellen sind Gegenstand der vorliegenden Spezifikation. Komponenten und Schnittstellen, welche in der Abbildung grau hinterlegt sind, werden in der vorliegenden Spezifikation nicht weiter betrachtet. 

Hinter den gestrichelt dargestellten Schnittstellen verbergen sich organisatorische Prozesse und Verfahren; die anderen Schnittstellen sind Bestandteil der Abläufe zur Autorisierung und Authentifizierung eines Anwenders im Kontext einer Fachanwendung.

Die organisatorischen Prozesse dienen der Registrierung und Löschung von Teilnehmern der Föderation sowie der Aktualisierung der beim Federation Master hinterlegten TLS-Schlüssel der sektoralen Identity Provider.

Im Ablauf der Autorisierung und Authentifizierung eines Anwenders im Vertrauensraum der Föderation müssen der beteiligte Fachdienst und  der beteiligte sektorale Identity Provider sicherstellen, dass der jeweilige Kommunikationspartner ebenfalls ein Mitglied der Föderation ist. Diese Teilschritte sind in der Abbildung als Federation-Flow gekennzeichnet und grün hinterlegt.

Beide Komponenten laden sich dazu das Entity Statement des Federation Master zur jeweils anderen Komponente herunter unter:

GET /.well-known/openid-federation HTTP/1.1

Host: <host Teilnehmer>

Zur Verifizierung müssen die Komponenten prüfen, ob der jeweils andere Teilnehmer Teil der Föderation ist. Das Entity Statement des Federation Master (HTTP-GET <federation master>/.well-known/openid-federation HTTP/1.1) enthält die URL der API-Schnittstelle des Federation Master. Die Information zu einem Teilnehmer der Föderation kann dann über die API-Schnittstelle des Federation Master geladen werden. Dabei müssen sowohl der Entity Identifier (URL) des Federation Master als auch der des Teilnehmers als Parameter übergeben werden. Der Federation Master liefert ein von ihm signiertes Entity Statement zum angefragten Teilnehmer zurück.

Tabelle 1: Request zur Teilnehmerabfrage an den Federation Master

Jeder Teilnehmer stellt zusätzlich ein selbst signiertes Entity Statement bereit, dessen Schlüssel gegen das durch den Federation Master signierte Statement verifiziert werden.

2.3 Akteure und Rollen

Tabelle 2: Akteure und Rollen

2.4 Attributbeschreibung

Die folgende Tabelle enthält eine Erläuterung zu den Attributen, die in den Entity Statements des Federation Master verwendet werden. Die Attribute entsprechen dem OIDC Standard für Entity-Statements. 

Tabelle 3: Attributbeschreibung

Anforderungen an die konkrete Belegung der Attribute im Entity Statement des Federation Master sind in Kapitel 4.1  beschrieben .

3 Funktionsmerkale

3.1 Anwendungsfälle

Der Federation Master ist eine Komponente, welche in den Kommunikationsfluss bei der Nutzung von Fachdiensten der TI eingebunden ist. Zudem ist der Federation Master an notwendigen organisatorischen Prozesse beteiligt. Folgende Anwendungsfälle dienen der Beschreibung der Anforderungen an den Federation Master:

Tabelle 4: Übersicht über die Anwendungsfälle im Gesamtkontext Federation Master

Abbildung 4: Anwendungsfälle Federation Master

Tabelle 5: Anwendungsfälle Federation Master

Die technischen Anwendungsfälle des Federation Master werden hier im Detail beschrieben. Details zu den organisatorischen Anwendungsfällen des Federation Master finden sich in Kapitel 4.2 Organisatorische Prozesse am Federation Master . Die Ausprägung der Anwendungsfälle anderer Komponenten spielt im Rahmen dieser Spezifikation keine Rolle.

3.2 Anwendungsfall - IDP-Liste bereitstellen

Abbildung 5:  Aktivitätsdiagramm  "Auswahl sektorale Identity Provider"

3.2.1 Akzeptanzkriterien - IDP-Liste bereitstellen

3.3 Anwendungsfall - Entity Statement bereitstellen

Abbildung 6: Federation Master im Authorization-Flow

Tabelle 9: Federation Master im Authorization-Flow

.well-known/openid-federation

.well-known/openid-federation

Hinweis: Eine detaillierte Beschreibung der Verwendung des OAuth- und OIDC-Standards ist nicht Teil dieser Spezifikation. Die diesbezüglichen Schritte im Flow werden nicht weiter erläutert.

3.3.1 Akzeptanzkriterien - Entity Statement bereitstellen

Hinweis: Für den Fetch Entity Request gelten die Festlegung im Standard [OpenID Connect Federation1.0] Kapitel 7.1.1. 

Hinweis: Will eine Relying Party den Umfang der vom sektoralen IDP anforderbaren scopes oder claims erweitern oder redirect_uris ändern, so müssen diese Änderungen über den organisatorischen Registrierungsprozess laufen.

3.4 Anwendungsfall - Schlüssel verwalten

AF_10110 - Monitoring der TLS- Zertifikate der VAU

Abbildung 7: Prüfung der TLS-Zertifikate eines sektoralen Identity Provider am Federation Master

Tabelle 14: Anwendungsfall "Monitoring der TLS-Zertifikate der VAU"

Attribute	Bemerkung
Beschreibung	Certificate Transparency Monitor für die TLS-Zertifikate
Akteur	Federation Master
Auslöser	Ein TLS-Zertifikat für eine Domäne, welche in der VAU des jeweiligen sektoralen IDP-Dienstes mündet, wird erstellt.  Regelmäßige Prüfung der veröffentlichten TLS-Zertifikate
Komponente	Federation Master sektoraler Identity Provider
Vorbedingung	Der sektorale Identity Provider ist in der TI-Föderation registriert. Bei neu erstellten TLS-Zertifikaten wurde der Prozess Certificate Transparency TLS-Zertifikate der sektoralen Identity Provider prüfen  erfolgreich durchlaufen. Die öffentlichen Schlüssel des sektoralen Identity Provider und seine öffentliche TLS-Schlüssel sind beim Federation Master hinterlegt.
Ablauf	Der Federation Master MUSS einen Certificate Transparency Monitor für die TLS-Zertifikate der Domains der sektoralen Identity Provider betreiben, die in der VAU des jeweiligen sektoralen IDP-Dienstes münden. In diesem Certificate Transparency Monitor findet der Abgleich der Zertifikate gegen die bekannten Schlüssel der sektoralen Identity Provider statt (RFC9162). Dazu MUSS der Federation Master einmal täglich die TLS-Zertifikate der registrierten sektoralen Identity Provider prüfen. Zu diesem Zweck extrahiert er aus den im Entity Statement des sektoralen Identity Provider hinterlegten Adressen zum Token-, PAR- und  Authorization-Endpunkt die Domänennamen. Der Federation Master fragt mit allen ermittelten Domänennamen die Schnittstelle mindestens zweier unterschiedlicher öffentlich zugänglicher Provider für Certificate Transparency Records ab (z.B. https://sslmate.com/ct_search_api/). Die Provider liefern alle registrierten Zertifikate zum Domänennamen. Der Federation Master MUSS jedes Zertifikat dahingehend prüfen, ob der zugehörige öffentliche Schlüssel beim Federation Master bekannt und damit im HSM der VAU hinterlegt ist.
Ergebnis	Bei erfolgreicher Prüfung ist keine Maßnahme seitens Federation Master notwendig. Ist mindestens eine Prüfung negativ, MUSS der Federation Master weitere Schritte hinsichtlich des negativ geprüften sektoralen Identity Provider einleiten und einen "Security Incident" (gemäß 3.4 aus [gemRL_Betr_TI]) erstellen.
Akzeptanzkriterien	,
Alternativen	-

[<=]

3.4.1 Akzeptanzkriterien - Schlüssel verwalten

4 Anforderungen an den Produkttyp

4.1 Aufbau und Inhalt des Federation Master Entity Statement

Der Federation Master bildet den Vertrauensanker der Föderation.  Ebenso ist der Federation Master eine Entität innerhalb der Föderation. Gemäß dem verwendeten Standard OpenID Connect mit OAuth 2.0 kommen JSON Web Token (JWT), JSON Web Encryption (JWE), JSON Web Signature (JWS) und JSON Web Key (JWK) zum Einsatz.

Um nutzenden Anwendungen eine einheitliche Bezugsquelle für die Adressierung von Schnittstellen zu schaffen, werden die für alle Akteure grundlegenden Schnittstellen im sogenannten Entity Statement zusammengefasst und dort unter der ".well-known/openid-federation" gemäß [OpenID Connect Federation 1.0#rfc.section.6] veröffentlicht.

Alle Akteure der Föderation sind angehalten, das Entity Statement herunterzuladen und den Inhalt in den geplanten Betrieb einzubeziehen. Die Teilnehmer der Föderation benötigen das Entity Statement des Federation Master zur: 

• Validierung der Vertrauenskette in der Kommunikation zwischen Fachdiensten und sektoralem Identity Provider
• Validierung anderer Kommunikationsteilnehmer in der Föderation
• Ermittlung des API-Endpunktes des Federation Master
• Ermittlung der Liste aller in der Föderation registrieren sektoralen Identity Provider.

Hinweis: Ist ein sektoraler IDP ggf. temporär nicht erreichbar, so sollte das Herunterladen des Entity Statements über den Federation Master weiter (z.B. stündlich) versucht werden.

Hinweis 1: Das Sperren eines Fachdienstes bedeutet technisch den Ausschluss aus der Föderation. Fragt ein sektoraler IDP die Teilnehmerauskunft zu einem gesperrten Fachdienst beim Federation Master ab, so antwortet dieser gemäß https://openid.net/specs/openid-federation-1_0.html#error_response mit Error Code HTTP-401 invalid_client.

Hinweis 2: Zum Entsperren muss der Fachdienst die Abweichungen in seinem Entity Statement korrigieren oder im Fall gewollter Änderungen zur Aktualisierung den organisatorischen Registrierungsprozess erneut durchlaufen.

Hinweis: Die Anforderung ist als SOLL formuliert. Von dieser Anforderung kann abgewichen werden, wenn es begründete Bedenken (z.B. weitere Incidents) gegen die Zulassung des Fachdienstes gibt.

4.2 Organisatorische Prozesse am Federation Master

Hinweis 1: Der Aufbau und die Verwendung der hierarchischen Vertrauensbeziehung (Trust Chain)  ist im Standard [OpenID Connect Federation 1.0] festgelegt und wird darüber hinaus hier nicht weiter spezifiziert.

Hinweis 2: Die Registrierung MUSS für jede Betriebsumgebung separat erfolgen. Betriebsumgebungen sind Test-Umgebung (TU), Referenz-Umgebung (RU) und die Produktiv-Umgebung (PU). Die Registrierung für die Produktiv-Umgebung erfolgt erst nach Zulassung oder Bestätigung.

Fachdienste sollten nur genau die scopes beanspruchen, die für die Ausführung ihrer Anwendungsfälle unbedingt notwendig sind. Eine differenziertere Unterscheidung in verpflichtenden Attribute (essential claims, ohne die eine Diensterbringung gar nicht möglich ist) und freiwillige Attribute (voluntary claims, ohne die eine Diensterbringung in eingeschränktem Umfang möglich ist) wird durch die Verwendung von claims ermöglicht.

Hinweise 1:  Die Abwicklung kann über Service Request durch gematik. oder durch definierte Trigger im Rahmen eines Sicherheitsvorfalls erfolgen.

Hinweis 2: Beim Löschen eines sektoralen Identity Providers aus der Föderation wird zusätzlich die Sperrung der Signaturzertifikate in der Komponenten-PKI veranlasst, welche dieser zur Signatur seiner ID_TOKEN verwendet. Dies geschieht selbstständig durch den Anbieter des IDP oder bei "Wegfall der Voraussetzung für den Betrieb" durch die gematik.

Hinweis: Für den Ablauf der Schlüsselprüfungen siehe AF_10110 - Monitoring der TLS- Zertifikate der VAU 

Hinweis: Geeignete Maßnahmen können je nach Analyseergebnis z.B. das Einstellen von Security-Bugs beim Betreiber des sektoralen Identity Provider, die Einstellung eines sicherheitsrelevanten Notfalls gegen den Anbieter des entsprechenden sektoralen IDP durch den Federation Master im ITSM, aber auch das Löschen des betroffenen sektoralen IDP sein.

4.3 Allgemeine Sicherheitsanforderungen

4.4 Sicherheit der Netzübergänge

Hinweis: Durch die Zurückweisung von Verbindungen wird sichergestellt, dass Clients einen Verbindungsaufbau mit einer anderen Instanz des Fachdienstes versuchen, bei dem die erforderlichen Ressourcen zur Verfügung stehen.

4.5 Fehlermeldungen

5 Anhang – Verzeichnisse

5.1 Abkürzungen

Tabelle 19: Abkürzungen

5.2 Glossar

Tabelle 20: Glossar

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

5.3 Abbildungsverzeichnis

5.4 Tabellenverzeichnis

5.5 Referenzierte Dokumente

5.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

Tabelle 21: Quellen

5.5.2 Weitere Dokumente

Tabelle 22: Weitere Dokumente