[ { "c_id" : "C_12118", "title" : "E-Rezept: Aufnahme der FHIR Packages ins BDEv2", "source_polarion_documents" : "Spezifikation / gemSpec_Perf", "change_reason" : "Die FHIR-Paketversionen sollen in die Betriebsdaten integriert werden, um einen reibungslosen Übergang zwischen den Versionen sicherzustellen. Dadurch kann die Umsetzung auf der Clientsystemseite (Primärsysteme, Frontend des Versicherten) überwacht werden. Bei fehlender Umsetzung sollte der Hersteller kontaktiert werden, um den kontinuierlichen Betrieb des E-Rezept-Fachdienstes zu gewährleisten.", "change" : "gemSpec_Perf Kapitel 3.2.2\nAlt:\n A_23090-05 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Message\n Der Produkttyp E-Rezept-Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes \"message\" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.\n{ \"cid\": \"$clientid\", \"ua\": \"$useragent\", \"leip\": \"$leipseudonym\", \"size\": $size, \"bkdur\": $backendduration, \"mvonr\": $mvo-nummer, \"vnr\": $vorgangsnummer, \"anr\": $anrvalue, \"zanr\": $zanrvalue, \"it\": $fhir-issue-type, \"ec\": $error-component, \"sec\": $suberror-component, \"suf\": $error-suffix, \"epa\": $epa, \"wf\": $workflow, \"fsc\": $freischaltcode. \"tldur\": $throttlingduration\"}\n * $clientid: Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String\n* $useragent: HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme, Datentyp String\n* $leipseudonym: Stark pseudonymisierte Telematik-ID, Datentyp String\n* $size: Größe des Requests in kilobyte, Datentyp Integer\n* $backendduration: Zeit in ms für Abfragen an OCSP, für die Anfragen an die ePA Aktensysteme oder analogen Backendsystemen, Datentyp Integer\n* $mvo-nummer: Der Wert Nummer des Rezepts der Mehrfachverordnung, Datentyp Integer\n* $vorgangsnummer: Task-ID im Fachdienst, Datentyp String\n* $anrvalue: Der Wert des Feldes identifier:ANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer\n* $zanrvalue: Der Wert des Feldes identifier:ZANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer \n* $fhir-issue-type: Der Wert der Kategorie im OperationOutcome Fehlercode, Datentyp String\n* $error-component: Der Wert des Objektes im OperationOutcome Fehlercode, Datentyp String\n* $suberror-component: Der Wert der Regel im OperationOutcome Fehlercode, Datentyp String\n* $error-suffix: Der Wert des Suffixes im OperationOutcome Fehlercode, Datentyp String\n* $epa: Der Wert der Subdomain der URL des ePA-Aktensystems, Datentyp String\n* $workflow: Der Wert des E-Rezept Workflows bei Aufruf einer E-Rezept-ID, Datentyp Integer\n* $freischaltcode: Rückgabewert (1 oder 0) ob der Freischaltcode für ERP.UC_4_4 mit Workflow 162 übertragen wurde (wurde übertragen = 1, wurde nicht übertragen = 0), Datentyp Integer\n* $throttlingduration: Drosselungszeit eines User Agents in ms, Datentyp Integer \nBei 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. <=\t\nNeu:\nAufnahme der 4 Messagefeld Erweiterungen: gematikworkflowprofil, gematikpatientenrechnung, kbvverordnungsdaten, davabgabedaten\nA_23090-06 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Message\n Der Produkttyp E-Rezept-Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes \"message\" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.\n{ \"cid\": $clientid, \"ua\": $useragent, \"leip\": $leipseudonym, \"size\": $size, \"bkdur\": $backendduration, \"mvonr\": $mvo-nummer, \"vnr\": $vorgangsnummer, \"anr\": $anrvalue, \"zanr\": $zanrvalue, \"it\": $fhir-issue-type, \"ec\": $error-component, \"sec\": $suberror-component, \"suf\": $error-suffix, \"epa\": $epa, \"wf\": $workflow, \"fsc\": $freischaltcode, \"tldur\": $throttlingduration\", \"gwp\": $gematikworkflowprofil, \"gpr\" :$gematikpatientenrechnung, \"kbv\": $kbvverordnungsdaten, \"dav\": davabgabedaten}\n* $clientid: Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String\n* $useragent: HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme, Datentyp String\n* $leipseudonym: Stark pseudonymisierte Telematik-ID, Datentyp String\n* $size: Größe des Requests in kilobyte, Datentyp Integer\n* $backendduration: Zeit in ms für Abfragen an OCSP, für die Anfragen an die ePA Aktensysteme oder analogen Backendsystemen, Datentyp Integer\n* $mvo-nummer: Der Wert Nummer des Rezepts der Mehrfachverordnung, Datentyp Integer\n* $vorgangsnummer: Task-ID im Fachdienst, Datentyp String\n* $anrvalue: Der Wert des Feldes identifier:ANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer\n* $zanrvalue: Der Wert des Feldes identifier:ZANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer \n* $fhir-issue-type: Der Wert der Kategorie im OperationOutcome Fehlercode, Datentyp String\n* $error-component: Der Wert des Objektes im OperationOutcome Fehlercode, Datentyp String\n* $suberror-component: Der Wert der Regel im OperationOutcome Fehlercode, Datentyp String\n* $error-suffix: Der Wert des Suffixes im OperationOutcome Fehlercode, Datentyp String\n* $epa: Der Wert der Subdomain der URL des ePA-Aktensystems, Datentyp String\n* $workflow: Der Wert des E-Rezept Workflows bei Aufruf einer E-Rezept-ID, Datentyp Integer\n* $freischaltcode: Rückgabewert (1 oder 0) ob der Freischaltcode für ERP.UC_4_4 mit Workflow 162 übertragen wurde (wurde übertragen = 1, wurde nicht übertragen = 0), Datentyp Integer\n* $throttlingduration: Drosselungszeit eines User Agents in ms, Datentyp Integer \n* $gematikworkflowprofil: FHIR Profil Version des gematik eRezept Worklow Package, Datentyp String\n* $gematikpatientenrechnung: FHIR Profil Version des gematik eRezept Patientenrechnungs Package, Datentyp String\n* $kbvverordnungsdaten: FHIR Profil Version des KBV Verordnungsdatensatz Package, Datentyp String\n* $davabgabedaten: FHIR Profil Version des DAV Abgabedatensatz Package, Datentyp String\nBei 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. <=\nPrüfverfahren: funkt. Eignung: Test/ProduktFA", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemSpec_Perf", "effected_other_documents" : "", "upserted_requirement_ids" : "A_23090-06", "removed_requirement_ids" : "A_23090-05", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_12113", "title" : "E-Rezept-Fachdienst: OperationOutcome für noch nicht einlösbare Teilverordnung einer MVO erweitern", "source_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "change_reason" : "Nach dem Stecken der eGK erhält ein AVS die Liste der einlösbaren Rezepte. Im nachfolgenden Schritt lädt das AVS die Verordnungsdaten zu jedem Rezept herunter. Für noch nicht einlösbare Teilverordnungen einer Mehrfachverordnung (MVO) erhält das AVS nicht die Verordnungsdaten, sondern die Information „Teilverordnung ab einlösbar.“.\n Wenn ein Versicherter mehrere MVO verschrieben bekommen hat, lassen sich die Rückmeldungen zu den Teilverordnungen den MVO zuordnen.\nDie Information soll um eine Referenz auf die MVO ergänzt werden.", "change" : "alt:\n A_22635-01 - E-Rezept-Fachdienst - Task akzeptieren - Mehrfachverordnung - Beginn Einlösefrist prüfen\nDer E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task//$accept die Operation mit dem Fehlercode 403 abbrechen, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet ist und und der Beginn der Einlösefrist (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.start) zu einem späteren Zeitpunkt als das aktuelle Datum liegt, da Teilverordnungen von Mehrfachverordnungen erst ab Beginn der Einlösefrist abgerufen werden dürfen. Im Falle dieses Fehlers ist im OperationOutcome des Response der Beginn der Einlösefrist wie folgt anzugeben: „Teilverordnung ab einlösbar.“, wobei der Wert im Format \"dd.mm.yyyy\" ist.<=\nneu:\n A_22635-02 - E-Rezept-Fachdienst - Task akzeptieren - Mehrfachverordnung - Beginn Einlösefrist prüfen\nDer E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task//$accept die Operation mit dem Fehlercode 403 abbrechen, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet ist und und der Beginn der Einlösefrist (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.start) zu einem späteren Zeitpunkt als das aktuelle Datum liegt, da Teilverordnungen von Mehrfachverordnungen erst ab Beginn der Einlösefrist abgerufen werden dürfen. Im Falle dieses Fehlers ist im OperationOutcome des Response der Beginn der Einlösefrist wie folgt anzugeben: „Teilverordnung zur Mehrfachverordnung ist ab einlösbar.“, wobei der Wert sowie der Wert im Format \"dd.mm.yyyy\" ist. <=\nPrüfverfahren: funkt. Eignung: Test Produkt/FA", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_22635-02", "removed_requirement_ids" : "A_22635-01", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_12099", "title" : "E-Rezept: Angabe von Freitext-Dosierinformationen bei der Abgabe", "source_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "change_reason" : "In Abstimmung mit der Industrie wurde sich darauf geeinigt, dass zum Start der ePA 3.0 AVS bei der Übermittlung von Abgabeinformationen ggü. dem E-Rezept-Fachdienst Dosierangaben nicht strukturiert, sondern als Freitext angeben werden. Weiterhin sollen die Dosierinformationen nur dann angegeben werden, wenn diese sich ggü. der Verordnung geändert haben.\nDieser Änderungseintrag fügt diese Anforderungen dem Implementierungsleitfaden für Primärsysteme E-Rezept hinzu. Dabei wird ein generisches Kapitel zur Erstellung der MedicationDispense erstellt und dann in den Abschnitten zur Abgabe referenziert.", "change" : "siehe C_12099_Anlage", "attachment" : "Anlagendokumente P-Liste / C_12099_Anlage", "effected_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_27033\nA_27034\nA_27035\nA_26004-01\nA_22071-01\nA_21105-01\nA_27036\nA_27037\nA_19288-03\nA_24291-01\nA_23384-03\nA_27047", "removed_requirement_ids" : "A_21105\nA_22071\nA_24291\nA_24292\nA_24293\nA_19288-02\nA_26004\nA_23384-01\nA_23384-02", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemSST_PS_eRp_abgebend\nSteckbriefe / gemSST_CS_eRp_KTR\nSteckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_12093", "title" : "E-Rezept: Redaktionelle Änderung für Einstellen von Communications", "source_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "change_reason" : "Mit der Einführung des Features \"DiGA\" können auch Kostenträger Communications am E-Rezept-Fachdienst einstellen. Diesem Umstand soll mit dieser Änderung Sorge getragen werden.", "change" : "Alte Afo:\n A_19448-02 - E-Rezept-Fachdienst - Nachricht einstellen - Absender und Sendedatum\n Der E-Rezept-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication die Absenderidentifikation aus dem Attribut idNummer des im HTTP-Header \"Authorization\" übergebenen ACCESS_TOKEN mit dem entsprechenden System https://gematik.de/fhir/sid/telematik-id für Apotheken bzw. http://fhir.de/sid/gkv/kvid-10 oder http://fhir.de/sid/pkv/kvid-10 für Versicherte übernehmen sowie das Absendedatum Communication.sent auf die aktuelle Systemzeit des E-Rezept-Fachdienstes setzen, damit Absender und Sendezeitpunkt für den Empfänger eindeutig sind. <=\nNeue Afo:\n A_19448-03 - E-Rezept-Fachdienst - Nachricht einstellen - Absender und Sendedatum\n Der E-Rezept-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication die Absenderidentifikation aus dem Attribut idNummer des im HTTP-Header \"Authorization\" übergebenen ACCESS_TOKEN mit dem entsprechenden System https://gematik.de/fhir/sid/telematik-id für Institutionen der TI bzw. http://fhir.de/sid/gkv/kvid-10 oder http://fhir.de/sid/pkv/kvid-10 für Versicherte übernehmen sowie das Absendedatum Communication.sent auf die aktuelle Systemzeit des E-Rezept-Fachdienstes setzen, damit Absender und Sendezeitpunkt für den Empfänger eindeutig sind. <=\nPrüfverfahren: funkt. Eignung: Test Produkt/FA", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_19448-03", "removed_requirement_ids" : "A_19448-02", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_12038", "title" : "E-Rezept: Drosselung der User Agent Aufrufe", "source_polarion_documents" : "Spezifikation / gemSpec_Perf", "change_reason" : "Der E-Rezept Fachdienst muss ein Throttling/Drosselung anhand der Aufrufe eines User-Agents implementieren, damit eine Überlast durch einen User-Agent am Fachdienst verhindert werden kann. \nDurch ein Batchverhalten einzelner User-Agents kommt es in einigen UseCases zu kurzzeitigen Lastspitzen, die über die spezifizierten Spitzenwerte der gesamten UseCases hinaus geht. Mit einer minimalen Drosselung soll eine Glättung dieser Aufrufe herbeigeführt werden, damit diese Aufrufe die anderen UseCases und User-Agents nicht beeinträchtigen.", "change" : "Neu:\nAufnahme in gemSpec_FD_eRP Kapitel 5.8.1\nA_26579 - E-Rezept Fachdienst - Drosselung User Agent Aufrufe\n Der E-Rezept Fachdienst MUSS bei einer im laufenden Betrieb konfigurierbaren Anzahl von 200 Aufrufen pro Sekunde eines User Agents die Antwortzeit um ein konfigurierbares Zeitintervall (Default 500ms) verzögert zurückschicken, um eine Überlast am E-Rezept Fachdienst zu verhindern. Die Drosselung muss über einen konfigurierbaren Schalter im laufenden Betrieb aktivierbar bzw. deaktivierbar sein. Zusätzlich MUSS ein Whitelisting implementiert werden, damit User Agents von der Drosselung ausgenommen werden können. <=\nPrüfverfahren: funkt.Eignung: Test Produkt/FA\nÄnderung der Version der Anforderung in der gemSpec_Perf Kapitel 3.2.2\n Im Messagefeld der Betriebsdaten wird das Feld \"throttlingduration\" eingeführt, mit dem die gedrosselte Zeit des Requests eines betroffenden User Agents mitgeliefert werden soll. Änderungen zur vorherigen Version sind fett markiert.\n A_23090-05 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Message\n Der Produkttyp E-Rezept-Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes \"message\" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.\n{ \"cid\": \"$clientid\", \"ua\": \"$useragent\", \"leip\": \"$leipseudonym\", \"size\": $size, \"bkdur\": $backendduration, \"mvonr\": $mvo-nummer, \"vnr\": $vorgangsnummer, \"anr\": $anrvalue, \"zanr\": $zanrvalue, \"it\": $fhir-issue-type, \"ec\": $error-component, \"sec\": $suberror-component, \"suf\": $error-suffix, \"epa\": $epa, \"wf\": $workflow, \"fsc\": $freischaltcode. \"thdur\": $throttlingduration\"}\n* $clientid: Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String\n* $useragent: HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme, Datentyp String\n* $leipseudonym: Stark pseudonymisierte Telematik-ID, Datentyp String\n* $size: Größe des Requests in kilobyte, Datentyp Integer\n* $backendduration: Zeit in ms für Abfragen an OCSP, für die Anfragen an die ePA Aktensysteme oder analogen Backendsystemen, Datentyp Integer\n* $mvo-nummer: Der Wert Nummer des Rezepts der Mehrfachverordnung, Datentyp Integer\n* $vorgangsnummer: Task-ID im Fachdienst, Datentyp String\n* $anrvalue: Der Wert des Feldes identifier:ANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer\n* $zanrvalue: Der Wert des Feldes identifier:ZANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer \n* $fhir-issue-type: Der Wert der Kategorie im OperationOutcome Fehlercode, Datentyp String\n* $error-component: Der Wert des Objektes im OperationOutcome Fehlercode, Datentyp String\n* $suberror-component: Der Wert der Regel im OperationOutcome Fehlercode, Datentyp String\n* $error-suffix: Der Wert des Suffixes im OperationOutcome Fehlercode, Datentyp String\n* $epa: Der Wert der Subdomain der URL des ePA-Aktensystems, Datentyp String\n* $workflow: Der Wert des E-Rezept Workflows bei Aufruf einer E-Rezept-ID, Datentyp Integer\n* $freischaltcode: Rückgabewert (1 oder 0) ob der Freischaltcode für ERP.UC_4_4 mit Workflow 162 übertragen wurde (wurde übertragen = 1, wurde nicht übertragen = 0), Datentyp Integer\n* $throttlingduration: Drosselungszeit eines User Agents in ms, Datentyp Integer \nBei 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. <=\nPrüfverfahren: funkt. Eignung: Test/ProduktFA", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemSpec_Perf\nSpezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_26579\nA_23090-05", "removed_requirement_ids" : "A_23090-04", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_12037", "title" : "E-Rezept: Blocklisting von Versionen eines unlauteren User Agents am E-Rezept Fachdienst", "source_polarion_documents" : "", "change_reason" : "Am E-Rezept Fachdienst soll ein Blocklisting eingeführt werden, damit ein unlauterer User-Agent (Produktversion eines Herstellers) auf Anforderung der gematik, über einen organisatorischen Prozess, zeitweise abgewiesen werden kann. Ein unlauterer User-Agent bedeutet das eine neue oder vorhandene Produktversion eines Herstellers durch ein stark veränderndes Aufrufverhalten die Stabilität des E-Rezept-Fachdienstes stark beeinträchtigt. \n*Hinweis: Das Blocklisting soll nur als Notfallvariante in den E-Rezept Fachdienst integriert werden. Vorab wird es immer erst eine Kommunikation mit dem Hersteller geben, um das Aufrufverhalten des User-Agents zu normalisieren.", "change" : "Aufnahme der folgenden Anforderungen in gemSpec_FD_eRp Kapitel 5.2.3\nNeu:\n A_26577 - Blocklisting unlauterer Clientsysteme an der Internet-Schnittstelle\n Der E-Rezept-Fachdienst MUSS an der Schnittstelle zum Internet eine Funktionalität zum Blockieren von User-Agents (ein User-Agent repräsentiert eine Produktversion eines Herstellers) auf Grundlage einer konfigurierbaren Blocklist bereitstellen, damit nach Anweisung der gematik Zugriffe dieser Produktversionen unterbunden werden. <= Prüfverfahren: Sich.tech Eignung: Produktgutachten\n Die Konfiguration der Blocklist erfolgt mittels eines organisatorischen betrieblichen Prozesses unter Steuerung der gematik.\nPrüfverfahren: Sich.techn. Eignung: Produktgutachten\nA_26578 - Blocklisting unlauterer Clientsysteme an der TI-Schnittstelle\n Der E-Rezept-Fachdienst MUSS an der Schnittstelle zum zentralen Netz der TI eine Funktionalität zum Blockieren von User-Agents (ein User-Agent repräsentiert eine Produktversion eines Herstellers) auf Grundlage einer konfigurierbaren Blocklist bereitstellen, damit nach Anweisung der gematik Zugriffe dieser Produktversionen unterbunden werden. <= Prüfverfahren: Sich.tech Eignung: Produktgutachten\n Die Konfiguration der Blocklist erfolgt mittels eines organisatorischen betrieblichen Prozesses unter Steuerung der gematik.\nPrüfverfahren: Sich.techn. Eignung: Produktgutachten", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_26577\nA_26578", "removed_requirement_ids" : "", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_12034", "title" : "E-Rezept: Zugriff für Arbeitsmediziner/Betriebsärzte", "source_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "change_reason" : "Aktuell können Ärzte und Zahnärzte E-Rezepte ausstellen, welche in einer Arztpraxis, Zahnarztpraxis, Psychotherapie oder Krankenhaus arbeiten. Es soll auch Ärzten und Zahnärzten die Möglichkeit gegeben werden E-Rezepte auszustellen, die in einer Betriebsstätte Vorsorge- und Rehabilitation, in einer Betriebsstätte Öffentlicher Gesundheitsdienst, in einer Betriebsstätte Arbeitsmedizin oder in einer Betriebsstätte Sanitätsdienst Bundeswehr arbeiten.\nEs werden folgende oid's für den Zugriff auf den E-Rezept-Fachdienst in der Rolle Verordnender hinzugefügt, damit dort angestellte Ärzte Rezepte ausstellen können.\n * oid_institution-vorsorge-reha\n* oid_institution-oegd\n* oid_institution-arbeitsmedizin\n* oid_sanitaetsdienst-bundeswehr\nHinweis: Beim Einstellen eines E-Rezeptes prüft der E-Rezept-Fachdienst die QES und stellt sicher, dass die QES mit dem HBA eines Arztes oder Zahnarztes erstellt wurde.", "change" : "siehe C_12034_Anlage", "attachment" : "Anlagendokumente P-Liste / C_12034_Anlage", "effected_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_19018-01\nA_19022-01\nA_19026-01\nA_19145-01", "removed_requirement_ids" : "A_19018\nA_19022\nA_19026\nA_19145", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_12028", "title" : "E-Rezept: AVS: nonQES für Abgabedatensatz", "source_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "change_reason" : "Wenn der Konnektor im offline-Modus betrieben wird, dann wird bei einer nonQES keine OCSP-Prüfung des Signaturzertifikates vor der Signatur durchgeführt.\nUm auszuschließen, dass Abgabedatensätze mit einer gesperrten SMC-B durch ein AVS signiert werden, soll das AVS prüfen, ob die SMC-B gültig ist.", "change" : "In gemILF_PS_eRp ist der Anwendungsfall \"Abgabedatensatz signieren\" beschrieben. Es wird die folgende Anforderung ergänzt.\nA_27050 - PS abgebende LEI: Abgabedatensatz signieren - Gültigkeit SMC-B prüfen\n Das PS der abgebenden LEI MUSS beim Signieren eines Abgabedatensatzes mit einer non-QES vor dem Signieren prüfen, dass die für die nonQES verwendete SMC-B gültig ist.<=\nPrüfverfahren: funkt. Eignung: Herstellererklärung\nHinweis: Die SMC-B ist gültig, wenn ein gültiger ACCESS_TOKEN des IDP-Dienstes für den Zugriff auf den E-Rezept-Fachdienst auf Basis dieser SMC-B vorliegt.", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_27050", "removed_requirement_ids" : "", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemSST_PS_eRp_abgebend" }, { "c_id" : "C_12003", "title" : "E-Rezept: Konkretisierung des Handhabens von Medications am E-Rezept-Fachdienst", "source_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "change_reason" : "Mit der Umstellung der Workflowprofile auf die Version 1.4 ergeben sich Änderungen in der Handhabung der Ressourcen MedicationDispense und Medication.\n In den Workflowprofilversionen vor 1.4 wurden bisher die Medications in der MedicationDispense-Ressource als Contained-Elemente übergeben. Das bedeutet, dass die MedicationDispense die Medication im selben Datenobjekt enthalten hat.\nDamit musste am E-Rezept-Fachdienst bisher nur spezifiziert werden, wie mit der MedicationDispense-Ressource umzugehen ist. \n Durch die Entkopplung der Datenobjekte MedicationDispense und Medication ist eine konkrete Beschreibung der entsprechenden Objekte notwendig.\nBeim Aufruf der Operationen $dispense bzw. $close wird eine Schemaprüfung der übermittelten Dispensierinformation vorgenommen. Es soll klargestellt werden, dass bei einer fehlerhaften Prüfung, die Operation abgebrochen wird und die Daten nicht gespeichert werden.\n Die Anforderungen \"A_24281-01 - E-Rezept-Fachdienst - Dispensierinformationen bereitstellen - Schemaprüfung und Speicherung MedicationDispense\" und \"A_19248-04 - E-Rezept-Fachdienst - Task schließen - Schemaprüfung und Speicherung MedicationDispense\" werden aufgeteilt in jeweils eine Anforderung zur Schemaprüfung und eine Anforderung zum Speichern.", "change" : "s. Anlagedokument C_12003_Anlage", "attachment" : "Anlagendokumente P-Liste / C_12003_Anlage", "effected_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_19248-05\nA_24286-02\nA_19027-06\nA_26527\nA_24281-02\nA_26002-01\nA_26003-01\nA_27051\nA_27052", "removed_requirement_ids" : "A_19027-05\nA_24281-01\nA_24286-01\nA_19248-04\nA_26002\nA_26003", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_11999", "title" : "E-Rezept: Betriebliche Erweiterung für DiGA", "source_polarion_documents" : "Spezifikation / gemSpec_Perf", "change_reason" : "Anpassung der Betriebsdatenlieferung zur zentralen Auswertbarkeit des DiGA Features im E-Rezept Fachdienst.", "change" : "gemSpec_Perf Kapitel 3.2.2\n Alt:\n A_23090-03 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Message\n Der Produkttyp E-Rezept-Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes \"message\" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.\n{ \"cid\": \"$clientid\", \"ua\": \"$useragent\", \"leip\": \"$leipseudonym\", \"size\": $size, \"bkdur\": $backendduration, \"mvonr\": $mvo-nummer, \"vnr\": $vorgangsnummer, \"anr\": $anrvalue, \"zanr\": $zanrvalue, \"it\": $fhir-issue-type, \"ec\": $error-component, \"sec\": $suberror-component, \"suf\": $error-suffix, \"epa\": $epa}\n * $clientid: Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String\n* $useragent: HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme, Datentyp String\n* $leipseudonym: Stark pseudonymisierte Telematik-ID, Datentyp String\n* $size: Größe des Requests in kilobyte, Datentyp Integer\n* $backendduration: Zeit in ms für Abfragen an OCSP, für die Anfragen an die ePA Aktensysteme oder analogen Backendsystemen, Datentyp Integer\n* $mvo-nummer: Der Wert Nummer des Rezepts der Mehrfachverordnung, Datentyp Integer\n* $vorgangsnummer: Task-ID im Fachdienst, Datentyp String\n* $anrvalue: Der Wert des Feldes identifier:ANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer\n* $zanrvalue: Der Wert des Feldes identifier:ZANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer \n* $fhir-issue-type: Der Wert der Kategorie im OperationOutcome Fehlercode, Datentyp String\n* $error-component: Der Wert des Objektes im OperationOutcome Fehlercode, Datentyp String\n* $suberror-component: Der Wert der Regel im OperationOutcome Fehlercode, Datentyp String\n* $error-suffix: Der Wert des Suffixes im OperationOutcome Fehlercode, Datentyp String\n* $epa: Der Wert der Subdomain der URL des ePA-Aktensystems, Datentyp String\nBei 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. <=\nNeu:\n A_23090-04 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Message\n Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes \"message\" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.\n{ \"cid\": \"$clientid\", \"ua\": \"$useragent\", \"leip\": \"$leipseudonym\", \"size\": $size, \"bkdur\": $backendduration, \"mvonr\": $mvo-nummer, \"vnr\": $vorgangsnummer, \"anr\": $anrvalue, \"zanr\": $zanrvalue, \"it\": $fhir-issue-type, \"ec\": $error-component, \"sec\": $suberror-component, \"suf\": $error-suffix, \"epa\": $epa, \"wf\": $workflow, \"fsc\": $freischaltcode}\n * $clientid: Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String\n* $useragent: HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme, Datentyp String\n* $leipseudonym: Stark pseudonymisierte Telematik-ID, Datentyp String\n* $size: Größe des Requests in kilobyte, Datentyp Integer\n* $backendduration: Zeit in ms für Abfragen an OCSP, für die Anfragen an die ePA Aktensysteme oder analogen Backendsystemen, Datentyp Integer\n* $mvo-nummer: Der Wert Nummer des Rezepts der Mehrfachverordnung, Datentyp Integer\n* $vorgangsnummer: Task-ID im Fachdienst, Datentyp String\n* $anrvalue: Der Wert des Feldes identifier:ANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer\n* $zanrvalue: Der Wert des Feldes identifier:ZANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer \n* $fhir-issue-type: Der Wert der Kategorie im OperationOutcome Fehlercode, Datentyp String\n* $error-component: Der Wert des Objektes im OperationOutcome Fehlercode, Datentyp String\n* $suberror-component: Der Wert der Regel im OperationOutcome Fehlercode, Datentyp String\n* $error-suffix: Der Wert des Suffixes im OperationOutcome Fehlercode, Datentyp String\n* $epa: Der Wert der Subdomain der URL des ePA-Aktensystems, Datentyp String\n* $workflow: Der Wert des E-Rezept Workflows bei Aufruf einer E-Rezept-ID, Datentyp Integer\n* $freischaltcode: Rückgabewert (1 oder 0) ob der Freischaltcode für ERP.UC_4_4 mit Workflow 162 übertragen wurde (wurde übertragen = 1, wurde nicht übertragen = 0), Datentyp Integer\nBei 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. <=\nPrüfverfahren: funkt. Eignung: Test/ProduktFA", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemSpec_Perf", "effected_other_documents" : "", "upserted_requirement_ids" : "A_23090-04", "removed_requirement_ids" : "A_23090-03", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_11993", "title" : "E-Rezept: Korrektur Link Relations für Paging", "source_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "change_reason" : "In der Konzeption von Paging wurde eine Link-Relation für die Abfrage der Protokolleinträge gefordert, die bisher so nicht vom E-Rezept-Fachdienst umgesetzt wurde, da das Pattern zur Abfrage der FdV für die Protokolleinträge ist, immer die nächste (next) Seite abzufragen.\nDaher wird für den Endpunkt GET /Auditevent die Link-Relation \"prev\", also den Link für die vorherige Seite der Protokolleinträge, nicht mehr gefordert.", "change" : "Entfernen der LinkRelation \"prev\" für GET /Auditevent aus A_24443\nA_24443-01 - E-Rezept-Fachdienst - Handhabung der Rückgabe von mehreren FHIR-Objekten - Paginierung\n Der E-Rezept-Fachdienst MUSS bei der Handhabung der Rückgabe von mehreren FHIR-Objekten die Paginierung nach FHIR für folgende Endpunkte mit den jeweiligen Parametern unterstützen\nTabelle # : TAB_eRPFD_026 Endpunkte mit Paginierung\nEndpunkt\tPaginierung\tTotal-Count\tLink-Relations\t\nGET /Task\tJa\tJa\tself, next, prev, first, last\t\nGET /Communication\tJa\tJa\tself, next, prev, first, last\t\nGET /MedicationDispense\tNein\timmer \"0\"\t-\t\nGET /ChargeItem\tJa\tJa\tself, next, prev, first, last\t\nGET /AuditEvent\tJa\timmer \"0\"\tself, next, first\t\n<=\nPrüfverfahren: funkt. Eignung: Test Produkt/FA", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_24443-01", "removed_requirement_ids" : "A_24443", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_11988", "title" : "E-Rezept: Das Vermeiden von personenbezogenen und medizinischen Informationen im KIM-Header ist nicht mehr notwendig.", "source_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "change_reason" : "Beim Austausch von KIM-Nachrichten müssen Daten, insbesondere personenbezogene Informationen, sicher übertragen werden.\nKIM-Nachrichten werden dabei von KIM-Clientmodul zu KIM-Clientmodul verschlüsselt. Die eigentliche MIME wird als \"Payload\" in einer Standard \"KOM-LE-Nachricht\" transportiert, wobei der Betreff ebenfalls verschlüsselt wird. \nErst beim empfangenden KIM-Client wird die Nachricht samt Betreff entschlüsselt.\nAktuell fordert A_21872, dass der Betreff keine personenbezogenen Daten enthält. Da der Betreff aber auch beim Transport verschlüsselt ist, kann die Anforderung entfallen.\n A_21872 - E-Rezept - KIM-Header subject\n Das PS der verordnenden und der abgebenden LEI MUSS die Angabe von personenbezogenen oder medizinischen Informationen im KIM-Header \"subject\" unterbinden. [<=]", "change" : "Die Anforderung A_21872 wird gestrichen.", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "", "removed_requirement_ids" : "A_21872", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemSST_PS_eRp_abgebend\nSteckbriefe / gemSST_PS_eRp_verordnend" }, { "c_id" : "C_11984", "title" : "E-Rezept: Nutzung der Akzeptanzfeatures GesundheitsID für E-Rezept", "source_polarion_documents" : "Spezifikation / gemSpec_IDP_Dienst\nSpezifikation / gemSpec_FD_eRp", "change_reason" : "Damit Nutzer, die sich mit GesundheitsID authentifizieren und hier z.b. Biometrie nutzen (Akzeptanzfeatutes GesundheitsID), die E-Rezept App nutzen (oder allg. auf den E-Rezept Fachdienst zugreifen) können, müssen Anpassungen am E-Rezept Fachdienst durchgeführt werden.\nAußerdem ist die Spezifikation des E-Rezept Authorization Server (IDP-Dienst) hinsichtlich der Informationen, welche an den E-Rezept Fachdienst gesendet werden, anzupassen.", "change" : "siehe Anlagedokument C_11984_Anlage", "attachment" : "Anlagendokumente P-Liste / C_11984_Anlage", "effected_polarion_documents" : "Spezifikation / gemSpec_IDP_Dienst\nSpezifikation / gemSpec_FD_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_22271-03\nA_19439-03", "removed_requirement_ids" : "A_19439-02\nA_22271-02", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_IDP-Dienst\nSteckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_11946", "title" : "E-Rezept: Anpassen der Spitzenlastwerte für die E-Rezept UseCase", "source_polarion_documents" : "Spezifikation / gemSpec_Perf", "change_reason" : "Die bisherigen Spitzenlastwerte der E-Rezept UseCases sind Hochrechnungen aus den letzten 2 Jahren. Mit den neuesten Performance- und Nutzungszahlen und einer Hochrechnung bis Ende 2025 werden diese Werte auf die tatsächliche Nutzung angepasst.", "change" : "Siehe Anlagedokument C_11946_Anlage", "attachment" : "Anlagendokumente P-Liste / C_11946_Anlage", "effected_polarion_documents" : "Spezifikation / gemSpec_Perf", "effected_other_documents" : "", "upserted_requirement_ids" : "A_20165-09", "removed_requirement_ids" : "A_20165-08", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemProdT_eRp_FD" }, { "c_id" : "C_10884", "title" : "E-Rezept: Signaturprüfung des ACCESS_TOKEN anstelle des ID_TOKEN", "source_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "change_reason" : "Es ist nicht zwingend, dass Primärsysteme die Signatur des nicht weiter verwendeten ID_TOKEN prüfen.\nEs macht fachlich mehr Sinn die identisch gestaltete Signatur des ACCESS_TOKEN zu verifizieren, welches anschließend auch beim Fachdienst eingereicht wird.\nDie Anforderung A_20674 wird dementsprechend umformuliert.", "change" : "Alt:\n A_20674 - Formale Prüfung der Signatur des ID_TOKEN\n Das Primärsystem MUSS die Signatur des ID_TOKEN mathematisch prüfen und auf ein zeitlich gültiges C.FD.SIG-Zertifikat mit der Rollen-OID \"oid_idpd\" zurückführen können. <=\nNeu:\n A_20674-01 - CS: Formale Prüfung der Signatur des ACCESS_TOKEN\n Das Clientsystem MUSS die Signatur des ACCESS_TOKEN mathematisch prüfen und auf ein zeitlich gültiges C.FD.SIG-Zertifikat mit der Rollen-OID \"oid_idpd\" zurückführen können. <=\nPrüfverfahren: funkt. Eignung: Konformitätsbestätigung, funkt. Eignung: Test Produkt/FA", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_20674-01", "removed_requirement_ids" : "A_20674", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemSST_PS_eRp_abgebend\nSteckbriefe / gemSST_PS_eRp_verordnend\nSteckbriefe / gemSST_CS_eRp_KTR\nSteckbriefe / gemProdT_NCPeH_FD" }, { "c_id" : "C_10804", "title" : "E-Rezept: Konkretisierung für sicheres Löschen von Token", "source_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "change_reason" : "Die Anforderung \"A_20658 - Sicheres Löschen der Token\" kann in zwei Richtungen ungewollt interpretiert werden.\n* Zum einen wird nicht erwartet das ein Primärsystem direkt den Arbeitsspeicher kontrolliert. In modernen Betriebssystemen wie Windows10 oder macOS hat eine Anwendung hierzu nur beschränkte Möglichkeiten\n* Zum anderen zielt die Anforderung auf ein kontrolliertes Beenden der Anwendung. Es wird nicht erwartet das das Primärsystem im Fall eines Absturz oder einer Deaktivierung durch das Betriebssystem noch Aktivitäten durchführen muss.\nEine neue Formulierung und ein Hinweis sollen dies klarstellen.", "change" : "Alt:\n A_20658 - Sicheres Löschen der Token\n Das Primärsystem MUSS, wenn es absichtlich gestoppt oder deaktiviert wird, vorhandene \"ACCESS_TOKEN\", \"ID_TOKEN\" und \"AUTHORIZATION_CODE\"-Objekte sicher aus dem RAM löschen. <=\nNeu:\n A_20658-01 - CS: Sicheres Löschen der Token\n Das Clientsystem MUSS, wenn es kontrolliert beendet wird, vorhandene \"ACCESS_TOKEN\", \"ID_TOKEN\" und \"AUTHORIZATION_CODE\"-Objekte sicher löschen. <=\nPrüfverfahren: funkt. Eignung: Konformitätsbestätigung, funkt. Eignung: Test Produkt/FA\nDarüber hinaus wird außerhalb der Anforderung ein ergänzender Text ausgenommen\n Hinweise zu A_20658-01 und A_21337: Der Begriff des sicheren Löschen mit Bezug auf diese Anforderungen bedeutet, daß das Primärsystem Maßnahmen trifft um die entsprechenden Objekte aktiv zu überschreiben, seien sie nun im Arbeitsspeicher oder lokal gespeichert. Beide Anforderungen können nicht erfüllt werden wenn die Anwendung durch das Betriebssystem terminiert wird, ohne selbst aktiv werden zu können.", "attachment" : "", "effected_polarion_documents" : "Spezifikation / gemILF_PS_eRp", "effected_other_documents" : "", "upserted_requirement_ids" : "A_20658-01", "removed_requirement_ids" : "A_20658", "updated_assignment_requirement_ids" : "", "effected_profiles" : "Steckbriefe / gemSST_PS_eRp_abgebend\nSteckbriefe / gemSST_PS_eRp_verordnend\nSteckbriefe / gemSST_CS_eRp_KTR\nSteckbriefe / gemProdT_NCPeH_FD" } ]

Änderungsliste