Kommentierungs-Phase: Kommentare & Antworten Version 1.20.0

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.

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 74_PR_VoS_DokuRef 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).
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?
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.
Es soll eine entsprechende (PVS-) Zertifizierung zur Sicherstellung der Umsetzung der neuen Version zum 01.01.2022 geben.

Die Unterpunkte 3 + 4 aus Version 2.0.0 fehlt in Version 1.2.0 und sollten ergänzt werden, da es einen deutlichen Mehrwert bietet.

Unterpunkt 3
"Der Praxis müssen alle zur Einrichtung der Schnittstelle benötigten Daten ohne Hilfe Dritter verfügbar gemacht werden. Sowohl in PVS als auch VOS müssen Daten eingegeben werden, die im jeweils anderen System festgelegt werden (z. B. Aufruf-URL). PVS und VOS sollten dem Benutzer jeweils die Daten anzeigen, die er zur Konfiguration des jeweils anderen Systems benötigt."
Unterpunkt 4
"Der Benutzer muss in der Lage sein, die Aufrufparameter frei und vollständig an sein vorhandenes System anpassen zu können:
• Applikations-Pfad, wenn die VOS als Applikation aufgerufen wird
• URL und Port, wenn die VOS als Webseite aufgerufen wird
• Festlegung für die sichere Verbindung - der Benutzer sollte frei wählen können, ob er eine Verbindung über https verwenden möchte
• Authentifizierungsverfahren (der Benutzer sollte frei auswählen können, ob er die Authentifizierung über Benutzername und Passwort oder über Zertifikate verwenden möchte. Benutzernamen und Passwort sollten frei vergeben werden können)
• weitere Aufrufparameter (z.B. URL bei Aufruf als Applikation)"

Der Unterpunkt 4 aus Version 2.0.0 fehlt in Version 1.2.0 und sollte ergänzt werden, da es einen deutlichen Mehrwert bietet.

"Die Entscheidung, ob eine externe VoS angebunden werden soll, und die für die Anbindung benötigten Parameter müssen pro Arbeitsplatz festgelegt werden können."

Die Anforderung KP4-120 aus Version 2.0.0 fehlt in Version 1.2.0.
Es ist nicht klar ob eine Stornierung des E-Rezeptes aus der VoS erfolgen soll. Wenn ja, muss das in einer Anforderung präzisiert werden.

"Der Arzt kann die VoS mit dem Aufrufkontext = 12 aus dem PVS aufrufen. Begründung: Diese Anforderung ermöglicht den direkten Aufruf der Verordnungsfunktion „eRezept-Storno“ mit den dazugehörigen Daten. Akzeptanzkriterium: 5. Der Arzt kann mit dem Aufrufkontext = 12 die VoS aus dem PVS unter Berücksichtigung der Pflichtfunktion P4-10 aufrufen. 6. Das PVS stellt sicher, dass das entsprechende Aufruf-Bundle unter Berücksichtigung der Pflichtfunktion P4-10 der VoS übergeben wird. 7. Bei jedem Aufruf müssen die als „Pflicht“ gekennzeichneten Informationen gemäß Spalte „12 eRezeptStorno“ aus Tabelle 18 mit den zugehörigen FHIR-Profilen (siehe ebenfalls Tabelle 18) vom PVS im Aufruf-Bundle übergeben werden. 8. Bei jedem Aufruf können die als „erwartbar“ gekennzeichneten Informationen gemäß Spalte „12 eRezept-Storno“ aus Tabelle 18 mit den zugehörigen FHIR-Profilen (siehe ebenfalls Tabelle 18) vom PVS im Aufruf-Bundle übergeben werden. Bedingung: Diese Anforderung muss nur dann umgesetzt"

Die Anforderung aus Version 2.0.0 fehlt in der Version 1.2.0 und sollte ergänzt werden, da es einen deutlichen Mehrwert bietet.
"Begründung: Der Praxis müssen alle erforderlichen Informationen vorliegen, um die Einrichtung der Schnittstelle vornehmen zu können.
Akzeptanzkriterium:
1. Mitarbeiter/Mitarbeiterinnen einer Arztpraxis müssen in der Lage sein, die Schnittstelle sowohl in der Praxis-Software (PVS) als auch in der Verordnungssoftware (VOS) ohne fremde Hilfe selbst einrichten zu können.
2. Die Praxis muss auf eine Beschreibung zurückgreifen können, die die Einrichtung der Schnittstelle schrittweise und ausführlich erläutert. Diese Beschreibung muss in ihrer aktuellen Form für die Praxis ohne Beschränkung über die Webseite des Anbieters zugänglich sein:
3. Die Erfassung der notwendigen Verbindungsdaten in den Einstellungen des PVS muss direkt und ohne komplizierte Schrittfolge erreichbar sein (z. B. kein Schutz durch ein nur dem Hersteller/Support bekanntes Passwort)."

Die Anforderung aus Version 2.0.0 fehlt in der Version 1.2.0 und sollte ergänzt werden, da es einen deutlichen Mehrwert bietet.
"Begründung: Die Installation der Software soll für den Anwender einfach gestaltet werden. Akzeptanzkriterium: Sollte für die lokale Komponente des PVS eine Software-Installation durchgeführt werden müssen, muss der Hersteller ein Installationspaket zur Verfügung stellen, das die Installation nach Aufruf selbstständig und vollständig durchführt."

Der Unterpunkt 3 aus Version 2.0.0 fehlt in der Version 1.2.0 und sollte ergänzt werden, da es einen deutlichen Mehrwert bietet.
"Der Anwender/Arzt muss in der Lage sein, nach Eingabe der benötigten Parameter im PVS den Aufruf der VOS unmittelbar zu testen. Die Beschreibung des PVS muss einen Abschnitt enthalten, der die beim Setup auftretenden möglichen Fehler und ihre Behebung beschreibt."

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.

Gemäß der Übersicht der Aufrufkontexte in Kapitel 5.2, Tabelle 18 kann bei einigen Aufrufen auch ein signiertes E-Rezept als DocumentReference mitgegeben werden.
Es muss definiert werden wie mit abweichenden Informationen in E-Rezept und Vos-Profilen umgegangen werden soll.
Für die Aufrufkontexte 5-9 macht das übertragen des signierten E-Rezeptes keinen Sinn, da es für die im Aufrufkontext definierte Funktionalität nicht benötigt wird.

KP4-60: Aufrufkontext “Arzneimittelrecherche ohne Patientenkontext” (5) kann ein E-Rezept übergeben werden.
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)?
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 5.2, Tabelle 18 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”
Was bedeutet die Formulierung “mindestens”? Gibt es außer dem vorgeschlagenen Signaturverfahren noch weitere (erweiterte) Optionen?
Was genau ist unter der “Metainformation der Signatur” zu verstehen, die im PVS gespeichert werden muss?
Es fehlt die Angabe mit welchem Typ und ContentType die PKCS7-Datei an das PVS übertragen werden soll
Die PKCS7-Datei muss in derselben DocumentReference übertragen werden wie das E-Rezept, damit für das empfangene System der Zusammenhang zwischen beiden klar wird.
Welche Daten sollen übertragen werden? Handelt es sich hierbei um eine signierte PDF Datei oder um signierte E-Rezept FHIR Daten?

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.

Beim Sprung von Version 1.10.010 auf Version 1.2.0 handelt es sich nach den üblichen Konventionen um einen Rückschritt der Version. Es sollte wie üblich in der Softwareentwicklung ein Inkrement der Version auf z.B. 1.11.0 erfolgen.

Ergänzend zur Frage VOS1X2X0-7:

Für die im Simplifier Bundle example genannten Beispiel-Daten sehen wir keine umfängliche  Übergabe in andere Ressourcen der VoS FHIR Profile. Sollten die Ressourcen aus den gematik Profilen auf andere Weise in den VoS Ressourcen aufgehen, bitten wir um eine Erläuterung, welche das sein sollten.

Das Profil DokuRef soll laut Spezifikation das eRezept als PKCS#7-Datei enthalten. Bedeutet dies, dass innerhalb dieser Datei ein komplettes Bundle im Sinne von <span class="nobr"><a href="https://simplifier.net/erezept-workflow/Bundle-example/~xml" class="external-link" rel="nofollow">https://simplifier.net/erezept-workflow/Bundle-example/~xml^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> enthalten ist, oder soll dies komplett den ergänzenden Inhalt der gematik Profile enthalten, welche nicht durch eigene Profile der VoS abgedeckt werden?

Innerhalb des groupidentifier bestimmt der Identifier die Zugehörigkeit von einzelnen Medikamentenverschreibungen zu einem Rezept, wobei der Text sich auf die Papierform bezieht. Soll dies auch für die Zuordnung von bis zu 4 Medikationen zu einem eRezept über diesen Identifier zum Ausdruck gebracht werden, oder gibt es im Fall des eRezepts einen anderen Weg? Wenn es einen anderen Weg gibt: Welcher Weg wäre das?

<span class="nobr"><a href="https://simplifier.net/verordnungssoftware-schnittstelle/74prvosrezept" class="external-link" rel="nofollow">https://simplifier.net/verordnungssoftware-schnittstelle/74prvosrezept^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Die Rükgabe des Status über eine Stornierung von VoS zu PVS ist mit DocumentReference.extension:eRezept-Storno klar.
Aktuell würde natürlich über einen "allgemeineren Aufrufkontext" in der VOS eine Veranlassung zur Stornierung möglich sein, jedoch scheint uns dies ein eher komplizierter Weg.
Wie soll jedoch nun ohne den Aufrufkontext eRezept Storno eine Stornierung kundenfreundlich initiiert werden?