Schnittstellenfestlegung Version 1.2.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.

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.

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.

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

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?

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"