On Sat, Jul 29, 2006 at 05:42:06PM +0200, Dr. Philipp Walderdorff wrote:

> Habe nun die Orientierung verloren und wei~ nicht recht, wer nun zust{ndig 
> ist 
> f}r die Ver|ffentlichung von Ideen zur OpenSource-Programmentwicklung f}r die 
> Allgemeinmedizin. Die Sache scheint sich doch schon ein wenig auszuweiten.
Resmed-de ist schon richtig.

> Bis jetzt konnte ich GNUmed noch nicht installieren. Da ich annehme, dass die 
> Leitlinien von R.N.Braun, Mader und Danninger als starre Abfrageliste 
> angeboten wird,
Es wird noch gar nicht angeboten. Und wenn, warum als starre Liste ??

> Die Eingabe der Beratungsursache und der diagnostische Weg zum 
> Beratungsergebnis ist unabhängig  von den diversen Forderungen der regionalen 
> Gesundheitssysteme und abgesehen von regionalen Schwerpunkten 
> (Tropenkrankheiten, Endemiegebiete usw.) ein Vorgehen, das wohl auf der 
> ganzen Welt gleich ist. Deshalb kann ein solches Programm weltweit Anwendung 
> finden.  Voraussetzung ist die plattformübergreifende Programmierung. 
Exakt deswegen konzentriert sich GNUmed vorerst noch nur auf
medizinische Dokumentation und ist plattformübergreifend
programmiert.

> Dieses Programm sollte von jedem der unzähligen Praxisprogramme aus einfach 
> und rasch gestartet werden können (Dazu ist nur eine Patienten-ID und ev. die 
> dazugehörigen Daten wie Alter und Geschlecht nötig).
GNUmed läßt sich auf mehrere Arten und Weisen von Praxis-EDV
aufrufen und mit einem Patienten versorgen. Hier
unterstützen wird u.a. die gängige BDT/GDT-Schnittstelle.

> Diagnostische Leitlinien für die Allgemeinmedizin am Papier gibt es seit 
> Jahrzehnten 
> (http://www.springer.com/dal/home/medicine?SGWID=1-10054-22-46624664-0&SHORTCUT=www.springer.com/sgw/cda/frontpage/0,11855,1-10054-22-46624664-0,00.html).
Ja, das habe ich auch.

> Habe geh|rt, dass GNUmed die Leitlinien von R.N.Braun ebenso schon zum Thema 
> gemacht hat,
Ja, zum Thema. Zum einbauen fehlen uns noch a) die
Entwickler, b) die lizenzrechtliche Genehmigung (allerdings
hat auch noch niemand nachgefragt).

> Die (vermutlich) neue Idee: 
> Um das Arzt-Patient-Gespräch möglichst wenig zu stören, sollte der Bildschirm 
> in Gesichtnähe des Patienten platziert sein (möglichst kleiner Blickwinkel 
> zw. Patient und Bildschirm) und Einhandbedienung mit der Maus, damit die 
> Sitzhaltung dem Patienten gegenüber offen sein kann, mit geöffneter 
> Armhaltung, was Offenheit signalisiert.
Mit anderen Worten, 50% der Ärzte müssen linkshändigen
Mausbetrieb lernen ?

> Die Eingabe der für die 
> leitliniengesteuerte Diagnostik nötigen Daten (BU mit allen Zusatzfragen) muß 
> sehr einfach gehen. Mit wenigen Mausklicken. Übersichtlichkeit am Bildschirm.
> Für den bestehenden Fall und für den bearbeitenden Arzt individuell 
> zusammengestellte Fragenkaskaden, gesteuert durch bestimmte Kriterien 
> (Beratungsursache, Risikofaktoren, Gefahrenmomente, 
> Befragungssensitivität=Zeit des Arztes,...usw).
Ein Open Source Projekt kann hier relativ einfach und in
guter technischer Qualität die Software bereitstellen. Das
Problem ist a) das Austüfteln der Oberfläche und b) das
Pflegen/Nachführen der Inhalte. Bei solchen Dingen mangelt
es oft an der Arbeitskräften.

> Das Programm sollte so gestaltet sein, dass ein normaler Anwender (Arzt) 
> selber Fragenkaskaden zu bestimmten Beratungsursachen vorbestimmen kann. Er 
> sollte die Steuerung des Programmablaufes durch Parameter zu den einzelnen 
> die Diagnostik steuernden Elementen (BU, einzelne Fragenkaskaden, allgemeine 
> Programmeinstellungen) selber bestimmen können.  
Ein Prototyp ist unter OpenSDE zu finden.

> Die Programmteile:
> 1. Die Eingabe der Beratungsursache
In GNUmed als ein eigenes Feld "Beratungsanlass" gelöst.

> 2.Der diagnostische Weg von der Beratungsursache zum Beratungsergebnis 
> (Leitliniengesteuerte Fragenkaskaden)
Dieses wäre Ihre Aufgabe :-)

> 3.Die übersichtliche Darstellung des Falles, ev. in Verbindung mit anderen 
> Fällen des selben Patienten.
Dieses leistet GNUmed schon ziemlich gut.

> 4.Ad 1. Die Beratungsursache:
> Hier fängt das Problem der Anwendbarkeit in der Allgemeinpraxis schon an. 
> Welcher Kollege 
> ist gewillt, bei der Masse an banalen Fällen jedes mal eine Beratungsursache 
> zu suchen und aus einer Liste auszuwählen?
In den banalen Fällen ist die Angabe des Patienten vorn an
der Anmeldung erstaunlich oft erstaunlich richtig. Freilich
nicht immer. Eine geschulte Anmeldungskraft kann daraus sehr
oft eine sinnvolle, ICPC-verschlüsselbare,
"Anmeldungsursache" erzeugen (die stimmt lange nicht immer
mit dem eigentlichen Problem überein).

> Definition: Die Beratungsursache (BU) ist der Grund des Kommens des 
> Patienten. 
> Es ist allerdings allgemeinmedizinisch wissenschaftlich noch nicht exakt 
> definiert, wie diese BU formuliert wird.
Es stellt sich jedoch vielmehr die Frage, ob es der Grund
des Kommens ist, den der *Patient* vermeint zu sehen, oder
der wirkliche, medizinische Grund, den ich erstmal
rauskriegen muß.

> Die eine Möglichkeit ist, ganau zu dokumentieren, was der Patient wörtlich 
> gesagt hat. Das ist im Praxisalltag nicht sinnvoll, kann aber  in 
> Einzelfällen (psychiatrische Anamnese, forensisch) von Wichtigkeit sein.
Es muß ja nicht *alles* wörtlich dokumentiert sein. Zu
unterscheiden wären: Anmeldungsangabe, wahre
Beratungsursache und Anamnese. Erstere sollte wörtlich
erfolgen, ggf mit Zusatznotiz. Dies steht dann meist in der
Wartezimmerliste der EDV. Die zweite kriege ich bei der
Anamnese (oder später) raus. In der Anamnese muß ich einiges
wörtlich dokumentieren, anderes nicht. Es gibt
orthografische und grammatikalische Konstrukte, die bei der
Differenzieren helfen (man denke an Kennzeichnung wörtlicher
Rede und den Konjunktiv).

Im Banalfall ist es einfach:

an der Rezeption: "schnief" (mancher sagt nicht mehr)
Wartezimmerliste: "Schnupfen"
BU-Zeile: "Schnupfen"
BE-Zeile: "Inf ob LW, eher viral"

Hier ist die einmalige Eingabe "Schnupfen" durch die
Anmeldung und die *Auswahl* von "Inf ob LW, eher viral"
durch der Arzt nötig. Die Auswahl entsteht durch BU-ICPC für
Schnupfen -> BE-ICPC -> ICD/Diagnosenliste.

> Es gibt viel zu viele Beratungsursachen, als dass man diese übersichtlich am 
> Bildschirm zur Auswahl anbieten könnte.  Die Idee zur Lösung des Problems: 
> Gliederung und Gruppierung der Beratungsursachen. Die Verknüpfung von 
> BU-Charakteristikum und Lokalisation reduziert die Möglichkeiten, die am 
> Bildschirm anzubieten sind, schon sehr.
Exakt dieses leistet ICPC.

Auch ein phrasewheel leistet gute Hilfe. Tippe ich "rück"
ein, werde mögliche "Rücken*"-problematiken angeboten.

> Beispiel: Ein Schmerzsymbol wird mit der Maus auf die kleine Zehe einer 
> Skizze 
> des menschlichen Körpers gelegt.
Dauert für mich länger als "Schmerz GZ l". Die Software kann
meinetwegen GZ in Großzehe übersetzen, weil ich immer GZ
statt Großzehe schreibe.

> In der Datenbank ???Homunkulus??? könnte eingetragen sein, dass am Endglied 
> der 
> kleinen Zehe  nur  vorkommen kann: Schmerz, Verletzung, Hautausschlag, 
> Nicht vorkommen kann dort: Angst, Erkältungssymptom, Schwitzen
Angst und Schwitzen wird sehr wohl vom Patienten an der
kleinen Zehe berichtet.

> Zwei mögliche Wege, wie dieser Vorgang abläuft:
> 1. "Was-Wo-SeitWann": Auswahl eines Symboles (Schmerz, Verletzung, 
> Hautausschlag,...) und                Bewegen auf die Lokalisation. Bedingt 
> durch 
> Symptomgruppe und Lokalisation wird nun die           detailiertere Auswahl 
> angeboten: 
>       Beim Schmerz die Schmerzcharkteristika (Brennen, Ziehen, Drücken, usw) 
>       Bei der Verletzung: Schnittwunde, Knochenbruch usw
>       Darauf folgt die Frage nach Dauer der Beschwerden, wobei eine 
> graphische 
>       Eingabemöglichkeit auch einen wechselnden Verlauf eintragen läßt. 
Dieses läuft in GNUmed über kontextsensitive
detail-spezifische Editoren. Wenn ich bei Anamnese eintippe
"Schmerz", dann kommt ein Editor für Charakter/Stärke/Zeit
(den ich durch <ESC> ignorieren kann).

Tippe ich in Therapie "Impf", dann kommt ein Editor zur
Eingabe einer Impfung.

> Was aber, wenn nicht nur eine einzige BU vorleigt? Mehrere Beratungsursachen 
> können zusammenhängen, oder getrennt zu sehen sein: Schnittwunde und 
> Erkältung, Kopfschmerz und Regelschmerz, Magenschmerz und Depression 
Diese sind ein GNUmed komplett und sauber trennbar und auch
getrennt als Fall über beliebige Zeiträume führbar. Dies
nennen wir "Episode". "Episoden" können im Rahmen von
"Grunderkrankungen" zusammengefasst werden.

> Ich habe seit Jahren eine solche Hilfssteuerung zu meiner Zufriedenheit in 
> Verwendung: Ich trachte, die Rückfragen durch den PC möglichst selten zu 
> machen. Beim Eintrag des Beratungsergebnisses gibt es die Möglichkeit, dass 
> das Programm durch Rückschau in der Datenbank wissen muß, ob dieses BE heuer 
> schon einmal da war. Aber es kann sich um eine Wiederholung der Erkrankung 
> handeln, oder nur um eine weiter Therapiekontrolle bei dem selben BE. Um 
> diese Rückfragen zu reduzieren habe ich in meiner BE-Tabelle drei Kennzeichen 
> vergeben: Diabetes Mellitus(Zuckerkrankheit) ist immer die selbe, bekommt 
> Kennzeichen 1.
Das wär dann bei uns eine "Grundkrankheit". Da kann es dann
eine Episode geben, die gerade läuft (weil der Zucker wegen
starker Hitze außer Kontrolle ist), oder eben keine, weil
der Zucker schon 6 Monate normal lief. Das wird einfach bei
der Anmeldung aus den vorhandenen Episoden gewählt: "Ach ja,
Sie kommen nochmal wegen des Zuckers oder geht es um etwas
anderes?"

> Die Hautwunde kann 
> mehrmals an verschiederner Stelle auftreten, hat die Kennzahl 2. Da muss 
> nachgefragt werden: MESSAGE "Hautwunde am 1.1.2006, ist diesmal die selbe 
> Wunde  J/N:?" Wenn "J", dann = Inanspruchnahme, Wenn "N", dann "Neuer Fall".
Dies würde eben die Anmeldung (oder ich) direkt durch wählen
des alten oder anlegen einer neuen Episode (Falls)
erledigen. Keine Rückfrage nötig.

> Leitlinien
>  Diese Tabelle steuert, was nun alles abgefragt werden soll.
> Sie enthält eine Liste von Fragen und Untersuchungen. Aber, die Liste wird 
> nicht Zeile für Zeile abgearbeitet, sondern die Fragen werden nach einem 
> Wichtigkeitsschlüssel aufgerufen. Also kommt die Frage, die den Höchsten 
> Wichtigkeitsschlüssel hat, als erste dran. Jede Frage wird nur einmal 
> gestellt. Welche Frage die nächste ist, entscheidet entweder die Folgefrage 
> im Fragenkatalog oder der Wichtigkeitsschlüssel. Auf diese (oder ähnliche) 
> Weise könnte die Befragung individuell gestaltbar gemacht werden.
Das Problem ist eben nicht die Programmierung dieser Dinge,
sondern das Erstellen der Inhalte.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
resmedicinae-deutsch mailing list
resmedicinae-deutsch@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resmedicinae-deutsch

Antwort per Email an