Kommentare

Eine Umsetzung bis 01.01.2021 sehen wir als nicht zumutbar und auch nicht sinnvoll an, weil
1) die Schnittstellenveränderungen sehr umfangreich sind
2) wir aus Praxistests mit PVS-Herstellern wissen, dass es einige Iterationen gedauert hat, bis die Schnittstelle in derzeitiger Version ohne Fehler implementiert werden konnte
3) Die Version 2.0 noch nicht final ist und weitere Änderungen nach Start der Umsetzung anzunehmen sind, weil noch keine Implementierung stattgefunden hat.
4) Eine umfangreiche Pilotphase zwischen PVS-Herstellern und VOS-Herstellern notwendig ist, um einen reibungslosen Umstieg von der derzeitigen Version auf Version 2.0 zu ermöglichen.
Es ist bei dieser kurzfristigen Umsetzungsfrist zu erwarten, dass das Gegenteil der ursprünglichen Intention erreicht wird, den unabhängigen Wechsel von Verordnungssoftware und Praxisverwaltungssystem zu ermöglichen - weil die Mehrzahl der Hersteller die Umsetzung nicht fristgerecht und in praxistauglichem Maße erreichen wird. Eine Verschiebung um 6-12 Monate ist aus unserer Sicht angemessen.

KBV_PR_VoS_Prescription: Es fehlt weiterhin die Möglichkeit Sprechstundenbedarfsrezepte auszustellen.

KBV_PR_VoS_Prescription: Es fehlen die Sonderkennzeichen für T-Rezpte und BTM-Rezepte in strukturierter Form.

KBV_PR_VoS_Patient: Wieso wurde die Angabe der PVS-Installationsspezifischen Patientennummer entfernt?

KBV_PR_VoS_Patient Die Angabe der Identifier Patient.identifier:versichertennummer_pkv und Patient.identifier:versichertennummer_kvk am Patienten machen keinen Sinn, da diese vom jeweiligen Kostenträger gesetzt werden und nicht Kostenträgerübergreifend wie von der Vertrauensstelle Krankenversichertennummer. Eine Übergabe der Versichertennummer an der Coverage-Ressource wie vorher wäre sinnvoller. Des weiteren macht die Kardinalität von 1..1 keinen Sinn: So hat ein Patient mit ausländischer europäischer Krankenversicherungskarte keine der drei geforderten Identifikationsmerkmale. Patienten können darüber hinaus mehrere Versicherungen gleichzeitig haben.

KBV_PR_VoS_Patient Wäre es nicht einfacher die Kardinalität von Patient.birthDate auf 0..1 zu ändern, statt das fehlen des Geburtsdatums mittels Patient.birthDate.extension:data-absent-reason zu übergeben?

KBV_PR_VoS_Organization und KBV_PR_VoS_Practitioner : Wieso sind Organization.identifier:KZV-Abrechnungsnummer und Practitioner.identifier:ZANR must-support?

KBV_PR_VoS_MedicationStatement_MP: Entgegen dem Datenmodell des BMP und des eMP fehlt hier eine Möglichkeit für eine Freitextdosierung. Desweiteren fehlen die erweiterten Medikationsangaben des eMPs wie: Hinweise/Kommentar, Behandlungsgrund, Kennzeichen Dauermedikation, Kennzeichen Historisiert.

KBV_PR_VoS_Medication_Compounding: Laut K3-723 des Anforderungskatalogs AVWG muss auf eine Rezepturverordnung das "Gefäß/Primärpackmittel, sofern angegeben" abgedruckt werden. Diese Daten Fehlen jedoch in dem Profil. Im Profil ist der Rezepturname Pflicht, im AVWG ist jedoch von "Rezepturname, sofern angegeben" die Sprache.

KBV_PR_VoS_Medication_Ingredient: Wieso ist Medication.ingredient auf 1..1 eingeschränkt? Ist eine Wirkstoffverordnung von Kombiarzneimitteln nicht vorgesehen?

KBV_PR_VoS_Medication_PZN: Wieso ist die Angabe des Herstellers weggefallen? Dieser wird zur Dokumentation beim Rückschrieb im PVS benötigt.

KBV_PR_VoS_Medication_PZN und KBV_PR_VoS_Medication_Ingredient: Wieso ist die Angabe des ATC-Codes weggefallen? Dieser ist für statistische Auswertungen wichtig.

KBV_PR_VoS_Medication_PZN und KBV_PR_VoS_Medication_Ingredient: Für eine bessere Statistische Auswertung wäre es hilfreich wenn auch die Unverbindliche Preisempfehlung beim Fehlen des Apothekenverkaufspreis, der Festbetrag, die Mehrkosten, die Zuzahlung und die Gesamtzuzahlung mit übertragen werden könnten.

KBV_PR_VoS_Medication_Ingredient: Laut O4-140 des Anforderungskatalogs AVWG wird bei Wirkstoffverordnungen "der Preis des günstigsten austauschbaren Arzneimittels übernommen", jedoch fehlt die Preisinformation am Profil KBV_PR_VoS_Medication_Ingredient, wodurch keine Statistik durchgeführt werden kann.

KBV_PR_VoS_Medication_PZN und andere Medication-Profile: Das Element Medication.extension:kategorie verhindert mit dem jetzigen ValueSet, dass zum Beispiel Hilfsmittel über die VoS-Schnittstelle verordnet werden. Auch ist es nicht ersichtlich warum die Eigenschaft ob es sich um ein Impfstoff handelt als orthogonal gesehen wird. Auch macht eine feinere Untergliederung Sinn:
Betäubungsmittel,
T-Rezept-Arzneimittel nach AMVV § 3a Abs. 1,
sonstiges Arzneimittel,
Impfstoff,
Verbandmittel nach § 31 SGB V,
Harn- und Blutteststreifen nach § 31 SGB V,
Dietätikum nach § 31 SGB V,
sonstiges Dietätikum,
Hilfsmittel,
sonstiges Medizinprodukt,
Sonstiges

KBV_PR_VoS_DocumentReference: Im Element DocumentReference.context.related.reference gibt es die Möglichkeit einer Referenz auf ein Bundle des Profils KBV_PR_ERP_Bundle. Die Übertragung von Ressourcen mit den eRezept-Profilen ist jedoch an der VoS-Schnittstelle nicht spezifiziert. Was ist hierfür der Hintergrund? Auch im Profil KBV_PR_VoS_MedicationStatement_MP gibt es Referenzen auf Resourcen mit eRezept-Profilierung.

KBV_PR_VoS_Coverage: Wieso wurde die SKT-Zusatzangabe im Vergleich zur alten Schnittstelle entfernt?

KBV_PR_VoS_Coverage: Welchen Anwendungsfall hat die Extension "https://fhir.kbv.de/StructureDefinition/KBV_EX_FOR_Alternative_IK"? Auch im Technischen Handbuch Digitale Muster geht dies nicht hervor.

KBV_PR_VoS_Coverage: Es fehlt die Information des Kostenträgerabrechnungsbereichs (KTAB). Die VoS benötigt diese Information da zum Beispiel bei KTAB BEG (Bundesentschädigungsgesetz) auf dem Muster 16 das Feld 6 BVG auch dann bedruckt werden muss, wenn keine besondere Personengruppe 6 BVG vorliegt.

KBV_PR_VoS_Condition: Es wäre sinnvoll das Element Condition.code.coding.display als must-support Element und einer Kardinalität von 1..1 mit zu übergeben, damit dem Anwender eine Beschreibung der Diagnose angezeigt werden kann.

KBV_PR_VoS_AllergyIntolerance: Hier gibt es eine Abweichung zum Datenmodell des eMPs: Eine Allergie im eMP hat immer die Information ob diese ärztlich diagnostiziert oder eine Eigenangabe des Patienten ist, in dem Profil fehlt diese Information bzw. es es ist nicht ersichtlich wo diese steht. Ist diese Abweichung gewollt?

Es ist von einer Authentifizierung mittels Zertifikat die Rede, jedoch ist in der Schnittstellenbeschreibung nur eine Authentifizierung mittels Basic Authentification spezifiziert.

Wir erachten es als deutlich nutzerfreundlicher, wenn die FHIR-Basis-URL des PVS beim Aufruf der VoS mit übergeben wird. Dies ermöglicht auch die gesetzlich notwendige Trennung von Datenbeständen in Praxisgemeinschaften durch unterschiedliche Basis-URLs.

Eine Festlegung der Einstellung für die VoS-Anbindung auf arbeitsplatzbezogene Speicherung hat zur Folge, dass im Falle einer Umstellung auf jedem Arbeitsplatz einzeln die Umstellung konfiguriert werden muss. Ist dies so gewollt?

P4-170 Akzeptanzkriterium 2.: Ist die Änderung so zu verstehen, dass alle Ressourcen zusätzlich der Profilierung für das eRezept entsprechen müssen? Dies ist jedoch nicht möglich, da sich die Profile wegen den unterschiedlichen Anwendungsfällen widersprechen. Auch legt die Schnittstellenbeschreibung die ausschließliche Verwendung der VoS-Profile fest.

Wir erachten den Zusatzaufwand mögliche Logeinträge zu beschreiben und es für den Anwender konfigurierbar zu machen nicht für zielführend. Nur bei schwerwiegenden Fehlern ist ein Betrachten des Logs notwendig. In solchen Fällen muss dem Arzt technische Hilfe zur Verfügung gestellt werden (siehe Akzeptanzkriterium 2.). Für diese ist eine Dokumentation wie das Logging eingeschaltet werden kann und wo das Log zu finden ist ausreichend.

Es ist nicht offensichtlich was mit "Eingabe der benötigten Parameter" gemeint ist. Geht es hier um das Konfigurierung einer VoS-Anbindung in einem PVS?

Leider wird in der Schnittstellenbeschreibung nicht erklärt wie die Schnittstelle im Zusammenhang mit der Telematik-Infrastruktur und der Funktionsweise des eRezeptes steht. Es entsteht der Eindruck, als müsste auch eine VoS mit der Telematik-Infrastruktur kommunizieren. Bereits absehbar ist, dass diese doppelte Anbindung mit einem erheblich erhöhten Umsetzungsaufwand einer Verordnungssoftware einher gehen würde. Auch in den Praxen wäre das mit einem erhöhten Konfigurationsaufwand verbunden. Weitere Probleme die durch diese Konstellation auftreten können sind wahrscheinlich.

Die Validierung der Profile ist nur mit erwarteten Fehlern und Warnungen möglich. Das erschwert die korrekte Validierung bei der Umsetzung der Profile. Profile welche eine fehlerfreie Validierung ermöglichen wären wünschenswert.

KBV_PR_VoS_MedicationStatement_MP ist laut Beschreibung das “Profil für die Übertragung einer strukturierten Dosierung für den Medikationsplan”. Muss die Dosierung für eine Verordnung über ein anderes Profil übertragen werden? Wenn ja welches Profil soll hierfür verwendet werden? Momentan wird der MP nur als BMP-XML+PDF zurückgeschrieben. Wird sich das mit der neuen Version ändern?

KBV_PR_VoS_MedicationStatement_MP kann als Referenz verschiedene Profile für dieselbe Art Medication enthalten. (z.B. KBV_PR_VoS_Medication_FreeText und KBV_PR_ERP_Medication_FreeText). Müssen beide Profile unterstützt werden? Und falls ja, wann werden die jeweiligen Profile verwendet (z.b. beim Zurückschreiben der Daten)?

In dem Profil “KBV_PR_VoS_DocumentReference” kann unter “author/ausstellendesSystem” als Referenz ein Patient/RelatedPerson angegeben werden. Wie kann man diese Referenz verstehen?

In dem Profil “KBV_PR_VoS_Coverage” kann unter “payor” eine Referenz zu Organization/Patient/RelatedPerson angeben werden, innerhalb des Elements ist aber eine Referenz zu einer iknr Pflicht. Was soll dort angegeben werden falls ein Patient referenziert wurde?

In dem Profil “KBV_PR_VoS_Composition” kann unter “author/PRF” eine Referenz zu einem Patienten/RelatedPerson übergeben werden. Laut der Definition wird dieses Element für die "Identifikation des PVS, welches die VoS aufruft" verwendet. Wie ist in diesem Zusammenhang die Referenz auf einen Patienten zu verstehen?

KBV_PR_VoS_Accident ist nur eine Referenz auf einen Patienten angegeben. Wie können wir einen Unfall auf ein Rezept mappen? in dem Profil KBV_PR_VoS_Prescription werden dieselben Daten direkt gesetzt. Sind dadurch diese Daten nicht redundant?

Es wäre wünschenswert umfangreichere Beispiel für die Profile zu erhalten. Die Beispieldateien decken oft nur die einfachsten Fälle ab. Für die Implementierung wäre es hilfreich ausführlichere Beispiele für weitere und auch komplizierte Anwendungsfälle zu haben.

An mehreren Stellen in der Spezifikation werden für den Benutzer aussagekräftige Fehlermeldungen gefordert. Da eine Kommunikation mit dem Fremdsystem erfolgt und die Ursache mancher Fehler auch am Fremdsystem liegen können wäre es für den Benutzer hilfreich die Kontaktdaten des Fremdsystems in Fehlermeldungen anzeigen zu können. Es wäre daher hilfreich die Kontaktinformationen des Herstellers (z.B. Kundensupport) in die übertragenen Daten aufzunehmen. Alternativ könnte man auch eine Maschinenlesbare Liste mit Prüfnummern und den zuzuordnenden Kontaktdaten definieren, welche in die Software integriert werden kann.

Im Profil KBV_PR_VoS_DocumentReference im Attribut DocumentReference.type wird das Value Set KBV_VS_VoS_DocumentType referenziert. Dieses enthält eine List der Möglichen Dokumente die an das PVS bzw. die VoS übertragen werden können. Aus der Profilbeschreibung und der Beschreibung des Code Systems geht aber die Bedeutung der Typen nicht richtig hervor.
Zum Beispiel ist nicht definiert ob das XML des Bundeseinheitlichen Medikationsplanes als BMP_eMP oder Medikationsplan an die VoS bzw. das PVS übertragen werden soll. Auch ist nicht beschrieben ob bei der Übertragung des Medikationsplanes von der VoS an das PVS die XML Dateien des Medikationsplanes und das PDF des Medikationsplanes in einer DocumentReference übertragen werden sollen oder jeweils ein Dokument genau einer DocumentReference entspricht.
Es soll eine detaillierte Zuordnung von Typ zu den erwarteten Attachments mit ihren entsprechenden ContentTypes definiert werden.

Kapitel 4.1.8: Die Unterstützung von Paging ist nur vorgeschlagen aber nicht verpflichtend. Da bei einer Patientensuche eine erhebliche Datenmenge anfallen kann, verhindert fehlendes Paging die Anforderung, dass es bei der Kommunikation zwischen PVS und VoS zu keiner Verzögerung kommen soll (P3-240).
a. Bei der Patientensuche soll die Umsetzung von Paging verpflichtend gemacht werden. Es Die Menge der in einem Suchvorgang enthaltenen Treffer soll auf maximal 20 begrenzt werden, um ein performantes Antwortverhalten des PVS gegenüber der VoS zu gewährleisten.

Kapitel 6 und 7: Es sollte eine Roadmap für den Übergang von Version 1.10.010 auf Version 2.0.0 geben?
a. Um die Umstellung aller beteiligten Systeme zu erleichtern, ist ein paralleler Betrieb beider Schnittstellenversionen für einen bestimmten Zeitraum erforderlich. Dieser Übergangszeitraum sollte aber nicht mehr als 3 Monate betragen.
b. Es soll eine entsprechende (PVS-) Zertifizierung zur Sicherstellung der Umsetzung der neuen Version zum 01.01.2022 geben.

Im Absatz 1. wird gefordert, dass die von der VoS zur Verfügung gestellten Dokumente in verschiedenen Formaten im PVS gespeichert werden sollen. Hier soll für jedes Dokument bzw. jedes Bundle genau definiert werden, in welcher Form die Speicherung erfolgen soll.

Kapitel 4.2: Es muss definiert werden, wie damit umgegangen werden soll. wenn im PR_ERP_Bundle weitere Practitioner/Coverage/PractitionerRoles übergeben werden, die sich nicht mit den übergebenen Daten des VOS Bundles decken.

Gemäß der Übersicht der Aufrufkontexte in Kapitel 4.2 kann bei einigen Aufrufen sowohl eine Resource vom Typ KBV_PR_ERP_Bundle und ein KBV_PR_VoS_MedicationStatement_MP übermittelt werden.
a. Es soll klargestellt werden, ob es sich um verschiedene Verordnungen handeln kann, oder es sich um die gleiche Verordnung handelt
b. Es muss definiert werden, welches Profil zu verwenden ist, wenn beide Profile geliefert werden und diese jeweils unterschiedliche Inhalte haben.

KP4-60: Aufrufkontext “Arzneimittelrecherche ohne Patientenkontext” (5) kann ein E-Rezept übergeben werden.
a. Die Arzneimittelrecherche dient doch dazu, dem Benutzer die Möglichkeit zu geben, nach einem beliebigen Arzneimittel zu suchen, um z.B. dessen Fachinformationen einzusehen. Stellt sich die Arzneimittelrecherche im Fall der Übergabe eines E-Rezeptes anders dar (z.B. soll nach dem verordneten Präparat gesucht werden)?
b. Sollen die Patientendaten eines im Rahmen einer Arzneimittelrecherche übergebenen Rezeptes verwendet oder ignoriert werden?

KP4-100: Aufrufkontext “Medikationsplan auf Basis eines bestehenden strukturierten MP aktualisieren” (9) .

• Nach der Übersicht in Kapitel 4.2 kann beim Aufrufkontext 9 entweder ein Medikationsplan oder ein signiertes E-Rezept übergeben werden. Auf Basis der Daten eines E-Rezeptes kann aber kein Medikationsplan erstellt werden. In diesem Fall sollte ausschließlich ein bestehender MP übertragen werden können

P5-55: “Eine Instanz des E-Rezeptes soll mindestens als signierte Datei übertragen werden”
a. Was bedeutet die Formulierung “mindestens”? Gibt es außer dem vorgeschlagenen Signaturverfahren noch weitere (erweiterte) Optionen?
b. Was genau ist unter der “Metainformation der Signatur” zu verstehen, die im PVS gespeichert werden muss?
c. Es fehlt die Angabe mit welchem Typ und ContentType die PKCS7-Datei an das PVS übertragen werden soll
d. Die PKCS7-Datei muss in derselben DocumentReference übertragen werden soll wie das E-Rezept, damit für das empfangene System der Zusammenhang zwischen beiden klar wird.

Im Hinweis wird erwähnt, dass “mit dem Aufruf die VoS in den Vorder- und das PVS in den Hintergrund tritt”, um den Workflow des Verordners nicht zu unterbrechen und die Ausführung der VoS nicht zu behindern. Es wäre wünschenswert, wenn diese Funktion schärfer formuliert und als Teil der Anforderung aufgenommen wird, da sonst zu befürchten ist, dass der Hinweis ignoriert wird.

MedicationRequest.extension:RezeptTyp: Nur CodeSystem ist angegeben, es fehlt das ValueSet-Binding
Die Rezeptdaten des eRezepts: <span class="nobr"><a href="https://simplifier.net/erezept/kbvprerpprescription" class="external-link" rel="nofollow">https://simplifier.net/erezept/kbvprerpprescription^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
enthält die Extension „Mehrfachverordnung“ und VoS enthält diese Extension nicht: <span class="nobr"><a href="https://simplifier.net/Verordnungssoftware-Schnittstelle/KBVPRVoSPrescription" class="external-link" rel="nofollow">https://simplifier.net/Verordnungssoftware-Schnittstelle/KBVPRVoSPrescription^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
Die Verordnungssoftware-Schnittstelle (VoS) sollte auch die Extension „Mehrfachverordnung“ enthalten, um kompatibel zum eRezept zu sein.

Practitioner.identifier.system auf 1..1, „must support“ und ein NamingSystem muss angegeben werden, sonst kann der Wert in identifier.value nicht identifiziert werden.
Practitioner.name sollten die Elemente ausspezifiziert werden nicht einfach auf 0..1 oder 0..* lassen, sonst wird es evtl. nicht einheitlich verwendet.

Observation.performer 0..* - es wird wohl immer nur ein Arzt den Schwangerschaftsstatus fixieren, also 0..1.