search

gematik / spec-ISiK-Dokumentenaustausch

The ISiK module "Document Exchange" (Dokumentenaustausch) provides FHIR resources as a specification, examples and an implementation guide. Theses resources enable newly created documents (e.g., forms filled out on a tablet; image documentation created using a smartphone app; findings documentation written on web-based clients; documents scanned with a smartphone camera; etc.) to be managed in clinical document management systems.
Other
4 stars 2 forks source link

Automatische zuweisung von KDL-Codes (bei vorhandenen XDS-Type-Codes) #20

Closed simoneOnFhir closed 2 years ago

simoneOnFhir commented 2 years ago

Kann bei einem Dokument, das von einem XDS-Repo/ePA übernommen wird automatisch ein KDL-Code (Resteklasse?/Übergeordnete Hierarchiebene?) zugewiesen werden?

simoneOnFhir commented 2 years ago

Mail v. Fr. Clees vom 29.11.:

_Die Frage war, welche KDL-Klassen in Frage kommen, wenn Dokumente im Rahmen der Patientenaufnahme erstmalig als Digitalisat zur Übertragung in andere Systeme ISiK-konform bereitgestellt werden. Hier kommen in unseren Projekten verschiedene KDL-Klassen zum Einsatz abhängig vom konkreten Dokument, um das es geht. So sind eine Reihe patienteneigener Dokumente spezifisch in der KDL enthalten, wie der Implantatpass oder Allergiepass. Eine Resteklasse ist hierfür ebenso vorgesehen. In unseren Projekten spielen diese Klassen eher eine untergeordnete Rolle. Aus der Diskussion am Freitag habe ich jedoch auch entnommen, dass es weniger um die Dokumente geht, die dem Patienten selbst gehören. Vielmehr drehte es sich um Dokumente, die eine Aufnahme für eine stationäre Behandlung begründen, wie Arztbriefe oder Befunde.

Resteklassen stehen in beiden Bereichen zur Verfügung, jedoch sieht die Arbeitsgruppe der KDL die Resteklassen nur als Fallback vor, wenn keine spezifische KDL-Klasse passt. Als Vorbelegung, um eine manuelle Klassifizierung zu erleichtern oder mangels geeignetem Regelwerk automatisiert etwas zuzuordnen, sind diese Resteklassen nicht gedacht.

Zu solchen spezifischen Fragen der Klassifizierung möchte ich vorschlagen, einen eigenen Sitzungstermin zu nutzen und Frau Müller in ihrer Rolle als Arbeitsgruppenleiterin für die KDL beim DVMD einzuladen. Da sie auch die Prozesse, die zur Entstehung von Dokumenten sehr gut kennt, könnte sie vermutlich hierzu hilfreichen Input geben. Da ich auch den Eindruck hatte, dass nicht alle Mitstreiter die AG die KDL so kennen wie wir als DMS-Anbieter, kann das möglicherweise auch Gelegenheit sein, Wissen zu verteilen._

AMuellerDVMD commented 2 years ago

Der Nutzen von Resteklassen in einem Klassifikationssystem besteht darin, sicherzustellen, dass alle zu klassierenden Einheiten mit einem Kode klassiert werden können. Dies gilt auch für die KDL-Resteklassen.

Das bedeutet, wird aus der ePA ein Dokument mit dem IHE-XDS typeCode BERI (Arztberichte) kommuniziert, ist es unkritisch, wenn - bei fehlendem spezifischem KDL-Kode - die Resteklasse AD010199 (Sonstiger Arztbericht) manuell oder automatisiert vergeben wird. Dieses Verfahren ist auf alle weiteren IHE-XDS typeCodes übertragbar.

Bei den IHE-XDS classCodes ist dieses Verfahren nicht nutzbar, da hier verschiedenste KDL-Unterklassen betroffen wären. Bspw. DUR (Durchführungsnachweis) - hierunter fallen sowohl Pflegedokumente, Intensivdokumente, Aufnahmedokumente, etc.

Die Frage ist jedoch ob es einen Anwendungsfall gäbe, wo nur IHE-XDS classCode in der ePA vorhanden und als Dokumentenmerkmal kommuniziert wird?

Mein Nicht-Expertenwissen: Ich bin der Meinung, dass die ePA IHE-XDS classCode UND IHE-XDS typeCode verlangt, um Dokumente zu beschreiben. Mit dieser Annahme wird bei der Kommunikation aus der ePA IHE-XDS typeCode generell übertragen. Damit ist auch die Generierung oder Wahl einer passenden KDL-Resteklasse möglich. Um das zu gewährleisten, ist dann aber IHE-XDS DocumentEntry.typeCode in ISiK ein MUSS sein. Aktuell ist nur ein KDL-Kode ein MUSS.

simoneOnFhir commented 2 years ago

Wäre es denkbar, dass der DVMD ein kuratiertes Mapping von IHE-Typecode auf KDL bereitstellt? Z.B. im Rahmen der nächsten KDL-Version?

AMuellerDVMD commented 2 years ago

Denkbar ist ein kuratiertes Mapping für typeCode auf KDL - ABER: Nach genauerer Prüfung wird dies nicht für alle typeCodes machbar sein, da bspw. FPRO in verschiedenen Klassen der KDL vorkommt. Gleiches gilt bspw. für GEBU. Die Idee, generell eine Reste-KDL aus einer Unterklasse zu verwenden, funktioniert daher nicht vollständig.

Der Nutzen eines weiteren (unvollständigen) Mappingkonzeptes muss von den Herstellern der Anwendungssysteme bewertet werden und sollte ggf. in einer der nächsten Sitzungen angesprochen werden.

Alternativen:

  1. Werden Dokumente ohne KDL-Kode, aber mit classCode und/oder typeCode kommuniziert, stellt das sendende System sicher, dass der KDL-Kode UB999999 (Sonstige medizinische Dokumentation) vergeben wird. Damit ist das Pflichtfeld KDL gesetzt.

  2. KDL-Kode ist kein Pflichtfeld in ISiK. classCode/typeCode sollten es schon sein, da sie auch im Rahmen der ePA-Kommunikation gesetzt sind.

  3. KDL-Kode muss generell in allen Anwendungssystemen (senden/empfangen) verwendet werden. Das ist aber ein sehr dickes Brett ;-)

simoneOnFhir commented 2 years ago

Rücksprache mit R. Kulisch: Die übernahme von Dokumenten aus der ePA Bedarf ohnehin einer Benutzerinteraktion um den Patientenkontext zu verifizieren und den Encounter zu wählen. Im Zuge dessen kann auch die KDL-Kodierung erfolgen. Die Auswahl relevanter Codes kann vorab auf Basis der Ordnerzugehörigkeit des Dokumentes in der ePA eingeschränkt werden.