Anforderungskatalog Version 2.1.0

"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?

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.