gms | German Medical Science

Im vergangenen Wintersemester 2005/06 wurde eine Studie durchgeführt mit dem Ziel, die Akzeptanz verschieden komplexer Fälle im Kontext eines Blended Learning Konzepts in der Kardiologie als Teil der Pflichtvorlesung Inneren Medizin im Studiengang Humanmedizin der Universität Würzburg zu untersuchen.

Im Rahmen der Studie wurde das Autoren- und Ablaufsystem d3web.Train benutzt, um 18 kardiologische Trainingsfälle zu erstellen, die das Spektrum der wichtigsten kardiologischen Diagnosen im Rahmen der Pflichtvorlesung „Innere Medizin“ im 2. bzw.3 klinischen Semester der Humanmedizin abdecken. Die Fälle wurden nach der Vorlesung zur Klausurvorbereitung bereitgestellt, das Bearbeiten der Fälle war für die Medizinstudentinnen und -studenten freiwillig. Die Fälle unterschieden sich in der Komplexität und Art der Aufgaben. Neben Multiple-Choice-Fragen (MC) gab es auch hierarchische Long-Menu-Fragen (HLM), bei denen die Diagnose, Therapie bzw. Untersuchung aus einer Begriffshierarchie, dargestellt als Baumauswahl mit auf- und zuklappbaren Teilhierarchien, mit einer Vielzahl von möglichen Alternativen ausgewählt werden musste. Die Aufgabenarten umfassten Fragen nach der Enddiagnose (alle Fälle; HLM), nach Zwischendiagnosen (12 Fälle; HLM), nach Untersuchungen (14 Fälle, davon 6 MC und 8 HLM), nach Befundung von Bildern bzw. Videos (15 Fälle; MC), nach Therapien (15 Fälle, davon 7 MC und 8 HLM), nach Diagnosen bzw. Therapieänderungen in Folgesitzungen (4 Fälle; MC); und Fragen nach Hintergrundwissen (alle Fälle; MC). Bei jedem Fall wurde die Bearbeitungsdauer, sowie die Qualität der studentischen Falllösung automatisch aufgezeichnet, außerdem wurden bei Fallabschluss 2 Fragen gestellt, wobei die Studierenden die technische Bedienung (Skala von 1= leicht; 15=sehr schwierig) und den Inhalt des Falles (Schulnoten: 1-6) bewerten sollten. Außerdem konnten sie einen Kommentar zum Fall eingeben.

Ergebnisse der Studie: Wir beschränkten uns bei der Untersuchung auf die letzten 16 Fälle, da die ersten beiden (einfachen) Fälle offensichtlich zur Einarbeitung und Orientierung dienten, und nur die engagierteren 32 der 261 (~12%) Studierenden auch die weiteren Fälle freiwillig bearbeiteten. Diese Studierenden bearbeiteten dabei jeweils sowohl die einfachen als auch komplexen Fäll; daher ist nur bei ihnen ein Vergleich ihrer Bewertung zwischen den beiden Fallgruppen interessant. Wir klassifizierten Fälle als komplex, bei denen die Studierenden Untersuchungen mit hierarchischen Long-Menu-Fragen auswählen mussten, da die Auswahl der Untersuchung in allen diesen Fällen auch unmittelbar Auswirkungen auf die weitere Präsentation hatte: zu Untersuchungen, die die Studierenden nicht ausgewählt hatten, wurden ihnen auch keine Untersuchungsergebnisse präsentiert, so dass ihnen unter Umständen entscheidende Hinweise zur Diagnosestellung fehlten. Daher haben diese Fälle einen deutlich höheren Schwierigkeitsgrad als Fälle, bei denen die Studierenden immer alle relevanten Untersuchungsergebnisse präsentiert bekommen. Ein weiterer Unterschied zwischen „komplexen“ und „einfachen“ Fällen ist, dass die komplexen Fälle auch bei der Therapie LM-Fragen hatten, während die einfachen Fälle MC-Therapiefragen enthielten. Weiterhin hatten 4 der acht komplexen Fälle eine Folgesitzung (und keiner der einfachen Fälle) und auch die Frage nach Zwischendiagnosen war wesentlich komplexer als bei den einfachen Fällen.

Die Durchschnittwerte (Tabelle 1 [Tab. 1]) zeigten, dass die einfachen Fälle 4,6 Minuten (33,6%) weniger Bearbeitungszeit brauchten, sie um 9,8 Prozentpunkte (13,5%) besser gelöst wurden, die subjektive Bewertung der Leichtigkeit der Bedienung um 1,5 Punkte (25,4%) auf einer 15-stufigen Skala schwieriger und der Inhalt mit 0,7 um fast eine Schulnote (25,0%) schlechter bewertet wurden. Sowohl bei den objektiven Kriterien (Bearbeitungsdauer, Lösungsqualität) als auch den subjektiven Kriterien (Leichtigkeit der Bedienung, Bewertung der Fallqualität) schnitten die komplexen Fälle signifikant schlechter ab (zweiseitiger T-Test; α<0,05) Insbesondere die schlechtere Inhaltsbewertung der komplexeren Fälle ist überraschend, da in ihnen mehr inhaltliches Wissen steckt.

Fazit der Studie: Realistischere Fälle, d.h. Fälle, bei denen die Aufgaben ähnlicher sind zu dem Vorgehen eines Arztes bei der Patientenbehandlung sind nicht nur inhaltlich komplexer – wodurch ihre Bearbeitung mehr Zeit braucht –, auch die prozedurale Komplexität des Trainingssystems steigt. In der vorliegenden Fallstudie überwogen offensichtlich die Nachteile der Bedienkomplexität, was sich auch in der überraschend schlechteren inhaltlichen Bewertung der komplexeren Fälle ausdrückt: hier liegt die Vermutung nahe, dass die Schwierigkeiten bei der Bedienung das Vermitteln der Inhalte beeinträchtigt haben. Diese Vermutung wird auch durch die Freittextkommentare der Studierenden im Fallfragebogen unterstützt.

Man könnte nun die Möglichkeit in Betracht ziehen, die Lernenden an das Programm heranzuführen, indem man viele Fälle geringer Komplexität erstellt, die die Lernenden zuerst bearbeiten, bevor man sie mit den komplexen Fällen konfrontiert. Dieses Vorgehen hat aber mehrere Nachteile: Zum einen werden die Fälle meist begleitend zur Vorlesung eingesetzt, in der die verschiedenen Lerninhalte thematisch gegliedert sind und nicht gemäß der Komplexität der zugehörigen Fälle, d.h. schon der zweite Fall kann eine hohe Komplexität aufweisen. Zum anderen sollen die Fälle möglichst breit einsetzbar sein, also für Lernende mit unterschiedlichem Vorwissen, unterschiedlicher Kenntnis vom Trainingssystem, usw. Da vom grundsätzlichen Standpunkt inhaltlich komplexere Fälle mehr Wissen und auch die differentialdiagnostische Vorgehensweise besser vermitteln können, ist es notwendig, die inhaltliche Komplexität der Fälle unabhängig von der prozeduralen Komplexität des Trainingssystems variieren zu können, und es so ermöglichen, anspruchsvolle Inhalte auch den Lernenden näher zu bringen, die mit dem Trainingssystem nicht vertraut sind.

Wir zeigen in diesem Papier, wie wir die verschiedenen Arten von prozeduraler Komplexität im Trainingssystem d3web.Train an das Niveau der Lernenden anpassen können – unter anderem wird dabei das Konzept des Zustandsautomaten verwendet, um Komplexität zu erfassen und gezielt zu reduzieren und um die Lernenden an Fälle mit hoher prozeduraler Komplexität heranzuführen.

Ein Fall in d3web.Train umfasst die Behandlung einer Patientin oder eines Patienten, dabei wird zwischen der ausführlich gestalteten (ersten) Sitzung und Folgesitzungen, in denen die Therapieüberwachung behandelt wird, unterschieden.

Die erste Sitzung, kann dabei aus mehreren Abschnitten bestehen, typischerweise behandelt der erste Abschnitt Anamnese und körperliche Untersuchung, in den weiteren Abschnitte werden dann nach und nach die aufwändigeren, d.h. riskanteren oder teureren Untersuchungen durchgeführt und ausgewertet. In jedem Abschnitt können dabei die folgenden Aufgaben zur Bearbeitung gestellt werden:

• Untersuchungen anfordern: Es muss – auch unter Berücksichtigung von Kosten, Zeit und Patientenbelastung gewählt werden –, welche Untersuchungen aufgrund der momentanen Lage sinnvoll sind. Wenn eine Untersuchung angefordert wurde, dann werden die dabei gewonnenen Erkenntnisse in die Patientenakte eingetragen. Untersuchungen werden im hierarchischen Long-Menu-Format (HLM-Format) gestellt.
• Multimedia-Daten befunden: Wenn das Ergebnis einer Untersuchung eine Multimedia-Datei ist, dann muss die Lernerin bzw. der Lerner selbst den tatsächlichen Befund erheben.
• Befunde lokalisieren: Es genügt aber nicht, einen Befund nur anzugeben, man muss zusätzlich angeben, wo sich (auf einem Bild) ein Hinweis für diesen Befund findet.
• Diagnosen stellen: Aufgrund der Befunde sollte nun eine Diagnosestellung möglich sein, im HLM-Format sind nun Verdachtsdiagnosen und bestätigte Diagnosen auszuwählen.
• Diagnosen begründen: Auch hier ist eine einfach Angabe einer Diagnose noch nicht ausreichend. Es muss zusätzlich angegeben werden, welche Angaben (im Text der Patientenakte) für die angegebenen Diagnosen sprechen. Wird eine begründete Diagnose aufgrund weiterer Fakten zurückgezogen muss auch angegeben werden, was gegen diese vorher begründete Diagnose gesprochen hat.
• Therapien stellen: Passend zu den Diagnosen und den Angaben in der Patientenakte muss die richtige Therapie (ebenfalls im HLM-Format) gewählt werden.
• Freie Fragen beantworten: Mit MC-Fragen können grundsätzlich alle anderen Aufgaben nachgebildet werden, sie können aber auch ergänzend sinnvoll sein, z.B. wenn man nach Hintergrundwissen zu Untersuchungen fragt oder zu Einschränkungen für eine Therapie, also nach allen Inhalten, die mit den angegebenen Aufgaben nicht abgebildet werden können.

Folgesitzungen bestehen immer aus nur einem Abschnitt. Es werden die Ergebnisse der durchgeführten Untersuchungen präsentiert und es muss entschieden werden, ob sich an der Diagnose etwas geändert hat und ob die Therapie (entsprechend) modifiziert werden muss.

In den Abbildungen 1 [Abb. 1] und 2 [Abb. 2] ist ein Fallablauf mit den wichtigsten Stationen eines (relativ einfachen Falles) dargestellt.

Anhand der Betrachtung zweier exemplarischer Situationen der Benutzeroberfläche (Abbildung 3 [Abb. 3]) des Trainingssystems unterscheiden wir verschiedene Arten der prozeduralen Komplexität:

• Informationskomplexität: Wie viele Informationen werden dargestellt bzw. sind über das System zugänglich? In d3web.Train werden zwei Arten von Informationen angeboten: die Patientendaten (1) und Hintergrundinformationen (2).
• Bedienkomplexität: Welcher Aufwand ist nötig, um eine bestimmte Aufgabe mit den Interaktionsmöglichkeiten der Oberfläche zu bearbeiten? In der Abbildung kann man die Bedienelemente zur Auswahl einer Diagnose (3) und zum Erstellen eines Befundes (4) sehen.
• Navigationskomplexität: Wie aufwändig ist die Navigation zwischen den verschiedenen Aufgaben? Die Navigationsmöglichkeiten im Hauptfenster sind in der Abbildung mit (5) markiert, die des Multimedia-Fensters mit (6).

Ziel muss es nun sein, alle drei Arten von Komplexität so weit wie möglich zu reduzieren oder die Benutzerinnen und Benutzer bei ihrer Bewältigung optimal zu unterstützen.

Die inhaltliche Komplexität ist die am schwersten generisch reduzierbare Art von prozeduraler Komplexität, da sie größtenteils vom Fallinhalt vorgegeben ist. Dennoch gibt es in d3web.Train einige Möglichkeiten auch hier die Komplexität anzupassen:

Die Patientendaten eines Falles werden gesammelt in der durch – von der Untersuchungshierarchie bestimmten – Reitern strukturierten Patientenakte dargestellt. Dies ist die unserer Meinung nach optimale Darstellungsform. Dabei können die Lernenden auf verschiedene Arten schnell zwischen den Reitern wechseln. Außerdem können die Daten unterschiedlich komplex dargestellt werden, z.B. als Aufzählung der Fakten oder als Fließtext oder besonders angepasst, so können Labordaten auch wie in einem realen Laborausdruck angezeigt werden. Zusätzlich können die Lerner auch uninteressante Ergebnisse ausfiltern lassen oder diejenigen Ergebnisse ausblenden, die bei der aktuellen Aufgabe nicht interessieren.

Um den Aufwand für die Bearbeitung einer Aufgabe zu reduzieren, gibt es natürlich immer die Möglichkeit, diese Aufgabe nicht vom Lernenden lösen zu lassen. Sie kann dann vom System gelöst werden oder ganz ausgeblendet werden. Letzteres ist in d3web.Train bei allen Aufgaben möglich, das System kann so konfiguriert werden, dass eine Aufgaben, auch wenn sie vom Fall unterstützt wird, nicht angezeigt wird.

Nicht alle Aufgaben sind für alle Lernenden gleich gut geeignet. So ist das Auswählen von Untersuchungen eine Aufgabe, die bei Studierenden im vorklinischen Semester verfrüht ist, da ihnen noch der Überblick über die diagnostischen Möglichkeiten fehlt – vor allem was Kosten und Patientenrisiko betrifft. Es müssen aber immer Untersuchungen angefordert werden, damit es einen nächsten Fallabschnitt geben kann. In d3web.Train gibt es drei Alternativen für die Untersuchungsanforderung:

• Die Lernenden wählen die Untersuchungen selbst. Diese Alternative wird nur für Experten empfohlen, die sich über das Lehrbuch-mäßige Vorgehen hinwegsetzen wollen (und können).
• Die Untersuchungen werden vom Programm vorgegeben, d.h. beim Wechsel zum nächsten Abschnitt werden automatisch alle sinnvollen Untersuchungen vorgenommen und die (teilweise bildhaften) Befunde in die Patientenakte eingetragen.
• Die Untersuchungen werden nur in den ersten Abschnitten (der ersten Sitzung) vorgegeben (da hier sowieso meist ein generisches Vorgehen empfohlen wird). Im letzten Abschnitt wählen die Lernenden dann selbst aus den schwieriger zu entscheidenden technisch aufwändigeren Untersuchungen aus.

Eine Erweiterung der dritten Alternative wäre, dass die Lernenden in jedem Abschnitt aus einer bestimmten Teilmenge von Untersuchungen wählen könnten und beim Wechsel zum nächsten Abschnitt der Fall der Lernerin oder des Lerners mit dem von der Autorin oder dem Autor gewünschten Fallverlauf synchronisiert wird. Dieses Konzept kann in d3web.Train mit freien Fragen simuliert werden.

Untersuchungen, Diagnosen und Therapien wählt man im HLM-Format aus. Das HLM-Format ist zwar eine die Ordnung der Begriffe vermittelnde, dennoch aber komplexe und u.U. unübersichtliche Darstellung (etwa, wenn viele Äste aufgeklappt sind). Deshalb lassen sich bei diesen Aufgaben die Antworten auch auf andere Weise auswählen, wenn dies vom Fallautor so gewünscht wird: Es besteht die Möglichkeit der Freitexteingabe (inkl. Synonymsuche), der Suche nach Begriffen durch Eingabe von Teilworten oder einer Long-Menu-Auswahl. Die beiden Such-Arten können dabei ergänzend zu den Alternativen Baumstruktur (HLM) bzw. (flaches) Long-Menu angeboten werden. Zur weiteren Vermittlung der Begriffshierarchien kann man sich auch durch Texteingabe gefunden Begriff in der Baumstruktur anzeigen lassen.

Eine weitere Möglichkeit hier wäre es, Filter zu spezifizieren, mit denen ähnlich wie bei der oben besprochenen Auswahl von Untersuchungen, die Auswahl auf bestimmte Teilbereiche der Hierarchie eingeschränkt wird.

Bei der Auswahl von Diagnosen und Therapien muss die ausgewählte Diagnose bzw. Therapie noch weiter spezifiziert werden: Bei Diagnosen wird unterschieden zwischen „verdächtig“ und „sicher“, bei Therapien zwischen „sinnvoll“ und „indiziert“. Ob eine solche Spezifizierung notwendig ist, ist konfigurierbar, diese Komplexitätserhöhung kann also zur weiteren Erleichterung dieser Aufgaben abgeschaltet werden.

Wie schon bei der Beschreibung der Aufgabe „Freie Fragen beantworten“ angegeben, lässt sich jede Aufgabe durch eine oder mehrere Multiple- oder One-Choice-Fragen abbilden. Dies ist vor allem bei dem Stellen von Befunden sinnvoll. Hier werden normalerweise alle möglichen zu einer Untersuchung passenden Befunde als Alternativen angeboten. Dies können so viele sein, dass eine Auflistung aller Möglichkeiten schon aus Gründen der Aufgabendarstellung Probleme bereitet. Aus didaktischen Gründen ist aber meist eine Reduktion auf wenige Möglichkeiten sinnvoll, so dass dann die Befundung mit einer entsprechend formulierten eigenen MC/OC-Frage abgehandelt wird.

Werden aber alle Aufgaben durch MC/OC-Fragen emuliert, dann macht die Darstellung von d3web.Train wie in Abbildung 3 [Abb. 3] mit der Trennung in viele verschiedene Aufgaben wenig Sinn. d3web.Train kann dann so konfiguriert werden, dass die Patientenakte so angepasst wird, dass Multimedia-Daten direkt in den Text eingebunden sind (statt sie – wie eigentlich vorgesehen – mit den zugehörigen Aufgaben in einem eigenen Übersichtsfenster geordnet zusammenzufassen) und im Aufgabenbereich werden dann nur noch MC/OC-Fragen gestellt. Um der gebräuchlichen „Von-Links-Nach-Rechts“-Leserichtung gerecht zu werden, wird der Aufgabenbereich und die Patientenakte vertauscht und die (Minimal-)Navigation wandert nach rechts unten und beschränkt sich auf „Antworten eintragen und zur nächsten Frage“ bzw. „Antworten eintragen und zum nächsten Abschnitt“ bzw. „Antworten eintragen und Fall beenden“. d3web.Train wird damit zu einem sehr einfachen, quasi-seitenbasierten MC/OC Trainingssystem.

Neben der wirklich einschneidenden Methoden der Linearisierung (s.u.) lässt sich auch durch eine relativ einfach zu realisierende Adaptivität der Oberfläche eine Verringerung der Navigationskomplexität erreichen: Durch dynamisches Ausblenden oder Deaktivieren von Navigationsmöglichkeiten kann ein Teil der Komplexität vermieden werden, da die Lernenden sich dann nur zwischen den Aufgaben entscheiden müssen, die in der aktuellen Situation Sinn machen.

In d3web.Train wurde beides implementiert:

• Navigationsmöglichkeiten zu einer Aufgabe, die im gesamten Fall nicht verwendet wird, werden komplett ausgeblendet.
• Ist eine Aufgabe im aktuellen Abschnitt nicht möglich, dann wird die entsprechende Navigationsmöglichkeit deaktiviert. Wird dann zu einem Abschnitt gesprungen, in dem die Aufgabe genutzt wird, dann wird die zugehörige Navigationsmöglichkeit wieder aktiviert. Dies wird natürlich auch entsprechend visuell signalisiert (Schaltfläche wird bei Deaktivierung grau, bei Aktivierung farbig)

Wie beschrieben, bearbeiten die Lernenden in d3web.Train Trainingsfälle, bei denen sie in verschiedenen Fallabschnitten verschiedene Aufgaben bearbeiten müssen, zwischen diesen aber frei wählen können. Entscheidet sich eine Benutzerin bzw. ein Benutzer für die Bearbeitung einer Aufgabe, dann wechselt die Applikation in den dieser Aufgabe zugehörigen Modus, der durch Wahl einer anderen Aufgabe jederzeit wieder geändert werden kann.

Damit lässt sich der Ablauf gut als relativ einfacher Zustandsautomat [4] bzw. als UML-Zustandsdiagramm [5], [6] darstellen (Abbildung 4 [Abb. 4]). Es sind auch ausführlichere formale Beschreibungen von Trainingssystemen möglich [7], für unsere Zwecke genügt aber der Zustandsautomat.

Ein Zustandsdiagramm zeigt eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann, und gibt an, aufgrund welcher Ereignisse Zustandsänderungen stattfinden. Ein Zustand wird dabei als Rechteck mit abgerundeten Ecken dargestellt, ein Zustandsübergang durch einen Pfeil. Bedingungen für einen Zustandsübergang werden in eckigen Klammern in der Pfeilbeschriftung angegeben – auch die Ereignisse, die zu einem Zustandsübergang führen, werden dort notiert. Bei UML-Zustandsdiagrammen ist die Verwendung einer Reihe von Pseudozuständen möglich, wir beschränken uns in unseren Diagrammen aber auf die folgenden:

• Startzustand (●): In diesem Zustand startet der Automat, der erste Zustandsübergang wird sofort ausgeführt.
• Endzustand (): Gelangt der Automat in diesen Zustand, dann wird das zugehörige Objekt gelöscht.
• Entscheidung (): Ein Entscheidungsknoten dient dazu, eine Entscheidung, die beim Verlassen mehrerer Zustände vorkommt und daher mehrfach angegeben werden müsste, nur einmal anzugeben. Es werden die Bedingungen der abgehenden Zustandsübergänge ausgewertet und der entsprechende Zustandsübergang durchgeführt.

Übertragen auf unser Programm stehen die Zustände für den Modus, in dem sich das Programm während der Fallbearbeitung befindet. Die Ereignisse, die zu Zustandsänderungen führen, sind die Eingaben des Benutzers.

Wir unterscheiden bei unseren Zustandsdiagrammen allgemeine und konkrete Diagramme:

• In allgemeinen Diagrammen wird – aus Gründen der Übersichtlichkeit – nicht angegeben, wie viele verschiedene Abschnitte möglich sind. Außerdem wird nicht berücksichtigt, welche Aufgaben in einem bestimmten Abschnitt innerhalb eines Falles gestellt werden. Andernfalls müsste bei jedem Übergang zu dem zugehörigen Zustand eine Bedingung „[{Aufgabe} in {aktuellem Sitzungsabschnitt, aktueller Folgesitzung} vorhanden]“ eingefügt werden.
• Konkrete Diagramme beschreiben den Zustandsautomaten für einen bestimmten Fall. Hier wird zwischen gleichartigen Aufgaben in verschiedenen Abschnitten unterschieden. Ebenso werden nur die Zustände eingetragen, die auch möglich sind.

Um die Diagramme lesbar zu halten, wird bei Zustandsübergängen in einen Modus wie z.B. „Befunde lokalisieren“ das dazugehörige Ereignis „Benutzer wählt ‚Befunde lokalisieren’“ nicht angegeben. Es wird nur die Benutzeraktion „weiter“ angegeben, da diese von jedem Zustand aus aufgerufen werden und verschiedene Auswirkungen haben kann.

Ein konkreter Beispiel-Zustandsautomat für einen Fall aus dem Kardiologie-Kurs (s.o.), in dem nicht alle Aufgaben aus Abbildung 4 [Abb. 4] in jedem Abschnitt eingesetzt werden, ist in Abbildung 5 [Abb. 5] zu sehen.

Die Freiheit bei der Navigation zwischen den verschiedenen Aufgaben eines Abschnitts erhöht zwar den simulativen Aspekt des Trainingssystems. Ein tatsächliches freies Hin- und Herspringen macht aber inhaltlich nur wenig Sinn. Es stellt sich also die Frage, ob man dennoch diese Freiheit gewährt oder ob man zugunsten einer verminderten Navigationskomplexität diese so weit einschränkt, dass zwar immer noch alle verschiedenen Aufgaben-Typen verwendet werden, die Reihenfolge aber so festgelegt wird, wie sie sich natürlich aus der Beschreibung der Aufgaben ergibt, nämlich:

Untersuchungen anfordern → Bilder befunden → Befunde lokalisieren → Diagnosen stellen → Diagnosen begründen → Therapien stellen (→ Abschnittswechsel)

Damit die freien Fragen entsprechend in den Ablauf einsortiert werden können, muss ihre Semantik festgelegt werden.

Die Benutzeraktion „weiter“, die im nicht-linearisierten Ablauf zum Abschluss des aktuellen Abschnitts führt, dient im linearisierten Ablauf dazu, jeweils zum gemäß der Reihenfolge nächsten Zustand zu gelangen.

Das zugehörige im Vergleich zu Abbildung 4 [Abb. 4] vereinfachte Zustandsdiagramm ist in Abbildung 6 [Abb. 6] dargestellt. Angewandt auf den gleichen Fall wie in Abbildung 5 [Abb. 5] dargestellt ergibt sich der abschnittsweise lineare Verlauf in Abbildung 7 [Abb. 7]. Man kann unschwer erkennen, dass die Freiheiten bei der Navigation erheblich eingeschränkt wurden.

Das Trainingssystem ist damit auch fast-seitenbasiert, allerdings werden eben nicht nur Multiple-Choice-Fragen verwendet, sondern besser geeignete Aufgaben, wie HLM-Format, Diagnosebegründung im Text, Befundlokalisation, usw., die d3web.Train zur Verfügung stellt.

Der eingeschränkte Zustandsautomat lässt sich aber nicht nur für einen linearisierten Ablauf nutzen. Um einerseits die Freiheit des Lernenden zu erhöhen und damit die Applikation wie erwünscht explorierbar zu halten, andererseits aber doch dafür sorgen zu können, dass sich die Lernenden an den gewünschten Ablauf halten, können durch den Einsatz eines adaptiven Hilfeagenten wie bisher alle Navigationsmöglichkeiten zur Verfügung gestellt werden, die Lernenden erhalten vom Hilfeagenten aber Hinweise, wenn sie den idealen Bearbeitungspfad verlassen.

Der adaptive Hilfeagenten wurde bereits in anderen Papieren [8], [9] vorgestellt und wird hier nur kurz beschrieben (schematische Darstellung siehe Abbildung 8 [Abb. 8]):

Mittels eines Overlay-Modells wird erfasst, wie gut die Lernenden bestimmte Bedienkonzepte verstanden haben, dabei wird zwischen Konzepten über das Wann einer Aufgabe und solchen über das Wie einer Aufgabe unterschieden. Dazu werden alle Aktionen der Lernenden erfasst und mittels Regeln die verschiedenen (auch voneinander abhängenden) Konzepte im Overlay-Modell bewertet. Sobald ein Konzept als zu schlecht verstanden erkannt wird, wird die letzte Aktion – die zu dieser schlechten Bewertung geführt hat – unterbrochen und es erscheint der Hilfeagent mit einem entsprechenden Hinweis. Weil die Lernenden diesen Hinweis lesen, wird optimistisch angenommen, dass sie nun das angesprochene Konzept besser verstehen.

Die Regeln, mit denen erkannt wird, ob das Wie einer Aufgabe verstanden wurde, lassen sich nicht aus einem der obigen Zustandsautomaten ableiten, dazu müssten auch alle möglichen Zwischenzustände berücksichtigt werden. Wie dies möglich ist, ist in [8] genauer beschrieben.

Die Regeln, die den richtigen Zeitpunkt einer Aufgabe betreffen, lassen sich dagegen direkt aus den Zustandsdiagrammen generieren. Die Anwendung dieser Regeln führt zum Beispiel dazu, dass nach dem Anfordern von Untersuchungen, bei denen Multimedia-Daten für die Befundung durch die Lernenden in die Patientenakte eingefügt werden, es als Fehler erkannt wird, wenn die Lernenden zur Aufgabe „Diagnosen stellen“ springen, anstatt zunächst die Bilder zu befunden.

Wir versprechen uns durch die Reduktion der Komplexität eine größere Akzeptanz des Systems bei unerfahrenen Lernenden. Eine Studie, die beim Einsatz von d3web.Train zur ärztlichen Fortbildung im Rahmen eines Rheumatologie-Workshops durchgeführt aber noch nicht veröffentlicht wurde, zeigt, dass das System mit weit reduzierter Bedien- und Navigationskomplexität (automatische Auswahl von Untersuchungen, Emulation aller Aufgaben durch freie Fragen) trotz hoher inhaltlicher Komplexität auch von den wenig computer-affinen Teilnehmerinnen und Teilnehmern sehr gut akzeptiert wurde.

Es lassen sich jedoch nicht alle Aufgaben sinnvoll durch MC/OC-Fragen mit wenigen Antwortalternativen ersetzen, der Einsatz von solchen Fragen ist auch nicht ohne Kritik [10]. Damit die Lernenden nicht nur die korrekten Antworten erkennen können, sondern dabei auch die zugehörige Begriffshierarchie erlernen, ist es meist sinnvoller, Untersuchungen, Diagnosen und Therapien nicht in Form von MC/OC-Fragen abzufragen sondern in einer der weiter oben beschriebenen komplexeren Formen. Bei Diagnosen ist dies vor allem zu Beginn des Falles, wo noch sehr viele Diagnosen verdächtigt werden können, sinnvoller. Auch die Lokalisation von Befunden, bei der die Lernenden auf den Befund hinweisende Areale des Bildes markieren müssen, lässt sich nur umständlich, durch mehrfache Fragen und nur mittels vorbereiteter Bilder auf MC/OC-Fragen abbilden.

Wir benutzen zwar auch bei den komplexeren Bedienalternativen wie oben beschrieben den Hilfeagenten, indem wir feinere Zustände des Systems betrachten – dies ist aber nur begrenzt möglich, und wird zusätzlich dadurch erschwert, dass Bedienschwierigkeiten oft nicht klar aus Benutzeraktionen gefolgert werden können. Deshalb muss hier mit gängigen Mitteln (Benutzerhandbuch, Online-Hilfe, …) weitere Unterstützung angeboten werden.

Auch bei der Reduktion der Navigationskomplexität ist eine Linearisierung nicht immer sinnvoll, denn eigentlich kann auch die Schleife aus Untersuchungen → Befunde → Diagnosen → Therapie innerhalb eines Abschnitts öfters durchlaufen werden. Eigentlich sollte dies nur einmal pro Abschnitt möglich sein, es wäre aber dann oft mühsam, den Fall in sehr viele sehr kurze Abschnitte aufzuteilen, in denen dann jeweils nur eine Untersuchung angefordert werden würde. In komplexeren Fällen – vor allem wenn bei einer Patientin oder einem Patient mehrere Krankheiten auf einmal vorliegen – ist es daher sinnvoller, die Wiederholung dieser Schleife innerhalb eines Abschnittes zu ermöglichen. Zudem kann es sinnvoll sein, vor der Festlegung einer Therapie festzustellen, ob diese überhaupt verträglich ist. In diesen Fällen kommt dann besser der adaptive Hilfeagent zum Einsatz.

Ein Vorteil des Konzeptes von Freiheiten bei der Navigation, aber Lenkung durch den Hilfeagenten ergibt sich auch dadurch, dass der Hilfeagent so konfiguriert werden kann, dass er möglichst unaufdringlich arbeitet, d.h. wenn die Lernenden darauf hingewiesen wurden, dass eine bestimmte Aufgabe jetzt eigentlich an der Reihe wäre und die Lernenden dennoch eine andere Aufgabe zuerst ausführen, dann wird der Hilfeagent nicht sofort wieder intervenieren, sondern vielleicht erst nach mehrmaligem Verstoß gegen den idealen Ablauf.

Evaluationen [3] haben auch gezeigt, dass Studierende das Trainingssystem nicht nur zum Durcharbeiten der Fälle als Ganzes nutzen. So kommt es z.B. vor, dass nur bestimmte Aufgaben wie das Stellen der Befunde anhand von Multimedia-Daten wiederholt werden. Dann wird das Stellen von Diagnosen immer übersprungen und sofort nach dem Befunden der Bilder in den nächsten Abschnitt gewechselt. Wenn dieses Vorgehen durch Unterbrechungen unmöglich gemacht wird, verlieren die Benutzerinnen und Benutzer den Spaß an der Arbeit mit dem Programm. Dies ist auch ein wichtiger Grund, warum dem Konzept von Freiheit und Lenkung gegenüber dem Konzept der Linearisierung bei erfahreneren Lernenden der Vorrang zu geben ist: Diese haben bereits lange genug mit dem System gearbeitet um zu wissen, was wann zu tun ist, können sich aber die Freiheit erlauben, dieses Wissen zu ignorieren.

Anfängern dagegen kommt eher die Linearisierung entgegen: Hier wird ihnen die (noch wenig verständliche) Wahl der nächsten Aufgabe abgenommen. Wichtig ist hier nur, dass klar ersichtlich ist, welche Aufgabe gerade bearbeitet wird, damit diese später im Modus für erfahrenere Benutzerinnen und Benutzer identifiziert und selber gewählt werden kann. Wie dies gegenüber den jetzigen nicht-linearisierten Fällen angenommen wird, wird in einer künftigen Studie geklärt werden müssen.

Die Beschreibung des Fallablaufs als Zustandsautomat kann aber auch unmittelbare Vorteile für die Fallautorinnen und -autoren bringen: Haben diese die Möglichkeit, den Fallablauf und die Konfiguration des Trainingssystems getrennt vom Fallinhalt deklarativ zu beschreiben, können (inhaltlich komplexe) Fälle weitestgehend an die Anforderungen spezifischer Benutzergruppen angepasst werden. Für die Konfiguration von d3web.Train steht den Autorinnen und Autoren schon eine entsprechende Eingabemöglichkeit zur Verfügung, für die Beschreibung des Fallablaufs muss diese noch realisiert werden.