bewert - Christoph Busch

Bewertung des Systems
1
Hier die Kopfzeile eingeben
2
Bewertung des Systems
Die Bewertung des MediWeb-Systems wird in drei Aspekte aufgeteilt. Im ersten Teil
wird die Tauglichkeit des WorldWideWeb als Basistechnologie für das System
betrachtet. Dabei gilt es zu zeigen, wo die Probleme in der Anwendung von MediWeb
liegen, die auf die derzeitige Konzeption der vorhandenen Techniken im WWW
zurückzuführen sind. Gleichzeitig werden Aspekte zur Performanz des Systems
diskutiert. Der zweite Teil der Bewertung beschäftigt sich mit den Funktionalitäten der
Diagnoseunterstützung. Hier geht es in erster Linie um eine Gegenüberstellung der Ziele
und der tatsächlichen Realisierung von MediWeb. Darüber hinaus sollen Kritikpunkte
von Ärzten an der Diagnoseunterstützung diskutiert werden. Im letzten Teil der
Bewertung wird auf die Anwendbarkeit des Systems eingegangen. Diese umfaßt neben
dem theoretischen Anspruch, verwendbar zu sein, auch die praktische Realität,
verwendet zu werden. Eventuell müßten dazu notwendige und/oder sinnvolle
Erweiterungen diskutiert werden.
MediWeb im WWW - eine
Performanzanalyse
Bei der Untersuchung der Performanz des Systems unter Berücksichtigung der
Besonderheiten durch die Verwendung des WorldWideWeb als Benutzungsoberfläche
müssen folgende Kriterien getrennt betrachtet werden:
der Umfang der Benutzerinteraktion,
die Menge der zu übertragenden Daten,
die Dauer der Datenverarbeitung und
die Aufteilung der Verarbeitung auf die Systemkomponenten.
Der Umfang der Benutzerinteraktion spiegelt sich in der Häufigkeit aufzurufender
CGI-Skripte wieder. Bei der Menge der zu übertragenden Daten geht es nicht um die
Gesamtzahl der Daten, sondern um die Größe der einzelnen HTML-Dokumente und
Bilder während einer einzelnen Übertragung. Mit der Datenverarbeitung ist die jeweils
auf der Seite des WWW-Servers durchzuführende Funktionalität des Systems gemeint,
nicht der Aufwand für die Abwicklung der Kommunikation zwischen Client und Server
im WWW. In der Tabelle 6 erfolgt eine vergleichende Aufwandsabschätzung bezüglich
der drei genannten Kriterien für die drei Bereiche Datenbankpflege (Zellenwerte),
Diagnoseunterstützung und Bewertungsinformationssystem des MediWeb-Systems.
Datenbankpfleg
e (Zellenwerte)
hoch
Benutzerinteraktio
DiagnoseBewertungsinfor
unterstützung - mationssystem
gering
sehr gering
3
Kapitel 7
n
Datenübertragung
Datenverarbeitung
Aufteilung
mittel
gering
gering
sehr hoch
hinderlich
unkritisch
Aufwandsabschätzung
mittel
gering
unkritisch
Aus dieser Tabelle läßt sich leicht erkennen, daß sich die Anforderungen bezüglich der
Performanz des Systems bei den verschiedenen Anwendungsgebieten auf
unterschiedliche Bereiche verteilen. So ist die Pflege der Daten geprägt durch eine hohe
Interaktion zwischen dem Anwender und dem System. Dadurch hängt die
Geschwindigkeit stark von der Qualität der Verbindung zwischen Client und Server,
sowie der Leistung des verwendeten CGI-Servers ab. Erschwerend kommt ein
permanenter Auf- und Abbau der notwendigen Verbindungen hinzu. Dies führt trotz des
relativ geringen Aufwands für die Datenverarbeitung, die sich bei der Pflege in erster
Linie auf das Lesen vorhandener Datensätze beschränkt, zu einem unverhältnismäßigem
Zeitaufwand. Das Schreiben neuer, bzw. geänderter Datensätze erfolgt nicht direkt in die
Datenbank, sondern in eine Datei, die im Batchbetrieb ausgewertet wird. Hier würden
sich somit zwei mögliche Verbesserungen bezüglich der Performanz des Systems
anbieten:
Unter der Voraussetzung, daß die Datenpflege in der Regel an ein und
dem selben Ort von einer kleinen Gruppe von Experten durchgeführt
werden könnte, würde es sich anbieten, auch das komplette System dort zu
installieren. Dadurch hätte man die Möglichkeit, die Datenbankpflege im
direkten Zugriff ohne Umweg über das WWW zu realisieren. Das hätte
eine deutliche Verkürzung der Antwortzeiten bei den einzelnen Aktionen
zur Folge. Diese Voraussetzung ist aber, wie in Kapitel 2.2.3 beschrieben,
nicht gegeben.
Bleibt die Installation getrennt von dem Ort der Datenpflege, könnte man
diese dadurch beschleunigen, indem der Experte zu Beginn der Pflege
einen frei definierbaren Ausschnitt aus der Wissensbasis herunter lädt,
diesen lokal bearbeitet und komplett wieder zurückschickt. Dies bedeutet
einen relativ hohen Zeitaufwand bei der Vorbereitung der Pflege. Dieser ist
jedoch
in
Anbetracht
der
daraus
resultierenden
kürzeren
Bearbeitungszeiten während der eigentlichen Pflege durchaus vertretbar.
Dies würde jedoch bedeuten, daß Funktionalitäten benötigt werden, wie sie
derzeit nur von JAVA zur Verfügung gestellt werden. Im Bereich der
Pflege der Wissensbasis dürfte es bei der Verwendung von JAVA keine
Probleme geben, da es sich bei den betrachteten Daten entweder um reines
Lehrbuchwissen oder um anonymisierte Krankengeschichten handelt, also
nicht um zu schützende, personenbezogene Daten.
Für die Diagnoseunterstützung ist der Kommunikationsaufwand fast unbedeutend. Die
Performanz ist hier in erster Linie durch die aufwendigen Berechnungen
gekennzeichnet. Wie sich in der Praxis gezeigt hat, können schon alleine durch die Wahl
der verwendeten Hardware die Antwortzeiten des Systems drastisch reduziert werden.
So betrugen zum Beispiel die Zeiten für eine Differenzierung zwischen vier Diagnosen
auf einem 486DX2-66 ca. 15 Sekunden und auf einem Pentium 150 nur noch knapp
4
Bewertung des Systems
5 Sekunden, wobei beide Rechner mit 32 MB Hauptspeicher ausgestattet waren.
Darüber hinaus ist die Rechenzeit auch deutlich abhängig von der Art der Eingaben.
Wurden zum Beispiel Sperrsymptome definiert, war der Berechnungsaufwand deutlich
geringer, als wenn keine angegeben waren. Das liegt vor allem daran, daß durch die
Definition von Sperrsymptomen die Anzahl betrachteter Diagnosen deutlich reduziert
wird. Daran läßt sich erkennen, daß ein medizinisch versierter Anwender, sprich ein
erfahrener Arzt, wesentlich effizienter mit dem System arbeiten kann, als ein
medizinisch unbedarfter Laie.
Die Antwortzeiten für die Abfrage von Bewertungsinformationen haben sich als eher
unkritisch erwiesen. Der Aufwand beschränkt sich dabei in der Regel nur auf die
übersichtliche Zusammenstellung schon vorhandener Informationen. Selbst die
Erzeugung der Graphiken nimmt keine nennenswerte Zeit in Anspruch.
Ein zusätzlicher Performanzgewinn könnte durch die Verwendung der API des
WWW-Servers erreicht werden. Dadurch könnte man eine feste Verbindung zwischen
CGI- und M-Server aufbauen. Diese muß derzeit bei jedem Aufruf eines Skriptes
aufgebaut und nach dessen Beendigung wieder abgebaut werden. Der Nachteil dieses
Vorgehens wäre jedoch, daß man abhängig von einem einmal gewählten Produkt und
dadurch in der Regel auch von der gewählten Plattform ist.
Da die M-Technologie ein komplettes Netzmanagement beinhaltet, könnte man sich
auch eine räumliche Trennung von WWW- und M-Server vorstellen. Beide Server
stellen relativ hohe Anforderungen an die verwendete Hardware. Würde man den
M-Server auf einen zweiten Rechner installieren und den Rechner mit dem
WWW-Server nur noch als M-Client verwenden, so kann unter Umständen die
Gesamtperformanz des Systems verbessert werden, gerade dann, wenn mehrere
Anfragen vom System parallel bearbeitet werden müssen. Inwieweit sich eine solche
Trennung tatsächlich positiv auf die Performanz auswirkt, müßte im Rahmen eines breit
angelegten Versuches getestet werden. An den jetzigen Programmen wäre dafür keine
Änderung notwendig, da die Verbindung zum M-Server derzeit schon über einen
TCP-Socket als Loop-Back realisiert ist. Es müßte nur in der Konfiguration des
M-Clients die IP-Adresse des entsprechenden M-Servers als Standardverbindung
eingetragen werden.
Was noch aussteht, ist eine Bewertung der Leistungsfähigkeit der verwendeten
Datenbank und des vorhandenen Datenbankmodells bei der Verwendung großer
Datenmengen. Dies ist derzeit nicht möglich, da nur eine geringe Anzahl an Daten zur
Verfügung steht, die zum Testen der Funktionalität eingegeben wurden. Derartige Tests
müssen nachgeholt werden, sobald ein realistisches Datenvolumen eingegeben worden
ist.
Die Diagnoseunterstützung
Eine qualitative Bewertung der Verfahren zur Gewichtung der möglichen
Differentialdiagnosen und der Wahl der Symptome für die Differenzierung konnte im
5
Kapitel 7
Rahmen dieser Arbeit leider nicht erfolgen. Die Daten, die zum Testen des Systems
eingegeben wurden, reichen nicht aus, um umfassende Auswertungen durchführen zu
können. Alleine die Einpflege der benötigten Daten in die Wissensbasis würde mehrere
Wochen in Anspruch nehmen. Erst im Anschluß daran könnte die eigentliche
Auswertung beginnen.
Die Betrachtung der Hierarchieinformationen aus der Datenbasis konnte, wie schon in
Kapitel 6 beschrieben, nicht umgesetzt werden, da eine Betrachtung der Hierarchie von
Symptomen nur in einigen Teilbereichen durchgeführt werden kann, deren
Klassifikation unter den gegebenen Umständen nicht möglich ist. Dabei ist es auch nicht
immer eindeutig, für welchen Teil der Hierarchie eine Betrachtung sinnvoll ist, und für
welchen nicht. Somit war es nicht möglich, ein mathematisches Modell zu entwickeln,
mit dem die Informationen aus der Hierarchie für die Bewertung hätten ermittelt werden
können.
Ein Ansatz, um dieses Problem zu lösen, wäre die Erweiterung der Struktur-Datenbank
um einen Hinweis auf die Art der Hierarchie. Man kann grob zwischen zwei
verschiedenen Hierarchiearten unterscheiden, einer begrifflichen und einer fachlichen
Hierarchie.
Die begriffliche Hierarchie
kann man in gewisser Weise mit der Definition von Meta-Begriffen
vergleichen, die unterschiedliche Aspekte in sich vereinen. Als Beispiel kann
man hier den Begriff Schmerz als begrifflich höhere Hierarchiestufe für die
Begriffe Kopf-, Bauch- und Halsschmerz nehmen. Diese drei Schmerzarten
haben aus medizinischer Sicht nicht viel miteinander zu tun, außer, daß es sich
jeweils um Schmerzen handelt.
Die fachlichen Hierarchie
bezieht sich dagegen auf die Untergliederungen, die eine Spezifizierung, bzw.
eine Verallgemeinerung eines Krankheitsbildes verkörpern. Wenn man bei dem
Beispiel der Schmerzen bleibt, so könnte man unter der fachlichen Hierarchie
eine Erweiterung des Schmerzbegriffs um die Art des Schmerzes (stechend,
dumpf, pochend, usw.) oder um eine Lokalisation des Schmerzes (rechts, links,
vorne, oben, usw.) verstehen.
Wären alle Einträge in der Struktur-Datenbank entsprechend gekennzeichnet, so könnte
man die Hierarchiebetrachtung bei der Bewertung durchführen, indem nur die fachlichen
Hierarchieteile betrachtet werden.
Bei der Besprechung des Systems mit Medizinern und Medizin-Informatikern des
Uniklinikums in Frankfurt wurde dennoch ein überwiegend positives Urteil gefällt. Als
gut und umfangreich wurden die vielen Möglichkeiten gesehen, mit denen der Arzt
selbst in den Vorgang der Bewertung und Differenzierung eingreifen kann. Die dafür zur
Verfügung gestellten Informationen über den Status der Berechnungen helfen dem Arzt,
auch ohne direkte Kenntnis der Bewertungsalgorithmen die Konsequenzen seiner
Eingaben auf die weiteren Berechnungen schon im voraus abschätzen zu können. Ein
besonderes Augenmerk fiel dabei auf die graphische Darstellung der Auswirkung eines
Symptoms auf die weitere Differenzierung.
6
Bewertung des Systems
Als hilfreich für die Anwendung in der Praxis schlug man vor, bei der ersten
Diagnosenstellung nicht nur Differentialdiagnosen aus dem gewählten Fachgebiet
anzuzeigen, sondern darüber hinaus auch Hinweise auf mögliche Erkrankungen
fachfremder medizinischer Bereiche zu geben. Dies dürfte im Grunde genommen kein
großes Problem sein, da die Wissensbasis von MediWeb beliebig viele Domänen der
Medizin beinhalten kann, die in der Regel voneinander unabhängig sind.
Ein Problem, was alle Expertensysteme zur Diagnoseunterstützung haben und auch hier
wieder zur Sprache kam, ist die Betrachtung jeweils einzelner Diagnosen. In der
Medizin ist es jedoch häufig der Fall, daß ein Patient an mehreren Erkrankungen
gleichzeitig leidet. In diesen Fällen ist die von einem solchen Expertensystem gebotene
Unterstützung für den Arzt eher gering. Rein theoretisch wäre eine Betrachtung von
Diagnosekombinationen durchaus denkbar. In der Realität scheitert es jedoch an der
Komplexität des Problems. Neben den einzelnen Krankheiten müßten zusätzlich alle
möglichen Krankheitsbilder betrachtet werden, die sich durch das gemeinsame Auftreten
mehrerer Diagnosen ergeben. Ein Ausweg aus diesem Dilemma wäre eine Definition
einzelner, häufig auftretender Kombinationen von Krankheiten als eine Art
Meta-Diagnose. Diese könnten wie die 'normalen' Diagnosen in das System eingefügt
und dann mit der vorhandenen Funktionalität ausgewertet werden.
MediWeb in der Praxis
In der derzeitigen Form ist MediWeb für die Diagnoseunterstützung prinzipiell
verwendbar. Voraussetzung dafür ist jedoch, daß ein entsprechender Umfang an Daten
in das System eingegeben wird. In der Praxis hat MediWeb aber kaum Aussichten auf
eine breite Anwendung. Das Problem dafür liegt in der Tatsache, daß ein Arzt nicht
mehrfach die selben Angaben zu einem Fall eingeben will. Er ist verpflichtet, alle
Informationen, die er im Rahmen einer Untersuchung sammelt, zu dokumentieren. Dies
erfolgt entweder über das Führen einer herkömmlichen Patientenakte oder über eine
EDV-gestützte Patientenverwaltung. Er wäre also gezwungen, alle Befunde für die
Dokumentation einzutragen und gleichzeitig noch einmal für die Diagnoseunterstützung
einzugeben. Diesen Aufwand wird er in der Regel nicht freiwillig in Kauf nehmen.
Daraus ergibt sich ein erster Ansatz dafür, wie man MediWeb sinnvoll erweitern könnte.
Man müßte eine Schnittstelle anbieten, die das Expertensystem mit einem System zur
Befunddokumentation verbindbar macht. Dabei würde die Eingabe der
Ausgangsbefunde durch das Einlesen eines Patientendatensatzes aus dem
Befunddokumentationssystem
ersetzt
werden.
Nach
der
durchgeführten
Diagnoseunterstützung müßten gleichermaßen die zustätzlich gewonnenen
Informationen über weitere Befunde, sowie das Ergebnis der Differenzierung den
Patientendaten hinzugefügt werden, die dann wieder in die Befunddokumentation
einfließen. Dadurch würde die doppelte Eingabe der Daten entfallen. Darüber hinaus
hätte dieses Vorgehen auch zur Folge, daß der Inhalt der Befunddokumentation in
gewisser Weise standardisiert wäre, da die Wahl der verwendeten Bezeichnungen für
Diagnosen und Symptome durch den Thesaurus des MediWeb-Systems eindeutig
7
Kapitel 7
vorgegeben sind.
Eine solche, standardisierte Befunddokumentation bildet eine optimale Basis für die
Auswertung von Krankengeschichten für die Pflege der Zellenwerte, genauer der Zähler
für die statistische Bewertung von Symptom-Diagnose-Beziehungen. Aufgrund dieser
Ausgangssituation bietet es sich an, diese Auswertung automatisch durchzuführen. Da
die verwendete Begriffswelt mit der von MediWeb übereinstimmt, kann es bei der
jeweiligen Zuordnung von Bezeichnern auf die entsprechenden Symptome, bzw.
Diagnosen zu keinen Schwierigkeiten kommen. Man könnte somit ein System zur
automatischen Einpflege von Krankengeschichten erstellen. Der Effekt wäre, daß das
MediWeb-System dadurch die Fähigkeit zum Lernen erhält. Jede ärztliche Untersuchung
eines Patienten würde zu einer Aktualisierung der statistischen Werte führen.
Voraussetzung für ein solches selbstlernendes Expertensystem ist jedoch, daß es von
einer möglichst großen Anzahl unabhängiger Ärzte benutzt wird. Der Begriff
'unabhängig' bezieht sich in diesem Falle auf die entsprechende Definition aus der
Statistik und bedeutet hier in etwa, daß die Ärzte möglichst an verschiedenen
Universitäten studiert haben und sich ihr Patientenkreis in der ethnischen, sozialen und
wirtschaftlichen Struktur unterscheidet. Ansonsten besteht die Gefahr, daß sich das
Wissen des Expertensystems auf eine bestimmte Untersuchungsmethode und/oder einen
bestimmten Patientenkreis fokusiert und somit die Ergebnisse von Fällen, die außerhalb
dieses Bereichs liegenden, verfälscht.
Eine dritte Erweiterungsmöglichkeit wäre das Einführen eines Lernsystems, wie es
beispielsweise in ILIAD enthalten ist. Als Basis für die Fallbeispiele könnte ich mir die
oben beschriebene Anbindung an ein Befunddokumentationssystem vorstellen. Dadurch
hätte das System einen Zugriff auf eine beliebig große Anzahl an realen Fällen aus der
Praxis. Die in der Diagnoseunterstützung enthaltene Funktionalität für die Bewertung
der Diagnosen und die Wahl der Symptome für die Differenzierung könnten einfach
übernommen werden. Das einzige was sich ändern würde, wäre die Richtung der
Anwender-System-Kommunikation. Der Anwender erhält vom System die
Ausgangsbefunde und stellt im Gegenzug Fragen über weiterführende Symptome an das
System, bis er meint, die entsprechende Diagnose zu kennen. Das System müßte im
Rahmen der Differenzierung eine Bewertung der Vorgehensweise des Anwenders
vornehmen und ihm eventuell Alternativen vorschlagen. Wie dies im Einzelnen realisiert
werden kann, müßte an anderer Stelle ausführlich diskutiert werden.
8