Da ich nun nicht recht wei~, wer f}r die Ver|ffentlichung von Prorgrammideen 
f}r GNUmed oder andere OpenSource-Programme f}r die Allgemeinmedizin 
zust{ndig ist, deponiere ich meine Gedanken dazu  an zwei stellen:
hier und bei [EMAIL PROTECTED]

================Die Programm-Skizze ===========================
Thema:
Dokumentation der Beratungsursache und leitlinienunterstützte Diagnostik 
in der Allgemeinmedizin (BuBe)

Einleitung:
Ein Programm bzw. ein Programm-Plug-In zur Dokumentation der Beratungsursache 
(BU) und zur leitlinienunterstützten Führung des Falles (Beratungsergebnis, 
BE).

Da ein Großteil der allgemeinmedizinischen Fälle ohne großen Aufwand zu führen 
sind, wird ein derartiges Programm nur in Einzelfällen wirklich gebraucht. 
Zu Dokumentationszwecken aus forensischer Sicht allerdings wäre ein solches 
Programm immer sinnvoll. 
Wenn die Anwendung sehr einfach und zweckmäßg ist, wird das Programm dann auch 
in weniger komplexen Fällen eine sinnvolle Hilfe sein. 

Begründung für die Verwendung dieses Programmes bei jeder einzelnen 
Inanspruchnahme:
Die Notwendigkeit der Verwendung dieser diagnostischen Hilfe wird meist erst 
im Laufe des Arzt-Patient-Gespräches bewußt. Deshalb, und weil die 
allgemeinmedizinische Alltagsarbeit aus vielen kleinen Einheiten besteht 
(Zeit für Diagnostik pro Fall: Sekunden bis Minuten) ist es sinnvoll bei 
jedem Fall die gleiche EDV-technische Arbeitsroutine anzuwenden. Ob das nun 
ein paar Mausklicks sind, oder eine komplexe diagnostische Abfrage und 
Befundeintragung, das stellt sich im Laufe der Diagnostik heraus. Dann ist es 
sinnvoll, wenn man diese diagnostische Hilfe bereits zur Hand hat und die 
ersten Eingaben schon gemacht hat. Deshalb wird ein solches Programm nur 
angenommen werden, wenn es in seiner Anwendung sehr variabel und einfach in 
der Anwendung ist. Das ist die große Herausforderung an das Programm. 

 Das Programm soll eine  fallorienterte, variabel gestaltbare Fragenkaskade 
(z.B.: (Husten)>(trocken/Auswurf)>(klar,gelbgrün,blutig) bereitstellen, die 
einerseits an "abwendbar gefährliche Verläufe" erinnert und andererseits eine 
Dokumentation der Anamnestik und der erhobenen Befunde ermöglicht.

Die Entwicklung eines Basis-Programmes zur Eingabe der Beratungsursache und 
leitlinienunterstützer Diagnostik einerseits und in weiterer Folge die 
Entwicklung der Datenstruktur der Leitlinien selber, ist ein sehr komplexes 
Geschen, an dem wohl viele Ärzte mitwirken werden müssen.

Deshalb habe ich an Open Source gedacht. 
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. 

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). Nur so ist es möglich, 
dass möglichst viele Anwender das Programm verwenden und an dessen 
Entwicklung aktiv mitwirken. 

Gibt es derartige Programme schon am Markt?
Leitlinien als fixer Programmablauf (Abfrageliste oder fixe Fragenkaskade) 
wurde durch Dr. Edinger schon vor Jahren versucht. Auch ich habe solche 
Versuche in meinem Praxisprogramm unternommen.
Das hat sich nicht bew{hrt. 

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).

Habe geh|rt, dass GNUmed die Leitlinien von R.N.Braun ebenso schon zum Thema 
gemacht hat, allerdings konnte ich das Programm bei mir noch nicht 
installieren.

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.  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). 
Nur wenn diese Fragenkaskaden ein absolutes Minimum an Aufwand für den Arzt 
bedeuten, wird sich das System durchsetzen! 
Ich denke z.B. an einen Dringlichkeitsschlüssel zu jeder Fragenkaskade: 
Fragenkaskaden mit Dringlichkeitsstufe 1 kommen immer, auch wenn der Arzt 
nicht viele Zeit hat. Fragenkaskaden mit Dringlichkeitsstufe 3 kommen nur, 
wenn der Arzt sich Zeit nehmen will, um genau zu befragen (Dieser Punkt 
bedarf sicherlich noch einiger Diskussion (forensich: wie genau muß ich 
untersuchen?).
 
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.  

Die Programmteile:
1. Die Eingabe der Beratungsursache
2.Der diagnostische Weg von der Beratungsursache zum Beratungsergebnis 
(Leitliniengesteuerte Fragenkaskaden)
3.Die übersichtliche Darstellung des Falles, ev. in Verbindung mit anderen 
Fällen des selben Patienten.

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? Der Aufwand ist viel zu groß für 
den fraglichen Vorteil bei der Masse an banalen Fällen.
Deshalb muss die Dokumentation der Symptome und Beschwerden sehr einfach 
gehen. Dies kann durch intelligente Einschränkung der in einer bestimmten 
Lokalisation in einer bestimmten Situation anzubietenden Beratungsursachen 
geschehen.

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.

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.

Die andere Idee: Die Beratungsursache ist ein vordefinierter Begriff, der, 
nachdem der Patient in seinen Worten sein Problem geschildert hat, sinngemäß 
vom Arzt ausgewählt wird. Ein derartig verstandener Beratungsursachenbegriff 
impliziert eine Deutung und Bewertung (auch schon in Hinblick auf mögliche 
diagnostische Schritte) der Patientenaussage durch den Arzt. 

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.             
Beispiel: Ein Schmerzsymbol wird mit der Maus auf die kleine Zehe einer Skizze 
des menschlichen Körpers gelegt. In diesem Beispiel gibt es nur mehr wenige 
Fragen, die zu klären wären und die das Programm anbieten muss. Anders sieht 
es bei komplexeren Problemen aus. Wie dies im Einzelnen zu verwirklichen sein 
wird, muss diskutiert werden. 
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
Der Beratungsanlass kann sein:
1.eine der häufigen Möglichkeiten (unvollständige Liste):
        lokal:  Schmerz, Verletzung, Hautausschlag,  Erkältungssynmptome,
        allgemein:      Müdigkeit, nicht klar definiertes Unwohlsein,  Angst, 
Depression, Schwitzen,                          Juckreiz, Haarausfall,  
2.eines von vielen seltenen bis sehr seltenen Symptomen

Das edv-technische Objekt “Beratungsursache” kann nun verschiedene 
Eigenschaften haben:
*  Lokalisation, 
*  genauere Beschreibung des Symptoms (Schmerzcharakteristika, Verletzungsart, 
Beschreibung des                Hautausschlages, usw)
* Zeitangabe
  
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. 
2."Wo-Was-SeitWann": Der Beginn mit der Lokalisation durch Klick auf eine 
        Stelle am Körper: Lokalisationsabhängig wird nun das "Was" angeboten, 
gefolgt 
        von der Zeitabfrage.

Abhängig von dieser Eintragung kann nun die weitere Befragung standardisiert 
(durch Leitlinien unterstützt) ablaufen (siehe Punkt 2). Das Endergebnis 
dierser Befragung und Untersuchung ist dann das “Beratungsergebnis” (BE).

Ad 2. Der diagnostische Weg von der Beratungsursache zum Beratungsergebnis 
(Leitliniengesteuerte Fragenkaskaden):

Die auf die oben beschreibenen Weise gefundene Beratungsursache  löst  dann 
bei Bedarf die weiterführenden Fragenkaskaden (=Leitlinien) aus. 
Unter Fragenkaskade verstehe ich fixe Frage-Folgen: 
Wenn die Frage Husten mit “Ja” beantwortet ist, bedingt das immer die Frage 
nach  vordefinierten Folgefragen   >Hustencharakter>Auswurf>Auswurf-Farbe 
usw.
Die Ergebnisse dieser Befragung werden in Datenbanken eingeschrieben, mit 
Hintergrundinformation, sodass diese Frage in der Diagnostik dieses Falles 
nicht mehr gestellt werden muss.

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 

Datenbanken: 
Mit folgenden Tabellen könnte man den Programmablauf steuern und die 
gewonnenen Daten speichern (Ein Ideen-Entwurf).

Homunculus (Homunculus nennt man eine Skizze des menschlichen Körpers, nach 
Wichtigkeit verzerrt)
Die Homunkulus-Skizze  für die Definition der BU darf und soll vermutlich 
nicht zu genau sein, damit die Sache nicht zu kompliziert wird. Sie dient 
nicht der genauen Lokalisationangabe (ist erst für das BE nötig), sondern 
steuert die Abläufe zur Erleichterung der Definition und Dokumentation der 
BU.
In dieser Datei könnte definiert sein, was alles z.B. an der Lokalisation 
"kleine Zehe" oder "Auge" zu geschehen hat:

ZB.: Klick auf Auge kann folgende Symbole anbieten: Hautproblem(Augenlider), 
Verletzung, Schmerz, Diverse Visusstörungen, kurz alles, was dort wichtig 
ist. Das wird bei der kleinen Zehe anders sein, als in der Lebergegend.
So kann man die Eingabe erleichtern, da nach Bekanntgabe der Lokalisation die 
Anzahl der Möglichkeiten reduziert ist. Wenn dies durch die "Symptomart"  
schon weiters eingeschränkt ist, dann wird die Sache schon übersichtlicher: 
Z.B. man nimmt das Schmerzsymbol und legt es auf das Auge. So gelangt man 
hoffentlich einfach und direkt zur Auswahl der Beratungsursache.

Die Tabelle Beratungsursachen (BU): 
Enthält neben allen Feldern, die zur BU interessant sind auch ein Feld namens 
"Leitlinie" in dem definiert ist, welche Leitlinie(n) zu Hilfe geholt werden 
sollen. Aber es gibt auch ein Feld "Dringlichkeit", in dem mit drei  
Graduationen festgelegt wird, ob die Leitlinie tatsächlich aufgerufen wird. 
(1=hohe Dringlichkeit = Leitlinie kommt immer 3=niedrige Dringlichkeit = 
Leitlinie kommt nur, wenn Arzt Zeit dazu hat, wie auch immer das dann 
gesteuert wird)

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. Ein Diabetes mellitus wird für die Prävalenzsstatistik nur  
einmal im Jahr gezählt, das ist Klar. Keine Rückfrage. 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".
Und für diejenigen Fälle, die ich bei der Erstellung der Tabelle BE nicht 
entscheiden konnte, bekamen die Zahl 3. In diesem Sinne könnte ich mir auch 
die individuelle Steuerung der Fragenroutinen vorstellen.

Eine BU steuert somit das weiter Vorgehen mit oder ohne Leitlinie. Wenn im 
Feld Leitlinie z.B. das Wort "Blickdiagnose" steht, dann ist keine weitere 
Befragung nötig und die BU wird automatisch gleich zum BE. Das ist eine 
Möglichkeit, zB. beim Hornhautfremdkörper eine diagnostische Abkürzung zu 
nehmen.


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.

Fragenkatalog 
Steuert die Fragenkaskaden. Eine Frage kann (muß aber nicht) eine Folgefrage 
enthalten. Die Abfolge der Befragung durch die Leitlinie wird also durch den 
"Wichtigkeitsschlüssel" (oder wie auch immer ???) variabel oder fix durch die 
im Fragenkatalog definierte Folgefrage gesteuert.

Auch Fragen können Dringlichkeitsschlüssel enthalten.
Dieses System auszuklügeln braucht viel Praxiserfahrung mit einem 
Testprogramm.

Es sollte jeder Anwender dieses Vorgehen beeinflussen können. Entweder direkt, 
oder das Programm selbstlernend durch die Anwendung bei vielen Kollegen.

Befund-Tabelle:
Die Antworten werden in einer Befund-Datei festgehalten. Die Fragen, die 
gestellt wurden, werden durch eine Fragen-ID gekennzeichnet. Diese Fragen-ID 
enthält auch die Information, ob es eine Folgefrage ist. Das heißt 
Mutter-Fragen und Tochterfragen.
So würded die Befund-Tabelle unter anderem die Patienten-ID, das Datum, ev. 
den Ordinationsraum(Arzt), die Zeilennummer der Behandlungsdatei, die Frage 
mit komlexer Fragen-ID und die Antwort enthalten.

Das Ganze ist noch sehr wage, ist mir noch nicht klar. Für eine klare Lösung 
braucht es auch Kenntnis der modernsten Programmiertechnologien. Soweit ich 
einen blassen Schimmer von der Materie habe, dürfte das mit 
objekt-orientiertem Programmieren gehen.

Auf diese Weise kommt man entweder direkt, blitzschnell oder durch eine mehr 
oder weniger komplizierte Befragung und Untersuchung zum Beratungsergebnis. 
Dieses BE kann nun genauer durch eine exakte Lokalisation definiert werden 
(z.B. unfallchirurgische Diagnosen-Bezeichnung "Fraktura ossis metacarpale 2 
sinister") (wenn nötig) in einer genauen Patienten-Skizze. Die Skizzendetails 
können in der folgenden Tabelle definiert sein.


Beratungsergebnisse (BE)
 Enthält neben diversen Informationen zum BE auch ein Feld "Lokalisation".
 ZB. steht dann beim BE "Hornhautfremdkörper" in der Spalte Lokalisation 
"Auge", womit gesteuert wird, dass zur genauen Lokalisationseintragung das 
Bild eines Auges kommt.

=======================Ende der Programmskizze =================



mfg PhW



-------------------------------------------------------------------------
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