Nach Abschluss der Kommentierung und der Prüfung sowie Bewertung des 1. Teils der eingegangenen Kommentare (83) ist hier ein Überblick zu den eingegangenen Kommentaren und den Bewertungsergebnissen einsehbar. Hier kann entnommen werden, an welchen Stellen Kommentare zu einer Überarbeitung des MIOs oder zur Aufnahme von Operationalisierungsempfehlungen für die umsetzenden IT-Systeme geführt haben.
Inhalt
| Kommentarthema | Ergebnis |
|---|---|
| Nur ein im Labor erzeugtes MIO Laborbefund wird später nach Befundbesprechung mit dem Patienten seinen Weg in die ePA finden und so weiteren Ärzten (sowie dem Patienten) zur Verfügung stehen | Das Anliegen, das MIO Laborbefund im Labor zu erzeugen, wurde mehrfach und auf vielen Ebenen diskutiert, insbesondere auch im Rahmen der "Arbeitsgruppe Fachgremien Labor", mit deren Expertise wir die Spezifikation MIO Laborbefund vorbereitet haben. Es gibt ein klares Votum dafür, dass ein MIO dort erzeugt wird, wo die Daten entstehen und dass ein MIO Laborbefund vom dokumentierenden Labor erzeugt werden können soll. Für die Verteilung des MIO Laborbefund werden/sind zwei Wege geebnet:
|
| Es wurde vorgeschlagen, LDT zusätzlich oder HL7 V2 zusätzlich zum MIO zu verwenden. Das bedeutet, es gibt verschiedentlich Redundanzen ohne einen Hinweis, wie diese bei Diskrepanzen aufgelöst werden können. | Unsere Vision ist, dass das MIO Laborbefund zukünftig der führende Standard wird. Eine parallele Übermittlung in verschiedenen Formaten wird nicht angestrebt. |
| Der Laborbefund stellt nicht Gesamtprozess dar. Das MIO Laborbefund ist so anzupassen, dass alle Prozessschritte abgebildet werden können. | Beim MIO-Laborbefund handelt es sich um die Befunddokumentation, also genau ein Artefakt von mehreren Dokumenten aus dem gesamten Prozess. Das Befunddokument kann nicht den gesamten Prozess abdecken, aber es kann auf den zugrundeliegenden Auftrag verweisen und das ist eingearbeitet. |
| Das angedachte Datenmodell entspricht nicht einer Befundübermittlung. | Das MIO enthält in der Tat nicht die Übermittlungsdaten, wie sie der LDT3 als Auftragsdaten oder Abrechnungsdaten enthält. Das ist auch nicht Ziel des MIO-Dokumentes für die ePA. Das angedachte MIO Datenmodell entspricht genau einem Laborbefund(-Dokument). |
Die Möglichkeit, die Fragestellung zu präzisieren finde ich grundsätzlich gut und für die interprofessionelle Zusammenarbeit auch sehr hilfreich. Hier eine Frage zum Verständnis: Gerade im hausärztlichen Kontext kommt es häufiger vor, dass mit einer Untersuchung mehrere Fragestellungen ausgeschlossen und/oder bestätigt werden sollen. Ein einfaches Beispiel wäre die Abklärung von Müdigkeit, bei der sowohl ein kleines Blutbild zum Ausschluss einer Anämie als auch gleichzeitig TSH oder ganz allgemein Leberwerte bestimmt werden könnten. Präzisiere ich die Fragestellung für jeden einzelnen Wert? Das wäre im klinischen Alltag sicherlich zu aufwendig. Andernfalls gibt es eben eine gewisse Unschärfe, denn nicht immer kann klar zwischen Ausschließen oder Bestätigung (u. a.) unterschieden werden. | Im MIO Laborbefund gibt es ein Freitextfeld "Fragestellung", welches bezweckt, die Fragestellung(en) zusammenzutragen, die aus dem Laborauftrag stammen. Hier wird ein fachlicher Bezug zum Auftrag hergestellt. Das Feld wurde gezielt in die Struktur mit aufgenommen, nicht nur weil die LDT3-Kommunikationsstruktur eine solche Angabe enthält (FK8417, Anlass der Untersuchung, allerdings zahlen-codiert), sondern vor allem, weil der labormedizinische Beirat bestrebt ist, die Qualität der labormedizinischen Befundung zu verbessern. Wenn der befundenen Person die Fragestellung bekannt ist, kann die Bewertung präziser erfolgen. Umfang und Präzision des Inhaltes zu "Fragestellung" sind abhängig vom jeweiligen Fall und dem Genauigkeitsanspruch des/der behandelnden Arztes/Ärztin. Ergänzung zur bereits veröffentlichten Antwort: Im Rahmen weiterer Kommentarbearbeitungen wurde das Datenelement Fragestellung weiter präzisiert zu einer Datenstruktur mit den Unterelementen für Auftragsdiagnose, Anlass und/oder Veranlassungsgrund. |
| Sammelzeitraum mit genauem Beginn und Ende wird seltener angegeben. Dauer ist üblicher und sollte deshalb vorrangig anzugeben sein, dies sollte das Infomodell berücksichtigen (Rangfolge Strukturknoten, Kardinalität/Konformität) | Die Rangfolge der Strukturknoten hat keinen Einfluss auf die (Reihenfolge in der) Darstellung. Das Informationsmodell entspricht hier dem FHIR® Standard. Die Kardinalitäten für die Elemente Entnahmezeitpunkt und Sammelzeitraum haben wir auf optional 0..1 gesetzt. Das ist in der Benehmensversion angepasst. |
| Sammelzeitspanne von/bis kann kein Pflichtfeld sein | Die Kardinaliät des Strukturknotens Sammelzeitraum haben wir auf optional 0..1 gesetzt. Das ist in der Benehmensversion angepasst. Die Felder der untergeordneten Elemente von und bis werden nur dann zu verpflichtenden Angaben, wenn die Struktur Sammelzeitraum überhaupt befüllt wird. |
6.3.5.9 Ergänzende Angaben zur Probe, Phase I: das Beispiel LDT3 sind Patienteneigenschaften oder Auftragseigenschaften vgl. 4.6. Hier sollten nur Probeneigenschaften wie z. B. Stuhl: Konsistenz weich, Abstrich eitrig, Serum hämolytisch, Zeitspanne nach Applikation Testsubstanz usw. angegeben werden. | Der Einwand ist korrekt. Der Beschreibungstext zu Ergänzende Angaben zur Probe ist in der Benehmensversion angepasst und mit adäquaten Beispielen versehen. Die bisher aufgeführten LDT3-Beispiele passen in der Tat in das Freitextfeld Auftragsdaten / Klinische Angaben. Dort sind und waren sie bereits gelistet. |
| Was passiert bei Patientenverwechslung? | Grundsätzlich können Befunde in der ePA überschrieben werden. Die Konstellation, dass ein MIO versehentlich zum falschen Patienten hochgeladen wird, betrifft den Datenschutz beim Dokumentenmanagement in der ePA. Zu den Details der Konsequenzen wäre die gematik der Ansprechpartner. |
| Was passiert generell bei nachträglich erfolgter Befundkorrektur, wird der Erstbefund überschrieben in der ePA? | Dieses Thema wurde im Rahmen der Kommentarbearbeitung noch einmal vertieft, unsere Antwort haben wir zum Zeitpunkt der "Teilveröffentlichung II" aktualisiert: Das Informationsmodell wurde erweitert, so dass aus der Kombination "Status Gesamtbefund" und optional "Sekundärstatus Gesamtbefund" erkennbar ist, warum es eine neue Version des Befundes gegeben hat. Bei nachträglicher Korrektur oder Erweiterung eines eines MIO Laborbefund, werden nicht nur die Inhalte sondern auch Status bzw. Sekundärstatus des Befundes aktualisiert. Dieser aktualisierte Befund kann so beispielsweise durch einen Status von "Storniert" oder "irrtümliche Eingabe", oder einen Sekundärstatus wie "Geändert", "Korrigiert" oder "Angefügt" die geschehene Änderung abbilden. In den Metadaten der FHIR-Daten des Befundes wird die Version aktualisiert, während die Identifier identisch bleiben. Dadurch ist eine Versionsnachverfolgung per FHIR möglich. Die aktualisierten FHIR-Ressourcen nehmen in der ePA mit dem Upload den Platz als aktueller Befund ein, während die alten Versionen weiterhin per Versionshistorie verfügbar sind. |
Komparator beim Titer, Ergebniswert Ratio Falsche Position, ein Komparator vor der Division bedeutet z. B., dass 1:20 kleiner ist als 1:10, dies dürfte nicht gemeint sein. Korrekt müsste ein geringerer Titer als 1:10 mit >1:10 angegeben werden oder der Komparator in den Nenner wandern als 1:<10. | Die Angabe des Titers setzt sich aus zwei ins Verhältnis gesetzten Quantitäten (Zähler, Nenner) zusammen. Wenn zur Ergebnisdarstellung von Antikörpertitern ein Komparator benötigt wird, dann gelten - auch im Sinne der Maschinenlesbarkeit - die mathematischen Regeln, beispielsweise ist 1:32 ein kleinerer Wert als 1:16. Damit dies für Kommentierende menschenlesbar erscheint, steht im Informationsmodell das Element Komparator vor den Elementen Zähler und Nenner. In FHIR® wird für Quotienten der Komparator beim Zähler (numerator) abgebildet. Letztlich obliegt die Darstellung in einer Anwendung dem jeweiligen Primärsystem. |
| Klinischer Bezugszeitpunkt: Das Feld ist redundant. Ist das nicht durch die Abnahme- oder Sammelzeit bereits beantwortet? | Die Definition des Klinischen Bezugszeitpunktes entstand in Abstimmung mit der Modellierung des Kerndatensatzes Modul Laborbefund der Medizininformation-Initiative und auch in Abstimmung mit dem labormedizinischen Beirat für das MIO. Die Redundanz ist beabsichtigt. Es geht darum, einen Zeitpunkt ermitteln zu können, der für Forschungsstatistiken als vergleichsrelevant eingestuft wird. Da im klinischen Alltag nicht sichergestellt ist, dass grundsätzlich und immer der Zeitpunkt der Materialentnahme auch dokumentiert wird, wurde ein Algorithmus für den klinischen Bezugszeitpunkt festgelegt, um die Dokumentation eines statistisch relevanten Zeitpunktes zu garantieren. In der Benehmensversion ist der Beschreibungstext im Informationsmodell um eine Erläuterung erweitert. |
| Es wird gewünscht, für die konkrete Benennung des Kollektivs aus einer standardisierten Wertetabelle auswählen zu können, beispielsweise auch die im LDT3 gelisteten Einflussgrößen zu verwenden und zu erweitern. | Es gibt unvollständige Standardisierungsansätze für die Eingrenzung von Kollektiven (nachzulesen z. B. bei XeHealth ID 5.3 WP5 Draft V0.7 oder HL7 FHIR® oder LDT3). Bisher sind aber keine ausgereiften Standards zur Bezeichnung oder Strukturierung von Kollektiven verfügbar. Auch im Rahmen der Zusammenarbeit mit dem Beirat (AG Fachgremien Labor) gab es dazu kein abgestimmtes Ergebnis. Aus diesem Grund wird in dieser Ausbaustufe ein Freitextfeld ohne Restriktionen angeboten. Beispiele für Inhalte sind:
In der Benehmensversion ist der Beschreibungstext im Informationsmodell um eine Erläuterung erweitert. |
| Für die untere/obere Richtgrenze fehlt der Komparator. Es ist wichtig zu wissen, ob Grenzen inklusive oder exklusive gelten. | In den Regeln von HL7 FHIR® ist festgelegt, dass Referenzgrenzen inklusive gelten:
Durch die Angabe der Richtgrenze ist eindeutig vorgegeben, welcher Komparator gemeint ist. Daher wird an dieser Stelle der Datenstruktur kein zusätzliches Datenelement "Komparator" benötigt. Ein Beispiel: Die obere Richtgrenze (vom Typ "Referenzbereich") ist mit 5,3 angegeben. Diese Grenze gilt inklusive, d. h. <= 5,3 liegen innerhalb der Referenzgrenze, Werte > 5,3 liegen außerhalb der Referenzgrenze. |
Eine vielfach genannte Anforderung: Bildanhänge zur Untersuchungsgruppe ermöglichen Als Ergänzung zu Messergebnissen muss es möglich sein, Bilddaten anzuhängen. Als Beispiele wurden genannt: Elektrophorese Kurven, Reiberdiagramm, Durchfluss-Cytometrie, Gelscans, Blotscans, Scattergramme. | Wir haben verstanden, dass eine ergänzende Abbildung zur Untersuchungsgruppe wichtige zusätzliche Informationen enthalten kann. Beispielsweise kann die Ausprägung einer Elektrophorese-Kurve hilfreiche und wichtige Zusatzinformationen zu einer Erkrankung geben, die durch die quantitativen Ergebniswerte allein nicht hinreichend erkennbar wären. In der Benehmensversion ist die Spezifikation dementsprechend erweitert. |
Eine vielfach genannte Anforderung: Bildanhänge zur einzelnen Laboruntersuchung ermöglichen Als Ergänzung zum Messergebnis muss es möglich sein, Bilddaten anzuhängen. Als Beispiele wurden genannt: Elektrophorese Kurven, Reiberdiagramm, Durchfluss-Cytometrie, Gelscans, Blotscans, Scattergramme. | Wir haben verstanden, dass eine ergänzende Abbildung zur Laboruntersuchung wichtige zusätzliche Informationen enthalten kann. Beispielsweise kann die Ausprägung einer Elektrophorese-Kurve hilfreiche und wichtige Zusatzinformationen zu einer Erkrankung geben, die durch einen quantitativen Ergebniswert allein nicht hinreichend erkennbar wären. In der Benehmensversion ist die Spezifikation dementsprechend erweitert. |
Kontroverse Diskussion um die Erzeugung einer UUID für den Laborbefund Contra: Dies könnte eine Hürde für die Umsetzung des Profils darstellen, da ggf. in manchen sendenden Systemen eine Änderung im Datenmodell nötig ist, um die UUID persistent zu speichern. Es gibt andere Wege als eine UUID um eine weltweite Eindeutigkeit des Laborbefunds zu gewährleisten. Pro: Wichtig ist ein bundesweit einheitliches System, das ggf. auch EU-konform ist (EHDS). In mehreren Vorgesprächen in den verschiedenen Arbeitsgruppen wurde die UUID als die geeignetste Möglichkeit herausgearbeitet. | Die UUID ist die gängige Art und Weise einen global eindeutigen Identifier zu erzeugen. Sie ist auch EU-konform (EHDS, European Health Data Space). In Zusammenarbeit mit dem Beirat (AG Fachgremien Labor) wurde die UUID als das am besten geeignete System für ein bundesweit einheitliches Verfahren konsentiert. |
Verschachtelung von Untersuchungsgruppen Sollte man nicht innerhalb ("hasMember") von Untersuchungsgruppen (kbv_pr_mio_lab_observation_laboratory_study_group) zusätzlich zu Untersuchungen (kbv_pr_mio_lab_observation_laboratory_study) auch weitere Untersuchungsgruppen haben, sodass man auch Unterüberschriften auf dem Laborbefund abbilden kann? | Die MIO-Spezifikation enthält keine Information zum Layout. Gruppierung und Sortierung sind technische, maschinenlesbare Zuordnungsmöglichkeiten, woraus ein Layout abgeleitet werden kann. Da es beim Laborbefund fachlich geboten ist, einzelne Laboruntersuchungen im fachlichen Kontext zusammenzufassen, wurde in Zusammenarbeit mit dem Beirat (AG Fachgremien Labor) die Gruppierung als einfaches Strukturierungsmittel abgestimmt, anhand dessen auch die Bewertung einer Gruppe von Untersuchungen möglich ist. Tiefere Verschachtelungen von Gruppierungen und Einzeluntersuchungen sind für das MIO nicht vorgesehen, würden die FHIR®-Umsetzung komplizierter machen und möglichweise an Akzeptanzgrenzen stoßen. |
Warum ist der Typ "valueString" als "value" für die "Observation" nicht erlaubt? Warum kann das Untersuchungsergebnis nicht als String angegeben werden? | Ergebnisse von Laboruntersuchungen sind strukturiert abgebildet, als quantitatives oder qualitatives Messergebnis. Das qualitative Messergebnis kann als Code oder als Freitext angegeben werden. Außerdem kann zur Untersuchung insgesamt ein Freitext mitgegeben werden. |
Richtgrenzen: Obere/Untere Referenzgrenze Verstehe ich das richtig, dass jeweils nur eine Referenzgrenze angegeben werden muss? | Ja, das ist korrekt verstanden. Mindestens eine der Referenzgrenzen muss vorhanden sein, entweder die obere oder die untere. Beide zusammen können ebenso vorhanden sein. |
Kontroverse Diskussion, ob der zlog-Wert Teil des Laborbefundes sein soll Contra: Der zlog-Wert ist lediglich eine alternative Darstellungsform eines numerischen Ergebniswertes und könnte weggelassen werden bzw. bei Bedarf im empfangenden System jederzeit berechnet werden. PRO: Die Rili-BÄK erlaubt anstelle einer Referenzgrenze auch eine Entscheidungsgrenze, die nicht für die Berechnung des zlog-Werts durch den Empfänger herangezogen werden darf. Der zlog-Wert steht in der Verantwortung des befundenden Laboratoriums. | Die Option für das Datenelement zlog-Wert wurde in Abstimmung mit dem Beirat zum MIO Laborbefund (AG Fachgremien Labor) als nützliches Konzept in das Informationsmodell aufgenommen. Auch im Beirat gab es heterogene Positionen dazu. Als konsentiertes Arbeitsergebnis des Beirates bleibt diese Struktur bestehen. |
Beschreibung zum zlog-Wert Bitte hier ergänzen: ...Relativwert, der auf einer logarithmischen Skala angibt, um wie viele Standardabweichungen ... | Wir haben die Beschreibung dahingehend ergänzt, sodass es in der Benehmensversion des MIO enthalten ist. |
| UDI im Sinne des Patientenschutzes dringend erforderlich: Die Mitgabe der UDI dient wesentlich zur Vermeidung von Verwechslungen bei Kumulativ- bzw. Verlaufsdarstellungen von Laborbefunden. | Die Vergleichbarkeit von Laboruntersuchungen ergibt sich primär aus dem LOINC®-Code. Zusätzlich gibt die UDI als Identifikator für das Messgerät/Diagnostikum auch einen Hinweis auf die Messmethode und kann so bei LOINC-Codes, welche die Methode nicht ausreichend eindeutig identifizieren, zur Genauigkeit beitragen. Ebenfalls zu berücksichtigen wären auch die ergänzenden Spezifizierungen für Untersuchungsmethode und Probenart. Ergänzung zur bereits veröffentlichten Antwort: Im Rahmen weiterer Kommentarbearbeitungen wurde im Beirat konsentiert, das Datenelement GTIN-Code zur Struktur Laboruntersuchung hinzuzufügen. Die Beschreibung enthält: "Verwendung im Kontext Laborbefund: für die Darstellung von Laboruntersuchungen kann die GTIN herangezogen werden, um die Vergleichbarkeit von Tests zu validieren. Mit der GTIN (kurz für Global Trade Item Number) kann jeder Artikel, jedes Produkt oder jede Produktvariante weltweit überschneidungsfrei identifiziert werden. Sie fungiert als Zugriffsschlüssel auf in Datenbanken hinterlegte Produktinformationen. Die GTIN ist gleichzeitig die Basis für den Barcode (auch bekannt als Strichcode). Über den Barcode wird sie maschinenlesbar und kann per Scanner automatisch ausgelesen werden. Die GTIN ist Teil der UDI-DI ..." Operationalisierungshinweis dazu: "Labore haben die Option, zusätzlich zur Spezifikation der Laboruntersuchung eine GTIN mitzugeben. Es wird das Vorgehen nach folgenden Regeln empfohlen:
|
| 2.3 Behandelnde Person/Einrichtung/Rolle→ 2.3.3.1.1 KBV-Fachgruppencodierung Frage: Wie wird die Codierung bei Mehrfachqualifikation oder Zusatzbezeichnungen gelöst, z. B. Labormedizin und Mikrobiologie? | Für "Behandelnde Person/Einrichtung/Rolle gelten die Kardinaltiäten: Fachrichtung - Code/Bezeichnung 0..* (-> KBV-Fachgruppencodierung 0..1). Das bedeutet, dass die Struktur Fachrichtung - Code/Bezeichnung je Person/Einrichtung/Rolle mehrfach vergeben werden kann bzw. darf, sodass Mehrfachqualifikationen damit abgedeckt sind. |
| Die angedachte Sortiernummer für die Untersuchungsgruppe soll sicherstellen, dass der Laborbefund auf allen Ebenen (Befund im KIS, Befund im AIS, Befund im Patientenendgerät) zu einer identischen und damit schnell begreif- und überschaubaren Darstellung kommt. Die angedachte Sortiernummer wird vom gebenden Laboratorium vermittelt, sollte aber hilfsweise verknüpft mit den LOINC-Codes auch über eine seitens BfArM verfügbare Mastersortierung (Befunddruckreihenfolge) verfügbar sein. | Falls das BfArM als Standardisierungsorganisation eine LOINC®-orientierte "Master-Sortierung" bzw. "Master-Reihenfolge" für Laboruntersuchungsgruppen veröffentlichen würde, könnten verarbeitende Systeme aus dem LOINC®-Code die darzustellende Sortierung ableiten. An der Spezifikation für das MIO Laborbefund würde sich dadurch nichts ändern. Eine solche Vorgabe könnte als Operationalisierungshinweis aufgenommen werden. |
| Beim LDT hat man sich zum Status des Ergebnisses auf eine Vielzahl von zu unterscheidenden Status geeinigt. Wo findet man die Entsprechung im MIO? | Im MIO gibt es Status Laboruntersuchung. Der Wert für den Status ist ein Code, das ValueSet orientiert sich an FHIR® und enthält die unter dem Confluence-Link hinterlegten Codes aus der Werteliste "Status Laboruntersuchung":
|
| Um es den empfangenden Systemen zu ermöglichen, den jeweiligen Normalwert korrekt zu interpretieren, wurde im LDT die FK 8424 "Normalwertspezifikation" aufgenommen. Wo findet man die Entsprechung im MIO? | Da für die LDT-Feldkennung 8424 zwei unterschiedliche Begriffe/Dimensionen als Inhalt infrage kommen, mussten dazu im MIO zwei Felder entstehen:
Sie sind jeweils als Freitext einzugeben, da noch nicht auf gültige Code-Standards zurückgegriffen werden kann. Im Informationsmodell ist dargestellt, welche Inhaltswerte aus der LDT3-Spezifkation FK 8424 hierzu passen könnten:
2. Quellen für Richtgrenzen
Im MIO können in den beiden Freitextfeldern auch Inhalte eingegeben werden, die über die beiden Beispiel-Listen aus dem LDT hinausgehen. |
| Die aktuelle Beschreibung auf den veröffentlichten Seiten zum MIO Laborbefund vermischt die Begriffe Daten und Befunde. | Das MIO Laborbefund entspricht dem Dokument, welches den abschließenden Befundbericht enthält, also inklusive der ärztlichen Interpretationen zu einzelnen Untersuchungsergebnissen und der abschließenden ärztlichen Beurteilung. In diesem Sinne haben wir den Text der Hintergrundinformationen noch einmal überprüft und korrigiert. |
Wichtig ist jetzt schon die Berücksichtigung des GenDG und ggf. anderer Befunde, die besonderen Einschränkungen unterliegen (vgl. z. B. die nicht-namentlichen Meldungen des IFSG). Hierzu muss klar definiert sein, was ein genetischer Befund ist und wie mit den genetischen Befunden umgegangen wird. | Wenn wir die Modellierung des genetischen Laborbefundes in Arbeit nehmen werden, sind Genetik-ExpertInnen im Beirat willkommen. |
| Bei genetischen Befunden muss die Einwilligung, Widerruf der Einwilligung, Begrenzung der Empfänger und die fristgemäße Löschung abgebildet werden. | Die ePA ist eine patientengeführte Akte. Und der/die PatientIn entscheidet, wer die Daten sehen bzw. bearbeiten darf und was gelöscht werden soll |
| Der Datenfluss des Laborbefunds ist nicht klar. Kann ein Labor selbst einen Laborbefund in der ePA ablegen oder geht das immer über den Hausarzt? Kann das Labor auch lesend zugreifen? Ist ggf. sogar vorgesehen, Daten aus der ePA dem Labor zur Verfügung zu stellen (z. B. für Vorwertbetrachtungen) | Die Zustellung eines MIO Laborbefund kann auf diesen Wegen erfolgen: Jede mitbehandelnde bzw. diagnostizierende Einrichtung sollte abhängig von der erteilten Berechtigung Lesezugriff bekommen können. |
| Es wurde gesagt, dass mit der MIO-Spezifikation keine Darstellung vorgegeben wird. In der Spezifikation tauchen aber Elemente auf, die nur die Darstellung betreffen, zum Beispiel Sortiernummern. | Sortiernummern sind technische Zuordnungen, essenziell für fachliche Gruppierungen, falls solche benötigt werden. Das legt noch nicht die Form der Darstellung fest, sondern schafft die maschinenlesbare Zuordnungsmöglichkeit. |
| Es wird LOINC verwendet. Zusätzlich besteht aber die Möglichkeit, eine Messmethode oder eine Probenart anzugeben. Diese Information ist doch regelmäßig in LOINC schon enthalten. | Für den Fall, dass die LOINC®-Codierung nicht präzise genug ist, wurde aus Fachkreisen (AG Fachgremien Labor) gefordert eine ergänzende Spezifizierung anzubieten. Beispielsweise könnte der Wert der LOINC®-Achsen METHOD (Untersuchungsmethode) oder SYSTEM (Probenart) als nicht ausreichend spezifisch erachtet werden oder für die Methode gar nicht vorhanden sein. Im Informationsmodell wurden deshalb diese Optionen für eine ergänzende Spezifizierung geschaffen:
Ergänzung zur bereits veröffentlichten Antwort: Zum Datenelement Laboruntersuchung LOINC®-Code 1..1M wurde als Vorgabe formuliert: "Nach Möglichkeit soll die Laboruntersuchung mit dem LOINC®-Code präzise spezifiziert sein, so dass auf ergänzende Spezifizierungen verzichtet werden kann." |
| Besitzen Geräte Lot-Nummern oder bezieht sich diese Angabe nur auf Verbrauchsmaterialien? | Die Lot-Nummer kann ein Bestandteil der UDI-PI und somit ggf. auch für Geräte notwendig sein. |
| Wozu ist für die behandelnde Person ein "Administratives Geschlecht" erforderlich? Wäre die Anrede besser geeignet? | Es entspricht dem Konzept der KBV-Basis-Profile und auch der FHIR®-Struktur, zu Personen das administrative Geschlecht mitzuführen. Eine Anrede würde vom Anwendungsprogramm anhand des administrativen Geschlechtes abgeleitet und ist nicht Teil der Datenstruktur. Das Geschlecht einer behandelnden Person kann medizinisch relevant sein, die Angabe ist optional. Ob das administrative Geschlecht übermittelt wird, obliegt dem sendenden System und das empfangende System muss es auswerten können. |
| Den kompletten Namen mit allen Vor- Zusatzworten usw. in der korrekten Reihenfolge auszugeben ist schwierig. Die eGK macht Vorgaben, aber der MIO-Laborbefund soll ja nicht "künstlich" auf GKV/eGK-Fälle beschränkt sein, sondern universell alle Laborbefunde in allen Zusammenhängen abbilden können. | Die Zusätze zum Namen sind optional. Das stellt lediglich eine Möglichkeit dar, solche Informationen mitzugeben, falls sie vorhanden sind. Die Reihenfolge ist durch das MIO nicht festgelegt. Das wird vom verwendenden System vorgegeben. |
| Kontaktdaten Patient / Kontaktkanal Code: In der Auswahlliste für den Code gibt es "Pager". Die Auswahlmöglichkeit Pager ist hier unnötig. Pager ist kein relevantes Kommunikationsmedium mehr. | Die Datenstruktur "Kontaktkanal" wurde von Basisprofilen abgeleitet. Es gibt diesbezüglich noch Schnittstellen, bei denen der Pager theoretisch vorkommen kann. Langfristig ist davon auszugehen, dass die Angabe "Pager" nicht mehr benötigt wird. |
| Behandelnde Person / Kontaktkanal Code: In der Auswahlliste für den Code gibt es "Pager". Die Auswahlmöglichkeit Pager ist hier unnötig. Pager ist kein relevantes Kommunikationsmedium mehr. | Die Datenstruktur "Kontaktkanal" wurde von Basisprofilen abgeleitet. Es gibt diesbezüglich noch Schnittstellen, bei denen der Pager theoretisch vorkommen kann. Langfristig ist davon auszugehen, dass die Angabe "Pager" nicht mehr benötigt wird. |
Behandelnde Person / Kontaktkanal Telefon Einrichtung / Kontaktkanal Telefon Der Kontaktkanal Telefon weist hier nur die Kardinalität 1..1 auf. Es ist aber durchaus relevant mehrere Telefonnummern angeben zu können. | Hier liegt ein Missverständnis vor. Die Strukturebene eine Ebene höher "Kontaktdaten" hat die Kardinalität 0..*. So kann der Kontaktkanal vom Typ Telefon mehrfach angelegt werden. |
Behandelnde Person / Rolle in Bezug auf die Einrichtung / Code In der Auflistung fehlt die Möglichkeit die Rolle Facharzt/Fachärztin auszuwählen. Der Begriff Assistenzarzt/ärztin gibt veraltete Rollenbilder wieder. Es sollte auch Codes geben für Abteilungsleitung / Bereichsleitung, gerade im Hinblick auf die teilweise geforderte Spezialisierung. | Wir unterscheiden die "Rolle" und die "Qualifikation". Facharzt/Fachärztin ist eine Qualifikation für ein Gebiet. Die finden Sie unter Behandelnde Person / Fachrichtung - Code und dort eine Code-Auswahl, die sich an den ärztlichen Fachgruppen der KBV orientiert, z. B. von "Allgemeinmedizin" bis "Viszeralchirurgie", darin enthalten auch "Arzt/Ärztin ohne Facharzt-Weiterbildung". Unter Behandelnde Person / Rolle in Bezug auf die Einrichtung / Code wird angegeben, in welcher Funktion, Auftrag, Rolle ein/e Arzt/Ärztin innerhalb der Einrichtung aktiv ist. Das kann für die ärztlichen Rollen beispielsweise sein: Ärztin/Arzt in Weiterbildung, Assistenzärztin/-arzt, Stationsärztin/-arzt, Oberärztin/-arzt, Leitende(r) Oberärztin/-arzt, Chefärztin/-arzt, Belegärztin/-arzt usw. |
Behandelnde Person / Vorname Vorname und Nachname der behandelnden Person sollten Pflichtangaben sein. Ein Großlabor bspw. dürfte mehrere Ärzt:innen als Zuweiser von Proben haben, die den gleichen Nachnamen teilen. Die kompletten Daten sind ja im LIS vorhanden. | Es ist heute üblich, maschinell erstellte (Labor-)Befunde zu versenden, die nur mit einem Nachnamen und Datum freigegeben wurden. Die Identifikation der behandelnden Person ergibt sich nicht nur aus dem Namen, sondern auch durch die Angabe der Einrichtung / Praxis, Adresse, Kontext (Einsender:in, Empfänger:in, Labormediziner:in) und weitere Parameter. In diesem Sinne beschreibt es auch der Abschnitt 6.3.2 in der Richtlinie der Bundesärztekammer zur Qualitätssicherung Wenn aus administrativen Gründen z. B. Vermeidung von Verwechslung bei gleichen Nachnamen der Vorname benötigt wird, besteht grundsätzlich die Option, den Vornamen mitzugeben. Das MIO Laborbefund als übermittelter Befundbericht enthält (anteilig) Daten aus dem LIS, aber niemals die kompletten LIS-Daten. |
| Hebammen nehmen im Rahmen ihrer Arbeit Proben und geben Laborbefunde in Auftrag. Es muss sichergestellt werden, dass Hebammen in vollem Umfang das MIO Laborbefund nutzen können und dass es keine Pflichtfelder gibt, die von Hebammen nicht ausgefüllt werden können. | Die Angabe der Identifikatoren zur behandelnden Person oder zur Einrichtung/Institution sind optional. Es gibt hier keine Pflichtvorgaben, die Hebammen nicht ausfüllen könnten. Und falls eine Hebammen-IK eingetragen werden soll, wäre die IK für die Einrichtung zu verwenden. |
| Im Abschnitt "Behandelnde Person" wird von ärztlichen und nicht-ärztlichen Personen gesprochen, an anderen Stellen wird ausschließlich von ärztlichen Personen gesprochen. Diese Stellen müssen angepasst werden. | Wir haben die zu ändernden Stellen im entsprechenden Abschnitt unter Übersicht Laborbefund angepasst und verwenden nun ausschließlich den Begriff "Behandelnde Personen". |
Codierung
| Kommentarthema | Ergebnis |
|---|---|
Code Laboruntersuchung (LOINC®) und Long Common Name Die Langbezeichnung (Long Common Name) ist eine ist redundante Information zum LOINC®, der Kode an sich ist ausreichend. Problem: Datenbank-Feld im LIS fehlt oder hat unzureichende Länge, und muss mit jeder LOINC®-Release geprüft/gepflegt werden, meist manuell. | Im Informationsmodell ist das redundant dargestellte Element "Long Common Name" in der Benehmensversion entfernt. Es gilt aber zu beachten, dass das Element Code im Informationsmodell generell die FHIR®-Daten-Struktur "coding" repräsentiert, die sich aus folgenden Pflichtangaben zusammensetzt:
Darin enthalten ist die Pflichtangabe für den Anzeigenamen. Das gilt so für alle MIOs. Es gilt für LOINC®, dass als Anzeigename der Long Common Name (LCN) mitgegeben werden soll. Dies ist Standard-Vorgehen in FHIR® Spezifikationen. Der LOINC®-Katalog wurde noch nicht vollständig ins Deutsche übersetzt. Wir empfehlen als Anzeigenamen, sofern vorhanden, den deutschen Anzeigenamen aus der LOINC® Linguistic Variants DE (enthalten in den Accesory-Files der LOINC®-Version) zu verwenden. |
Qualitatives Messergebnis: Aktuell ist es gemäß Vorgabe erlaubt, dass zu einem Messwert mehr als eine Codierung geben kann: Welche fachliche Motivation steht hinter der Möglichkeit zu einem Wert multiple Codierungen zuzulassen? | Die fachliche Motivation zu einem Wert multiple Codierungen zuzulassen rührt daher, dass unterschiedliche Terminologien (LOINC®, SNOMED CT®) im Umlauf sind. Diese Terminologien haben durchaus Überschneidungen, sodass mehr als ein Code für eine Beobachtung denkbar ist. Das Risiko widersprüchlicher Code-Eingaben besteht, jedoch ist hier das sendende System in der Verantwortung, inhaltlich korrekte Codierungen zu senden. Sie haben die Struktur für das qualitative Messergebnis kommentiert. Im Rahmen der Kommentarnachbereitung sind wir zu einer anderen Schlussfolgerung gekommen, als bereits veröffentlicht, wo wir für die Codierung eines qualitativen Ergebnisses der Eingrenzung auf SNOMED zugestimmt hatten. Stand heute steht für ValueSets zu einem qualitativen Ergebnis (noch) kein allgemeingültiger Standard zur Verfügung. Um auch EU-weit die Interoperabilität zu gewährleisten, können wir derzeit kein Codesystem ausschließen. Im Rahmen der EU-weiten Erarbeitung von MVC (master value catalogues) könnte sich in der Zukunft eine Eingrenzung ergeben. Bis dahin schränken wir das Codesystem nicht ein, um die Interoperabilität nicht zu gefährden. Es kann u.a. über ein offenes Slicing abgebildet werden. |
MIO-Spezifische Operationalisierungshinweise, betrifft
Bitte als "deprecated" markieren, die Freitextfelder und alternativen Codierungen sollten auf Dauer entfallen. | In der Benehmensversion ist bei den MIO-spezifischen Operationalisierungshinweisen der Abschnitt "Codes aus anderen Code-Systemen" entfernt. Auch wenn die Eingrenzung auf ein einziges Code-System das bevorzugte Vorgehen im Sinne einer widerspruchsfreien Interoperabilität ist, bleibt die Option "Code aus anderem Code-System" als grundsätzliche Möglichkeit für die Modellierung der MIOs bestehen. Deshalb gibt es unter Übergreifende Operationalisierungshinweise eine Erläuterung dazu. |
| Codierung der Länderkennzeichen nach ISO 3166 | Die Form der Codierung resultiert aus Verträgen mit dem Spitzenverband der gesetzlichen Krankenkassen (GKV-SV). Dieser bestimmt zur Zeit, dass hier die "Datenerfassungs- und übermittlungs-Verordnung (DEÜV)" genutzt werden soll. Das bedeutet, diese Codierung muss im Feld genutzt werden. Zusatz für Ticket 152: Die Werte in dieser Anlage orientieren sich an der Staats- und Gebietssystematik des Statistischen Bundesamtes. Die Staatsangehörigkeitsschlüssel (SASC) entsprechen dem Destatis-BEV-Code. Die Länderkennzeichen (LDKZ) werden bei Änderungen weiter an die Ländercodierliste gemäß ISO 3166-1 angeglichen. |
| Wieso gibt es für das Geschlecht zwei unterschiedliche Code-Systeme http://fhir.de/CodeSystem/gender-amtlich-de und http://hl7.org/fhir/administrative-gender? Muss das Geschlecht je nach Kontext anders codiert werden oder ist das ein Irrtum? | Die Codierung variiert nicht abhängig vom Kontext und es liegt auch kein Irrtum vor. Das Basisprofil KBV_PR_Base_Patient (https://simplifier.net/base1x0/kbv_pr_base_patient) gibt vor, dass für "gender" das FHIR Code-System AdministrativeGender (mit den Werten male, female, unknown, other) zu verwenden ist. |
Kodierung DiagnosticReport.category als Laborkategorie Da es sich um einen Labor-spezifische Untersuchung handelt, sollte diese entsprechend per Observation.category gekennzeichnet werden. | Aus Gründen umfassender terminologischer Abstimmungen wurde der Laborgesamtbefund (Diagnostic Report) - anders als in der Teilveröffentlichung 1 formuliert - mit einem fixen LOINC-Code 11502-2 Laboratory report assoziiert. |
Das Element Observation.category:testPanel enthält kein ValueSet Binding. Die Einschränkung auf LOINC® in .system ist hier zu grob. Bitte ValueSet mit Code Einschränkungen spezifizieren (mindestens als Example Binding) | Wir planen der observation.category ein implizites ValueSet mit LOINC®-Codes hinzuzufügen. So könnte die Auswahlmöglichkeit auf ca. 1.400 Panel-Codes reduziert werden. Für konkrete Auswahlmöglichkeiten an Panel-Codes die im deutschsprachigen Raum verwendet werden, stehen wir über das BfArM mit der KKG LOINC® in Kontakt. |
Kein SNOMED Interpretation ValueSet vorgegeben. Der Snomed-Interpretation sollte ein ValueSet Binding hinzugefügt werden. Ohne bleibt unklar, worauf sich der Code beziehen soll. Ein ValueSet könnte z.B. Filter mit "alle Untercodes von X, Y, oder Z" enthalten da die Ausprägung sonst stark variieren könnte. | Über die genaue Abbildung einer Interpretation zugeordnet zu einem Wert besteht in Fachkreisen keine Einigkeit, weswegen wir für dieses Datenelement nach wie vor alle SNOMED CT®-Codes zulassen. Dennoch gibt es Hierarchien in SNOMED CT®, die sich anbieten. Wir haben die Unterkonzepte von 442499005 |Interpretation value (qualifier value)| mit Example-Binding hinterlegt, um eine geeignete Hierarchie für Anwender bereitzustellen. Das Datenelement Interpretation lässt grundsätzlich zwei Code-Systeme zu , das ValueSet http://hl7.org/fhir/R4/valueset-observation-interpretation.html käme auch in Frage. |
| Wie soll mit Werten umgegangen werden, für die kein LOINC® Mapping existiert? | Es gibt den Operationalisierungshinweis zum Element "Code Laboruntersuchung (LOINC®): Falls gar kein Code zur Laboruntersuchung ermittelt werden kann, wäre ersatzweise diese Mindest-Codierung möglich: " LOINC: 30954-2 Relevant diagnostic tests/laboratory data Narrative". Die Konkretisierung der Aussage eines wäre dann über die angebotenen Freitexteingaben vorzunehmen. |
Kodierung DiagnosticReport.code als Laborbefund Eine einheitliche Kodierung (bei gleichen Inhalten) des MIOs Laborbefund und eHDSI-LaboratoryReportType unterstützt die Zuordnung von Dokumenten für den europäischen Datenaustausch. Im eHDSI Kontext wird hingegen folgender Kode verwendet: Kodiersystem: LOINC®, 2.59, Kode: 11502-2, Bezeichnung im Kodiersystem: Laboratory report. | Wir danken für den Hinweis und haben unter KBV_PR_MIO_LAB_DiagnosticReport_Laboratory_Result.code.coding den LOINC-Code 11502-2 laboratory report hinzugefügt um den Austausch im europäischen Kontext zu erleichtern. |
Technische Repräsentation
| Kommentarthema | Ergebnis |
|---|---|
| Sollten die Spezifikationen im Sinne der Interoperabilität nicht eher offen gehalten werden? | FHIR bietet eine gute semantische Definition vieler Elemente, jedoch sind diese nicht immer eindeutig. Z. B. durch die Verwendung zusätzlicher Freitexte oder optionaler ValueSets, die durch eigene ValueSets ersetzt werden können, kann die Interoperabilität nicht durchgehend gewährleistet werden. Wenn man solche Elemente einfach in ihrer Grundkardinalität belassen würde, dann könnten diese in nicht eindeutig definierter Art und Weise befüllt werden. Auch wenn diese Informationen für die Schnittstelle nicht direkt erforderlich sind, also nicht mit dem Must-Support gekennzeichnet sind, könnten für den Sendenden wichtige Informationen an den Empfänger übertragen werden, ohne dass diese adäquat behandelt werden, da Sender und Empfänger leicht unterschiedliche semantische Einschätzungen von dem gleichen Element haben. Weiterhin könnten für den Empfangenden völlig unverständliche Codes transferiert werden. Dies kann absichtlich oder auch unabsichtlich sein. |
Aufbau der Extensions Die Extensions für deutsche Anzeigenamen sollten entfernt werden. | Die Extensions für deutsche Anzeigenamen sind in der Benehmensversion entfernt. Die deutschen Anzeigenamen werden nun gebündelt in einer großen ConceptMap bereitgestellt. |
| Kardinalität von KBV_PR_MIO_LAB_Specimen.container sollte von 0..1 zu 0..* geändert werden | Die Struktur des Containers und die Kardinalität ist in der Benehmensversion angepasst. Anstatt des Freitextfeldes wird der Container nun strukturiert dargestellt. |
| Das Slice KBV_PR_MIO_LAB_Observation_Laboratory_Study_Group.code.coding:iheCode sollte umbenannt werden | Das Slicing ist in der Benehmensversion von "iheCode" in "loincCodeAusIhe" umbenannt. |
| KBV_PR_MIO_LAB_Observation_Laboratory_Study_Group.interpretation.coding:hl7Interpretation.system enthält kein fixedValue und kein ValueSet-Binding | Im Element KBV_PR_MIO_LAB_Observation_Laboratory_Study_Group.interpretation.coding:hl7Interpretation.system ist das Code-System als Pattern hinterlegt. |
| Warum werden die Spezifikationen im XML-Format veröffentlicht? | Die ePA unterstützt nur FHIR-XML-Dateien. Zudem setzen alle anderen FHIR-Schnittstellen der KBV (inkl. eAU und eRezept) auch auf XML. Aus Konsistenzgründen wurde für die MIOs daher auch XML als Format festgelegt. Bei Bedarf können öffentlich zugängliche Konvertierungstools genutzt werden, um die Spezifikationen in JSON umzuwandeln. |
| Ergänzung von Kodierhinweisen und Operationalisierungshinweisen auf Simplifier | Da Operationalisierungshinweise häufig auch nach der Festlegung eines MIO ergänzt werden, können sie nicht in die FHIR-Spezifikation integriert werden, da die Spezifikation sonst regelmäßig aktualisiert werden müsste. Wir arbeiten daran, künftig andere Darstellungen von Operationalisierungshinweisen auf Simplifier zu ermöglichen. |
Operationalisierung
| Kommentarthema | Ergebnis |
|---|---|
"Non-KBV-LANR" Fehlende Klarheit, wie Validierung der ANR erfolgt, z. B. im KH-Bereich sind LANR vom Typ "5555..." als Pseudo-LANR für Ambulante spezialfachärztliche Versorgung (ASV) üblich, bei Zahnärzten anderes Format, usw. | Die ANR dient der Identifikation der behandelnden Person. Im Feld ANR werden nur Arztnummern übertragen, die dieser Zweckbestimmung dienen. Diese ANR wird in FHIR auf strukturelle Integrität (Format) geprüft. Ob die ANR eine gültige Nummer z.B. im Sinne der Arztnummernrichtlinie (https://www.kbv.de/media/sp/Arztnummern_Richtlinie.pdf) ist, muss das Primärsystem prüfen. Die sog. Pseudo-ANR bzw. Pseudo-Arztnummern sind kein Identifikator für die behandelnde Person. Sie sind nicht eindeutig für eine Person sondern beziehen sich auf eine Personengruppe mit derselben ASV-Nr. oder Fachgruppen-Nr. und werden zumeist im Abrechnungskontext verwendet. Pseudonummern sollen aus diesen Gründen nicht im ANR Feld der im MIO aufgeführten Behandelnden Person übertragen werden. Innerhalb des MIO Laborbefund ist der Identifikator der behandelnden Person keine verpflichtende Angabe. |
| Auftragsdaten-Dringlichkeit: wie werden die vier Dringlichkeitsstufen aus http://hl7.org/fhir/request-priority (Routine, Dringend, Baldmöglichst, Sofort/Notfall) auf die drei Stufen lt. LDT (Notfall/intraoperativ, Eilig, Routine) gemappt? | Der LDT3 sieht für eine gegebene Dringlichkeit zwei Status vor:
In HL7 FHIR RequestPriority gibt es 4 Status:
Für die Handhabung bei der Migration bzw. Umwandlung von LDT3 in das MIO-FHIR-Format empfehlen wir:
Die Vision, dass FHIR als einziges Format zum Einsatz kommt, beinhaltet auch, dass für die Dringlichkeitsstufen alle 4 Status angewendet werden. |
Eine Darstellung des Verlaufs bzw. eine Vergleichsmöglichkeit mit Vorwerten ist sehr sinnvoll und wird von Ärztinnen und Ärzten als wichtige Funktion eingeschätzt. Gleichwohl sollte sensibel überdacht werden, ob Gleiches wirklich mit Gleichem verglichen wird. Transparenz bezüglich unterschiedlicher Quellen oder Reagenzien ist geboten, auch im Hinblick auf den Patientenschutz. | Das MIO Laborbefund bildet selbst keinen Prozess ab und ist das Befunddokument als Ergebnis des Prozesses von einer Laborbeauftragung über die Labordiagnostik bis hin zu einer Ergebnisbewertung. Die Datenstruktur des MIO Laborbefund kann grundsätzlich sowohl Ergebnisse zu unterschiedlichen Laboruntersuchungen am selben Zeitpunkt als auch Ergebnisse zur selben Laboruntersuchung an unterschiedlichen Zeitpunkten enthalten. Daraus ergeben sich als Darstellungsoptionen im Primärsystem:
Beide Darstellungsformen werden im klinischen Alltag benötigt und entsprechen verschiedenen Nutzungsszenarien. Es obliegt den Primärsystemen in Kliniken und Praxen, eine benutzergerechte Aufbereitung von Laborergebnissen vorzuhalten. Diese Erläuterung ist in der Benehmensversion als Operationalisierungshinweis zum MIO Laborbefund enthalten. |
| In der Klinik werden Laborbefunde zu 98% kumulativ gelesen. Es gibt diesbezüglich Bedenken, dass sich zahlreiche Einzel-Laborbefunde in der ePA ansammeln, was zur Unübersichtlichkeit führen würde. | Während eines stationären Aufenthaltes ist davon auszugehen, dass es nicht unbedingt adäquat ist, jede Laborbefundung direkt in die ePA zu übertragen, sondern dass die Verlaufskontrolle für den stationären Aufenthalt - wie bisher - im Primärsystem, d. h. im KIS stattfindet. Das Nutzungsszenario ist so zu verstehen, dass zum Ende einer stationären Behandlung ein abschließender Laborbefund sinnvoll wäre, der ggf. zusammen mit einem KH-Entlassbrief ausgehändigt wird und dann in die ePA übertragen wird. |
Hinweis für Freitext-Datenfelder Gemäß § 363 SGB V können Patienten ihre Daten für eine Datenspende freigeben. Vor diesem Hintergrund sollte bei Freitextfeldern (String, Freitext) wie „Ergänzende Angaben", „Besonderheiten" oder „Hinweise" darauf hingewiesen werden, ggf. als Warnmeldung, dass keine Namen oder Daten hinterlegt werden sollten, die eine eindeutige Zuordnung zu einer Person ermöglichen (z. B. Patientenname, Versichertennummer). | Das ist eine sinnvolle Anmerkung. Wir haben den Sachverhalt auf die Webseite Übergreifende Operationalisierungshinweise aufgenommen, siehe "Hinweis für Freitextfelder bzgl. personenbezogener Daten" |
Übergreifendes
| Kommentarthema | Ergebnis |
|---|---|
| Vorschlag: Einführung MIO Laborbefund erst, wenn Hebammen an Telematikinfrastruktur (TI) angeschlossen sind | Laborergebnisse spielen eine wichtige Rolle bei der Diagnose, der Behandlung und der Nachsorge von Patient:innen. So ist in Bezug auf das MIO Laborbefund eine weitreichende fachübergreifende Verwendung für nahezu alle medizinischen Disziplinen sowohl im ambulanten Sektor als auch im klinischen stationären Bereich zu erwarten und sicherzustellen. Ideal wäre natürlich, wenn zum Start des MIO Laborbefund alle Beteiligten an die TI angebunden wären. Das sollte so zeitnah wie möglich erfolgen, um von sämtlichen Vorteilen, die ein solches MIO Laborbefund mit sich bringt, profitieren zu können. |
Relevanz Laborbericht für eine Unfallversicherung (UV) Im MIO fehlt die Möglichkeit, den Kostenträger als Empfänger zu adressieren. | Das MIO Laborbefund ist dafür konzipiert, den Inhalt des Laborbefundberichtes zu dokumentieren, aber nicht dafür vorgesehen, den Anforderungs- und Weiterleitungsprozess abzubilden. Die Prozesse werden in den Primärsystemen (LIS, KIS, PVS u. a.) dokumentiert. Das MIO Laborbefund enthält jegliche Möglichkeit, einen Empfänger als Person oder Einrichtung zu adressieren. Die Zustellung des MIO Laborbefund kann Ein eindeutiger Identifikator, wie z. B. das IK des jeweiligen UV-Trägers, sowie auch die Möglichkeit an geeigneter Stelle das Aktenzeichen des UV-Trägers zu hinterlegen, kann im Prozess erst über die Anforderung des UV-Trägers abgebildet werden, d. h., nachdem das MIO Laborbefund bereits erzeugt wurde. Das MIO selbst enthält diese Prozessinformation jedoch nicht. |
