Help
Login
Busy
Search
MII Core Data Set - Datasets

 
Concept locked
Concept locked
Select Target
Select Concept
De-inherit concept

Select object
 
Edit
Filter
Edit
true50
Fall
Id mide-dataelement-6 Version 2018-06-05 15:30:32
Status Draft Version Label
Description
Das Basismodul Fall  vereint Merkmale eines Aufenthaltes in einer Gesundheitseinrichtung wie Aufnahmedatum, Entlassdatum, Entlassungsart etc.
Source
Konkretisierung des Inhalts:
Die Medizinische Dokumentation verwendet regelmäßig die Unterscheidung Person - Patient - Fall (Visit_occurence); ferner die Unterscheidung von administrativen und medizinischen Fällen.
Für das Basismodul des MI-I-Kerndatensatzes bietet sich die Füllung einer Tabelle “Fall” analog zum P21- Datensatz sowie zur Tabelle “Visit_occurence” im OMOP Common Data Model an. Der P21-Datensatz orientiert sich für die Abrechnung von stationären Fällen an den Definitionen der Administration. Ein “Fall” beginnt mit der Aufnahme ins Krankenhaus an einem Aufnahmedatum und endet mit der Entlassung an einem Entlassungsdatum. Zu den Falldaten gehören in diesem Sinne verschiedene 1:1-Merkmale eines Aufenthaltes - unter anderem die Entlassungsart mit der möglichen Ausprägung “verstorben”. Wertvolle demografische Merkmale in der Tabelle Fall sind Alter, Geschlecht und Wohnort (PLZ). Enthalten sind auch die Versichertennummer und der führende Leistungsträger.
Während eines Aufenthaltes im Krankenhauses ist für jeden Fall jederzeit eine Fachabteilung hauptsächlich zuständig. Dies wird durch die Tabelle FAB (Fachabteilung) im Datensatz nach § 21 KHEntgG ziemlich genau dokumentiert und kann aus deren Grundlage in eine Ergänzung der Falldaten im MI-I-Kerndatensatz übernommen werden.
Im ambulanten Sektor grenzen sich Fälle einer Person entsprechend der Honorierungsart regelmäßig durch Quartalsgrenzen voneinander ab. Im Kerndatensatz sollte trotzdem eine möglichst große Ähnlichkeit der Abbildung angestrebt werden.
Eine entsprechende Ergänzung der Falldaten im ambulanten Sektor könnten im Rahmen des Quartalsfalles die tatsächlichen Arztbesuche darstellen.
Rationale
Begründung der Zuordnung im Kerndatensatz:
Die Falldaten (Merkmale in der Tabelle Fall) werden insbesondere für die sektorale, zeitliche und räumliche Zuordnung sowie für die Provenance der Daten benötigt. Sie bilden das Rückgrat des Datenmodells.
Comment
Vorschlag zum Vorgehen:
In der Startphase der DIZ führen P21-analoge Tabellen “FALL” und “FAB”die wichtigsten Falldaten. Abgestimmte Anpassungen erfolgen bei Bedarf.
Stufe: 1
Operationalization
Vorschläge für die Strukturierung und Codierung:
Die Strukturierung und Kodierung der Tabelle Fall darf sich stark an die Tabellen “FALL” und “FAB” des P21- Datensatzes anlehnen.
Für ambulante Fälle sollte eine Integration in dieses Format unter Berücksichtigung eines besonderen Provenance-Merkmals angestrebt werden.
/
<<  !<<  (r) 
-
/
-
/
/
false
Usage (3)
Busy
Transaction Cardinality / Conformance Project
MI-Datensatz 1…1 Required MII-Kerndatensatz
Template Path (Card/Conf) Project
CDA componentOf B 2019-04-30T15:55:06 hl7:componentOf (0…1) MII-Kerndatensatz
Dataset Path Project
Test CORD_MI_EN / Sandbox BIH
false
Issues (1)
Busy
false
Change Request Status = Open ( mide-issue-33 ): Umbenennung Falldaten
Type Change Request Status Change Request Status = Open Priority Normal
Events
Tracking / Status = Open 2019-04-23 14:26:37 : Tracking by Dagmar Büschges
Description
Finding: Wollten wir die Falldaten nicht umbenennen in "Falldaten (Administration)" o.ä. und eine "Falldaten (medizinisch)" - Struktur anlegen?

-

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)
    Busy
    Transaction Project
    MI-Datensatz MII-Kerndatensatz
    Bildgebung MII-Kerndatensatz
    false
    Issues (1)
    Busy
    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:

    -