Stream: german (d-a-ch)
Topic: Fallarten
Thorsten Conrad (Sep 15 2016 at 08:32):
Hallo,
wie können wir die deutschen Fallarten in FHIR abbilden? Die Encounter Ressource bietet leider nur ein festes, internes ValueSet an, welches nicht erweitert werden kann. In der Spec steht zwar, dass man den Code „other“ nehmen kann, dann aber über eine Extension diesen Wert näher spezifizieren soll. Die bisher definierten Extensions passen aber nicht richtig.
Mir geht es im speziellen um die Werte wie z.B. Vorstationär, Nachstationär, Teilstationär, Begleitperson, etc. welche teilweise in HL7 v2 und in den deutschen PAM Nachrichtenprofilen definiert sind. Hat jemand eine Idee?
PS: Diese Frage habe ich schon im Implementer Stream unter „Encounter.classes“ gestellt, wurde aber noch nicht gelöst.
Patrick Werner (Sep 15 2016 at 16:05):
da status ein code ist, und die Kardinalität 1:1 besitzt können wir nicht einfach einen zweiten detailierteren code durch ein profile adden, es bleibt so nur eine Extension. Ich denke nicht, dass es sinnvoll wäre auf 1:* umzustellen, da man einen eindeutigen status haben möchte. Das binding des codes ist required, kann also auch nicht durch ein profil verändert werden.
Ich fände eine profilierte Extension hier nicht mal so schlecht. Vor-,Teil- und nachstationär sind eine erweiterung der eigentlichen codes. Es kann einen vorstationäre encounter geben der planned | arrived | in-progress | onleave | finished | cancelled ist.
Patrick Werner (Sep 15 2016 at 16:07):
während ich das schrieb fiel mir auf, dass Vorstationär, Nachstationär, Teilstationär eigentlich nicht in status gehören, sondern in Encounter.type.
Encounter.type
Definition
Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation).
Simone Heckmann (Sep 15 2016 at 18:05):
Das Encounter.class-ValueSet ist "extensible". Wenn uns etwas fehlt, können wir das Set also ohne Probleme erweitern. Encounter.type hat sogar nur ein "example" binding. Dort können wir also nicht nur fehlende Codes hinzufügen, sondern auch ein komplett eigenes ValueSet definieren.
Simone Heckmann (Sep 15 2016 at 18:13):
Da es sich bei den ValueSet "ActEncounterCode", das für Encounter.class verwedet wird, um ein V3-Set handelt, könnte ich mir vorstellen, dass die Frage, welche Codes hier für Deutschland fehlen, bereits von einer V3-Arbeitsgruppe gelöst wurde. @dr Kai U. Heitmann @Mathias Aschhoff ??
http://hl7-fhir.github.io/encounter-definitions.html#Encounter.class
http://hl7-fhir.github.io/v3/ActEncounterCode/vs.html
Encounter.type erscheint mir für die Fallart zu speziell.
Simone Heckmann (Sep 15 2016 at 18:15):
In unserem Wiki finde ich aber auch nur das Original-Set: http://wiki.hl7.de/index.php?title=2.16.840.1.113883.1.11.13955
Patrick Werner (Sep 15 2016 at 18:19):
wie kam ich da vorher aus status. Ja class finde ich auch passender als type. Die Trennung des Scopes zwischen class und type finde ich etwas schwierig. Vor allem wenn man sich mögliche logische Abhängigkeiten überlegt. Schön, dass die STU3Encounte.class als extensible definiert.
Simone Heckmann (Sep 15 2016 at 18:24):
Ist das die finale Liste der Codes, die gemäß PAM (DE) gebraucht werden?
http://wiki.hl7.de/index.php?title=Segment_PV1#Tabelle_0004:_Patient_Class
Simone Heckmann (Sep 15 2016 at 19:14):
Hier mal ein Schnellschuss für "unser" ValueSet: https://www.simplifier.net/ui/Publication/Show?projectkey=FHIRABENDSandbox&pubUrlKey=encounter-class
Simone Heckmann (Sep 15 2016 at 19:19):
Unser Encounter-Profil hätte dann ein "required binding" an dieses ValueSet.
Thorsten Conrad (Sep 16 2016 at 07:13):
Danke.
Ja, es dreht sich um die Tabelle 0004 (http://wiki.hl7.de/index.php?title=Segment_PV1#PV1-2_Patientenstatus).
An STU3 habe ich gar nicht gedacht Dort ist es tatsächlich extensible. Dann macht es Sinn, ein eigenes ValueSet
zu definieren und per Profile darauf zu verweisen.
Ich bin mir nur nicht sicher, ob sich alle KIS Hersteller an diese Codes halten, dann müsste man Projektspezifisch
dieses ValueSet erweitern.
Thorsten Conrad (Sep 16 2016 at 07:14):
Hier noch einmal die Übersicht:
Thorsten Conrad (Sep 16 2016 at 07:14):
Vorhandene Codes:
O AMB ambulatory
E EMER emergency
- FLD field
- HH home health
I IMP inpatient
- ACUTE inpatient acute
- NONAC inpatient non-acute
P PRENC pre-admission
- SS short stay
- VR virtual
Fehlende Codes:
R - recurring
V - vorstationär
NS - nachstationär
TS - teilstationäre Behandlung
TK - tagesklinische Behandlung
H - Begleitperson
U - Unknown
N - Not Applicable
Stefan Lang (Sep 16 2016 at 08:22):
Angesichts der "Flexibilität" mit der in v2 einiges gehandhabt wird, denke ich auch, wir sollten es im deutschen Basisprofil extensible setzen.
Natürlich mit dem Hinweis, am besten an zentraler Stelle, dass extensible bedeutet "nur, wenn's wirklich sein muss"
Simone Heckmann (Sep 17 2016 at 19:53):
Streng genommen bedeutet "extensible", dass man nur dann neue Codes hinzufügen darf, wenn für das zu codierende Konzept kein passender Code existiert. Einfach einen abweichenden Code für etwas zu verwenden, was im ValueSet bereits enthalten ist, ist verboten. In diesem Fall sollte man - im Namen der Interoperabilität - besser mappen.
Stefan Lang (Sep 17 2016 at 20:01):
Joah, ich hatte bei dem "an zentraler Stelle" so ein bisschen im Hinterkopf, dass wir für die Implementierer eine Art Mini-Cookbook (oder meinetwegen FAQ) machen könnten, mit solchen Infos wie den do's and don'ts der Value Sets oder z.B. "wie gehe ich mit einem (deutschen) Basisprofil oder Use Case Profil um" usw., je nachdem, was uns im Lauf der Zeit so an Caveats auffällt.
Simone Heckmann (Sep 17 2016 at 20:04):
Guter Gedanke! Es gibt ja in FHIR die Idee der "ImplementationGuide" Resource, die sämtliche Profile, ValueSet, NamingSystems, Examples etc... mit erläuterndem Text zu einem hübschen Paket verpackt. Dort wäre das m.E. gut aufgehoben. Der ImplementationGuide-Editor ist bereits in der Mache!
Stefan Lang (Sep 17 2016 at 20:05):
Muss ich mir mal angucken.
Gibt's da ein Alpha-/(Betatester-Programm? ;-)
Simone Heckmann (Sep 17 2016 at 20:06):
Nein, bisher gibt's nur das Gerücht :)
Simone Heckmann (Sep 17 2016 at 21:08):
Korrektur: Das Beta-Tester-Programm läuft bereits!
https://simplifier.net/ui/campaign/BecomeBetaTester
Stefan Lang (Sep 20 2016 at 14:33):
thx :)
Mathias Aschhoff (Sep 26 2016 at 07:53):
Also es gibt ein ValueSet dazu in ART-DECOR
http://art-decor.org/decor/services/RetrieveValueSet?id=2.16.840.1.113883.1.11.13955&effectiveDate=&prefix=hl7chcda-&format=html&language=de-CH
Es ist ein Schweizer ValueSet. Das können wir natürlich auch in unseren Namensraum kopieren.
Jan Schuster (Sep 26 2016 at 20:06):
Ich fände es nicht gut einfach das Schweizerer Valueset für Deutschland zu kopieren . Im HL7-Wiki DE wurde bereits ein gutes inhaltliches Set dokumentiert. Aus meiner Sicht sollte das Set nur eine Sprache (vorzugsweise englisch) verwenden.
Stefan Lang (Sep 26 2016 at 21:29):
@Jan Schuster Da ich auf die Schnelle das Value Set auf wiki.hl7.de nicht finde: gibt's dazu einen Link?
@Mathias Aschhoff Grundsätzlich sollte ja ein ValueSet, das im WIki auftaucht, auch in Art-Decor zu finden sein.
Was spräche ansonsten gegen das Schweizer ValueSet?
Jan Schuster (Sep 27 2016 at 12:48):
Hallo, Patient Class Table 0004. OK, das ist kein ValueSet. Die Frage ist, ob man sich hier von der HL7-Table entfernen muss.
Stefan Lang (Sep 28 2016 at 05:50):
Ah, das hatte ich jetzt missverstanden, ich dachte, es gäbe da noch eine andere außer der Table 0004.
Der Punkt ist, dass das FHIR value set extensible ist (genauer gesagt: required + extensible). Insofern müssen wir die gebundenen Codes verwenden und können unsere Deutschland-spezifischen aus der deutschen Table 0004 dazu nehmen, was Simone ja oben schon getan hat.
Insofern passt das dann tatsächlich auch besser als das Schweizer Set.
Simone Heckmann (Sep 28 2016 at 06:14):
Nebenbei: das "Schweizer Set" ist doch komplett identisch mit dem FHIR-Set, oder kuck ich schief?
Stefan Lang (Sep 28 2016 at 10:29):
Gnah, ja. Manchmal sollte ich einfach erst den ersten Kaffee wirken lassen :D
Henrik Blau (Oct 05 2020 at 13:38):
Gibt es zu dieser Thematik ein erweitertes ValueSet? Ich konnte im IG Basisleitfaden für R4 keine Infos zu Encounter-Ressource finden. Vor Allem das Mapping von v2.x auf FHIR ist dadurch nicht möglich.
Alexander Zautke (Oct 22 2020 at 11:27):
Hallo @Henrik Blau, welche Fallarten werden hier verwendet? Wenn wir eine Liste bekommen könnten, würden wir versuchen ein entsprechendes FHIR Mapping bereitzustellen.
Simone Heckmann (Oct 23 2020 at 13:22):
Ich fürchte, dass es hier in der Vergangenheit nie zu einer deutschlandweiten Harmonisierung gekommen ist. Ich erinnere mich aus V2-Zeiten, sowohl S als auch I für stationär, O als auch A für ambulant gesehen zu haben und div. weitere Kürzel für teilstätionär, Tagesklinik etc.
Nebenbei betrachtet wäre aber natürlich ein präzises Mapping von V2-PV1 auf MI-I-Encounter von großem Mehrwert...
Simone Heckmann (Oct 23 2020 at 13:34):
Hier sind zumindest mal ein paar relevante Pragrafen aufgeführt: https://reimbursement.institute/blog/stationaer-teilstationaer-oder-ambulant/
René Spronk (Oct 23 2020 at 13:56):
The German v2 spec does contain a list of values, as usual based on the universal code table with added codes for German specific fall types such as Vorstationäre Behandlung.
Mareike Przysucha (Oct 23 2020 at 14:09):
@Frank Oemig ?
Thomas Freier (Oct 26 2020 at 17:52):
https://wiki.hl7.de/index.php?title=Segment_PV1 In der Praxis sehe ich meist von den versch. KIS Anbietern: die Werte: R(Nur Nuklearmedizin) E O P I U. Etwa 20% liefern Werte die nicht der Tabelle 04 entsprechen und dann von uns im System gemappt werden müssen. Eine klare Definition in FHIR wäre super.
Frank Oemig (Oct 27 2020 at 09:26):
http://www.hl7.eu/HL7v2x/v24de/hl7v24detab0004.htm
Mareike Przysucha (Oct 27 2020 at 09:26):
danke sehr @Frank Oemig
Frank Oemig (Oct 27 2020 at 09:27):
Das sind jetzt keine "Fallarten", sondern "Patientenstatus".
Frank Oemig (Oct 27 2020 at 09:28):
Das erinnert mich wieder daran, dass man mal genauer beschreiben muss, was man eigentlich meint.
Last updated: Apr 12 2022 at 19:14 UTC
