Stream: german/mi-initiative
Topic: Modul Fall - Diagnosereferenz verpflichtend
Joshua Wiedekopf (Jun 16 2020 at 07:58):
Guten Morgen aus Lübeck,
wir sind dabei, den Patientensimulator 'synthea' (https://github.com/synthetichealth/synthea) dahingehend anzupassen, dass auch FHIR-Ressourcen gemäß des aktuellen Arbeitsstandes für die Kerndatensatz-Module generiert werden können, die wir dann z.B. als Testgrundlage für die Einrichtung des SMICS im UC IC von HiGHmed einsetzen können.
Damit Synthea authentische, aber vollständig synthetische, Patientenakten generiert, verwendet die Applikation Module, die das Verhalten der simulierten Agenten beeinflussen. Natürlich sind diese Module stark auf den US-amerikanischen Markt zugeschnitten, sodass wir viele Eigenheiten des deutschen Gesundheitswesen und Anforderungen der Kerndatensatz-Module nur durch Mapping und Erweiterungsmodule abbilden können.
In meiner konkreten Frage geht es um den Versorgungsfall, in dem verpflichtend (1..1) eine Referenz auf eine Condition (Profil 'Diagnose') angegeben werden muss. In der simulierten Welt wird das sicherlich für stationäre Aufenthalte auch möglich sein, jedoch kann es auch vorkommen, dass ein Patienten-Agent bei einem niedergelassenen Arzt für sogenannte 'wellness encounter' (SNOMED CT: 185349003|Encounter for check up|) vorstellig wird. Bei gesunden Patienten können dann zwar Prozeduren (z.B. Blutpanels oder Impfungen) durchgeführt werden, aber eine Diagnose wird nicht immer gestellt werden können.
Ich stimme zu, dass in den meisten Fällen eine solche Angabe sehr wichtig und erforderlich ist. In einem solchen Fall finde ich die Abbildung jedoch schwierig. Möglichkeiten für die Abbildung, die ich sehe, sind a) eine Diagnose mit z.B. dem SNOMED-Code |160245001|No current problems or disability (situation)| und/oder ICD-10 |Z00.0|Ärztliche Allgemeinuntersuchung bei Personen ohne Beschwerden oder angegebene Diagnosen| anzulegen - dann sehe ich aber Probleme darin, das onset und den clinicalStatus dieser Diagnose zu bestimmen oder b) die Extension data-absent-reason wie oben beschrieben zu verwenden oder c) die Kardinalität von Encounter.diagnosis anzupassen. Welche Lösung würdet Ihr da bevorzugen?
Thomas Wendt (Jun 16 2020 at 11:53):
Wir hatten das Thema ja eben auch in der Projectathon-TelKo. Ich hatte auch dafür argumentiert, auf verpflichtende Angaben bzw. verpflichtende Referenzen von Diagnosen im Modul Fall zu verzichten. Aus meiner Sicht schaffen wir mit einer Pflicht zur Diagnoseangabe eine unnötige "Strenge", die ein schrittweises Vorgehen an den Standorten (ohne für mich erkennbaren Grund) erschwert. Das gilt insbesondere in solchen Integrationsszenarios, in denen Diagnosedaten erst nachträglich per P21-Export oder nur separat per BAR-Nachricht zur Verfügung stehen.
Welche in der MII relevanten Auswertungsfragestellungen können wir NICHT beantworten, wenn wir auf die Pflicht verzichten?
Thomas Wendt (Jun 16 2020 at 15:23):
Thomas Wendt said:
Wir hatten das Thema ja eben auch in der Projectathon-TelKo. Ich hatte auch dafür argumentiert, auf verpflichtende Angaben bzw. verpflichtende Referenzen von Diagnosen im Modul Fall zu verzichten. Aus meiner Sicht schaffen wir mit einer Pflicht zur Diagnoseangabe eine unnötige "Strenge", die ein schrittweises Vorgehen an den Standorten (ohne für mich erkennbaren Grund) erschwert. Das gilt insbesondere in solchen Integrationsszenarios, in denen Diagnosedaten erst nachträglich per P21-Export oder nur separat per BAR-Nachricht zur Verfügung stehen.
Welche in der MII relevanten Auswertungsfragestellungen können wir NICHT beantworten, wenn wir auf die Pflicht verzichten?
Hab ein Issue daraus gemacht.
Last updated: Apr 12 2022 at 19:14 UTC
