gemSpec_FD_TI-Flow_V1.0.0_CC

Prereleases:

PDF HTML Excel XML
Zurück nach oben






Telematikinfrastruktur 2.0





Spezifikation: 

TI-Flow-Fachdienst




Version1.0.0_CC
Revision1649056
Stand30.06.2026
Statuszur Abstimmung freigegeben
Klassifizierungöffentlich_Entwurf
ReferenzierunggemSpec_FD_TI-Flow

Dokumentinformationen

Gender-Hinweis
Aus Gründen der besseren Lesbarkeit wird in diesem Dokument überwiegend die männliche Form verwendet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

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

Dokumentenhistorie

Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung
1.0.0_CC 30.06.2026 Ersterstellung der Spezifikation: TI-Flow-Fachdienst gematik

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegende Spezifikation definiert Anforderungen zu Herstellung und Betrieb des Produkttyps TI-Flow-Fachdienst.

Die Spezifikation wird ergänzt durch den Implementation Guide TI-Flow, in dem insbesondere die durch den TI-Flow-Fachdienst für Clientsysteme bereitgestellten Schnittstellen beschrieben sind.

1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller des TI-Flow-Fachdienstes, sowie an Hersteller und Anbieter von Clientsystemen des TI-Flow-Fachdienstes.

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. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) fest­gelegt und bekannt gegeben.

Wichtiger 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 Festlegungen zum Themenbereich:

  • Bereitgestellte Schnittstellen für Clientsysteme des TI-Flow-Fachdienstes
  • Integration des TI-Flow-Fachdienstes als HCC-Dienst in die HCC-Plattform

1.5 Methodik

Anforderungen / Anwendungsfälle

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

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

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

Hinweise auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:

Beispiel für einen offenen Punkt.

2 Systemüberblick

Der TI-Flow-Fachdienst verwaltet verschiedene Workflows von Anwendungen der Telematikinfrastruktur als ein zentraler Ressourcenserver auf Basis des FHIR-Standards mit einer RESTful API. 

Die Workflows werden dabei über eine eindeutige Ressourcen-ID (Task-ID) adressiert. Für jeden Workflow ist ein Statusmodell spezifiziert. Der TI-Flow-Fachdienst verwaltet die Statusübergänge und stellte die Zulässigkeit der durch Nutzer initiierten Statusübergänge sicher.

Der TI-Flow-Fachdienst protokolliert alle Zugriffe auf einen Workflow für den dem Workflow zugeordneten Versicherten.

Der TI-Flow-Fachdienst stellt sicher, dass die Daten nur entsprechend der gesetzlich zulässigen Speicherdauer vorgehalten werden.

Der TI-Flow-Fachdienst bietet seine Aussenschnittstellen im Internet an und setzt für die Authentisierung und Autorisierung von Clientsystemen Zero Trust Access (ZETA) Mechanismen um.

Der TI-Flow-Fachdienst unterstützt eine asynchrone Übermittlung von Daten an Drittsysteme (bspw. ePA Medication Service).

Der TI-Flow-Fachdienst realisiert die Vertraulichkeit und Integrität der verarbeiteten Daten über das Konzept der vertrauenswürdigen Ausführungsumgebung (VAU), die eine durchgängige Verschlüsselung der Verordnungen und der dazu gehörigen Daten aus einer Kombination kryptographischer Verfahren während des Transports, der vertrauenswürdigen Verarbeitung und in der verschlüsselten Persistierung der Daten sicherstellt. Dabei realisiert der TI-Flow-Fachdienst die VAU nicht selbst, sondern dadurch, dass der TI-Flow-Fachdienst auf einer durch einen Healthcare Confidential Computing (HCC)-Provider betriebenen HCC-Plattform läuft, welche auch für weitere Anwendungen der TI genutzt werden kann.

Abbildung 1: Systemüberblick TI-Flow-Fachdienst

Hinweis: Die Anbindung des TI-Flow-Fachdienstes an die ePA-Aktensysteme soll, wie in der Abbildung dargestellt, ab der Implementierung des ZETA Guards durch die ePA-Aktensysteme über den ZETA Guard erfolgen. Vor dieser Implementierung wird der TI-Flow-Fachdienst sich direkt über das Internet mit dem ePA-Aktensystemen verbinden. Hierbei wird die mit dem E-Rezept-Fachdienst etablierte Authentisierung auch für den TI-Flow-Fachdienst genutzt.

3 Systemkontext

3.1 Nachbarsysteme

BfArM Webservice

Backend-System für den TI-Flow-FD. Der TI-Flow-FD übermittelt Daten zu eingelösten T-Rezepten an das BfArM.

Clientsystem des Kostenträgers

Das Clientsystem des Kostenträgers setzt die Bereitstellung von Freischaltcodes für Digitale Gesundheitsanwendungen um.

ePA Aktensystem

Der TI-Flow-FD übermittelt Verordnungsdaten und Dispensierinformationen von E-Rezepten an den ePA Medicationservice der Aktensysteme.

FHIR-VZD

Der TI-Flow-FD ermittelt am FHIR-VZD bspw. Informationen zu europäischen Ländern, welche ermöglichen, dass E-Rezepte im Szenario ePrescription/eDispensation Land A eingelöst werden können.

Frontend des Versicherten

Clientsystem des Versicherten zur Einsichtnahme seiner Daten am TI-Flow-FD und zur Zuweisung von Verordnungen an abgebende Institutionen.

NCPeH-FD

Der NCPeH-FD ist ein Clientsystem des TI-Flow-FD. Er übermittelt Anfragen zum Einlösen von E-Rezepten im Szenario ePrescription/eDispensation Land A.

PoPP-Service

Der TI-Flow-FD prüft von Clientsystemen übermittelte PoPP-Token. Hierfür bezieht der TI-Flow-FD Informationen zum Signaturzertifikat des Tokens vom PoPP-Service.

Primärsystem abgebender Leistungserbringer

Primärsysteme (AVS) von Leistungserbringerinstitutionen, welche die Verordnungen vom TI-Flow-Fachdienst abrufen und die verordnete Leistung erbringen.  

Primärsystem verordnender Leistungserbringer

Primärsysteme (PVS/ZPVS/KIS) der Leistungserbringer, welche Verordnungen erstellen und in den TI-Flow-Fachdienst einstellen. 

Push Gateway

Backend-System für den TI-Flow-FD. Der TI-Flow-FD übermittelt Informationen zu Notifications für das FdV des Versicherten an das zur FdV Instanz registrierten Push Gateway.

HCC-Plattform

Die HCC-Plattform ist die Ausführungsumgebung des TI-Flow-Fachdienstes. Sie stellt dem TI-Flow-Fachdienst Mechanismen zur Umsetzung der Datenverarbeitung in einer VAU sowie Services wie bspw. Datenbankservices und HSM zur Verfügung.

ZETA-Service

Der ZETA-Service stellt dem ZETA Guard regelmäßig Policy-Updates bereit, welche durch den Authorization Service im ZETA Guard angewandt werden.

3.2 Akteure und Rollen

Der TI-Flow-Fachdienst wird vom Anbieter TI-Flow-Fachdienst in der vom Anbieter HCC-Plattform bereitgestellten Infrastruktur im Internet betrieben. Es müssen für die verschiedenen Betriebsumgebungen (Produktivumgebung (PU), gemäß [gemKPT_Test] geforderten Test- und Referenzumgebungen (RU und RU-DEV)) in jeweils voneinander unabhängige (virtuellen) Instanzen betrieben werden. Für die Absicherung gegenüber dem Internet wird der von der gematik beigestellte ZETA Guard verwendet.

3.2.1 Herstellung und Betrieb

3.2.1.1 Hersteller des TI-Flow-Fachdienst

Der Hersteller des TI-Flow-Fachdienstes implementiert und entwickelt den TI-Flow-Fachdienst gemäß [gemProdT_TI-Flow-FD]. 

3.2.1.2 Anbieter TI-Flow-Fachdienst

Der Anbieter TI-Flow-Fachdienst verantwortet und betreibt den TI-Flow-Fachdienst gemäß den Vorgaben der gematik. Der Anbieter TI-Flow-Fachdienst muss hierfür Dienste der HCC-Plattform nutzen.  

Neben dem Betrieb von Instanzen für den Produktivbetrieb müssen weitere Instanzen für den Testbetrieb gemäß [gemAnbT_TI-Flow-FD] betrieben werden. 

Der Anbieter TI-Flow-Fachdienst nimmt gemäß [gemAnbT_TI-Flow-FD] am TI-ITSM teil.

3.2.1.3 Anbieter HCC-Plattform (HCC-Provider)

Der Anbieter HCC-Plattform verantwortet die HCC-Plattform gemäß den Vorgaben der gematik, auf der der TI-Flow-Fachdienst betrieben wird.

Der Anbieter HCC-Plattform stellt dem Anbieter TI-Flow-Fachdienst Dienste bereit, welche für das Deployment und den Betrieb des Fachdienstes genutzt werden. 

3.2.1.4 gematik

Die gematik spezifiziert den TI-Flow-Fachdienst und schreibt die Entwicklung sowie den Produktivbetrieb des TI-Flow-Fachdienstes aus.

Die gematik unterstützt den Anbieter TI-Flow-Fachdienstes durch die Beistellung des ZETA Guard. Darüber hinaus betreibt die gematik die Zero Trust Komponenten Policy Information Point (PIP) und Policy Administration Point (PAP): ZETA PIP und PAP-Service. 

3.2.1.5 Clientsystem-Hersteller

Clientsystem-Hersteller setzen die TI-Flow-Client- inklusive ZETA-Client/Modul-Funktionalität um. Sie nutzen den vom Anbieter TI-Flow-Fachdienst Test- und Referenzumgebungen, um ihre jeweilige Umsetzung zu testen.

3.2.2 Nutzer des Dienstes

3.2.2.1 Akteure der Workflows

In der Spezifikation eines Workflow wird ein Statusmodell mit seinen Statusübergängen sowie die Akteure, welche diese Statusübergänge initiieren können, festgelegt.

Akteure sind bspw. (Zahn-)Arztpraxen, Krankenhäuser, Apotheken, Pflegeeinrichtungen, Kostenträger und Versicherte.

Die Akteure nutzen Clientsysteme, um auf die Daten des TI-Flow-Fachdienstes zuzugreifen. Der Datenzugriff von Akteuren im europäischen Ausland zum Einlösen von E-Rezepten wird über den NCPeH-FD geroutet.

Die deutschen institutionellen Akteure werden über ihre Telematik-ID identifiziert. 

3.2.2.2 Versicherte

Ein Versicherter ist Begünstigter eines Workflows, bspw. als Empfänger der Leistung einer Verordnung. In der Spezifikation eines Workflows können Statusübergänge festgelegt werden, welche der Versicherte als Akteur durchführen kann.

Der TI-Flow-Fachdienst stellt dem Versicherten ein Zugriffsprotokoll bereit, welches die Zugriffe auf seine Daten dokumentiert.

Der Versicherte nutzt ein Frontend des Versicherten (bereitgestellt durch den Kostenträger oder die gematik) für den Zugriff auf den TI-Flow-Fachdienst.

Der Versicherte wird über seine Versicherten-ID (10-stelliger unveränderlicher Teil der Krankenversichertennummer (KVNR)) identifiziert.

Hinweis: Es ist geplant, die von der gematik zu erarbeitende anwendungsübergreifende Vertreterfunktionalität zu integrieren.

4 Datenschutz und Informationssicherheit

Der TI-Flow-Fachdienst zeichnet sich aus Datenschutz- und Informationssicherheitssicht insbesondere dadurch aus, dass er personenbezogene und personenbezogene medizinische Daten (Schutzbedarf Vertraulichkeit und Integrität „sehr hoch“) verarbeitet, ohne dass der Anbieter des TI-Flow-Fachdienstes eine Legitimation zum Zugriff auf diese Daten besitzt.

Da der TI-Flow-Fachdienst auf einer HCC-Plattform läuft, die von einem anderen Anbieter - dem HCC-Provider - betrieben wird, ergeben sich gegenseitige Abhängigkeiten bei der Realisierung von gesamtheitlich wirkenden Datenschutz- und Informationssicherheitsmaßnahmen.

Es müssen also technische und organisatorische Maßnahmen getroffen werden, um sowohl den Anbieter des TI-Flow-Fachdienstes als auch andere an der Zurverfügungstellung der TI-Flow-Fachdienst-Funktionalität beteiligte, vom Zugriff auf die im TI-Flow-Fachdienst verarbeiteten Daten auszuschließen.

Der TI-Flow-Fachdienst muss sich auf die für die Erbringung der Gesamtsicherheit erforderlichen Maßnahmen durch die HCC-Plattform verlassen können. Der Anbieter des TI-Flow-Fachdienstes erfüllt dabei seine Pflicht, wenn er den TI-Flow-Fachdienst ausschließlich auf einer HCC-Plattform zum Laufen bringt, die die gematik dafür als geeignet beurteilt hat. Zudem müssen sowohl der Hersteller als auch der Anbieter des TI-Flow-Fachdienstes die vom HCC-Provider bereitgestellten Leitlinien und Empfehlungen für die sichere Konfiguration, Installation und Nutzung der HCC-Plattform-Services für den TI-Flow-Fachdienst umsetzen.

Auf der anderen Seite darf ein HCC-Provider nur von der gematik als geeignet beurteilte Fachdienste auf seiner HCC-Plattform laufen lassen. Auf der technischen Seite wird dies durch eine Attestierung des TI-Flow-Fachdienstes beim Starten in der HCC-Plattform realisiert. Die dafür notwendigen Voraussetzungen werden in den Prozessen der Entwicklungs-Pipeline geschaffen.

Damit der TI-Flow-Fachdienst von der gematik als geeignet beurteilt werden kann, muss der Hersteller des TI-Flow-Fachdienstes (der zugleich auch der Anbieter des TI-Flow-Fachdienstes sein kann) die Qualität seines sicheren Entwicklungsprozesses durch ein Sicherheitsgutachten nachweisen und die Qualität des TI-Flow-Fachdienstes durch ein Produktgutachten.

Der Anbieter des TI-Flow-Fachdienstes (der zugleich auch der Hersteller des TI-Flow-Fachdienstes sein kann) weist seine Fähigkeit, den TI-Flow-Fachdienst sicher betreiben zu können, durch ein Sicherheitsgutachten und kontinuierlich durch die Integration in das Sicherheitsmanagement der gematik nach. Der Anbieter des TI-Flow-Fachdienstes ist aufgrund der Kritikalität des Dienstes und der Verantwortung der gematik für den Dienst dem Security Governance Level (SGL) 1 zugeordnet.

Der Anbieter TI-Flow-Fachdienst ist zusammen mit dem HCC-Provider gemeinsam datenschutzrechtlich Verantwortliche im Sinne Art. 26 DSGVO. Sie legen in einer Vereinbarung in transparenter Form fest, wer von ihnen welche Verpflichtung gemäß der DSGVO erfüllt, insbesondere was die Wahrnehmung der Rechte der betroffenen Person angeht, und wer welchen Informationspflichten gemäß den Artikeln 13 und 14 nachkommt, sofern und soweit die jeweiligen Aufgaben der Verantwortlichen nicht durch Rechtsvorschriften der Union oder der Mitgliedstaaten, denen die Verantwortlichen unterliegen, festgelegt sind. Die Vereinbarung muss die jeweiligen tatsächlichen Funktionen und Beziehungen der gemeinsam Verantwortlichen gegenüber betroffenen Personen gebührend widerspiegeln. Das wesentliche der Vereinbarung wird der betroffenen Person zur Verfügung gestellt. Ungeachtet der Einzelheiten der Vereinbarung kann die betroffene Person ihre Rechte im Rahmen dieser Verordnung bei und gegenüber jedem einzelnen der Verantwortlichen geltend machen.

Authentisierung und Autorisierung von Nutzern

Der TI-Flow-Fachdienst stellt sicher, dass ausschließlich die gesetzlich vorgesehenen Nutzer- bzw. Nutzergruppen auf die Daten zugreifen können, für die sie autorisiert sind. Umgesetzt wird dies einerseits durch die Zugriffsregeln im ZETA Guard und andererseits durch die statusabhängigen Zugriffsregeln im TI-Flow-Fachdienst. Die Authentisierungstärke ist für professionelle Nutzer (z.B. Leistungserbringer, Kostenträger) immer „gematik-ehealth-loa-high“. Versicherte können sich nach Einwilligung statt mit „gematik-ehealth-loa-high“ auch mit „gematik-ehealth-loa-substantial“ authentisieren. Die Zulässigkeit dieser Authentisierungsstärken wird von der gematik festgelegt und über die Policy im ZETA Guard durchgesetzt.

Authentisierung von Geräten

In Abhängigkeit vom Entwicklungsstand des ZETA Guard stellt dieser sicher, dass Nutzer nur mit registrierten und attestierten stationären und mobilen Clients auf den TI-Flow-Fachdienst zugreifen können. Die diesbezüglichen Policies sind anwendungsunabhängig und werden von der gematik festgelegt.

Ende-zu-Ende-Sicherheit

Zur Sicherstellung der Ende-zu-Ende-Sicherheit der Anwendungen, die den TI-Flow-Fachdienst nutzen, sind – neben der Maßgabe des Betreiberausschlusses bei der Verarbeitung der Daten (data in use) – alle Verbindungen zu Clients TLS- und ggf. (in Abhängigkeit des Schutzbedarfs der übertragenen Daten) zusätzlich ASL-verschlüsselt (data in transfer). Eine zusätzliche Verschlüsselung mittels ASL erfolgt in jedem Fall ausgehend von den Clients der Nutzer bis zum ZETA-Guard im TI-Flow-Fachdienst. Dies ist dem hohen Angriffspotenzial des Internets geschuldet. Sollte der ZETA-Guard und der Resource Server des TI-Flow-Fachdienstes in verschiedenen virtuellen Machines laufen, so erfolgt die Transportverschlüsselung zwischen den VMs mittels mTLS - also ohne zusätzlichen ASL. Damit wird der Betreiberausschluss gewährleistet und dem niedrigeren Angriffspotenzial der HCC-Provider-Betriebsumgebung Rechnung getragen. Perspektivisch erfolgt eine Migration auf Post-Quanten-TLS (PQC-TLS) sobald Implementierungen auf der Grundlage eines diesbezüglichen Standards verfügbar sind.

Die Speicherung von personenbezogenen medizinischen Daten erfolgt verschlüsselt, wobei die Verschlüsselung mit Schlüsseln erfolgt, auf die der Anbieter des TI-Flow-Fachdienstes selbst keinen Zugriff hat (data at rest).

Protokollierung und Monitoring

Der TI-Flow-Fachdienst protokolliert Daten für verschiedene Zwecke. Für Versicherte erfolgt eine Protokollierung der Zugriffe auf ihre Daten. Diese Protokolle können ausschließlich von den Versicherten selbst abgerufen werden (bzw. werden gemäß Referentenentwurf GDIG von der koordinierenden Stelle der gematik auf Anfrage eines Versicherten zur Verfügung gestellt). Zur Sicherstellung des Betriebs erfolgt einerseits eine Betriebsdatenerfassung (Telemetriedaten) für die gematik und andererseits führt der Anbieter des TI-Flow-Fachdienstes für seine betrieblichen Belange. In diesen Protokollen dürfen Identitäten natürlicher oder juristischer Personen ausschließlich pseudonymisiert erfasst werden. Der Anbieter des TI-Flow-Fachdienstes ist nicht in der Lage diese Pseudonyme aufzulösen. Die in den Daten der Betriebsdatenerfassung enthaltenen Pseudonyme können zweckgebunden durch die gematik aufgelöst werden. Der Zweck ist hierbei die Erkennung von Anomalien in der Verwendung der Anwendungen und ggf. die Möglichkeit für die gematik in Verdachtsfällen auf einzelne (professionelle) Nutzer zugehen zu können.

Neben der Protokollierung von Ereignissen, erfolgt eine sicherheitstechnische Überwachung des TI-Flow-Fachdienstes mittels Security Monitoring, das im ZETA Guard implementiert ist und Daten in Echtzeit an die gematik sendet, wo die Daten gesammelt und mit Security Monitoring Tools ausgewertet werden.

Drosselung bei Anomalie-Erkennung

Eine Anomalie-Erkennung findet auch im TI-Flow-Fachdienst selbst statt. Das Ausführen ausgewählter Anwendungsfälle wird sukzessive verzögert, wenn ein ungewöhnliches Nutzungsverhalten detektiert wird. DoS- bzw. DDoS-Angriffe werden an verschiedenen Stellen im Gesamtsystem (HCC-Plattform / ZETA Guard / TI-Flow-Fachdienst) abgewehrt.

Proof of Patient Presence (PoPP)

Der PoPP-Service erzeugt die Bestätigung eines Versorgungskontexts in Form eines kryptographisch gesicherten Popp-Tokens. Dieses Token bestätigt, dass ein bestimmter Versicherter mit einer bestimmten LEI zusammengekommen ist. Im E-Rezept-Kontext wird der PoPP-Token im Anwendungsfall des Präsentierens der eGK in einer Apotheke zwecks Abrufs und Einlösung (vor Ort oder remote mit App) benötigt. Hierbei ist keine eGK-PIN-Eingabe durch den Versicherten erforderlich, um das Einlösen von E-Rezepten – auch durch Vertreter - möglichst niederschwellig zu gestalten.

Verifikations- und Prüfidentitäten

Die gematik besitzt eine SMC-B mit der sie sich in der Produktivumgebung ausweisen kann. Die Verwendung dieser Identität ist streng reglementiert. Mit dieser Identität kann die gematik die $create-Operation ausführen und damit die Erreichbarkeit des TI-Flow-Fachdienstes auf der Ebene eines funktionalen Aufrufs verifizieren. Zur Ausführung anderer Operationen ist diese Identität nicht befugt.

Prüfidentitäten sind Identitäten fiktiver Versicherter, die insbesondere in Verbindung mit einer Prüfkarte eGK durch Dienstleister (vor Ort) zum Einsatz kommen, um das Funktionieren bestimmter Anwendungsfälle in der Produktivumgebung der TI aus Leistungserbringerinstitutionen heraus zu prüfen.

Der unveränderbare Teil der KVNR – die Versicherten-ID – der Prüfidentitäten entspricht einer bestimmten Bildungsregel, die von der gematik festgelegt ist. Die Versicherten-ID dient im TI-Flow-Fachdienst der Identifikation von Versicherten und der Zuordnung ihrer Daten. Dabei kann der TI-Flow-Fachdienst nicht feststellen, ob eine Versicherten-ID einer realen Person zugeordnet ist oder nicht. Er könnte zwar die Versicherten-ID einer Prüfidentität nach dem Muster der Bildungsregel identifizieren, aber bei von der Bildungsregel abweichenden fiktiven Versicherten-IDs könnte er diese nicht als Prüfidentität identifizieren.

Die aktuell spezifizierten Anwendungsfälle des TI-Flow-Fachdienstes lassen die Nutzung einer fiktiven Prüfidentität zu, ohne dass ein Schaden für Versicherte dabei entstehen kann.

Finanzielle Risiken entstehen u.U. für abgebende Leistungserbringer, falls für eine eGK Prüfkarte ein E-Rezept eingestellt wurde, dass mit dieser Karte in einer Apotheke eingelöst wird. Durch die auffällige optische Gestaltung der Prüfkarten ist eine Identifikation als solche durch abgebende Leistungserbringer leicht und eine Verwechslung mit eGKs realer Versicherter praktisch nicht möglich.

Feature-Toggles

Feature-Toggle bieten eine Möglichkeit Funktionen vorzeitig in produktiven Code zu übernehmen, ohne diese direkt verfügbar zu machen. Sie bieten ebenso die Möglichkeit konfigurativ auf betriebliche Situationen durch An- oder Abschalten von Funktionen im laufenden Betrieb zu reagieren.

Sicherheitsrelevante Toggle dürfen nur nach Anweisung der gematik durch den Hersteller des TI-Flow-Fachdienstes umgestellt werden. Die dafür notwendigen Prozesse werden zwischen dem Hersteller des TI-Flow-Fachdienstes und der gematik vereinbart.

5 Übergreifende Festlegungen

5.1 Sicherheit

5.1.1 Allgemeine Sicherheitsanforderungen

A_29702 - TI-Flow-Fachdienst - Berücksichtigung OWASP-Top-10-Risiken

Der TI-Flow-Fachdienst MUSS Maßnahmen zum Schutz vor den OWASP-Top-10-Risiken in der aktuellen Version umsetzen. [<=]

Hinweis: Der Hersteller des TI-Flow-Fachdienstes muss die jeweils aktuellen OWASP Top 10 Risiken im TI-Flow-Fachdienst berücksichtigen, sobald diese veröffentlicht wurden.

Der TI-Flow-Fachdienst soll sich vor Anfragen, die nicht auf ein übliches Verhalten von Leistungserbringerinstitutionen und Versicherten während des Verordnungsprozesses schließen lassen, schützen. Diesen Anomalien wird mit einer Drosselung der Bearbeitungsgeschwindigkeit begegnet, um bspw. Brute-Force-Attacken auf das Erraten von AccessCodes für den Zugriff auf Verordnungsdaten unattraktiv zu machen. 

A_29703 - TI-Flow-Fachdienst - Drosselung Brute-Force-Anfragen

Der TI-Flow-Fachdienst MUSS jede Antwort auf einen Funktionsaufruf, der einen nicht gültigen AccessCode oder ein nicht gültiges Secret enthält, um den http-Response-Header "Warning" (default "999 Throttling active") ergänzt und um ein konfigurierbares Zeitintervall (default: 500 Millisekunden) verzögert zurückschicken, um Brute-Force-Angriffe durch einen hohen Zeitaufwand unattraktiv zu machen. [<=]

A_29704 - TI-Flow-Fachdienst – Drosselung Fälschungen

Der TI-Flow-Fachdienst MUSS jede Antwort auf einen Funktionsaufruf, der einen Datensatz mit nicht gültig prüfbarer Signatur enthält, um den http-Response-Header "Warning" (default "999 Throttling active") ergänzt und um ein konfigurierbares Zeitintervall (default: 500 Millisekunden) verzögert zurückschicken, um Angriffe durch Fälschungen durch einen hohen Zeitaufwand unattraktiv zu machen. [<=]

Eine Anpassung der Konfigurationsparameter erfolgt in Absprache mit der gematik im Vorfeld des Build zu einem Release. Die Konfigurationsänderung erfolgt nicht zur Laufzeit.

A_29705 - TI-Flow-Fachdienst - Konfiguration und Deaktivierung Drosselung

Der Hersteller des TI-Flow-Fachdienstes MUSS die Funktion der Drosselung sowie die Konfiguration auf Weisung der gematik aktivieren oder deaktivieren bzw. die Konfigurationsparameter anpassen, um die Wirksamkeit des Mechanismus im Feld bei Bedarf zu verbessern. [<=]

5.1.2 Identifikation eines Clientsystems

Der TI-Flow-Fachdienst verwaltet und steuert den Einlöseprozess für elektronische Verordnungen. Damit kommt ihm eine Relevanz in der medizinischen Versorgung zu, die sich zum einen in einer hohen Verfügbarkeit und zum anderen in einem hohen Angriffspotential widerspiegelt. Zur Unterstützung der betrieblichen Überwachung des TI-Flow-Fachdienstes wird die Nutzung der im Feld befindlichen Clientsysteme protokolliert. Dabei ist der Zugriff auf die Schnittstellen des TI-Flow-Fachdienstes nur durch registrierte Clientsysteme zulässig. Der ZETA Guard stellt die Identifikation des Clientsystems sicher. Der Resource Server des TI-Flow-Fachdienst erkennt ein Clientsystem anhand der im eingehender HTTP-Requests angegebenen product_id und product_version. Der TI-Flow-Fachdienst protokolliert diese Werte.

A_29706 - TI-Flow-Fachdienst – Erkennung und Protokollierung Clientsystem

Der TI-Flow-Fachdienst MUSS das vom aufrufenden Nutzer verwendete Clientsystem anhand des im Rahmen der Authentisierung übermittelten zeta-user-info und zeta-client-data erkennen und in den Einträgen zur Telemetriedatenerfassung gemäß [gemSpec_Perf] protokollieren. [<=]

5.1.3 Sicherheit der Netzübergänge

Der TI-Flow-Fachdienst wird für Clientsysteme über das Internet erreichbar gemacht. Die folgenden Anforderungen beschreiben
die für diese Netzübergang erforderlichen Sicherheitsmechanismen.

Alle Zugriffe von Clientsystemen erfolgen über den ZETA Guard, welcher u.a. die Authentisierung und Autorisierung für den Zugriff auf den Resource Server umsetzt.

Zugriffe des Resource Servers auf Dienste im Internet müssen ebenfalls abgesichert werden. Es kann bei Verfügbarkeit die Egress Komponente des ZETA Guard genutzt werden.

Für die Umsetzung sind Services des HCC-Providers entsprechend zu konfigurieren.

A_29707 - Anbieter TI-Flow-Fachdienst – Richtlinien für den Paketfilter zum Internet - Protokolle

Der Anbieter TI-Flow-Fachdienst MUSS sicherstellen, dass die Weiterleitung von IP-Paketen vom Resource Server an der Schnittstelle zum Internet auf die nachfolgenden Protokolle beschränkt wird:

  1. HTTPS
  2. OCSP
  3. DNS
  4. NTP
[<=]

A_29708 - Anbieter TI-Flow-Fachdienst – Richtlinien für den Paketfilter zum Internet - Anfragen im Internet

Der Anbieter TI-Flow-Fachdienst MUSS sicherstellen, dass die Weiterleitung von IP-Paketen vom Resource Server an der Schnittstelle zum Internet auf die Aktivitäten

  1. OCSP-Responder und CRL-Download-Anfragen
  2. DNS-Anfragen
  3. NTP-Anfragen
  4. FHIR-VZD-Suchanfragen
  5. Anfragen an BfArM Webdienst
  6. Anfragen an Push Gateways
  7. Anfragen an PoPP-Service (Download des JWKS)
  8. Anfragen an ePA-Aktensysteme
beschränkt sind und jeden anderen Verbindungsaufbau aus dem Resource Server in Richtung Internet unterbinden. [<=]

Für den ZETA Guard gibt es entsprechende Anforderungen für die Kommunikation ins Internet.

5.1.4 Nutzung Vertrauenswürdige Ausführungsumgebung

In diesem Abschnitt werden die Anforderungen an den TI-Flow-Fachdienst zur Umsetzung in einer Vertrauenswürdigen Ausführungsumgebung (VAU) dargestellt. Die VAU dient der datenschutzrechtlich zulässigen und sicheren Verarbeitung von schützenswerten Klartextdaten innerhalb des TI-Flow-Fachdienstes sowie dem technischen Ausschluss der Profilbildung durch den Anbieter bzw. Betreiber. Die VAU stellt dazu Verarbeitungskontexte (d. h. Instanzen der VAU) bereit, in denen die Verarbeitung sensibler Daten im Klartext erfolgen kann. Die VAU wird durch den HCC-Plattform-Provider für den Fachdienst bereitgestellt.

Verarbeitung von Daten

A_29709 - TI-Flow-Fachdienst – Umsetzung der fachlichen Operationen in einer VAU

Der TI-Flow-Fachdienst MUSS die Verarbeitung aller fachlichen Operationen des Fachdienstes in einer Vertrauenswürdigen Ausführungsumgebung umsetzen. [<=]

A_29710 - TI-Flow-Fachdienst – Nutzung HCC-Plattform für VAU

Der Anbieter TI-Flow-Fachdienst MUSS für die Umsetzung der VAU die durch einen durch die gematik beauftragten HCC-Plattform-Provider angebotenen Dienste nutzen. [<=]

Persistieren von Daten

A_29713 - TI-Flow-Fachdienst – Verschlüsselung von außerhalb der VAU zu speichernden Daten

Der TI-Flow-Fachdienstes MUSS sicherstellen, dass sämtliche schützenswerten Daten vor einem Speichern außerhalb der VAU verschlüsselt werden. [<=]

A_29714 - TI-Flow-Fachdienst – Schlüssel für außerhalb der VAU zu speichernder Daten

Der TI-Flow-Fachdienstes MUSS für das Verschlüsseln zu speichernder Daten den Schlüssel für nur jeweils einen individuellen Vorgang (bspw. Workflow zu einer Verordnung inkl. aller mit diesem Workflow verbundenen Daten) verwenden oder mindestens einmal pro Sekunde den verwendeten Schlüssel wechseln, so dass nur die innerhalb einer Sekunde neu angelegten Vorgänge mit einem Schlüssel verschlüsselt werden. [<=]

A_29715 - TI-Flow-Fachdienst – Ableitung der Persistenzschlüssel durch ein HSM

Der TI-Flow-Fachdienstes MUSS die zum Verschlüsseln der persistierten Vorgangsdaten verwendeten Schlüssel von einem HSM der HCC-Plattform abrufen. [<=]

Übermittlung von Daten

A_29716 - TI-Flow-Fachdienst – vertrauliche Kommunikation

Der TI-Flow-Fachdienst MUSS sicherstellen, dass er nur transportverschlüsselt mit Komponenten außerhalb des TI-Flow-Fachdienstes kommuniziert. [<=]

Diese Anforderung gilt insbesondere für die Clientsysteme des TI-Flow-Fachdienstes (u.a. PVS, AVS, E-Rezept-FdV, NCPeH-FD, ...)

Hinweis: Für die Qualität der Transportverschlüsselung gelten die Anforderungen aus [gemSpec_Krypt].

A_29717 - TI-Flow-Fachdienst – ZETA Guard als Eingangspunkt für Clientsysteme

Der TI-Flow-Fachdienst MUSS ausschliesslich den ZETA Guard als Eingangspunkt für Anfragen von Clientsystemen an den TI-Flow-Fachdienst erlauben. [<=]

5.1.5 Speicherung Schlüsselmaterial

A_29718 - TI-Flow-Fachdienst - Speicherung Schlüsselmaterial in HSM

Der TI-Flow-Fachdienstes MUSS das private Schlüsselmaterial für kryptographische Verfahren (Entschlüsseln, Signieren) in einem HSM speichern. [<=]

Dies gilt insbesondere für die Identitäten des ZETA Guards.

A_29719 - Anbieter TI-Flow-Fachdienst - HSM der HCC-Plattform nutzen

Der Anbieter TI-Flow-Fachdienst MUSS für die Funktionen eines HSM einen Service der HCC-Plattform nutzen. [<=]

5.1.6 gematik-Logdaten zum Zwecke der gesetzlichen Kontrollpflichten der gematik

Für die Pseudonymisierung der gematik-Logdaten siehe [gemSpec_Krypt#Anomalie Erkennung].

A_29724 - TI-Flow-Fachdienst - Pseudonymisieren der gematik-Logdaten - Geheimer Schlüssel für Pseudonymisieren nur in VAU

Der TI-Flow-Fachdienst MUSS sicherstellen, dass der für das Pseudonymisieren der gematik-Logdaten benötigte geheime Schlüssel key_pn_log im Klartext ausschließlich innerhalb einer VAU-Instanz verarbeitet wird. [<=]

A_29725 - TI-Flow-Fachdienst - Pseudonymisieren der gematik-Logdaten - Möglichkeit zum Einbringen des Schlüssels im 4-Augen-Prinzip

Der TI-Flow-Fachdienst MUSS sicherstellen, dass der für das Pseudonymisieren der gematik-Logdaten benötigte geheime Schlüssel key_pn_log ausschließlich im 4-Augen-Prinzip in den TI-Flow-Fachdienst eingebracht werden kann. [<=]

Hinweis: Der geheime Schlüssel für das Pseudonymisieren der gematik-Logdaten muss nicht im VAU-HSM gespeichert werden.

A_29726 - Anbieter TI-Flow-Fachdienst - Pseudonymisieren der gematik-Logdaten - Einbringen des Schlüssels im 4-Augen-Prinzip

Der Anbieter TI-Flow-Fachdienst MUSS den für das Pseudonymisieren der gematik-Logdaten benötigten geheimen Schlüssel key_pn_log ausschließlich im 4-Augen-Prinzip in den TI-Flow-Fachdienst einbringen. [<=]

A_29727 - Anbieter TI-Flow-Fachdienst - Pseudonymisieren der gematik-Logdaten - unverzüglicher Schlüsselwechsel

Der Anbieter TI-Flow-Fachdienst MUSS den für das Pseudonymisieren der gematik-Logdaten benötigten geheimen Schlüssel key_pn_log unverzüglich nach Bereitstellung durch die gematik wechseln. [<=]

Es ist ein jährlicher Schlüsselwechsel geplant.

5.2 Integration in HCC-Plattform

Die HCC-Plattform ist in [gemSpec_HCC] beschrieben.

Der Anbieter TI-Flow-Fachdienstes übernimmt die Rolle des HCC-Dienstanbieters. Der Hersteller des TI-Flow-Fachdienstes übernimmt die Rolle HCC-Workload-Hersteller. Siehe [gemSpec_HCC#Rollen und Verantwortlichkeiten].

Der TI-Flow-Fachdienst ist in diesem Kontext ein HCC-Dienst.

Die Bereitstellung (der Komponenten) des TI-Flow-Fachdienstes erfolgt in Form von HCC-Workload-Images. Der HCC-Provider stellt dem Hersteller des HCC-Dienstes ein Template bereit. 

Der HCC-Provider stellt dem Anbieter TI-Flow-Fachdienst die HCC-Infrastruktur zum Betrieb des Dienstes bereit. Siehe [gemSpec_HCC#HCC-Provider – Bereitstellung HCC-Infrastruktur] und [gemSpec_HCC#Weitere Dienste].

Der HCC-Provider stellt dem Anbieter TI-Flow-Fachdienst einen Mandantenkontext für die Administration des Dienstes in der Cloud zur Verfügung. Siehe [gemSpec_HCC#HCC-Provider – Mandanten für HCC-Dienstanbieter].

5.3 Systemprotokolle

Der TI-Flow-Fachdienst soll Protokolldateien schreiben, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren und die Performance zu analysieren. Für diese Zwecke führt der TI-Flow-Fachdienst ein Systemprotokoll, mit dem der Anbieter des Dienstes jederzeit den Betriebszustand des Systems kontrollieren kann.

A_29728 - TI-Flow-Fachdienst - Systemprotokoll für Betriebszustand

Der TI-Flow-Fachdienst MUSS ein Systemprotokoll über durchgeführte Operationen und deren Erfolg/Misserfolg führen, um dem Anbieter des Dienstes jederzeit eine Übersicht über den aktuellen Betriebszustand zu ermöglichen. [<=]

A_29729 - TI-Flow-Fachdienst - Systemprotokoll ohne personenbezogene und ohne medizinische Daten

Der TI-Flow-Fachdienst MUSS in jedem zu tätigenden Systemprotokolleintrag alle personenbezogenen, personenbeziehbaren und medizinischen Informationen vor der Speicherung entfernen, damit vom administrativen Personal keine personenbezogenen Daten der Versicherten oder Leistungserbringer eingesehen werden können. [<=]

A_29730 - Anbieter TI-Flow-Fachdienst - Systemprotokoll Verfügbarkeit interner Logdaten

Der Anbieter TI-Flow-Fachdienst MUSS im Rahmen von Testmaßnahmen dem Testbetriebsverantwortlichen auf Anforderung die Log-Dateien des Systemprotokolls des TI-Flow-Fachdienstes übermitteln. [<=]

A_29731 - Anbieter TI-Flow-Fachdienst - Systemprotokoll Aufbewahrungsfristen

Der Anbieter TI-Flow-Fachdienst MUSS die Systemprotokolle des TI-Flow-Fachdienstes mindestens sechs Monate verfügbar halten. [<=]

Hinweis: Die Systemprotokolle können nach Ablauf der Aufbewahrungsfrist gelöscht werden.

5.4 Zertifikatsprüfung

A_29732 - TI-Flow-Fachdienst - verpflichtende Zertifikatsprüfung

Der TI-Flow-Fachdienst MUSS alle Zertifikate, die er aktiv verwendet (bspw. TLS-Verbindungsaufbau), auf Integrität und Authentizität prüfen. Falls die Prüfung kein positives Ergebnis ("gültig") liefert, so MUSS es die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.
Der TI-Flow-Fachdienst MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können. [<=]

"Ein Zertifikat aktiv verwenden" bedeutet im obigen Sinne, dass der Fachdienst einen öffentlichen Schlüssel innerhalb einer kryptographischen Operation (Signaturprüfung, Verschlüsselung, Signaturprüfung von öffentlichen (EC)DH-Schlüsseln etc.) nutzt. Erhält der Fachdienst Daten, in dem Signaturen und Zertifikate enthalten sind und behandelt es dieses als opakes Datenobjekt, ohne die Zertifikate darin gesondert zu betrachten, dann verwendet der Fachdienst diese Zertifikate im obigen Sinne passiv.

Zertifikatsprüfung von Zertifikaten der TI-PKI

Der TI-Flow-Fachdienst prüft Zertifikate der TI-PKI gemäß den Vorgaben von [gemSpec_PKI], d.h. insbesondere X.509 nonQES Zertifikate gemäß "TUC_PKI_018 Zertifikatsprüfung in der TI" und X.509 QES Zertifikate gemäß "TUC_PKI_030 QES-Zertifikatsprüfung".

Zertifikatsprüfung von Zertifikaten der Internet-PKI

Der TI-Flow-Fachdienst prüft Internet TLS Zertifikate gemäß den Vorgaben von [gemSpec_Krypt].

ToDo: Afos aus gemSpec_Krypt PT TI-Flow-FD zuweisen

5.5 ZETA Guard im TI-Flow-Fachdienst

Der ZETA Guard im TI-Flow-Fachdienst übernimmt wesentliche Sicherheitsleistungen für den Zugang von Clientsystemen zum TI-Flow-Fachdienst. 

Der ZETA Guard erfüllt folgende Aufgaben:

  • Die Policy-basierte Zugriffskontrolle stellt sicher, dass alle Zugriffe auf den TI-Flow-Fachdienst sicher und autorisiert sind, indem er kontinuierlich die Aktivitäten überwacht und analysiert.
  • Clientsystem Authentisierung Leistungserbingerinstitutionen
    • Die Authentifizierung mittels SM(C)-B erfolgt automatisch bei freigeschalteter SM(C)-B, indem der ZETA Client im Clientsystem ein ID Token erstellt und mit der SM(C)-B signiert. Dieses Token nutzt DPoP, um sicherzustellen, dass die Anfragen vom autorisierten Clientsystem stammen und Replay-Attacken verhindert werden.
  • Das Session Management für den TI-Flow-Fachdienst im ZETA Guard verwendet OAuth2, wobei Access- und Refresh-Token sicher verwaltet und bei Bedarf erneuert werden. Die Token sind durch DPoP an spezifische Clientsystem-Instanzen gebunden, um sicherzustellen, dass nur autorisierte Clientsysteme Zugriff haben. Bei abgelaufenen Sessions ist eine erneute Authentifizierung erforderlich.

Der ZETA Guard wird dem Hersteller des TI-Flow-Fachdienstes durch die gematik bereitgestellt.

Dieses Kapitel beschränkt sich folgend nur auf die ZETA Guard Komponenten mit TI-Flow-Fachdienst-spezifischen Konfigurationsanforderungen. Vorgaben zur operativen Umsetzung der folgenden Konfigurationsanforderungen sind [gemSpec_ZETA] zu entnehmen.

Tabelle 1: TAB_TI-Flow_Konfigurationsübersicht_ZETA_Guard

ZETA Guard Komponente TI-Flow-spezifische Konfigurationsanforderungen auf Anwendungsebene
Ingress und Egress nein
PEP HTTP-Proxy  ja
Authorization Server ja
PDP Datenbank nein
Policy Engine nein
Telemetrie-Daten Service ja
Notification Service tbd

Hinweis: Unabhängig von den folgenden Anforderungen muss der Hersteller des TI-Flow-Fachdienstes Konfigurationen für die Integration des ZETA Guards in die Runtime Umgebung vornehmen (bspw. für die Nutzung des Datenbankservices durch die Komponente PDP Datenbank).

A_29754 - TI-Flow-Fachdienst - Ausschließlich TLS-gesicherte Verbindungen mit Clientsystem

Der Hersteller des TI-Flow-Fachdienstes MUSS den ZETA Guard so konfigurieren, dass der ZETA Guard ausschließlich durch TLS gesicherte Verbindungen von Clientsystemen akzeptiert. [<=]

5.5.1 Konfiguration Ingress

Die Ingress Komponente bietet die Möglichkeit der Konfiguration von Ratelimits.

5.5.2 Konfiguration PEP HTTP-Proxy

Der HTTP-Proxy nimmt die Anfragen eines Clientsystems entgegen und prüft die Anfrage vor dem Weiterleiten an erlaubte Endpunkte des Resource Servers auf eine vorhandene sowie gültige Berechtigung auf Basis von DPoP- und Access-Token.

Antworten des Resource-Servers nimmt der HTTP-Proxy entgegen und leitet diese an das Clientsystem weiter.

A_29761 - TI-Flow-Fachdienst - ZETA Guard - HTTP-Proxy - ZETA/ASL für Request an Resource Server

Der Hersteller des TI-Flow-Fachdienstes MUSS den HTTP-Proxy des ZETA Guard so konfigurieren, dass der ZETA Guard von Clientsystemen nur Anfragen an den Resource Server akzeptiert, welche mittels ZETA/ASL verschlüsselt sind. [<=]

A_29762 - TI-Flow-Fachdienst - ZETA Guard - HTTP-Proxy - ASL-Kanal terminieren

Der Hersteller des TI-Flow-Fachdienstes MUSS den HTTP-Proxy des ZETA Guard so konfigurieren, dass der ASL-Kanal vom Clientsystem terminiert wird. [<=]

A_29763 - TI-Flow-Fachdienst - ZETA Guard - HTTP-Proxy - ZETA/ASL für Responses des Resource Servers

Der Hersteller des TI-Flow-Fachdienstes MUSS den HTTP-Proxy des ZETA Guard so konfigurieren, dass die Response des Resource Servers durch ZETA/ASL gesichert an das anfragende Clientsystem übertragen wird. [<=]

A_29764 - TI-Flow-Fachdienst - ZETA Guard - HTTP-Proxy - HTTP-Header zeta-client-data

Der Hersteller des TI-Flow-Fachdienstes MUSS den HTTP-Proxy des ZETA Guard so konfigurieren, dass die Informationen des HTTP-Header zeta-client-data an den Resource Server weitergeleitet wird. [<=]

5.5.3 Konfiguration Authorization-Server

A_29765 - Anbieter TI-Flow-Fachdienst - ZETA Guard - AuthZ-Server - Authentifizierung von Institutionen mit SM(C)-B

Der Anbieter TI-Flow-Fachdienst MUSS den Authorization-Server des ZETA Guard so konfigurieren, dass die Authentifizierung einer Leistungserbringerinstitution oder Kostenträger nur auf Basis einer SM(C)-B durchgeführt wird. [<=]

Die Gültigkeit des Refresh-Tokens wird mittels dem Policy Dokument-umgesetzt. Sie ist standardmäßig 24 Stunden. Dieser Standardwert kann aufgrund von Sicherheitsereignissen oder auf Basis der Sicherheitsbewertung des Clientsystems (Client-Attestation) im Betrieb mittels ZT-Policy geändert werden 

Die Gültigkeit des Access-Tokens wird mittels dem Policy-Dokument umgesetzt. Sie ist standardmäßig 5 Minuten. Dieser Standardwert kann bspw. aufgrund von Sicherheitsereignissen oder auf Basis der Sicherheitsbewertung des Clientsystems (Client-Attestation) im Betrieb mittels ZT-Policy geändert werden.

A_29766 - TI-Flow-Fachdienst - ZETA Guard - AuthZ-Server - Authentifizierung mit SM(C)-B einmal am Tag

Der Hersteller des TI-Flow-Fachdienstes MUSS den Authorization-Server so konfigurieren, dass - unabhängig von einem möglicherweise noch gültigem Refresh-Token - einmal täglich die Authentifizierung von Institutionen auf Basis einer SM(C)-B durchgeführt wird. [<=]

Hinweis: Die tägliche Authentifizierung ist ein Standardwert, der bspw. aufgrund von Sicherheitsereignissen oder auf Basis der Sicherheitsbewertung des Clientsystems (Client-Attestation) im Betrieb mittels ZT-Policy geändert werden kann. Zukünftig und bei Verfügbarkeit der TI-Flow-Fachdienst-Policy wird dieser Standardwert über die TI-Flow-Fachdienst-Policy festgelegt und nicht mehr innerhalb dieser Spezifikation. Die Authentifizierung der LEI erfolgt automatisiert über ZETA ohne deren manuelle Mitwirkung.

5.5.4 Konfiguration Telemetriedaten Service

Der TI-Flow-Fachdienst übermittelt Betriebsdaten, Selbstauskunft und Metriken zu Bestandsdaten unter Verwendung des OpenTelemetry-Frameworks an die gematik. Aus den Telemetriedaten können Informationen zur Performance, Last und Fehlersituationen, sowie Daten über den Status und Versionsständen von Clientsystemen abgeleitet werden.

Die Schnittstelle ist in [gemSpec_Perf] beschrieben.

Die Kommunikation vom TI-Flow-Fachdienst zum gematik Telemetriedaten Service und SIEM übernimmt der ZETA-Guard.

Für alle zu reportenden Aktivitäten, welche durch Clientsysteme getriggert werden und somit durch den ZETA Guard geroutet werden, erstellt der ZETA Guard den Trace und der Resource Server liefert die anwendungsspezifischen Daten im Span an den ZETA Guard.

Für den TI-Flow-Fachdienst muss die Konfiguration des OTEL Collectors (siehe Betriebshandbuch ZETA Guard) so angepasst werden, dass auch Traces zu Aktivitäten, welche durch den Resource Server gegenüber Backendsystem getriggert werden, weitergeleitet werden.

5.5.5 Konfiguration Notification Service

Hinweis: Der TI-Flow-Fachdienst unterstützt Push Notifications für Frontends der Versicherten. Mit der Verfügbarkeit der Funktionalität im ZETA Guard erfolgt die Verwaltung der App-Registrierungen und Channels im ZETA Guard und nicht mehr im Resource Server. Die Spezifikation wird entsprechend angepasst. Der Notification Service ist ggf. für das Zusammenwirken mit dem Resource Server zu konfigurieren.

5.6 Exporter

Der TI-Flow-Fachdienst unterstützt eine asynchrone Übermittlung von Daten an Drittsysteme (bspw. ePA Medication Service und BfArM Webservice). Die dafür eingesetzte Exporter Komponente nutzt eine Queue für Übermittlungsaufträge inclusive eines Mechanismus für nicht abarbeitbare Aufträge (Dead Letter Queue (DLQ)). 

A_29767 - TI-Flow-Fachdienst – Asynchrone Übermittung an Backendsysteme (Exporter)

Der TI-Flow-Fachdienst MUSS es ermöglichen, Daten zu Backendsystemen asynchron zum initiierenden Operationsaufruf eines Clientsystems zu übermitteln. [<=]

A_29768 - TI-Flow-Fachdienst – Exporter - Wiederholte Übermittung an Backendsysteme (Retry)

Der TI-Flow-Fachdienst MUSS es ermöglichen, dass bei Nichtverfügbarkeit des Zielsystems oder Fehler bei der Übertragung der Daten, die Daten nach einem definierten und konfigurierbaren Verhalten erneut gesendet werden können. [<=]

A_29769 - TI-Flow-Fachdienst – Exporter - Dead Letter Quque

Das TI-Flow-Fachdienst MUSS es ermöglichen, dass im Falle von wiederholten nicht-erfolgreichen Übermittlungsversuchen die Übermittlung pausiert wird. [<=]

A_29770 - Anbieter TI-Flow-Fachdienst – Exporter - Dead Letter Quque bereinigen

Der Anbieter TI-Flow-Fachdienst MUSS es in Absprache mit der gematik ermöglichen, pausierte Übermittlungsaufträge zu löschen. [<=]

5.7 Vertrauenswürdige Uhrzeit im TI-Flow-Fachdienst

Der TI-Flow-FD erstellt Signaturen für Abrechnungsinformationen und prüft den Zeitstempel des PoPP-Token. Für das Erstellen der Signatur und das Prüfen der Gültigkeit des PoPP-Token ist es notwendig, mit einer vertrauenswürdigen Uhrzeit zu arbeiten.

A_29734 - TI-Flow-Fachdienst - Vertrauenswürdige Uhrzeit

Der TI-Flow-Fachdienst MUSS seine lokale Systemzeit mindestens einmal täglich mit einem qualifizierten Zeitstempel eines eIDAS-Vertrauensdiensteanbieters synchronisieren, um sicherzustellen, dass die lokale, mittels ntp synchronisierte Systemzeit nie mehr als 10 Sekunden vom Wert des aktuell eingeholten qualifizierten Zeitstempels abweicht. [<=]

A_29735 - Anbieter TI-Flow-Fachdienst - Vertrauenswürdige Uhrzeit

Der Anbieter TI-Flow-Fachdienst MUSS, wenn die Systemzeit mehr als 10 Sekunden vom Wert des aktuell eingeholten qualifizierten Zeitstempels abweicht, einen Security Incident entsprechend [TI-SEC-Standard] eröffnen. [<=]

Hinweis: Die Bundesnetzagentur listet unter [AnbieterVZeitD] verschiedene Anbieter für qualifizierte Zeitstempel.

5.8 FHIR Validierung im TI-Flow-Fachdienst

Der TI-Flow-FD muss als zentraler Dienst für FHIR Artefakte in der TI eine umfassende Validierung der eingehenden FHIR-Ressourcen vornehmen, um die Weiterverarbeitung in Systemen auch außerhalb der TI sicherzustellen. Weiterhin ist auch die Unterstützung von Clients im Übergang zwischen verschiedenen Versionen von FHIR-Artefakten ein wesentlicher Aspekt. 

Die gematik veröffentlicht und maintained den [gematik Referenzvalidator]. Dieser ist eine Erweiterung des [HL7 Java Validator]. Der Referenzvalidator liefert autoritative Antworten zur Validität von übertragenen Datensätzen und ist somit eine Referenz für im Rahmen einer TI-Anwendung eingesetzten FHIR-Validatoren.

Der Referenzvalidator ist konfigurierbar und mit verschiedenen FHIR-Paketen ausführbar.  Die FHIR-Pakete für die Anwendung TI-Flow werden dem Hersteller des TI-Flow-FD durch die gematik bereitgestellt.

Der TI-Flow-FD muss für eine korrekte Aussage zur Validität von FHIR Artefakten sicherstellen, dass die Ausgaben der Validierung des FD exakt derer des gematik Referenzvalidators entsprechen. Es ist dem Anbieter des TI-Flow-FD freigestellt, ob dafür der Referenzvalidator eingebettet oder ein proprietärer Validator genutzt wird. Falls ein proprietärer Validator genutzt wird, muss der die gleichen Validierungsergebnisse wie der gematik Referenzvalidator liefern.

Für die weitere Beschreibung wird der Begriff "Validierungskomponente des TI-Flow-Fachdienst" eingeführt, die als eigenständiges Modul innerhalb des TI-Flow-Fachdienstes betrachtet wird.

5.8.1 Validierung bei Versionsübergängen

Im Verlauf der Weiterentwicklung von Anwendungsfällen kommt es fachlich oder technisch motiviert zu neuen Versionen von FHIR-Packages, welche durch den TI-Flow-FD verarbeitet werden. Den Clientsystemen des TI-Flow-FD werden für die Umsetzung von Major und Minor Updates von FHIR-Packages "Übergangszeiten" angeboten, in denen mehrere Versionen eines FHIR-Profils gültig sind. Der TI-Flow-FD muss für eine performante und flexible Realisierung dieser Übergänge, Validierungen gegen mehrere Versionen eines Profils gleichzeitig unterstützen.

5.8.2 Architektur der Validierungskomponente

Der TI-Flow-Fachdienst betreibt die FHIR-Validierung als eigenständiges, containerisiertes Modul. Die Architektur trennt zwischen dem unveränderlichen Validierungskern (CoreImage) und dem konfigurationsgebundenen Einsatzartefakt (ValidatorImage).

Der Hersteller des TI-Flow-Fachdienstes stellt das CoreImage bereit. Dieses CoreImage kann in Kombination mit einer FHIR-Konfiguration, die durch die gematik bereitgestellt wird, dann das ValidatorImage erzeugen. Die FHIR-Konfiguration bildet dabei die Kombination aus zulässigen Versionen von FHIR-Packages im Validierungskontext in einem Zeitraum ab. Als Beispiel dient API-ERP: FHIR-Transition.

Abbildung 2: Entstehung FHIR-ValidatorImage für TI-Flow-Fachdienst

Ein ValidatorImage wird in einer Pipeline aus der Kombination des CoreImage mit einer FHIR-Konfiguration erzeugt. Ein erzeugtes ValidatorImage ist in der Lage eine FHIR-Konfiguration zu validieren.

Der TI-Flow-Fachdienst muss für die Realisierung der Übergangszeiten in der Lage sein mehrere verschiedene ValidatorImages gleichzeitig im Betrieb zu nutzen.

Damit das ValidatorImage frühzeitig für die Entwicklungsbegleitung der Industrie bereitgestellt werden kann, muss es möglich sein das ValidatorImage nach Abschluss der Spezifikation und Erstellung eines FHIR-Packages zu erzeugen und zu veröffentlichen.

A_29821 - TI-Flow-Fachdienst - Validierungskomponente - Bereitstellung als OCI-Container

Der Hersteller des TI-Flow-Fachdienstes MUSS die Validierungskomponente als OCI-konformes Container-Image bereitstellen, das in einer Container-Laufzeitumgebung (z.B. Kubernetes, Docker) deploybar ist. [<=]

Ein FHIR-Package kann ValueSets enthalten, welche Inhalte (Filter) definieren, die aus externen Quellen, bspw. Terminologieservern bezogen werden müssen. Das ValidatorImage muss offline in der Lage sein auch diese Terminologien zu validieren.  

A_29822 - TI-Flow-Fachdienst - Validierungskomponente - Offline-Fähigkeit des ValidatorImage

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS zur Build-Zeit des ValidatorImage alle notwendigen FHIR-Packages, Terminologien (ValueSets, CodeSystems) und Validierungsregeln herunterladen, alle referenzierten ValueSets gegen einen konfigurierten Terminologieserver expandieren und die expandierten Terminologieartefakte im Image persistieren. [<=]

A_29823 - TI-Flow-Fachdienst - Validierungskomponente - Verbindungen des ValidatorImage zur Lauf-Zeit

Die Validierungskomponente des TI-Flow-Fachdienstes DARF NICHT erlauben, dass das Image zur Laufzeit ausgehenden Verbindungen zu externen Paket-Registries oder Terminologie-Servern aufbaut.
[<=]

A_29824 - TI-Flow-Fachdienst - Validierungskomponente - Snapshot Generierung zur Build-Zeit

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS in der Lage sein, zur Build-Zeit des ValidatorImage Snapshots aus FHIR-Packages zu generieren, um diese für die Validierung zu nutzen. [<=]

A_29825 - TI-Flow-Fachdienst - Validierungskomponente - Bereitstellen von Snapshots zur Build-Zeit

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS in der Lage sein, zur Build-Zeit des ValidatorImage Snapshots als packetierte Datei bereitzustellen, um den erzeugten Validierungskontext nachprüfbar zu machen. [<=]

Das ValidatorImage stellt eine REST-API zur Verfügung.

Der Hersteller des TI-Flow-Fachdienstes kann entscheiden, ob die Validierungskomponente für das Deployment des TI-Flow-Fachdienstes via REST-Schnittstelle oder über ein internes Protokoll angesprochen wird. 

A_29826 - TI-Flow-Fachdienst - Validierungskomponente - Wahlfreiheit der Integrationstiefe

Der Hersteller des TI-Flow-Fachdienstes KANN die Validierungskomponente des TI-Flow-Fachdienstes über die bereitgestellte REST-API in den TI-Flow-Fachdienst einbinden oder die Validierungslogik tiefer in den Fachdienst integrieren (z.B. als eingebettete Bibliothek im selben Prozess). [<=]

A_29827 - TI-Flow-Fachdienst - Validierungskomponente - Erweiterbarkeit des CoreImage

Der Hersteller des TI-Flow-Fachdienstes MUSS das CoreImage der Validierungskomponente des TI-Flow-Fachdienstes so entwerfen, dass es durch Konfiguration oder durch definierte Erweiterungsschnittstellen um weitere Validierungsmodule ergänzt werden kann (z.B. für CDA-Dokumente oder PDF/A-Validierung), ohne die bestehende FHIR-Validierungslogik zu verändern. [<=]

A_29828 - TI-Flow-Fachdienst - Validierungskomponente - Validierungsergebnisse wie gematik Referenzvalidator

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS die gleichen Funktionalitäten der Validierung wie der gematik Referenzvalidator bereitstellen, damit sichergestellt ist, dass das Validierungsergebnis identisch ist. [<=]

5.8.3 Konfiguration der Validierungskomponente des TI-Flow-Fachdienst

Wie in der Architektur der Validierungskomponente beschrieben, muss die Validierungskomponente des TI-Flow-Fachdienstes konfigurierbar sein.

A_29829 - TI-Flow-Fachdienst - Validierungskomponente - Ausgabe der Konfiguration

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS die im ValidatorImage umgesetzte Konfiguration über die REST-Schnittstelle /fhir-configuration ausgeben. [<=]

A_29830 - TI-Flow-Fachdienst - Validierungskomponente - FHIR-Package-basierte Konfiguration

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS für die Ausgabe der Konfiguration mindestens die folgenden Angaben enthalten:

  • Eine Auflistung von FHIR-Konfigurationen:
    • Zeitlich begrenzte Gültigkeit einer FHIR-Konfiguration
    • Name und Version eines FHIR-Packages
  • Optionale Validierungsparameter (z.B. Aktivierung/Deaktivierung von Terminologie-Validierung)
[<=]

A_29831 - TI-Flow-Fachdienst - Validierungskomponente - Validierung der Konfiguration von FHIR-Packages

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS in der Lage sein, zur Build-Zeit die bereitgestellte Konfiguration auf Plausibilität und Konsistenz hin zu prüfen und bei negativen Bescheid den Build-Prozess abbrechen. [<=]

A_29832 - TI-Flow-Fachdienst - Validierungskomponente - Konfiguration von FHIR-Packages

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS in der Lage sein, zur Build-Zeit eine Konfiguration von FHIR-Packages mit definierter Gültigkeit zu konsumieren und für die Validierung zu nutzen. [<=]

Als fachliche Anforderung ist es notwendig, dass für einzelne Profile ein Datum (bspw. MedicationRequest.authoredOn) als zeitliche Referenz ausgewählt werden kann, wonach eine Zuordnung zu einer FHIR-Profilversion erfolgt. 

A_29833 - TI-Flow-Fachdienst - Validierungskomponente - Konfiguration von datumsbezogenen Parametern

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS in der Lage sein für ein Datumsfeld mit Datentypen date, dateTime oder instant eines FHIR-Profils die zeitliche Gültigkeit zu konfigurieren und für die Validierung zu verwenden. [<=]

A_29845 - TI-Flow-Fachdienst - Validierungskomponente - Validierung von datumsbezogenen Parametern

Die Validierungskompopnente des TI-Flow-Fachdienstes MUSS in der Lage sein konfigurierte Datumsfelder entsprechend der in der FHIR-Konfiguration angegebenen Datumsgrenzen zu validieren. [<=]

A_29834 - TI-Flow-Fachdienst - Validierungskomponente - Reproduzierbarkeit des Build-Prozesses

Der Hersteller des TI-Flow-Fachdienstes MUSS einen dokumentierten Build-Prozess für die Validierungskomponente des TI-Flow-Fachdienstes bereitstellen, durch den die gematik aus einer Konfigurationsdatei und dem CoreImage eigenständig ein ValidatorImage erzeugen kann. [<=]

A_29835 - TI-Flow-Fachdienst - Validierungskomponente - Terminologieserver-Konfiguration im Build-Prozess

Der Hersteller des TI-Flow-Fachdienstes MUSS sicherstellen, dass der Build-Prozess für die Validierungskomponente des TI-Flow-Fachdienstes einen konfigurierbaren Terminologieserver-Endpunkt unterstützt, gegen den alle in den FHIR-Packages referenzierten ValueSets und CodeSystems während des Builds expandiert werden. [<=]

A_29836 - TI-Flow-Fachdienst - Validierungskomponente - Dokumentation Terminologieserver-Expansion im Build-Prozess

Der Hersteller des TI-Flow-Fachdienstes MUSS sicherstellen, dass der Build-Prozess für die Validierungskomponente des TI-Flow-Fachdienstes das Ergebnis der Terminologie-Expansion versioniert und im ValidatorImage eingefroren abrufbar macht, sodass spätere Builds mit demselben Terminologieserver und denselben Packages zu identischen Validierungsergebnissen führen. [<=]

A_29837 - TI-Flow-Fachdienst - Validierungskomponente - Bereitstellung eines ValidatorImage bei Profilveröffentlichung

Der Hersteller des TI-Flow-Fachdienstes MUSS den Build-Mechanismus der Validierungskomponente des TI-Flow-Fachdienstes so gestalten, dass die gematik zum Zeitpunkt der Veröffentlichung einer neuen FHIR-Package-Version eigenständig und ohne Mitwirkung des Anbieters ein ValidatorImage erzeugen und bereitstellen kann, das funktional identisch mit dem ValidatorImage der Produktivumgebung sein wird. [<=]

5.8.4 REST-Schnittstelle der Validierungskomponente des TI-Flow-Fachdienst

A_29838 - TI-Flow-Fachdienst - Validierungskomponente - FHIR-$validate-Operation

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS eine $validate-Operation bereitstellen. [<=]

ToDo: OperationDefinition im FHIR-IG erstellen und verlinken

A_29839 - TI-Flow-Fachdienst - Validierungskomponente - Fehlerausgabe bei Validierung

Die Validierungskomponente des TI-Flow-Fachdienstes MUSS im Fehlerfall der Validierungsoperation das Ergebnis als FHIR OperationOutcome-Ressource zurückgeben. [<=]

A_29840 - TI-Flow-Fachdienst - Validierungskomponente - Fehlerausgabe ohne Nutzdaten

Die Validierungskomponente des TI-Flow-Fachdienstes DARF im Fehlerfall der Validierungsoperation Fehlermeldungen im OperationOutcome NICHT Inhalte der validierten Ressource (z.B. Patientenname, Versicherungsnummer, Medikamentenbezeichnung) in Fehlermeldungen zurückgeben. [<=]

A_29841 - TI-Flow-Fachdienst - Keine FHIR-$validate-Operation

Der TI-Flow-Fachdienst DARF NICHT die $validate-Operation gegenüber Clientsystemen exponieren. [<=]

5.9 Konfiguration von Fachdienst-Instanzen

Der TI-Flow-Fachdienst unterstützt verschiedene Workflows. Er wird kontinuierlich weiterentwickelt und um neue Workflows ergänzt. Um Pilotierungsphasen eines Workflows zu begleiten und Entwicklungsumgebungen gezielt zu konfigurieren, muss der TI-Flow-Fachdienst in der Lage sein, Workflows und Features per Deployment-Konfiguration zu steuern. Damit ist es möglich, Funktionalität bereits im Code auszuliefern, ohne dass diese in der entsprechenden Umgebung aktiv ist. Dies ermöglicht eine bessere Release-Steuerung.

Die Konfiguration umfasst drei Bereiche: die Steuerung der Operationalisierung einzelner Flowtypes, die Steuerung der Verfügbarkeit von Features sowie die Festlegung des Referenzzeitpunkts für die FHIR-Validierung. Die jeweils aktive Konfiguration einer Instanz wird im CapabilityStatement des TI-Flow-Fachdienstes ausgegeben, sodass Clientsysteme die Konfiguration abrufen und ihr Verhalten entsprechend anpassen können.

Die konkrete Darstellung und Ausgabe von Konfigurationsparametern im CapabilityStatement, sowie die Struktur der Daten im Fehlerfall wird im FHIR-IG beschrieben.

A_29771 - TI-Flow-Fachdienst - Konfiguration je Instanz

Der TI-Flow-Fachdienst MUSS für jede Betriebsumgebung eine Konfiguration unterstützen und anwenden. [<=]

A_29772 - Anbieter TI-Flow-Fachdienst - Abstimmung zur Konfiguration

Der Anbieter TI-Flow-Fachdienst MUSS die Konfigurationen der Instanzen in Abstimmung mit der gematik umsetzen. [<=]


5.9.1 Konfiguration von Flowtypes

Die Operationalisierung einzelner Flowtypes kann per Konfiguration gesteuert werden. Das Deaktivieren eines Flowtypes verhindert den Abruf neuer Task-IDs für den entsprechenden Flowtype über die $create-Operation. Bereits erzeugte Tasks mit einem deaktivierten Flowtype bleiben vollständig bearbeitbar, um die Versorgung sicherzustellen. Grundlage für die möglichen Konfigurationsparameter ist das CodeSystem (CS) der Flowtypes. Mit der Definition neuer Flowtypes im Codesystem wird die Menge der konfigurierbaren Parameter automatisch erweitert.

Anforderungen und Spezifikationen hierzu sind im Implementation Guide TIFlow - Kernfunktionalitäten zu finden.

5.9.2 Konfiguration von Features

Neben Flowtypes können auch Features konfiguriert werden, die nicht über einen Flowtype abbildbar sind (bspw. Einlösen von E-Rezepten im europäischen Ausland oder der Übertrag des digitalen Durchschlags für T-Rezepte an den BfArM-Webservice). Features werden im FHIR-IG beschrieben und müssen bei der Konzeption so abgekapselt werden, dass eine Deaktivierung technisch umsetzbar ist. Das Deaktivieren eines Features verhindert die Ausführung der zugehörigen Operationsaufrufe bzw. Prozessschritte.

Die Definition eines Features wird im jeweiligen FHIR-IG beschrieben und als FeatureDefinition Ressource bereitgestellt.

5.9.3 Konfiguration des Referenzzeitpunkts für die FHIR-Validierung

Der TI-Flow-Fachdienst verwendet für die FHIR-Validierung jeweils eine definierte Kombination aus FHIR-Packages (FHIR-Konfiguration). Da der TI-Flow-Fachdienst auch externe FHIR-Pakete (bspw. kbv.ita.erp) unterstützt, die sich außerhalb des IG-Release-Zyklus ändern können, publiziert die gematik die FHIR-Konfigurationen außerhalb des FHIR-IGs (bspw. auf GitHub oder [RUAAS]). In einer Instanz ist jeweils genau eine FHIR-Konfiguration aktiv. Der Bezeichner der aktiven Konfiguration wird im CapabilityStatement ausgegeben (bspw. "fhir_config": "tif_fhir_2028_01").

Zur Unterstützung von Testumgebungen existiert ein optionaler Konfigurationsparameter, der einen zeitlichen Versatz (Offset) des Referenzzeitpunkts für die FHIR-Validierung ermöglicht. Dieser Parameter darf ausschließlich in Test- und Referenzumgebungen gesetzt werden und erlaubt es, eine vorgelagerte FHIR-Validierung zu erzielen, ohne andere Systemkomponenten anpassen zu müssen. In der Produktivumgebung darf dieser Parameter nicht gesetzt sein.

A_29773 - Anbieter TI-Flow-Fachdienst - Übernahme der FHIR-Konfiguration

Der Anbieter TI-Flow-Fachdienst MUSS die von der gematik veröffentlichte FHIR-Konfiguration übernehmen und im TI-Flow-Fachdienst bereitstellen. [<=]

Ein Beispiel für eine FHIR Konfiguration kann in der API-ERP angesehen werden: https://github.com/gematik/api-erp/blob/master/resources/configuration/2026-07-01_fhir-transition.json 

6 Anhang – Verzeichnisse

6.1 Abkürzungen

Kürzel
Erläuterung
CVM Convidential virtual machine
eGK elektronische Gesundheitskarte
FD Fachdienst
HCC Healthcare Confidential Computing
KVNR Krankenversichertennummer
NCPeH National Contact Point for eHealth
PKI Private key infrastructure
PoPP Proof of Patient Presence
PU Produktivumgebung
RU Referenzumgebung
TI Telematikinfrastruktur
TU Testumgebung
VAU vertrauenswürdige Ausführungsumgebung
ZETA Zero trust access

6.2 Glossar

Begriff
Erläuterung
Funktionsmerkmal
Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems.
Versicherten-ID 10-stelliger unveränderlicher Teil der Krankenversichertennummer (KVNR)

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.

[Quelle]
Herausgeber: Titel
[gemAnbT_TI-Flow-FD] gematik: Anbietertypsteckbrief TI-Flow-Fachdienst
[gemGlossar] gematik: Einführung der Gesundheitskarte – Glossar
[gemProdT_TI-Flow-FD] gematik: Produkttypsteckbrief TI-Flow-Fachdienst
[gemSpec_HCC] gematik: Spezifikation Healthcare Confidential Computing (HCC)
[gemSpec_Krypt] gematik: Übergreifende Spezifikation Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur
[gemSpec_Perf] gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform
[gemSpec_PKI] gematik: Übergreifende Spezifikation PKI
[gemSpec_ZETA] gematik: Spezifikation Zero Trust Access (ZETA)
[gematik Referenzvalidator] gematik: https://github.com/gematik/app-referencevalidator 

6.5.2 Weitere Dokumente

[Quelle]
Herausgeber (Erscheinungsdatum): Titel
[AnbieterVZeitD] Die Bundesnetzagentur listet unter https://www.elektronische-vertrauensdienste.de/EVD/DE/Uebersicht_eVD/Dienste/5_Zeitstempel.html?nn=691392 verschiedene Anbieter für qualifizierte Zeitstempel.
[HL7 Java Validator] https://github.com/hapifhir/org.hl7.fhir.core 

7 Anhang - Weitere Spezifikationen

In diesem Anhang können Anteile erfasst werden, welche später in übergreifende Dokumente übernommen werden.

7.1 gemSpec_Krypt

7.1.1 TI-Flow-spezifische TLS-Vorgaben (Internet PKI)

Der TI-Flow-Fachdienst tritt in verschiedenen Datenverbindungen (bspw. zum BfArM-Webservice) als TLS-Client auf.

Wenn der TI-Flow-Fachdienst als TLS-Server auftritt gelten die Zero-Trust Zeta Guard spezifischen TLS-Anforderungen.

A_29774 - TLS-Client, TLS-Versionen

Ein Produkttyp MUSS in der Rolle TLS-Client die TLS-Version 1.2 [RFC-52469] und die TLS-Version 1.3 [RFC-8446] unterstützen. [<=]

A_29775 - TLS-Client, TLS-Version 1.2

Ein Produkttyp MUSS, wenn er in der Rolle TLS-Client die TLS-Version 1.2 [RFC-52469] verwendet, folgende Vorgaben umsetzen:

  1. Er MUSS mindestens folgende Ciphersuiten unterstützen
    1. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x2C),
    2. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2B),
    3. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2F),
    4. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x30).
  2. Er KANN weitere Cipher-Suiten aus [TR-02102-2, Abschnitt 3.3.3.1 Tabelle 3] unterstützen. 
  3. Er MUSS Domainparameter (Schlüssellängen, ECC-Kurven) aus [TR-02102-2, Abschnitt 3.6] erwenden.
[<=]

A_29776 - TLS-Client, TLS-Version 1.3

Ein Produkttyp MUSS, wenn er in der Rolle TLS-Client die TLS-Version 1.3 [RFC-8446] verwendet, folgende Vorgaben umsetzen:

  1. Er MUSS mindestens die Ciphersuite
    TLS_AES_128_GCM_SHA256
    unterstützen [RFC-8446#9.1].
  2. Er MUSS Domainparameter (Schlüssellängen, ECC-Kurven) aus [TR-02102-2, Abschnitt 3.6] verwenden.
[<=]

Folgende Anforderungen an den E-Rezept-Fachdienst werden um den TI-Flow-Fachdienst erweitert:

A_27855-03 - E-Rezept: Zugriff auf Webdienste - Webzertifikat aus Internet PKI

Der E-Rezept-Fachdienst und der TI-Flow-Fachdienst MÜSSEN bei Aufbau einer HTTPS-Verbindung zu Diensten im Internet sicherstellen, dass das zu prüfende Zertifikat auf ein CA-Zertifikat der [CA/B Forum] Baseline Requirements per Signaturkette kryptographisch rückführbar ist. [<=]

A_27856-02 - E-Rezept: Zugriff auf Webdienste - Hostname-Prüfung für TLS-Server-Zertifikat durchführen

Der E-Rezept-Fachdienst und der TI-Flow-Fachdienst MÜSSEN bei Aufbau einer HTTPS-Verbindung zu Diensten im Internet sicherstellen, dass der angesprochene Hostname mit dem im X.509-Zertifikat des Ziel-Webdienstes angegebenen Common Name (CN) oder den Subject Alternative Names (SANs) gemäß RFC 6125 übereinstimmt und bei Nichtübereinstimmung den Verbindungsaufbau abbrechen. [<=]

A_27857-02 - E-Rezept: Zugriff auf Webdienste - Sperrprüfung für TLS-Server-Zertifikat durchführen

Der E-Rezept-Fachdienst und der TI-Flow-Fachdienst MÜSSEN vor Nutzung des BfArM Webdienstes im Internet gemäß RFC 5280 prüfen, ob das präsentierte TLS-Serverzertifikat gesperrt wurde (z. B. mittels OCSP oder CRL) und im Fall einer Sperrung oder bei nicht durchführbarer Sperrprüfung die Verbindung abbrechen. [<=]

7.1.2 Datenpersistierung

Bei der Verarbeitung von medizinischen Daten im TI-Flow-Fachdienste müssen Daten für einen begrenzte Zeitspanne persistiert werden. Die maximale Länge der Zeitspanne hängt von medizinischen Objekt ab, und beträgt bspw. bei einem E-Rezept drei Monate. Es gibt auch Daten im TI-Flow-Fachdienst, die eine VAU länger als drei Monate persistieren können muss.

Die folgend definierten Anforderungen zur Datenpersistierung werden zukünftig nicht nur vom TI-Flow-Fachdienst verwendet, und werden deshalb in einer übergreifenden Spezifikation [gemSpec_Krypt] aufgeführt.

offener Punkt: Die Anforderung zur Datenpersistierung sind gematik-intern noch in der Abstimmung.

Die Datenpersistierung wird sich an den bestehenden Mechanismen im ePA-Aktensystem (VAU) und E-Rezept-Fachdienst (VAU) orientieren. Dort gibt es Masterkeys in den VAU-HSM, die regelmäßig gewechselt werden. Die Masterkeys sind Grundlage von Schlüsselableitung je Aufgaben-Kontext. Die je nach Aufgaben-Kontext abgeleiteten Schlüssel dient als Schlüssel für einen authentisierte Verschlüsselung der medizinischen Daten. Die entstehende Chiffrate werden außerhalb der VAU persitiert. Der Wechsel eines Masterkeys kann zu einer Umschlüsselung bei Daten die deutlich länger persitiert werden müssen als der Wechselzyklus, der Masterkeys lang ist, führen.

7.1.3 Nutzerpseudonyme

A_28578-01 - Pseudonymisierung bei den Telemetriedaten (Anomalie-Erkennung)

Ein Produkttyp MUSS bei der Pseudonymisierung von Daten im Kontext der Übermittlung von zu pseudonymisierenden Telemetriedaten folgende Vorgaben umsetzen:

  1. Der Produkttyp MUSS ein von der gematik/CDC bereitgestelltes Verschlüsselungszertifikat, integritäts- und authentitätsgeschützt in der VAU einpflegen (Initialisierung des Fachdienstes). (Hinweis: Das Verschlüsselungszertifikat ist ECC-basiert, d. h. auch der EE-Schlüssel ist ein ECC-Schlüssel.)
  2. Der Produkttyp MUSS auf Anweisung der gematik/CDC dieses Verschlüsselungszertifikat innerhalb von 5 Werktagen wechseln können. (Kontext: Regelmäßiger Wechsel des Verschlüsselungszertifikats)
  3. Sei P die zu pseudonymisierende Zeichenkette. Der Produkttyp MUSS am Ende von P solange Leerzeichen anfügen bis die Länge der somit erzeugten Zeichenkette ein Vielfaches von 32 ist. Sei Padding-Länge die Anzahl der hinzugefügten Leerzeichen. Diese Padding-Länge wird als Byte kodiert (Beispiel: Padding-Länge 0 würde als \x00 Byte kodiert) und der erzeugten Zeichenkette vorangestellt. Das Ergebnis wird als Plaintext bezeichnet.
  4. Der Produkttyp MUSS diesen Plaintext mittels ECIES (AES/GCM) unter Verwendung des öffentlichen Verschlüsselungsschlüssels aus dem Verschlüsselungszertifikat aus Punkt 1 (bzw. 2) verschlüsseln.
    1. Der Produkttyp MUSS dabei ein ephemeres ECDH-Schlüsselpaar zufällig erzeugen und mit diesem und dem öffentlichen Schlüssel aus dem Verschlüsselungszertifikat ein ECDH gemäß [NIST-800-56-A] durchführen. Das somit erzeugte gemeinsame Geheimnis ist Grundlage für die folgende Schlüsselableitung.
    2. Der Produkttyp MUSS als Schlüsselableitungsfunktion die HKDF nach [RFC-5869] auf Basis von SHA-256 verwenden.
    3. Der Produkttyp MUSS dabei den Ableitungsvektor "ecies-cdc-p17" verwenden, d. h. in der Formulierung von [RFC-5869] info="ecies-cdc-p17".
    4. Der Produkttyp MUSS mit dieser Schlüsselableitung einen AES-128-Bit Content-Encryption-Key (CEK) für die Verwendung von AES/GCM ableiten.
    5. Der Produkttyp MUSS für die Verschlüsselung mittels AES/GCM einen 96 Bit langen Null-Vektor (0…0) als Initialisierungsvektor (IV) verwenden.
    6. Der Produkttyp MUSS mit dem CEK und dem IV mittels AES/GCM den Plaintext verschlüsseln, wobei dabei ein 128 Bit langer Authentication-Tag zu verwenden ist.
    7. Der Produkttyp MUSS aus dem Verschlüsselungszertifikat den SubjectKeyIdentifier (SKI) entnehmen und die ersten 16 Bit als „gekürzter SKI“ im folgenden Schritt verwenden.
    8. Der Produkttyp MUSS das Ergebnis wie folgt kodieren: chr(0x02) || <gekürzter SKI> || <32 Byte X-Koordinate des öffentlichen Schlüssels aus (a) > || <AES-GCM-Chiffrat> || <16 Byte AuthenticationTag>. (Hinweis: es fehlt absichtlich die Y-Koordinate und der IV).
    9. Die X-Koordinate ist (wie üblich) vorne mit chr(0) zu padden solange bis sie eine Kodierungslänge von 32 Byte erreicht. Die Byte-Order MUSS Network-Byte-Order (= Big) sein.
    10. Das so kodierte Ergebnis wird als erweitertes Chiffrat bezeichnet.
  5. Der Produkttyp MUSS das erweiterte Chiffrat mittels Base64 kodieren. Das Ergebnis ist ein Pseudonym von P (vgl. Punkt 3)
[<=]

Welche anwendungsspezifischen Telemetriedaten pseudonymisiert übermittelt werden müssen, ist in [gemSpec_Perf] beschrieben.

A_29779 - Wechsel von Nutzerpseudonymen

Ein Produkttyp MUSS, wenn er Pseudonyme von Identitäten natürlicher oder juristischer Personen (Nutzerpseudonym) bildet, sicherstellen, – sofern dies nicht für konkrete Pseudonyme durch andere Anforderungen geregelt ist - dass ein Nutzerpseudonym nach maximal 12 Monaten gewechselt wird, dass zwei aufeinander folgende Nutzerpseudonyme für eine Identität unterschiedlich sind und die Kenntnis der Pseudonyme keine Rückschlüsse auf die Identität zulässt. [<=]

Hinweis: Diese Anforderung ist bezüglich des Empfängers generisch formuliert und wird perspektivisch auch für andere Produkttypen verwendet.

7.2 gemSpec_Perf

7.2.1 3.x TI-Flow-Fachdienst

7.2.1.1 3.x.1 Leistungsanforderungen TI-Flow-Fachdienst (E-Rezept)
7.2.1.1.1 3.x.1.1 Lastmodell E-Rezept

Die Anwendungsfälle zum E-Rezept setzen die Workflows zur Verordnung von apothekenpflichtigen Arzneimitteln um. Dabei werden die folgenden performance-relevanten Anwendungsfälle gemäß [IG] betrachtet:

Offener Punkt: Es wird eine Statistik des aktuellen Lastverhaltens des E-Rezept-Fachdienstes ergänzt.

7.2.1.1.2 3.x.1.2 Bearbeitungszeiten E-Rezept

Für das E-Rezept müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_TI-Flow Bearbeitungszeitvorgaben je Anwendungsfall" angegebenen Mittelwerten sein.

Tabelle 2: Tab_TI-Flow Bearbeitungszeitvorgaben je Anwendungsfall

ID
Anwendungsfall
Datenmenge
[KB]
Mittelwert
[sec]
ERP.UC_2_1
E-Rezept durch Verordnenden erzeugen
10
4,2
ERP.UC_2_3
E-Rezept durch Verordnenden einstellen
10
1,4
ERP.UC_3_1 Nachrichten durch Abgebenden übermitteln/empfangen 10 1,3
ERP.UC_3_3 Nachrichten durch Versicherten übermitteln/empfangen 10 1,3
ERP.UC_3_7 Abrechnungsinformationen durch den Versicherten abrufen 20 1,5
ERP.UC_4_1
E-Rezept durch Abgebenden abrufen
10
3,1
ERP.UC_4_4 E-Rezept durch Versicherten abrufen 10 2,5
ERP.UC_4_7
Abgabe durch Abgebenden vollziehen
10
1,3
ERP.UC_4_10 Abrechnungsinformationen durch Abgebenden abrufen 10 1,5
ERP.UC_4_11 Abrechnungsinformationen durch Abgebenden bereitstellen 10 1,4
ERP.UC_4_15 E-Rezepte vom Versicherten durch Abgebenden abrufen (PoPP) 10 4
ERP.UC_4_16 Dispensierinformationen durch Abgebenden bereitstellen 10 2,5

Die ID aus der Tabelle "Tab_TI-Flow Bearbeitungszeitvorgaben je Anwendungsfall" referenziert auf die entsprechenden Anwendungsfälle gemäß der Implementation Guides TI-Flow.

Die erhöhte Bearbeitungszeit bei dem Anwendungsfall zum Erstellen einer Verordnung beim Verordnenden sind daraus zu begründen, dass hier die Konnektor-Operationen für das QES-Signieren von 10 KB-Dokumenten enthalten sind.

Ebenfalls ist die erhöhte Bearbeitungszeit daraus zu begründen, dass ist in der Modellbetrachtung von einer Transportanbindung von 1024 kbit/sec in Download-Richtung und 128 kbit/sec in Upload-Richtung für die Leistungserbringer-Umgebung sowie für die des Versicherten ausgegangen wird.

Hinweis: In den Bearbeitungszeitvorgaben der jeweiligen Anwendungsfälle ist die Authentisierung am ZETA Guard nicht berücksichtigt.

7.2.1.1.3 3.x.1.3 Performancevorgaben E-Rezept

A_29785 - Performance – TI-Flow-Fachdienst - E-Rezept - Bearbeitungszeit unter Last

Der TI-Flow-Fachdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_TI-Flow-Fachdienst: Bearbeitungszeitvorgaben E-Rezept" unter einer Spitzenlast von 1770 Aufrufen pro Sekunde an der TI Schnittstelle und 620 Aufrufen pro Sekunde an der Internet-Schnittstelle erfüllen.

Tabelle 3: Tab_gemSpec_Perf_TI-Flow-Fachdienst: Bearbeitungszeitvorgaben E-Rezept

UseCase-Bezug Fachdienstoperation Mittlere Bearbeitungszeit
[msec]		 99%-Erfüllungsquote
[msec]
ERP.UC_1_1 GET /Device 120 200
ERP.UC_1_2 GET /metadata 120 200
ERP.UC_2_1 POST /Task/$create 250 400
ERP.UC_2_3* POST /Task/<id>/$activate 460 620
ERP.UC_2_5 POST /Task/<id>/$abort 330 470
ERP.UC_3_1 GET /Task 380 530
ERP.UC_3_2 POST /Task/<id>/$abort 330 470
ERP.UC_3_3 POST /Communication 430 590
ERP.UC_3_4 GET /Communication 540 720
ERP.UC_3_5 GET /AuditEvent 540 720
ERP.UC_3_6 GET /Task/<id> 380 530
ERP.UC_3_7 GET /ChargeItem/<id> 480 650
ERP.UC_3_8 DELETE /Communication/<id> 540 720
ERP.UC_3_9 GET /MedicationDispense?<parameter>= 540 720
ERP.UC_3_10 GET /ChargeItem 540 720
ERP.UC_3_11 DELETE /ChargeItem/<id> 430 590
ERP.UC_3_12 PATCH /ChargeItem/<id> 310 440
ERP.UC_3_13 GET /Consent 280 410
ERP.UC_3_14 POST /Consent 340 480
ERP.UC_3_15 DELETE /Consent 430 600
ERP.UC_3_16 POST /$grant-eu-access-permission  430 590
ERP.UC_3_17 DELETE /$revoke-eu-access-permission 430 590
ERP.UC_3_18 GET /$read-eu-access-permission 380 530
ERP.UC_3_20 POST /pushers/set
460 620
ERP.UC_3_21 GET /pushers
380 530
ERP.UC_3_22 GET /channels
380 530
ERP.UC_3_23 GET /channels/{pushkey}
380 530
ERP.UC_3_24 POST /channels/{pushkey}
460 620
ERP.UC_4_1 POST /Task/<id>/$accept 340 480
ERP.UC_4_2 POST /Task/<id>/$reject 300 430
ERP.UC_4_3 POST /Task/<id>/$abort 330 470
ERP.UC_4_4 POST /Task/<id>/$close 460 620
ERP.UC_4_6 GET /Communication 540 720
ERP.UC_4_7 POST /Communication 430 590
ERP.UC_4_8 GET /Task/<id>?secret 615 800
ERP.UC_4_9 DELETE /Communication/<id> 290 420
ERP.UC_4_10 GET /ChargeItem/<id> 480 650
ERP.UC_4_11 POST /ChargeItem 510 680
ERP.UC_4_12 GET /Task(PNW) 600 840
ERP.UC_4_13 PUT /ChargeItem/<id>  510 670
ERP.UC_4_14 POST /Subscription 230 350
ERP.UC_4_15 GET /Task(PoPP) 600 840
ERP.UC_4_16 POST /Task/<id>/$dispense 460 620
ERP.UC_4_17 GET /Task/<id>?accesscode 615 800
ERP.UC_4_19  POST /$get-eu-prescriptions mit Requesttype demographics 615 800
ERP.UC_4_20 POST /$get-eu-prescriptions mit Requesttype e-prescriptions-list 650 840
ERP.UC_4_21 POST /$get-eu-prescriptions mit Requesttype e-prescriptions-retrieval 650 840
ERP.UC_4_22 POST /Task/<id>/$eu-close  460 620
[<=]

Die ID aus der Tabelle "Tab_gemSpec_Perf_TI-Flow-Fachdienst: Bearbeitungszeitvorgaben E-Rezept" referenziert auf die entsprechenden Anwendungsfälle gemäß der Implementation Guides TI-Flow. Die in der Tabelle definierten Bearbeitungszeiten beziehen sich auf die vom Fachdienst umzusetzenden Operationen in den referenzierten Anwendungsfällen.

A_29786 - Performance - TI-Flow-Fachdienst - Robustheit gegenüber Lastspitzen

Der TI-Flow-Fachdienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_TI-Flow-Fachdienst: Bearbeitungszeitvorgaben E-Rezept" verfügbar bleiben. [<=]

Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der TI-Flow-Fachdienst vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter des Fachdienstes hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

A_29787 - Performance - TI-Flow-Fachdienst - Skalierung

Der Anbieter TI-Flow-Fachdienst MUSS nachvollziehbar darstellen, wie die Skalierung des TI-Flow-Fachdienstes im Produktivbetrieb erreicht wird. [<=]

Im Zuge des Zulassungsverfahrens hat der Anbieter des TI-Flow-Fachdienstes der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

A_29788 - Performance - TI-Flow-Fachdienst - Verfügbarkeit

Der Anbieter TI-Flow-Fachdienst MUSS folgende Verfügbarkeit des TI-Flow-Fachdienstes in den festgelegten Servicezeiten einhalten:

  • Hauptzeit: 99,99%
  • Nebenzeit: 99,97%
[<=]

Die Verfügbarkeit der funktionalen Eigenschaften des E-Rezept-Fachdienstes wird mittels der Probes des Service Monitorings und die qualitativen Eigenschaften durch Auswertung der Betriebsdaten ermittelt.

A_29789 - Performance - TI-Flow-Fachdienst - ePA Medication Service - Spitzenlastvorgaben

Der TI-Flow-Fachdienst MUSS als Client des ePA Medication Service die Spitzenlastvorgaben aus Tabelle "Tab_gemSpec_Perf_TI-Flow-Fachdienst: Spitzenlastvorgaben ePA Medication Service" erfüllen.

Tabelle 4: Tab_gemSpec_Perf_TI-Flow-Fachdienst: Spitzenlastvorgaben ePA Medication Service

UseCase-Bezug Beschreibung Spitzenlast [1/sec]
ERP.UC_5_1 Verordnungsdaten in ePA Medication Service einstellen 390
ERP.UC_5_2 Löschinformation Verordnungsdaten an ePA Medication Service übermitteln 35
ERP.UC_5_3 Dispensierinformationen in ePA Medication Service einstellen 145
ERP.UC_5_4 Löschinformation Dispensierinformationen an ePA Medication Service übermitteln 65
[<=]

A_29790 - Performance - TI-Flow-Fachdienst - ePA Medication Service - Maximale Übertragungszeit

Der TI-Flow-Fachdienst MUSS als Client des ePA Medication Service die UseCases zum Einstellen und Übermitteln der Löschinformationen von Verordnungsdaten und Dispensierinformationen spätestens nach 12 Stunden im ePA Aktenkonto durchgeführt haben, es sei denn, technische Fehler im ePA Aktensystem verhindern dies. [<=]

A_29791 - Performance - TI-Flow-Fachdienst - Push Notification - Übertragunsgzeit

Der TI-Flow‑Fachdienst MUSS Notifications an das Push‑Gateway spätestens innerhalb von 60 Minuten nach Ereignisgenerierung versenden, sofern das Push‑Gateway erreichbar ist. [<=]

A_29792 - Performance - TI-Flow-Fachdienst - Push Notification - Spitzenlast

Der TI-Flow-Fachdienst MUSS als Client der Push Gateways beim Versenden der Push Notifications eine Spitzenlast von 300 Aufrufen pro Sekunde erfüllen. [<=]

A_29793 - Verfügbarkeit - TI-Flow-Fachdienst - Erreichbarkeit eines Push Gateways

Der Anbieter TI-Flow-Fachdienst KANN bei Nicht-Erreichbarkeit eines Push Gateways Meldungen im eigenen Monitoring für dieses Push Gateway ignorieren, bis das Push Gateway wieder zur Verfügung steht. [<=]

A_29794 - Performance - TI-Flow-Fachdienst - Datenlieferung an ZETA Guard

Der Anbieter TI-Flow-Fachdienst MUSS Daten an die OpenTelemetry-Schnittstelle des Telemetrie-Daten-Service vom ZETA Guard gemäß [gemSpec_ZETA#Telemetrie-Daten Service], [gemSpec_Perf#Kapitel Telemetriedaten] sowie die nachfolgenden produktspezifischen Telemetriedatenanforderungen senden. [<=]

7.2.1.2 3.x.2 Telemetriedatenlieferung - Spezifika TI-Flow-Fachdienst

In Ergänzung an die allgemeinen Anforderungen an die Telemetriedatenlieferung befinden sich nachfolgend die produkttypspezifischen Anforderungen.

A_29796 - Performance - Telemetriedatenlieferung- Spezifika TI-Flow - Pseudonymisierte Telematik-ID

Der TI-Flow-Fachdienst MUSS die Telematik-ID der Institutionen für die Telemetriedatenerfassung entsprechend der Vorgaben zu Anomalieerkennung  pseudonymisieren. [<=]

Für Vorgaben zur Anomatieerkennung siehe [gemSpec_Krypt#Anomalie-Erkennung].

A_29797 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Operation

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferungen die Operationen der Tabelle "Tab_gemSpec_Perf_Berichtsformat_TI-Flow-Fachdienst_E-Rezept" berücksichtigen und den Use Case eindeutig über die Trace Parameter attributes:http_method und attributes:http_route kenntlich machen.  [<=]

A_29798 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Status

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferung im Trace Span des Resource Servers für das Feld "rs_statuscode" vorrangig den gemappten Details Code des Fehlers verwenden. In allen anderen Fällen ist der an den Client zurückgemeldete, HTTP-Response Code in das Feld einzutragen. [<=]

Für das Mapping des Details Code für die Telemetriedatenlieferung siehe [ConceptMap: Telemetry Data Status Codes Concept Map].

A_29799 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Duration

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferung für das Feld "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger. [<=]

A_29800 - Performance - Telemetriedaten - Spezifika TI-Flow - Message

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferungen produkttypspezifische Informationen gemäß Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten als key / value Paar im Trace mitliefern. 

Tabelle 5: Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten

key Beschreibung Datentyp Erläuterung
"pdt_cid" zeta-client-data.client_id
String
"pdt_pn_telematikID" Pseudonymisierte Telematik-ID der aufrufenden Institution String 
"pdt_size" Größe des Requests in Kilobyte Integer
"pdt_bkdur" Zeit in ms für synchron ausgeführte Abfragen an andere Systeme (bspw. OCSP-Responder)
Integer
"pdt_mvonr" falls Flag für Mehrfachverordnung gesetzt: Nummerator der Teilverordnung Integer
"pdt_vnr" Vorgangsnummer
für Aktivitäten mit Bezug auf einen einzelnen Task: Task-ID
für Aktivitäten ohne Bezug aus einen Task oder mehrere Tasks: null		 String
"pdt_anr" falls fehlerhafte Prüfung von identifier:ANR.value gemäß IG-TIFLOW-CORE-190:  identifier:ANR.value String 
"pdt_zanr" falls fehlerhafte Prüfung von identifier:ZANR.value gemäß IG-TIFLOW-CORE-190:  identifier:ZANR.value String 
"pdt_wf" für Aktivitäten mit Bezug auf einen einzelnen Task: flowtype Integer
"pdt_cov" für Aktivitäten mit Bezug auf einen einzelnen Task: coverage typ String 
"pdt_fsc" falls POST /task/<id>/$close für DiGA-Verordnung:
Angabe, ob ein Freischaltcode in der Abgabeinformation enthalten ist		 boolean
"pdt_tldur" Throttling duration
Drosselungszeit eines Clientsystems in ms		 Integer
"pdt_gwp" FHIR Profil Version des gematik eRezept Worklow Package  String
"pdt_gpr" FHIR Profil Version des gematik eRezept Patientenrechnung Package
String 
"pdt_kbv" FHIR Profil Version des KBV Verordnungsdatensatz Package  String 
"pdt_dav" FHIR Profil Version des DAV Abgabedatensatz Package String 
[<=]

Exporter ePA Medication Service

A_29801 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Status - ePA Medication Service

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferung im Trace Span zugehörig zum Medication Exporters bzgl. des Feldes "rs_statuscode" den vom ePA Aktensystem im äusseren Http Request zurückgegeben HTTP Status Code übermitteln. 
Der TI-Flow-Fachdienst MUSS, wenn der HTTP Status Code des äusseren HTTP Requests gleich 200 ist, den vom ePA Aktensystem im inneren Http Request zurückgegeben HTTP Status Code übermitteln. [<=]

A_29802 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Duration - ePA Medication Service

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferung des Medication Exporters bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit dem Aufbau der Verbindung und endet mit dem vollständigen Empfang der Antwort vom ePA Aktensystem. [<=]

A_29803 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Message - Error-Component - ePA Medication Service

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferung des Medication Exporters bzgl. des Attributes "pdt_ec" für die UseCase ERP_UC_5_1, ERP_UC_5_2, ERP_UC_5_3 und ERP_UC_5_4 den Inhalt des OperationOutcome.issue.details.code ohne das Prefix "MEDICATIONSVC_" und für den ERP_UC_5_5 den Inhalt des healthcareProcess - erp-submission übermitteln. [<=]

A_29804 - Performance - Telemetriedaten - Spezifika TI-Flow - Message - ePA Medication Service

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferungen des Medication Exporters produkttypspezifische Informationen gemäß Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten_MedicationService als key / value Paar im Trace mitliefern. 

Tabelle 6: Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten_MedicationService

key Beschreibung Datentyp Erläuterung
"pdt_cid" client_id des TI-Flow-Fachdienstes String
"pdt_size" Größe des Requests in Kilobyte Integer
"pdt_bkdur" Zeit in ms von Erstellungszeitpunkt bis zum Aufruf
Integer
"pdt_vnr" Vorgangsnummer: Task-ID String
"pdt_ec" error component
bei Fehler in der Ermittlung des Aktensystems: healthcareProcess - erp-submission Informationen
bei Fehler in der Datenübermittlung: Der Wert im OperationOutcome.issue.details.code		 String 
"pdt_epa" Der Wert der Subdomain der URL des ePA-Aktensystems String 
"pdt_wf" für Aktivitäten mit Bezug auf einen einzelnen Task: flowtype Integer
[<=]

Exporter BfArM Webservice

A_29805 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Duration - BfArM Webservice

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferung des E-T-Rezept Exporters bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit dem Aufbau der Verbindung und endet mit dem vollständigen Empfang der Antwort vom BfArM Webservice. [<=]

A_29806 - Performance - Telemetriedaten - Spezifika TI-Flow - Message - BfArM Webservice

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferungen des Exporters BfArM Webservice produkttypspezifische Informationen gemäß Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten_BfArM als key / value Paar im Trace mitliefern. 

Tabelle 7: Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten_BfArM

key Beschreibung Datentyp Erläuterung
"pdt_cid" client_id des TI-Flow-Fachdienstes String
"pdt_size" Größe des Requests in Kilobyte Integer
"pdt_bkdur" Zeit in ms von Erstellungszeitpunkt bis zum Aufruf
Integer
"pdt_vnr" Vorgangsnummer: Task-ID String
"pdt_ec" error component: Der Wert im OperationOutcome Code String 
"pdt_wf" flowtype Integer
[<=]

Exporter Push Gateway

A_29807 - Performance - Telemetriedatenlieferung - Spezifika TI-Flow - Duration - Push Gateway

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferung für Use Case ERP.UC_5_10 (Push Notification) bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit dem Aufbau der Verbindung und endet mit dem vollständigen Empfang der Antwort vom Push Gateway. [<=]

 

A_29808 - Performance - Telemetriedaten - Spezifika TI-Flow - Message - Push Gateway

Der TI-Flow-Fachdienst MUSS bei Telemetriedatenlieferungen des Exporters Push Gateway produkttypspezifische Informationen gemäß Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten_Push als key / value Paar im Trace mitliefern.

Tabelle 8 : Tab_Berichtsformat_TI-Flow-Fachdienst_Telemetriedaten_Push

key Beschreibung Datentyp Erläuterung
"pdt_cid" client_id des TI-Flow-Fachdienstes String
"pdt_size" Größe des Requests in Kilobyte Integer
"pdt_bkdur" Zeit in ms von Erstellungszeitpunkt bis zum Aufruf
Integer
"pdt_vnr" Vorgangsnummer: Task-ID String
"pdt_epa" DNS-Adresse des Push Gateways String 
[<=]

Tabelle 9: Tab_gemSpec_Perf_Berichtsformat_TI-Flow-Fachdienst_E-Rezept

$FD-operation
Operation
Schnittstelle zu
ERP.UC_1_1 GET /Device alle
ERP.UC_1_2 GET /metadata alle
ERP.UC_2_1
POST /Task/$create
verordnende LEI
ERP.UC_2_3
POST /Task/<id>/$activate
verordnende LEI
ERP.UC_2_5 POST /Task/<id>/$abort verordnende LEI
ERP.UC_3_1 GET /Task Versicherte
ERP.UC_3_2 POST /Task/<id>/$abort Versicherte
ERP.UC_3_3 POST /Communication Versicherte
ERP.UC_3_5 GET /AuditEvent Versicherte
ERP.UC_3_6 GET /Task/<id> Versicherte
ERP.UC_3_7 GET /ChargeItem/<id> Versicherte
ERP.UC_3_8 DELETE /Communication/<id> Versicherte
ERP.UC_3_9 GET /MedicationDispense?<parameter>= Versicherte
ERP.UC_3_10 GET /ChargeItem Versicherte
ERP.UC_3_11 DELETE /ChargeItem/<id> Versicherte
ERP.UC_3_12 PATCH /ChargeItem/<id> Versicherte
ERP.UC_3_13 GET /Consent Versicherte
ERP.UC_3_14 POST /Consent Versicherte
ERP.UC_3_15 DELETE /Consent Versicherte
ERP.UC_3_16 POST /$grant-eu-access-permission  Versicherte
ERP.UC_3_17 DELETE /$revoke-eu-access-permission Versicherte
ERP.UC_3_18 GET /$read-eu-access-permission Versicherte
ERP.UC_3_19 PATCH /Task/<id> Versicherte
ERP.UC_4_1 POST /Task/<id>/$accept abgebende LEI
ERP.UC_4_2 POST /Task/<id>/$reject abgebende LEI
ERP.UC_4_3 POST /Task/<id>/$abort abgebende LEI
ERP.UC_4_4 POST /Task/<id>/$close abgebende LEI
ERP.UC_4_6 GET /Communication abgebende LEI
ERP.UC_4_7 POST /Communication
abgebende LEI
ERP.UC_4_8 GET /Task/<id>?secret abgebende LEI
ERP.UC_4_9 DELETE /Communication/<id> abgebende LEI
ERP.UC_4_10 GET /ChargeItem/<id> abgebende LEI
ERP.UC_4_11 POST /ChargeItem abgebende LEI
ERP.UC_4_13 PUT /ChargeItem/<id> abgebende LEI
ERP.UC_4_14 POST /Subscription abgebende LEI
ERP.UC_4_15 GET /Task(PoPP) abgebende LEI
ERP.UC_4_16 POST /Task/<id>/$dispense abgebende LEI
ERP.UC_4_17 GET /Task/<id>?accesscode abgebende LEI
ERP.UC_4_19  POST /$get-eu-prescriptions mit Requesttype demographics NCPeH-FD
ERP.UC_4_20 POST /$get-eu-prescriptions mit Requesttype e-prescriptions-list NCPeH-FD
ERP.UC_4_21 POST /$get-eu-prescriptions mit Requesttype e-prescriptions-retrieval NCPeH-FD
ERP.UC_4_22 POST /Task/<id>/$eu-close NCPeH-FD
ERP.UC_5_1 Verordnungsdaten in Aktenkonto einstellen ePA-Aktensystem
ERP.UC_5_2 Löschinformation Verordnungsdaten an Aktenkonto übermitteln ePA-Aktensystem
ERP.UC_5_3 Dispensierinformationen in Aktenkonto einstellen ePA-Aktensystem
ERP.UC_5_4 Löschinformation Dispensierinformationen an Aktenkonto übermitteln ePA-Aktensystem
ERP.UC_5_5 ePA-Aktensystem ermitteln und Widerspruch prüfen ePA-Aktensystem
ERP.UC_5_6 Login ePA-Aktensystem ePA-Aktensystem
ERP.UC_5_7 POST /ords/rezepte/oauth/token BfArM Service
ERP.UC_5_8 POST /ords/rezepte/t-rezept/v1 BfArM Service
ERP.UC_5_9 GET [baseUrl]/search FHIR-VZD

7.2.1.3 3.x.2 Bestandsdatenlieferung - Spezifika TI-Flow-Fachdienst

A_29811 - Performance - Bestandsdaten - Spezifika TI-Flow - Anbieter

Der Anbieter TI-Flow-Fachdienst MUSS in einem definierten, konfigurierbaren Zeitintervall (jeweils zum Wechsel in den nächsten Berichtsintervall) definierte Metriken zu den Bestandsdaten im Rahmen der Telemetriedatenlieferung übermitteln. [<=]

Defaultmäßig ist eine tägliche Lieferung vorgesehen.

A_29812 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Workflow 160

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
  "name": "tiflow_workflow_160_count",
  "description": "the number of stored workflows with flowtype 160 for various statuses",
  "unit": "1",
  "type": "COUNTER",
  "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
  "status": "ready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=160 im Status "ready" als Integer
  "status": "inprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=160 im Status "in-progress" als Integer
  "status": "completed" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=160 im Status "completed" als Integer
  "status": "cancelled" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=160 im Status "cancelled" als Integer
  "status": "deleteready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=160 zur Löschung am Folgetag im Status "ready" als Integer
  "status": "deleteinprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=160 zur Löschung am Folgetag im Status "in-progress" als Integer [<=]

A_29813 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Workflow 162

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
   "name": "tiflow_workflow_162_count",
   "description": "the number of stored workflows with flowtype 162 for various statuses",
   "unit": "1",
   "type": "COUNTER",
   "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
   "status": "ready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=162 im Status "ready" als Integer
   "status": "inprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=162 im Status "in-progress" als Integer
   "status": "completed" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=162 im Status "completed" als Integer
   "status": "cancelled" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=162 im Status "cancelled" als Integer
   "status": "deleteready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=162 zur Löschung am Folgetag im Status "ready" als Integer
   "status": "deleteinprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=162 zur Löschung am Folgetag im Status "in-progress" als Integer [<=]

A_29814 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Workflow 166

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
   "name": "tiflow_workflow_166_count",
   "description": "the number of stored workflows with flowtype 166 for various statuses",
   "unit": "1",
   "type": "COUNTER",
   "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
   "status": "ready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=166 im Status "ready" als Integer
   "status": "inprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=166 im Status "in-progress" als Integer
   "status": "completed" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=166 im Status "completed" als Integer
   "status": "cancelled" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=166 im Status "cancelled" als Integer
   "status": "deleteready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=166 zur Löschung am Folgetag im Status "ready" als Integer
   "status": "deleteinprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=166 zur Löschung am Folgetag im Status "in-progress" als Integer [<=]

A_29815 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Workflow 169

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
   "name": "tiflow_workflow_169_count",
   "description": "the number of stored workflows with flowtype 169 for various statuses",
   "unit": "1",
   "type": "COUNTER",
   "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
   "status": "ready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=169 im Status "ready" als Integer
   "status": "inprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=169 im Status "in-progress" als Integer
   "status": "completed" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=169 im Status "completed" als Integer
   "status": "cancelled" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=169 im Status "cancelled" als Integer
   "status": "deleteready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=169 zur Löschung am Folgetag im Status "ready" als Integer
   "status": "deleteinprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=169 zur Löschung am Folgetag im Status "in-progress" als Integer [<=]

A_29816 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Workflow 200

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
   "name": "tiflow_workflow_200_count",
   "description": "the number of stored workflows with flowtype 200 for various statuses",
   "unit": "1",
   "type": "COUNTER",
   "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
   "status": "ready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=200 im Status "ready" als Integer
   "status": "inprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=200 im Status "in-progress" als Integer
   "status": "completed" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=200 im Status "completed" als Integer
   "status": "cancelled" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=200 im Status "cancelled" als Integer
   "status": "deleteready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=200 zur Löschung am Folgetag im Status "ready" als Integer
   "status": "deleteinprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=200 zur Löschung am Folgetag im Status "in-progress" als Integer [<=]

A_29817 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Workflow 209

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
   "name": "tiflow_workflow_209_count",
   "description": "the number of stored workflows with flowtype 209 for various statuses",
   "unit": "1",
   "type": "COUNTER",
   "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
   "status": "ready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=209 im Status "ready" als Integer
   "status": "inprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=209 im Status "in-progress" als Integer
   "status": "completed" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=209 im Status "completed" als Integer
   "status": "cancelled" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=209 im Status "cancelled" als Integer
   "status": "deleteready" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=209 zur Löschung am Folgetag im Status "ready" als Integer
   "status": "deleteinprogress" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Tasks mit FlowType=209 zur Löschung am Folgetag im Status "in-progress" als Integer [<=]

A_29818 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Exporter eML

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
   "name": "tiflow_eml_count",
   "description": "the number of stored items in eml exporter queue",
   "unit": "1",
   "type": "COUNTER",
   "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
   "status": "kvnr" <-- Anzahl der KVNRs zum Abfragezeitpunkt mit Einträgen in der Queue des eML Exporter als Integer
   "status": "pending" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Übermittlungsaufträge im Status "pending" in der Queue des eML Exporter als Integer
   "status": "dLQ" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Übermittlungsaufträge im Status "deadLetterQueue" in der Queue des eML Exporter als Integer [<=]

A_29819 - Performance - Bestandsdaten - Spezifika TI-Flow - Metrik Anzahl Exporter BfArM

Der TI-Flow-Fachdienst MUSS bei der Lieferung von Bestandsdaten (gem. Tab_gemSpec_Perf_Telemetriedaten_metric) unter "metrics" eine Metrik mit folgenden Informationen liefern:
   "name": "tiflow_bfarm_count",
   "description": "the number of stored items in bfarm exporter queue",
   "unit": "1",
   "type": "COUNTER",
   "data_points": [...]
und unter "data_points" Datenpunkte für folgende Labels:
   "status": "kvnr" <-- Anzahl der KVNRs zum Abfragezeitpunkt mit Einträgen in der Queue des BfArM Exporter als Integer
   "status": "pending" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Übermittlungsaufträge im Status "pending" in der Queue des BfArM Exporter als Integer
   "status": "dLQ" <-- Anzahl der zum Abfragezeitpunkt vorhandenen Übermittlungsaufträge im Status "deadLetterQueue" in der Queue des BfArM Exporter als Integer [<=]

7.2.1.4 Servicezeiten

A_23350 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag eingeschränkt

Das Produkt MUSS folgende Servicezeiten gewährleisten: 

  • Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr.
  • Bundeseinheitliche Feiertage werden wie ein Sonntag behandelt, alle übrigen Feiertage wie ein Montag.
  • Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]

A_24962 - Performance - Servicezeiten des Anbieters basierend auf Produkttypen

Der Anbieter MUSS gemäß der in [gemKPT_Betr#Tab_gemKPT_Betr_Servicekomponente] aufgeführten Servicekomponenten bzw. der Zuordnung von Produkttypen zu serviceverantwortlichen Anbieter die dem entsprechenden Produkttypen zugeordneten Servicezeiten erfüllen. [<=]

Tabelle 10: Tab_gemSpec_Perf_Servicekomponente->Servicezeit, Wartungsfenster 

Servicekomponente Servicezeit Wartungsfenster
<...>
SK TI-Flow Fachdienst A_23350 - HZ Mo bis So eingeschränkt A_23618*

7.2.1.5 Verfügbarkeitsberechnung

A_23618-02 - Performance - Wartungsfenster und Ausfall - Ausfallfreier Betrieb

Der Anbieter MUSS bei Wartung seiner Servicekomponente gemäß [gemKPT_Betr#Tab_gemKPT_Betr_Servicekomponente] den durchgängigen, also ausfallfreien Betrieb gewährleisten.

Hinweis: Im Regelfall ist jede Nutzungseinschränkung eines unterbrechungsfreien Betriebs als Ausfall anzusehen. Entstehen durch den Anbieter nachweisbar unverschuldete Ausfallzeiten, wird die gematik diese Zeiten mildernd berücksichtigen. Ist ein Ausfall im Rahmen einer Wartung unvermeidbar, so ist dieser dennoch anzukündigen und zu begründen - auch wenn dieser als Ausfall zulasten des Anbieters gewertet wird.
[<=]

7.2.1.6 Schnittstellenoperationen
7.2.1.7 Service Level Werte

Performance-Kenngrößen / SL-Werte

Der Bearbeitungszeitraum  für die aufgeführten Soll-Werte beträgt ein Kalendermonat.

Die Bildung der Performance-Kenngrößen basiert auf folgenden PG-Schemata: PG-Schema-I

Tabelle 11: Tab_gemSpec_Perf_eRP_Performance-Kenngroessen

Performance-
Kenngröße (PKG-ID)
Beschreibung
berechnet aus (Betriebsdaten, Probing)
SL-Wert
(Soll-Wert)
min / max
Normative Referenz
TI-Flow-Fachdienst - PDTXX - (ERP*)
PDTXX-A01-D3-G33 Relative Verfügbarkeit im Betrachtungszeitraum zur Hauptzeit inkl. Wartung. [%*1000] Probing 99990
(PU)		 min A_29788
PDTXX-A01-D3-G33 Relative Verfügbarkeit im Betrachtungszeitraum zur Hauptzeit inkl. Wartung. [%*1000] Probing 99500
(RU, TU) 		 min kein SL 
PDTXX-A01-D3-G34 Relative Verfügbarkeit im Betrachtungszeitraum zur Nebenzeit inkl. Wartung. [%*1000]  Probing 99970
(PU)		 min A_29788 
PDTXX-A01-D3-G34 Relative Verfügbarkeit im Betrachtungszeitraum zur Nebenzeit inkl. Wartung. [%*1000]  Probing 85000
(RU, TU)		 min kein SL 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_2_1)
PDTXX-A02-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 250 max A_29785
PDTXX-A02-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 400 max A_29785
PDTXX-A02-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_2_3)
PDTXX-A03-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 460 max A_29785 
PDTXX-A03-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 620 max A_29785 
PDTXX-A03-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_1)
PDTXX-A04-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 380 max A_29785 
PDTXX-A04-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 530 max A_29785 
PDTXX-A04-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_3)
PDTXX-A05-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 430 max A_29785 
PDTXX-A05-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 590 max A_29785 
PDTXX-A05-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_6)
PDTXX-A06-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 380 max A_29785 
PDTXX-A06-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 530 max A_29785 
PDTXX-A06-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_1)
PDTXX-A07-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 340 max A_29785 
PDTXX-A07-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 480 max A_29785 
PDTXX-A07-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_4)
PDTXX-A08-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 460 max A_29785 
PDTXX-A08-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 620 max A_29785 
PDTXX-A08-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_7)
PDTXX-A09-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 430 max A_29785 
PDTXX-A09-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 590 max A_29785 
PDTXX-A09-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_2_3_169)
PDTXX-A10-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 460 max A_29785 
PDTXX-A10-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 620 max A_29785 
PDTXX-A10-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_7)
PDTXX-A11-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 480 max A_29785 
PDTXX-A11-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 650 max A_29785 
PDTXX-A11-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_11)
PDT50-A12-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 510 max A_29785 
PDT50-A12-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 680 max A_29785 
PDT50-A12-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.VAU)
TI-Flow-Fachdienst - PDTXX - (ERP.UC_2_3_200)
PDTXX-A14-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 460 max A_29785 
PDTXX-A14-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 620 max A_29785 
PDTXX-A14-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_2_3_209)
PDTXX-A15-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 460 max A_29785 
PDTXX-A15-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 620 max A_29785 
PDTXX-A15-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_10)
PDTXX-A16-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 480 max A_29785 
PDTXX-A16-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 650 max A_29785 
PDTXX-A16-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_1_1)
PDTXX-A18-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 120 max A_29785 
PDTXX-A18-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 200 max A_29785 
PDTXX-A18-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min AA_29785
TI-Flow-Fachdienst - PDTXX - (ERP.UC_1_2)
PDTXX-A19-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 120 max A_29785 
PDTXX-A19-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 200 max A_29785 
PDTXX-A19-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785
TI-Flow-Fachdienst - PDTXX - (ERP.UC_2_5)
PDTXX-A20-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 330 max A_29785 
PDTXX-A20-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 470 max A_29785 
PDTXX-A20-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_2) 
PDTXX-A21-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 330 max A_29785 
PDTXX-A21-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 470 max A_29785 
PDTXX-A21-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_4)
PDTXX-A22-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 540 max A_29785 
PDTXX-A22-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 720 max A_29785 
PDTXX-A22-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_5)
PDTXX-A23-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 540 max A_29785 
PDTXX-A23-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 720 max A_29785 
PDTXX-A23-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_8)
PDTXX-A24-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 540 max A_29785 
PDTXX-A24-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 720 max A_29785 
PDTXX-A24-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_9)
PDTXX-A25-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 540 max A_29785 
PDTXX-A25-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 720 max A_29785 
PDTXX-A25-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_10)
PDTXX-A26-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 540 max A_29785 
PDTXX-A26-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 720 max A_29785 
PDTXX-A26-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_11)
PDTXX-A27-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 430 max A_29785 
PDTXX-A27-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 590 max A_29785 
PDTXX-A27-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_12)
PDTXX-A28-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 310 max A_29785 
PDTXX-A28-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 440 max A_29785 
PDTXX-A28-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_13)
PDTXX-A29-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 280 max A_29785 
PDTXX-A29-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 410 max A_29785 
PDTXX-A29-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_14)
PDTXX-A30-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 340 max A_29785 
PDTXX-A30-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 480 max A_29785 
PDTXX-A30-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_3_15)
PDTXX-A31-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 430 max A_29785 
PDTXX-A31-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 600 max A_29785 
PDTXX-A31-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_2)
PDTXX-A32-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 300 max A_29785 
PDTXX-A32-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 430 max A_29785 
PDTXX-A32-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_3)
PDTXX-A33-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 330 max A_29785 
PDTXX-A33-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 470 max A_29785 
PDTXX-A33-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_6)
PDTXX-A34-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 540 max A_29785 
PDTXX-A34-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 720 max A_29785 
PDTXX-A34-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_8)
PDTXX-A35-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 615 max A_29785 
PDTXX-A35-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 800 max A_29785 
PDTXX-A35-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_9)
PDTXX-A36-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 290 max A_29785 
PDTXX-A36-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 420 max A_29785 
PDTXX-A36-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_13)
PDTXX-A37-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 510 max A_29785 
PDTXX-A37-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 670 max A_29785 
PDTXX-A37-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_14)
PDTXX-A38-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 230 max A_29785 
PDTXX-A38-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 350 max A_29785 
PDTXX-A38-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_15)
PDTXX-A44-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 650 max A_29785 
PDTXX-A44-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 840 max A_29785 
PDTXX-A44-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_16)
PDTXX-A47-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 460 max A_29785 
PDTXX-A47-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 620 max A_29785 
PDTXX-A47-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_4_17)
PDTXX-A48-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 615 max A_29785 
PDTXX-A48-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 800 max A_29785 
PDTXX-A48-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_29785 
TI-Flow-Fachdienst - PDTXX - (ERP.UC_2_3_166)
PDTXX-A66-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 460 max A_29785
PDTXX-A66-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]  Betriebsdaten 620 max A_29785 
PDTXX-A66-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]  Betriebsdaten 99000 min A_29785 

7.3 gemKPT_Betr

7.3.1.1 Änderungen in Kapitel 3.4.4

Anbieter TI-Flow_FD wird zur Tabelle 2 Tab_KPT_Betr_Betriebliche Rolle_Vertragsart hinzugefügt

Tabelle 12: Tab_KPT_Betr_Betriebliche Rolle_Vertragsart

Spezifische Ausprägung der Rolle Vertragsart Vertreter möglich? Steckbrief Bemerkung
<...>
Anbieter TI-Flow-Fachdienst <Beauftragung> gemAnbT_TI-Flow_FD_ATV

7.3.1.2 Änderung in Kapitel 3.5.2: Servicezerlegung

Tabelle 13: Tab_gemKPT_Betr_Servicekomponente

Servicekomponente (SK) Service Provider
(Eigener Service)		 Produkt-
typ		 Produkttyp-
Name		 Anbieter-
ausschluss (SK)
<...>
SK TI-Flow_Fachdienst Anbieter TI-Flow-Fachdienst PDTxx TI-Flow-Fachdienst

7.3.1.3 Änderungen in Kapitel 3.5.3: Mitwirkungsverpflichtung im TI-ITSM gemäß [gemRL_Betr_TI]

Tabelle 14: Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM

Mitwirkung in den TI-ITSM-Prozessen:
INC PRO CHG SKM SLM RF Perf CapM KM CSI CM NM
<...>
Anbieter TI-Flow-Fachdienst A/E A/E X . A/E A A A A/E . A/E A/E

7.3.1.4 in Kapitel 5.2: Organisatorische Service Level
7.3.1.5 in Kapitel 5.2.2: Spezifische Ausprägungen

Hinzufügen des neuen Anbieters TI-Flow-Fachdienst zu den Organisatorischen Service Level Zeiten

Tabelle 15: Tab_gemKPT_Betr_OrgSL_Serviceleistung_Zeiten

Organisatorischer Service Level Betriebliche Rolle
zu Haupt- und Nebenzeit
(TIP1-A_7265-*)		 <...>
Anbieter TI-Flow-Fachdienst

Weitere Organisatorische Service Level

Tabelle 16: Tab_gemKPT_Betr_OrgSL_Weitere_Serviceleistung

Weitere Organisatorische Service Level Betriebliche Rolle
Change - Ursache für Incidents (A_23664) <...>
Anbieter TI-Flow-Fachdienst
Störungsfreie Kommunikationsbeziehungen (A_23665) <...>
Anbieter TI-Flow-Fachdienst

7.4 gemKPT_Test

A_29778 - Bereitstellung von Testartefakten

Der Hersteller MUSS der gematik ein Git-Repository mit Lesezugriff bereitstellen. Dieses Repository MUSS mindestens Testsuiten, Testfälle, Testszenarien, Testdaten und Testkonfigurationen in der jeweils zur freigegebenen Produktversion gehörenden Fassung enthalten. Die Artefakte MÜSSEN so vollständig und versioniert bereitgestellt werden, dass die gematik die Hersteller-Tests ohne Mitwirkung des Herstellers reproduzierbar ausführen kann. [<=]

A_29777 - Support bei bereitgestellten Testsuiten

Der Hersteller MUSS technischen Support bei der Ausführung der von ihm an die gematik übergebenen Testsuiten leisten. Dieser Support umfasst die Unterstützung der gematik bei der Einrichtung, Testvorbereitung, Fehleranalyse sowie der Behebung von Fehlerzuständen in der Testsuite. [<=]

A_29780 - Bereitstellung von Testkomponenten und Testartefakten in den Testumgebungen

Der Hersteller MUSS das Testobjekt und Testartefakte so entwickeln und bereitstellen, dass diese in allen Testumgebungen (RU-Dev, TU, RU) genutzt werden können. [<=]

A_29784 - Automatisierte Qualitätssicherung

Der Hersteller MUSS nach jedem Deployment auf einer Testinstanz in der RU DEV Umgebung die Interoperabilitätstest des EVT ausführen. Diese Suite MUSS: 

  • vollständig automatisiert (getriggert durch das Deployment) gestartet werden
  • potenzielle Probleme identifizieren können, die andere Hersteller (Teilnehmer der TI) beeinträchtigen könnten
  • automatisiert ablaufen (ohne manuelle Eingriffe)
  • sämtliche Testergebnisse, Logs und Reports signieren und direkt für den AG einsehbar in der dafür vorgesehenen Artifact Registry der HCC-Cloud ablegen
  • Den Testausführung analysieren und im Fehlerfall Tickets anlegen
[<=]

A_29783 - Bereitstellung der Testpipeline im Mandantenkontext

Der Hersteller MUSS eine automatisierte Testpipeline innerhalb seines eigenen Mandantenkontextes so aufsetzen und bereitstellen, dass diese für die Testausführung der Interoperabilitätstest in den RU-Dev-Instanzen genutzt werden können.
Der Hersteller MUSS dem Auftraggeber jederzeit vollen Zugriff (Lese- und Ausführungsrechte) auf diese Testpipeline sowie die dazugehörigen Konfigurationen und Testergebnisse gewähren.
[<=]

A_29795 - Standardisiertes Testreport-Schema für die automatisierte Attestierung

Der Hersteller MUSS für alle Testberichte und Qualifizierungsnachweise ein einheitlich definiertes Testreport-Schema verwenden, um das automatisierte Staging sowie die automatisierte Auswertung der Attestierung zu ermöglichen.
Der Hersteller MUSS für die Erstellung dieser Attestierungen das Schema von in-toto Test Result (https://in-toto.io/attestation/test-result/v0.1) verwenden und alle darin geforderten Pflichtfelder vollständig und valide befüllen. [<=]

A_29873 - Signierung und Ablage des Testreport-Schema für die automatisierte Attestierung

Der Hersteller MUSS diesen nach dem in-toto Schema erstellten Testreport vor der Ablage kryptografisch signieren, um die Integrität und Authentizität des Prüfergebnisses lückenlos nachweisbar zu machen.
Der Hersteller MUSS den signierten in-toto Testreport zusammen mit der dazugehörigen Signatur (Verfahren Cosign) automatisiert in der dafür vorgesehenen Artifact Registry innerhalb der HCC-Cloud ablegen.
[<=]

A_27460 - IOP Tests mit Primärsystemen

Zulassungsnehmer, deren Produkte eine Schnittstelle zu Primärsystemen haben, MÜSSEN nach der Generalprobe in der Referenzumgebung (RU) ihr Zulassungsobjekt für Interoperabilitätstests im Rahmen einer Konformitätsbewertung oder eines Bestätigungsverfahrens zur Verfügung stellen. [<=]

TIP1-A_6517-02 - Eigenverantwortlicher Test: Zulassungsnehmer

Der Zulassungsnehmer MUSS seine Aufgaben gemäß [Tab_Test_005_01] "Eigenverantwortlicher Test (EvT)" erfüllen. [<=]

A_27438 - Durchführung der Generalprobe

Der Zulassungsnehmer MUSS seine Aufgaben [Tab_Test_035_02] "Gesamtintegrationstest - Generalprobe" erfüllen.  [<=]

A_27475 - Fehlerbehebungsplan

Der Zulassungsnehmer MUSS im Fehlerbehebungsplan alle offenen Fehler sowie deren geplante Behebungstermine dokumentieren. Für jeden offenen Fehler sind folgende Informationen zu dokumentieren:

  1. Fehlerübersicht:
    • eindeutige Fehler-ID (fortlaufende Nummerierung oder eindeutiger Code)
    • Kurzbeschreibung des Fehlers
    • detaillierte Fehlerbeschreibung, einschließlich betroffener Produkte
  2. Fehlerbewertung:
    • Bewertung der Auswirkungen eines Fehlers auf das Gesamtsystem gemäß definierter Fehlerschweregradkriterien im Kapitel Fehlermanagement
  3. Behebungsplanung:
    • geplanter Behebungstermin
    • Status der Behebung
Format und Bereitstellung:
  • Das Dokument ist in einem gängigen Format wie zum Beispiel (Excel, PDF oder CSV) bereitzustellen.
  • Eine regelmäßige Aktualisierung (mindestens wöchentlich) und die Zugänglichkeit für den Testansprechpartner der gematik MUSS gewährleistet sein.
Der Fehlerbehebungsplan MUSS mit Abschluss der eigenverantwortlichen Tests erstellt und vor Beginn der Zulassungstests der gematik zur Verfügung gestellt werden. [<=]

A_25392-01 - Nutzung Testfallmatrix-Template der gematik

Der Zulassungsnehmer MUSS das gematik "Afo_Testmatrix" Template als Teil der Dokumentation der ausgeführten / nicht ausgeführten Testfälle nutzen und der gematik zur Verfügung stellen. [<=]

A_27248 - Güteprüfung Test

Die Güteprüfung stellt eine zentrale Qualitätssicherungsmaßnahme im Rahmen von Beauftragungen dar. Sie dient der detaillierten Prüfung und Bewertung der geforderten Testdokumente und die jeweiligen Produkte. 
Der Auftragnehmer MUSS mindestens folgende Testdokumente als Liefergegenstände bereitzustellen:

  1. Testkonzept: Entsprechend den Vorgaben in Tab_Test_013 des [gemKPT_Test],
  2. Testspezifikation: Gemäß den Anforderungen in Tab_Test_014 des [gemKPT_Test],
  3. Testbericht: Konform zu Tab_Test_018 des [gemKPT_Test],
  4. Produktdokumentation: entsprechend der Vorgaben in "Tab_Test_016 Produktdokumentation" des [gemKPT_Test],
  5. Afo-Testmatrix: In Übereinstimmung mit den Richtlinien des [gemKPT_Test].
Diese Dokumente bilden die Grundlage für eine umfassende Beurteilung der Testqualität und -Vollständigkeit. Der Auftraggeber (AG) prüft die Dokumente auf Einhaltung der definierten Vorgaben  gemäß [TIP1-A6524-01] und protokolliert die Prüfung.
[<=]

A_27141 - Testmanagementsystem des AN

Der AN MUSS für die Testaktivitäten während der eigenverantwortlichen Tests ein umfassendes Testmanagementsystem einsetzen und dem AG den vollen Zugriff hierfür gewähren. Das Testmanagementsystem MUSS folgende Testaktivitäten unterstützen:

  1. Testdurchführung: Alle Tests im System durchführen und dokumentieren, einschließlich E2E-Tests und BDD-Szenarien.
  2. Fehlermanagement: Fehler erfassen, mit Details versehen und sichtbar machen.
  3. Fortschritt und Berichte: Testfortschritt jederzeit einsehbar, automatische Berichtgenerierung.
  4. Artefakte: Testartefakte im System verwalten.
  5. Dokumentation: Benutzerdokumentation und Systemanleitungen bereitstellen.
  6. Zugriffsrechte: AG erhält Lesezugriff, bei Bedarf auch Schreibrechte.
  7. Versionskontrolle: Für Testfälle, Skripte und andere Artefakte.
  8. Nachverfolgbarkeit: Zwischen Anforderungen, Testfällen und Ergebnissen.
Der AN MUSS die Erfüllung dieser Anforderungen für eine transparente Zusammenarbeit gewährleisten.
[<=]

A_27142-01 - Anforderungen an Testreporting

Der AN MUSS über den Teststatus der eigenverantwortlichen Tests in der RU DEV regelmäßig berichten (Frequenz noch zu definieren), dabei werden folgende Informationen bereitgestellt: 

  1. Eine Darstellung des aktuellen Testfortschritts, einschließlich der Anzahl durchgeführter, erfolgreicher und fehlgeschlagener Tests.
  2. Einer detaillierten Erfassung aller gefundenen Fehler, inklusive Schweregrad, Priorität und Status.
  3. Informationen zur Testabdeckung, um sicherzustellen, dass alle kritischen Funktionen getestet wurden.
  4. Eine Einschätzung der identifizierten Risiken basierend auf den Testergebnissen.
[<=]