TIFlow - Verordnungen für Arzneimittel
Version 2.0.0-ballot.1 - ci-build

FD-Anforderungen $activate

Diese Seite enthält die normativen Anforderungen an den TI-Flow-Fachdienst für die Operation $activate.

Anforderungen aus der Core Spezifikation

Diese Seite enthält die workflowtyp-übergreifenden normativen Anforderungen an den TI-Flow-Fachdienst für die Operation $activate.

Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate die zeta-user-info.professionOID des Nutzers bestimmen und sicherstellen, dass ausschließlich Nutzer in der Rolle
  • oid_praxis_arzt
  • oid_zahnarztpraxis
  • oid_praxis_psychotherapeut
  • oid_krankenhaus
  • oid_institution-vorsorge-reha
die Operation am Fachdienst aufrufen und bei Abweichungen die Operation mit dem folgenden Fehler:
HTTP-Code 403 - Forbidden
Severity error
Code invalid
Details Code TIFLOW_AUTH_ROLE_NOT_ALLOWED
Details Text Der Nutzer ist nicht berechtigt, die aufgerufene Operation anzufordern
abbrechen, damit E-Rezepte nicht durch Unberechtigte eingestellt werden können.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den im HTTP-RequestHeader "X-AccessCode" oder URL-Parameter "?ac=..." übertragenen AccessCode gegen den im referenzierten Task gespeicherten AccessCode Task.identifier:AccessCode als https://gematik.de/fhir/erp/NamingSystem/GEM_ERP_NS_AccessCode prüfen und bei Ungleichheit oder Fehlen des AccessCodes die Operation mit dem folgenden Fehler:
HTTP-Code 403 - Forbidden
Severity error
Code invalid
Details Code TIFLOW_ACCESSCODE_MISMATCH
Details Text -
abbrechen, damit Zugriffe auf diesen Datensatz nur durch Berechtigte in Kenntnis des AccessCodes erfolgen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den im referenzierten Task gespeicherten Status Task.status prüfen und, wenn Task.status ungleich "draft" ist, die Operation mit dem folgenden Fehler:
HTTP-Code 412 - Precondition Failed
Severity error
Code invalid
Details Code TIFLOW_TASK_STATUS_MISMATCH
Details Text Task has invalid status.
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den im Aufrufparameter übergebenen FHIR-Operationsparameter des QES-Datensatzes als PKCS#7-Datei einer Enveloping CAdES-Signatur entgegennehmen und verarbeiten und bei Fehlen oder ungültiger ASN.1 Datenstruktur die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code SVC_VALIDATION_FAILED
Details Text FHIR Profile validation failed.
abbrechen, damit kein Schadcode und keine "fachfremden" Daten in den TI-Flow-Fachdienst hochgeladen werden.
Der TI-Flow-Fachdienst MUSS das QES-Signaturzertifikat C.HP.QES in der Signatur des übergebenen QES-Datensatzes gemäß [gemSpec_PKI#TUC_PKI_030] mit folgenden Parametern auf Gültigkeit prüfen:
Parameter Wert
Zertifikat Signaturzertifikat des HBA (eingebettet in Signatur-Objekt des QES-Datensatzes):
  • C.HP.QES (oid_hba_qes = 1.2.276.0.76.4.72 gemäß gemSpec_OID)
Referenzzeitpunkt Zeitpunkt der QES-Erstellung gemäß signingTime im QES-Datensatz
Offline-Modus nein
OCSP-Response eingebettet in QES-Datensatz
Tabelle: TAB_eRPFD_006 Parameter Prüfung Signaturzertifikat QES des HBA

Der TI-Flow-Fachdienst MUSS, wenn keine OCSP-Response eingebettet oder die eingebettete OCSP Response nicht gültig ist, eine gecachte OCSP-Response verwenden, wenn die gecachte OCSP-Response nach den Signaturzeitpunkt erstellt wurde, oder eine OCSP-Response beim zugehörigen TSP anfragen.
Der TI-Flow-Fachdienst MUSS das Signaturzertifikat prüfen, für [mathematisch gültig UND zeitlich gültig UND online gültig ] befinden und andernfalls die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_CERTIFICATE_INVALID
Details Text -
abbrechen, damit sichergestellt wird, dass ausschließlich Verordnungen verwaltet werden, die von einer gültigen, nicht gesperrten Heilberufsidentität eines HBA signiert wurden.
Der TI-Flow-Fachdienst MUSS, wenn im Rahmen der Prüfung der Gültigkeit eines QES-Signuturzertifikates C.HP.QES die Abfrage des OCSP-Response für das Signaturzertifikat fehlschlägt, die Operation mit dem folgenden Fehler:
HTTP-Code 512 - OCSP Backend Error
Severity error
Code invalid
Details Code TIFLOW_OCSP_BACKEND_ERROR
Details Text OCSP Backend Error
abgelehnt werden.
Der TI-Flow-Fachdienst MUSS, wenn im Rahmen der Prüfung der Gültigkeit eines QES-Signuturzertifikates C.HP.QES keine OCSP-Response eingebettet oder die eingebettete OCSP Response nicht gültig ist, die die Prüfung genutzte OCSP-Response in den QES-Datensatz einbetten. Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate die qualifizierte Signatur des QES-Datensatzes gemäß [ETSI_QES] prüfen und bei nicht gültiger qualifizierter Signatur die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_SIGNATURE_INVALID
Details Text -
abbrechen, damit der nachfolgende Workflow ausschließlich auf Basis vom Leistungserbringer mittels Signatur freigegebener Daten erfolgt.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate das innerhalb des PKCS#7-Datensatz enveloping-enthaltene FHIR-Bundle einer FHIR-Validierung gegen die eRezept-Schema-Definition der KBV kbv.ita.erp oder kbv.itv.evdga unterziehen und bei Invalidität die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code SVC_VALIDATION_FAILED
Details Text FHIR Profile Validation Failed
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den Datensatz als PKCS#7-Datei speichern und in Task.input mit Codingsystem https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_DocumentType = 1 über eine interne, eindeutige UUID referenzieren, damit der nachfolgende Workflow auf Basis vom Leistungserbringer mittels Signatur freigegebener Daten erfolgt. Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate die Angabe zum Mimetype des signierten Dokumentes prüfen und, wenn dieser ungleich "text/plain; charset=utf-8" ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_SIGNATURE_INVALID
Details Text -
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, dass die PrescriptionID des Tasks mit der PrescriptionID im übergebenen QES-Datensatz übereinstimmt und andernfalls die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_FLOWTYPE_MISMATCH
Details Text -
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, dass der Präfix der PrescriptionID gleich dem Flowtype des zu aktivierenden Tasks ist und andernfalls die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_FLOWTYPE_MISMATCH
Details Text -
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, dass Patient.identifier.system gleich "http://fhir.de/sid/gkv/kvid-10" ist und andernfalls die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_KVNR_INVALID
Details Text Als Identifier für den Patienten muss eine VersichertenID (KVNR) angegeben werden.
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate, wenn das Datum authoredOn zur Gültigkeitsberechnung der Verordnung nicht dem Datum in QES.Erstellung im Signaturobjekt entspricht, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_SIGNATURE_AUTHOREDON_MISMATCH
Details Text Ausstellungsdatum und Signaturzeitpunkt weichen voneinander ab, müssen aber taggleich sein
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate die KVNR des Patienten dem Identifier http://fhir.de/sid/gkv/kvid-10 der Patient-Ressource im E-Rezept-Bundle entnehmen und diesen als Identifier in Task.for mit system http://fhir.de/sid/gkv/kvid-10 hinzufügen, damit ausschließlich eine gültige, vom Arzt signierte Patientenreferenz im Workflow verwendet wird. Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate bei erfolgreichem Abschluss der Operation, den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.activate" und den Versicherten mit der KVNR = Task.for initiieren. Der TI-Flow-Fachdienst MUSS die zulässige Aktivierung eines Tasks mittels /Task/<id>/$activate-Operation im Status Task.status = ready vollziehen und bei erfolgreichem Abschluss der Operation die Ressource Task im HTTP-Body der HTTP-Response zurückgeben, damit die verordnende Leistungserbringerinstitution über den erfolgreichen Abschluss der Operation in Kenntnis gesetzt wird. Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate die im QES-Datensatz enthaltene Verordnung in ein Bundle gleichen Typs in JSON-Repräsentation beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task/<id> zurück liefern. Dies gilt für folgende Bundles: https://fhir.kbv.de/StructureDefinition/KBV_PR_ERP_Bundlehttps://fhir.kbv.de/StructureDefinition/KBV_PR_EVDGA_Bundle
Der TI-Flow-Fachdienst MUSS für diese Bundles
  • einen neuen, eindeutigen Identifier für die Bundle.id als UUID generieren,
  • das Bundle entsprechend der Kanonisierungsregeln http://hl7.org/fhir/canonicalization/json#static normalisieren (Bundle.text und Bundle.meta im "root-Element" entfernen),
  • mit der Signaturidentität des Fachdienstes ID.FD.OSIG gemäß [FHIR-Sig] signieren und
  • das signierte Bundle mit Referenz in Task.input mit Codingsystem https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_DocumentType = 2 zurück liefern,
damit der Versicherte einen Nachweis über die Integrität der gespeicherten Daten einsehen kann.

Die Festlegungen in [FHIR-Sig] sind in Teilen unspezifisch, konkrete Beispiele finden sich in der gematik-API-Beschreibung für das E-Rezept auf https://github.com/gematik/api-erp .
Die Signatur soll als JSON Web Signature [JWS] detached erstellt werden, dementsprechend bleibt das data-Feld der JWS-Struktur leer. Im JWS-Header muss das Zertifikat C.FD.SIG eingebettet werden, mit dessen zugehörigen privaten Signaturschlüssel signiert wurde. Als Wert für targetFormat ist der MimeType application/fhir+json und für sigFormat ist der MimeType application/jose zu verwenden.

Verifizieren von Prüfziffern

Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate einen im FHIR Profil KBV_PR_FOR_Coverage gespeicherten Wert für payor.identifier.value gemäß dem im "Gemeinsames Rundschreiben Institutionskennzeichen (IK)" vom 01.06.2020 unter Kapitel 1.2.5 "Prüfziffer" beschriebenen Prüfalgorithmus validieren, und bei einer fehlerhaften Prüfung die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_IKNR_INVALID
Details Text Ungültiges Institutionskennzeichen (IKNR): Das übergebene Institutionskennzeichen im Versicherungsstatus entspricht nicht den Prüfziffer-Validierungsregeln.
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate die im FHIR Profil KBV_PR_FOR_Coverage gespeicherten Werte für payor.identifier.extension:alternativeID.value[x]:valueIdentifier gemäß dem "Gemeinsames Rundschreiben Institutionskennzeichen (IK)" vom 01.06.2020 unter Kapitel 1.2.5 "Prüfziffer" beschriebenen Prüfalgorithmus validieren, und bei einer fehlerhaften Prüfung die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_IKNR_INVALID
Details Text Ungültiges Institutionskennzeichen (IKNR): Das übergebene Institutionskennzeichen des Kostenträgers entspricht nicht den Prüfziffer-Validierungsregeln.
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate einen im FHIR Profil KBV_PR_FOR_Patient gespeicherten Wert für Patient.identifier:versichertenId.value gemäß der Anlage 1 der "Prüfziffernberechnung für die Krankenversichertennummer nach § 290 SGB V" vom 26.02.2019 beschriebenen Prüfalgorithmus validieren, und bei einer fehlerhaften Prüfung die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_KVNR_INVALID
Details Text Ungültige Versichertennummer (KVNR): Die übergebene Versichertennummer des Patienten entspricht nicht den Prüfziffer-Validierungsregeln.
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate einen im FHIR Profil KBV_PR_FOR_Practitioner hinterlegten Wert für identifier:ANR.value bzw. identifier:ZANR.value gemäß der Anlage 6 BMV-Ä der "Technischen Anlage zum Vertrag über den Datenaustausch zwischen dem GKV-Spitzenverband (Spitzenverband Bund der Krankenkassen) und der Kassenärztlichen Bundesvereinigung" unter "Aufbau der lebenslangen Arztnummer - LANR" beschriebenen Prüfalgorithmus unter Beachtung der folgenden zulässigen Ausnahmen validieren, und bei einer fehlerhaften Prüfung auf diese Auffälligkeit gemäß der Konfiguration reagieren.
ANR/ZANR Ursache
555555 plus Ordnungsnummer für die Reihenfolge in der Anzeige an die ASV-Verzeichnisstelle (KH-Zähler) plus Fachgruppencode Verordnungen im Rahmen der Versorgung nach § 116b Abs. 1 SGB
Tabelle: TAB_eRPFD_016 Zulässige Ausnahmen in Form von Pseudoarztnummern

Hinweis: Folgende weitere Pseudoarztnummern werden genutzt. Sie sind Prüfziffernkonform:

ANR/ZANR Ursache
4444444 plus Fachgruppencode Pseudoarztnummer im Rahmen des Reha-Entlassmanagements
999999900 Ambulanzen in Krankenhäusern gemäß
000000000 Ausnahme der Verordnungen im Rahmen der Versorgung nach § 116b Abs. 1 SGB V
999999991 Zahnärzte z.B. in zahnärztlichen Hochschulambulanzen
333333300 Verordnungen von Arznei, Heil- und Hilfsmitteln im Rahmen der spezialisierten ambulanten Palliativversorgung (SAPV)
Tabelle: TAB_eRPFD_017 Zulässige Ausnahmen in Form von Pseudoarztnummern (Prüfzifferkonform)

Hinweis: Im Rahmen der ambulanten spezialfachärztlichen Versorgung (ASV) nach § 116b SGB V wird gemäß der ASV-Vereinbarung von Krankenhausärzten die sog. Fachgruppennummer statt der LANR verwendet. Die Fachgruppennummer wird ein einem separaten Element hinterlegt. In diesem Fall muss keine ANR angegeben werden.

Der TI-Flow-Fachdienst MUSS für die Überprüfung der ANR/ZANR eine Möglichkeit der Konfiguration vorsehen und bei der Durchführung einer Vergleichsoperation je nach Konfiguration bei Auffälligkeit die Operation mit einer Warnung fortführen oder mit einer Fehlermeldung abbrechen. Der TI-Flow-Fachdienst MUSS für die Überprüfung der ANR/ZANR, wenn bei der Prüfung eine Auffälligkeit auftritt und die Konfiguration Fehler aktiv ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_LANR_ZANR_INVALID
Details Text Ungültige Arztnummer (LANR oder ZANR): Die übergebene Arztnummer entspricht nicht den Prüfziffer-Validierungsregeln.
abbrechen.
Der TI-Flow-Fachdienst MUSS für die Überprüfung der ANR/ZANR, wenn bei der Prüfung eine Auffälligkeit auftritt und die Konfiguration Warning aktiv ist, mit dem Http-Responsecode 252 antworten und den Response für die Auffälligkeit mit einem Http-Header "Warning" mit
  • warning-code: 252
  • warning-agent: "erp-server"
  • warning-text: "Ungültige Arztnummer (LANR oder ZANR): Die übergebene Arztnummer entspricht nicht den Prüfziffer-Validierungsregeln."
erweitern.

Modulspezifische Anforderungen

Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 160, 169, 200 oder 209 mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, ob die QES gemäß der professionOID des Signaturzertifikats von einer Berufsgruppe ausgestellt wurde, die einer der folgenden professionOID entspricht:
  • oid_arzt
  • oid_zahnarzt
und bei einer Abweichung die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_SIGNATURE_INVALID_ISSUING_ROLE
Details Text -
abbrechen, damit nur solche Leistungserbringer ein signiertes E-Rezept einstellen, die zur Verordnung von Medikamenten ermächtigt sind.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 166 mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, dass die QES gemäß der professionOID des Signaturzertifikats von einer Berufsgruppe ausgestellt wurde, die der folgenden professionOID entspricht:
  • oid_arzt
und bei einer Abweichung die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_SIGNATURE_INVALID_ISSUING_ROLE
Details Text -
abbrechen, damit nur solche Leistungserbringer ein signiertes E-Rezept einstellen, die zur Verordnung von T-Rezepten ermächtigt sind.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 160, 169, 200 oder 209 mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, dass im Bundle eine MedicationRequest-Ressource und eine Medication mit Medication.extension:Arzneimittelkategorie = 00 enthalten ist, und andernfalls die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_FLOWTYPE_MISMATCH
Details Text Für diesen Workflowtypen sind nur Arzneimittelverordnungen zulässig
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 166 mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, dass im Bundle eine MedicationRequest-Ressource und eine Medication mit Medication.extension:Arzneimittelkategorie = 02 enthalten ist, und andernfalls die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_FLOWTYPE_MISMATCH
Details Text Für diesen Workflowtypen sind nur T-Rezept Verordnungen zulässig
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 160, 166, 169, 200 oder 209 mittels HTTP-POST-Operation über /Task/<id>/$activate die Validierung von strukturierten Dosierungen anwenden. Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 160 oder 169 mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, ob Coverage.type.coding.code nicht mit dem Wert "PKV" belegt ist und im Fehlerfall die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_COVERAGE_TYPE_MISMATCH
Details Text -
abbrechen, um sicherzustellen, dass diese Workflows nicht für E-Rezepte für PKV-Versicherte genutzt werden.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 200 oder 209 mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, ob Coverage.type.coding.code mit dem Wert "PKV" belegt ist und im Fehlerfall die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_COVERAGE_TYPE_MISMATCH
Details Text -
abbrechen, um sicherzustellen, dass diese Workflows nur für E-Rezepte für PKV-Versicherte genutzt werden.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn der übergebene QES-Datensatz als Betäubungsmittel-Verordnung (Bundle.Medication.extension:KBV_EX_ERP_Medication_Category:code gleich "01") gekennzeichnet ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_DRUG_CATEGORY_FORBIDDEN
Details Text BTM nicht zulässig
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den Wert für Task.extension:eu-isRedeemableByProperties auf "true" setzen, wenn:
  • Task.extension:flowType = 160 oder 200 und
  • MedicationRequests.medication vom Typ KBV_PR_ERP_Medication_PZN.
Andernfalls ist der Wert der Extension auf "false" zu setzen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mit Flowtype 160, 166, 169, 200 oder 209 mittels HTTP-POST-Operation über /Task/<id>/$activate bei erfolgreichem Abschluss der Operation, die Daten des Verordnungsdatensatzes für die Übermittlung in den ePA Medication Service bereitstellen.

Prozessparamter

Der TI-Flow-Fachdienst MUSS bei einem Task mit Task.flowType = 160 die Attribute in Task in Abhängigkeit des in der http-POST-Operation /Task/<id>/$activate übergebenen gültig signierte E-Rezept-Bundle gemäß TAB_eRpDM_004 belegen.
Feld in Task Feldbelegung
Task.performerType.coding.system "https://gematik.de/fhir/erp/CodeSystemGEM_ERP_CS_OrganizationType"
Task.performerType.coding.code "1.2.276.0.76.4.54"
Task.performerType.coding.diplay "Öffentliche Apotheke"
Task.PrescriptionType.valueCoding.display "Flowtype für Apothekenpflichtige Arzneimittel"
Task.ExpiryDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.AcceptDate = >Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Tabelle: TAB_eRpDM_004 Prozessparameter Flowtype 160
Der TI-Flow-Fachdienst MUSS bei einem Task mit Task.flowType = 166 die Attribute in Task in Abhängigkeit des in der http-POST-Operation /Task/<id>/$activate übergebenen gültig signierte E-Rezept-Bundle gemäß TAB_eRpDM_006 belegen.
Feld in Task Feldbelegung
Task.performerType.coding.system "https://gematik.de/fhir/erp/CodeSystemGEM_ERP_CS_OrganizationType"
Task.performerType.coding.code "1.2.276.0.76.4.54"
Task.performerType.coding.diplay "Öffentliche Apotheke"
Task.PrescriptionType.valueCoding.display "Flowtype für Arzneimittel nach § 3a AMVV"
Task.ExpiryDate Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 6 Kalendertage
Task.AcceptDate Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 6 Kalendertage
Tabelle: TAB_eRpDM_006 Prozessparameter Flowtype 166
Der TI-Flow-Fachdienst MUSS bei einem Task mit Task.flowType = 169 die Attribute in Task in Abhängigkeit des in der http-POST-Operation /Task/<id>/$activate übergebenen gültig signierte E-Rezept-Bundle gemäß TAB_eRpDM_007 belegen.
Feld in Task Feldbelegung
Task.performerType.coding.system "https://gematik.de/fhir/erp/CodeSystemGEM_ERP_CS_OrganizationType"
Task.performerType.coding.code "1.2.276.0.76.4.54"
Task.performerType.coding.diplay "Öffentliche Apotheke"
Task.PrescriptionType.valueCoding.display "Flowtype für Workflow-Steuerung durch Leistungserbringer"
Task.ExpiryDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.AcceptDate = >Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Tabelle: TAB_eRpDM_007 Prozessparameter Flowtype 169
Der TI-Flow-Fachdienst MUSS bei einem Task mit Task.flowType = 200 die Attribute in Task in Abhängigkeit des in der http-POST-Operation /Task/<id>/$activate übergebenen gültig signierte E-Rezept-Bundle gemäß TAB_eRpDM_008 belegen.
Feld in Task Feldbelegung
Task.performerType.coding.system "https://gematik.de/fhir/erp/CodeSystemGEM_ERP_CS_OrganizationType"
Task.performerType.coding.code "1.2.276.0.76.4.54"
Task.performerType.coding.diplay "Öffentliche Apotheke"
Task.PrescriptionType.valueCoding.display "Flowtype für Apothekenpflichtige Arzneimittel (PKV)"
Task.ExpiryDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.AcceptDate = >Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Tabelle: TAB_eRpDM_008 Prozessparameter Flowtype 200
Der TI-Flow-Fachdienst MUSS bei einem Task mit Task.flowType = 209 die Attribute in Task in Abhängigkeit des in der http-POST-Operation /Task/<id>/$activate übergebenen gültig signierte E-Rezept-Bundle gemäß TAB_eRpDM_009 belegen.
Feld in Task Feldbelegung
Task.performerType.coding.system "https://gematik.de/fhir/erp/CodeSystemGEM_ERP_CS_OrganizationType"
Task.performerType.coding.code "1.2.276.0.76.4.54"
Task.performerType.coding.diplay "Öffentliche Apotheke"
Task.PrescriptionType.valueCoding.display "Flowtype für Workflow-Steuerung durch Leistungserbringer (PKV)"
Task.ExpiryDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.AcceptDate = >Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Tabelle: TAB_eRpDM_007 Prozessparameter Flowtype 209
Der TI-Flow-Fachdienst MUSS nach der Feststellung der Prozessparametern die folgenden Parameter mit abweichenden Werten belegen:
  • Task.AcceptDate = <Datum der QES.ErstellungBundle.signature.when> + 2 Werktage (Montag bis Samstag, ausgenommen bundeseinheitliche Feiertage) (Abweichende Regelungen durch denGemeinsamen Bundesausschuss (G-BA) sind zu beachten.)
wenn das in der http-POST-Operation /Task/<id>/$activate übergebene, gültig signierte E-Rezept-Bundle in der Extension https://fhir.kbv.de/StructureDefinition/KBV_EX_FOR_Legal_basis in Bundle.Composition den code="04" oder "14" des Code-Systems https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_STATUSKENNZEICHEN ("Entlassmanagement-Kennzeichen") enthält und die übrigen Prozessparameter unverändert übernehmen, damit der Prozess für das E-Rezept mit den abweichenden Festlegungen für das Entlassrezept gemäß Arzneimittelrichtlinie [AM-RL] umgesetzt wird.

Verifizieren von Prüfziffern

Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den im FHIR Profil KBV_PR_ERP_Medication_PZN gespeicherten Wert für code.coding:pznCode.code gemäß den "Technischen Hinweisen zur PZN-Codierung - Prüfziffernberechnungen der PZN, PPN und Basic UDI-DI" beschriebenen Prüfalgorithmus validieren, und bei einer fehlerhaften Prüfung die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_PZN_INVALID
Details Text Ungültige PZN: Die übergebene Pharmazentralnummer entspricht nicht den vorgeschriebenen Prüfziffer-Validierungsregeln.
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den im FHIR Profil KBV_PR_ERP_Medication_Compounding gespeicherten Wert für ingredient.item[x]:itemCodeableConcept.coding:pznCode.code gemäß den "Technischen Hinweisen zur PZN-Codierung - Prüfziffernberechnungen der PZN, PPN und Basic UDI-DI" beschriebenen Prüfalgorithmus validieren, und bei einer fehlerhaften Prüfung die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_PZN_INVALID
Details Text Ungültige PZN: Die übergebene Pharmazentralnummer entspricht nicht den vorgeschriebenen Prüfziffer-Validierungsregeln.
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate, wenn die PZN einer übergebenen PZN-Verordnung in KBV_PR_ERP_Medication_PZN.code.coding.code nicht 8-stellig ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_PZN_INVALID
Details Text Länge PZN unzulässig (muss 8-stellig sein)
abbrechen.

Prüfung von Mehrfachverordnungen

Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet und der Flowtype ungleich 160, 169, 200 oder 209 ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_FLOWTYPE_INVALID
Details Text -
abbrechen, weil Mehrfachverordnungen nur für die Verordnungen von apothekenpflichtigen Arzneimittel (kein BtM, kein T-Rezept) zulässig sind.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet und der Numerator oder Denominator größer als 4 ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_INVALID
Details Text -
abbrechen, weil eine Mehrfachverordnungen aus maximal 4 Teilverordnungen bestehen darf.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet und der Numerator kleiner als 1 ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_INVALID
Details Text -
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet und der Denominator kleiner als 2 ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_INVALID
Details Text -
abbrechen, weil eine Mehrfachverordnungen aus mindestens 2 Teilverordnungen bestehen muss.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet und der Numerator größer als der Denominator ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_INVALID
Details Text -
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung nicht als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false) gekennzeichnet ist, aber eine Extension Nummerierung oder Zeitraum enthält, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_INVALID
Details Text -
abbrechen, weil normale Verordnungen keine MVO-Angaben enthalten dürfen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) und als Entlassrezept ( code="04" oder "14" in Extension https://fhir.kbv.de/StructureDefinition/KBV_EX_FOR_Legal_basis in Bundle.Composition.extention:rechtsgrundlage) gekennzeichnet ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_INVALID
Details Text -
abbrechen, weil für Entlassrezepte keine Mehrfachverordnungen zulässig sind.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) und als Ersatzverordnung ( code="10" oder "11" oder "17" in Extension https://fhir.kbv.de/StructureDefinition/KBV_EX_FOR_Legal_basis in Bundle.Composition.extention:rechtsgrundlage) gekennzeichnet ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_INVALID
Details Text -
abbrechen, weil für Ersatzverordnungen keine Mehrfachverordnungen zulässig sind.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet ist und der Beginn der Einlösefrist (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.start) nicht angegeben ist, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_STARTDATE_INVALID
Details Text -
abbrechen, weil die Information des Beginns der Einlösefrist notwendig ist, um den Gültigkeitszeitraum zu ermitteln.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet ist und das Startdatum (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.start) vor dem Ausstellungsdatum (MedicationRequest.authoredOn) liegt, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_STARTDATE_INVALID
Details Text -
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet, ein Endedatum (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end) angegeben ist und das Endedatum vor dem Startdatum (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.start) liegt, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_ENDDATE_INVALID
Details Text -
abbrechen.
Der TI-Flow-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen und, wenn die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet ist und der dazugehörige value (MedicationRequest.extension:Mehrfachverordnung.extension:ID.value[x]:valueIdentifier.value) nicht dem Schema aus [KBV_ITA_VGEX_Technische_Anlage_ERP] entspricht, die Operation mit dem folgenden Fehler:
HTTP-Code 400 - Bad Request
Severity error
Code invalid
Details Code TIFLOW_EREZEPT_MVO_ID_INVALID
Details Text -
abbrechen.