Help
Login
Search
MII Core Data Set - Datasets

 
Concept locked
Concept locked
Select Target
Select Concept
De-inherit concept
Select object
 
Edit
Filter
Edit
true50
Laborbefund
Id mide-dataelement-35 Version 2018-06-05 22:24:45
Status Draft Version Label
Description
Das Basismodul Laborbefunde enthält strukturierte Informationen zu Laboruntersuchungen.
Source
Konkretisierung des Inhalts:
Zu nahezu jedem stationär behandelten Patienten werden Laboruntersuchungen durchgeführt; die resultierenden Laborbefunddaten liegen zum großen Teil zentral vor. Patienten- und fallbezogen sollten je Laboruntersuchung folgende Informationen in das DIZ überführt werden:
  • Durchgeführte Untersuchung - Analysename mit eindeutiger Untersuchungs-ID (mittels LOINC, s.u.)
  • Untersuchungsdatum
  • Ergebnis (Messwert) der Untersuchung - mit normierter Einheit (mittels UCUM, s.u.)
  • Interpretation: Kennzeichnung, ob pathologischer Wert (empfohlen)
  • Skalentyp (optional)
  • Referenzbereich (empfohlen)
  • Herkunftslabor (optional)
Über den Bereich der klassischen klinisch-chemischen und hämatologischen Labordaten hinaus können weitere klinische Untersuchungen, mikrobiologische Befunde und Vitalparameter gleichermaßen abgebildet werden. Sukzessiv kann die LOINC-Normierung und normierte Datennutzung auf weitere Beobachtungen (z.B. in Radiologie, Pathologie) bis hin zur deskriptiven medizinischen Dokumentation (LOINC Clinical Document Ontology) ausgebaut werden.
Rationale
Begründung der Zuordnung im Kerndatensatz:
Dieser Datenkörper kann in großer Breite und für einen sehr großen Anteil der Fälle die Datenbestände analog zu § 21 KHEntG ergänzen und medizinisch relevante Fragestellungen zu beantworten helfen (z.B. im Bereich Pharmakovigilanz, symptomatisches Screening, Evaluierung medizinischer Dokumentation/Diagnosesicherung, Therapieüberwachung, Infektionsforschung, Ein- und Ausschlusskriterien zu klinischen Studien, Entwicklung und Validierung neuer Referenzbereiche). Ein früher Einschluss und eine frühe Nutzung dieses Datenkörpers erscheinen vielversprechend und sinnvoll, da die Normierung zumindest im ersten Schritt (Subset klinisch-chemische Laboruntersuchungen, s.u.) nicht in menschliche Dokumentationsprozesse eingreift, sondern apparativ generiert werden kann. Des Weiteren existiert für weite Teile von LOINC eine deutsche Übersetzung durch das DIMDI.
Comment
Vorschlag zum Vorgehen:
a) LOINC-Subset:
Im ersten Schritt soll ein Subset ausgewählt werden, das sich an folgenden Kriterien orientieren soll:
  • Untersuchung (Analyse) an möglichst vielen Standorten der MI-I vorhanden
  • Untersuchung für möglichst viele Patientenfälle relevant
  • Untersuchung relevant für Fragestellungen der Forschung und Patientenversorgung
  • Untersuchung relevant für Use Cases der Konsortien
  • LOINC-Codes vorhanden (Globaltests vor Spezialtests)
  • Einfaches Handling der LOINC-Normierung für die betreffende Untersuchungsart
  • LOINC-Code existiert schon als konsentierter Teil anderer einschlägiger Projekte
  • (LOINC-Name ist in Deutsch verfügbar)
Aus den Kriterien leitet sich ab, mit einem Subset der klinisch-chemischen Laboruntersuchungen (inkl. Basis Hämatologie/Toxikologie) zu starten und sukzessive im Rahmen der Roadmap um komplexere Bereiche (z.B. Mikrobiologie) zu erweitern. Das Subset der ersten Stufe soll zum 01.01.2020 an allen DIZ für jeden eingeschlossenen Patienten, zu welchem Analysen aus dem Subset durchgeführt wurden, normiert zur Verfügung stehen.

  • Entwicklung eines Vorschlags für ein deutsches LOINC-Subset unter besonderer Berücksichtigung existierender Vorarbeiten (II/2017)
  • Bei Bedarf: ggf. Fachworkshop mit den Verfassern entsprechender LOINC-Subsets in A (ELGA), CH (e-health Suisse), F (IHE LTF-4), evtl. NL, USA 
  • Kleine Redaktionsgruppe sendet ein Subset-Draft für die deutschen “LOINC 1000+” abzustimmenden Codes an alle antragstellenden Standorte zur dortigen Kenntnisnahme bzw. Kommentierung durch IT und Laboratoriumsmedizin.
  • Festlegung noch in III+IV/2017, sodass zwei Jahre zum Mapping und zur Einrichtung in den Standorten zur Verfügung stehen.
  • Mapping der “LOINC 1000+” an allen DIZ-Standorten zwischen 01.01.2018 und 31.12.2019.
  • Das Subset der ersten Stufe steht ab 01.01.2020 an allen DIZ für jeden eingeschlossenen Patienten, zu welchem Analysen aus dem Subset durchgeführt wurden, LOINC-normiert zur Verfügung.
  • Der Datenkörper kann für übergreifende Audit-Abfragen ab IV/2020 genutzt werden.
Stufe: 2

b) UCUM:
  • Fachaustausch (Workshop) zum gezielten Diskussion von Erfahrungen in Nachbarländern (insbesondere Schweiz, Österreich, Niederlande, ggf. USA) zur Implementation und Nutzung von UCUM in Bestandssystemen. Wichtig: Einbeziehung der Industrie (insbes. Hersteller/Anbieter von LIS-/KAS-/PDMS-Systemen). Zielzeitraum: III+IV/2017
  • Hierauf basierend weiterer Verfahrensvorschlag zur Ergänzung der Roadmap. (fertigzustellen bis Start der Aufbauphase)
Stufe: 3
Operationalization
Vorschläge für die Strukturierung und Codierung:
LOINC + UCUM (Laborparameter und Einheiten)

a) LOINC:
LOINC ( L ogical O bservation I dentifiers N ames and C odes) enthält eine flache Tabelle mit international eindeutigen IDs für klinische Untersuchungen und Beobachtungen, die eine hohe Diskrimination zwischen Untersuchungsvarianten erlauben. LOINC ist frei verfügbar und wird regelmäßig gepflegt (Regenstrief Inst./USA). Details siehe LOINC-Webseite (samt Datenbank und Werkzeugen). LOINC ist als Referenzterminologie u.a. in der FHIR Resource “Observation” explizit erwähnt. Die LOINC-Normierung apparativ gewonnener Untersuchungen ist deshalb besonders einfach, da im zugehörigen IT-System (z.B. LIS) nur einmalig die Mastertabelle der Analysen/Untersuchungen erweitert werden muss um eine Spalte der dazugehörigen LOINC-ID - und diese mit den Analysen über eine Schnittstelle mit ausgegeben werden können. Da die Übermittlung mehrerer IDs schon dem HL7v2-Protokoll entspricht, ist hier eine hohe Realisierungswahrscheinlichkeit mit Bestandssoftware gegeben.

b) Auswahl eines Subsets mit LOINC-Normierung
Das LOINC Subset für die erste Stufe der DIZ- und konsortienübergreifenden Normierung folgt folgenden Vorerfahrungen:
Als sinnvolle Größe eines Subsets, das eine hinreichende Nutzung erlaubt (nicht nur für das Audit 2020/21), wird ein Umfang von ca. 1.000 Parametern angestrebt (vergleichbar dem Umfang der Festlegungen bei der ELGA). Dabei ist die Anzahl kein Meilenstein für sich, sondern muss den Machbarkeiten und Gegebenheiten ggf. angepasst werden (in die eine oder andere Richtung).
Zur Orientierung: Das IHE LOINC Test Codes Subset umfasst 2.500 Codes und schlüsselt sich wie folgt auf:
  • Discipline - Number of LOINC test codes selected
  • Chemistry including urinalysis and challenge studies - 873
  • Hematology - 284
  • Toxicology + drug monitoring - 194
  • Virology (including serology) - 374
  • Parasitology and mycology - 158
  • Bacteriology - 387
  • Immunology and cell mark - 278
  • Patient and specimen - 30
Mit einem Subset dieser Größe lassen sich ca. 99% aller Laboruntersuchungen im Routinebetrieb kodieren.

c) UCUM
UCUM (The Unified Code for Units of Measure) definiert eine international einheitliche maschinenlesbare Wiedergabe von Maßeinheiten.
Die Implementation von UCUM in LIS-Bestandssysteme ist etwas komplexer. Hier empfiehlt sich ein Fachaustausch (Workshop) zum gezielten Diskussion von Erfahrungen in Nachbarländern (insbesondere Schweiz, Österreich, Niederlande, ggf. USA). Eine deutsche Routine-Implementation von UCUM ist derzeit nicht bekannt. Allerdings kann ein Mapping auf UCUM-Einheiten auch auf Ebene einer Forschungsdatenbank erfolgen.

d) Syntaktische Normierung der Kommunikation von Labor- und anderen Untersuchungsdaten
Die Patienten- und Fall-bezogene Kommunikation von Labor- und anderen Untersuchungsdaten mit LOINC- (und ggf. UCUM-) Normierung ist weitestgehend unabhängig von der Wahl der Syntax; nahezu alle relevanten Kommunikationsstandards und -profile unterstützen die Nutzung von LOINC (und UCUM):
  • HL7 CDA
  • HL7 v2 Messaging
  • HL7 FHIR
  • IHE
  • LDT 2.0 und 3.0
  • CDISC SDTM
In der Klinik ist eine Nutzung internationaler Standards wünschenswert, aber eine Vereinheitlichung der ETL-Strecke zum Import der Labordaten in die DIZ nicht zwingend konsortienübergreifend notwendig.
/
<  <<  !<<  (r) 
-
/
-
/
/
false
Usage (5)
Transaction Cardinality / Conformance Project
MI-Datensatz 1…1 Required MII-Kerndatensatz
Template Path (Card/Conf) Project
Speciality-SectionA 2019-03-26T16:24:56 hl7:section (0…*) MII-Kerndatensatz
Dataset Path Project
Test ECR / Befunde, Dokumente / Diagnostikbefunde / Sandbox BIH
SMITH Sandbox
MI Datensatz Erweiterungsmodule / Bioprobendaten / Bioprobe / MII Core Data Set
false
Issues (1)
false
Change Request Status = Open ( mide-issue-28 ): Weiteres Vorgehen
Type Change Request Status Change Request Status = Open Priority Normal
Events
Assignment 2019-02-11 08:43:32 : Assigned To dr Kai U. Heitmann by Dagmar Büschges
Tracking / Status = Open 2019-02-11 08:43:31 : Tracking by Dagmar Büschges
Description
Finding:

Wie geht es weiter mit der Template-Generierung/Assoziation? 

Werden die (finalen) Template-Assoziationen des MI-Datensatzes zu “MI-Templates” zusammengefasst? 

Übernehmen wir dann die MI-Templates als Vorlagen für (spezialisierte) Use Case Templates, und assoziieren diese dann zu den Datenelementen in den Use-Case-Datensätzen?

Suggestion:

-

Further explanation:

-
 
 
true50
Dataset MI Datensatz –
Id mide-dataset-1 Version 2018-06-05 12:44:12
Status Draft Version Label
false
Description
MI-I-Kerndatensatz

Methodik zur Erstellung des Kerndatensatzes
Ausgangspunkt der Erstellung des Kerndatensatzes waren die im Rahmen der AG Data Sharing zusammengestellten Vorschläge für Audit-Abfragen, die in der Sitzung der AG Interoperabilität am 09.01.2017 diskutiert wurden. Hierbei wurden die jeweils in den Abfragen benannten Datenarten zu Modulen zusammengefasst und Vorschläge der AG-Mitglieder zur Strukturierung und semantischen Auszeichnung ergänzt.

Ausschlaggebend für die Aufnahme in den Kerndatensatz waren die folgenden Kriterien:
  • Relevanz für Forschung und Patientenversorgung
  • Relevanz für die Use Cases der Konsortien
  • Verfügbarkeit und Erschließbarkeit an den Standorten
  • Strukturierungsgrad und Verfügbarkeit von Terminologien
Auf Basis der Verfügbarkeit wurde in der AG-Sitzung darüber hinaus eine Zuordnung von Datenarten entweder zu einem Basismodul, das konsortienübergreifend für Audit-Abfragen vorgehalten werden soll oder zu verschiedenen Erweiterungsmodulen vorgenommen, die in Abhängigkeit der Use cases der einzelnen Konsortien ergänzend vorgehalten werden können.

Die Redaktionsgruppe Kerndatensatz hat diesen Vorschlag über mehrere Telefonkonferenzen hinweg in Bezug auf die folgenden Aspekte ausgearbeitet:
  • Konkretisierung des Inhalts
  • Begründung für die Aufnahme in das Basis- oder ein Erweiterungsmodul
  • Vorschläge für die Strukturierung und Codierung
  • Vorschläge zum weiteren Vorgehen
Aufgrund der begrenzten Zeit musste eine Priorisierung vorgenommen und einzelne Module zur späteren Ausarbeitung zurückgestellt werden. Der Kerndatensatz ist insgesamt als “Work in Progress” zu verstehen, der im Verlauf der MI-Initiative laufend vervollständigt und an die aktuelle Entwicklung angepasst werden muss. Dies umfasst auch den Austausch von heute aus pragmatischen Gründen gewählten nationalen Terminologien (z.B. unmittelbar verfügbare Codelisten aus der § 301- Abrechnungsdokumentation) gegen internationale Terminologien, sobald ihre Verfügbarkeit für die Konsortien geklärt ist (z.B. im Fall von SNOMED CT) und Ressourcen für die Etablierung entsprechender Mappings zur Verfügung stehen.

Die Weiterentwicklung des Kerndatensatzes sollte in enger Abstimmung mit der Roadmap des Nationalen Steuerungsgremiums und dem Eckpunktepapier “Mindestanforderungen Interoperabilität” der AG Interoperabilität erfolgen. Bei mehreren Modulen des Kerndatensatzes wurden im Abschnitt “Weiteres Vorgehen” Vorschläge für die weitere Ausarbeitung im Rahmen von Vorbereitungs- oder Begleitprojekten im Kontext der MI-Initiative eingearbeitet.

Hinweise zur Interpretation des Dokuments
  • Im Text wird mehrfach auf den “Paragraph 21”-Datensatz referenziert (analog zum § 21 KHEntgG). Hiermit ist ausdrücklich die inhaltliche Zusammensetzung und syntaktische Struktur, nicht jedoch die Herkunft der Daten gemeint. Ein “analog zu § 21” strukturierter Diagnosedatensatz kann (und soll) z.B. durchaus für die Bereitstellung ambulanter oder auch nicht abrechnungsrelevanter Nebendiagnosen verwendet werden.
  • Aus der Nennung einer Datenart oder eines Datenelements in einem Modul des Kerndatensatzes ergibt sich keine Aussage darüber, ob auf eine Anfrage hin eine Bereitstellung bzw. Herausgabe von Daten der Standorte erfolgen kann. Hier sind die Vorgaben des Datenschutzes sowie Entscheidungsprozesse innerhalb der Konsortien und einzelnen Standorte (z.B. im Rahmen von Use & Access Committees) ausschlaggebend.
  • Im Dokument wird mehrfach auf SNOMED CT als geeignete Nomenklatur für die Codierung verschiedener Datenelemente verwiesen. Die Nutzung von SNOMED CT steht jedoch unter dem Vorbehalt einer entsprechenden Lizensierung, so dass hier ggf. geeignete Alternativen gesucht werden müssen.
  • Zur Kennzeichnung des Handlungsbedarfs für die weitere Aufarbeitung wurde jede Datenart im Abschnitt “Weiteres Vorgehen” nach der folgenden Stufenskala kategorisiert: 
    1. Datenelemente liegen bereits in strukturierter Form vor und geeignete Vorgaben zu ihrer Ablage und semantischen Codierung sind bereits etabliert (z.B. Elemente analog § 21-Datensatz)
    2. Datenelemente liegen strukturiert vor und es gibt geeignete Vorgaben zu ihrer Ablage und Codierung, die jedoch noch nicht umgesetzt sind (z.B. LOINC-Codierung von Laboranalyten)
    3. Datenelemente liegen vor, aber ihre Struktur und Aufbereitung muss noch weiter ausgearbeitet werden (z.B. Medikation)
    4. Datenelemente sind relevant, aber ihre Verfügbarkeit muss noch erhoben und auf dieser Basis die weitere Aufbereitung ausgearbeitet werden (z.B. strukturierte Merkmale aus Pathologie- und Radiologiebefunden)
    Bezüge aus den einzelnen Modulen können sowohl zu einzelnen Behandlungsfällen (und damit indirekt auch zur Person) oder auch nur zur Person hergestellt werden. Querbezüge zwischen den Modulen (z.B. Verknüpfung einer Diagnose mit einer Medikation als Indikation) sind möglich (und wünschenswert), aber bislang nicht Bestandteil des Kerndatensatzes. Das Modul Strukturdaten enthält Daten ohne Patientenbezug und hat daher keine Verbindungen zu den restlichen Modulen.

    Quellen: 
    false
    Usage (2)
    Transaction Project
    MI-Datensatz MII-Kerndatensatz
    Bildgebung MII-Kerndatensatz
    false
    Issues (1)
    false
    Change Request Status = Open ( mide-issue-18 ): Modellierung Specimen, Körperort, Messverfahren
    Type Change Request Status Change Request Status = Open Priority High
    Events
    Tracking / Status = Open 2019-02-04 08:55:06 : Tracking by Dagmar Büschges
    Description
    Die allgemeinen Messwerte erhalten eine Struktur analog der Laboruntersuchung (ohne das Attribut "Probe")
    Tracking / Status = Open 2019-01-31 08:40:50 : Tracking by Danny Ammon
    Description
    Ganz recht, die LOINC-Top300 beziehen sich auf die 300 häufigsten Analyte im Laborbereich (haupts. Blutuntersuchungen)!
    Tracking / Status = Open 2019-01-30 18:03:12 : Tracking by Dagmar Büschges
    Description
    Ich habe festgestellt, dass ich gedanklich Labor- und andere Messwerte in einen Topf geworfen habe.
    Gehe ich recht in der Annahme, dass von der LOINC 300 Primär-/Sekundärproblematik auch "nur" LOINC-codierte 
    Labor- und Blutgaswerte betroffen sind?
    Tracking / Status = Open 2019-01-28 17:59:22 : Tracking by dr Kai U. Heitmann
    Description
    Dagmar, die Modellierung von Laborwert ist noch nicht vollständig (im MI-Datensatz Basis).
    Sorry für die Abkürzungen, also:
    • Methode (Datentyp Code) muss Bestandteil der Laboruntersuchung sein.
    • Probenmaterial ist zum einen Bestandteil der übergeordneten Gruppe (für eine Reihe von Laboruntersuchungen mit allen derselben Probe) und zum anderen auch an der Laboruntersuchung (für einzelne Untersuchungen).
    Ich hoffe, wir können in der nächsten Zeit mit der Laborgruppe mal alle Items zusammen reviewen, denn sonst leiten alle hiervon ab, obwohl es vielleicht noch nicht ganz fertig ist.

    Weitere Hinweise: IHE XDLAB CDA
    Laboruntersuchung https://art-decor.ihe-europe.net/art-decor/decor-templates--XDLAB-?section=templates&id=1.3.6.1.4.1.19376.1.3.1.6
    Probe https://art-decor.ihe-europe.net/art-decor/decor-templates--XDLAB-?section=templates&id=1.3.6.1.4.1.19376.1.3.1.2
    Tracking / Status = Open 2019-01-28 15:20:51 : Tracking by Dagmar Büschges
    Description
    Hallo Kai,

    danke für die prompte Antwort.
    Da im DIZ die LOINC Top 300 Codierungen als Standard gesetzt sind und diese - soweit ich gesehen habe - z.T. unspezifisch sind, müssen wir nach meinem Verständnis die anderen Informationen ausmodellieren. Das wollte ich tun, aber wo finde ich Specimen oder methodCode?
    Tracking / Status = Open 2019-01-28 12:49:37 : Tracking by dr Kai U. Heitmann
    Description
    Hier zwei Anmerkungen von mir:
    • Messwerte sind keine Prozeduren, sondern Bestandteil (value) einer Beobachtung.
    • LOINC ist bekanntlich multiaxial, eine Achse ist die Methode, eine andere das Material. Es sollte entschieden werden, ob man "methodenlose" und "materiallose" LOINC Codes verwendet und die Methode dann separat im Element methodCode angibt, das Material in Specimen, oder der LOINC Code immer die Methode mit umfasst und der methodCode etc. dann "verboten" ist.
    Tracking / Status = Open 2019-01-28 11:45:11 : Tracking by Dagmar Büschges
    Description
    Finding:

    Insbesondere im Zusammenhang mit der Verwendung der LOINC 300 Codes anstelle spezifischerer Codes frage ich mich, ob und wie zusätzliche Informationen wie untersuchtes Material (Blut, arterielles Blut, Urin...), Messort am Körper oder Messverfahren zu eine Messwert modelliert werden sollen.
    Diese Parameter habe ich in Procedure-Templates gesehen.

    - Werden Messwerte im DIZ zukünftig mit einer Prozedur verknüpft?
    - Übernehmen wir die Werte in ein MI-Messswert-Template?

    Suggestion:

    -

    Further explanation:

    -