Stream: german (d-a-ch)
Topic: MI-I-Kerndatensatz
Kutaiba Saleh (Mar 12 2018 at 10:22):
Hallo zusammen,
wie schon im Rahmen des Interop-Forums besprochen füge ich unter diesem Link (https://docs.google.com/spreadsheets/d/1SGiSNUL4Y4y_jcr7By2lskDRqPH27BmOEPAFblZedSA/edit?usp=sharing) eine Mapping-Tabelle ausgewählter P21-Datensatz-Items (hier der Link auf dessen Spezifikation: http://www.g-drg.de/Datenlieferung_gem._21_KHEntgG/Dokumente_zur_Datenlieferung/Datensatzbeschreibung) ins FHIR als ersten Vorschlag für eine weitere Diskussion bei, wie mit der Abbildung in FHIR zu verfahren ist. Diese Tabelle ist eine erste Sammlung möglicher Abbildungen auf Ressourcen, welche die Elemente des MI-I-Kerndatensatzes enthalten würden. Wir wollen ja die Daten weitestgehend als bestehende Ressourcen abbilden und als eventuell nötige neue Attribute etc. dann als Erweiterungen im Basisprofil-DE definieren. Als Erstes ist die Frage, passen die ausgewählten Ressourcen so auf die genannten P21-Items?
Stefan Lang (Mar 12 2018 at 13:23):
Auf den ersten Blick sehe ich da noch Ungereimtheiten. Eine Diagnose z.B. entspricht grundsätzlich einer Condition. Zu den administrativen/FM-Ressourcen kann wahrscheinlich @Simone Heckmann mehr sagen.
Generell noch einmal zum Begriff "identifier", da hier wohl ein systematischer Irrtum vorliegt. Identifier meint unique Business Identifier ("A numeric or alphanumeric string that is associated with a single object or entity within a given system.")
In der Tabelle werden aber Kategorisierungs- bzw. Versionierunginformationen dorthin gemappt.
Grundsätzlich hatten wir ja abgestimmt, dass wir die besagten Datenelemente in den Basisprofilen abbildbar machen. Ich denke, es macht Sinn, wenn wir uns hierzu auch im Rahmen der Basisprofil-Weiterentwicklung erstmal Gedanken machen.
Simone Heckmann (Mar 12 2018 at 21:36):
Bezüglich "Institutionskennzeichen des verlegenden Krankenhauses -Fall.CSV.30": Ich habe in vorauseilendem Gehorsam schon einen ChangeRequest für R4 eingereicht, dass Encounter.hospitalization.origin alternativ auch auf Organization verweisen können muss (statt nur Location). Der Antrag ist bereits angenommen worden und die Änderungen sind für R4 durchgeführt (siehe GF#15021).
Da im Kerndatensatz jedoch die Angabe des Identifiers (IK-Nummer) ausreichend ist, würde ich hier ohnehin die Verwendung einer Logical Reference (http://build.fhir.org/references.html#logical) empfehlen. Anstatt einer Referenz auf eine Organization-Resource würde also nur der Identifier angegeben. Damit sollte die Umsetzung auch in STU3 unproblematisch sein.
Simone Heckmann (Mar 12 2018 at 22:29):
Entgelte = ChargeItems?
Christof Gessner (Mar 13 2018 at 07:43):
Hi Simone, siehst Du die logical reference als Ergänzung/Workaround für literal references- oder ersetzend? In diesem Fall, und auch allgemein? Könnten wir mal ein “Designprinzip” für solche Fälle schreiben?
Simone Heckmann (Mar 13 2018 at 08:02):
Logical References sind aus meiner Sicht überall dort sinnvoll, wo die Nennung eines (nationalen) Identifiers ausreicht, um ein Objekt für alle an der Kommunikation beteiligten ausreichend zu beschreiben. Es obliegt den empfangenden Systemen, diese logische Referenz dann durch einen "echten" Link auf die diesem Identifier entsprechenden Ressource zu ersetzen, oder die logische Referenz beizubehalten.
Wenn über ein Objekt nichts als der Identifier bekannt ist (IK-Nr. für Organisation, LANR für Practitioner), wäre es Overkill, dafür eine separate Ressource anzulegen, in der nur dieses eine Attribut gefüllt ist. Ob logische Referenzen in einem Use Case erlaubt sind, sollte im jeweiligen Profil festgelegt werden.
Simone Heckmann (Mar 13 2018 at 08:05):
Noch sinnvoller wäre die Verwendung von LRs natürlich überall dort, wo nationale Registries im Einsatz sind, also die Details einer Organisation oder eines Practitioners anhand des nationalen Identifiers in einer Registry nachgeschlagen werden können. Dann macht es überhaupt keinen Sinn mehr, diese Details bei jeder Kommunikation auszutauschen. Aber soweit sind wir halt in Deutschland leider noch nicht...
Christof Gessner (Mar 13 2018 at 08:13):
Ist letzteres aber nicht exakt der Use Case für Literal References, die Resource wird darüber per FHIR von der Registry abgeholt? Und: auch bei Verwendung logischer Referenzen muss die Resource (z. B im Bundle) bereitgestellt werden. Oder sprichst Du von Ersetzung der Reference durch einen Identifier? Das ist m. E. dann aber was anderes als eine logical reference.
Christof Gessner (Mar 13 2018 at 08:21):
vgl z B MedicationRequest.medication, auch wenn es hier um CodeableConcept statt Identifier geht.
Patrick Werner (Mar 13 2018 at 08:43):
Logical Reference (https://www.hl7.org/fhir/references.html#logical):
<patient> <identifier> <system value="http://hl7.org/fhir/sid/us-ssn" /> <value value="000111111" /> </identifier> </patient>
Das ist im Endeffekt ja dem der CodeableConcept Referenz sehr ähnlich, benutzt ein system und den value
Patrick Werner (Mar 13 2018 at 08:50):
Bei einer Registry will ich ja über den bekannten identifizierenden value die Organization holen, dies ist der Identifier. Die ID der literal Reference ist mir ja erstmal nicht bekannt. Man könnte natürlich den Auskunftsdienst so bereitstellen, dass die Organization unter /Organization/<IK_NUMMER> erreichbar wäre - aber das ist momentan nicht der präferierte Weg (soweit ich das überblicke). Das Argument hier ist immer, dass die ID vom Server vergeben wird und sich somit bei Transfers von Server zu Server ändern wird. Der Identifier bleibt hingegen bekannt.
Patrick Werner (Mar 13 2018 at 08:51):
Wenn man auf ein Registry verlinkt fände ich <Registry_URL>/RessourceName/Identifier aber auch gar nicht mal so unelegant
Simone Heckmann (Mar 13 2018 at 08:56):
"auch bei Verwendung logischer Referenzen muss die Resource (z. B im Bundle) bereitgestellt werden"
Nein, wieso?
"Mvgl z B MedicationRequest.medication, auch wenn es hier um CodeableConcept statt Identifier geht." Hier besteht ja im MPP genau die Situation, dass mehr Infos zu dem Medikament erfasst werden, als nur die PZN, z.B. auch die Darreichungsform.
Und das es kein "offizielles Deutsches Medikamentenverzeichnis" gibt, in dem man dies bei Bedarf anhand der PZN nachschlagen könnte, muss das halt in jedem MPP enthalten sein...
Christof Gessner (Mar 13 2018 at 09:32):
Wir sprechen vielleicht nicht über die gleiche Sache hier? Es gibt einerseits Resourcen, in denen Reference als Alternative in einer Choice auftaucht (Questionnaire.item.initial[x], ConceptMap.source[x], MedicationStatement.medication[x] etc. ), oder nicht als Choice sondern nebeneinander, wie in DocumentReference.context.related. Andererseits bietet der Datentyp Reference selbst zwei Varianten, eine Resource zu bezeichnen: literal und logical reference. Dabei scheint mir hier die Art der Referenzierung aber keinen Einfluss auf die Anforderungen an die referenzierte Ressource zu haben, sind eben bloß zwei unterschiedliche Arten, diese zu bezeichnen.
Stefan Lang (Mar 13 2018 at 09:46):
Ich denke, dass hier weitgehend Konsens besteht: es geht um die Varianten innerhalb des Reference-Datentyps.
Zu Logical References vgl. http://hl7.org/fhir/references.html#logical : "
In many contexts where FHIR is used, applications building a resource may know an identifier for the target of the reference, but there is no way for the application to convert this to a literal reference that directly references an actual resource. This situation may arise for several reasons:
- There is no server exposing any such resource. This is often the case with national identifiers (e.g. US SSN or NPI), and such identifiers are widely used
- The server that exposes the resource is not available to the source application, so it has no way to resolve an identifier to a reference
- The application is not in a RESTful environment - it is creating a message or a document
"
Das beschreibt Use Cases, in denen es z.T. per se unmöglich ist, eine Ressource zum logisch referenzierten Target zu haben bzw. zu kennen. Dann kann man natürlich außer der logischen Referenz (=> dem referenzierten Identifier) auch nichts in ein Bundle bringen.
Stefan Lang (Mar 13 2018 at 09:48):
Klassisches Beispiel:
(Fast) jedes System in D kennt intern eine Liste der KVen mit IK, Name, Adresse usw.
Es reicht aber in der Regel völlig, hier die IK zu übermitteln => logical reference
Christof Gessner (Mar 13 2018 at 10:01):
Wenn ich weiß, dass ich nur den Identifier (oder den Code) brauche, und niemals eine literale Referenz, dann brauche ich an der Stelle auch keinen Datentyp Reference nehmen. Oder ?
Stefan Lang (Mar 13 2018 at 10:03):
Wenn es ein Code ist, ist der Datentyp ja CodeableConcept.
Um eine Referenz per Identifier (also die logische Referenz) auszudrücken, ist aber genau der Reference-Datentyp vorgesehen.
Simone Heckmann (Mar 13 2018 at 10:03):
Dier Option "logical reference" wurde kurz vor STU3 eingeführt. Daher haben viele Ressourcen immer noch value[x]-Attribute mit (Reference|Identifier). Diese sollten in R4 jedoch alle auf den Datentyp Reference konsolidiert werden, da die choice damit redundant ist.
Christof Gessner (Mar 13 2018 at 10:15):
Danke sehr, Simone, das beantwortet meine Frage abschließend!
Und welche Resourcen in das Bundle müssen, ist für eine Composition genau spezifiziert (siehe 2.41.2 in https://www.hl7.org/fhir/composition.html ). Dazu gehören u. a. auch Composition.custodian und Composition.encounter. Heißt also: auch wenn nur BSNR oder IK-Nr. bekannt, muss die Resource Custodian ins Körbchen.
Patrick Werner (Mar 13 2018 at 10:21):
Ja, bei einer Composition muss diese SHALL Liste als resource mit ins Bundle sofern diese aus Composition heraus Referenziert werden.
Patrick Werner (Mar 13 2018 at 10:23):
Was ich persönlich für nicht optimal erachte, im falle einer Logical Reference sollte das SHALL keinen Bestand haben.
Sollen wir ein Tracker Item erstellen? Oder wurde das schonmal diskutiert?
Es gibt kein TrackerItem und es wurde noch nicht explizit in diesem Kontext auf Zulip diskutiert, ich erstelle mal...
Patrick Werner (Mar 13 2018 at 10:41):
Kutaiba Saleh (Mar 14 2018 at 15:42):
Auf den ersten Blick sehe ich da noch Ungereimtheiten. Eine Diagnose z.B. entspricht grundsätzlich einer Condition. Zu den administrativen/FM-Ressourcen kann wahrscheinlich @Simone Heckmann mehr sagen.
Generell noch einmal zum Begriff "identifier", da hier wohl ein systematischer Irrtum vorliegt. Identifier meint unique Business Identifier ("A numeric or alphanumeric string that is associated with a single object or entity within a given system.")
In der Tabelle werden aber Kategorisierungs- bzw. Versionierunginformationen dorthin gemappt.Grundsätzlich hatten wir ja abgestimmt, dass wir die besagten Datenelemente in den Basisprofilen abbildbar machen. Ich denke, es macht Sinn, wenn wir uns hierzu auch im Rahmen der Basisprofil-Weiterentwicklung erstmal Gedanken machen.
Danke sehr für die Informationen. Ich pflege eure Hinweise in die Tabelle ein.(auch IKs )
Wir haben dabei auch ermittelt, dass clinicalStatus und verificationStatus für die Abbildung der Diagnosesicherheit im ICD-10 nicht geeignet sind. clinicalStatus bezeichnet den Status einer Erkrankung und verificationStatus den Status einer Diagnose. Die Sicherheit einer Diagnose (Verdacht, ausgeschlossen, gesichert, symptomlos) ist jedoch inhaltlich nochmal etwas anderes. Ggf. gibt es diese Konzepte aber auch bereits im HL7 RIM und es wäre ein erweiterndes Attribut hier noch hilfreich?
Patrick Werner (Mar 14 2018 at 16:27):
Wie die Notation von ICD10-GM in FHIR erfolgen soll wird gerade von @Stefan Lang und @Julian Sass geklärt. Ich bin aber vorsichtig pessimistisch ob die Zusatzkennzeichen L,R,B sowie die Diagnosesicherheit als postkoordinierter ICD10-GM Code "erlaubt" werden.
Patrick Werner (Mar 14 2018 at 16:29):
da laut: https://chat.fhir.org/#narrow/stream/german.20(d-a-ch)/subject/ICD-10/near/132320 ohnehin die Information zusätzlich als Extension enthalten sein sollte wäre die Abbildung über Extensions sinnvoll.
Patrick Werner (Mar 14 2018 at 16:32):
related hierzu: https://fhirblog.com/2017/01/10/extending-a-required-valueset-binding/
Stefan Lang (Mar 14 2018 at 16:51):
Die Seitenlokalisation (also L, R,B) hatten wir vor Längerem als Condition.bodySite angedacht.
Ich bin mir aber nicht sicher, ob das so ideal wäre. Wahrscheinlich würde man dort eher einen separaten Lokalisations-Code erwarten, also z.B. ICD-O-3-Topographie-Codes oder dergleichen.
Ansonsen wäre das dann tatsächlich eine Extension. Ich bin hier aber extrem offen für Meinungen und Feedback.
Stefan Lang (Mar 14 2018 at 17:10):
@Kutaiba Saleh Es erscheint mir durchaus möglich, die Diagnosesicherung auf clinicalStatus und verificationStatus zu mappen.
cStatus und vStatus bezeichnen Statusinformationen der Condition, zu deutsch; Gesundheitsstatus/Erkrankung, ausgedrückt durch eine ICD-10-codierte Diagnose.
Was spricht gegen:
Verdacht <==> cS "active", vS "provisional"
ausgeschlossen <==> cS "active", vS "refuted"
gesichert <==> cS "active", vS "confirmed"
(symptomloser) Zustand nach <==> cS "inactive" [Edit: oder "resolved"]
Man muss diese beiden Status-Informationen sogar entsprechend füllen, da sie Modifier sind - eine ausgeschlossene Diagnose ist ja die Negation einer gesicherten. Ein System, das gerade keine deutschen Profile kennt, muss in der Lage sein, das aus den "offiziellen" FHIR Elementen abzuleiten.
Es erscheint mir allerdings sinnvoll, hier dennoch eine Extension zu haben, die die in ICD-10-GM üblichen Codes dazu enthält. Das ist dann zwar inhaltlich redundant, aber sicher praxis-orientierter.
Stefan Lang (Mar 14 2018 at 17:15):
(Genau genommen ist es ICD-10, wo die semantischen Konzepte von clinicalStatus und verificationStatus in die Diagnosesicherungscodes gemischt sind)
Evelyn Dröge (Mar 16 2018 at 12:57):
Wir beschäftigen uns gerade auch mit Diagnosen. Condition.verificationStatus hatten wir auch für die Diagnosesicherheit angedacht.
Bei der Lokalisation denken wir auch über die Verwendung von Condition.bodySite nach. Da würde man ja dann nur ein CodeSystem für L, R und B benötigen - oder was waren eure Gedanken dazu, @Stefan Lang ? Ein bisschen merkwürdig bei bodySite ist allerdings schon, dass L, R und B ja nicht sehr spezifisch sind und man bodySite beispielsweise auch für Zahnnummern verwendet. Dadurch ist die Verwendung schon sehr unterschiedlich. Bei der Extension besteht dann nur wieder die Gefahr, dass sie niemand versteht. Ich bin da noch unentschlossen, welche der Alternativen besser ist.
Zusätzlich wollen wir auch noch aussagen können, ob es sich um eine Haupt- oder Nebendiagnose handelt. Das macht man dem Basisprofil nach via category, richtig?
Simone Heckmann (Mar 16 2018 at 13:09):
bodySite ist 0..* daher können wir slicen und fordern, dass immer mindestens eine gültige R/L/B-Angabe gemacht werden muss, man aber zusätzlich auch noch differenziertere Angaben machen kann...
Haupt/Nebendiagnose sehe ich eher in Encounter.diagnosis.role, da das ja eine Eigenschaft bezogen auf einen Fall ist, nicht direkt eine Eigenschaft der Diagnose.
Simone Heckmann (Mar 16 2018 at 13:10):
...das ValueSet müssen wir für DE aber noch zurechtfönen...
Simone Heckmann (Mar 16 2018 at 13:12):
Moment, ist Haupt/Nebendiagnose das gleiche wie Primär/Sekundärdiagnose...? Dann wäre es Encounter.diagnosis.rank!
Simone Heckmann (Mar 16 2018 at 13:13):
Laut den Beispielen wäre Hauptdiagnose ("Principal Diagnosis") so darzustellen:
<!-- Example of a principal diagnosis with role=CC and rank=1 --> <diagnosis> <condition> <display value="The patient is treated for a tumor"/> </condition> <role> <coding> <system value="http://hl7.org/fhir/diagnosis-role"/> <code value="CC"/> <display value="Chief complaint"/> </coding> </role> <rank value="1"/> </diagnosis>
Stefan Lang (Mar 16 2018 at 13:16):
Ein ValueSet bzw. Codesystem für L/R/B haben wir ja schon:
https://simplifier.net/BasisprofilDE/s-icd-seitenlokalisation-2
Simone Heckmann (Mar 16 2018 at 13:16):
"Zurechtfönen" bezog sich auf diagnosis-role
Stefan Lang (Mar 16 2018 at 13:17):
Verstanden :)
Ich bezog mich gerade auf Evelyns Frage oben ;)
Stefan Lang (Mar 16 2018 at 13:18):
bodySite slicen wäre eine Option.
Wobei natürlich ICD-O-3-Topo wiederum das angehängte L/R/B kennt ...
Stefan Lang (Mar 16 2018 at 13:21):
Ich persönlich wäre nicht böse darum, wenn wir die ganze Haupt/Neben/Primär/Sekundär/.... Zuordnung nicht in der Condition drin hätten.
Allein schon: was für die eine Abteilung die Hauptdiagnose ist, ist für die andere die Nebendiagnose.
Nur weil Patient X plötzlich Krebs hat, ist für die Nephrologie ja nicht plötzlich die Niereninsuffizienz eine Nebendiagnose.
Stefan Lang (Mar 16 2018 at 13:21):
Das ist also immer kontextabhängig
Stefan Lang (Mar 16 2018 at 13:27):
Auf jeden Fall habe ich mir vorgenommen, den aktuellen Diskussionsstand nächste Woche mal in das condition-de-basis-Profil einzubauen.
Dann hat man eine bessere Basis für weitere Diskussionen.
Stefan Lang (Mar 16 2018 at 13:29):
Zum Thema Lokalisation haben wir auch noch http://build.fhir.org/bodystructure.html
Dort gibt es z.B. so etwas wie locationQualifier ...
Stefan Lang (Mar 16 2018 at 13:31):
Leider kann man das nicht direkt mit Condition verknüpfen.
Ich halte dazu einen CR für sinnvoll. Meinungen?
Simone Heckmann (Mar 16 2018 at 13:35):
"for example it can be the target of a Procedure resource or Observation resource"
...ist es aber (noch) nicht. Die Ressource scheint noch sehr frisch zu sein...
Simone Heckmann (Mar 16 2018 at 13:36):
...was in Bezug auf Observation interessant ist, da Kandidat für Normative :P
Stefan Lang (Mar 16 2018 at 13:38):
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3600&start=0
Simone Heckmann (Mar 16 2018 at 13:38):
Ah! das wird über die Extension gemacht: http://build.fhir.org/extension-body-structure.html
Simone Heckmann (Mar 16 2018 at 13:38):
Die kann man natürlich überall benutzen, einschließlich Condition...
Stefan Lang (Mar 16 2018 at 13:39):
Hm, das widerspricht ein bisschen dem gerade verlinkten GF#3600
Simone Heckmann (Mar 16 2018 at 13:39):
...der ist von 2014 :)
Stefan Lang (Mar 16 2018 at 13:40):
Ja, aber trotz accepted motion wurde er nicht vollständig umgesetzt:
'
Motion for “straw vote for OO direction” for bodysite to be choice of codeableconcept|to-be-developed BodySite Resource
'
Stefan Lang (Mar 16 2018 at 13:40):
Condiiton.bodySite ist nach wie vor CodeableConcept only
Stefan Lang (Mar 16 2018 at 13:41):
Aber gut, wenn es eine Extension gibt, hat man sich wohl irgendwann anders entschieden
Simone Heckmann (Mar 16 2018 at 13:41):
vermutlich.
Stefan Lang (Mar 16 2018 at 13:41):
(BodySite wurde irgendwann 2017 nach BodyStructure umbenannt)
Evelyn Dröge (Mar 19 2018 at 10:28):
Moment, ist Haupt/Nebendiagnose das gleiche wie Primär/Sekundärdiagnose...? Dann wäre es Encounter.diagnosis.rank!
Das passt aus meiner Sicht. Es hätte da auch noch diese Extension gegeben, aber die passt nicht, weil ich dann nicht wüsste, wie ich den Link zu der speziellen Condition hinbekäme: http://hl7.org/fhir/extension-encounter-primarydiagnosis.html
Simone Heckmann (Mar 19 2018 at 10:29):
Die Extension haben wir in R4 entfernt, da es sich mit Encounter.diagnosis.rank abbilden lässt. Daher besser nicht verwenden!
Evelyn Dröge (Mar 19 2018 at 10:30):
Super, danke für den Hinweis!
Birger (Sep 06 2018 at 07:26):
Hallo an alle! Ich bin noch etwas erschlagen von der Struktur hier im Chat, daher hoffe ich, dass es OK ist, diese Frage im Kontext des MI-I Kerndatensatzes zu stellen. Wir wollen uns bei der Modellierung in openEHR bei der Referenzierung von Terminologien an FHIR halten (warum das Rad neu erfinden). Allerdings habe ich im Simplifier keinen URI für OPS finden können. Habt Ihr da schon was überlegt und ich habe es übersehen, oder ist das tatsächlich noch nicht definiert? Besten Dank!
Simone Heckmann (Sep 06 2018 at 07:34):
Wir hatten mal das ValueSet definiert: https://simplifier.net/basisprofilde/ops
Simone Heckmann (Sep 06 2018 at 07:35):
...aber das expanded nicht, da es a) aktuell keinen Terminologie-Server gibt, der OPS mit FHIR-API hostet und b) die von uns gewählte Schreibweise
'Include all codes defined in http://fhir.de/CodeSystem/dimdi/ops|*' nicht ganz legitim ist :angel:
Simone Heckmann (Sep 06 2018 at 07:37):
Wir hatten dazu einen Change Request eingereicht, da es im Standard keine Möglichkeit gab, ein ValueSet zu definieren, das alle Versionen eines CodeSystems enthält. Das war uns aber wichtig, da wir die Profile und die Terminologie-Bindings nicht jedes Jahr ändern wollen, wenn ein neuer ICD/OPS-Katalog erscheint.
Simone Heckmann (Sep 06 2018 at 07:38):
Unserem CR wurde stattgegeben, allerdings nicht in der ...|* -Notation, sondern es wurde definiert, dass ein Include ohne Angabe einer expliziten Version stets bedeutet "include all"
Simone Heckmann (Sep 06 2018 at 07:39):
...daher müssten wir das in unserem Profil entsprechend anpassen, wenn die R4-Spezifikation raus ist...
Birger (Sep 06 2018 at 07:40):
OK, das entspricht ja dem üblichen Vorgehen. Das heißt also, dass wir "http://fhir.de/CodeSystem/dimdi/ops" verwenden sollten, right?
Simone Heckmann (Sep 06 2018 at 07:47):
Genau. Da beim OPS immer die Version mit angegeben werden muss, würde das in einer FHIR.Instanz dann ungefähr so aussehen:
<coding> <system value="http://fhir.de/CodeSystem/dimdi/ops"/> <version value="2018"/> <code value="1-2345"/> </coding>
Simone Heckmann (Sep 06 2018 at 07:48):
BTW, Willkommen im Chat :smiley:
Birger (Sep 06 2018 at 07:52):
Super, ist bei openEHR das gleiche. Daher auch gerne zukünftig die Trennung nach Benennung und Version beibehalten :) Und Dankeschön, war leider zwischenzeitlich zwischen Urlaub und Ausschreibungen versumpft. Aber jetzt geht das hoffentlich mal fachlich weiter :simple_smile:
Patrick Werner (Sep 20 2018 at 15:09):
Ich bin mir nicht sicher ob hier diejenigen mitlesen die auf dem InteropForum danach fragten, falls nicht bitte ggfs. weiterleiten.
Es wurde nach Tooling für CodeSystem Mappings gefragt. Ich persönlich benutze hierzu (FHIR) ConceptMaps und hapi-fhir-cli und einen HAPI Server.
ConceptMaps lassen sich durch hapi-fhir-cli aus einem CSV File generieren, das Umwandeln des konkreten Codes kann dann der HAPI Server (oder jeder andere Server welche die operation unterstützt).
Die Operation ist hier die $translate Operation des ConceptMap Endpunktes: https://www.hl7.org/fhir/conceptmap-operations.html
Christof Gessner (Sep 23 2018 at 20:27):
Damit das zielführend wird, braucht es wahrscheinlich eine allgemein akzeptierte Definition von “Version” und “Release”. Während meines Wissens für die deutschen Ausgaben vo ICD und OPS jährlich neue codeSystem OIDs (bzw. URL) vergeben werden, bleibt die ID von SNOMED CT und LOINC konstant, so dass ggf. (wann??) die Übermittlung der version sinnvoll/unerlässlich sein könnte.
Christof Gessner (Sep 23 2018 at 20:30):
Frage ist dann, wie mit Nachrichten umgegangen wird, die _keine_ Versionsangabe mitbringen. Ablehnen? Wir haben die Diskussion auch bei eHDSI für die europäischen Value Sets. Wird das version-attribute Pflicht? Und brauchen wir dann noch jährlich neue OIDs für ICD-GM?
Stefan Lang (Sep 24 2018 at 07:25):
Für ICD-10-GM und OPS bilden wir das jährliche "neue" Codesystem bereits durch die Kombination URL + Version ab. Das hat vor allem den praktischen Grund, dass anderenfalls jedes Jahr das zugehörige ValueSet "alle Codes aus allen Jahren" upgedated werden müsste, weil eine neue URL dazu kommt. Ab FHIR R4 ist in einem ValueSet dann "CodeSystem URL ohne Version" gleichbedeutend mit "alle Versionen eines CodeSystems".
Wir hatten das vor längerem recherchiert und in diversen Kreisen ja auch diskutiert, mit dem Ergebnis, dass für ICD-10-GM und OPS keine Unterversionen (also unterjährige neue Versionen ohne neue OID) existieren, bzw. zumindest nicht als solche benannt werden.
Last updated: Apr 12 2022 at 19:14 UTC
