Entwicklung und Evaluation eines fall- und webbasierten Trainingsprogrammes (d3web.Train)

Inhaltsverzeichnis

Tabellenverzeichnis

Abbildungsverzeichnis

Diagrammverzeichnis

1 Einleitung
1.1 Allgemeine Überlegungen
1.2 Problem-Orientiertes Lernen
1.3 Lernprogramme allgemein
1.3.1 Grundsätzliche Unterschiede diverser Trainingssysteme
1.3.1.1 Präsentations- und Browsingprogramme
1.3.1.2 Drill-Programme
1.3.1.3 Tutor-Systeme
1.3.1.4 Simulationen
1.4 Fallbasierte Diagnostische Trainigssysteme (FDTS)
1.5 Fragestellung

2 Material und Methoden
2.1 Trainingssystem
2.1.1 d3web.Train allgemein
2.1.2 Fallerstellung
2.1.2.1 Generierung Diagnostischer Trainingsfälle aus Arztbriefen
2.1.2.2 Typische Architektur eines Arztbriefes
2.1.2.3 Einzelne Schritte in der Fallgenerierung
2.1.2.3.1 Erweiterung des Arztbriefes
2.1.2.3.2 Inhaltliche und Formelle Anpassung
2.1.2.3.3 Formulieren der Fragen / Schaffung der Prüfungskomponente
2.1.2.3.4 Formatierung
2.1.2.3.5 Einlesen und Zerlegung der Arztbriefinformationen
2.1.2.3.6 Überprüfung der zerlegten Inhalte
2.1.2.4 Arztbriefkonvertierungstool: Phoenix (vormals KnowMe)
2.1.3 Struktur eines Generierten Trainingsfalles
2.1.4 Liste der Fälle und Diagnosen
2.1.5 Systemvorstellung
2.1.5.1 Online-Kurs-System
2.1.6 Fallvorstellung und Screenshots
2.1.7 D3web.Train
2.1.7.1 Ankunft im System, einführender Screen eines Falles
2.1.7.2 Die virtuelle Patientenakte und deren Steuerung
2.1.7.3 Bildbetrachtung
2.1.7.4 Erstellen der Befunde
2.1.7.5 Diagnosenauswahl
2.1.7.6 Fallabschluss
2.1.7.6.1 Beurteilung / Gesamtscore / Kommentar des Autors
2.1.7.6.2 Fallende
2.2 Darstellung des eingelesenen Beispielfalles
2.2.1 Intro
2.2.2 Anamnese
2.2.3 Körperliche Untersuchung
2.2.4 Labor
2.2.5 Technische Untersuchungen
2.2.6 Diagnosestellung
2.2.7 Beurteilung / Gesamtscore
2.2.8 Fallkommentar / Fallende
2.3 Kursdesign
2.4 Durchführung des Kurses
2.5 Evaluation und Fragebögen
2.5.1 Evaluationskonzept
2.6 Fragebogen / Evaluation
2.6.1 Fragebogen zu Beginn des Kurses (Evaluation I)
2.6.2 Abschluss-Evaluation III (Teil 1)
2.6.3 Abschluss-Evaluation III (Teil 2)
2.6.4 Fallspezifischer elektronischer Feedback-Fragebogen (Evaluation II)
2.7 Kurze Vorstellung alternativer Trainingssysteme
2.7.1 CAMPUS-Software
2.7.2 CASUS
2.7.3 INMEDEA-Simulator

3 Ergebnisse
3.1 Zusammensetzung des Kurses
3.2 Ergebnisse der Evaluation I
3.3 Ergebnisse der Evaluation II
3.4 Evaluation der Fälle
3.4.1 Bewertung der Fälle aus dem Themenbereich der Allergologie
3.4.1.1 Bewertung der Fälle aus dem Themenbereich der Immundefektsyndrome
3.4.1.2 Bewertung der Fälle aus dem Themenbereich der Rheumatologie
3.4.1.3 Dauer der Fallerstellung
3.5 Weitere Ergebnisse und allgemeine Nutzerstatistik
3.6 Klausurergebnisse

4 Diskussion
4.1 Allgemeine Überlegungen
4.2 Kursdesign und Gestaltung der Trainingsfälle
4.3 Diskussion der Ergebnisse
4.3.1 Diskussion der Ergebnisse aus der Evaluation I
4.3.2 Diskussion der Ergebnisse aus den Evaluationen I und III
4.3.2.1 Erwartungen an das Trainingssystem
4.3.3 Diskussion der Ergebnisse aus der Evaluation II
4.3.3.1 Fallbewertung durch Online-Fragebogen
4.3.3.2 Fallbewertung durch Online-Freitextkommentare
4.3.4 Fallerstellung
4.3.5 Diskussion der Klausurergebnisse
4.3.6 Systemaufbau und -integration

5 Ergebnisse nachfolgender Semester
5.1 Allgemeine Ergebnisse der Nutzerstatistik
5.2 Ergebnisse aus den Fallbearbeitungen
5.3 Ergebnisse aus der Evaluation durch Fragebögen
5.4 Klausurergebnisse
5.5 Diskussion der Ergebnisse der nachfolgenden Semester

6 Zusammenfassung
6.1 Zusammenfassung der Ergebnisse der weiteren Semester
6.2 Fazit und Ausblick

7 „CaseTrain“ als „Weiterentwicklung“ des Trainers
7.1 CaseTrain -Grundlagen
7.2 Konzeption und Anforderungen
7.3 CaseTrain – Benutzeroberfläche
7.4 Einsatz von CaseTrain
7.5 Evaluation
7.6 Ergebnisse
7.7 Ausblick

8 Literaturverzeichnis

Danksagung

Tabellenverzeichnis

Tabelle 1-1 Vergleich: Vorteile und Nachteile CBT/WBT

Tabelle 2-2 Formatierung des Textes und Funktion für die Konvertierung

Tabelle 2-3 Fallliste der Allergologie

Tabelle 2-4 Fallliste der Immundefektsyndrome

Tabelle 2-5 Fallliste des rheumatologischen Formenkreises

Abbildungsverzeichnis

Abbildung 2-1 Screenshot eines Arztbrief in MS Word

Abbildung 2-2 Screenshot: Anonymisierung eines Arztbriefes

Abbildung 2-3 Screenshot: MC-Frage zur späteren Wissensüberprüfung in der Fallbearbeitung

Abbildung 2-4 Screenshot: Arztbriefkonverter Phoenix (KnowMe)

Abbildung 2-5 Screenshot: Log-Screen der Konvertierung

Abbildung 2-6 Grafisch dargestellte Struktur eines generierten Trainingsfalles

Abbildung 2-7 Systemvorstellung: Willkommens-Screen im Online-Kurs-System

Abbildung 2-8 Systemvorstellung: Bearbeitungsstatus der Fälle

Abbildung 2-9 Systemvorstellung: Auswahl-Screen der Online-Bedienkurse

Abbildung 2-10 Screenshot: Intro

Abbildung 2-11 Screenshot: Virtuelle Patientenakte

Abbildung 2-12 Screenshot: Bildbetrachtung

Abbildung 2-13 Screenshot: Bildbefundung

Abbildung 2-14 Screenshot: Diagnosenauswahl

Abbildung 2-15 Screenshot: Gesamtscore

Abbildung 2-16 Screenshot: Fallende/-abschluss

Abbildung 2-17 Screenshot: Intro des Beispielfalles in D3web.Train

Abbildung 2-18 Screenshot: Anamnese-Fenster des Beispielfalles

Abbildung 2-19 Screenshot: Körperliche Untersuchung des Beispielfalles

Abbildung 2-20 Screenshot: Körperliche Untersuchung des Beispielfalles und Prof. Edgar

Abbildung 2-21 Screenshot: Laborfenster des Beispielfalles

Abbildung 2-22 Screenshot: Laborfenster des Beispielfalles

Abbildung 2-23 Screenshot: Technische Untersuchungen des Beispielfalles

Abbildung 2-24 Screenshot: Technische Untersuchungen des Beispielfalles

Abbildung 2-25 Screenshot: Technische Untersuchungen des Beispielfalles – Lungenfunktionsanalyse

Abbildung 2-26 Screenshot: Technische Untersuchungen des Beispielfalles - EKG

Abbildung 2-27 Screenshot: Technische Untersuchungen des Beispielfalles – Prof. Edgar

Abbildung 2-28 Screenshot: Diagnosestellung - Prof. Edgar

Abbildung 2-29 Screenshot: Beurteilung / Gesamtscore

Abbildung 2-30 Screenshot: Bildbefundung, Abschluss des Falles

Abbildung 2-31 Screenshot: Kommentar des Autors im Fallabschluss

Abbildung 2-32 Screenshot: Fall verlassen, Rückkehr zum Leistungsscreen

Abbildung 2-33 Kursdesign, grafische Darstellung

Abbildung 2-34 Durchführung des Kurses, grafische Darstellung

Abbildung 2-35 Evaluationskonzept, grafische Darstellung

Abbildung 7-36 Screenshot: Begrüssung und Fall-Intro

Abbildung 7-37 Screenshot: Körperlicher Untersuchungsbefund

Abbildung 7-38 Screenshot: Untersuchungsauswahl – Labor

Abbildung 7-39 Screenshot: Untersuchungsauswahl – Röntgen

Abbildung 7-40 Screenshot: Untersuchungsauswahl – Ergebnis und Feedback

Abbildung 7-41 Screenshot: Auswertung und Fallabschluss

Diagrammverzeichnis

Diagramm 3-1 Geschlechtsverteilung im Kurs

Diagramm 3-2 Einsatz als Ergänzung zur klassischen Lehre

Diagramm 3-3 Einarbeitungszeit

Diagramm 3-4 Von den Studierenden erwartete/gewünschte Einarbeitungszeit in das Trainingsprogramm

Diagramm 3-5 Bessere Vorbereitung auf den Beruf?

Diagramm 3-6 Subjektive Einschätzung der Netzkompetenz

Diagramm 3-7 Eigener Computer

Diagramm 3-8 Internetzugang

Diagramm 3-9 Einsatz des Trainers als Ergänzung? Semesterbeginn / Semesterende / Im Vergleich

Diagramm 3-10 Bessere Vorbereitung auf den Beruf durch den Einsatz von CBT (d3web.Train)

Diagramm 3-11 Tatsächliche Einarbeitungszeit

Diagramm 3-12 Bearbeitung am eigenen Rechner

Diagramm 3-13 Wo wurden die Fälle bearbeitet?

Diagramm 3-14 Wie viele Fälle alleine bearbeitet?

Diagramm 3-15 Personen aktiv bei der Fallbearbeitung

Diagramm 3-16 Hilfen bei der Einarbeitung

Diagramm 3-17 Schwierigkeiten nach der Einarbeitung

Diagramm 3-18 Mittelwerte der Fallbewertung

Diagramm 3-19 Mittlere Bewertungen der Fälle der Allergologie

Diagramm 3-20 Mittlere Bewertungen der Fälle der Immundefekt-Syndrome

Diagramm 3-21 Mittlere Bewertungen der Fälle des rheumatologischen Formenkreises

Diagramm 3-22 Dauer der Fallerstellung in Stunden

Diagramm 3-23 Klausurergebnisse (Notenverteilung)

Diagramm 5-24 Computerausstattung

Diagramm 5-25 Gesamtzahl der Benutzer

Diagramm 5-26 Anteil der aktiven Benutzer in Prozent

Diagramm 5-27 Gesamtzahl der freigeschalteten Fälle

Diagramm 5-28 Durchschnittliche Fallbearbeitungen gesamt

Diagramm 5-29 Durchschnittliche Fallbearbeitungsdauer

Diagramm 5-30 Gesamtzahl der erfolgreichen Fallbearbeitungen

Diagramm 5-31 Durchschnittlicher Fallbearbeitungs-Score

Diagramm 5-32 Durchschnittliche Bewertung der Bedienbarkeit

Diagramm 5-33 Durchschnittliche Bewertung des Inhalts

Diagramm 5-34 Klausurergebnisse

Diagramm 7-35 Nutzungs-Statistik CASETRAIN

1 Einleitung

1.1 Allgemeine Überlegungen

Die Hochschullandschaft in Deutschland war in den letzten beiden Jahrzehnten großen Veränderungen ausgesetzt. Durch die enorme Wissensexplosion der Menschheit kann eine Universität weder das „Wissen für ein ganzes Arbeitsleben“ während des Studiums vermitteln, noch kann sie ihrem früher innegehabten Auftrag nachkommen gleichzeitig eine breite allgemeinbildende Ausbildung zu gewährleisten. Des Weiteren hat einmal erworbenes Wissen eine stetig kürzer werdende Halbwertszeit. „Wer in der Wissensgesellschaft Schritt halten will, muss lebenslang lernen“. (Bertelsmann Stiftung, Heinz Nixdorf Stiftung (Hrsg.), 2001) (Gemeinschaften, 2000)

Im Studium der Humanmedizin lag der Fokus der Lehre bisher auf dem Faktenlernen und war durch eine weitgehende Trennung des Erlernens theoretischer Grundlagen in Vorlesungen und Seminaren und deren praktischer Umsetzung gekennzeichnet. Praktisches Wissen eigneten sich die Studierenden vornehmlich im Rahmen von Famulaturen und des Praktischen Jahres sowie in einzelnen Übungskursen an Phantompuppen an.

Mit der Einführung der neuen Approbationsordnung (im Folgenden abgekürzt mit „ÄAppO“) (Bundesministerium für Gesundheit, 2002) am 27. Juni 2002 wurden große Teile der bisherigen medizinischen Ausbildung tiefgreifenden Änderungen unterworfen. Die Vorgabe des Gesetzes ist eine – mehr als bisher – problemorientierte, fallbasierte und interdisziplinäre Ausbildung, die im Kern eine stärkere Verknüpfung von Theorie und Praxis aufweist, um die Studierenden näher am Beruf auszubilden. Deshalb werden durch die ÄAppO unter anderem auch neue Unterrichtsformen gefordert, um den Studierenden eine verstärkt interdisziplinäre Ausbildung zu ermöglichen. Ferner soll ein lebenslanges Lernen antrainiert werden, was in einem sich schnell und breit entwickelnden Fach - wie der modernen Medizin - eine Grundvoraussetzung darstellt, um zu der in der ÄAppO geforderten ständigen Weiter- und Fortbildung befähigt zu sein.

Die Fakultäten erhielten mit dem Inkrafttreten der neuen ÄAppO größere Freiheiten zur Umstrukturierung ihrer Lehrveranstaltungen. Diese neue Freiheit brachte gleichzeitig aber die Verpflichtung mit sich, die vermittelten Inhalte in Klausuren zu überprüfen. Das bedeutet für die Universität im klinischen Abschnitt des Medizinstudiums Prüfungen in 22 Hauptfächern und 12 sogenannten (interdisziplinären) Querschnittsfächern durchführen zu müssen. Diese Überprüfung der Lerninhalte erfordert gemäß dem „Assessment drives learning“ (Wass V., 2001) neue aufwändigere Prüfungsmethoden. Die Umstrukturierung oder Neugestaltung von medizinischen Curricula ist von den jeweils verfügbaren menschlichen und finanziellen Ressourcen (der jeweiligen Fakultäten) abhängig, die durch die neuen Regelungen stärker beansprucht werden dürften. Die Möglichkeiten einer großzügigen Umsetzung der geforderten Modifikationen sind begrenzt, da es die Hochschullandschaft in Deutschland in Zeiten knapper werdender Mittel trifft. Aber auch die personellen Ressourcen sind knapper geworden. Die im Zuge der Umstrukturierung des Gesundheitssystems eingeführten DRGs (Diagnosis Related Groups) (Wikipedia, DRGs, 2008) erhöhen gleichermaßen den Patientendurchsatz sowie den Dokumentationsaufwand und binden die personellen Mittel. Es liegt also nahe, dass verschiedene Fakultäten verschiedene Wege werden finden müssen, um die bestehende Lehre gemäß den Vorschriften zu modifizieren. In dieser Arbeit soll einer der Ansätze, der an der Würzburger Universität eingeführt wurde, näher erläutert werden.

1.2 Problem-Orientiertes Lernen

Ein Ansatz, um die Lehre an die neuen Vorschriften anzupassen, ist die Anwendung des Problem-Orientierten Lernens (POL), ein Ende der 60er Jahre aufgekommener Ansatz, welcher lerntheoretisch dem Konstruktivismus (Wikipedia, Konstruktivismus (Lernpsychologie), 2008) zugeordnet werden kann (Thömen).

Doris Thömen definiert POL wie folgt:

„Zusammenfassend lässt sich das POL im engeren Sinne als einen interaktiven, auf bestimmte Problemstellungen ausgerichteten Lernprozess beschreiben. Ausgangspunkt für das POL ist eine Problemstellung oder ein Fallbeispiel aus der Berufspraxis, wie zum Beispiel eine Krankengeschichte oder ein Beschwerdebild. Ziel der problemorientierten Lehre ist es, die Studierenden zur Erfassung und zur erfolgreichen Bearbeitung von komplexen (praxisnahen) Aufgaben zu befähigen.“

Entscheidend für den Lernerfolg ist daher nicht alleine die Lösung eines Problems, sondern die Strategie der Problembearbeitung im Sinne der Problemerfassung und des damit verbundenen gezielten Nachforschens und Wissenserwerbs. Auf dieser „neu geschaffenen Wissensbasis können wiederum Entscheidungen für die weitere Vorgehensweise gefällt werden (Hmelo C.E., 2000).

Für den Einsatz speziell in medizinischen Curricula definiert Barrows (Barrows H.S., 1986) fünf Hauptziele des POL-Ansatzes:

- Construction of clinically useful knowledge
- Development of clinical reasoning strategies
- Development of effective self-directed learning strategies
- Increased motivation for learning
- Becoming effective collaborators

1.3 Lernprogramme allgemein

Im Rahmen der neuen Approbationsordnung für Ärzte und auf der Basis der inzwischen bestehenden technischen Infrastruktur sowie durch die spürbaren finanziellen staatlichen Förderungen (Bulmahn, 2000) wurde eine Vielzahl an elektronischen Lernformen entwickelt, die die Anwendung des POL-Ansatzes ermöglichen. In Tabelle 1-1 können die Vor- und Nachteile der zwei wichtigsten elektronischen Lernformen entnommen werden

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1-1 Vergleich: Vorteile und Nachteile CBT/WBT

Das sogenannte eLearning ermöglicht die Applikation von fallbasierten Trainingssystemen (FBTS). Diese Lernprogramme kommen oft im Sinne des sogenannten „Blended Learning“ (Dawabi P., 2004) begleitend zum klassischen Frontalunterricht zur Anwendung. Zudem können die Programme aber auch von Dozenten zur Erstellung von Lerninhalten für ihre Lehrveranstaltungen genutzt werden.

Durch den Einsatz der Lernprogramme als Unterstützung des klassischen Unterrichts soll vor allem eine Bereicherung der selbstbestimmten Lernphasen der Studierenden geschaffen werden. Ein in das System integrierter intelligenter Feedback-Mechanismus dient als Wissenskontrolle für den Lernenden. So soll ein Lernumfeld entstehen, das ein insgesamt flexibleres Lernen ermöglicht und besser auf die individuellen Bedürfnisse des Einzelnen zugeschnitten ist. Die folgende Aufstellung soll einen kurzen Überblick über die verschiedenen Trainingssysteme geben.

1.3.1 Grundsätzliche Unterschiede diverser Trainingssysteme

1.3.1.1 Präsentations- und Browsingprogramme

Präsentationsprogramme bieten dem Lernenden insgesamt wenig Interaktions-möglichkeiten und beschränken sich im Normalfall auf eine lineare Darstellung des vorher zu wählenden Lernstoffes in Form von Text und multimedialer Inhalte (Audio, Video).

Der wesentliche Unterschied der Browserprogramme ist die zusätzliche Möglichkeit des Lernenden, die Reihenfolge der Inhalte selbst bestimmen zu können durch individuelles Verfolgen von verlinktem Kontext(Ifland, 2008) (Reinhardt, Didaktische Strategien in generierten Trainingssystemen, 2000).

1.3.1.2 Drill-Programme

Auch bei diesen Programmen ist ein vorhandenes Wissen des Users Grundvoraussetzung, da durch solche Systeme Wissen lediglich abgefragt und nicht durch Präsentation neuen Lernstoffes vermittelt wird. Am Ende einer Trainingssitzung steht meist eine Auswertung der richtig bzw. falsch beantworteten Fragen(Ifland, 2008) (Reinhardt, Didaktische Strategien in generierten Trainingssystemen, 2000).

1.3.1.3 Tutor-Systeme

Im Prinzip eine Verknüpfung der zuvor erwähnten Systeme. Dem Lernenden wird neuer Lernstoff präsentiert, wobei neues Wissen vermittelt werden soll. Basierend darauf bzw. auf der Annahme bereits vorhandenen Grundwissens werden dem User Fragen gestellt, worauf häufig ein direktes Feedback folgt. Durch Antwortanalyse des Trainers werden die darzustellenden Inhalte in bestimmtem Maße an den Lernenden angeglichen. Der Lerner hat deshalb eingeschränkte Möglichkeiten bei der Wahl der darzustellenden Inhalte(Ifland, 2008) (Reinhardt, Didaktische Strategien in generierten Trainingssystemen, 2000).

1.3.1.4 Simulationen

Ziel dieser Programme ist es dem User ein „dynamisches Modell eines bestimmten Ausschnittes aus der Realität“ darzustellen. Hierzu wird ein Szenario mit einer Problemstellung präsentiert, wobei der Lernende durch die eigenen Aktionen Reaktionen des Systems erzeugt und dadurch Einfluss auf den Ablauf des Inhaltes nehmen kann. Die Simulation endet im Normalfall dann, wenn das Problem gelöst werden konnte(Ifland, 2008) (Reinhardt, Didaktische Strategien in generierten Trainingssystemen, 2000).

1.4 Fallbasierte Diagnostische Trainigssysteme (FDTS)

Die Medizin als analytisches und diagnoselastiges Fach eignet sich besonders für die Anwendung fallbasierter, diagnostischer Trainingssysteme. Theoretische Komponenten, wie Anamnese, Beobachtungsinterpretation, Untersuchungshierarchie und Hypothesenbildung lassen sich im Gegensatz zu manuellen und mechanisch-motorischen Untersuchungen einfacher in Software umsetzen und am Monitor zu Trainingszwecken darstellen.

FDTS (Puppe F., 2003) präsentieren einen realen, beziehungsweise möglichst realitätsnahen Fall, der vom Benutzer durch die Interpretation der gegebenen Informationen in Bezug auf die Problemstellung durch die Eingabe einer Diagnose und gegebenenfalls entsprechender Therapien oder durch die Anforderung von Untersuchungen gelöst werden muss. Die theoretischen Grundlagen dafür sind die Definitionen von Krankheitszuständen anhand bestimmter Charakteristika, sprich Diagnosekriterien. Ist die Menge an Informationen nicht ausreichend, beziehungsweise nicht eindeutig genug um eine vorläufige Diagnose stellen zu können, müssen gezielt weitere Untersuchungen angefordert werden, um die Diagnose sichern zu können.

Diese FDTS sollen die bisherige Ausbildung um das Lernen und die Anwendung des im Studium erworbenen Grundwissens und Trainieren von Lösungsalgorhythmen an virtuellen Patienten ergänzen. Virtuelle Patienten können und sollen den echten Patientenkontakt nicht ersetzen, jedoch bieten sich durch deren Einsatz nicht zu unterschätzende Vorteile in der medizinischen Ausbildung: Nicht immer ist ein den aktuellen Themen der Vorlesung entsprechendes Patientengut vorhanden, beziehungsweise ist aus ethischen oder persönlichen Gründen möglich dieses für den Anschauungsunterricht zu rekrutieren. Mit den Übungen haben Studierende die Möglichkeit Patienten „vom Erstkontakt bis zur Entlassung“ zu betreuen, wie es im Stationsunterricht selten möglich wäre. Janssen-Noordman et al. berichten, dass sich diese ganzheitliche Herangehensweise positiv auf die Motivation, die differentialdiagnostischen Fähigkeiten und damit insgesamt auf den Lernerfolg auswirken kann (Janssen-Noordman Ameike M B, 2007).

Lernmethodisch liegt diesen Trainingsprogrammen die Darstellung und Bearbeitung realitätsnaher Kasuistiken zugrunde, die von den Autoren aus Arztbriefen, Akten und umfangreichem Bild- und Videomaterial generiert wurden (Rettig, 2007). Durch breiten Einsatz können fall- und praxisorientierte Inhalte standardisiert simuliert werden. Um jedoch einzelne Themenbereiche der Medizin qualitativ hochwertig und attraktiv anbieten zu können, ist eine große Menge an guten Fällen erforderlich, um das große Spektrum der verschiedenen (wichtigen) Erkrankungen in ihren jeweiligen Ausprägungen und den dazugehörigen Differentialdiagnosen darstellen zu können. Solch eine Fallsammlung wird zum Beispiel im CASEPORT-Projekt zusammengetragen(Fischer M. R., 2004) (Huwendiek S, 2008).

Wie oben erwähnt sind diese Programme dabei „nur“ ergänzender Natur im Sinne des Blended Learning und (laut vielen Studien) wahrscheinlich günstig einzusetzen, wenn bereits Grundwissen besteht, welches die minimalen Grundvoraussetzungen für eine sinnvolle Nutzung darstellt. Dieses Wissen beinhaltet neben dem medizinischen Wissen, das durch die klassische Lehre vermittelt werden soll, einen halbwegs sicheren Umgang mit der Hardware, sowie eine geeignete Unterstützung für den User um das Trainingssystem kennenzulernen. Sind diese Rahmenbedingungen nicht ausreichend gegeben, kann das Potential des Blended Learning nicht in vollem Umfang genutzt werden (Creß U., 2002)(Lawless K.A., 1997)(Marchionini G., 1990) (Weidenmann B., 1995).

Durch einen modularen Aufbau (Shell-Systeme) sind stark vereinfachte bis hochkomplexe Versionen der Trainerprogramme möglich und wahrscheinlich auch sinnvoll, je nachdem in welchem Bereich oder in welchem Stadium der Lehre beziehungsweise der Fortbildung die Software eingesetzt werden soll. Zum Beispiel wurde das Internetportal „RheumaNet“ geschaffen, welches Informations- und Weiterbildungsmöglichkeiten sowohl für Ärzte als auch Patienten bietet (Specker C., 1998).

Der von dem Lehrstuhl für Informatik und künstliche Intelligenz an der Universität Würzburg entwickelte Trainer (d3web.Train) (Hörnlein A., 2002) (Vergleiche dazu andere Lernsysteme (Fischer M. , 2001), (CASUS - INSTRUCT AG), (Leonhardt-Huober H.)) wurde sowohl als Lehr-, Lern- und Fortbildungsplattform konzipiert. Den Studierenden dient das Programm als Lernplattform zum Selbststudium. Für die Dozierenden hingegen ist das Programm nützlich zur Erstellung von Lerninhalten oder als Ergänzung zu den Vorlesungen. In diesem spezifischen Falle der Rheumatologie und der klinischen Immunologie. Mit entsprechenden Inhalten beziehungsweise Kasuistiken kann der Trainer jedoch auch in anderen (Fach-) Bereichen Anwendung finden.

Mehrere Untersuchungen zeigen, dass fall- und wissensbasierte Trainingssysteme in der medizinischen Ausbildung einen großen Nutzen in der Wissensvermittlung haben können. Außerdem erfreuen sich diese Lernprogramme eines hohen Akzeptanzwertes von Seiten der Studenten (Schewe S., 1996) (Langer I., 1998) (Simonsohn A., Evaluation of a case-based computerized learning program (CASUS) for medical students during their clinical, 2004) (Reimer S. K. C.-P., 2004) (Zumbach J., 2000) (Ruderich F., 2002).(Ruiz, Mintzer, & Leipzig, 2006) Der „LRSMed“ der Universität Essen listet derzeit um die 2000 verschiedene frei zugängliche Lernsysteme im Web (Learning Resource Server Medizin) (LRSMed, 2008). Das Angebot ist beachtlich und wächst stetig weiter. Die GMDS-AG Computergestützte Lehr- und Lernsysteme in der Medizin hat in verschiedenen Publikationen festgestellt, dass nur etwa 5% der Medizinstudenten diese während ihres Selbststudiums nutzen (GMDS-AG, 2008). Riedel stellte in einer Studie zum fallbasierten Trainingsprogramm CASUS an der LMU München fest, dass das System umso mehr genutzt wurde, je prüfungsrelevanter dessen Inhalte waren (Riedel J, 2003).

Aus diesem Grunde versuchten wir in unserem Kurs die Immunologie/Rheumatologie in Form der klassischen Lehre (als Vorlesung) und (ergänzt) durch das Trainingsprogramm d3web.Train (Selbststudium) als Pflichtkomponente abzubilden und zu vermitteln. Durch die kombinierte Anwendung moderner Lehrkonzepte im Sinne einer (online stattfindenden) fallorientierten Prüfung der durch die klassische Vorlesung vermittelten Wissensinhalte erhofften wir uns besseren Lernerfolg bei den Studenten. In einem anschließenden Praktikum sollte das aufgenommene Wissen eingesetzt und weiter verfestigt werden. Durch die Anwendung dieser miteinander eng verflochtenen Komponenten erhofften wir uns eine Verbesserung der Ausbildung in diesem Fachbereich.

Der Kurs wurde am Ende mit einer MC-Klausur abgeschlossen. Anhand von mehreren Evaluationen wurde versucht den Erfolg - im Sinne einer Verbesserung des Lernerfolgs durch Problem-orientiertes-Lernen - oder Misserfolg des Kurses zu erheben.

Eine genauere Darstellung des Kurses beziehungsweise die Ergebnisse der Evaluation und deren Interpretation werden auf den folgenden Seiten zu finden sein.

1.5 Fragestellung

Thema der Dissertation:

„Entwicklung und Evaluation eines fall- und webbasierten Trainingsprogrammes (d2web.Train) als begleitenden Kurs zur Vorlesung in einem Pflichtkurs der klinischen Immunologie / Rheumatologie an der Universität Würzburg im Wintersemester 2004/2005.“

Da in dem vorgestellten Konzept der Einsatz des Trainingssystems d3web.Train als Pflichtteil der Ausbildung im Querschnittsbereich klinische Immunologie / Rheumatologie vorgesehen ist, wurde ein Weg begangen, der eine weitaus stärkere Nutzung des Trainers verlangt, als dies bisher der Fall war.

Entscheidend für einen erfolgreichen Einsatz ist die Akzeptanz durch die Studierenden und die Dozenten. Nur wenn diese bereit und motiviert sind, elektronische Lernformen zu nutzen, kann das Potential dieser Technologie in Lernerfolgen realisiert werden. Inwieweit die Teilnehmer unseres Kurses unser Konzept akzeptieren und motiviert sind, damit zu lernen, war eine der zentralen Fragestellungen dieser Untersuchung. Damit einhergehend wurde untersucht, in wie weit dieses Lehrkonzept den Lernerfolg der Studierenden anhand deren subjektiver Einschätzung verbessert.

Außerdem wird die Arbeit die Umsetzung des Kurses im Hinblick auf Nachhaltigkeit die zugrunde liegenden Ressourcen beleuchten.

2 Material und Methoden

2.1 Trainingssystem

2.1.1 d3web.Train allgemein

Das Expertensystem – die Entwicklungs- und Ablaufumgebung D3 und die Trainingskomponente D3Trainer - basieren auf der in der Künstlichen Intelligenz häufig zur Anwendung kommenden Programmiersprache LISP (LISP, 2008). Die weitere Entwicklung von D3 und D3Trainer war im Jahre 2001 eingestellt worden.

Auf den Erfahrungen mit D3/D3Trainer aufbauend wurde damals die Neu-Implementierung von d3web (Hörnlein A., 2002) begonnen, welche durch ein komponenten-basiertes Model wesentlich leichter zu warten und anzupassen ist. Als Programmiersprache wurde Java (Java (Programmiersprache), 2008) gewählt, da Java eine weitgehende Plattformunabhängigkeit bietet und zahlreiche Bibliotheken zur Datenbankanbindung, XML-Processing, Servlet-Technologie, Sprachverarbeitung, etc. zur Verfügung stellt (Java (Technik), 2008). Darüber hinaus wird die Erstellung von Java-basierten Anwendungen durch ausgereifte Open-Source Werkzeuge zur Team-Entwicklung deutlich besser unterstützt (Merz A.-K., 2002).

D3web.Train ist als Trainingssystem in der studentischen Ausbildung seit 2004 an der Universität Würzburg und seit 2005 an der Virtuellen Hochschule Bayern im Rahmen des CASEPORT-Projekts im Einsatz (Fischer M. R., 2004). Außerdem kommt das Programm in Workshops und im Internet zur zertifizierten medizinischen Fortbildung für Ärzte zur Anwendung (Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik der Universität Würzburg).

2.1.2 Fallerstellung

2.1.2.1 Generierung Diagnostischer Trainingsfälle aus Arztbriefen

Zur Erstellung diagnostischer Trainingsfälle für den Einsatz in oben genannten Trainingssystemen kommen sogenannte Autorensysteme zum Einsatz, die über eine Eingabemaske die Eintragung verschiedener Informationen zu einem kompletten Fall zusammenfügen. Doch selbst mit guten Autorensystemen (CASUS - INSTRUCT AG)(d3web.Train, 2008) (CAMPUS - Medizinische Fakultät Heidelberg, 2008) ist dies eine aufwändige und zeitintensive Aufgabe. Um diesen Prozess zu vereinfachen und zu beschleunigen wurde am Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik ein Tool geschaffen, welches ein Einlesen der Fälle aus Arztbriefen erlaubt.

Diese Vorgehensweise hat verschiedene Vorteile (Betz C. B. H.-P., 2004):

- Das vorhandene Fallangebot kann binnen kurzer Zeit für den Benutzer erweitert werden
- Je nach Bedarf können mit wenig Zusatzaufwand neue Fälle erstellt werden (Voraussetzung sind gute Arztbriefe)
- Es können jederzeit Veränderungen oder Erweiterungen in der Ursprungsdatei eingefügt und der Fall neu eingelesen werden
- Für die Dozenten wird damit die Möglichkeit geschaffen in Lehrveranstaltungen aktuelle Patienten auf der Station im Trainingsprogramm zu präsentieren ohne sich dabei mit Autorensystemen auskennen zu müssen. Weiter kann der Verlauf zeitnah eingepflegt und im Kurs verfolgt werden. Außerdem können Patienten im Gegensatz zu „fremden“ virtuellen Patienten live im Anschauungsunterricht auftreten.

In den folgenden Unterkapiteln werden die einzelnen Schritte einer typischen Fallaufbereitung gezeigt und näher erläutert werden.

2.1.2.2 Typische Architektur eines Arztbriefes

- "Vorspann": Absender, Adresse, Anrede, …
- Diagnosen
- Anamnese
- körperlicher Untersuchungsbefund
- Laborwerte
- technische Untersuchungen
- Beurteilung (einschl. Therapie)
- "Nachspann": Grüsse, Unterschrift

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1 Screenshot eines Arztbrief in MS Word

Basierend auf dieser typischen Struktur eines Arztbriefes wurde das Tool KnowMe/Phoenix (Betz C., 2001) entwickelt, um eine automatisierte Generierung von Trainingsfällen zu ermöglichen. Aus diesem Grund ist diese einheitliche Struktur eine zwingende Voraus-setzung für einen fehlerfreien Fallgenerierungsvorgang.

Auf die Besonderheiten der Formatierung für einen möglichst reibungsfreien Einlese- und Erstellungsvorgang wird weiter unten im Text eingegangen.

2.1.2.3 Einzelne Schritte in der Fallgenerierung

2.1.2.3.1 Erweiterung des Arztbriefes

In der Klinik werden alle patientenbezogenen Informationen primär in einer Akte, sowie zusammenfassend in einem Arztbrief abgelegt. Diejenigen Informationen, die nur unvollständig oder in komprimierter Form im Arztbrief vorliegen, werden durch Originalbefunde aus den Patientenakten komplettiert. Dabei wurden die Originalbefunde mit Hilfe eines handelsüblichen Scanners von Canon (“CanoScan 3200F“, 1200x2400 dpi) (Canon, 2008) und einer Digitalkamera von FujiFilm („F601 Zoom“, 3.1 MegaPixel) (FujiFilm, 2008) auf der Hardware-Seite digitalisiert.

Als Software zur weiteren Bearbeitung der neuen digitalisierten Inhalte wurden vor allem Photoshop 7 (für Bildmaterial) von Adobe (Adobe Systems Incorporated) und Microsoft Word XP (für Textmaterial) (Microsoft) eingesetzt.

Das erstellte Bildmaterial wurde zu jedem Fall in einem separaten Material-Ordner gespeichert, anonymisiert und archiviert. Auch wurde eine Bilddatenbank programmiert, die ein späteres Navigieren und schnelles Auffinden ermöglichen sollte.

2.1.2.3.2 Inhaltliche und Formelle Anpassung

Im nächsten Schritt folgte eine Anonymisierung des Arztbriefes sowie eine weitere inhaltliche Anpassung und Straffung des Textes. Die Erweiterung des Arztbriefes ist dabei sehr von der Qualität des Originalbriefes abhängig. Die Komplettierung mit multimedialen Inhalten ist dabei optional.

Als formelle Anpassung wurde der Text, falls notwendig, strukturiert und für den Einlesevorgang neu formatiert (Hörnlein, 2004).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2 Screenshot: Anonymisierung eines Arztbriefes

2.1.2.3.3 Formulieren der Fragen / Schaffung der Prüfungskomponente

In diesem Schritt der Fallaufbereitung wurde eine Prüfungskomponente zur Wissensüberprüfung während der späteren Fallbearbeitung im Trainer in den Arztbrief integriert. Dies erfolgte durch Implementierung von Fragen, die sich stets auf bereits bekannte (meist aktuell dargebotene) Informationen aus dem Text bezogen. Oft wurde dabei auch eine Bildbefundung verlangt. Die Fragen wurden hauptsächlich im Multiple-Choice-Format gehalten. Mehrfachnennungen waren möglich. Durch die spezielle Formatierung des Textes werden dem Fallerstellungs-Tool die Frage an sich sowie richtige und falsche Antworten markiert.

Auch die Prüfungskomponente ist optional.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3 Screenshot: MC-Frage zur späteren Wissensüberprüfung in der Fallbearbeitung

2.1.2.3.4 Formatierung

In diesem Bearbeitungsschritt erfährt das gesamte Word-(StarOffice-)Dokument eine vordefinierte Formatierung, die für eine fehlerfreie Fallgenerierung notwendig ist. Somit ist die Bearbeitung des Arztbriefes abgeschlossen. Fallanfang und Fallende sind durch die Anrede („Sehr geehrter…“) und am Fuße des Arztbriefes durch die Grußformel („Mit freundlichen Grüßen“) definiert. Legende:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-2 Formatierung des Textes und Funktion für die Konvertierung

2.1.2.3.5 Einlesen und Zerlegung der Arztbriefinformationen

Der Arztbrief wird beim Konvertieren von einem Textdokument zu einem Fall zuerst durch das Tool analysiert und anschließend in verschiedene vordefinierte Blöcke zerlegt, die fortan auch getrennt behandelt werden müssen. Diese Zerlegung dient dazu, die Informationen später in D3web.Train portionsweise zu präsentieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4 Screenshot: Arztbriefkonverter Phoenix (KnowMe)

2.1.2.3.6 Überprüfung der zerlegten Inhalte

Die Überprüfung des Ergebnisses der Konvertierung erfolgt in einem extra Vorschaufenster, in dem der gesamte Fall aufgeschlüsselt und in inhaltliche Blöcke aufgeteilt dargestellt wird. Integriert ist ein Fehlerwarnsystem, das den Autor visuell (durch farbliche Markierung) auf eventuelle Probleme im Quelldokument hinweist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5 Screenshot: Log-Screen der Konvertierung

2.1.2.4 Arztbriefkonvertierungstool: Phoenix (vormals KnowMe)

Um effektiv und schnell Fälle ins D3-Format konvertieren zu können, wurde am Lehrstuhl für Künstliche Intelligenz und angewandte Informatik IV (Leitung Prof. Puppe) von den Informatikern Alexander Hörnlein und Christian Betz unter der Leitung von Prof. Puppe eine Anwendung geschaffen, ein so genannter „Parser“, der eine (fach-) unabhängige, da regelbasierte, Generierung von Trainingsfällen gestattete, indem ein Fall aus einem modifizierten und mit multimedialen Inhalten komplettierten Arztbrief erstellt werden konnte. Der Arztbrief musste dabei in einem XML(-unterstützenden)-Format vorliegen (früher StarOffice (=“.sxw“), heute MS Word (=“.doc“)) (Betz C. B. H.-P., 2004)(Hörnlein, 2004)(Betz C., 2001).

Da dieses Tool eine lokale Installation auf dem Rechner des Autors benötigte, wurde eine neue Lösung, „Phoenix“, entwickelt. Diese ist webbasiert, also ubiquitär verfügbar, und kann das auf einem Server liegende KnowMe steuern und die Falldaten übertragen. Ziel war es, das für einen Autor zur Bedienung des Autorensystems KnowMe nötige Grundwissen auf Null zu reduzieren und uneingeschränkt verfügbar zu machen. Beide Eigenschaften zielten darauf ab, mehr Autoren für mehr neue Fälle zu rekrutieren.

2.1.3 Struktur eines Generierten Trainingsfalles

Folgendes Schema soll einen generierten Trainingsfall in die einzelnen inhaltlichen Blöcke aufgeteilt grafisch darstellen. Ebenso Teil des Schaubildes ist die Abfolge der Blöcke während der Präsentation im Trainingssystem sowie deren aktive und passive Bearbeitung. An bestimmten Stellen (in der Abbildung markiert mit „*“) erlaubt das System eine Wissensüberprüfung durch Zwischenfragen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-6 Grafisch dargestellte Struktur eines generierten Trainingsfalles

in seinen wichtigsten Bestandteilen

2.1.4 Liste der Fälle und Diagnosen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-3 Fallliste der Allergologie

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-4 Fallliste der Immundefektsyndrome

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-5 Fallliste des rheumatologischen Formenkreises

2.1.5 Systemvorstellung

2.1.5.1 Online-Kurs-System

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-7 Systemvorstellung: Willkommens-Screen im Online-Kurs-System

(übersichtshalber modifizierter Screenshot)

Der Screenshot zeigt den individuellen Willkommens- und Leistungs-Screen im Online-Kurs-System. Die Fallliste gibt einen Überblick über die verfügbaren Fälle und informiert den User über deren jeweiligen Bearbeitungsstatus und bisherige Erfüllung der Klausur-voraussetzungen. Über den „Start-Button“ können die Fälle gestartet werden.

Die Fallliste sowie der Bearbeitungsstatus werden in Echtzeit vom System aktualisiert.

Der Username entspricht der Matrikelnummer.

Nach der Klausur werden hier die Note sowie die erreichte Punktzahl angezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-8 Systemvorstellung: Bearbeitungsstatus der Fälle

(Ausschnittsvergrößerung aus dem Leistungs-Screen)

Der Bearbeitungsstatus bietet dem Benutzer durch die Anzeige in den Ampelfarben einen raschen Überblick über seine bisherigen Leistungen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-9 Systemvorstellung: Auswahl-Screen der Online-Bedienkurse

Die Online-Bedienkurse dienen dem Erlernen der Funktionen und der Bedienung des Programms und können über den „Start-Button“ gestartet werden.

2.1.6 Fallvorstellung und Screenshots

Im Folgenden wird der „knappe Kurs“ vorgestellt.

2.1.7 D3web.Train

2.1.7.1 Ankunft im System, einführender Screen eines Falles

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-10 Screenshot: Intro

Der obere Kasten zeigt das „Intro“, eine kurze Einführung in den Fall. Der untere Kasten liefert eine kurze Einführung in die wichtigsten Funktionen und in die grobe Bedienung des Programms.

Der Fall wird mit dem „Weiter“-Button gestartet.

2.1.7.2 Die virtuelle Patientenakte und deren Steuerung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-11 Screenshot: Virtuelle Patientenakte

Während der Fallbearbeitung ist eine Dreiteilung des Screens vom System vorgegeben.

Der große Frame rechts beinhaltet die Akte des virtuellen Patienten. Die Reiter oben zeigen jeweils die gewählte Untersuchungsgruppe an. Mit dem „Weiter“-Button links oben können Ergebnisse weiterer Untersuchungen angefordert werden.

Die Lupensymbole hinter den Untersuchungsüberschriften, sowie der Button „Bilder usw. starten“ links oben, öffnen ein neues Fenster zur Betrachtung bildhafter Befunde.

Über den Link „Sie müssen dazu noch eine Frage beantworten“ gelangt der User zum Fragenfenster.

Sind alle Untersuchungsergebnisse betrachtet und alle Fragen beantwortet worden, müssen im Aktionsfenster die Diagnosen ausgewählt werden, die dann direkt darunter im Diagnosenfenster angezeigt werden. Danach kann der Fall mit dem „Fall abschließen“-Button beendet werden und der User bekommt seinen Score sowie den Abschlußkommentar des Autors angezeigt.

2.1.7.3 Bildbetrachtung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-12 Screenshot: Bildbetrachtung

Die Leiste oben zeigt alle Bilder in Miniaturansichten (Thumbnails). Mit einem Klick auf den Pfeil-Button direkt unterhalb dieser Thumbnails wird das gewählte Bild vergrößert im blau unterlegten Anzeigerahmen eingeblendet. Mit einem Klick in das Bild bzw. auf das Lupensymbol in der rechten oberen Ecke wird es in einem neuen Fenster noch weiter vergrößert bzw. in Originalgröße angezeigt.

Der Linke Frame zeigt die Untersuchungen, zu denen Bildbefunde existieren. Durch einen Klick auf eine Untersuchungsgruppe werden die dazugehörigen Thumbnails in der Leiste oben markiert dargestellt.

2.1.7.4 Erstellen der Befunde

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-13 Screenshot: Bildbefundung

Mit den Buttons links oben kann zwischen dem Anzeigemodus und den Bildfragen gewechselt werden. Darunter im Kasten sind die zu bearbeitenden Fragen zu sehen, die oben markierte Frage wird aktuell im Kasten darunter angezeigt. Die zur Beantwortung der jeweiligen Frage relevanten Bilder sind mit einer leichten blauen Markierung unterlegt.

Soll eine Frage beantwortet werden, müssen die Kästchen vor den richtigen Antworten angehakt und mit einem Klick auf den „Eintragen“-Button in das System übertragen werden. Anschließend kann man sich durch Markieren einer Frage (grün umrandete Kästchen) und durch einen Klick auf den „Feedback“-Button die Bewertung vom System anzeigen lassen.

Der „Fenster schließen“-Button schließt das aktive Fenster und beendet die Bildbetrachtung bzw. –befundung.

2.1.7.5 Diagnosenauswahl

Abbildung in dieser Leseprobe nicht enthalten

Der Diagnosebaum im Aktionsfenster kann durch Klicken auf die Plus- oder Minussymbole erweitert oder geschlossen werden.

Die Symbole hinter den Diagnosen beinhalten Links zu Websites, die Hintergrundinformationen zur jeweiligen Diagnose bieten.

Zwischen den beiden Kästen befindet sich die Textsuche für Diagnosen. Mit den dortigen Buttons kann das Suchergebnis als Diagnose ins System übernommen, im Baum angezeigt oder als voll aufgeklappter Baum ausgedruckt werden.

Das Diagnosefenster zeigt dem User an, wie viele Diagnosen vom System erwartet werden.

Durch klicken auf eine Diagnose im Aktionsfenster erscheint diese Im Diagnosefenster (siehe links Legende).

Durch einen Klick auf den „Feedback“-Button zeigt das System ein Bewertungsfenster an.

Abbildung 2-14 Screenshot: Diagnosenauswahl

Abbildung in dieser Leseprobe nicht enthalten

[...]