Kommentare & Antworten Version 2.0.0

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.

Observation.subject.reference auf „must support“ setzen
Observation.performer 0..* - es wird wohl immer nur ein Arzt den Kreatininwert fixieren, also 0..1.

Observation.subject.reference auf „must support“ setzen und die Kardinalität von subject.type/.identifier/.display jeweils auf 0..0 setzen
Observation.performer 0..* - es wird wohl immer nur ein Arzt den Status „stillend“ fixieren, also 0..1. Wenn auch eine Organisation optional angegeben werden kann, dann sollte es durch Slicing realisiert werden.

Kann hier nicht einfach das eRezept-Profil „KBV_PR_ERP_Medication_PZN“ genutzt werden oder zumindest als „baseDefinition“ angegeben werden, damit kenntlich ist, dass es auf die ERP-Vorlage beruht?

Kann hier nicht einfach das eRezept-Profil „KBV_PR_ERP_Medication_Ingredient“ genutzt werden oder zumindest als „baseDefinition“ angegeben werden, damit kenntlich ist, dass es auf die ERP-Vorlage beruht?

Kann hier nicht einfach das eRezept-Profil „KBV_PR_ERP_Medication_FreeText“ genutzt werden oder zumindest als „baseDefinition“ angegeben werden, damit kenntlich ist, dass es auf die ERP-Vorlage beruht?

Kann hier nicht einfach das eRezept-Profil „KBV_PR_ERP_Medication_Compounding“ genutzt werden oder zumindest als „baseDefinition“ angegeben werden, damit kenntlich ist, dass es auf die ERP-Vorlage beruht?

DocumentReference.masterIdentifier.system auf 1..1, „must support“ und ein NamingSystem für „value“ angeben.
DocumentReference.identifier.system auf 1..1, „must support“ und ein NamingSystem für „value“ angeben.

Composition.subject : In subject sollte die Referenz auf den Patienten enthalten sein! – also subject.reference auf 1..1 „must support“ setzen und im subjekt die Reference „KBV_PR_VoS_Patient“ festlegen. Subject.display ist dann nicht mehr nötig, also dann auf 0..0
Composition.author : weiterer slice für den Arzt „KBV_PR_VoS_Practitioner“, gehört hier hin und nicht in der section.entry
Composition.section : Die Composition.section sollte „nach Kapiteln“ gesliced werden. So wie es jetzt aufgebaut ist, wird dieser Teil der Composition als unstrukturierte Liste verwendet. „KBV_PR_VoS_Patient“ und „KBV_PR_VoS_Practitioner“ in subject und author referenzieren, nicht in den section.entry!

Vorschlag: Bundle.identifier auf „must support“

Bundle.identifier.system auf 1..1 : Da value 1..1 ist, das Element system beschreibt was value ist.

S. 16 Funktionen 7 bis 9: Aus dem Kontext (Barcode) ergibt sich, dass es um einen BMP geht --> besser auch so benennen, um Verwechslung etwa mit dem eMP auszuschließen

S. 13 Schnittstellenfestlegung: " ValueSets hingegen beinhalten einen Satz von Codes aus einem CodeSystem, um anzugeben, welche Codes in einem bestimmten Kontext verwendet werden können."

besser: "...aus einem oder mehreren Codesystems..."

S. 13 der Schnittstellenfestlegung: Die kanonische URL der Extension KBX_EX_VOS_ACCIDENT_ORGANIZATION ist falsch angegeben, müsste eigentlich <span class="nobr"><a href="https://fhir.kbv.de/StructureDefinition/KBX_EX_VOS_ACCIDENT_ORGANIZATION" class="external-link" rel="nofollow">https://fhir.kbv.de/StructureDefinition/KBX_EX_VOS_ACCIDENT_ORGANIZATION^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> lauten

Die Anforderungen für die VoS-SST 2.0 sind stand jetzt noch nicht final. Der Zeitplan für Entwicklung und Rollout ist sehr sportlich. Insbesondere verbleibt kein Spielraum für eine vorzeitige Test-Pilotierung. Insofern wäre eine spätere Umsetzungsfrist aus gründen der Qualität und Sorgfalt dringend geboten.
Hinzu kommt, dass die weiteren zertifizierungs-relevanten gesetzlichen Anforderungen verhindern, unsere Entwicklung "mit Volldampf" an der VoS-SST arbeiten zu lassen.

Bereits zur VoS 1.10 hatten wir dieses Problem erwähnt, wiederholen es jedoch nun anlässlich der Kommentierung wieder.

In der Tabelle zu den Akzeptanzkriterien wird in der Zeile Patient verlangt, dass "Alle im PVS vorhandenen Patienten" übergeben werden müssen. Weiter folgend sollen auch zu allen Patienten die Profile übergeben werden. Dies kollidiert mit der Anforderung P3-240 Zeitverhalten, da es nicht möglich ist bei einer Praxis mit großem Patientenstamm in einen verzögerungsfreien Aufruf zu starten, wenn alle Patienten inklusive verschiedenster Details der gesamten Praxis übergeben werden sollen.

Fachlich wäre es für uns sinnvoll zumindest die Profile nur für jene Patienten zu übergeben, welche dann in der VoS ausgewählt werden.

Wie stellt man sich an dieser Stelle einen Kompromiss vor und was wäre näher spezifiziert eine "übliche Reaktionszeit"? (In Anlehnung an Herr Wilms Frage)

In der Tabelle zu den Akzeptanzkriterien wird in den Zeilen Behandelnder bis Anwender verlangt alle Profile die im PVS vorhanden sind, inklusive deren Rollen bereitzustellen.

Wie stellt man sich das in einer Praxisgemeinschaft vor, welche getrennte Patientenstämme hat und auch die Verantwortlichkeit jeweils nur bei den eigenen Patienten der Ärzte liegt? Ist dann trotzdem eine Bereitstellung aller Behandelnden Ärzte, Organisationen und Nutzer legitim und legal? 

Laut AVWG 5.2  P3-710 heißt es "Die Verordnungssoftware muss die elektronische Verordnung ermöglichen. Die Vorgaben der gematik sind umzusetzen."
gematik eRp 1.2.0 verweist auf die "Technischen Anlage elektronische Arzneimittelverordnung <span class="error">[KBV_ITA_VGEX_TECHNISCHE_ANLAGE_ERP]</span> (<span class="nobr"><a href="https://update.kbv.de/ita-update/DigitaleMuster/ERP/KBV_ITA_VGEX_Technische_Anlage_ERP.pdf" class="external-link" rel="nofollow">https://update.kbv.de/ita-update/DigitaleMuster/ERP/KBV_ITA_VGEX_Technische_Anlage_ERP.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>)
Diese sagt aus, dass Signatur etc in der VoS erfolgen muss.

Frage: Gehen wir nur über das Behandlerprofil sicher, dass die Registrierung der Ärzte übereinstimmt? Gibt es an dieser Stelle ein ToDo im PVS? Wie stellt man sich die Komfortsignatur dazu vor? Wie stellt man sich darüber hinaus die Registrierung des HBA mit der VOS vor?

Es wird auf die Anforderung P3-150 verwiesen, welche jedoch nicht mehr existent ist. Da die FHIR Profile restrukturiert wurden, wäre ein Bezug zu den aktuellen Profilen sinnvoll - Können Sie diesen nennen, oder wird das Kriterium in einer anderen Weise geändert?

In der Spezifikation heißt es: "Der Speicherort der Log-Datei muss durch den Anwender/Arzt definierbar sein"

Der Speicherort wird im Sinne der Ordnerstruktur auf dem Computer vom Anwendenden ausgewählt werden können. Die Bereitstellung des Typs wird in einem gängigen Log-Format sein. Ist diese Interpretation korrekt? 

In der Spezifikation heißt es: "PVS und VOS müssen eine Option bieten, die Schnittstellenaktivität zu loggen. Die Inhalte der Log-Datei müssen definiert und in der Dokumentation beschrieben werden"

Der Log würde maximal präzise den Fehler loggen/ alle technischem Details für technische Experten bereitstellen (Mitarbeiter des VoS-Herstellers, technische Betreuer der Praxis, Mitarbeiter des AIS-Herstellers etc.). Diese Beschreibung des Nutzen findet sich dann in der Update-Information wieder.

Ist diese Interpretation korrekt? Ggf. benötigt es hier eine noch klarere Formulierung bzw. eine Kontextualisierung.

In Anbetracht der kompletten Restrukturierung der FHIR-Profile und noch bestehenden grundlegenden Fragen zu jenen Profile, sowie der noch offenen fachlichen Fragen zum AKA, wäre der Zeitraum zur Umsetzung weniger als 6 Monate von der Festlegung der Spezifikation bis zum Roll out/Deployment. Darüber hinaus bestehen noch zahlreiche gesetzlichen Anforderungen (eRp, eAU, ePA 2.0 etc.), deren Pflicht zur Auslieferung nun teilweise vorverlegt wurde. Wir sehen daher eine Umsetzung zum 01.01.2022 als nicht zumutbar an.

Welchen Grund zur pflichtmäßigen Integration der VoS 2.0 B1-SST sehen sie aktuell, der eine so außergewöhnlich kurzfristige Umsetzung in diesem Umfang, sowie im Kontext der bestehenden Digitalisierungswelle rechtfertigt?

Beim Vergleich der Profile fällt auf, dass jene für das ERP weder zur Übergabe zwischen B1 und B2-SST inkludiert, noch ergänzend sind. Sie scheinen sich in Ihren Informationen zu überlappen, aber nicht zu decken.

Konkret äußert sich dies unter Anderem bei der Stornierung des eRezepts (PK4-120), wo die erwartbaren FHIR-Profile für uns nicht erkenntlich den Status des Rezepts beinhalten, welcher in der Spezifikation zum ERP unter "MedicationRequest → Status" (<span class="nobr"><a href="http://hl7.org/fhir/StructureDefinition/MedicationRequest" class="external-link" rel="nofollow">http://hl7.org/fhir/StructureDefinition/MedicationRequest^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) angegeben und geändert werden würde.

Darüber hinaus ist für uns nicht zu erkennen, wie diese Profile zukünftig ineinander greifen.

Wie Stellt man sich bei KBV und gematik dieses ineinandergreifen vor? Wird es eine erneute Anpassung der Spezifikationen oder der Profile geben?

Die notwendige ggfs. Abweichung Profilierung der FHIR-Ressourcen ist nachvollziehbar. Auch eine formularübergreifende Definition z.B. FOR ist sinnvoll. Um Fehler zu vermeiden, möchten wir zwei Vorschläge machen.

1. Die übergreifende Definition von in verschiedenen Projekten genutzten Ressourcen sollte konsequenter genutzt werden.
2. Im Bezug zum E-Rezept sollte die Separierung der VOS- und ERP-Ressourcen aufgegeben werden. Praxissoftware haben die Schwierigkeit bspw. alle Ressourcen der VOS-Profile für das E-Rezept in ERP und FOR-Profile bzw. umgekehrt zu transformieren. Das ist fehleranfällig und vermeidbarer Mehraufwand.

KBV_PR_FOR_Practitioner und KBV_PR_VoS_Practitioner sehen bis auf den verbotenen Narrative (FOR) identisch aus.

Ist diese Abweichung beabsichtigt oder kann das vereinheitlicht werden?

Die Extension KBV_PR_VoS_Coverage.einlesedatum-karte ist nicht in KBV_PR_FOR_Coverage-Profil enthalten.

Ist diese Abweichung beabsichtigt?

Die Extension KBV_PR_VoS_Composition->KBV_EX_VoS_Legal_basis scheint eine Kope der Definition zu KBV_PR_ERP_Composition->KBV_EX_FOR_Legal_basis zu sein.

In VOS erfolgt eigene, geschlossene Definition, in ERP wird auf FOR verwiesen.

Kann das vereinheitlicht werden?

Im MedicationProfil existiert eine Abhängigkeit zu den Profilen des erezept-Projekts im simplifier. Diese Dependency sollte im VOS-Projekt ergänzt werden.

Ressourcentyp/FHIR-Profil - MedicationStatement
Bei Betrachtung dieses Profils im simlifier.net ist aufgefallen, dass es mit der 2.0 anscheinend keinen Dosierungs-Freitext mehr gibt.

Zum Ressourcentyp / FHIR-Profil - Coverage
Bei Betrachtung dieses Profils im simlifier.net fehlt nach wie vor die Versicherungsart "Privatpatient"

In der Konditionalen Pflichtfunktion KP4-120 (Seite 30) wird von einer Verordnungsfunktion "eRezept-Storno" gesprochen. Diese findet sich weder im Anforderungskatalog AVWG 5.2 noch in den referenzierten Dokumenten der gematik.
Worum handelt es sich hierbei? Und was genau ist hierbei eine Funktion der VoS, da ja die Anbindung an die TI im PVS stattfindet und im Besonderen eine webbasierte VoS hierauf keinen Zugriff hat?

Es wären Erläuterungen des Kontexts gut, warum P3-40 bis P3-180 (eingeschlossen) herausgenommen wurden. Ohne jene Erläuterungen wird eine intensive Absprache zwischen der technischen und fachlichen Abteilung benötigt, allein um sich die strukturellen Änderungen zu erschließen und in den Kontext zu setzen.

Eine Rückmeldung ob und wann dies erfolgen kann, wäre sehr hilfreich - Danke

Ich möchte Herr Wilms Anliegen auch aus unserer Sicht noch bekräftigen:
Es ist sehr mühevolle Arbeit die Dokumente einigermaßen effizient zu vergleichen. Eine Markierung mit Durchstreichungen und gelben MArkierungen im üblichen Stil wären hier sehr wertvoll.

Die Formulierung "Antworten, Rück- und Fehlermeldungen erfolgen in der für eine Software üblichen Reaktionszeit." ist missverständlich. Aus der Formulierung "eine Software" kann nicht geschlossen werden, dass es sich um das aufrufende PVS handeln muss. "Eine Software" kann als allgemeiner Vergleichsmaßstab irgendeine sehr langsame Software sein. Es wäre besser, zu definieren: "Antworten, Rück- und Fehlermeldungen erfolgen in der für die jeweils aufrufende Software üblichen Reaktionszeit".

Es wäre hilfreich, wenn die Veränderungen im Dokument (so wie normalerweise in den anderen KBV-Anforderungsdokumenten) hervorgehoben werden könnten.