Kommentare & Antworten Version 2.1.0

In der ersten Kommentierungsphase hatten wir diesen Punkt bereits angemerkt: "Der Speicherort der Log-Datei muss durch den Anwender/Arzt definierbar sein"

Dies halten wir für Überflüssig, da dies der Anwendung selbstüberlassen sein sollte wo diese die Logdaten speichert. Einem Anwender den Speicherort wählbar zu gestalten birgt zu viele weitere Probleme (z.B.: Zugriffeinschränkungen, etc.)

Beantwortet wurde der Hinweis damit, dass es eine Downloadmöglichkeit für den Nutzer geben soll.
Leider fehlen hierzu weitere Informationen:

Welcher Use Case steckt hinter dem Download von Log Daten?
Die Anwender können wohl kaum diese technischen Informationen in den Log Dateien lesen.
Wenn es schon spezifiziert wird, sollte es Regeln zur Verwaltung der Logs geben (bezogen auf Größe, Inhalt, Wann sollten Daten in den Logs gelöscht werden um keine unendlichen Dateien zu erzeugen ...)
Zudem sind hier auch Aspekte des Datenschutzes/DSGVO zu bedenken.

Was soll nach dem Download passieren? Werden die Logs weiter vorgehalten oder sollen diese dann zurückgesetzt werden?

Wünschenswert wäre hier dann eine weitere Definition zur Verwaltung und des Logverhaltens. Ansonsten wäre auch die Anforderung dem Anwender diese Log-Informationen zugänglich zu machen nicht zielführend.

Es gibt eine Inkompatibilität zwischen dem eRezept, der AWST (1.3.0) und der VOS (2.1.0) bei den MedicationRequest Profilen. Das Element Requester hat unterschiedliche Referenzen.

• eRezept: Practitioner
• AWST: PractitionerRole
• VOS: PractitionerRole
  Ein Practitioner kann mehrere assozierte PractitionerRoles haben. Das bedeutet, dass basierend auf dem Practitioner die PractitionerRole nicht eineindeutig ermittelt werden kann.
  Somit müssen beide Informationen (Practitioner + PractitionerRole) immer verarbeitet und gespeichert werden, um in einer Software alle Anwendungsfälle auf einer gemeinsamen technischen Basis abbilden zu können (Erstellung eines eRezepts + AWST/VOS Support). Die Profile sollten vereinheilticht werden.

Wir konnten Ihre Antwort auf unseren ersten Kommentar nicht ganz nachvollziehen. Aus diesem Grund müssen wir hier erneut kommentieren.

Sie schreiben, dass “das Profil des E-Rezepts <span class="error">[...]</span> als Grundlage direkt kopiert und nur an den Stellen angepasst, an denen eine Notwendigkeit für die VoS-SST bestand” wurde.

Was spricht hier gegen ein KBV Basisprofil? Extensions könnten entweder direkt in der Basis hinzugefügt werden, oder hier - im Use-Case-Spezifischen Profil. Für Implementierende und aus Gründen der generellen Ziele der Interoperabilität wäre es durchaus wünschenswert, wenn sowohl das eRezept-Profil, als auch das VOS-Profil dieselbe Basis hätten.

Wenn Sie sich gegen eine KBV Basis entscheiden sollten, würden wir uns wünschen, dass Sie uns die Gründe erläutern könnten, warum genau für dieses Profil keine Basis erstellt wird.

Wir konnten Ihre Antwort auf unseren ersten Kommentar nicht ganz nachvollziehen. Aus diesem Grund müssen wir hier erneut kommentieren.

Sie schreiben, dass “insbesondere bei ärztlichen Angaben nicht immer die Referenz auf den korrekten Practitioner möglich” ist und es durch die “Aufnahme der Provenance-Ressource <span class="error">[...]</span> ermöglicht wird, unter agent.who.type nur den Typ ohne Referenz anzugeben.”

Dies ist auch für AllergyIntolerance.asserter.type gegeben. Sowohl agent.who, als auch asserter.type nutzt den Datentyp “Reference”, welcher es erlaubt nur einen Typ anzugeben.

Vor diesem Hintergrund erscheint es uns nicht sinnvoll, ein weiteres Profil für Daten einzuführen, welches ohne Probleme in bereits definierten Profilen untergebracht werden kann.

Die Schnittstellenfestlegung sagt folgendes aus: "Die Authentifizierung des PVS erfolgt über ein Serverzertifikat."

Der Satz suggeriert, dass das PVS ein Zertifikat für eine Authentifizierung verwendet. In welchem Anwendungsfall authentifiziert sich das PVS an der Verordnungssoftware?
Oder erfolgt eine Authentifizierung der Verordnungssoftware am PVS per Zertifikat?

Falls es um eine Authentifizierung der Verordnungssoftware am PVS geht, müssen dann beide Verfahren unterstützt werden oder nur eins der beiden: Authentifizierung per Zertifikat + Benutzer/Passwort?

Entscheidet dann der Nutzer, welches Authentifizierungsverfahren verwendet wird?

"Niveau 1 ist nur gestattet, wenn die Kommunikation auf einem gesicherten System stattfindet (z.B. ein Praxisrechner). Andernfalls ist Niveau 2 umzusetzen."

Müssen für die Zertifizierung beide Sicherheitsniveaus 1 und 2 umgesetzt werden? Oder kann man als Hersteller festlegen, dass die Software nur auf einem gesicherten System eingesetzt werden darf? Im Rahmen der Zertifizierung ist nicht bekannt, was ein gesichertes System ist. Wäre es dann nicht eine Pflichtfunktion, wenn beide Sicherheitsniveaus unterstützt werden müssten?

1. Preisinformationen
Preisinformationen sind aus unserer Sicht (PVS) Teil der Verordnungssoftware
2. Medikationsplaninformation
"Grund und "Hinweis" sollten zusätzlich in FHIR übertragen werden.

1. Es sollte eine Möglichkeit geschaffen werden, dass auch Preisinformationen für das eRezept übertragen werden können.

2. Wir würden es begrüßen, wenn die Felder “Hinweis” und “Grund” auch in FHIR übertragen werden.

Das Profil ist nicht von der KBV-Basis abgeleitet. Wie wird die Interoperabilität zwischen dem eRezept MedicationRequest und und dem VOS MedicationRequest gewährleistet? Beide Spezifikation sollten von der Basis abgeleitet werden.

Was ist der Unterschied zwischen Patient.identifier:versichertenID_pkv und Patient.identifier:versichertennummer_pkv? In einer Antwort auf einen anderen Kommentar schreiben Sie: “Im Kommentar "E-REZEPT-24" wurde uns mitgeteilt, dass für die Nutzung der Anwendungen der Telematikinfrastruktur nur die 10-stellige "versichertenID_pkv" nutzbar und die "versichertennummer_pkv" nicht mehr enthalten ist. Aber für den Fall, dass kein E-Rezept ausgestellt wird kann es auch vorkommen, dass die "versichertennummer_pkv" Anwendung findet.” Könnten Sie uns weitere Informationen diesbezüglich mitteilen? Auch den erwähnten Kommentar können wir nicht finden.

Warum werden mehrere Telematik-IDs benötigt? Ist die Logik hier, dass wenn mehrere Ärzte in einer Betriebsstätte arbeiten, sämtliche Telematik-IDs der Ärzte übertragen werden?

Für dieses Profil sollte ein Basis-Profil erstellt und entsprechend von diesem abgeleitet werden, um die Interoperabilität zwischen diesem und dem PKA-Profil Pregnancy_Status herzustellen (<span class="nobr"><a href="https://simplifier.net/pka/kbv_pr_mio_nfd_observation_pregnancy_status" class="external-link" rel="nofollow">https://simplifier.net/pka/kbv_pr_mio_nfd_observation_pregnancy_status^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>).
Falls hier kein Basis-Profil erstellt wird, sollte das Element value<span class="error">[x]</span> als codierter Wert statt einem Boolean gespeichert werden. Weiterhin sollte der gleiche LOINC Code wie im PKA Profil verwendet werden. Falls es für den Schwangerschaftsstatus einen entsprechenden Snomed Code gibt, wäre es auch wünschenswert, wenn sich dieser im Profil wiederfindet.

Warum wird hier kein Snomed-Code verwendet?

Warum wird hier nicht das MIO-Mutterpass Profil und die entsprechenden Codesysteme wiederverwendet (<span class="nobr"><a href="https://simplifier.net/mp1x0/kbvprmiomrobservationbreastfeedingbehavior" class="external-link" rel="nofollow">https://simplifier.net/mp1x0/kbvprmiomrobservationbreastfeedingbehavior^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> / <span class="nobr"><a href="https://simplifier.net/mp1x0/kbvvsmiomrbreastfeedingbehavior" class="external-link" rel="nofollow">https://simplifier.net/mp1x0/kbvvsmiomrbreastfeedingbehavior^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> )? Es könnte auch ein Basis-Profil erstellt werden und von diesem entsprechend abgeleitet werden.
Konsistenz bei der Benennung der Code-Slices wäre wünschenswert - siehe:
BodyWeight = Observation.code.coding:loinc
BreastFeeding_Status = Observation.code.coding:codeLoinc

Das Element Observation.effective<span class="error">[x]</span> sollte als mustSupport definiert sein.

Das Element Observation.effective<span class="error">[x]</span> sollte als mustSupport definiert sein.

Im Sinne der Eindeutigkeit sollte die Kardinalität der Extensions begrenzt werden (3..4 statt 3..*).

Im Sinne der Eindeutigkeit sollte die Kardinalität der Extensions begrenzt werden (2..3 statt 2..*).

Im Sinne der Eindeutigkeit sollte die Kardinalität der Extensions begrenzt werden (2..2 statt 2..*).

Im Sinne der Eindeutigkeit sollte die Kardinalität der Extensions begrenzt werden (3..5 statt 3..*).

Warum hat das Element Medication.ingredient.item<span class="error">[x]</span>:itemCodeableConcept.coding:pznCode eine Kardinalität von 0..1? Gibt es hier einen Edge-Case?

Das Profil sollte mit dem ISiK Datenaustausch-Profil (<span class="nobr"><a href="https://simplifier.net/spec-isik-dokumentenaustausch/isikdokumentenmetadaten" class="external-link" rel="nofollow">https://simplifier.net/spec-isik-dokumentenaustausch/isikdokumentenmetadaten^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) harmonisiert werden. Im Speziellen die Elemente type und category.
Das Element DocumentReference.date sollte als mustSupport definiert sein.

Das Element Device.type.text ist gleichzeitig mustSupport und hat die Kardinalität 0..0.

Im Sinne der Interoperabilität sollte für die Coverage ein KBV-Basis-Profil erstellt werden, welches dann für die VOS, FOR und AWS genutzt wird.

Im Sinne der Vollständigkeit und Homogenität sollte das Element Condition.clinicalStatus.coding.version als mustSupport definiert sein.

Weiterhin fragen wir uns warum die Elemente Condition.clinicalStatus.coding.display und Condition.verificationStatus.coding.display als mustSupports definiert sind. Was ist hier der konkrete UseCase?

Im Sinne der Vollständigkeit und Homogenität sollte das Element Composition.subject.reference als mustSupport definiert sein. Weiterhin sollte im Profil eine einheitliche Verwendung von Pattern/FixedValues angestrebt werden.

P5-20: Hier könnte ein weiteres Akzeptanzkriterium ergänzt werden, welche es der VOS erlaubt Daten zu ignorieren (die keine mustSupport Eigenschaft besitzen), statt einzelne Profilelemente auf 0..0 zu beschränken.

KP4-140: Versichertenart, BesonderePersonengruppe und DMP sind für gesetzlich Versicherte Pflichtfelder. Ist diese Anforderung ausschließlich für Privatversicherte relevant? Weiterhin wäre es auch wünschenswert, wenn ergänzt wird, wo diese Informationen übertragen werden, wenn diese vorhanden sind.

Weiterhin könnte das erste Akzeptanzkriterium erweitert werden: von “sprich befüllen und übermitteln können” zu “sprich befüllen und übermitteln können - wenn diese im System vorliegen”. Als Beispiel sei hier KBV_PR_VoS_Organization.identifier:KZV-Abrechnungsnummer genannt. In einem Nicht-Zahnarzt-System ist diese Information nicht vorhanden. Die Anforderung würde aber verlangen, ein Feld im System für die Befüllung dieses Feldes vorzuhalten.

P3-210: Die Anforderung beschreibt den Umgang mit Elementen, welche mit der Eigenschaft mustSupport gekennzeichnet sind. Über dieses Element wird sichergestellt, dass Systeme Elemente mit dieser Eigenschaft befüllen, übermitteln, auslesen und verarbeiten können. Wir möchten anregen, diese Anforderung um ein weiteres Akzeptanzkriterium zu erweitern. Dieses soll regeln, dass sämtliche Elemente ohne die mustSupport Eigenschaft von Systemen ignoriert werden können. Dies soll es ermöglichen, auf sämtliche 0..0 Constraints der Profile zu verzichten.

Das Profil KBV_PR_VoS_Provenance_AllergyIntolerance sollte entfernt werden. Die Information, ob Allergien ärztlich diagnostiziert oder Eigenangaben der behandelten Person sind, lassen sich sehr gut über die Elemente asserter und onset des Profils KBV_PR_VoS_AllergyIntolerance abbilden.
(Auf "doppelte" Kommentare an den jeweiligen Profilen und der Schnittstelle wird unsererseits verzichtet)

In der änderungsmarkierten Version des Anforderungskatalogs Version 2.1.0 wurde das Kapitel 3.2 "KBV Profile" komplett gestrichen. Dieses Kapitel enthielt Mappings von Praxis, patienten- und Verordnungsdaten auf FHIR. Hier sind uns Hintergrund und Auswirkungen der Streichung nicht klar.

das Vorhandensein des Attributs "Rezeptpflicht" zu einem Medikament ist wichtig, wenn es z.B. auf PVS-Seite um die Entscheidung geht, ob ein eRezept erstellt werden darf bzw. vorher ein Dialog mit dem Anwender imitiert werden müsste.
Der Rezepttyp ist hier leider keine Alternative, denn eine Verordnungssoftware kann ein nicht rezeptpflichtiges Medikament auf ein M16 übertragen.
Die "FHIR-Festlegung R4" sollte kein Kriterium sein. Nach Kenntnis dürfen in einer Ableitung Streichungen, Ergänzungen etc. bestehen.
Man könnte auch eine weitere Extension für das Attribut "Rezeptpflicht" einführen (die Extension's sind übrigens auch nicht in der R4 enthalten).
Ich möchte hiermit nochmals darum bitten, das "Rezeptpflicht"-Attribut zu belassen.

In der Resource KBV_PR_VoS_MedicationStatement_MP ist für eine Rezeptübergabe (VoS->PVS) ist nur eine codierte Dosierung parametrierbar. Die Möglichkeit einer Freitext-Dosierung bzw. "Dj" fehlt.

Ein Attribut für "Rezeptpflicht" fehlt jetzt.
In der VoS 1.20 gab es das Attribut medication.sOverTheCounter mit dem die Verordnungssoftware bei einer Rezeptübergabe dem PVS mitteilt, ob für das Medikament eine Rezeptpflicht besteht.
Dieses ist für die Auswahl des Rezeptträgers auf PVS-Seite (Stichwort "AVWG") notwendig.

Für einen "reinen Zahnarzt" (nicht-Mediziner) ist der Value für Practitioner.identifer.ANR dem PVS unbekannt.
Daher plädieren wir für eine Kardinalität 0..1

Im Hinblick auf die Verfügbarkeit dieses Values vor allem bei einemPKV-Versichertenverhältnis plädiere ich wie gehabt für eine Kardinalität 0..1

Die 5 möglichen identifier sind redundant

die Paare

• pid
• versichertenid_GKV

• versichertennummer_pkv
• versichertenID_pkv

sind redundant.

Sind nicht analog zum eRp bzw. eAU die 3 Identifier

• versichertenid_GKV
• versichertennummer_kvk
• versichertennummer_pkv

ausreichend ?

Eine Zahnarztpraxis/PVS kennt keine Betriebsstättennummer.
Hier wird alternativ Organization.identifier.KZV-Abrechnungsnummer gesetzt wird.

Siehe hierfür auch das Profil KBV_PR_FOR_Organization

Mehr Beispiele der Form

• KBV_PR_VoS_Bundle_VoS_PVS als auch
• KBV_PR_VoS_Bundle_PVS_VoS
  machen die Schnittstelle verständlicher.

KBV_PR_VoS_Bundle_VoS_PVS mit diversen Coverage Variationen,

KBV_PR_VoS_Bundle_VoS_PVS mit unterschiedlichen Medications

• KBV_PR_VoS_Medication_PZN
• KBV_PR_VoS_Medication_Compounding
• KBV_PR_VoS_Medication_FreeText
• KBV_PR_VoS_Medication_Ingredient
• als auch 2 oder 3 Medikamente gleichzeitig auf einem Rezept

Frage:
Birgt eine Dosierungsangabe einerseits in
MedicationStatement->dosageinstruction
andererseits in
MedicationRequest->dosage

nicht Redundanzen bzw. warum hat man unter MedicationStatement->dosage den Freitexttyp nicht belassen?

Als Motiv zur Änderung der VoS schreiben Sie, Zitat:
"Anpassungen an das eRezept in der Version 1.1.0 und Nutzung der Profile als Vorlage für die VoS-Profile".

Daher ist nicht verständlich, wieso es neue Profile explizit für VoS gibt
(z.B. Patient,Practitioner,Organization,Coverage), die von Ihrem Inhalt von den entsprechenden Profilen des eRezeptes abweichen.
Sollte man nicht vielmehr Updates der eRezept-Profile definieren und diese dann unter VoS 2.1.0 referenzieren ?

Beispiel: "Patient->identifier"
hier gibt es nun zusätzlich "versichertennummer_pkv".
Diese ist aber im Zusammenhang mit "eRezept für PKV-Patienten" auch für das eRezept sinnvoll.