gms | German Medical Science

GMS Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS)

ISSN 1860-9171

Konzeption und Evaluation eines fallbasierten Trainingssystems im universitätsweiten Einsatz (CaseTrain)

Conception and evaluation of a case-based training system for university-wide adoption (CaseTrain)

Originalarbeit

  • corresponding author Alexander Hörnlein - Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik, Julius-Maximilians-Universität, Würzburg, Deutschland
  • author Marianus Ifland - Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik, Julius-Maximilians-Universität, Würzburg, Deutschland
  • author Peter Klügl - Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik, Julius-Maximilians-Universität, Würzburg, Deutschland
  • author Frank Puppe - Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik, Julius-Maximilians-Universität, Würzburg, Deutschland

GMS Med Inform Biom Epidemiol 2009;5(1):Doc07

doi: 10.3205/mibe000086, urn:nbn:de:0183-mibe0000861

Published: February 25, 2009

© 2009 Hörnlein et al.
This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.en). You are free: to Share – to copy, distribute and transmit the work, provided the original author and source are credited.


Zusammenfassung

Basierend auf umfangreichen Erfahrungen mit fallbasierten Trainingssystemen in der Medizin werden Anforderungen, Umsetzung und eine universitätsweite Evaluation des fachübergreifenden Players und Autorensystem für fallbasiertes Training CaseTrain präsentiert. Die wichtigsten Erfolgsfaktoren waren (1) die Falleingabe mit Standardtextsystemen und einer Webapplikation zum Upload der Falldokumente und zur Fallverwaltung, (2) die Integration mit einer Lernplattform und (3) die curriculare Integration der Trainingsfälle mit automatisierten Evaluationstechniken.

Abstract

Based on previous experiences with systems for case-based training in medicine, requirements, implementation and university wide evaluation of the multidisciplinary player and authoring tool for case-based training CaseTrain are presented. Key factors for its success were (1) the facility, to author training cases with standard text systems and to manage case upload with a web based management tool, (2) the tight integration with a learning management platform, (3) an emphasis on curricular integration of the cases and automatic evaluation facilities.

Keywords: needs assessment, problem-based learning, educational measurement, rapid e-learning


1 Fragestellung und Motivation

Die Bearbeitung virtueller Problemfälle kann in der Lehre nicht nur in der Medizin vielfältig eingesetzt werden: Als Ergänzung zum systematischen Unterricht, indem echte oder didaktisch aufbereite Probleme als Übungsaufgaben angeboten werden oder im Rahmen des problembasierten Lernen, bei dem die Studierenden fehlendes Wissen zur Lösung der Probleme recherchieren und diskutieren sollen. Zahlreiche Studien haben eine hohe Akzeptanz bei Studierenden gezeigt [1]. Allerdings hängt die Verbreitung dieser Lehrform entscheidend von dem Aufwand für Dozenten ab, Problemfälle leicht zu erstellen oder vorhandene Problemfälle für ihre Lehrveranstaltungen zu adaptieren. Dafür sind spezielle Autorensysteme vorteilhaft. Ein Beispiel ist das Autoren- und Ablaufsystem d3web.Train [2], in dem Dozenten durch Annotation von Word-Dokumenten neue Fälle selbst erstellen können. Die resultierenden Trainingssysteme wurden u.a. in der Rheumatologie [3] und der Hämatologie [4] erfolgreich in der medizinischen Lehre an der Universität Würzburg eingesetzt und positiv evaluiert. Anfang 2007 stellte sich im Rahmen eines fachübergreifenden Blended Learning-Projektes der Universität Würzburg zum Einsatz fallbasierter Trainingssysteme die Frage, ob das vorhandene System auch außerhalb der Medizin eingesetzt werden kann oder ob eine Neuentwicklung Erfolg versprechender ist.


2 Anforderungsanalyse

In mehreren Sitzungen mit Dozenten der Universität Würzburg aus den Fächern Medizin, Jura, Wirtschaftswissenschaften, Psychologie, Pädagogik, Geographie, Bioinformatik u.a. wurden anhand der Diskussion beispielhafter Trainingsfälle (z.B. Diagnose und Therapie virtueller Patienten; die inkrementelle Erstellung einer Gliederung zur Lösung juristischer Fälle in den ersten Semestern; die Vorgehensweise zur Lösung betriebswirtschaftlicher Probleme; Fälle aus der klinischen Psychologie wie Diagnostik einer Angststörung; die Bewertung von per Video gezeigten Unterrichtssequenzen in der Pädagogik oder die inkrementelle Auswertung vorgegebener statistischer Daten, um eine bestimmte Hypothese zu prüfen) folgende organisatorische und technische Anforderungen an ein fachübergreifendes System zum fallbasierten Lernen gestellt, das sich an verschiedene didaktische Ansprüche aus unterschiedlichen Fächern adaptieren lässt:

2.1 Organisatorische Aspekte

  • Es sollen kurze Fälle erstellt werden, die in ca. 5–15 Minuten lösbar sind. Diese sind – wie Evaluationen in der Medizin gezeigt haben – für die Studierenden attraktiver und auch für die Dozenten leichter erstellbar. Hintergrundwissen soll nicht im Fall eingebunden sondern über Links angebunden werden, damit es wiederverwendbar ist.
  • Die Fälle müssen curricular eingebunden werden und sollten auch zur Vorbereitung von Prüfungen dienen. Das hat zwei Konsequenzen für das Autorensystem: Alte Prüfungssammlungen sollen leicht eingebunden werden können und die Fragen bzw. Fälle sollten leicht adaptierbar sein, um sie aktuell zu halten.
  • Die Studierenden sollen die Fälle online bewerten können.
  • Das System soll ohne Anleitung bedienbar sein und auf allen gängigen Browsern laufen.

Das Trainingssystem ist so ausgelegt, dass es in eine Lernplattform integriert ist und von dieser aufgerufen wird. Daher sollen Funktionen, die eine Lernplattform standardmäßig anbietet, nicht dupliziert werden (z.B. Kommunikation wie Email, Chat und Diskussionsforen, Studentenverwaltung, Bereitstellung von Vorlesungsmaterialien usw.).

2.2 Technische Aspekte des Fallplayers

  • Ein Fall besteht aus einer Menge von Situationsbeschreibungen und Fragen dazu. Die Situationsbeschreibungen bauen aufeinander auf. Sie enthalten Text mit eingebetteten Multimedia-Elementen (Bilder, Videos, Audio).
  • Ein typischer Fall hat eine lineare Sequenz von Situationsbeschreibungen. Darüberhinaus gibt es die Option, dass die Studierenden zusätzliche, zur Falllösung benötigte Informationen zum Fall aus einer Liste angebotener Untersuchungen selbst frei auswählen müssen und dann nur die Informationen der ausgewählten Untersuchungen angezeigt bekommen (sowie ein direktes Feedback, ob die Untersuchungsauswahl insgesamt sinnvoll war).
  • Es gibt verschiedene Fragetypen: MC-Fragen, numerische Fragen, Long-Menu-Fragen, hierarchische Long-Menu-Fragen oder Wort-Fragen. Weitere Fragetypen sollen leicht ergänzt werden können.
  • Für (hierarchische) Long-Menu-Fragen sollen wiederverwendbare Terminologien benutzt werden können (z.B. bei Fragen nach Diagnosen oder Untersuchungen, bei denen die Liste der möglichen Diagnosen für verschiedene Fragen dieselbe ist, aber mit unterschiedlichen korrekten Antworten).
  • Fragen sollen differenziert bewertet werden können: Das umfasst relative Gewichtungen für verschiedene Fragen eines Falles und ein differenziertes Bewertungsschema, um halbrichtige Antworten zu einer Frage angemessen bewerten zu können.
  • Bei Wortfragen soll die Möglichkeit bestehen, Tipp- oder Rechtschreibfehler bei der Eingabe bezüglich der Auswertung zu tolerieren, wobei der Autor bei der Fallerstellung die Toleranzgrenze individuell bestimmen kann (z.B. in Form einer maximalen Levenshtein-Distanz für jede Antwort).
  • Bei falsch oder teilweise falsch beantworteten Fragen soll der Student ein ausführliches Feedback bekommen, das neben den richtigen Antworten und einer Erläuterung des Bewertungsschemas auch Kommentare enthalten kann.
  • Der Student kann eine Frage nur einmal beantworten, also nicht zurückspringen. Er soll aber eine Übersicht über den bisher bearbeiteten Fall mit allen Informationen, Fragen und gegebenen Antworten einschl. deren Bewertung bekommen.
  • Aus der Summe aller beantworteten Fragen und ggf. der Bearbeitungszeit wird ein Score pro Fall gebildet, der mittels Schwellwert auf erfolgreich gelöst/nicht gelöst abgebildet werden kann. Die Information soll an die umgebende eLearning-Plattform gemeldet werden und kann in den Lehrveranstaltungen z.B. als Voraussetzung zur Klausurzulassung abgefragt werden.
  • Das System soll statistische Auswertungen für den Dozenten unterstützen, z.B. wie gut einzelne Fragen im Durchschnitt beantwortet wurden und wie viel Zeit Studierende zur Beantwortung der einzelnen Frage im Durchschnitt benötigen.
  • Jeder Fall soll eine Einleitung und einen pädagogischen Abschlusskommentar haben.

2.3 Technische Aspekte des Autorensystems

  • Das Autorensystem soll ohne spezielle Vorkenntnisse bedienbar sein, da Dozenten eher gelegentlich daran arbeiten. Es soll daher auf Standardtextsystemen aufbauen.
  • Die Text- und Mediendateien sollen über das Web hochgeladen und automatisch in einen ablauffähigen Fall umgewandelt werden können, ggf. auftretende Fehler sollen übersichtlich dargestellt werden, so dass die Verbesserungszyklen kurz sind.
  • Es soll ein Workflow mit Roherstellung, Überprüfung und Freigabe eines Falles durch verschiedene Personen unterstützt werden.

Eine Evaluation den Autoren bekannter Autorensysteme zeigte, dass kein Werkzeug alle Anforderungen erfüllt (vgl. auch die Dissertationen [2] und [5]). Mindestens eine der folgenden Bedingungen war nicht erfüllt:

  • Verfügbarkeit spezifisch fallbasierter Elemente (insbesondere aufeinander aufbauende Situationsbeschreibungen mit freier Informationsauswahl und Long-Menu-Fragetypen z.B. für Diagnose- und Untersuchungsfragen mit wiederverwendbarer Terminologie).
  • Einfaches Autorensystem für Gelegenheitsautoren basierend auf Standardtextsystemen und Web-Upload-Schnittstelle und einfaches Ablaufsystem für Studierende, das ad-hoc bedienbar ist.
  • Keine Beschränkungen wie Spezialisierung des Autorensystems auf bestimmte Domänen oder Verfügbarkeit des Trainingssystems nur in bestimmten Browsern

3 Konzeption und Implementierung

Im Folgenden beschreiben wir die konzeptionelle Umsetzung der Anforderungen. Gemäß dieser Konzeption und basierend auf den Erfahrungen mit d3web.Train, CASUS [6] und CAMPUS [7] wurde mit CaseTrain [8] ein neues Verwaltungs- und Ablaufsystem entwickelt. Diese Implementierung wird anhand einiger Screenshots von CaseTrain demonstriert.

3.1 Autorensystem

Als Standardtextsystem für die Fallerstellung wurde wegen seiner Verbreitung Microsoft® Word™ gewählt, wobei auch andere Systeme wie etwa OpenOffice.org Writer [9] oder iWork Pages [10] zum Einsatz kommen können, solange sich damit .doc-Dateien erzeugen lassen. Die Eingabe erfolgt mittels einer tabellarischen Schablone, die die Textkategorien (z.B. Infotext, Fragen, Antworten) vorgibt. Die Fallinhalte werden in der Tabelle mit Hilfe weniger Schlüsselwörter und einfacher Textauszeichnungen (u.a. Fett-Markierung, Zeilenumbruch) eingegeben (Abbildung 1 [Abb. 1]). Da Microsoft Word auch eine Nachverfolgung von Änderungen unterstützt, wird mit diesem Format eine komfortable gemeinsame Falldokumenterstellung mehrerer Autoren ermöglicht. Illustrationen können einfach in das Dokument eingefügt werden, sonstige Medien (Videos, PDF-Dokumente, …) und fallübergreifend verwendete Inhalte werden gemeinsam mit dem Dokument in einem Archiv verpackt, das dann als Ausgangspunkt für einen neuen fertigen Fall oder eine neue Version eines vorhandenen Falles dient.

Das Extrahieren der Falldaten aus den Worddokumenten geschieht durch den ebenfalls an der Universität Würzburg entwickelten TextMarker. Das TextMarker-System [11], [12] ist ein Tool für die Extraktion von Informationen, die Segmentierung und die Manipulation von Texten. Mit der regelbasierten Skriptsprache des Systems wird versucht, das übliche menschliche Vorgehen bei der Verarbeitung von Texten nachzuahmen: Oft werden relevante Information mit einem Farbstift hervorgehoben oder zusätzliche Informationen in Form von Notizen hinzugefügt. Diese Textstellen werden dann für eine weitere Verarbeitung genauer betrachtet.

Das wichtigste Sprachelement der TextMarker-Sprache ist die Regel. Eine TextMarker-Regel besteht aus einer beliebigen Anzahl von Regelelementen. Ein Regelelement enthält wiederum drei unterschiedliche Komponenten. Die notwendige Grundkondition bestimmt die Textstelle und deren Typ, welche von der Regel betrachtet werden soll. Zusätzliche kann ein Regelelement mehrere Konditionen und/oder Aktionen enthalten. Die Konditionen überprüfen die Textpassage auf weitere notwendige Eigenschaften. Die Aktionen verarbeiten die betrachtete Textstelle, indem der Textstelle ein neuer Typ zugewiesen wird, diese farblich hervorgehoben oder verändert wird oder Log-Informationen bezüglich dieser Textpassage ausgegeben werden.

TextMarker erwartet als eigentliche Eingabe Text-Dateien, deswegen wird das Word-Dokument zunächst (durch Anbindung des Open-Source-Projects OpenOffice.org) in einfaches HTML konvertiert. Dieses und die beiden optionalen Text-Dokumente – für long-menu-Fragen und die Untersuchungsauswahl – werden an TextMarker übergeben und durch jeweils eine TextMarker-Regeldatei verarbeitet. Als Ausgabe für den Benutzer werden für jede Eingabedatei Log-Informationen und eine annotierte Version der Eingabe erstellt. Als Ausgabe für die Weiterverwendung im CaseTrain-Player erzeugt TextMarker ein XML-Falldokument (Abbildung 2 [Abb. 2]) und ggf. (aus den Inhalten der beiden optionalen Text-Dokumenten) ein XML-Terminologie-dokument.

TextMarker ist zwar eigentlich für die Extraktion von Informationen und nicht für das Parsen von Dokumenten mit fest vorgegebener Struktur entwickelt worden, bietet aber viele Vorteile gegenüber starren Parsern. Durch die regelbasierte Sprache können Änderungen am Fallformat schnell und einfach integriert werden. Das dynamische Filtern des Eingabetextes ermöglicht eine robuste Extraktion der Informationen. Falls jedoch Informationen nicht sicher erkannt werden können, erzeugt TextMarker eine farbliche Markierung im Text. Durch dieses Feedback (Abbildung 3 [Abb. 3]) kann der Autor sehr einfach die vorhandenen Fehler finden und korrigieren.

Nach der Anwendung von Textmarker wird in den fertigen Fall ggf. noch ein Evaluationsabschnitt eingefügt (s.u.) und der Fall über seine Metadaten in der Fallbasis gespeichert. Abschließend wird der Fall mit der jeweils aktuellen Fallplayer-Version verknüpft so dass bei einer Aktualisierung des Fallplayers (z.B. aufgrund einer Änderung des Fallformats) keine Inkompatibilitäten auftreten können.

3.2 Wiederverwendbarkeit der Fälle

Durch Verwendung eines XML-Formats ist ein einfacher Austausch von Fallinhalten mit anderen fallbasierten Trainingssystemen mit nicht-prozedural definiertem Fallformat möglich. So ist z.B. eine Konvertierung in das XML-basierte MedicML-Format [13], [14] prinzipiell möglich, wobei das vorliegende XML-Format Fachgebiets-unspezifisch ist und eine Umsetzung in das auf medizinische Fälle spezialisierte MedicML deshalb Zusatzwissen erfordert. Die Konvertierung wurde eingesetzt, um Fälle aus d3web.Train, die ebenfalls auf einem XML-Format basieren, in CaseTrain nutzen zu können.

3.3 Fallverwaltung

Für die Fallerstellung und Verwaltung wurde die Webanwendung CaseTrain-Manager entwickelt. Um die in Abschnitt 2.3 gestellten Anforderungen erfüllen zu können, verfügt CaseTrain-Manager über Versionsverwaltung, Datenablage, Benutzerverwaltung mit Unterstützung mehrerer Rollen, eine Anbindung an die zentrale, auf Moodle [15] basierende eLearning-Plattform der Universität Würzburg wuecampus [16] und eine Statistikkomponente zur Erfassung und graphischen Auswertung der Fallbearbeitungen.

Der CaseTrain-Manager ist – wie der Fallplayer auch – browserunabhängig. Durch Anbindung an die LDAP-Benutzerverwaltung sind spezielle Benutzerdaten nicht zwingend nötig (aber möglich), die Autoren können sich also mit ihrem universitätsweiten Benutzeraccount anmelden. Mittels spezieller Skripte, die von wuecampus bereitgestellt werden, ist es möglich, Fälle vom CaseTrain-Manager aus einfach in wuecampus-Kurse einzubinden bzw. den Zustand dieser Verknüpfungen zu überwachen.

Ein Dozent kann Fälle zu Fallsammlungen zusammenfassen, die jeweils mit einem wuecampus-Kurs verknüpft sind, welcher wiederum einer Lehrveranstaltung zugeordnet ist. Rechte/Rollen werden immer für eine Fallsammlung gesetzt. Folgende Rollen können vergeben werden:

  • Dozent (Besitzer): Dozenten können eine Fallsammlung löschen, die Rechte vergeben und die Besitzrechte an andere Benutzer übertragen, zudem verfügen sie natürlich auch über alle weiteren Rechte an der Fallsammlung
  • Hilfskraft (Schreibrechte): Hilfskräfte können neue Fälle erstellen, neue Versionen von Fällen erstellen, Fälle löschen und auf Benutzungsstatistiken zugreifen
  • Reviewer (Freigaberechte): Diese Rolle ist für Reviewer, die nur Fälle freigeben können.
  • Supervisor (Recht zur erweiterten Dateneinsicht): Dieses Recht erlaubt den Einblick in die Nutzungsstatistiken, die Rechte für diese Fallsammlung und in die Historie dieser Fallsammlung (also wann wurde ein Fall erstellt, geändert, gelöscht, …).
  • Leserechte: Damit erhalten Benutzer Zugriff auf alle Dokumente und Fälle der entsprechenden Fallsammlung. Aktuell haben alle Benutzer Leserechte an allen Fallsammlungen, damit noch unerfahrene Autoren von Fällen aus vielleicht inhaltlich fremden Fallsammlungen aber mit ähnlichem Fallaufbau lernen können.

Darüber hinaus gibt es noch eine Administrator-Rolle, die Zugang zu einer umfassenden Statistik und der vollen Benutzerverwaltung gewährt. Zudem hat der Administrator implizit Besitzrechte an jedem Kurs.

Mehrere Benutzer mit Rechten an einer Fallsammlung werden gegenseitig – soweit sinnvoll – von ihren Aktionen per Mail informiert. Damit und mit einer dynamischen Oberfläche wird folgender Workflow in unterstützt:

1.
Dozent lädt Rohfall hoch und fordert Weiterbearbeitung an.
2.
Hilfskraft erstellt korrekten Fall und fordert Freigabe an.
3.
Peer-Reviewer erhält per Mail URL zur Fallbegutachtung und gibt den Fall frei (oder lehnt die Freigabe ab, woraufhin Dozent und Hilfskraft informiert werden).
4.
Hilfskraft (und Dozent) wird über Freigabe informiert und macht den Fall im zugehörigen wuecampus-Kurs zugänglich.
5.
Studierende bearbeiten den Fall und können Fragen im Kurs-eigenen Fragen-Forum stellen.
6.
Hilfskraft erhält Mail und beantwortet die Frage (oder leitet die Frage an den Dozenten weiter).
7.
Studierende werden über Antwort informiert.

Bei der Fallerstellung, d.h. dem Schritt, bei dem aus Dokumenten ablaufbare Fälle werden, werden zuerst alle Fallinhalte (Dokumente, Medien, …) für das Einlesen der Fallinhalte und die Verwendung im Fall vorbereitet: Das Falldokument wird in eine HTML-Zwischenrepräsentation konvertiert, integrierte Bilder werden extrahiert, konvertiert und ggf. skaliert, Videos und Audiodateien werden in ein vom Fallplayer unterstütztes Format konvertiert und entsprechende Dateistrukturen werden erstellt.

3.4 Fallplayer

Die Implementierung des Fallplayers CaseTrain-Player erfolgte in Adobe Flash 9, in welchem mit ActionScript 3.0 [17] – im Gegensatz zu Version 8 mit ActionScript 2.0 – eine streng objektorientierte Programmiersprache zur Verfügung steht. Er ist damit webbasiert, plattformunabhängig und sieht auf allen gängigen Browsern selbst bei aufwändigeren Effekten stets identisch aus. Es wurde viel Wert darauf gelegt, dass er einfach und ohne Einarbeitung zu bedienen ist, indem nur wenige, leicht als solche zu erkennenden Schaltflächen zur Verfügung stehen, deren Funktion zudem leicht erfassbar ist. Es werden alle Anforderungen aus 2.2 unterstützt. Abbildung 4 [Abb. 4] zeigt die Rückmeldung an den Lerner nach Beantwortung einer Frage, wobei seine Antwort bewertet und ein Autorenkommentar gegeben wird sowie die Gesamtbewertung einer Fallbearbeitung.

3.5 Evaluation

Um eine kontinuierliche Verbesserung der Inhalte und der Technik ermöglichen zu können findet die Evaluation auf vier Ebenen statt:

  • Fallbearbeitungsprotokolle (Log-Daten)
  • Kurzer Evaluationsfragenabschnitt am Ende jeder Fallbearbeitung
  • Ausführlicher Evaluationsfragebogen nach jedem Kurs
  • Analyse der Prüfungsergebnisse
Erfassung der Fallbearbeitungen (Log-Daten)

Jede Aktion des Lerners, insbesondere der Fallstart, die Beantwortung von Fragen, das Starten eines neuen Abschnittes usw. wird vom CaseTrain-Player zur Laufzeit protokolliert. Diese Informationen werden dann während des Fallverlaufs an die Statistik-Komponente des CaseTrain-Managers übertragen, so dass später eine genaue Auswertung möglich ist: Anhand dieser Daten können sowohl detaillierte objektive Statistiken über die Nutzung bestimmter Funktionen des Fallplayers (Zusammenfassung aufrufen, Hintergrundwissen öffnen, Kommentar öffnen usw.), als auch für den Fallautor interessante Statistiken über die Beantwortung einzelner Fragen erhoben werden. Wenn bei der Bereitstellung des Falles in der eLearning-Plattform wuecampus die Anonymisierung nicht aktiviert wird, kann jede Fallbearbeitung eindeutig einem Studierenden zugeordnet werden, was eine individuelle Auswertung ermöglicht.

Fallinterne Evaluationsfragen

Autoren können im Falldokument auch abschließende Evaluationsfragen definieren. Tun sie dies nicht, dann wird in den fertigen Fall ein kurzer Standard-Evaluationsabschnitt eingefügt – es sei denn der Autor schaltet das explizit im CaseTrain-Manager ab. Dieser ist konfigurierbar, derzeit aber nur sehr kurz um eine möglichst hohe Rücklaufquote zu erreichen: Er umfasst nur eine Schulnote für Bedienbarkeit des Fallplayers und eine für Qualität der Fallinhalte sowie die Möglichkeit eines Freitextkommentars. Die Evaluationsantworten werden mit den Fallbearbeitungen erfasst, wie die übrigen Fragen mittels der Statistik-Komponente unmittelbar ausgewertet und geben dem Fallautoren so ein unkompliziertes, direktes Feedback.

Kursevaluation

Jeder Dozent eines Kurses, bei dem CaseTrain-Fälle zum Einsatz kommen, hat die Möglichkeit, am Ende des Vorlesungszeitraums eine Evaluation durchführen zu lassen. Dazu existiert ein einheitlicher schriftlicher Fragebogen mit 19 Items u.a. zur curricularen Integration, der Bedienung und technischen Problemen. Die ausgefüllten Fragebögen werden (bis auf eventuelle Kommentare) automatisch ausgewertet und ein PDF-Bericht generiert.

Analyse der Prüfungsergebnisse

Neben der Kursevaluation ist gewünscht, dass Dozenten Prüfungsergebnisse daraufhin untersuchen, ob die vorherige Nutzung der Trainingsfälle Auswirkungen auf die Ergebnisse hatte. Im einfachsten Fall kann man die Leistungen der Studierenden bei der Fallbearbeitung mit denen in der Klausur vergleichen. Sind die Fälle aber nur anonym verfügbar, dann bietet sich die Möglichkeit, einige wenige Fragen aus den Trainingsfällen in der Klausur zu verwenden um daraus ableiten zu können, ob der jeweilige Teilnehmer Fälle bearbeitet hat oder nicht. Eine solche Auswertung kann aber immer nur Hinweise geben, schließlich besteht bei einer guten Korrelation zwischen Fallbearbeitungen und Prüfungsergebnis auch immer die Möglichkeit, dass nur fleißige oder gute Studierende das Angebot des fallbasierten Trainings genutzt haben und auch ohne diese Möglichkeit der Prüfungsvorbereitung gute Prüfungsergebnisse erzielt hätten.


4 Ergebnisse

Erst im Verlauf des Sommersemesters wurde der CaseTrain-Manager so erweitert, dass der kurze fallinterne Fragebogen bei der Fallerstellung automatisch hinzugefügt wird. Dementsprechend ist der Fragebogen nicht in allen Fällen verfügbar, zudem verfügen einzelne Fälle über von den Fallautoren selbst erstellte Fragebögen, die zwar ähnliche Items enthalten wie der Standard-Fragebogen, aber nicht in die Projekt-weite Evaluation aufgenommen werden. Fallbearbeitungen, die außerhalb der eLearning-Plattform wuecampus stattfinden (etwa, wenn ein Fallautor einen Fall über seine Homepage verfügbar macht), werden nur dann in die Statistik aufgenommen, wenn der Fall zusätzlich auch über wuecampus erreichbar ist. In Tabelle 1 [Tab. 1] sind die bisher gewonnenen Daten zu Fallbearbeitungen und Evaluationsfragen aufgeführt. Durch einige technische Umstellungen fehlen dabei Daten aus dem „Pilotsemester“ Sommersemester 2007 und teilweise auch aus dem Wintersemester 2007/08. Aufgeführt sind in Tabelle 1 [Tab. 1] zu jeder Lehrveranstaltung, die Fälle über wuecampus anbietet:

  • Anzahl der Studierenden, die diese Veranstaltung erfahrungsgemäß besuchen
  • Anzahl an Trainingsfällen, die den Studierenden am Semesterende zur Verfügung stand
  • Anzahl an Bearbeitungen (wobei auch jeweils mehrere Bearbeitungen eines Falles durch einen Lerner möglich waren)
  • Anzahl an vollständigen Bearbeitungen, hier werden nur die Bearbeitungen gezählt, bei denen mindestens die Abschlussbewertung angezeigt wurde
  • Durchschnittliche Bearbeitungsdauer in min (bezogen auf vollständige Bearbeitungen)
  • Anzahl an ausgefüllten Evaluationsfragen (diese sind optional)
  • Durchschnittliche Antwort auf das Item „Welche Note geben Sie für den Fallinhalt? (Schulnote 1–6)“
  • Durchschnittliche Antwort beim Item „Welche Note geben Sie für die Bedienung? (Schulnote 1–6)“

Insgesamt wurden über 400 Fälle in 33 Lehrveranstaltungen aus 10 Institutionen angeboten. Diese Fälle wurden über 27.000-mal gestartet und über 17.500-mal vollständig bearbeitet. Die durchschnittliche Bearbeitungsdauer von gut 9 min entspricht den Empfehlungen, Fälle mit einer Bearbeitungsdauer von 5–15 min zu erstellen. Der Standard-Fragebogen wurde über 2700-mal ausgefüllt, wobei die Fallinhalte durchschnittlich mit 1,9 benotet wurden, die Bedienung des Fallplayers mit 1,7 (die Durchschnittsberechnung erfolgte nach Fällen, nicht nach Kursen). Kurse mit wenigen ausgefüllten Fragebögen sind nicht sehr aussagekräftig und weisen große Schwankungen auf, deshalb wurde bei zu geringen Rückläufen auf eine Darstellung verzichtet.

Zusätzlich zur Benotung von Inhalt und Bedienung wurden die Studierenden mit der Frage „Haben Sie noch einen Verbesserungsvorschlag oder ist Ihnen etwas besonders (angenehm oder unangenehm) aufgefallen?“ aufgefordert, einen Kommentar zu hinterlassen. In einer groben Durchsicht reichte die Spannweite von enthusiastischer Zustimmung bis zur grundsätzlichen Ablehnung, Kritik wurde vor allem bezüglich der Wortfragen geäußert, da es hier immer wieder vorkommt, dass die Autoren ein Synonym oder eine Schreibweise nicht als richtige Antwort im Fall hinterlegt hatten.

Die erfreulich hohen Fallbearbeitungszahlen in einzelnen Fächern (z.B. in der Infektiologie im Sommersemester 2008) liegen zum einen an den relativ kurzen Fällen (ca. 5 Minuten Bearbeitungsdauer), zum anderen an der starken curricularen Integration – den Studierenden wurde die Benutzung zur Klausurvorbereitung dringend empfohlen.

In Abbildung 5 [Abb. 5] zeigen wir für den Kurs der Infektiologie detailliertere Ergebnisse, insbesondere den zeitlichen Verlauf der Anzahl der Fallbearbeitungen (Abbildung 5 [Abb. 5], links) und deren Aufschlüsselung nach Fall und Lerner (Abbildung 5 [Abb. 5], rechts).

Weiterhin wurde in 12 Kursen kurz vor oder nach der Klausur eine Kursevaluation durchgeführt. Eine umfassende Analyse der dabei gewonnenen Daten von ca. 700 ausgefüllten Fragebögen steht aber noch aus. Die dabei gegebenen Antworten und Kommentare decken sich aber dem ersten Anschein nach mit denen aus der fallinternen Evaluation, die dabei gestellte Frage nach der Zustimmung zum Einsatz von Trainingsfällen scheint aber hier – im Gegensatz zu manchen Kommentaren aus der fallinternen Evaluation – annähernd vollständig positiv beantwortet worden zu sein.

Auch die Analysen der Prüfungsergebnisse sind noch nicht abgeschlossen, Vergleiche der Infektiologie-Klausuren von Sommersemester 2008 und Sommersemester 2007 (wo noch keine Trainingsfälle verfügbar waren) deuten aber auf einen erheblichen positiven Effekt der Fallbearbeitungen hin.


5 Diskussion und Ausblick

Die große Zahl erstellter Trainingsfälle, die Anzahl der Fallbearbeitungen und die guten Bewertungen zeigen die hohe Akzeptanz fallbasierter Trainingsfälle bei Dozenten und Studierenden aus unterschiedlichen Fakultäten. Der Schwerpunkt der Projektarbeiten liegt derzeit auf der Entwicklung weiterer Kurse in fast allen Fakultäten der Universität Würzburg bzw. der Erstellung weiterer Fälle zu vorhandenen Kursen und dem Evaluation des Einsatzes. Bezüglich der Weiterentwicklung des Autorensystems sind die meisten fachübergreifenden Wünsche erfüllt, aber es gibt noch spezielle Wünsche, wie z.B. Mehrsprachigkeit mit besonderen Zeichensätzen (z.B. chinesisch, kyrillisch), weitere Fragetypen oder die Unterstützung von anderen Verzweigungsstrukturen als die „Infowahl“.

Für die Einbindung von CaseTrain in Lernplattformen ist die SCORM-Kompatibilität wichtig. Während die meisten Voraussetzungen dafür im CaseTrain-Player grundsätzlich gegeben sind, ist noch eine wichtige Erweiterung erforderlich: nämlich, dass ein Fall jederzeit unterbrochen und weitergeführt werden kann. Diese Funktionalität wird – auch im Hinblick auf einige Fachgebiete mit langen Fällen – nun auch als erstes in Angriff genommen.

Die Nutzung des CaseTrain-Players für Prüfungen wurde sowohl von Dozenten als auch von Studierenden gewünscht. Allerdings ist der Aufwand dafür recht hoch, wie die Erweiterungen des fallbasierten Lernsystems Campus zu einem Prüfungsplayer zeigen [18]. Nichtsdestotrotz ist eine entsprechende Weiterentwicklung geplant.

Ein besonders häufig geäußerter Wunsch ist die Unterstützung von Fragetypen mit Freitext-Antworten, zu denen nicht nur Musterlösungen angezeigt, sondern die auch bewertet werden sollen. Das erfordert Techniken der Sprachverarbeitung und Informationsextraktion [11], [12] und liefert im Allgemeinen nur eine begrenzte automatische Bewertungsqualität. Hier planen wir eine semiautomatische Korrektur, bei der der Antworttext vorverarbeitet und das Ergebnis von einem menschlichen Korrektor überprüft wird.


Anmerkungen

Interessenkonflikte

Keine angegeben.

Danksagung

Die Arbeiten wurden aus Studienbeiträgen der Studierenden der Universität Würzburg finanziert.


Literatur

1.
Ruiz J, Mintzer M, Leipzig R. The impact of E-learning in medical education. Acad Med. 2006;81(3):207-12. DOI: 10.1097/00001888-200603000-00002 External link
2.
Betz C. Scalable authoring of diagnostic case based training systems. VDM Verlag; 2007.
3.
Reimer S, Hörnlein A, Tony HP, Krämer D, Oberück S, Betz C, Puppe F, Kneitz C. Assessment of a case-based training system (d3web.Train) in rheumatology. Rheumatol Int. 2006;26(10):942-8. DOI: 10.1007/s00296-006-0111-x External link
4.
Krämer D, Reimer S, Hörnlein A, Betz C, Puppe F, Kneitz C. Evaluation of a novel case-based Training Program (d3web.Train) in Hematology. Ann Hematol. 2005;84(12):823-9. DOI: 10.1007/s00277-005-1062-0 External link
5.
Martens A. Ein Tutoring Prozess Modell für fallbasierte Intelligente Tutoringsysteme. DISKI 281. Akademische Verlagsgesellschaft; 2004.
6.
Simonsohn A, Fischer M. Evaluation of a case-based computerized learning program (CASUS) for medical students during their clinical years. Dtsch Med Wochenschr. 2004;129(11):552-6. DOI: 10.1055/s-2004-820543 External link
7.
Garde S, Bauch M, Haag M, Heid J, Huwendiek S, Ruderich F, Singer R, Leven FJ. CAMPUS - computer-based training in medicine as part of a problem-oriented educational strategy. Studies in Learning, Evaluation, Innovation and Development. 2005;2(1):10-9.
8.
CaseTrain - Fallbasiertes Training Online. Fakultätsübergreifendes Blended Learning Projekt - finanziert aus Studienbeiträgen [website]. Available from: http://casetrain.uni-wuerzburg.de [cited 2008-07-25] External link
9.
OpenOffice.org - The Free and Open Productivity Site [website]. Available from: http://www.openoffice.org [cited 2008-07-25] External link
10.
Apple. iWork - Pages [website]. Available from: http://www.apple.com/iwork/pages/ [cited 2008-12-10] External link
11.
Klügl P, Atzmüller M, Puppe F. Test-Driven Development of Complex Information Extraction Systems using TEXTMARKER. Proceedings of Knowledge Engineering and Software Engineering (KESE08), 31th German Conference on Artificial Intelligence (KI-2008); Kaiserslautern. 2008 [accepted].
12.
Atzmüller M, Klügl P, Puppe F. Rule-Based Information Extraction for Structured Data Acquisition using TEXTMARKER. Proceedings of LWA 2008 (Special Track on Knowledge Discovery and Machine Learning); Würzburg. 2008 [accepted].
13.
MedicML - XML-Struktur für medizinische Fachinformationen [website]. Available from: http://www.medicml.de [cited 2008-07-25] External link
14.
Merz A K, Schwarz C, Reng C M, Rockmann F. medicMED - XML and standard software for a new approach of ICL in medicine. International Workshop ICL - Interactive Computer Aided Learning; 25.-27.09.2002; Villach/Austria. 2002.
15.
Moodle - A Free, Open Source Course Management System for Online Learning [website]. Available from: http://moodle.org [cited 2008-07-25] External link
16.
WueCampus - Die uniweite eLearning Plattform [website]. Available from: http://wuecampus.uni-wuerzburg.de [cited 2008-07-25] External link
17.
Adobe - ActionScript Technology Center [website]. Available from: http://www.adobe.com/devnet/actionscript [cited 2008-07-25] External link
18.
Heid J, Bauch M, Brass K, Haag M, Jünger J, Leven FJ. Erfahrungen bei Entwicklung und Einsatz eines Prüfungsplayers für computerunterstütztes sicheres Prüfen. In: Matthies, Fischer, Haag, Klar, Puppe. eLearning in der Medizin. Proc. zum 9. Workshop der gmds-Ag CBT in der Medizin; 2005. Quintessenz-Verlag; 2005. S. 46-9