Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation ePA-Frontend des Versicherten im KTR-AdV-Terminal

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
27.03.2020
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSpec_Frontend_Vers_AdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

<<kurze Beschreibung der inhaltlichen Änderungen (max. ½ Seite)>>

Dokumentenhistorie

<<Genereller Hinweis:

Hidden Text wird blau dargestellt

In doppelten spitzen Klammen gefasste Mustertexte der Vorlage sind Hidden Text und sind für die Druckaufbereitung normalerweise ausgeblendet.

In einfachen spitzen Klammern gesetzte Begriffe sind Platzhalter und sinngemäß auszutauschen bzw. zu entfernen.

Alle Anforderungen und Abbildungen sind Muster und zu entfernen.

Fachliche Formulierungen und Abbildungen aus dem Kontext der TI sind beispielhaft und müssen entfernt werden

Weitere Hinweise – insbesondere zum Umgang mit Anforderungen – siehe Kap. 2.>>

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps <Produkttyp>.

<Danach kurze fachliche Einordnung des Dokumentengegenstands – 1 Absatz! – kann aus dem alten Kap. 1 abgeleitet werden>

1.2 Zielgruppe

<Wenn für alle 3 Lose>

Das Dokument ist maßgeblich für die Anbieter der Lose 1, 2 und 3 des Vorhabens „Erprobung Online-Rollout (Stufe 1)“ <nur sofern das Dokument für z. B Beistellungen von Komponenten (Kartenherausgeber) oder Fachdienste (wegen der Schnittstellen) relevant ist, wird folgende Klausel in den Satz aufgenommen:> sowie für Hersteller und Anbieter von weiteren Produkten zum Online-Rollout (Stufe 1).

<Andernfalls auf die Lose zuschneiden, also entweder >

Das Dokument ist maßgeblich für die Anbieter der Lose 1 und 2 des Vorhabens „Erprobung Online-Rollout (Stufe 1)“ <nur sofern das Dokument für z. B. Beistellungen von Komponenten (Kartenherausgeber) oder Fachdienste (wegen der Schnittstellen) relevant ist, wird folgende Klausel in den Satz aufgenommen:> sowie für Hersteller und Anbieter von weiteren Produkten zum Online-Rollout (Stufe 1).

<oder>

Das Dokument ist maßgeblich für die Anbieter von Los 3 des Vorhabens „Erprobung Online-Rollout (Stufe 1)“ <nur sofern das Dokument für z. B. Beistellungen von Komponenten (Kartenherausgeber) oder Fachdienste (wegen der Schnittstellen) relevant ist, wird folgende Klausel in den Satz aufgenommen:> sowie für Hersteller und Anbieter von weiteren Produkten zum Online-Rollout (Stufe 1).

<Hinweis: Der Hinweis auf die Geltung für Autoren von Spezifikationen ist obsolet! Diese Gültigkeit ist z.B. bereits im Projektauftrag aber auch in der Methodik der gematik verankert.>

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des Deutschen Gesundheitswesens für den Online-Rollout (Stufe 1). 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) fest­gelegt 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

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 A5).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps <Produkttyp> verzeichnet.

<sofern erforderlich, sind Abgrenzungen zu anderen Spezifikationen/Konzepten oder im Kontext derzeit nicht relevanten Themen vorzunehmen, andernfalls entfällt dieser Absatz>

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zum Themenbereich

<usw.>

1.5 Methodik

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.

<sofern die neue Nomenklatur der Afos verwendet wurde, zusätzlich:>

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.

Abbildung 1: Bsp.

<Weitere Methodik-Hinweise (z.B. auf UML als Modellierungsform) sind nicht erforderlich.>

1.5.1 Hinweis auf offene Punkte <<optional, nur bis einschl. Abstimmphase >>

2 Systemüberblick

<<hier erfolgt, in knappen Worten und ggf. Diagrammen, ein informativer Überblick über den Produkttyp und die Aufgaben die er erfüllt, und die Nachbarsysteme und Rollen, die mit diesem System (Produkttyp) interagieren. Um Redundanzen zu den Konzepten zu vermeiden, kann auf die Konzepte verwiesen werden, in denen relevante Anteile zum Systemüberblick des Produkttyps festgelegt wurden (z.B. relevante Use Cases). Dies Kapitel ist rein informativ, es dürfen keine Anforderungen gestellt werden.>>

3 Systemkontext

3.1 Akteure und Rollen <<optional – ggf. komplett zu streichen>>

<<Optionale Dezidiert auf den Produkttyp bezogene Konkretisierung von Akteuren und Rollen, basierend auf den Festlegen in den Konzepten. Es darf keine normative Wiederholung von Akteuren und Rollen der Konzepte erfolgen.>>

3.2 Nachbarsysteme <<optional – ggf. komplett zu streichen>>

<<Optionale Konkretisierung der Nachbarsysteme, basierend auf den Festlegungen in den Konzepten.>>

<<Das Kapitel (Ebene 1) muss auch dann erhalten bleiben, wenn keine Beschreibung des Kontexts notwendig ist.

Werden keine Festlegungen getroffen, sollte das Kapitel mit dem folgenden Standardsatz erhalten bleiben:

Eine Beschreibung des Systemkontexts ist nicht erforderlich.>>

4 Zerlegung des Produkttyps

<<Optional: Falls eine weitere Zerlegung des Produkttyps in Teilsysteme nötig ist, erfolgen alle Festlegungen hierzu in diesem Kapitel. Im weitern Verlauf des Dokuments kann auf die hier festgelegte Teilsysteme zurückgegriffen werden. Speziell können übergreifende Anforderungen für die Teilsysteme gestellt werden (Kapitel 6) und die Funktionsmerkmale die Teilsysteme konkretisieren (Kapitel 7). Das Kapitel muss auch dann erhalten bleiben, wenn keine weitere Zerlegung stattfindet.

Werden keine Festlegungen getroffen, sollte das Kapitel mit dem folgenden Standardsatz erhalten bleiben:

Eine weiter Untergliederung der Aufbaustruktur des Produkttyps ist nicht erforderlich.>>

5 Übergreifende Festlegungen

<<Sofern es Festlegungen für den Produkttyp und seine Teilsysteme aus Kap. 5 gibt, die sich nicht  einem Funktionsmerkmal zuordnen lassen, werden diese hier erhoben.>>

6 Funktionsmerkmale

<<Vollständig funktionale Zerlegung der Funktionen des Produkttyps in Funktionsmerkmale. I.d.R. ergeben sich die Funktionsmerkmale 1:1 aus den systemspezifischen Konzepten der TI-Plattform. Für die Architektur sind dies die in gemKPT_Arch_TIP definierten Basis-, Infrastruktur- und Netzwerkdienste mit Relevanz für den Produkttyp.>>

<<Ggf. Übersicht aller Funktionsmerkmale und Schnittstellstellen in geeigneter Form>>

<<Hinweis zur Struktur: Sollte nur genau ein Funktionsmerkmal zu beschreiben sein, sollte die überflüssige Gliederungsebene ausgelassen werden und alle untergeordneten Kapitel rücken dementsprechend eine Ebene höher – die Kapitelüberschrift der Eben 1 „7 Funktionsmerkmale“ wird dann ersetzt durch den Titel des Funktionsmerkmals – dann z. B. „7 Basisdienst Kartenverwaltung“, die Unterkapitel zu den einzelnen Schnittstellen rücken auf Ebene 2 etc.>>

6.1 <Funktionsmerkmal_ABC>

<<Folgende Reihenfolge ist bei der Dokumentation der Schnittstellen einzuhalten: 1: technische Schnittstellen mit einen direkten funktionalen Bezug zu Funktionsmerkmal; 2: technische Schnittstellen mit einem betrieblichen bzw. organisatorischen Bezug; 3: organisatorische Schnittstellen>>

6.1.1 Schnittstelle <I_XYZ>

<<Vollständige Definition (WAS) und Umsetzung (WIE)  der Schnittstelle I_XYZ.
Beispiel: Die Schnittstelle <I_XYZ> setzt die in gemKPT_XXX_TIP definierte Schnittstelle <I_AAA> technisch um>>

6.1.1.1 Schnittstellendefinition

<<Definition der Schnittstelle mit allen ihren Anteilen (z.B. Operationen) auf technischer Ebene im Sinne einer Schnittstellenspezifikation (Syntax und Semantik). Die Schnittstellendefinition ist von nutzenden Systemen zu beachten.

Die Schnittstellendefinition erfolgt beispielsweise durch

• Definition aller technischen Operationen mit Parametern
• Vollständige Semantik der Schnittstelle
• Nichtfunktionale Anteile
• Ablaufdiagramme im Kontext der Schnittstelle, falls nötig (für nicht-triviale Abläufe)

Die Definition der Schnittstelle muss in Umsetzung einer Konzeption erfolgen (durch Umsetzungsanforderungen)

In der Schnittstellendefinition darf nicht auf die Umsetzung im Produkttyp eingegangen werden.>>

6.1.1.2 Umsetzung

<<Wie wird die Schnittstelle im Produkttyp umgesetzt, z.B. durch Beteiligung mit anderen Produkttypen (Nutzung der dort bereitgestellten Schnittstellen). Der Fokus liegt hierbei auf einer Black-Box-Betrachtung der Umsetzung für den Produkttyp. Die Umsetzungsanteile sind irrelevant für den Nutzer und können daher geändert werden, ohne dass der Nutzer davon betroffen ist. Falls andere Produkttypen in der Umsetzung der Schnittstelle beteiligt sind, muss dies in geeigneter Form auf technischer Ebene beschrieben werden (z.B. durch Verwendung von Sequenzdiagrammen und Referenzierung der nötigen Schnittstellen). Betrachtet werden sollen hierbei aber nur die direkt verwendeten Schnittstellen und die bereitstellenden Produkttypen. Es soll hier keine E2E-Sicht erfolgen. Die E2E-Sicht in der TI-Plattform ist bereits auf Konzeptebene vollständig dargestellt.

Die Umsetzung der Schnittstelle im bereitstellen Produkttyp muss in Umsetzung einer Konzeption erfolgen (durch Umsetzungsanforderungen)>

6.1.1.3 Nutzung <<optional – ggf. komplett zu streichen>>

<<Optional falls bereits einheitliche Festlegungen zur Nutzung definiert werden sollen. Ansonsten können spezifische Festlegungen auch in den Spezifikationen der nutzenden Produkttypen erfolgen. Anforderung in diesem Kapitel sind ausschließlich  relevant für den Nutzer der Schnittstelle>>

6.1.2 Schnittstelle <P_XYZ>

<<Vollständige Definition (WAS) und Umsetzung (WIE)  der organisatorischen Schnittstelle P_XYZ. Hierzu zählen insbesondere auch produkttypspezifische organisatorische betriebliche Anteile. Technische Schnittstellen die für im Rahmen der organisatorischen Schnittstelle benötigt werden, müssen in einem Kapitel für technische Schnittstellen definiert werden.>>

6.1.2.1 Schnittstellendefinition

6.1.2.2 Umsetzung

6.1.2.3 Nutzung <<optional – ggf. komplett zu streichen>>

<< Optional falls bereits einheitliche Festlegungen zur Nutzung definiert werden sollen Ansonsten sollen spezifische Festlegungen auch in den Spezifikationen der nutzenden Produkttypen erfolgen

>>

6.1.3 Artefakte

<<Optional: Hier Datenstrukturen und Wertebereiche, die spezifisch im Kontext des Funktionsmerkmal liegen– andernfalls Kap. 7 nutzen

Werden keine Festlegungen getroffen, sollte das Unterkapitel mit dem folgenden Standardsatz erhalten bleiben:

Zu Artefakten im Zusammenhang mit Funktionsmerkmal werden keine gesonderten Festlegungen getroffen.>

6.1.4 Testunterstützung

<<Optional wenn für dieses Funktionsmerkmal  eine spezielle Testunterstützung benötigt wird. Hier sind speziell nötige Umsetzungen für den Produkttyp aus der Testarchitektur durchzuführen. Hierbei kann es sich um spezifische Ausprägungen des Produkttypen für Testumgebungen handeln, aber auch um spezielle Testfunktion die im Wirkbetrieb aktivierbar bzw. nutzbar sein müssen.

Werden keine Festlegungen getroffen, sollte das Unterkapitel mit dem folgenden Standardsatz erhalten bleiben:

Zur Unterstützung von Tests im Zusammenhang mit dem Funktionsmerkmal werden keine gesonderten Festlegungen getroffen>>

6.1.5 Hardwaremerkmale

<<Optional: Hardwaremerkmale im Kontext des Funktionsmerkmals. Beispielsweise HW-Schnittstellen oder andere HW-Bestandteile mit Sichtbarkeit nach Außen (z.B. Bedienelemente).

Werden keine Festlegungen getroffen, sollte das Unterkapitel mit dem folgenden Standardsatz erhalten bleiben:

Das Funktionsmerkmal setzt keine besonderen Hardwaremerkmale voraus.

>>

7 Informationsmodell

<<Optional: Enthält, sofern erforderlich, das technische Info-Modell – den Information View, z.B. auch Zertifkate, Schlüssel, eGK-Strukturen der TI-Plattform >>

<<Das Kapitel muss auch dann erhalten bleiben, wenn kein Informationsmodell angegeben wird.

Werden keine Festlegungen getroffen, sollte das Kapitel mit dem folgenden Standardsatz erhalten bleiben:

Eine gesondertes Informationsmodell der durch den Produkttypen verarbeiteten Daten wird  nicht benötigt.>>

8 Verteilungssicht

<<Optional: Darstellung der Verteilsicht des Produkttyps, also der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und die Einbettung in die physikalische Umgebung (z.B. Arztpraxis)>>

<<Das Kapitel muss auch dann erhalten bleiben, wenn kein Verteilungssicht dargestellt wird.

Werden keine Festlegungen getroffen, sollte das Kapitel mit dem folgenden Standardsatz erhalten bleiben:

Eine Darstellung der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird nicht benötigt >>

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

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

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.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.

9.5.2 Weitere Dokumente

9.6 Verzeichnis der verwendeten Operationen und Interfaces <<optional>>

9.7 Klärungsbedarf <<optional>>

9.8 Allgemeine Erläuterungen <<optional>>

<<hier können die Interfaces und Operationen mit Verweis auf die jeweilige Seite gelistet werden. Lesehilfe zur Auflösung von Querbezügen>>