Anforderungskatalog Version 1.3.0

Der Export von LDT-Befunddaten setzt voraus, dass das exportierende System diese auch erstellen kann. Ein „normales“ Praxisverwaltungssystem sollte laut Empfehlung der KBV (<span class="nobr"><a href="https://update.kbv.de/ita-update/Labor/Labordatenkommunikation/KBV_ITA_VGEX_FAQ_LDK.pdf" class="external-link" rel="nofollow">https://update.kbv.de/ita-update/Labor/Labordatenkommunikation/KBV_ITA_VGEX_FAQ_LDK.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) den LDT-Auftrag Export, sowie den LDT-Befund-Import implementieren.

Die Anforderung P6-03 fordert nun vom PVS einen Export im LDT Format in einer Anlage. Dies zwingt PVS-Hersteller - wenn diese nicht die empfangenen LDT-Befund-Dateien speichern - zusätzlich den LDT-Befund-Export zu implementieren, da sonst keine LDT-Datei erzeugt werden kann.
Eine Speicherung von empfangenen LDT-Dateien ist jedoch nach dem LDK Anforderungskatalog nicht vorgesehen.

Wir würden es daher begrüßen, das bereits in Entwicklung befindliche MIO Laborbefund in die AWST zu integrieren. Dies sollte dazu führen, dass eine entsprechende Anforderung im Anforderungskatalog aufgenommen wird und die Anforderung P6-03 gestrichen wird.”

Wenn ein Export der Patientenakte mit der Option “mit Terminen” gemäß Akzeptanzkriterium 7 stattfindet, sollen die Termine des Patienten dann Teil des Patientenakten-Bundles sein, oder sollen die Termine in dem Termin-Bundle gespeichert werden?

Warum gibt es keine dedizierte Anforderung für die Anlage des Sprechstundenbedarfs? Aktuell ist das Erzeugen des Sprechstundenbedarf-Bundles Teil der Anforderung KP4-04, jedoch geht aus der Anforderung die fachliche Verbindung zur Patientenakte nicht hervor.

Wie wirken sich die Suchparameter für die Einschränkung des Exports auf den Sprechstundenbedarf aus? Wenn man man z.B. die Patientenakte für einen Patienten exportiert ist es wahrscheinlich nicht notwendig den gesamten Sprechstundenbedarf zu exportieren.

Darüber hinaus enthält das Bundle für den Sprechstundenbedarf diese Entries:

• einen Slice für eine Composition für das Rezept
• und ein für den supplyRequest Sprechstundenbedarf

Wir gehen davon aus, dass Compositions für ein Rezept mit Patientenkontext (medicationRequest) nicht Bestandteil des Sprechstundenbedarf Bundles sein soll. Das muss noch ausspezifiziert werden.

Es wurde nicht definiert, wie mit Dokument-Metadaten (DocumentReference) umzugehen ist, bzw. konnte das aus der jetzigen Spezifikation durch uns nicht herausgelesen werden.

Die Anforderungen für die einzelnen Bundles (KP4-01, P4-02, P4-03, P4-04) geben dazu keine Auskunft In welchem Bundle werden die Metadaten welcher Dokumenttypen gespeichert?
Wenn die Unterscheidung nicht auf Basis von Dokumenttypen getroffen wird, wie werden Dokumente und deren Metadaten für den Export selektiert und einem Bundle zugeordnet?

Mögliche Bundles für das abspeichern der Dokument Metadaten:

• Bundle Adressbuch (KP4-02)
• Bundle Behandlungsbaustein (KP4-03)
• Bundle Patientenakte (KP4-04)
• Bundle Sprechstundenbedarf (KP4-04)
• Bundle Termin (KP4-01)

Dem stehen diese Ordner für Anlagen entgegen:

• Abrechnung
• Begegnung
• Behandler
• Behandlungsbaustein
• Betriebsstätte
• Patient
• Sonstige

Auf Basis der Zuordnung einer Anlage zu einem Ordner, kann nicht eindeutig das passende Bundle für die documentReference identifiziert werden.

Warum ist der Ordner Begegnung nicht ein Unterordner des Ordners Patient? Gibt es ein Dokument, das Fall-Kontext hat, aber keinen Patienten-Kontext? Med. Dokumente haben in der Regel einen Fall-Kontext und landen somit alle in einem gemeinsamen Ordner für die Begegnungen für alle Patienten. Ich glaube, die Auffindbarkeit wird hiermit nicht verbessert, da es nicht der gängigen Informationshierarchie folgt.

Akzeptanzkriterium 3 ist nicht nachvollziehbar:

“ (2) Im Ordner Begegnung müssen alle Anlagedateien (referenziert im KBV-Profil KBV_PR_AW_Anlage) die auf das KBV-Profil KBV_PR_AW_Begegnung referenzieren <span class="error">[...]</span> gespeichert werden

(3) Dies gilt ebenso für alle Instanzen, die auf das KBV-Profil KBV_PR_AW_Begegnung referenzieren und auf die aus dem KBV-Profil KBV_PR_AW_Anlage referenziert wird.”

Was für eine Konstellation ist damit gemeint?

Was passiert mit Dokumenten, die einen Patienten/Encounter und eine Claim Ressource referenzieren? In welchem Ordner soll diese gespeichert werden, Begegnung/Patient oder Abrechnung?

Die Einschränkung der Zuordnung zu dem Ordner passiert in der Spezifikation auf Basis eines Profils, das Profil kann nicht aus der Referenz in der documentReference ermittelt werden und würde eine Suche nach der Ressource im Bundle oder im Backend erfordern, um die Art der Abrechnung bzw. das Profil zu ermitteln. Ich befürchte, dass so etwas in einem Export sehr langsam wird. Wenn die Einschränkung auf Basis des Ressourcen-Typs erfolgt, wäre das nicht notwendig. Oder noch besser, auf Basis des Dokumenttyps in der documentReference.

Akzeptanzkriterium 3 schreibt, dass Verträge nicht in diesem Ordner gespeichert werden dürfen. Was sind “weitere Verträge” für die Abrechnung? Wie sind diese Verträge zu identifizieren, wenn diese auch einen Claim referenzieren?

In den Anforderungen KP5-54, KP5-55, KP5-56, KP5-57, KP5-58 wird festgelegt, dass entsprechend der referenzierte Ressourcen Anlagen in einen bestimmten Ordner kommen. Diese Zuordnung sollte auf basis standardisierter Dokumenttypen passieren, statt exportierende System zu zwingen, mögliche vorhandene Referenzen zu entfernen.
Darüber hinaus gibt es in der AWST Spezifikation keine Festlegung, welche Referenzen überhaupt zu einer documentReference hinzuzufügen sind.

Der aktuell spezifizierten Logik folgend, müsste die Einschränkung in P6-10 für Practitioner, practitionerRole und mehreren Organizations erweitert werden, um bei der Zuordnung der Dokumente gemäß KP5-54, KP5-55, KP5-56, KP5-57, KP5-58 Eindeutigkeit herzustellen.

• Wenn ein Dokument eine Referenz auf Patient und Organization Ressource hat, welche Referenz soll beim Exportieren entfernt werden?
• Wenn ein Dokument eine Referenz auf Patient und Practitioner Ressource hat, welche Referenz soll beim Exportieren entfernt werden?
• Was passiert mit Dokumenten, die eine Referenzen auf eine PractitionerRole Ressource haben?
• Was passiert mit Dokumenten, die eine Referenz auf Organization und Practitioner Ressource haben, welche Referenz soll beim Exportieren entfernt werden?
• Was passiert mit Dokumenten, die eine Organization, Practitioner und einen Behandlungsbaustein Ressource referenzieren?
• Was passiert mit Dokumenten, die eigene Betriebsstätte und eine andere Organization Ressource referenzieren (z.B. andere Betriebsstätte oder Krankenkasse?)

Das Problem lässt sich bei einer Zuordnung auf Basis von standardisierten Dokumenttypen umgehen.

Zur Verbesserung der Interoperabilität, Kompatibilität mit der TI ePA und ISiK und der Implementierbarkeit der AWST sollten standardisierte Dokumenttypen für med. Dokumente verwendet werden. Zum Beispiel die DokTypen der KDL, für welches Code-System auch ein XDS-Mapping existiert. <span class="nobr"><a href="https://simplifier.net/kdl/codesystem-kdl-2022" class="external-link" rel="nofollow">https://simplifier.net/kdl/codesystem-kdl-2022^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Fehlende Codes für Dokumente, die nur im Kontext einer PVS Migration existieren (Anlage als Fallback-Mechanismus), sollten in einem eigenen Code-System definiert werden.

Einrichtungs-/Behandler-bezogene Doktypen ohne einen Patientenkontext (z.B. erzeugte Statistiken und Übersichten) sollten in einem eigenen CodeSystem abgebildet sein, um diese Semantik über das CodeSystem herzustellen.

Auf basis von standardisierten Dokumenttypen lassen sich folgende Sachverhalte in der AWST Spezifikation verbessern:

• Dokumente eindeutig einem Ordner in der Datenstruktur zuordnen
• Dokumente eindeutig einem Bundle zuordnen
• Vorhandene Referenzen in Dokument Metadaten müssen beim Export nicht entfernt werden
• Dokumente können nicht auf Basis der Referenz in den Metadaten einem Ordner zugeordnet werden, da in der Referenz das Profil der referenzierten Ressource nicht bekannt ist.

Es reicht unserer Meinung nach nicht aus, nur festzulegen, dass eine documentReference genau eine Referenz (Patient, Betriebsstätte, Begegnung) haben muss (P6-10).

Zum einen bedeutet dies für das exportierende System bedeutet, dass evtl. vorhandene Informationen weggeschmissen werden und kollidiert mit der Anforderung P3-07.

Gleichzeitig gibt es in Abhängigkeit des Dokumenttyps eine Reihenfolge der Wichtigkeit der referenzierten Informationen.
z.B: Alle Dokumente mit einem Encounter-Kontext haben automatisch auch einen Patienten-Kontext. Der Encounter-Kontext sollte nie in einer documentReference entfernt werden, wenn dieser vorhanden ist.

“Jede Anlage hat genau eine Beziehung zu einer Begegnung, einem Patienten oder einer Betriebsstätte. Diese Beziehung kann allerdings durch eine weitere Referenz (z. B. auf einen Befund) typisiert werden.”

Was bedeutet die Typisierung dieser Beziehung? Welche Information soll dadurch ausgedrückt werden? Diese weitere Referenz kann einen Kontext zu einem anderen Informationsobjekt herstellen, aber nicht das Dokument oder eine andere Referenz in der Ressource typisieren.

Da referenzierte Ressourcen zu den Bundles hinzugefügt werden, sind die gleichen Ressourcen in verschiedenen Bundles enthalten (z.B. Organization, Practitioner). Die Informationen sind somit redundant. Es braucht eine stabile logische Ressourcen-ID, damit sich die Daten beim Import wieder zusammenführen lassen.
Fachlich sollte ausgeschlossen werden, dass Ressourcen IDs nur im Kontext eines Bundles existiern und beim Erstellen des Bundels dynamisch generiert werden.

• Das erfordert, dass die gleiche Ressource in jedem Bundle auch die gleiche logische Ressourcen-ID hat.
• Die logische Ressourcen-ID einer Ressource muss immer gleich bleiben, auch bei einem mehrfachen Export der gleichen Daten.

Alle Dummy-Werte sollten mit der Data-Absent-Reason Extension versehen werden, ansonsten geht diese Information verloren. Das exportierende System sollte angeben, ob ein Wert unbekannt ist oder nicht-supported, da das ein fachlicher Unterschied ist. <span class="nobr"><a href="https://www.hl7.org/fhir/valueset-data-absent-reason.html" class="external-link" rel="nofollow">https://www.hl7.org/fhir/valueset-data-absent-reason.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Ist dieses Vorgehen nur für die Patienten Ressource und der documentReference Ressource (Anlage) vorgesehen? Was ist mit allen anderen Ressourcen?

Es gibt eine Welt vor der AWST mit legacy Daten. Diese Daten lassen sich u.U. nicht in eine FHIR kompatible Datenstruktur migrieren und evtl. auch nicht anreichern, um eine valide FHIR-Ressource zu erzeugen. Somit würde eine gesamte Ressource nicht exportiert werden können, weil ein Element fehlt. Durch den Fallback auf ein generiertes PDF Dokument gehen u.U. strukturierte Informationen, die dem Standard entsprechen, für den Import verloren.

Parallel muss davon ausgegangen werden, dass in der Praxis beim Export Dummy-Werte eingestzt werden, um MustSupport und 1..1 Element in den FHIR Ressourcen zu befüllen, damit die Ressourcen erfolgreich validiert werden können bzw. das System zu zertifizieren.

Wenn Daten inkompatibel sind, nicht vorhanden sind oder nicht verarbeitet werden, sollte es zusätzlich zum PDF-Fallback den Weg geben, die Data-Absent-Reason Extension einzufügen, um die strukturierten Informationen zu exportieren.

Auf organisatorischem Wege muss festgelegt sein, dass die Data-Absent-Reason Extension als Fallback nur für historische Daten verwendet wird. Entsprechend darf der Fallback nicht für Daten verwendet werden, die mit einer AWST-zertifizierten Programmversion des PVS erstellt wurden, da davon auszgehen ist, dass in der zertifizierten Programmversion das Problem bzw. die Inkompatibilität behoben wurde.

Es ist möglich mittels passendem Testfällen und Testdaten die Vollständigkeit des Exports/Imports eines Systems zu überprüfen. Import eines Maximaldatensatz, mit anschließendem Export der Testdaten, wobei in diesem Export kein Data-Absent-Reason vorhanden sein darf, da die Testdaten vollständig sind.

Im Sinne der Standardisierung muss eine Variante für das Referenzieren von Ressourcen vorgegeben sein (Logische Referenzen vs. Absolute/Relative Referenzen).

Beim Import von Daten müssen im Zielsystzem die Referenzen zwischen Informationsobjekten auf Basis der im Export bereitgestellten Referenzen wieder hergestellt werden. Bei der Verwendung logischen Referenzen muss immer über den Business Identifier das zu verlinkende Objekt gesucht werden, was sehr teuer/aufwändig werden kann.

Bei relativen Referenzen könnte man hingegen beim Import mit einem Look-up Table für die Ressourcen IDs aus dem Export- und Importsystem arbeiten, was die Performance des Imports verbessert.

Worst-Case-Szenario ist, wenn für den Export nichts festgelegt ist und man Referenzen immer unterschiedlich behandeln kann (ggf. unterschiedlich je Ressource oder gar unterschiedlich innerhalb eines einzelnen Ressourcentyps). Meiner Meinung nach sollte immer eine relative Referenz auf die Ressource angegeben werden und es den Systemen überlassen sein, ob zusätzlich die Business Identifier oder Name in der Referenz mit übertragen werden.

In vielen Profilen der AWST folgt man diesem Ansatz und macht die Referenz zu einem verpflichtenden Element. Hier sollte man evtl. noch definieren, dass es sich um eine relative Referenz handelt.

Beim Export vorhandene Informationen sollten auf keinen Fall entfernt werden. Ich glaub man wird bei ganz anderen Teilen der Spezifikation Probleme mit dem Datenvolumen haben:

• bei der Historie
  -bei Provenance Ressource
  -bei dem Hinzufügen aller referenzierter Ressourcen zu einem Bundle (Administrative -Ressourcen inklusive deren Historie werden Teil aller Bundels sein)
• Generierung der Narrative mit sämtlichen Inhalten + anschließender Konvertierung zu PDF

Vor diesem Hintergrund werden die 3 Elemente zusätzlichen einer Referenz im Volumen wahrscheinlich nicht auffallen.

Falls in der Anforderung P3-19 andere URLs gemeinst sein sollten, geht das nicht aus der Anforderung hervor und muss konkretisiert werden.

Es gibt für diese konditionale Pflichtfunktionen keine Bedingung in den Anforderungen.

• KP3-08
• KP3-09

Anforderung: In den BUNDLE-Dateien müssen alle für das jeweilige BUNDLE definierten Ressourcen aufgenommen werden. Dabei sind die Definitionen für die unterschiedlichen Ressourcentypen zu beachten.

Definition im laut Root-Element in den FHIR Profilen: Das Bundle fasst alle Inhalte der Patientenakte zusammen. In dem Element Entry wurde nur die erste Ebene der Ressourcen angegeben, d.h. es wurden nur die Ressourcen explizit aufgeführt, die auf andere Ressourcen verweisen und auf die, im Sinne dieses Bundles, selbst nicht referenziert werden.

• Patientenakte: enthält keine Bundle.entries
• Adressbuch: enthält keine Bundle.entries
• Behandlungsbaustein: Bundle.entires sind definiert, aber Anlage fehlt
• Sprechstundenbedarf: Bundle.entries sind definiert, aber Anlage fehlt
• Termin: Bundle.entries sind definiert, aber Anlage fehlt

Es gibt keine Festlegungen/Anforderungen, wie die Bundles zu validieren sind. Das kann beispielsweise mit dem FHIR Validator oder aber auch mit einem XML Schema passieren. Die Ergebnisse der Validierung werden wahrscheinlich unterschiedlich sein.

Ein valides Export-Bundle kann beim Import u.U. nicht validiert werden. Eine aussagekräftige Fehlermeldung wird dabei auch nicht möglich sein, da es sich um das Bundle eines anderen Systems handelt.

Der Alles-oder-Nichts Ansatz ist aus Sicht der Vollständigkeit und Korrektheit zwar nachvollziehbar, wird aber zu einem Problem, wenn nur ein Element nicht valide ist oder die Validierung im Export- und Import-System jeweils unterschiedlich implementiert wurde.

Die Implementierbarkeit und das Funktionieren des Exports und Imports in produktiven Systemen (mit Legacy-Daten) erfordert meiner Meinung nach die Verwendung eines bereitgestellten Referenzvalidators der beim Export- und Importschritt gleiche Validierungsergebnisse liefern wird.

Beispiel und Rahmenbedingungen wie die PDFs aus Sicht der KBV auszusehen haben bzw was sie enthalten sollen wäre sehr hilfreich.

Müssen wirklich alle Informationen aus der XML auch ins PDF oder kann das reduziert wenn, wenn ja welche Bedingungen gibt es dafür.

Auf Grund der Performance kommen wir in Extrapolationen zu dem Problem, dass ein Wechsel des Systems auf Grund der Validierung mehrere Tage dauern kann.

Folgende Lösung haben wir dafür angedacht:

Trennung der Funktionalität von Archivierung und Wechsel.
Vorab: Auch bei der Trennung in der Anwendungen bleiben die Profile für beide Anwendungen die gleichen.

Bei der Archivierung sollte wie bisher ein XML-Bundle und eine PDF erzeugt werden.

Für den Wechsel zwischen zwei Systemen haben wir folgenden Vorschlag:

In der Zeit des Wechsels müssen beide Server laufen. Beide Server besitzen entsprechende FHIR-Rest-Endpunkte.
Das neue System kann dann die Daten aus dem alten System in einer für es selbst passenden Form abfragen. Zum Beispiel erst die Benutzer, dann die Ärzte, dann die Pateintenstammdaten, dann die Scheine des aktuellen Quartals,...
Ein Vorteil dieser Variante ist, dass das Abfragende System deutlich einfacher die Daten ins eigene System übertragen kann und Dopplungen vermieden werden (keine Prüfung mehr nötig, z.B. ob der entsprechende Arzt schon importiert wurde aus einem anderen Patienten-Bundle).
Zudem ist bei diesem Verfahren möglich, dass das neue System gezielt nur die Patientenstammdaten und alle nicht abgerechneten Scheine, Privatabrechnungen zuerst ins neue System überträgt. Somit wird die Unterbrechung von möglicherweise Tagen(Hochrechnung) deutlich reduziert. Die restlichen Daten könnte das neue System dann im Hintergrund vom Altsystem abfragen und übernehmen.

Aus usnerer Sicht würde das die Nutzbarkeit der Schnittstelle deutlich verbessern.