Telematikinfrastruktur 2.0
Spezifikation:
TI-Flow-Fachdienst
| Version | 1.0.0_CC |
| Revision | 1649056 |
| Stand | 30.06.2026 |
| Status | zur Abstimmung freigegeben |
| Klassifizierung | öffentlich_Entwurf |
| Referenzierung | gemSpec_FD_TI-Flow |
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 | |
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.
Das Dokument richtet sich an den Hersteller des TI-Flow-Fachdienstes, sowie an Hersteller und Anbieter von Clientsystemen des TI-Flow-Fachdienstes.
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) festgelegt 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.
Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zum Themenbereich:
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.
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.
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.
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.
Der Hersteller des TI-Flow-Fachdienstes implementiert und entwickelt den TI-Flow-Fachdienst gemäß [gemProdT_TI-Flow-FD].
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.
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.
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.
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.
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.
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.
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.
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. [<=]
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. [<=]
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:
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
Für den ZETA Guard gibt es entsprechende Anforderungen für die Kommunikation ins Internet.
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. [<=]
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. [<=]
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.
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].
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.
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
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:
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. [<=]
Die Ingress Komponente bietet die Möglichkeit der Konfiguration von Ratelimits.
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. [<=]
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.
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.
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.
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. [<=]
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.
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.
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.
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. [<=]
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:
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. [<=]
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. [<=]
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. [<=]
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.
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.
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
| 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 |
| 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.
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 |
| [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 |
In diesem Anhang können Anteile erfasst werden, welche später in übergreifende Dokumente übernommen werden.
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:
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:
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. [<=]
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.
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:
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.
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.
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.
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:
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. [<=]
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 |
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 [<=]
A_23350 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag eingeschränkt
Das Produkt MUSS folgende Servicezeiten gewährleisten:
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* |
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.
[<=]
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 |
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 |
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 |
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 |
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 |
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:
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:
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:
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:
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: