Kurzbeschreibung
In diesem Profil kann ein Laborbefund dokumentiert werden. Die im FHIR®-Profil abgebildete Information findet sich im Informationsmodell unter 1. PatientIn, 10. Gesamtbeurteilung, 11. Ergänzende Angaben zum Befund, 12. Anhang Gesamtbefund, 3. Auftragnehmendes Labor, 4. Auftragsdaten, 4.3.5 PatientIn, 4.4.4 PatientIn, 5. Eindeutige Identifikation Laborbefund, 5.1 URI System, 5.2 UUID, 6. Untersuchungsgruppe, 6.3 Laboruntersuchung, 7. Status Laborbefund und 8. Zeitstempel Befund-Erstellung.
Bezeichnung der FHIR®-Ressource
Der FHIR®-Identifikator der FHIR®-Ressource lautet:
https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_LAB_DiagnosticReport_Laboratory_Result
Die Ressource kann auf Simplifier.net unter folgendem Link eingesehen werden:
Übersichtsabbildung des Profils
Kommentierungen
-
-
Key
-
LAB1X0X0-120
-
Erstellt
-
02.08.2022
-
Name
-
BfArM
-
Organisation
-
BfArM
-
Zusammenfassung
-
Einheitliche Kodierung des Dokumententyps „Laboratory report“ für den europäischen Datenaustausch
-
Beschreibung
-
Um den Datentransfer nach Europa zu vereinfachen, sollten inhaltsgleiche Dokumententypen mit gleichnamigen Bezeichnungen dokumentiert werden. Die Kodierung der Dokumenttypen erfolgt im MIO Laborbefund mittels SNOMED CT, im eHDSI (eHealth-Dienste-Infrastruktur) Kontext werden diese mit LOINC-Kodes kodiert. Eine einheitliche Kodierung (bei gleichen Inhalten) des MIOs Laborbefund und eHDSI-LaboratoryReportType unterstützt die Zuordnung von Dokumenten für den europäischen Datenaustausch.
Beispiel:
Innerhalb des MIOs Laborbefund wird folgender Kode angegeben: Kodiersystem: SNOMED CT, 2022-01-31, Kode: 4241000179101, Bezeichnung im Kodiersystem: Laboratory report (record artifact). Im eHDSI Kontext wird hingegen folgender Kode verwendet: Kodiersystem: LOINC, 2.59, Kode: 11502-2, Bezeichnung im Kodiersystem: Laboratory report.
-
-
-
Key
-
LAB1X0X0-117
-
Erstellt
-
01.08.2022
-
Name
-
Thomas Tautz
-
Organisation
-
DHM
-
Zusammenfassung
-
DIAGNOSTICREPORT_LABORATORY_RESULT, PHASE I
-
Beschreibung
-
Warum ist presentedForm ein Pflichtfeld?
-
-
-
Key
-
LAB1X0X0-80
-
Erstellt
-
20.07.2022
-
Name
-
Alexander Zautke
-
Organisation
-
HL7 Deutschland
-
Zusammenfassung
-
Kodierung DiagnosticReport.category als Laborbefund
-
Beschreibung
-
Da es sich um einen Labor-spezifischen Befund handelt sollte dieser entsprechend per Observation.category gekennzeichnet werden
Folgende Kodierungsmöglichkeiten bestehen: <span class="nobr"><a href="http://loinc.org" class="external-link" rel="nofollow">http://loinc.org<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>|26436-6 <span class="nobr"><a href="http://terminology.hl7.org/CodeSystem/v2-0074" class="external-link" rel="nofollow">http://terminology.hl7.org/CodeSystem/v2-0074<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>|LAB
-
-
-
Key
-
LAB1X0X0-21
-
Erstellt
-
11.07.2022
-
Name
-
Mark Langguth
-
Organisation
-
Langguth.Digital
-
Zusammenfassung
-
Auf extensions für .anzeigenameXYZ verzichten
-
Beschreibung
-
Hallo liebes MIO-Team,
im Rahmen der MIO-Sprechstunden haben wir erarbeitet, auf die ergänzenden deutschen Klartextbezeichner über .extension zu verzichten (da diese Informationen auf UI-Ebene ohnehin nicht verwendet werden und daher nur unnötig Implementierungsaufwand erzeugen und potentiell Widersprüchlichkeiten erzeugen können).
Bei U-Heft, Mutterpass & Co werden diese extensions daher in den Fortschreibungen entfernt werden.
Aus diesem Grund sollten .anzeigenameStatus, .anzeigenameCode etc. daher in der erste Stufe des Laborbefunds direkt weggelassen werden.Beste Grüße
Mark Langguth
-
-
-
Key
-
LAB1X0X0-19
-
Erstellt
-
30.06.2022
-
Name
-
Mark Langguth
-
Organisation
-
Langguth.Digital
-
Zusammenfassung
-
presentedForm sollte nicht verpflichtend angegeben werden müssen
-
Beschreibung
-
Hallo liebes MIO-Team,
in der original FHIR-Ressource DiagnosticReport sind die Attachments über .presentedForm optional (0..<strong>), in der MIO-Ausprägung Laborbefund muss nun aber mindestens eine .presentedForm angegeben werden (1..</strong>).
Dies ist abzulehnen.
Ziel der MIO-Aktivitäten ist die Übermittlung strukturierter, syntaktisch wie semantisch interoperabler Werte. Redundanzen, noch dazu in völlig nicht-interoperabler Form als "irgendwie" verfasstes RTF, HTML oder sonstiger visueller Repräsentation, die ZUSÄTZLICH zu den codierten Werten übermittelt werden, gefährden die Verlässlichkeit der Aussage des Laborbefunds für den Arzt und letztlich die Patientensicherheit.
Da hilft es auch nichts, dass gefordert wird, dass das lesbare Attachment die gleichen semantischen Informationen enthalten muss. Ein empfangendes, sprich lesendes System kann nicht automatisiert überprüfen, ob diese Vorgabe eingehalten wurde. Soll der MIO-Laborbefund dem Arzt angezeigt werden, müsste ein System, wenn das MIO die strukturierten Daten sowie 1-n Anhänge enthält, den Arzt folglich darüber informieren, dass multiple Datenrepäsentanzen enthalten sind, ohne dass das System etwas zur Deckungsgleichheit aussagen kann. Dem Arzt müssten folglich ALLE Datensichten nebeneinander angezeigt werden:
1. Rendering der codierten Daten in menschenlesbarer Form (=das eigentliche Ziel des MIOs)
2. Anhang 1
3. Anhang 2
4. Anhang 3
...
ALLE diese Darstellungen müsste der Arzt dann sichten und auf mögliche Widersprüche prüfen. Erst wenn er erkannt hat, dass keine Widersprüchlichkeiten vorliegen, dürfte er sich auf die Daten des Laborbefunds verlassen.Das ist weder einem Arzt zuzumuten noch im Interesse der Digitalisierungsbemühungen.
Am Beispiel eArztbrief sieht man, dass im Format vorgesehene vereinfachte Fallbackoptionen (dort PDF) gegenüber den aufwändigeren Codierungen (im XML) bevorzugt werden. Diesen Fehler dürfen wir hier nicht erneut machen. Daher sollte .presentedForm nicht mandatory werden, sondern im Gegenteil im Unterschied zur orginal-Ressource gänzlich gestrichen werden.
Beste Grüße
Mark Langguth
-
