Wissensbasierte Diagnosesysteme mit D3

Ein Assistenzsystem zur Datenerfassung und
Diagnoseunterstützung auf PDA-Geräten
Joachim Baumeister, Christian Betz
Lehrstuhl für Informatik VI, Künstliche Intelligenz und Angewandte Informatik,
Universität Würzburg
{joba|betz}@informatik.uni-wuerzburg.de
Mobile Endgeräte ermöglichen die Durchdringung des ärztlichen Alltags mit
Informationstechnologie. Qualitätssicherung und Entlastung von Routineaufgaben sind dabei
zwei wichtige Gesichtspunkte. Die mobile Erfassung von Patientendaten anhand von
Guidelines liefert die Basis für eine automatische Diagnostik. So können unmittelbar bei der
Eingabe Warnmeldungen z.B. bei Medikamentenunverträglichkeiten oder bei übersehenen
(weil seltenen) Diagnosen generiert werden. Mit d3web existiert die Möglichkeit,
wissensbasierte
Datenerfassung
und
–auswertung
auf
mobilen
Endgeräten
zu
implementieren.
Einleitung
Den Computer im Gespräch mit dem Patienten einzusetzen, war bisher undenkbar: der
Dialog mit dem Patienten wurde nahezu unmöglich, die Bewegungsfreiheit des Arztes
unzumutbar eingeschränkt – selbst Notebooks sind davon nicht ausgenommen. PDAs
hingegen ermöglichen gerade durch ihre Mobilität eine weitere Durchdringung des ärztlichen
Alltags. Dies ist jedoch noch nicht per se ein Vorteil für Patient und Arzt – sondern könnte
durchaus auch eine Störung der Kommunikation nach sich ziehen. Erst, wenn sie gegenüber
bisherigen Lösungen wirklichen Zusatznutzen bringen, werden mobile Lösungen akzeptiert
werden.
Direkt am Krankenbett die Daten des Patienten elektronisch erfassen zu können, diese
nach der Visite automatisch ins Klinik-Informationssystem zu übertragen und in der nächsten
Visite wieder über den mobilen Rechner verfügbar zu haben, spart Übertragungsaufwand und
damit wertvolle Zeit. Als Assistenzsystem, vergleichbar den Office-Agenten von MS Word,
kann intelligente Software die eingegebenen Daten überprüfen. Nötigenfalls können
Warnhinweise, z.B. bei Therapie-Nebenwirkungen, generiert werden. Qualitätssicherung als
positiver Nebeneffekt einer Arbeitserleichterung. Ebenso wie Word dient das Programm
damit im Wesentlichen dem systematischen Erfassen von Daten (hier Patientendaten). Da die
Domäne sehr abgegrenzt ist im Vergleich zu einer Textverarbeitung, kann der Assisstent
wesentlich gezielter gesteuert werden und stört daher nur sehr selten. Er kann jedoch immer
um Rat gefragt werden.
Diagnosesysteme boten bereits die beschriebenen Möglichkeiten – allerdings bisher nur
(bedingt nicht zuletzt durch Programm- und Datenumfang) auf leistungsfähigen DesktopRechnern. Das von uns neue entwickelte d3web erlaubt es, kleine und leistungsfähige Dialogund Diagnosesysteme zu konfigurieren, die eine mobile Nutzung ermöglichen.
Zuerst werden wir einen Überblick über die Aufgaben mobiler Erfassungs- und
Diagnosesysteme geben. Die Techniken, die d3web zu Grunde liegen, werden im Anschluss
daran erläutert. Im Folgenden wenden wir uns den Besonderheiten mobiler Endgeräte zu und
stellen d3web, die Neuentwicklung von D3, im Hinblick auf diese Besonderheiten dar.
Intelligentes Erfassungs- und Diagnosesystem
Grundlage eines solchen oben skizzierten Assistenzsystems ist die Erfassung der
Symptome durch den Mediziner. Dabei müssen zwei Methoden zur Verfügung stehen: Eine
freie Eingabe der Symptome durch den Benutzer und ein intelligenter Dialog, der jeweils die
nächste zu beantwortende Frage vorgibt. Die freie Eingabe ist wichtig, damit die PatientenKommunikation nicht gestört wird. Der Arzt kann die Fragen stellen, die er für sinnvoll hält
und die Antworten eintragen, die der Patient gibt. Auch Labordaten müssen so importiert
werden können: in der Reihenfolge ihrer Verfügbarkeit
Das System kann aber auch einen intelligenten Dialog anbieten. Der Benutzer soll die
Möglichkeit haben, Checklisten durchzugehen und Guidelines zu befolgen, ohne diese
auswendig lernen zu müssen. „Intelligent“ wird der Dialog dadurch, dass die Checklisten die
bereits eingegebenen Antworten berücksichtigen. Gerade bei nicht-alltäglichen Erkrankungen
(Tropenmedizin etc.), die für den Arzt auch nicht zur Routine zählen, kann ein solches
Hilfesystem warnen, wenn Lösungen möglicherweise übersehen wurden.
Geführte Datenerfassung
Fragebögen
Um intelligente Fragebögen zu modellieren, stehen in d3web eine Reihe von Mechanismen
zur Verfügung. Grundlegend ist die Möglichkeit, Fragen zu Fragebögen zu aggregieren. Diese
können wiederum zusammengefasst werden. Dabei können einzelne Elemente in mehreren
Frageklassen auftreten, wobei Zyklen ausgeschlossen sind. So ergibt sich ein gerichteter
azyklischer Graph über allen Fragen, wie er in Abbildung 1 zu sehen ist. Alle Mechanismen,
wie sie unten skizziert werden, können sowohl einzelne Fragen als auch ganze Fragebögen
betreffen.
Folgefragen
Normalerweise werden alle Elemente eines Fragebogens der Reihe nach abgearbeitet. Es
gibt jedoch, wie bereits angedeutet, mehrere Möglichkeiten, die Fragebögen in Abhängigkeit
von der Situation zu modifizieren. Um beispielsweise auf einzelne Fragen näher einzugehen,
kann man Folgefragen angeben.
Beispiel:
Wenn Frage „Kopfschmerz“ den Wert „einseitig“ hat, dann stelle
Frage „Kopfschmerz rechts oder links?“.
Untersuchungen zur Abklärung
Dieser Mechanismus kann auch genutzt werden, um einen kompletten Fragebogen zu
aktivieren. Dies ist auch dann möglich und sinnvoll, wenn die Fragen nicht durch den Dialog
impliziert werden, sondern durch die momentanen Diagnosen (s.u.). So lassen sich
Abklärungen realisieren, wie das folgende Beispiel zeigt:
Beispiel:
Wenn die Diagnose „Migräne“ verdächtigt wird, dann stelle Frage
„Leiden Sie unter Empfindlichkeiten?“.
Kontraindikations- und Supressregeln
Analog kann man mit sogenannten Kontraindikationsregeln das Stellen von Fragen
unterdrücken. Beispielsweise ist so bei einem männlichen Patienten die Frage nach einer
Schwangerschaft zu unterbinden. Es ist ebenso möglich, eine Frage zwar zu stellen, aber
bestimmte Antwortmöglichkeiten in Abhängigkeit früherer Antworten (durch Supressregeln)
zu unterdrücken. Dies gilt beispielsweise, wenn „Schwangerschaft“ keine Ja/Nein-Frage ist,
sondern nur als Antwortalternative in einer Liste vorkommt:
Beispiel:
Frage 1: „Geschlecht“, Antworten: männlich/weiblich
Frage 2: „momentane psychische oder physische Belastungen?“
Antworten: Stress, Schwangerschaft, sonstiges, unbekannt
Regel: Wenn „Geschlecht“ ist „männlich“, dann unterdrücke
Antwort „Schwangerschaft“ bei Frage 2
Die beschriebenen Mechanismen genügen in aller Regel zur automatischen Strukturierung
des Dialoges. Dabei ist es möglich, weite Teile des Fragenstruktur zu unterdrücken. Auf diese
Weise lässt sich der Aufwand zur Erfassung der Informationen auf das nötige Minimum
reduzieren. Gerade bei komplexen Domänen wie der Medizin kann so die Übersichtlichkeit
von Erfassungsschemata deutlich verbessert werden.
Symptominterpretationen
Die einzelnen Fragen (=Symptome) können zur weiteren Nutzung automatisch aggregiert
werden. Ausgehend von einem oder mehreren Symptomen wird dazu über Formeln, Schemata
und ähnliche Mechanismen der Wert einer Symptominterpretation hergeleitet.
Beispiel Body-Mass-Index:
Wenn
„Gewicht“
bekannt
ist
und
„Größe“
bekannt
ist,
dann
berechne BMI = Gewicht [kg] / (Größe [m])²
Aus dem BMI lässt sich eine weitere Bewertung ableiten:
Bewertung Gewicht = Untergewicht, Normalgewicht, Übergewicht,
Adipositas Grad I, Adipositas Grad II, Extreme Adiopsitas
Grad III
Wenn BMI=bekannt, dann Bewertung Gewicht = BMI entsprechend
Schema [18,5;25,0;30,0;35,0;40,0]
Diagnostik
Wie oben bereits erwähnt, kann das System jederzeit nach einer „Meinung“ befragt
werden. Es ist in der Lage, anhand der eingegebenen Information zu jedem Zeitpunkt die
Diagnosen und Therapien auszugeben, die es verdächtigt bzw. für gesichert hält. Die
ermögicht einen Einsatz als Assisstenzsystem. Ein wichtiger Punkt ist dabei, dass es
selbständig entscheiden können muss, ob der Benutzer benachrichtigt werden sollte.
Aufgrund der Tatsache, dass der Benutzer in diesem Fall selbst Experte ist, darf das System
nur eingreifen, wenn es sich sicher ist, dass eine schwerwiegende Störung vorliegt. Dies
könnte beispielsweise der Fall sein, wenn eine verordnete Therapie für den Patienten
schädliche Nebenwirkungen mit sich bringt. Je nach Einstellung des Schwellwertes könnten
aber auch schon Warnhinweise generiert werden (z.B. wenn andere Medikamente bei gleicher
Erfolgsaussicht preisgünstiger sind).
Um die Diagnosen zu bestimmen, werden heuristische Regeln eingesetzt. Es gibt hierfür
prinzipiell noch eine ganze Reihe von Möglichkeiten, sogenannte Problemlösemechanismen.
Diese sind prinzipiell auch in d3web einzubinden, wir beschränken uns im Rahmen dieser
Arbeit jedoch auf die Darstellung heuristischer Regeln:
Die Aktion (dann-Teil) einer solchen Regel besteht aus einer Diagnose und einem Score.
Beispiel:
Wenn die Temperatur=hoch, dann gib Diagnose „Grippaler Infekt“
den Score P5.
P5 heißt dabei, dass ein grippaler Infekt sehr wahrscheinlich ist, wenn die Regelbedingung
(„Temperatur=hoch“) erfüllt ist. Auch negative Scores sind möglich, so dass sich insgesamt
ein Spektrum von N7 (ausgeschlossen) über N6, N5,... , P1, P2 usw. bis hin zu P7 (immer)
ergibt. Das System ist eigenständig in der Lage, unterschiedliche Scores zu verrechnen
(Beispiel: zwei P4-Scores und ein N3-Score ergeben zusammen eine immer noch etablierte
Diagnose). Das System ist auch in der Lage, die Ergebnisse zu bestimmen, wenn sich
Symptomwerte ändern. Regeln, die nicht mehr gültig sind, werden zurückgezogen und
dadurch verursachte Änderungen werden weiterpropagiert.
Will der Arzt wissen, wie das System eine Diagnose bewertet, so werden die Scores
verrechnet und das Ergebnis anhand eines Schemas ausgewertet, so dass Bewertungen von
„ausgeschlossen“ über „unklar“ und „verdächtig, möglich“ bis „wahrscheinlich, gesichert“
möglich sind. Wie man bereits sieht, können die Begriffe an die Wünsche der Anwender
angepasst werden.
Wissensbasis
Als Grundlage für die beschriebenen Funktionen dient eine Wissensbasis. Diese enthält
strukturierte Informationen über die Symptome, die Diagnosen und Therapien sowie die
Beziehungen zwischen all diesen Objekten. Für alle folgenden Ausführungen konzentrieren
wir uns auf Symptome und Diagnosen, da Therapien im Moment in d3web wie Diagnosen
behandelt werden. Da dies nicht ganz den Bedürfnissen entspricht, besteht hier noch Bedarf
für Erweiterungen.
Hierarchien
Grundlage der Wissensbasis sind die Objektmengen Symptome und Diagnosen. Beide
Mengen bilden jeweils einen gerichteten azyklischen Graphen: die Symptome sind wie oben
geschildert in Frageklassen gruppiert (Patientendaten, Beschwerden, Vorgeschichte,
Medikamente, ...).
Abbildung 1: Objekthierarchien von D3
Analog können Diagnosen gruppiert bzw. verfeinert werden. Diese Strukturen findet man
auch in den standardisierten Terminologien, wie sie in der Medizin Verwendung finden (ICD10, MeSH).
Regeln
Die Objekte sind verknüpft durch Beziehungen, hauptsächlich Regeln. Diese können von
unterschiedlichen Typen sein: Folgefrage- oder Kontraindikationsregeln zur Steuerung des
Dialogs oder sogenannte heuristische Regeln zur Herleitung von Diagnosen. D3Web ist
grundsätzlich auch in der Lage, andere Problemlösemethoden (ohne Regel-Struktur) wie z.B.
überdeckende Problemlösung, Bayes’sche Netze oder fallbasiertes Schließen zu ermöglichen,
diese Methoden sollen hier jedoch außen vor bleiben.
Eine Regel besteht aus einem beliebig komplexen booleschen Ausdruck (der Bedingung)
und der Regelaktion. Je nach Typ der Regel fällt die Aktion anders aus: Folgefrage-Regeln
haben als Aktion nur eine Liste von Fragen oder Fragebögen. Heuristische Regeln besitzen als
Aktion ein Diagnose/Bewertungs-Paar (s.o.).
Attribute
Für verschiedene Zwecke können den einzelnen Objekten statische Attribute zugewiesen
werden, beispielsweise der Name zur Verbalisierung, aber auch Codes (ICD-10, MeSH),
Links zu weiterführenden Informationen etc.
Fallstruktur
Die Wissensbasis beschreibt die globalen Zusammenhänge innerhalb der Domäne. Das
jeweilige Problem hingegen wird durch einen sogenannten Fall beschrieben. Ein Fall enthält
die gestellten Fragen mit den zugehörigen Antworten. Zusätzlich kann ein solcher Fall auch
die tatsächlichen Lösungen enthalten. Derart angereicherte Fälle können zum Fallvergleich
herangezogen werden, bei dem zu einem neuen Fall [A] der ähnlichste Fall [B] aus der Menge
der Fälle mit bekannter Lösung gewählt wird. Als Lösung zu Fall [A] präsentiert das System
dann die Lösung des Falles B.
Des weiteren enthält ein Fall üblicherweise Metadaten wie Autor, Titel, Erstellungsdaten
etc. Diese können beispielsweise für die Suche nach Fällen genutzt werden.
Die weitere Nutzung der Fallinformationen ist ein wesentlicher Gesichtspunkt beim Erfolg
eines Diagnose-Systems. Die Daten müssen beispielsweise im Klink-Informationssystem
abrufbar sein, für statistische Zwecke ausgewertet werden können und vieles mehr. Die
Übertragung der Fälle aus dem PDA in ein Informationssystem und die Speicherung in XML
oder in relationalen Datenbanken machen die weitere Nutzung einfach.
Im Folgenden wird der Shellbaukasten D3 vorgestellt, mit dem wissensbasierte
Diagnosesysteme mit den oben genannten Eigenschaften generiert werden können. Weiterhin
berichten wir von der Neuentwicklung d3web, welches als Ablaufumgebung für die erstellten
Diagnosesysteme dient und sich für den Einsatz auf mobilen Endgeräten eignet.
Wissensbasierte Diagnosesysteme mit D3
Das wissensbasierte Diagnosesystem D3 weist eine langjährige Entwicklung auf
[Puppe et al. 1996]. So entstanden beispielsweise im medizinischen Bereich unter anderen mit
dem RheumaTutor [Schewe et al. 1999], [Schewe 1999] und HepatoConsult [Buscher 1998]
erfolgreiche Systeme, die auch kommerziell erhältlich sind. Auch für technische
Anwendungen konnte unter anderem in Zusammenarbeit mit der Firma Koenig & Bauer
[Puppe et al. 2001] ein Diagnosesystem zur Fehlererkennung und Wartung von
Druckmaschinen implementiert werden.
Diese Systeme wurden mit der visuellen Entwicklungsumgebung von D3 erstellt, welche
im D3 Shellbaukasten [D3Url] enthalten ist. Mit dieser Entwicklungsumgebung können
Experten ihr Wissen über Formulare bzw. Hierarchien selbst eingeben und mit Hilfe der D3Ablaufumgebung unmittelbar testen.
Der D3-Shellbaukasten erfuhr über die Jahre hinweg eine Vielzahl von Erweiterungen und
wuchs so zu einem mächtigen Werkzeug zur Erstellung von Diagnosesystemen heran. So
bietet die visuelle Entwicklungsumgebung für eine Vielzahl von Wissensarten (z.B.
kategorisch, heuristisch, fallbasiert) Editoren an, welche in der Ablaufumgebung auch
kombiniert verarbeitet werden können. Eine Kopplung von multi-medialen Inhalten
ermöglicht zusätzlich den Aufbau eines Informationssystems.
Anforderungen an D3 für mobile Einsatzszenarien
Um jedoch den Anforderungen eines Diagnosesystems für mobile bzw. eingebettete Geräte
entsprechen zu können, muss D3 folgende Anforderungen erfüllen:
1. Konfigurierbare, modulare Größe
Das System soll möglichst klein sein, nicht benötigte Komponenten (bspw. eine
Dialogsteuerung bei automatischen, eingebetteten Systemen) sollen leicht entfernt
werden können.
2. Portabilität
Das System soll leicht auf beliebige Plattformen portierbar sein. Dies ist insbesondere
für die Dialogschnittstelle von besonderer Bedeutung.
3. Intuitive Benutzungsschnittstelle
Die Bedienoberfläche muss an das jeweilige Einsatzgebiet bzw. Systemumgebung
angepasst sein und für den Benutzer möglichst wenig Interaktionsaufwand darstellen.
Dies stellt durch die niedrig auflösenden Bildschirme und eine ungewohnte Steuerung
über Touch-Screens bzw. Touch-Pens eine besondere Herausforderung dar.
4. Geschwindigkeit/Effizienz
Eingebettete bzw. mobile Geräte beherbergen meist leistungsschwache Prozessoren
und verfügen über eine begrenzte Hardwareausstattung. Das System muss daher
möglichst effizient mit der Rechenleistung und dem verfügbaren Speicher umgehen.
5. Kopplungsfähigkeit
Eine problemlose Kopplung des Diagnosesystems an andere Programme (z.B.
Krankenhausinformationssystem) muss möglich sein.
D3 konnte diese Anforderungen in weiten Teilen nicht erfüllen. So ist durch die
monolithische Architektur mit integrierter Entwicklungsumgebung eine Entkopplung der
Ablaufumgebung, welche allein für den Einsatz in mobilen Geräten interessant ist, nicht
möglich. Die Portierung des bestehenden Diagnosesystem stellte ebenso eine schwierige
Fragstellung dar. Obwohl weitgehend in ANSI CommonLisp erstellt, bedingen die
integrierten GUI-Methoden eine Abhängigkeit von MS-Windows. Ein weiteres Problem ist
die Ablaufgeschwindigkeit von D3. Durch die monolithische Struktur und die Komplexität
des Systems sind die verlangsamenden Elemente schwer auszumachen bzw. zu reduzieren.
Aus den oben genannten Gründen wurde ab Sommer 2000 mit einer Neuimplementierung
von D3 unter dem Namen d3web begonnen. Im Folgenden wird die bereits umgesetzte und
geplante Funktionalität von d3web beschrieben:
Portabilität
d3web ist vollständig in Java geschrieben und verwendet nur die Standardkassen von
Java 2. Somit ist eine hohe Verfügbarkeit von virtuellen Maschinen für die verschiedensten
Plattformen gegeben. Hervorzuheben ist hier die virtuelle Maschine J9 von IBM, welche gut
für eingebettete Systeme bzw. PDAs geeignet ist und bereits 14 Plattformen unterstützt (unter
anderem Palm/OS und Windows CE). Darüber hinaus arbeitet Sun mit der Java 2ME
(MicroEdition) an einer eigenen Java Version für eingebettete bzw. mobile Systeme.
Konfigurierbarkeit
Der gesamte Kernel von d3web umfasst als JAR Datei 118KB und ist somit klein genug
für die meisten Systeme. Die Größe kann durch Hinzunahme/Entnahme optionaler (z.B.
weitere Problemlöser, Datenbankanbindung) Komponenten variieren. Die endgültige Größe
des Ablaufsystems hängt zum größten Teil von der eingesetzten Wissensbasis ab, da diese
separat vom Kernel initialisiert wird und eigenen Speicher benötigt.
Kopplungsfähigkeit
d3web bietet eine offene Schnittstelle für den Dialog an. Auf diese Weise können beliebige
Dialoge an den Kernel gekoppelt werden. Weiterhin ist die Persistenzschicht vom Kernel
getrennt. Für web-basierte Anwendungen können somit die Wissensbasen und Fälle in JDBCDatenbanken gehalten werden, während für mobile Systeme die Möglichkeit besteht,
Wissensbasen in Java class-Dateien vorzukompilieren und integriert auszuliefern.
Benutzungsschnittstelle
Der Dialog zum Benutzer ist von Kernel unabhängig und wird je nach System bzw.
Anwendung implementiert. Bisher wurde eine HTML/JSP-basierte Lösung als Web-Dialog
implementiert.
Für mobile Systeme ist eine Dialogoberfläche erforderlich, welche den Benutzer bei der
Dateneingabe nicht mit unnötigen Fragen bzw. Merkmalserhebungen stört. Die oben
beschriebenen Mechanismen zu Dialogsteuerung (Indikation von Folgefragen(klassen),
Unterdrücken von Antwortalternativen, usw.) werden von d3web bereitgestellt.
Ausblick
Das Diagnosesystem d3web ist momentan mit einer webbasierten Dialogschnittstelle
verfügbar. Eine Anpassung des Dialoges für mobile Anwendungen befindet sich momentan in
einem prototypischen Status. Für den realen Einsatz im mobilen Umfeld sind einige Punkte zu
beachten:
Effizienz
Die
aktuelle
Fassung
des
Kernels
ist
nicht
auf
Speichereffizienz
und
Ablaufgeschwindigkeit optimiert. Hier ist noch eine Untersuchung notwendig, inwieweit eine
Überarbeitung bezüglich dieser Gesichtspunkte notwendig ist. Gegenüber der früheren LISP-
Version von D3 ist allerdings subjektiv ein erheblicher Geschwindigkeitszuwachs bei
gleichzeitig geringerem Speicherverbrauch zu beobachten, so dass hier möglicherweise nur
wenig Zusatzaufwand geleistet werden muss.
Integrationsfähigkeit
Ein wichtiges Kriterium für die Einsatzfähigkeit von Diagnosesystemen ist die
Integrationsfähigkeit in bereits bestehende Systeme. Im medizinischen Umfeld sind dies meist
klinische Informationssysteme, welche neben der Patientenakte weitere relevante Daten
verwalten. Als erster Ansatz wäre eine Export-Funktion der Patientensymptome des d3web
Falls in
ein
geeignetes Format (beispielsweise XML) empfehlenswert, der die
Weiterverarbeitung
im
Informationssystem
ermöglicht.
Eine
umgekehrte
Import-
Funktionalität ist ebenso sinnvoll denkbar.
Kritikfähigkeit
Eine interessante Erweiterung von Diagnosesystemen ist die Kritikfähigkeit. Zusätzlich zu
den Symptomen gibt der Nutzer die von ihm angenommene Diagnose(-kombination) ein.
Findet das System eine abweichende Lösung aufgrund der beobachteten Merkmale, und wird
diese Lösung als signifikant unterschiedlich von der Benutzerlösung bewertet, so kritisiert das
System diese Entscheidung. Es kann Erklärungen geben, wie es zu einer differierenden
Diagnose gekommen ist und damit den Nutzer bei Bedarf unterstützen. In [RP:98] werden
Anforderungen an ein wissensbasiertes Diagnosesystem gezeigt, die bei der Erweiterung zu
einem Kritiksystem erfüllt werden müssten.
Freier Dialog
Im den obigen Anschnitten wurde aufgezeigt, wie mit Methoden der Dialogsteuerung ein
intelligenter, geführter Dialog ermöglicht wird. Auf diese Weise kann eine geführte und
standardisierte Erfassung von Merkmalen durchgeführt werden. Alternativ soll jedoch der
Benutzer die erfassten Merkmale frei in das System eingeben können, ohne einem speziellen
Dialog folgen zu müssen. Solche freien Dialoge werfen im Umfeld von mobilen Geräten
spezielle
Anforderungen
hinsichtlich
der
Ergonomie
auf
(Stichwort:
verringerte
Displayfläche, eingeschränkte Navigationsmöglichkeit).
Schließlich könnte sich das System am besten dem Nutzerverhalten anpassen, wenn eine
einfache Wechselmöglichkeit zwischen einem geführtem (mit Dialogsteuerung) und einem
freien Dialog während der Datenerfassung bestehen würde.
Literatur
[D3Url] Das wissensbasierte Diagnosesystem ist unter http://www.d3web.de erreichbar.
[Puppe et al. 1996] Puppe, F., Gappa, U., Poeck, K. und Bamberger, S.: Wissensbasierte
Diagnose- und Informationssysteme, Springer 1996.
[Puppe et al. 2001] Puppe, F. Ziegler, S., Martin, U., Hupp, J.: Wissensbasierte
Diagnosesysteme im Service Support - mit Erfahrungsberichten, Springer 2001
[RP:98] Rhein-Desel, U. and Puppe, F.: Concepts for a Critiquing System in Vague
Domains, in: Proc. of KI-98, 22nd German Conference on Artificial Intelligence, Springer,
LNAI 1504, 201-212.
[Schewe et al. 1999] Schewe S., Reinhardt B., Betz C.: Experiences with a Knowledge
Based Tutoring System for Student Education in Rheumatology, in Puppe, F. (ed.): XPS-99:
5th German Conference on Knowledge-Based Systems, Springer, LNAI 1570, pp.193-200,
1999
[Schewe
1999]
Schewe,
S.:
RheumaTutor,:
Fallbasiertes
rheumatologisches
Trainingsprogramm. Ullstein Medical, 1999
[Buscher, 1998] Buscher, H.-P.: HepatoConsult, Hepatologisches Second-OpinionProgramm. Ullstein Medical, 1998