Stream: german/mi-initiative
Topic: MII Laborprofile
Simone Heckmann (Apr 04 2019 at 09:41):
Hallo,
hat jemand einen aktuellen Stand / Link was das Thema "Laborprofile" anbelangt?
Danny Ammon (Apr 04 2019 at 09:44):
Hi, es gibt bislang nur die Arbeiten im ART-DECOR. Im Team für die Laborprofile hatten wir uns bislang Beispiele für FHIR-Ressourcen aus einzelnen Uniklinika erarbeitet und angeschaut, die eigentliche Profilierung liegt noch vor uns. Hier wird es am 18.4. einen ersten Vor-Ort-Termin in München geben! @Alexander Zautke ist hier auch eingebunden. Wir können / sollten dann auf alle Fälle hier informieren, wie es weitergeht!
Simone Heckmann (Apr 04 2019 at 09:51):
Danke Danny! Wir haben eine Einladung für den Termin in München erhalten, aber das war leider zu kurzfristig, als dass Stefan oder ich hätten teilnehmen können. Wäre schön, wenn ihr uns (und den lauernden Rest der Welt) hier auf dem Laufenden halten könntet! :)
Stefan Lang (Apr 04 2019 at 09:52):
Ja, bitte!
Christof Gessner (Apr 04 2019 at 10:01):
Wegen den Empfehlungen der europ. Kommission zum “Thema EHR Exchange Format” (auch für Labordaten) möchte ich auch gerne auf dem Laufenden bleiben.
Danny Ammon (Apr 04 2019 at 10:16):
Wahrscheinlich wird es wohl eher darauf hinauslaufen, dass wir in einem Folgetermin nochmal auf euer aller Expertise zurückgreifen :D, aber klar, ich werde berichten! Im ersten Schritt wurden / werden übrigens EPD- und elga-Laborbefund-Templates reviewt, also das Anlehnen an bestehende Leitfäden ist definitiv ein Ziel! Es bleibt natürlich trotzdem bei der Profilierung in FHIR…
Alexander Zautke (Apr 04 2019 at 10:38):
@Christof Gessner Hast du vielleicht ein paar Links parat in Hinblick darauf was alles zu beachten wäre? Dann könnte man ja von Anfang an eine Harmonisierung anstreben.
Simone Heckmann (Apr 04 2019 at 11:00):
Ich lege das Labor-(Observation)-Profil aus dem International Patient Summary mal hier hin: https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Observation-laboratory-uv-ips.html
Andreas Bietenbeck (Apr 09 2019 at 07:39):
Vielen Dank für den informativen Link. In Simplifier finde ich dazu noch nichts, oder? Mich würde auch der DiagnosticReport interessieren. Dann habe ich noch eine Frage zu der Gruppierung von Analysen. In FHIR 4 wird dazu Observation.Component verwendet, in IPS Observation.hasMember. Gibt es einen Grund für diesen Unterschied? Ist irgendwo festgelegt, welche Analyse ich unter welchem Panel zu erwarten habe? Der Kommentar zu https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Observation-laboratory-uv-ips-definitions.html#Observation.hasMember liesst sich so, als könnte diese Zuodnung fast beliebig ausfallen (...group a collection of observations, [...], or because they share a common interpretation comment ...) . Spricht für den reinen Datenaustausch etwas dagegen, alle Analysen erst einmal ungruppiert abzulegen?
Danny Ammon (Apr 26 2019 at 08:49):
Hi zusammen, ganz kurzes Feedback vom Treffen in München: Wir haben uns für die Laborbefunde der MI-Initiative auf folgende Dinge geeinigt:
– Profilierung in FHIR R4 (sobald Forge / Simplifier es unterstützen)
– Ableitung der MII-Laborbefund-Profile aus den Profilen des International Patient Summary
– Profile für die Ressourcen DiagnosticReport, Observation, ServiceRequest und Speciment werden erstellt
– einige übergreifende Punkte, z.B. Canonical URL für Profile etc. wurden besprochen und Vorschläge dafür erstellt
Erste Details dazu, was wir an den Ressourcen profilieren würden, haben wir dokumentiert und würden wir, sobald es dann technisch unterstützt wird, gern auch auf dem nächsten dann folgenden Interop-Forum vorstellen!
Andreas Bietenbeck (Jul 16 2019 at 15:58):
Wir haben uns gerade hier in München getroffen um weiter an den Laborprofilen für die MII zu arbeiten. Das Ergebnis ist jetzt unter https://simplifier.net/MedizininformatikInitiative-Laborprofile einsehbar. Natürlich ist noch nichts davon offiziell aber wir freuen uns trotzdem schon über Rückmeldung.
Patrick Werner (Jul 16 2019 at 16:10):
in Observation.category habt ihr einerseits ein Slice welches fixed values aus LOINC enthält + fixed values auf category direkt.
Patrick Werner (Jul 16 2019 at 16:16):
Dies widerspricht sich, lässt sich aber leicht durch Entfernen des slices lösen. Das es eine Laboruntersuchung ist sieht man bereits am value aus http://terminology.hl7.org/CodeSystem/observation-category
Patrick Werner (Jul 16 2019 at 16:18):
bei der DiagOrder.category würde ich auch das preferred ValueSet dem LOINC term vorziehen.
Andreas Bietenbeck (Jul 16 2019 at 16:18):
Danke, ich überprüfe das (Observation.category slices) mal. Wir haben über diesen Punkt länger diskutiert, Ziel war jeder Observation die category 'Labor' (aus LOINC) zuzuordenen, zusätzlcih aber noch weitere Categorien zu erlauben.
Patrick Werner (Jul 16 2019 at 16:20):
Das ist nachvollziehbar. Wenn man die codes aus http://terminology.hl7.org/CodeSystem/observation-category nutzt ist man sehr wahrscheinlich international interoperabel.
Patrick Werner (Jul 16 2019 at 16:21):
Und die Zuordnung, dass eine Observation eine Laboruntersuchung ist kann ich ja mit dem hl7 codesystem gleichwertig ausdrücken.
Andreas Bietenbeck (Jul 16 2019 at 16:26):
Mir fehlt da der Überblick was international besser kompatibel ist. Wenn HL7 besser ist, dann gerne auch das, ihc bin da völlig schmerzfrei und stelle das gerne zur Diskussion.
Alexander Kiel (Jul 16 2019 at 17:18):
In Observation.valueQuantity wollt ihr unit nutzen. Habt ihr überlegt präziser system + code zu benutzen? Observation.valueQuantity habt ihr auf 1:1. Sollte dies nicht auf 0:1 bleiben? Wenn ich den dataAbsentReason benutze, kann ich kein value angeben. Über interpretation könnte man auch noch nachdenken, wie es hier verwendet wird. Wollt ihr am Ende eine Observation pro Laborwert herstellen oder eine für alle Laborwerte nehmen?
Christof Gessner (Jul 16 2019 at 17:33):
Vielleicht ist es so vielseitiger. Denn: Von diesem Profil wäre dann ein weiteres Profil als constraint ableitbar, in dem die Unit garantiert auch codiert ist. Oder sogar: in UCUM codiert ist. Das a priori verpflichtend zu machen, könnte das Profil hingegen für einige Zwecke unbrauchbar machen.
Alexander Zautke (Jul 16 2019 at 17:40):
Bezüglich Observation.category / DiagnosticReport.category: Diese LOINC Codes wurden bewusst gewählt, da sie von unseren lieben Nachbarn in Österreich in ihren Laborbefunden verwendet werden. Wir hatten leider nicht darauf geachtet, dass im Core das ein preferred Binding ist. Ich denke es würde jedoch wenig dagegensprechen dies als weiteres Coding mit aufzunehmen. Das fixed value ist noch ein Fehler aus alten Versionen. Generell war es jedoch schon angedacht für Auswertungszwecke nur eine Catgeory d.h. ein CodeableConcept mit n Codings zuzulassen.
Alexander Zautke (Jul 16 2019 at 17:43):
Die dataAbesentReason wird noch auf 0..0 gesetzt um hier konform zur IPS zu sein. Entweder eine Observation hat ein Value oder eine data-absent-reason Extension wird an ihrer Stelle verwendet.
Alexander Zautke (Jul 16 2019 at 17:43):
1 Observation pro Laborwert + einen DiagnosticReport um alles zu bündeln.
Alexander Zautke (Jul 16 2019 at 17:45):
Bei valueQuantity sollte eigentlich auch unit und code verpflichtend sein um die Systeme auf UCUM zu verpflichten. Das ist irgendwie in Forge abhanden gekommen :/
Christof Gessner (Jul 16 2019 at 17:47):
system und code.
Alexander Zautke (Jul 16 2019 at 17:47):
Ahm ja :D
Christof Gessner (Jul 16 2019 at 17:48):
und system fixed to UCUM?
Alexander Zautke (Jul 16 2019 at 17:50):
Das war eigentlich geplant. Ich finde schon das es das Ziel sein sollte die Systeme und Hersteller dazu zu bewegen dies umzusetzen.
Alexander Kiel (Jul 16 2019 at 17:53):
Die dataAbesentReason wird noch auf 0..0 gesetzt um hier konform zur IPS zu sein. Entweder eine Observation hat ein Value oder eine data-absent-reason Extension wird an ihrer Stelle verwendet.
Ok das wusste ich nicht. Warum verwendet man den dataAbsentReason aus der Observation nicht?
Christof Gessner (Jul 16 2019 at 17:53):
Wie oben gesagt, bin ich mit diesem Ziel voll einverstanden. Aber in Kenntnis von Bestandssystemen bin ich skeptisch. Eine Abstufung im Sinne von “erstmal LOINC, dann UCUM” könnte pfiffig sein.
Andreas Bietenbeck (Jul 17 2019 at 11:37):
Das war eigentlich geplant. Ich finde schon das es das Ziel sein sollte die Systeme und Hersteller dazu zu bewegen dies umzusetzen.
Ich denke auch, dass wir UCUM auf jeden fall fordern sollen. In der MII können ja zur Not noch Transformationsschritte zwischengeschaltet werden um valide UCUM-Einheiten zu erzeugen, wenn das in den Primärsystemen noch nicht geht. Aber ein Vergleich von verschiedenen Standorten hinweg ohne UCUM erscheint mir nur schwer möglich.
Alexander Zautke (Jul 19 2019 at 10:48):
Alle handwerklichen Fehler die oben genannt wurden sollten nun behoben sein. Nach interner Abstimmung wird das system für valueQuantity auf UCUM gesetzt. Über Feedback welche Systeme hiermit nicht kompatibel wären und auch nicht gemappt werden können würden wir uns sehr freuen :)
Alexander Zautke (Jul 28 2019 at 08:10):
Ich würde ganz gerne folgende Invariante aus den R4 US Core Laborprofilen hier mal zur Diskussion stellen. "us-core-1: Datetime must be at least to day" (https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-observation-lab.html) definiert für effectiveDateTime. Im Endeffekt kann ich die Gründe nachvollziehen, was genau nützt es mir zu wissen aus welchem Jahr oder Monat die Observation stammt. Sollten wir diese Invariante mit aufnehmen, Meinungen?
Alexander Zautke (Jul 28 2019 at 08:11):
CC: @Andreas Bietenbeck
Andreas Bietenbeck (Jul 28 2019 at 09:03):
Gute Idee. Ich habe sogar im Implementation Guide sogare geschrieben, das man mindestens die Minute benötigt. Das ist wichtig um die Ergebnisse im Zeitverlauf ordenen zu können. Im Krankenhaus ist es auch durchaus üblich pro Stunde mehrere Proben pro Stunde zu bekommen, z.B. Blutgasanalysen. Fährst du morgen nach Berlin? Wenn sich da noch diese "Verschärfung" durchsetzen ließe, wäre ich stark dafür.
Björn Schreiweis (Nov 10 2021 at 14:57):
Kann mir jemand inhaltlich begründen, warum ein MII Laborbefund eine Referenz bzw. die Ressource ServiceRequest benötigt? Ich hänge hier gedanklich grade.
Alexander Zautke (Nov 10 2021 at 17:03):
In der initialen Auswertung der Papierbefunde auf denen der DiagnosticReport basiert hatten wir festgestellt, dass dort immer ein Identifier für die Anforderung drauf steht. Für die meisten Systeme ist dieser Identifier der Einstieg in die Ergebnisse.
Christof Gessner (Nov 10 2021 at 18:07):
Passt auch in das Event Pattern http://build.fhir.org/event.html als Event.basedOn
Björn Schreiweis (Nov 10 2021 at 18:11):
ok, damit hätte man ja die Kardinalität 0..* festsetzen können. Gibt es auch aus medizinischer bzw. medizinisch-forschender Sicht eine Begründung?
Alexander Zautke (Nov 10 2021 at 18:45):
@Andrea Essenwanger Wie sieht es aus der Seite der Datenauswertung aus? Ich könnte mir vorstellen, dass das die Verknüpfung wichtig ist um an die richtigen Observations zu kommen?
Alexander Zautke (Nov 10 2021 at 18:45):
@Björn Schreiweis In welchem Use Case bricht das Ganze denn gerade?
Björn Schreiweis (Nov 11 2021 at 08:08):
Wir sind da bei einem internen Review hängen geblieben und haben eben keinen Use Case gefunden.
Andrea Essenwanger (Nov 16 2021 at 09:20):
Alexander Zautke said:
Andrea Essenwanger Wie sieht es aus der Seite der Datenauswertung aus? Ich könnte mir vorstellen, dass das die Verknüpfung wichtig ist um an die richtigen Observations zu kommen?
Im Pathobefund ist sowas relevant ja, weswegen das auch bei uns mandatory wäre. Wir würden hier ja auch gerne darstellen können, welche Proben und Untersuchungen zu einem bestimmten Untersuchungsauftrag gehören. Der End-Befund selbst, kann dann ja sogar 1..* Untersuchungsaufträge haben mit ggf. unterschiedlichen Auftraggeber und Auftragnehmer. Auch Einsender und Entnehmer können sich ja unterscheiden, was für die Erfassung der Daten beim Modul auch somit eine klinische Relevanz hätte. Jedoch könnte ich da nicht sagen ob das auch für die allgemeinen Laboruntersuchungen wichtig wäre. Spontan erscheint es mir sinnvoll, ich schaue aber wahrscheinlich zu sehr mit der Patho-Brille drauf.
Noemi Deppenwiese (Dec 15 2021 at 08:45):
Im IG des Labormodules fehlt die explizite Dokumentation der Extension "Quelle klinisches Bezugsdatum" (sollte vermutlich auf einer Unterseite zu Observation sein) :thinking:
Last updated: Apr 12 2022 at 19:14 UTC
