ML-162583 - TIM ePA/Pro - Anpassung der Datenlieferung

[<=]

A_25259 - Ereignisdaten - Lieferung mittels TLS

Der Anbieter MUSS die Lieferungen von Sensordaten TLS-verschlüsselt nach GS-A_4384-03 durchführen. [<=]

A_25278 - Ereignisdaten - Authentifizierung via OAuth 2.0

Der Anbieter MUSS einen "OAuth 2.0 client credentials grant flow" in Abstimmung mit der gematik implementieren.
[<=]

A_25260 - Ereignisdaten - Lieferung mittels OAuth 2.0

Der Anbieter MUSS bei der Lieferung von Sensordaten das angebotene Zugangsverfahren zum Sensorik-Endpunkt auf Basis von OAuth 2.0 [RFC6749] umsetzen. [<=]

A_25261 - Ereignisdaten - Zeitpunkt der Lieferung

Der Anbieter MUSS nach der vollständigen Verarbeitung spezifizierter Ereignisse, die erforderlichen Daten unmittelbar an den Sensorik-Endpunkt versenden. [<=]

A_25262 - Ereignisdaten - Verhalten bei fehlgeschlagener Lieferung und Retry

Der Anbieter MUSS bei einer fehlgeschlagenen Ereignislieferung an den Sensorik-Endpunkt einen Retry-Mechanismus (z.B. Exponential Backoff) implementieren, um die Ereignislieferung nachzuholen.
Diese Nachlieferung wird nur bei folgenden Return-Codes des Sensorik-Endpunktes notwendig:

A_25263 - Ereignisdaten - Format der Lieferung

Der Anbieter MUSS bei der Ereignislieferung folgende Konventionen vollständig erfüllen:

• HTTP-Aufruf konform mit [RFC7231]
• Content-Encoding: erfolgt produktspezifisch
• Content-Type: application/json
• Ausschließliche Nutzung von POST-Requests
• Spezieller POST-Body nach spezifiziertem Schema
• die URL "https://<host>:<port><path>/" im POST Request wird von der gematik vorgegeben.
• keep-alive: max. 600 Sekunden
• Request Timeout: max. 120 Sekunden

A_25264 - Ereignisdaten - Format der Lieferung - POST-Body - Integervalidierung

Der Anbieter MUSS bei der Ereignislieferung im POST-Body gewährleisten, dass alle als Integer gekennzeichneten Werte als ganzzahlige Integer im POST-Body zu berücksichtigen sind und diese DÜRFEN NICHT als String übertragen werden.

Hinweis: Die Quotierung von Integerwerten z.B. 1234 und die damit einhergehende Typänderung zu String "12345" ist unzulässig.
[<=]

A_22940-01 - Performance - Betriebsdatenlieferung v2 - Spezifika TI-M Message

Das Produkt SOLL - bei Betriebsdatenlieferungen im "message"-Feld – folgende Informationen im JSON-Format übermitteln:

{
"Inst-ID":$Instanz-ID,
"UA-PTV": $UA-Produkttypversion,
"UA-PV": $UA-Produktversion,
"UA-A": $UA-Auspraegung,
"UA-P": $UA-Plattform,
"UA-OS": $UA-OS,
"UA-OSV": $UA-OS-Version,
"UA-cid": $UA-client_id,
"M-Dom":$Matrix-Domain,
"sizeIn":$sizeIn,
"sizeOut":$sizeOut,
"tID":$telematikID,
"profOID":$professionOID,
"Res":$response
}

Für $Instanz-ID ist eine für jede Instanz eines Anwendungsfalls entsprechend [gemSpec_TI-Messenger-Dienst] gleichbleibende ID einzutragen.
Die Instanz-ID SOLL somit für die jeweiligen Operationen bzw. Teilschritte innerhalb einer Instanz eines Anwendungsfalls gleich vergeben werden. "Instanz" bezieht sich hierbei auf die Instanziierung des Anwendungsfalls, nicht die physische Instanz des Messenger-Services o.ä.
Für Felder beginnend mit "UA-" sind die entsprechenden Werte einzutragen, welche vom Client (User-Agent) übermittelt werden. Falls die Anfrage für den Teilschritt des Anwendungsfalls von einem Matrix-Server ausgeht (Server-Server API), sind die Bezeichner mit "UA-" weiterhin aufzuführen und mit dem Wert "n/a" zu befüllen.
Für $UA-Auspraegung sind ausschließlich die Werte "Org-Admin-Client" und "Messenger-Client" entsprechend der TI-M Client Spezifikation erlaubt.
Für $UA-Plattform sind ausschließlich die Werte "mobil", "stationaer", "web" entsprechend der TI-M Client Spezifikation erlaubt.
Für $UA-OS ist das entsprechende Betriebssystem einzutragen, z.B. Windows, iOS, MacOS, Android, GNU/Linux.
Für $UA-OS-Version ist die Version des Betriebssystems einzutragen.
Für $UA-client_id ist die client_id einzutragen wie sie auch dem zentralen IDP-Dienst bzw. TI-Messenger Fachdienst IdP übermittelt wird.
Für $Matrix-Domain ist die eigene Matrix-Domain des Messenger-Services einzutragen.
Für $sizeIn ist das eingehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
Für $sizeOut ist das ausgehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
Für die $telematikID ist die telematikID der zur Domäne zugehörigen SMC-B einzutragen.
Für die $professinoOID ist die professionOID der zugehörigen SMC-B einzutragen.
Für die $response ist der Statuscode als Rückmeldung der entsprechenden Anwendungsfälle einzutragen.

Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]

A_27487-01 - Performance - Ereignisdaten - Liefersystematik - Spezifika TI-Messenger Fachdienst

Der Anbieter TI-Messenger Fachdienst MUSS die Ereignisdatenlieferungen in folgenden Zeitintervallen ausführen:

• Die stündliche Ereignisdatenlieferung gemäß [A_27699]: alle 60 Minuten
• Die tägliche Ereignisdatenlieferung gemäß [A_27785]: alle 24 Stunden

A_27786 - Performance - Ereignisdaten - Datenzulieferung - Spezifika TI-Messenger Fachdienst

Der TI-Messenger Fachdienst MUSS die Inhalte der Ereignisdaten gemäß [A_27785*] und [A_27699*] für die Weiterverarbeitung durch den Anbieter zur Verfügung stellen.

A_27785 - Performance - Ereignisdaten - Post-Body - Spezifika TI-Messenger - Tägliche Lieferung

Der Anbieter TI-Messenger Fachdienst MUSS bei der täglichen Ereignisdatenlieferung im POST-Body folgendes Schema vollständig implementieren:
{
  "abfragezeitpunkt": < Zeitangabe gemäß ISO 8601 unter expliziter Angabe einer Zeitzone Format YYYY-MM-DDTHH:mm:ss[.fff]Z als String>,
  "ci": <CI-ID des abgefragten Fachdienstes gemäß [A_17764] als String>,
  "anzMs": <Anzahl der zum Abfragezeitpunkt instanziierten Messenger-Service als Integer>,
  "msList":  [{
        "md": <UUIDV4 als Ersatz für die Messenger URL als String>,
        "hsv":<Version des eingesetzten Matrix HomeServers gem. Produktversion aus [gemSpec_OM::Tab_ProdIdentZ] - String>,
        "isIns": <Handelt es sich um eine Domain für Versicherte - Boolean (true/false)>,
        "dbSize": <Größe der Homeserver-Datenbank - in KB als long>,
        "uptime": <Uptime seit dem letzten Serverstart - in s als integer>,
        "hasScan": <Wird ein serverseitiger Content Scan durchgeführt - Boolean (true/false)>,
        "anzScan": <Anzahl der von einem Content Scanner monierten Events in den letzten 24 Stunden optional - integer>,
        "anzNu": <Anzahl der zum Abfragezeitpunkt registrierten Nutzer auf dieser Domain - Integer>,
        "anzAktNu": <Anzahl der zum Abfragezeitpunkt innerhalb der letzten 30 Tage aktiven Nutzer auf dieser Domain - Integer>,
        "anzRa": <Anzahl der zum Abfragezeitpunkt bestehenden Räume auf dieser Domain - Integer>,
        "anzRaOe": <Anzahl der zum Abfragezeitpunkt bestehenden öffentlichen Räume auf dieser Domain - Integer>,
        "profOID": <Profession OID der Institution>,
        "plz": <Die ersten 2 Stellen der Postleitzahl der Instituion
         "clientOverview": [

A_27699 - Performance - Ereignisdaten - Post-Body - Spezifika TI-Messenger - Stündliche Lieferung

Der Anbieter TI-Messenger Fachdienst MUSS bei der stündlichen Ereignisdatenlieferung im POST-Body folgendes Schema vollständig implementieren:
{
  "abfragezeitpunkt": < Zeitangabe gemäß ISO 8601 unter expliziter Angabe einer Zeitzone im Format YYYY-MM-DDTHH:mm:ss[.fff]Z als String>,
  "ci": <CI-ID des abgefragten Fachdienstes gemäß [A_17764] als String>,
  "msList":  [{
        "md": <UUIDV4 als Ersatz für die Messenger URL als String>,
        "anzFed": <Anzahl der abgelehnten Anfragen, weil der anfragende Server nicht Teil der Föderation war seit dem Zeitpunkt der letzten Lieferung als integer>,    
        "anzVzd": <Anzahl der dem FHIR VZD bereitgestellten Informationen zu einem User über den /userinfo Endpunkt seit dem Zeitpunkt der letzten Lieferung als integer>,
        "anzEmpf": <Anzahl der empfangenen Nachrichten vom Typ m.room.encrypted von einem anderen Homeserver der Föderation seit dem Zeitpunkt der letzten Lieferung als integer>,
        "anzSend": <Anzahl der gesendeten Nachrichten vom Typ m.room.encrypted an einem anderen Homeserver der Föderation seit dem Zeitpunkt der letzten Lieferung als integer>,
        "anzRaEe": <Anzahl der Raeume mit einem State Event vom Typ m.room.encrypted seit dem Zeitpunkt der letzten Lieferung als integer>,
        "anzInv": <Anzahl der Invites an einen User lokal auf dem Homeserver seit dem Zeitpunkt der letzten Lieferung als integer>,
        "anzInvF": <Anzahl der Invites an einen User auf einem anderen Homeserver seit dem Zeitpunkt der letzten Lieferung als integer>,
        "anzEvEe": <Anzahl der State Events vom Typ m.room.encrypted seit dem Zeitpunkt der letzten Lieferung als integer >,
        "anzEvEeL": <Anzahl der State Events vom Typ m.room.encrypted die von einem lokalen User seit dem Zeitpunkt der letzten Lieferung gesendet wurden als integer>,
        "syncTime": {
            "min": <minimal gemessene Zeit für eine Sync Anfrage eines Clients seit dem Zeitpunkt der letzten Lieferung - in ms als integer>,
            "max": <maximal gemessene Zeit für eine Sync Aufruf eines Clients seit dem Zeitpunkt der letzten Lieferung - in ms als integer>,
            "avg": <durchschnittlich gemessene Zeit für eine Sync Anfrage eines Clients seit dem Zeitpunkt der letzten Lieferung  - in ms als integer>,
            "Q95": <95 Prozent Quantil der Sync Anfragen von Clients seit dem Zeitpunkt der letzten Lieferung - in ms als integer>,
        }
        "uploads": {
            "anzUp": <Anzahl der Uploads seit dem Zeitpunkt der letzten Lieferung als integer>,
            "anzDown": <Anzahl der Downloads seit dem Zeitpunkt der letzten Lieferung als integer>,
            "min": <minimal gemessene Upload Größe ins Media Repository seit dem Zeitpunkt der letzten Lieferung - in KB als integer>,
            "max": <maximal gemessene Upload Größe ins Media Repository seit dem Zeitpunkt der letzten Lieferung - in KB als integer>,
            "avg": <durchschnittlich gemessene Upload Größe ins Media Repository seit dem Zeitpunkt der letzten Lieferung - in KB als integer>
        }
    }]
} [<=]

A_27484 - Pseudonymisierung der Domain

Der Anbieter MUSS für jede in den Bestandsdaten enthaltene Domain eine UUIDv4 generieren und die Domain durch die UUID ersetzen. [<=]

A_27485 - Erneuerung der UUID

Der Anbieter MUSS die UUIDv4 nach 90 Tagen durch eine neu generierte UUID ersetzen. [<=]

A_27486 - Kollisionsfreiheit der UUID

Der Anbieter MUSS die verwendeten UUIDs auf Kollisionsfreiheit prüfen und bei Kollisionen eine neue UUIDv4 generieren. [<=]

A_26175 - Performance - Selbstauskunft - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Daten zur Selbstauskunft gewährleisten. [<=]

A_26178 - Performance - Selbstauskunft - Umsetzungszeit zur Änderung des Lieferintervalls

Der Anbieter MUSS die Änderung der Konfiguration vom Lieferintervall (gemäß [A_26177*]) nach Aufforderung durch die gematik innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_26177 - Performance - Selbstauskunft - Konfigurierbarkeit des Lieferintervalls

Der Produkttyp MUSS die Lieferintervalle der Selbstauskunft flexibel zwischen 1 Minute und 1440 Minuten (24 Stunden) konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

A_26176 - Performance - Selbstauskunft - Lieferintervall

Der Produkttyp MUSS die Selbstauskunft in einem konfigurierbaren Lieferintervall senden. Sofern nicht explizit anders spezifiziert, ist das Lieferintervall von 60 Minuten als Default-Wert zu nutzen. [<=]

A_26174 - Performance - Selbstauskunft - Verpflichtung zur Erfassung

Der Produkttyp MUSS notwendige Metadaten für die Lieferung einer Selbstauskunft erfassen und verarbeiten. [<=]

A_26181 - Performance - Selbstauskunft v2 - Format und Übermittlung

Der Produkttyp MUSS notwendige Metadaten für die Selbstauskunft im JSON-Format gemäß A_26180 erfassen, verarbeiten und an die Schnittstelle I_OpsData_Update der Betriebsdatenerfassung gemäß [gemSpec_SST_LD_BD] versenden. [<=]

A_26180 - Performance - Selbstauskunft v2 - Grundgerüst

Der Produkttyp MUSS folgende Werte als Grundgerüst für die Selbstauskunft v2 im angegebenen Format zusammenstellen und liefern.
{

A_27766 - Performance - Selbstauskunft v2 - Schemaversion 2

Der Produkttyp MUSS folgende Werte für die Selbstauskunft v2 im angegebenen Format zusammenstellen und liefern.
{
   "timestamp": < Zeitangabe als String gemäß ISO 8601 unter expliziter Angabe einer Zeitzone im Format YYYY-MM-DDTHH:mm:ss[.fff]Z, als String >,
   "ci": < logische CI-ID des abgefragten Dienstes gemäß TI-ITSM, als String >,
   "manCount": < Gesamtanzahl aller Mandanten des Dienstes, als Integer >,
   "manList": [{
       "ptv": < Produkttypversion gem. gemSpec_OM::ProductTypeVersion des Resource Servers, als String >,
       "pv": < Produktversion gem. gemSpec_OM::Tab_ProdIdent des Resource Servers, als String >,
       "konv": < Konfigurationsversion gem. [A_20219-01] des Resource Servers, als String >,
       "cnt": < Anzahl von Mandanten in dieser Versions-Kombination, als Integer >
     }],
   "sv": 2
}

Hinweis: Für jede Kombination aus Produkttypversion, Produktversion und Konfigurationsversion ist ein neues Objekt im Array "manList" zu erstellen und die Anzahl der Mandanten in dieser spezifischen Konfiguration im Feld "cnt" einzutragen. Die Summe der Einzelwerte von "cnt" aller angegebenen Mandanten aus dem Array "manList" muss mit dem Gesamtwert aus dem Feld "manCount" übereinstimmen.
[<=]