C_12625_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

Während des Freigabeprozesses für die PoPP Service Spezifikation Stufe 1 wurde im Rahmen der Umsetzung weiterer Änderungsbedarf an der PoPP-Service Spezifikation identifiziert.
Es handelt sich in der Hauptsache um technische Detaillierungen und/ oder Korrekturen.

2 Änderung in gemSpec_PoPP_Service

2.1 gem_16 - Error Codes (P_POPP-25)

Status: in gemSpec_PoPP_Service eingearbeitet

Änderung 1: Das Kapitel "6.1.1.8 eGK-Handling Fehlercodes" wird inklusive seiner Kapitelüberschrift aus gemSpec_PoPP_Service entfernt wodurch unter anderem A_27049 wegfällt.

Änderung 2: Der komplette Inhalt von 6.3 wird durch folgenden Passus ersetzt, wodurch unter anderem A_26500 wegfällt.

Error Code (HTTP Status Code. ergänzt um operationsspezifische Ergebnisse) werden in den jeweiligen Schnittstellen Dateien (yaml-Files) erfasst und dokumentiert.

2.2 gem_25 & P_POPP-30 : Unterscheidung Kartengeneration

Status: in gemSpec_PoPP_Service eingearbeitet

Hintergrundinformation: Die Menge eGKincludedPtvObjSys enthält keine Informationen darüber, ob eine derart erlaubte eGK vom Typ G2.x oder Gx.y ist. Diese Unterscheidung ist gemäß Abbildung 7 wichtig.

2.2.1 gem_25.a

Ein Absatz in 6.1.1.3 wird wie folgt geändert:
Definition: eGKincludedPtv4ObjSys ist eine Menge mit Produkttypversionen von eGK G2.x Objektsystemen, die der PoPP-Service zu unterstützen hat.
Definition: eGKincludedPtv5ObjSys ist eine Menge mit Produkttypversionen von eGK Gx.y Objektsystemen, die der PoPP-Service zu unterstützen hat.
Produkttypversionen werden in diese Menge die Mengen eGKincludedPtv4ObjSys oder eGKincludedPtv5ObjSys aufgenommen oder aus ihr ihnen entfernt, wenn sich die Anforderungslage (also die Vorgaben der gematik) ändern. Basierend auf den Erfahrungen der Vergangenheit ist davon auszugehen, dass sich diese Menge nur wenige Male pro Jahr ändert, während sich die Anzahl zugelassener Kartenprodukte häufiger ändert. Deshalb wird die Menge zulässiger Kartenprodukte über die Produkttypversion definiert.

2.2.2 gem_25.b

Der Hinweis unterhalb von A_27019 wird durch folgenden ersetzt:
Hinweis: Die Produkttypversion eines Kartenproduktes findet sich in der Datei EF.Version2. Basierend auf der Anforderungslage der gematik besteht die Menge eGKincludedPtv4ObjSys im Januar 2026 aus folgenden Elementen:
{'040400', '040401', '040500', '040501', '040502', '040600', '040700'}. Die Menge eGKincludedPtv5ObjSys ist mit Stand Januar 2026 leer. Mit Einführung einer zukünftigen eGK Version Gx.y wird die Menge (laut aktuellem Plan) um den Wert '050000' ergänzt.

2.2.3 gem_25.c & P_POPP-30

In A_27009 Punkt 2.a wird folgende Änderung vorgenommen:
ersetze "eGKincludedPtvObjSys" durch "eGKincludedPtv4ObjSys oder eGKincludedPtv5ObjSys"

A_27018 und A_27019 werden wie folgt geändert:
A_27018 -PoPP-Service, Zulässige eGK Objektsystemversionen
Der PoPP-Service MUSS Änderungen an der Menge eGKincludedPtvObjSysdie Mengen eGKincludedPtv4ObjSys und eGKincludedPtv5ObjSys konfigurierbar gestalten und Änderungen , die ihm
ausschließlich durch die gematik angezeigt werden, innerhalb von sieben Tagen im
Betrieb berücksichtigen. Hinweis: Änderungen an den hier behandelten Mengen erfolgen per SerivceRequest im Service-Katalog durch die gematik.[<=]
A_27019 -PoPP-Service, Unzulässige eGK Objektsystemversionen
Der PoPP-Service MUSS Änderungen an der Menge die Menge eGKexcludedPiObjSys konfigurierbar gestalten und Änderungen, die ihm ausschließlich durch die gematik angezeigt werden, innerhalb von 24 Stunden im Betrieb
berücksichtigen. Hinweis: Änderungen an der hier behandelten Menge erfolgen per SerivceRequest im Service-Katalog durch die gematik.[<=]

2.3 gem_26 & P_POPP-151: A_27045

Status: in gemSpec_PoPP_Service eingearbeitet

Derzeit erfordert A_27045 eine "synchrone" Verarbeitung: Die Daten eContent werden vom TSP an den PoPP-Service übermittelt, in die eGK-Hash-Datenbank importiert und dann wird in derselben TLS-Session eContentResponse übermittelt.
Nach den Erfahrungen mit PoC und Beispielimplementierung dauert der Import einer großen Anzahl von eGKs eine gewisse Zeit, während der die eGK-Hash-Datenbank mit verringerter Geschwindigkeit arbeitet. Performanter ist es die Daten zunächst "asynchron" in eine offline Variante der eGK-Hash-Datenbank zu übernehmen. Dazu werden folgende Änderungen vorgenommen:

2.3.1 Ergänzung I_PoPP_EHC_CertHash_Import.json

Im Kapitel zu referenzierten Dokumenten der gematik wird folgende Zeile neu aufgenommen:

[I_PoPP_EHC_CertHash_Import]

OpenAPI Schnittstellenspezifikation für den Import von Daten in die eGK-Hash-Datenbank https://github.com/gematik/api-popp/blob/3.1.0/src/openapi/I_PoPP_EHC_CertHash_Import.json

2.3.2 Änderungen an A_27044

A_27044 wird geändert (siehe auch 2.16, P_POPP-148, IP vs. URL):

2.3.3 Änderungen an A_27045

A_27045 wird ersetzt durch folgenden Passus:

Die Verarbeitung gemäß A_27623 wird eine gewisse Zeit in Anspruch nehmen. Es gilt:

. . .

Hinweis 3: Gemäß A_28898 gliedert sich der Import in mehrere Schritte. Die importierte Nachricht wird zunächst auf einige Aspekte hin überprüft, was möglicherweise zu Fehlermeldungen führt und später möglicherweise auf weitere Aspekte, was möglicherweise zu weiteren Fehlermeldungen führt. Je nachdem welche und wie viele Aspekte wo überprüft werden, ist es möglich, dass eine konkrete Implementierung in eContentResponse nie den Status „invalidMessage“ liefert.

. . .

Hinweis 5: Es ist denkbar, dass für die Umsetzung der Importfunktion eine Implementierung gewählt wird, wo (kurz) vor dem Beginn der Verarbeitung gemäß A_27623* eine Kopie der eGK-Hash-Datenbank erstellt wird. Dann gibt es die „DB-Original“ von der die Kopie gezogen wurde und die „DB-Kopie“. Die Importfunktion arbeite dann mit „DB-Kopie“ und erstelle dabei die Antwort eContentResponse. Weiterhin ist es denkbar, dass während der Verarbeitung in „DB-Original“ Einträge blockiert werden, die in eContent für den Import vorgesehen sind. Es ist zulässig, dass in so einem Fall die Rückantwort eContentResponse einen in „DB-Original“ (frisch) gesperrten Eintrag NICHT in der Liste listBlocked enthält, weil er in „DB-Kopie“ ja nicht blockiert ist. Kostenträger werden dann nicht über eContentResponse, sondern über den in A_28902 dargestellten Mechanismus über blockierte eGK informiert. Im hier geschilderten Fall (Eintrag in „DB-Original“ (frisch) blockiert in „DB-Kopie“ nicht blockiert) fordert A_28895, dass bei der „Konsolidierung / Synchronisierung“ von „DB-Original“ und „DB-Kopie“ der in „DB-Original“ blockierte Eintrag weiterhin blockiert bleibt.

Hinweis 6: Nachdem ein Lieferant eine „POST…“ Nachricht an den PoPP-Service geschickt hat, ist es dem Lieferanten möglich keine, eine oder mehrere „GET…status“ Nachrichten zu schicken. Erst wenn der PoPP-Service so eine Nachricht mit „FINISHED“ beantwortet ist es sinnvoll eine „GET…result“ Nachricht zu schicken.

Hinweis 7: Nach dem Empfang eines „FINISHED“-Status ist es einem Lieferanten möglich innerhalb der Speicherzeit keine, eine oder mehrere „GET…result“ Nachrichten an den PoPP-Service zu schicken. Erst nach dem Empfang und einer erfolgreichen Verarbeitung der eContentResponse ist es für einen Lieferanten sinnvoll eine „DELETE…{jobId}“ Nachricht zu schicken.

Hinweis 8: Wenn ein Lieferant bereits Daten importierte, dann ist ein weiterer Import nur möglich, wenn die zugehörige eContentResponse im PoPP-Service vorliegt und gelöscht wurde. Eine eContentResponse wird entweder nach der Mindestspeicherzeit gemäß A_28896 vom PoPP-Service automatisch gelöscht, oder durch eine „DELETE…{jobId}“ Nachricht.

2.3.4 Änderungen an A_27623

A_27623 Punkte 6.c und 6.d werden geändert. A_27623 Punkt 6.e wird entfernt.

2.4 gem_27 & P_POPP-150: A_27045 Punkt 6

A_27045 Punkt 6 beschreibt etwa listIncorrect, listExpired, listIgnored, listBlocked als SEQUENCE. Korrekt wäre SEQUENCE OF.

Dieses Problem wird zusammen mit gem_26 gelöst, siehe dort.

2.5 gem_28 & P_POPP-142: A_26631

Status: in gemSpec_PoPP_Service eingearbeitet

A_26631 legt fest, dass in APDU-Pakete eine OCSP-Response einzubetten ist, die nicht älter als zehn Minuten ist. Ein timeout für die OCSP Abfrage wird dort nicht festgelegt. Ein timeout kann vom der PoPP-Service Implementierung beliebig gewählt werden, ohne dass sich dieser Wert durch White-Box-Testing feststellen ließe. Aus Sicht der Implementierung erscheint es sinnvoll für ALLE Zertifikatsprüfungen denselben timeout-Wert (also zehn Sekunden) zu verwenden. Zur Unterstützung dieser Sichtweise wird am Ende von A_26631 folgender Passus ergänzt:
und einen kontinuierlichen Betrieb gewährleisten unter der Randbedingung, dass es möglich ist, dass zwischen einer OCSP-Anfrage und ihrer OCSP-Antwort bis zu zehn Sekunden liegen

2.6 gem_29: A_28547

Status: in gemSpec_PoPP_Service eingearbeitet

Es fehlt eine Festlegung zum timeout der OCSP-Abfrage. Deshalb wird am Ende von A_28547 folgender Passus ergänzt:
, wobei als timeout für die OCSP-Abfrage zum C.FD.TLS-C.Zertifikat ein Wert von zehn Sekunden verwendet werden MUSS

2.7 gem_30: Kap. 5.6

Status: in gemSpec_PoPP_Service eingearbeitet

Im Kapitel 5.6 Federation Entity Statement gibt es aktuell noch die Unterscheidung zwischen PoPP-Authorization Server und PoPP-Resource Server. Es sollte einheitlich von PoPP-Service gesprochen werden.

Begründung:
Mit der geänderten Architektur unter Nutzung der ZETA-Komponenten gibt es keinen PoPP-Authorization Server mehr. Eine getrennte Betrachtung Authorization Server / Resource Server ist deshalb nicht notwendig

Änderungsvorschlag:
" .... Metadaten Informationen zur Konfiguration als:
1. OAuth Protected Resource (oauth_resource),Teilnehmer der TI-Föderation (federation_entity).

Die Metadaten enthalten u. a. die Endpunkte, unter denen der PoPP-Service Authorization Server erreichbar ist und Informationen zu Signatur- und Verschlüsselungsschlüssel. Die Tabelle "Entity Statement des PoPP-Service" im Anhang stellt das Entity Statement des PoPP-Service Authorization Server exemplarisch dar. Die folgenden Anforderungen werden an die Inhalte des Entity Statement gestellt:

2.8 gem_31: A_27295

Status: in gemSpec_PoPP_Service eingearbeitet

Die Anforderung lautet aktuell: "PoPP-Service - Bereitstellung .well-known für PoPP-Service Resource Server"
Da es keine Trennung Authorization Server / Resource Server mehr gibt sollte der Afo Text entsprechend angepasst werden.
Vorschlag:
"... PoPP-Service - Bereitstellung oauth_resource im .well-known für den PoPP-Service"

Begründung: 
Mit der geänderten Architektur unter Nutzung der ZETA-Komponenten gibt es keinen PoPP-Authorization Server mehr. Eine getrennte Betrachtung Authorization Server / Resource Server ist deshalb nicht notwendig

2.9 gem_32: FQDN für PoPP Service

Status: ist in gemSpec_PoPP_Service eingearbeitet

Die FQDN für den PoPP-Service werden festgelegt. Die Information ist für den PoPP-Service Hersteller und die nutzenden Systeme (Clients) wichtig.
In Kapitel  8 "Betrieb" wird folgendes, neues Kapitel aufgenommen und A_27390 dorthin verschoben:

2.9.1 Kapitel 8.3: Dienstlokalisierung PoPP Service

Die Lokalisierung des PoPP-Service für Clients, die den PoPP verwenden, erfolgt mittels eines generischen DNS-Musters: <Hostname>.<Umgebung>.<Domäne-Anbieter>.
Für den Betrieb des PoPP-Service ist eine DNS-Registrierung unter der Domäne poppservice.de erforderlich. Zu den zugreifenden Clients gehören die PoPP-Clients in den Primärsystemen sowie später die PoPP-Module, die über Apps auf Versicherten-Smartphones auf den PoPP Service zugreifen.

2.10 gem_34: Vertrauenswürdige Zeit

Status: in gemSpec_PoPP_Service eingearbeitet

1. Anpassung in Kapitel 5.5 wie folgt:

5.5 Vertrauenswürdige Uhrzeit im PoPP-Service

...

...

2. Die Anforderung wird dem Sicherheitsgutachten (Anbieter) zugeordnet, da es nun vermehrt Prozesse des Anbieters betrifft.
3. Der TI Security Standard [TI-SEC-Standard] muss in die Referenzen/Dokumentenliste aufgenommen werden.

2.11 OID für TSP

Status: in gemSpec_PoPP_Service eingearbeitet

Im Release Candidate von gemSpec_PoPP-Service wird die OID für TSP wie folgt benannt: oid_tsp_egk

In gemSpec_OID wird diese OID wie folgt benannt: oid_tsp-egk (Unterstrich und Bindestrich)

In gemSpec_PoPP-Service wird an allen Stellen "oid_tsp_egk" ersetzt durch "oid_tsp-egk". Das betrifft A_27044, A_28547 und A_28548.

2.12 P_POPP-133: A_26495 Hinweis entfällt

 Status: in gemSpec_PoPP_Service eingearbeitet

Hinweis: Für den Token-Signatur-Schlüssel wird zusätzlich zur Veröffentlichung via Entity Statement/JWKS (siehe A_26434* und A_26533*) ein Zertifikat mit entsprechender Rolle aus der Komponenten-PKI der TI ausgestellt und in die PoPP-Token eingebettet. Somit können FD entscheiden, ob sie die Token über den vom Federation Master oder den von der TI-PKI aufgespannten Vertrauensraum prüfen. Der Hersteller benötigt das Zertifikat um das Einbetten dieses Zertifikats in die PoPP-Token umsetzen zu können.

2.13 ANFTI2-154: A_26543 entfällt

 Status: in gemSpec_PoPP_Service eingearbeitet

Mit A_28526 aus gemSpec_ZETA  wird die Bereitstellung von ZETA Guard-Container Images über ein eine lokale Artifact Registry vorgeschrieben.
Damit entfällt die Anforderung A_26543, in der ein Zero Trust git-Repository der gematik angeführt wird, das nicht mehr vorgesehen ist.  -> A_26543 wird gestrichen. 
Das Sicherstellen der Kommunikation vom PoPP Service zu PIP/PAP wird über A_27795 aus gemSpec_ZETA gefordert.

Im Kapitel 5.4.1 "Bereitstellung, Konfiguration und Verwendung vom ZETA Guard" wird die Anforderung A_26543 entfernt. Die Anforderung entfällt.

Darüber hinaus wird folgender Teil des unter A_26543 stehenden Hinweises gestrichen:
Die URL inklusive Endpunkt für den PoPP-Service für das Zero Trust git-repository der gematik wird organisatorisch übermittelt

2.14 P_POPP-164: A_26540 entfällt

 Status: in gemSpec_PoPP_Service eingearbeitet

A_26540 besagt: Der Anbieter des PoPP-Service MUSS bei der Erstellung der Policy für den PoPP-Service mit der gematik zusammenarbeiten. Diese Policy wird über den PAP deployed und durch die Policy-Engine verarbeitet.
Diese Anforderung wird nicht benötigt, es ist keine direkte Zusammenarbeit bei der Erstellung der Policies notwendig.
Afo wird gestrichen A_26540

Im Kapitel 5.4.1 "Bereitstellung, Konfiguration und Verwendung vom ZETA Guard" wird die Anforderung A_26540 entfernt. Die Anforderung entfällt.

2.15 Rückfrage E-Rezept: ES/OCSP Grace Period

 Status: in gemSpec_PoPP_Service eingearbeitet

Es ist in 5.1.2 PoPP-Token Prüfung nicht vorgegeben, wie bei Nicht-Verfügbatkeit von OCSP oder EntityStatement/jwks Download vorgegangen werden soll. Dies wird präzisiert.

Bzgl. OCSP wird ergänzt:

Hinweis: Bei Nichterreichbarkeit des OCSP-Responders in A_27016* soll zunächst keine Takterhöhung der Abfragen stattfinden um Überlasten zu vermeiden. Um das Ablaufen der Nutzbarkeit der vorhanden OCSP-Response nach 24h zu vermeiden, kann eine Takterhöhung nach mehrfacher Nichterreichbarkeit erfolgen (bspw. nach 12h auf alle 30min und nach 18h auf 10min und nach 20h auf 5min).

Bzgl. Entity Statment / JWKS wird ergänzt:

Hinweis: Bei Nichterreichbarkeit der Downloadpunkte in A_26449* soll zunächst in kürzeren Abständen (bspw. minütlich) ein erneuter Abrufversuch stattfinden und erst nach mehrfachen (bspw. 3) erfolglosen Versuchen ein Incident über das TI-ITSM eröffnet werden.

Hinweis: Wird der Sperrstatus des PoPP-Token-Signaturzertifikats im Rahmen einer Prüfung nach TI-PKI per OCSP ermittelt (siehe A_27016*) und  als "good" ausgewertet, ist bei Nichterreichbarkeit der jeweiligen Downloadpunkte eine Überschreitung des in A_26449* für Entity Statements und JWKS angegebenen Gültigkeitzeitraums (also deren Weiterverwendung nach Ablauf des Zeitraums) um wenige Tage akzeptabel.

2.16 P_POPP-148: A_27044, IP vs. URL Schnittstelle

 Status: in gemSpec_PoPP_Service eingearbeitet

In A_27044 wird in den Punkten 2 und 3 folgende Änderung vorgenommen:

ersetze    IP-Adresse
durch      URL

Hinweis: Diese Änderungen sind in 2.3.2 in Verbindung mit P_POPP-151 dargestellt.

2.17 Kurzzeitprotokoll, Meldewege, P_POPP-139, 234

Status: in gemSpec_PoPP_Service eingearbeitet TODO entspricht das dem endgültig abgestimmten Stand?

Blockierte Einträge werden nun nicht nur im laufenden Betrieb, sondern auch beim Import erfasst und im Kurzzeitprotokoll abgelegt. Einträge des Kurzzeitprotokolls werden nun an die gematik gemeldet und der Meldeweg an Kostenträger wird präzisiert.

2.17.1 Änderungen an A_27622

In A_27622 wird Punkt 5.e inklusive der Unterpunkte durch folgenden Passus ersetzt:

Logging innerhalb der „check(. . .)"-Funktion: Es wird ein Log-Eintrag mit hashCvc und hashAut erzeugt, falls während der Abarbeitung der „check(. . .)-Funktion der Wert “blocked” zurückgegeben wird.

2.17.2 Zusatz unterhalb von A_27623

Nach A_27623 wird folgender Passus neu aufgenommen:

Hinweis 1: Aus A_28923 folgt für den Fall, dass eContent zwei Pärchen {hashCvc, hashAut} enthält (etwa einmal für "remove" und einmal für "import"), es nicht sicher ist, in welcher Reihenfolge diese Pärchen bearbeitet werden.

Definitionen:

1. Sei {hashCvcX, hashAutX} ein in der eGK-Hash-Datenbank nicht blockiertes Pärchen von Hashwerten.
2. Sei {hashCvcY, hashAutY} ein in der eGK-Hash-Datenbank nicht blockiertes Pärchen von Hashwerten.
3.  Sei “iccsnZ” die ICCSN aus einem CV-Zertifikat CVC-Z.
4. Sei “hashCvcZ” der SHA-256 Hashwert über das CV-Zertifikat CVC-Z.
5. Sei “ikZ” die IK-Nummer aus einem X.509-Zertifikat AUT-Z.
6. Sei “kvnrZ” die KVNR aus dem X.509-Zertifikat AUT-Z.
7. Sei “hashAutZ” der SHA-256 Hashwert über das X.509-Zertifikat AUT-Z.

Abbildung 1 : JSON-Beispiel für einen Eintrag in einer gematik-Meldung, siehe A_28902, Punkt 1

Abbildung 2 : JSON-Beispiel für einen Eintrag in einer Kartenherausgeber-Meldung, siehe A_28902, Punkt 2.a

Abbildung 3 : JSON-Beispiel für einen Eintrag in einer Kostenträger-Meldung, siehe A_28902, Punkt 2.b

Hinweis 1: Kartenherausgeber oder Kostenträger, die keinen Eintrag in die Tabellen gemäß A_28903 vornehmen lassen werden nicht direkt über blockierte Einträge informiert. Es besteht die Möglichkeit, dass die gematik über blockierte Einträge informiert, wenn diese über die Telemetriedaten an die gematik gemeldet werden. Gemäß A_28902 Punkt 1.b ist es unmöglich, dass eine Meldung über die gematik personenbezogene Daten (die komplette ICCSN oder die KVNR) enthält.

2.18 Wording: ZETA Produkthandbuch statt Betriebshandbuch

 Status: in gemSpec_PoPP_Service eingearbeitet

In gemSpec_PoPP_Service#Kap 5.4 und in A_26539 wird vom Betriebshandbuch des ZETA Guard Herstellers besprochen. Im ZETA Projekt wird jetzt die Bezeichnung Produkthandbuch verwendet. Die PoPP-Service Spezifikation soll entsprechend angepasst werden.

2.19 Sammler für Typos

1. Im Hinweis unter A_26543 heißt es: Die Verfügbarkeit von ZETA Guard soll durch die Bereitstellung einer lokalen Container Registry erhöht werden, siehe auch A_28256* 
   Die zitierte Afo ist die A_28526*

2.20 Paralleler Token-Abruf, P_POPP-130

 Status: in gemSpec_PoPP_Service eingearbeitet

Es wird ein neues Kapitel 6.4 mit folgendem Inhalt erstellt:

6.4 Kommunikationskanal Client - PoPP-Serivce

Für den Kommunikationskanal zwischen der Client und dem PoPP-Service gilt folgendes:

1. Ein Client baut zunächst eine TCP/IP Verbindung zum PoPP-Service auf.
2. Dann initiiert der Client einen TLS-Handshake mit dem PoPP-Service.
3. Anschließend verwendet der Client HTTP/1.1 für die Kommunikation zwischen ZETA Client und ZETA Guard.
4. Als nächstes initiiert der Client einen WebSocket Handshake gemäß [RFC 6455].
5. Anschließend ist der Client in der Lage gemäß der API-Spezifikation mit dem PoPP-Service Nachrichten auszutauschen.

Hinweis 1: Als Konsequenz der Anforderungen aus diesem Unterkapitel ergibt sich, dass von einem Client pro Aufbau einer WebSocket-Verbindung maximal ein PoPP-Token abrufbar ist.

3 Änderungen in gemKPT_Test

3.1 P_POPP-218: A_26688 - Labeln von Komponenten

Die Afo A_26688 aus gemKPT_Test ist ursprünglich mit dem Hintergrund dezentraler Komponenten aufgenommen worden. Dieser Kontext liegt jedoch nicht vor, sodass die Anforderung nicht einschlägig ist.
Die Afo A_26688 wird daher aus dem Produkttypsteckbrief entfernt.
Änderung in gemKPT_Test ggf später.

Status:  wip und nicht in gemSpec_PoPP-Service eingearbeitet.

4 Änderungen in Steckbriefen

4.1 Änderungen in gemProdT_PoPP_Service_PTV

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_PoPP_Service_PTV]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 3: Anforderungen zur funktionalen Eignung "Produkttest/Produktübergreifender Test"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
A_23225	lokales Caching von Sperrinformationen und Toleranzzeiten Zuordnung wird von funktionale Eignung / Test ==> nach funkt. Eignung/ Herstellererklärung geändert	gemSpec_PKI (P_POPP-182)
A_27791	Zuordnung von A_27791 aus gemKPT_Test wird wird entfernt.	gemKPT_Test (P_POPP-184 & P_POPP-203)
A_26688	Zuordnung von A_26688 aus gemKPT_Test wird wird entfernt.	gemKPT_Test (P_POPP-218)
A_26910	Zuordnung von A_26910 aus gemKPT_Test wird wird entfernt.	gemKPT_Test (P_POPP-224)
TIP1-A_7335	Zuordnung hinzugefügt, Prüfverfahren "funkt. Eignung Herstellererklärung"	gemKPT_Test

4.2 Änderungen in gemAnbT_PoPP_Service_ATV

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemAnbT_PoPP_Service_ATV]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 4: Anforderungen zur funktionalen Eignung "Produkttest/Produktübergreifender Test"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
A_27829	Zuordnung von A_27829  aus gemKPT_Test wird wird entfernt.	gemKPT_Test
A_27815	Zuordnung von A_27815 aus gemKPT_Test wird wird entfernt.	gemKPT_Test
A_25392-01	Zuordnung hinzugefügt, Prüfverfahren "organ./betriebl. Eignung: Anbietererklärung"	gemKPT_Test
TIP1-A_7335	Zuordnung hinzugefügt, Prüfverfahren "organ./betriebl. Eignung: Anbietererklärung"	gemKPT_Test