Schnittstellenfestlegung Version 1.3.0

In den Observation Ressourcen finden sich immer wieder unterschiedliche Benennungen von Code-Slices. Es wäre wünschenswert, diese einheitlich zu benennen.

Wir regen an, für jedes MS Feld eine Beschreibung zu hinterlegen. Dies würde die Verständlichkeit erhöhen und Missverständnisse vermeiden.

Es sollte eine fachliche Erläuterung in jeder Profilbeschreibung hinzugefügt werden, um die Verständlichkeit und den Einsatzzweck der Ressource besser zu verstehen.

Es sollte eine einheitliche Verwendung von fixedValues bzw. Pattern stattfinden und nicht in einem Profil fixedValues und im anderen Pattern. Dies führt zu Unübersichtlichkeit.

Die aktuelle Angabe der verwendeten Code-Systeme <span class="nobr"><a href="https://hub.kbv.de/display/AWS/Verwendete+Code-Systeme" class="external-link" rel="nofollow">https://hub.kbv.de/display/AWS/Verwendete+Code-Systeme^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> sieht nach einem Copy-Paste von einer MIO Seite aus. Ist es möglich, eine vollständige Liste aller verwendeter Code System zu bekommen, die nicht von HL7 International definiert sind?

• Alle verwendeten Kataloge (ICD10, AlphaID, EBM, PZN,…)
• Alle verwendeten Code Systeme der KBV Basis
• Alle verwendeten Code Systeme aus der HL7 DE Basis
• Alle weiteren DE standard Code Systeme

Wie sieht die Roadmap für die AWST aus, um Datenportabilität in Deutschland herzustellen? Eine Einordnung dieser Ziele/Anwendungsfälle ist wünschenswert:

• Ablösung BDT/xBDT als defakto-Standard (Erweiterung des Scopes der AWST zum MVP)
• Verpflichtung von aktuell optionalen Profilen
• Harmonisierung mit anderen Deutschen Interop Standards
• MIO Integration in die AWST
• Positionierung des Bulk Data Export/Import auf der Roadmap
• Stabilität in die Profile für Abwärtskompatibilität

Eine Roadmap könnte dem Thema Datenportabilität eine Perspektive aufzeigen und es den Herstellern erlauben, Entwicklungen so zu planen, dass Synergien bei der Umsetzung anderer Interoperabilitätsanforderungen entstehen.

Aktuell sind nur Teile der definierten Profile verpflichtend (siehe Liste der Profile im Dokument mit den Festlegungen zur AWST). Es noch nicht möglich, basierend auf der AWST ein Primärsystem zu migrieren. Unserer Meinung nach sollte die AWST den Umfang des BDT/xBDT Formats abdecken, damit Datenmigrationen möglich werden.

Folgende Paketabhängigkeiten sind definiert:

• KBV AWST 1.3.0 → Basiert auf HL7 DE Basis Profile 1.3.2
• KBV AWST 1.2.0 → Basiert auf HL7 DE Basis Profile 0.9.12

In der AWST 1.3.0 wird ein Paket mit Breaking-Changes der HL7 DE Basisprofilen verwendet, somit gibt es zwischen Version 1.2.0 und 1.3.0 auch Breaking-Changes.

Beispiel von Breaking-Changes in der AWST:

• Die Verwendung des ICD-10 Coding-Profils aus der HL7 DE Basis in der Diagnose: <span class="nobr"><a href="https://ig.fhir.de/basisprofile-de/stable/Ressourcen-DiagnosenCondition.html" class="external-link" rel="nofollow">https://ig.fhir.de/basisprofile-de/stable/Ressourcen-DiagnosenCondition.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
• Einführung geänderter Canonical URLs für CodeSystem in Basis Profilen, was eine Datenmigration zwischen 1.2.0 und 1.3.0 erforderlich machen kann.
• Änderungen der Kardinalität in Profilen von 0..1 auf 1..1

Gemäß Guidelines zur Versionierung <span class="nobr"><a href="https://docs.npmjs.com/about-semantic-versioning" class="external-link" rel="nofollow">https://docs.npmjs.com/about-semantic-versioning^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> ist die Abwärtskompatibilität nicht mehr gegeben. Auch die Anforderung P6-20 weißt darauf hin, dass eine Abwärtskompatibilität bei der AWST nicht gegeben ist.

Wir sind der Auffassung, dass die Versionsnummer auf 2.0.0 geändert werden muss und darauf hingewiesen werden sollte, wo es in der Spezifikation Breaking-Changes gibt.

Keine Rezertifizierung bereits etablierter Primärsysteme ist eine Ungleichbehandlung und widerspricht dem eigentlichen Ziel der AWST, der Datenportabilität. Erfahrungsgemäß ist davon auszugehen, dass die Erweiterungen nicht vollumfänglich oder in der notwendigen Qualität (Breaking-Changes zwischen den AWST-Versionen) umgesetzt werden.

FHIR Profile bieten die Möglichkeit, jedem Element ein maschinenlesbares Mapping mitzugeben. Teilweise ist das für Informationen aus dem KVDT Datensatz bereits in den spezifizierten Profilen hinterlegt (z.B. Patient).

Es ist anzunehmen, dass Informationen dieser Formate in den am Markt existierenden PVS umgesetzt sind. Um die Implementierbarkeit durch PVS Hersteller zu verbessern, die Spezifikation eindeutiger zu machen, das Daten-Mapping zu standardisieren und die Vollständigkeit der AWST garantieren, sollten die bereits existierenden Datenformate auf die jeweiligen FHIR Ressourcen und Elemente gemappt werden.

Wir würden es Begrüßen, wenn folgende Mappings als Teil der FHIR Profile bereitgestellt werden:

• Vollständiges KVDT Mappings in den FHIR Profilen
• Vollständiges BDT Mappings in den FHIR Profilen
• Vollständiges LDT Mappings in den FHIR Profilen

Das Profil KBV_PR_AW_Person repräsentiert eine generische Person. Das kann bspw. ein Anwender, Arzt, MA, Patient etc. sein. Wie kann beim Import einer Person die richtige Zuordnung im Zieldatenmodell garantiert werden?
Können Sie bitte ein Beispiel nennen?

„Die Schnittstellenfestlegung tritt am Tag nach der Veröffentlichung in Kraft. Gleichzeitig tritt die Festlegung „Version 1.2.0“ außer Kraft.“ <span class="error">[Kapitel 6 Gültigkeit]</span>

Anwender möchte auf ein Zielsystem wechseln das noch nicht die Version 1.3.0 unterstützt. Dann muss folglich die Export/Import-Version auswählbar sein.

Ist dies ein zu unterstützendes Szenario bzw. wird es für Kunden eine Übergangsfrist für den Wechsel von Schnittstellenversion 1.2.0 auf 1.3.0 geben?

Wenn ja, sollte dann nur die Vorgängerversion berücksichtigt werden?

4.4, Seite 39: "Bei einem fehlerhaften Export sind alle erzeugten Dateien und Verzeichnisse zu löschen. Der Nutzer ist entsprechend unter Angabe der Fehlerursache darüber zu informieren. Die Reportdatei darf in diesem Fall nicht erzeugt werden.."

Aus unserer Erfahrung führt dieser "alles-oder-nichts"-Ansatz zu Problemen bei großen Exporten, die aufgrund von Fehlern abbrechen. Es wäre besser, wenn sich der Export "merkt", welche Daten bereits exportiert wurden und in der Lage wäre, beliebig neu zu starten und dann an der Stelle weiter zu extrahieren, an der der Abbruch erfolgte.

4.4, Seite 39: "Für die Daten der zusätzlichen Module mit KBV-Zertifizierung wie z.B. eDMP, LDT und eDoku gibt es keine Informationsobjekte. Diese Daten sind im Format und Version der jeweiligen Schnittstelle, die zum Zeitpunkt der Erstellung der Daten gültig war, in Form einer Anlage zu übertragen."
In unserem PVS werden die Exporte, z.B. für DMP, nicht in der exportierten Form als XML-Datei erhalten; es werden für eine DMP-Dokumentation nur alle Daten gespeichert. Aus den Daten wird das XML erzeugt und kann auch jederzeit wieder erzeugt werden. Aufgrund der laufenden Änderungen an der DMP-Schnittstelle werden aber nur die jeweils gültigen Vorschriften zur Erzeugung im System vorgehalten, eine Erstellung in einem historischen Format ist nicht möglich und auch nicht sinnvoll, da die Datenannahmestellen historische Formate im Zweifelsfall auch nicht mehr einlesen können.

In Kapitel 3 Einleitung wird festgelegt, dass trotz Erweiterung des Schnittstellenumfangs keine neue Zertifizierung notwendig wird. Dies wird erfahrungsgemäß dazu führen, dass die Erweiterungen nicht oder nicht vollumfänglich umgesetzt werden. Zugleich dient eine Zertifizierung auch der Qualitätskontrolle sowie der Klärung von Anforderungen, weswegen es wünschenswert wäre, wenn eine Zertifizierung durchgeführt wird.