Technische Anlage eRezept in der Version 1.20

Wir bedanken uns für die Möglichkeit zur Kommentierung und bitten um die Berücksichtigung der folgenden Aspekte:

Im Basistarif der PKV ist die Angabe des Identifikators der Einrichtung zwingend erforderlich, da im Basistarif die Behandlung nur durch Vertragsärzte zulässig ist und Verordnungen nach GKV-Regelungen auszustellen sind.

Der Identifikator der Einrichtung sollte folglich auch ein Pflichtfeld für den Kostenträgertyp PKV sein.

Daher bitten wir darum, dass im Informationsmodell bei der Feldgruppe "Identifikator der Einrichtung" (ID 61) folgende Änderungen vorgenommen werden:

Bedingungen: Aufnahme der PKV zu den Kostenträgertypen, für die diese Feldgruppe Pflicht ist ("WENN das Feld "Kostenträgertyp" gleich "GKV" oder "BG" oder "SKT" oder "UK" oder "PKV" ist, und das Feld "Typ der...").

Wir bedanken uns für die Möglichkeit zur Kommentierung und bitten um die Berücksichtigung der folgenden Aspekte:

Auch Privatversicherte werden zukünftig zur Nutzung der Anwendungen der Telematikinfrastruktur digitale Identitäten (oder ggf. eGK) mit dem unveränderlichen Teil der Krankenversichertennummer nach § 290 SGB V erhalten (siehe hierzu § 362 SGB V). Die entsprechende Erweiterung der Richtlinie zum Aufbau und zur Vergabe einer Krankenversichertennummer und Regelungen des Krankenversichertennummernverzeichnisses nach § 290 SGB V wurde bereits um die Prozesse zur Generierung der Krankenversichertennummer für PKV-Versicherte erweitert und befindet sich aktuell im finalen Freigabeprozess. Der Start der Verfahrens für PKV-Versicherte ist für Q4-2022 vorgesehen.
 
Nur die Nutzung des unveränderlichen 10-stelligen Teil der einheitlichen Krankenversichertennummer gemäß § 290 SGB V kann den für die Nutzung der Anwendungen der Telematikinfrastruktur notwendigen eineindeutigen Personenbezug gewährleisten. Insbesondere da es derzeit genau genommen noch keine PKV-Versichertennummer sondern nur eine vertragsbezogene PKV-Versicherungsnummer gibt, die keinen eindeutigen Personenbezug gewährt, da ein Versicherungsvertrag auch mehr als eine Person umfassen kann. In diesem Fall bezieht sich die PKV-Versicherungsnummer sowohl auf den Versicherungsnehmer als auch auf die versicherte Person. Dies ist beispielsweise bei Kindern der Fall, die selber nicht als Versicherungsnehmer auftreten können. Des Weiteren handelt es sich bei der PKV-Versicherungsnummer um eine je Unternehmen individuell und unabhängig voneinander vergebene Nummer. Es gibt, ungleich zur einheitlichen Krankenversichertennummer gemäß § 290 SGB V, über die Unternehmen der privaten Krankenversicherung hinweg kein Verfahren, das die Eineindeutigkeit der Nummer gewährt.
 
Folglich ist die PKV-Versicherungsnummer nicht für die Nutzung der Anwendungen der Telematikinfrastruktur geeignet. Somit sollte in Analogie zur VersichertenID_GKV anstelle der PKV-Versichertennummer eine VersichertenID_PKV definiert (unveränderlicher 10-stelliger Teil der Krankenversichertennummer gemäß § 290 SGB V)  und im Informationsmodell abgebildet werden.
           
Daher bitten wir darum, dass im Informationsmodell bei Feld 19b folgende Änderungen vorgenommen werden:
Feldname: „VersichertenID_PKV“ statt „PKV-Versichertennummer“
Länge: „10“ statt „6…12“
Beschreibung: „Dieses Feld enthält die VersichertenID der privaten Krankenversicherung (unveränderliche Teil der einheitlichen Krankenversichertennummer gemäß § 290 SGB V).“ statt „Dieses Feld enthält die Versichertennummer der Privaten Krankenversicherung.“

Da in Zukunft, das Datum in der Signatur eines eRezeptes das eigentlich relevante Datum im Sinne der Arzneimittelverschreibungsverordnung (AMVV) sein wird, kann das Ausstellungsdatum eigentlich wegfallen, damit es keine Inkonsistenzen gibt.
Relevant ist der Zeitpunkt, an dem ein Arzt das Rezept unterschreibt, nicht das Datum an dem das Rezept ggf. vom/im PVS angelegt wurde.

Das Bestreben, die Anwender bei konsistenten Angaben bzgl. der Dosierung maximal zu unterstützen, ist zu begrüßen.
Sollte es tatsächlich zutreffen, dass das Stylsheet eine fehlende Angabe "Dj" automatisch nicht ergänzen, ist zu empfehlen, dies zu ändern. Andernfalls werden Softwareentwickler und die Anwender zu fehlerhaften eVerordnungen verleitet. Denn bei der Prüfung durch die Krankenkassen zählt ausschließlich der Inhalt der FHIR-Daten. Und die AVV lautet (§ 2 Abs. 1 Nr. 7): "... eine entsprechende schriftliche Dosierungsanweisung einer verschreibenden Person vorliegt und wenn die verschreibende Person dies in der Verschreibung kenntlich gemacht hat..."
D.h. auf die Kennzeichnung mit "false" kann nicht verzichtet werden.
Eine Softwareunterstützung für die Verordnenden, dass immer eine Eingabeaufforderung für das Kennzeichen u. ggf. die Dosieranweisung erfolgt, wenn die Verpflichtung zur Dosierungsangabe besteht, wäre wünschenswert.

Folgender Hinweis auf Seite 27 "Wenn das Feld „Kennzeichen Dosierung“ (ID 107) gleich true ist, ist eine Dosieranweisung (ID 108) in der Verordnung zu übermitteln. Wenn der Wert false ist, bedeutet dies, dass dem Versicherten außerhalb der Verordnung eine Dosieranweisung oder ein Medikationsplan mitgegeben wird."

Sollte auch aufSeite 78 ID 106 bis 108 deutlich werden:
z.B. durch eine Ergänzung wie folgt: "Wenn auf einer Verordnung eine Dosierung angegeben oder auf einen vorhanden Medikationsplan etc. verwiesen wird, dann sind diese Felder zu füllen. Eine Dosieranweisung oder ein "DJ" Eintrag darf nicht in anderen Feldern/Freitextfeldern erfolgen."
Die Software sollte die Anwender entsprechend im Workflow unterstützen.

MFA bereiten zb durch Rezept-AB bestellte Rezepte den Ärzten vor.
Dies erfolgt auch ausserhalb der Sprechstunden, zB Mittwoch oder Freitag Nachmittag ständig oder bei Teilzeittätigkeit/Arzt schon raus aus Praxis, MFA arbeiten "nach"

Auch im Arzt-Urlaub sind manchmal MFA wieder in der Praxis und bereiten Post vor und bereiten Rezepte vor, die erst im Nachgang signiert werden.

Dies ist ein sehr häufiger Use-Case in nahezu allen Praxen.
Erfahrung mit deutlich >1000 eRP in der Produktivumgebung haben das wiederholt gezeigt.

Die QES erfolgt dann an einem anderen Tag als die Anlage des eRP.
Ein Vordatieren ist nicht möglich.

Die Apotheke kann Tag A erstellte und Tag B signierte Rezepte nicht abrechnen.

Lösung: Abgeschlossen ist das eRP erst mit QES->Dies sollte dann auch das "Erstelldatum" sein und für Apotheke abrechenbar sein.

Im Praxisalltag werden neben dem Rezept an sich auch weitere Informationen vermittelt. Das physiche Rezept ist hier der "Datenträger".

Bei Muster 16 idR mit PostIt oder praxisinternen Signalen wie Büroklammer in bestimmter Farbe nahezu überall umgesetzt.
zB "Termin Di 16.6. 8.00" oder "eGK fehlt noch" wird so übermittelt.
Dies erfolgt idR durch MFA bei Vorbereitung von Rezepten und kann bisher auf Muster 16 direkt "geklebt werden".
Die QES des eRP erfolgt komplett getrennt von der "Anlage" durch MFA im PVS. So muss erst nach QES und Druck dann die Information Aufwendig nachgearbeitet werden.

Diese Möglichkeit ist bei eRP derzeit nicht gegeben.
Hier wäre aus Erfahrung mit mehreren tausend eRP in der Produktivumgebung wünschenswert, wenn man auf dem Ausdruck (zB unten rechts statt der APP-Werbung) einen Hinweistext hinterlegen könnte.
Dies müsste auch als "Notizfeld" für die App übertragbar sein.

Falls Datenschutzbedenken ->ein: "Bitte nehmen Sie nochmal Kontakt zu Ihrer Praxis auf, diese hat weitere Informationen für Sie" wäre da unproblematisch.

Aktuell benützt nahezu niemand die eRP APP.
Abholfächer in Arztpraxcen sind nach Nachnamen sortiert.
Nach deutlich über Tausend eRP wünschen sich meine MFA die Sortierung des Ausdrucks
Name, Vorname statt Vorname, Nachname

Hallo liebes KBV-Team,

für das Kapitel 6.2 (Patientenausdruck) möchte ich folgendes Vorschlagen:
Aus Kostengründen wählen Arztpraxen in der Regel A4 als Papierformat (A5 ist teurer). Entsprechend könnten 2 A5 Ausdrucke auf ein A4-Blatt gedruckt werden. Entsprechend ließe sich der Ausdruck (und damit der Papierbedarf) optimieren, wenn bei mehr als 3 ERPs eines Patienten die Software bei gewähltem A4-Format jeweils 2 A5-Stylesheets pro A4-Seite - bei ERPs des gleichen Patienten - ermöglichten muss.

Dies steht den PVS-Herstellern zwar auch ohne eine verbindliche Anforderung frei, es würde der Akzeptanz des Ausdrucks auf Arztseite aber helfen, wenn diese Ausdruckoptimierung in jeder zertifizierten Software vorhanden wäre.

Beste Grüße
Mark Langguth

Hallo liebes KBV-Team,

die Gebrauchsanweisung (.patientInstruction) ist ein Hinweisfeld, ausschließlich für den Patienten bestimmt. Daher sollte es für die Patienten auch immer lesbar sein. Für Patienten ohne eRezept-App ist der Ausdruck dafür der einzige Ort. Daher sollte es auf dem Ausdruck enthalten sein, auch da patientenseitig der Ausdruck nach der Dispensierung gerne zur Erinnerung nachgenutzt wird (z.B. zu Hause an den Kühlschrank gehängt).

1.
P6-23 (zusammen mit dem Stylesheet) sollte entsprechend pro ERP um .patientInstruction erweitert werden.

2.
Die Beschränkung von .patientInstruction auf Rezepturen erscheint nicht sinnvoll, da es auch außerhalb der Rezepturen den Bedarf für Gebrauchsanweisung geben KANN. Die Verwendung von .patientInstruction außerhalb von Rezepturen sollte daher nicht grundsätzlich verboten werden. K36-35 sollte daher aufgeweicht werden.

3.
Typo in P36-26:
Für die "Gebrauchsanweisung" wird auf P36-35 verwiesen, korrekt wäre aber K36-35.

Beste Grüße
Mark Langguth

Laut Gematik startet zum 01.10.22 des Jahres die Pilotphase / für das eRezept für PKV-Versicherte.
Bei einer Überarbeitung ist es wünschenswert, wenn die Codevalues zur
Coverage-Extension <span class="nobr"><a href="http://fhir.de/StructureDefinition/gkv/versichertenart" class="external-link" rel="nofollow">http://fhir.de/StructureDefinition/gkv/versichertenart^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
um den Versichertenstatus "Privat" erweitert bzw. ein abgeleitetes, erweitertes Profil angelegt werden würde.

PS: Ich habe Ihnen diese Anregung bereits unter "EREZEPT-3" gesendet, diese wurde jedoch leider bisher nicht aufgenommen (ohne Begründung).

In der neuen Version wurde Medication.extension:kategorie gestrichen.
Dieses Attribut war ursprünglich vorgesehen, um eine Verordnung als BtM Verordnung zu kennzeichnen.
Gibt es eine alternative Möglichkeit eine Verordnung als BtM-VO zu identifizieren?

Die gematik konzipiert aktuell das BtM Feature. Hierbei sind eigenständige Workflows für BtM-Rezepte für GKV und PKV-Versicherte geplant.
Die Kennzeichnung als BtM-VO sollte dafür genutzt werden, dass der E-Rezept-Fachdienst prüft, dass für BtM-VO der korrekte Workflow ausgewählt wurde.

Die verantwortliche Person ist immer der „fest in der Praxis arbeitende Arzt“.
Für den Arzt in Weiterbildung (03) ist er verantwortlich, weil er ihn ausbildet.
Für den Vertreter (04) ist er verantwortlich, weil er der Vertretene ist.

Insofern der Arzt eine Vertretung hat, tritt diese dann anstelle des Arztes als Verantwortlich für den Arzt in Weiterbildung?

Wir würden die Angaben wie folgt interpretieren:

Das Feld ausstellende Person ist bei Arzt in Weiterbildung optional.
Wenn es allerdings angegeben wird, ist die LANR Pflicht.
Somit kann das Feld bei Arzt in Weiterbildung, welche keine LANR besitzen weggelassen werden.

Hierarchie 3 -> 00, 01, 04 Pflicht / 02 darf nicht / sonst optional
Hierarchie 4 -> wenn 00, 03, 04 dann Pflicht / sonst optional

Ist dies so korrekt?

Hallo zusammen,

ich begrüße, dass das für die Apotheken sehr leidige Thema "Dj" angegangen wurde!

Konkret wurde die Validierung von KBV_EX_ERP_DosageFlag geändert:

• Zuvor wurde sichergestellt, dass bei KBV_EX_ERP_DosageFlag = false <em>keine</em> Dosierungsangabe existiert: "Wenn das Dosierungskennzeichen nicht gesetzt ist, darf auch kein Text vorhanden sein." Diese Regel ist entfallen.
• Nun wird verlangt, dass bei KBV_EX_ERP_DosageFlag = true stets eine textuelle Dosisangabe vorhanden ist: "Wenn das Dosierungskennzeichen true ist, muss eine Dosieranweisung vorhanden sein."

Die Absicht ist erkennbar, dass es keine fehlende Angabe "Dj" mehr geben soll. Das Stylesheet der KBV zur Visualisierung von Verordnungen interpetiert das Flag bereits jetzt schon genau so und ergänzt den Text “Dosieranweisung / Medikationsplan mitgegeben" automatisch.

Damit stellt sich die Frage, ob in DAV_CS_ERP_ArtRezeptaenderung der Heilungsgrund #5 “Ergänzung eines fehlenden Hinweises auf einen Medikationsplan, der das verschriebene Arzneimittel umfasst, oder auf eine schriftliche Dosierungsanweisung” noch relevant ist?

Konkrete Fragen:

1. Wie ist mit "Kostbarkeit #5" umzugehen? Gibt es dafür noch einen beabsichtigten Anwendungsfall? Welcher Fall wäre das?

2. Warum wurde die ursprüngliche Regel entfernt? Sollten nicht beide Regeln gleichzeitig gültig sein, um einen inkonsistenten Zustand zu verhindern?
"Wenn das Dosierungskennzeichen true ist, muss eine Dosieranweisung vorhanden sein." UND "Wenn das Dosierungskennzeichen nicht gesetzt ist, darf auch kein Text vorhanden sein." Und sollte nicht auch der Fall einer vorhandenen, aber leeren Dosierungsanweisung berücksichtgt werden?

3. Wie soll damit umgegangen werden, wenn KBV_EX_ERP_DosageFlag = false und dennoch vom Arzt eine (leere/nicht-leere) textuelle Dosieranweisung angegeben wurde?

4. Was soll geschehen, wenn KBV_EX_ERP_DosageFlag = true und vom Arzt als Dosieranweisung der Text “Dj” o.ä. angegeben wurde bzw. eine leere Dosieranweisung angegeben wurde? Muss dann Heilungsgrund #5 angegeben werden?

Vielen Dank und beste Grüße,
Thomas Voigt