Introduction

The role of a Virtual Learning Environment (VLE) like Moodle, OLAT, Dokeos or Blackboard is to aggregate educational content and to provide a communication platform for students and their teachers in e-learning and blended learning scenarios. A VLE offers usually a collection of general purpose tools for content authoring, remote collaboration, assessment and user management. The progress in computer-aided education, as well as the raising expectations of students require stepping up in the e-learning services beyond the generic tools offered by traditional VLEs. In the very specific field of medical education such services include e.g. presentation of virtual patient cases¹, tools for distant medical consultations² or medical workflows authoring³. A virtual patient (VP) is defined as „an interactive computer simulation of real-life clinical scenarios for the purpose of medical training, education, or assessment”⁴. A great variety of virtual patient systems, differing significantly in the applied data models, navigation methods, and supported learning designs is available⁵. European projects like eViP (electronic Virtual Patients)⁶ aim at collecting virtual patient cases for exchange and repurpose.

Background

Neither is the purpose of the virtual patient systems to replace existing VLEs of medical universities nor is a generic VLE expected to play the role of a specialized virtual patient system. It is the belief of the authors that the best results may be achieved by integrating these two e-learning services. A set of eight requirements on virtual learning environments generated by the use of virtual patients has been presented by the authors at the KDM'09 conference in Zakopane⁷. The VLE should provide (a) a university-wide single sign-on (SSO) mechanism to all e-learning services (including VP tools) offered by the school. It is a significant drawback of the current VP implementations to require separate authentication mechanisms, which cause lot of confusion among students. The VLE should also provide (b) lists from which the student can be enrolled into VP courses. A student should be present in those lists since his/her first days at the university. Important is (c) the automatic synchronization of courses availability on VLE and VP systems. Switching off modules of courses in VLE should cause the same effect in a subordinated VP course. These three features (a-c) together with the SSO mechanism would form a central Authentication and Authorization Infrastructure (AAI) for virtual patient usage. There should be also the possibility of (d) exporting at least a well-defined subset of students' performance indicators. Specialized reports on students' activities should be kept in the individual systems but accessible transparently with the AAI from the VLE. Support for (e) randomized controlled studies (like random assignment of different versions of patients to students) measuring the progress of learning could also be helpful. A very important factor is (f) the quality control of available cases and courses. Evaluation tools like students' or external reviewers' questionnaires need to be assignable to concrete VPs and protected from malpractices (like filling out the same questionnaire by a single person multiple times). In addition, the interface should be flexible enough to use external evaluation forms (like e.g. the eViP VP evaluation questionnaires). A fully-fledged implementation of the interface should even allow (g) the binding of a VLE with more than one VP system. Finally, it should be possible (h) not only to treat VPs as mere courses, but to incorporate (parts of) VPs in a VLE using more elaborate instructional designs, such as asynchronous collaborative learning, face-2-face group discussions, assessment of clinical reasoning.

This paper extends the previous contribution focusing on the presentation of three practical examples of standard-based integration of virtual patient systems into the existing e-learning infrastructure of a medical faculty. None of the presented integration scenarios fulfils all eight requirements, however, the presented solutions are important steps on the way towards a full integration of VP and VLE systems.

Methods

The achievement of the above outlined requirements can be reached partially or fully by the application of different software standards. There is a growing number of existing general-purpose e-learning specifications like SCORM, AICC, IMS, federated identity-based authentication and authorization mechanisms like Shibboleth, as well as specialized medical standards (as MedBiquitous MVP⁸) that can be applied in the implementation. In this paper a few of possible implementation scenarios are outlined and presented from the perspective of the authors' institutions.

Experience with VLE-VP integration from LMU University of Munich

At the Ludwig-Maximilians University (LMU) in Munich both point-to-point and multi-institutional solutions for integration of virtual patient systems has been used. Focus of this section will be the requirements (a) - i.e. single sign-on mechanisms, (b) - i.e. identity management, and (g) - i.e. binding VLE with more than one VP system.

A point-to-point connection was implemented from the VLE Moodle to the LMU's VP system CASUS⁹. This was achieved by the SCORM/AICC-HACP standard (SCORM: Sharable Content Object Reference Model, AICC: Aviation Industry Computer-Based Training Committee, HACP: HTTP-based AICC/CMI Protocol, HTTO: Hypertext Transfer Protocol, CMI: Computer Managed Instruction). This simple and robust protocol was established in 1998 and is used wide spread by Learning Management Systems. For a link from the Moodle platform to the CASUS course a set of descriptor files has been generated. The creation of such a link in Moodle is performed by uploading SCORM/AICC-HACP descriptor files and setting some Moodle specific properties, like optional external window, size of an external popup window, and others. The main problem came up when it was discovered that Moodle does not implement AICC-HACP 100% according to the specification. A patch had to be developed to make Moodle standard conform. This patch at this moment only handles Moodle session management in file system. For handling also database session management the patch has to be enhanced. It is planned to document this in detail and make this initiative available for the Moodle open source development.

If we are considering bi-directional navigation in VP systems the linkage mechanism described above can be a problem especially for guided resources. The navigation is working only in one way: for example it is possible to have an AICC link from the VLE to a VP-system, but not the other way round. This other direction might be useful if the VLE provides learning resources which shall be linked directly with a virtual patient.

For all point-to-point connections there are local issues which are particular for a given interface. To make such interface working for other systems it must be slightly modified. Also the identity management issue in most cases has not been solved by such integration solutions.

In 2002 there started a German project funded by the BMBF called CASEPORT. In this project participated four collaborating VP systems (including LMU's VP system CASUS)¹⁰. The aim was to develop new VPs and share them throughout German medical faculties. In contrast to other projects like for example eViP¹¹ the VPs were kept in their original VP system and have not been exchanged between different data models. Therefore, a course of different VPs could involve the use of up to four different VP systems. A portal server communicated via a SOAP (Simple Object Access Protocol) interface with the four connected VP systems. Each of them registered their VPs via this interface at the portal server. The user management was implemented through a LDAP (Lightweight Directory Access Protocol) server via a SOAP interface.

There are more projects like CASEPORT which offer a great variety of useful learning resources but integration into a VLE is not supported in a highly sophisticated way. For example the Virtual University of Bavaria (VHB)¹² offers a platform of interdisciplinary e-learning resources, but the connection to the VLE used by the universities accessing the VHB is proprietary.

Although most VP systems offer their own identity management it is no longer necessary to create the user accounts separately in the VP system, but give them access through a VLE. This reduces the administrative effort and enhances the usability for the learners having only one account for all online resources (SingleSignOn). The VP system can still offer the possibility to use its own result calculation and feed back these results to the teachers within the VP system or if implemented, return into the VLE.

Experience with VLE-VP integration from the Jagiellonian University

The Department of Bioinformatics and Telemedicine at the Jagiellonian University Faculty of Medicine (JUMC) is using the Blackboard Academic Suite® virtual learning environment in all their courses involving in total more than 1000 students annually. Being also part of the eViP project, the Jagiellonian University utilizes the virtual patient system CASUS® developed by the Ludwig-Maximilians University and INSTRUCT AG in Munich for their teaching activities¹³.

One of the aims of the eViP project was to evaluate the quality of the project's VPs and their integration into the curricula. This addresses the requirement (f) in our list of desiderata. A set of evaluation questionnaires has been developed for this purpose¹⁴. These tools have been implemented at the Maastricht University as web applications and are accessible for the project partners via a REST interface. JUMC has integrated these services into their courses via a SCORM sharable content object which communicates with the VLE (Blackboard) via the SCORM Run-Time API.

The core of the SCORM 1.2 conformant object was created with the RELOAD editor¹⁵ and then manually altered to implement the Maastricht's interface. The relevant functions were implemented in JavaScript technology. The package was imported into the Blackboard VLE. Blackboard supports SCORM packages via an additionally installed building block. On activation of the SCORM package by a student the learning object is initialised and reads the local user parameters like, for example, the student's unique id. The identifier is required to assure that one user does not fill out the same questionnaire multiple times. Questionnaires submitted by users not enrolled in the course may be discarded on request from the questionnaire repository. The user id is hashed with the MD5-algorithm to impede the recognition of students' identity while analysing the results. Finally the evaluation questionnaire for the selected virtual patient is opened.

Experience with VLE-VP integration from Maastricht University

VPs can be used effectively in elaborate educational scenarios involving group activities such as (offline or face-to-face) group discussions, moderated evaluation sessions, or polling. VP sessions incorporated in such scenarios are called in-session VPs, or iVPs. A smooth integration of such scenarios requires tight integration of the VLE and VP system.

In-session VPs can either be divided or undivided. In an undivided VP session, students run a VP session individually from start to end as a single learning activity. This can happen simultaneously for all students in the group, or offline within a given period of time. VP session can also be divided into separate learning activities. For instance, activity 1: start of the session to preliminary diagnoses, activity 2: anamnesis and physical examination, activity 3: first diagnosis, etc. The VP environment can be equipped with tools to allow for such breakpoints. Typically, the VP learning activities will be performed synchronously by all participating students and can be interspersed with group activities such as face-to-face discussions or polling. At Maastricht University, elaborate scenarios are designed and piloted using the VP system Campus¹⁶, the VLE/LAMS Dokeos¹⁷, and some additionally developed tools. For this the virtual patient was integrated as part of the learning path in Dokeos through the use of external links, a standard feature of Dokeos. Choices that students make in Campus are fed through a secure (tunnelled) database connection into a web-based feedback system, developed in PHP/PostgreSQL. The feedback is presented to the group a number of times during the session. It is clear that in this implementation scenario, the focus was put on our last desideratum (h).

Results

In order to illustrate the proposed solutions some examples from the integrations are presented below. The screenshots from the course integrations are presented in their original versions (German for LMU, Polish for JUMC) or English (for Maastricht).

Fig 1 Moodle - CASUS integration via a SCORM/AICC-HACP interface

source: authors
The LMU's integration of the virtual learning environment Moodle with the virtual patient system CASUS is presented in Fig. 1. Students open the relevant course (e.g. in Internal Medicine) hosted at the Moodle platform and may select AICC-HACP links to open the attached VP course in the CASUS environment without the need of a repeated manual authentication.

Fig. 2 presents a SCORM object created for evaluation of two virtual patients developed for the eViP project. The user selects the patient to evaluate by clicking on the corresponding link in the Blackboard's SCORM Run-Time Environment. If the patient has not been evaluated by the student yet, the Maastrichts' evaluation tool will be opened. Otherwise an error message will be displayed.

Fig 2 SCORM sharable content object integrating a course in the VUE system Blackboard with the VP evaluation tool developed for the eViP project

source: authors
As an example for the iVPs integration the authors present a scenario involving a paediatric case for clerkship students. In order to incorporate the VP into Dokeos, the html-based Card-player of Campus was used instead of the high-end but Java-based Classical player. The VP (called ‘Lars') was used undivided as the first learning activity and was followed by a poll and a moderated face-to-face group discussion. To facilitate the polling, we integrated DRBPoll¹⁸ into Dokeos. Fig. 3 shows a screen of Dokeos the learning path of the iVP (left side) and a poll form which is part of the path (right side).

Fig 3 Screenshot of Dokeos showing the learning path, including VP 'Lars', and a poll form

source: authors

Conclusions and future work

The goal of this paper was to outline the practical issues which may arise while integrating virtual patients system into virtual learning environments. Implementation examples from three institutions have been demonstrated to show a variety of possible solutions for interoperability problems encountered in the usage of virtual patients within an existing e-learning infrastructure. For each scenario we indicated its focus on VLE-VP integration desiderata (a-b,g-h). For some of the requirements we still seek for good, standard-based solutions (c-e). Our experiences show that the adherence of VLE environments is not always perfect or stable and sometimes requires additional implementation work in order to reach the requirements. At the moment it appeared not to be possible to fulfil all requirements at the same time. Future plans include closer integrations involving application of federated identity-based AAI as e.g. Shibboleth and specialized medical e-learning standards as e.g. the MedBiquitous specifications.

Bibliography

• C. Balasubramaniam, T. Poulton, eViP: Electronic virtual patients, „The Newsletter of the Higher Education Academy Subject Centre for Medicine, Dentistry and Veterinary Medicine” 2008, No. 1 (16).
• J. Bernauer, M.R. Fischer, F.J. Leven, F. Puppe, CASEPORT: Systemintegrierendes Portal für die fallbasierte Lehre in der Medizin, Telemedizinführer Deutschland, 2003.
• D. A. Cook, M. M. Triola, Virtual patients: a critical literature review and proposed next steps, „Medical Education” 2009, No. 43 (4).
• B. de Leng, J. Donkers, C. Brasch, S. Huwendiek, A.A. Kononowicz, Evaluation instruments to support educators in making deliberate choices when they use virtual patients to teach clinical reasoning, International Conference of Virtual Patients, Kraków, Poland, 2009.
• R. Ellaway, C. Candler, P. Greene, V. Smothers, An Architectural Model for MedBiquitous Virtual Patients, Baltimore, MD, MedBiquitous, 2006, Draft White Paper, http://groups.medbiq.org/medbiq/display/VPWG/MedBiquitous+Virtual+Patient+Architecture.
• R. Ellaway, T. Poulton, U. Fors, J.B. McGee, S. Albright, Building a virtual patient commons, „Medical Teacher” 2008, No. 30 (2).
• M.R. Fischer, CASUS - An authoring and learning tool supporting diagnostic reasoning, [in:] Use of Computers in Medical Education (Part II), „Zeitschrift für Hochschuldidaktik” 2000.
• A. Gackowski, Ł. Czekierda, A. Chrustowicz, J. Cała, M. Nowak, J. Sadowski, P. Podolec, M. Pasowicz, K. Zieliński, Development, Implementation, and Multicenter Clinical Validation of the TeleDICOM - Advanced, Interactive Teleconsultation System, „Journal of Digital Imaging”, 2010.
• S. Garde, M. Bauch, M. Haag, J. Heid, S. Huwendiek, F. Ruderich, R. Singer, F.J. Leven. CAMPUS - Computer-based training in medicine as part of a problem-oriented educational strategy. „SLEID” 2005, No. 2 (1), http://sleid.cqu.edu.au/viewissue.php?id=6.
• M. Holzer, A. Hörnlein, M. Atzmueller, R. Singer, S. Schlott, F. Leven, F. Puppe, M. Fischer, Interoperability of case-based training systems in medicine: The CASEPORT approach, [in:] Proceedings zum eLearning in der Medizin und Zahnmedizin, 2005.
• S. Huwendiek, B. de Leng, N. Zary, M.R. Fischer, J. G. Ruiz, R. Ellaway, Towards a typology of virtual patients, „Medical Teacher” 2009, No. 31 (8).
• S. Huwendiek. H. Haider, B. Tönshoff, B. de Leng, Evaluation of curricular integration of virtual patients: Development of a student questionnaire and a reviewer checklist within the electronic virtual patient (eVIP) project, „Bio-Algorithms and Med-Systems” 2009, No. 5 (9).
• A.A. Kononowicz, I. Hege, M. Adler, B. de Leng, J. Donkers, I. Roterman, Requirements on Virtual Learning Environments generated by the use of Virtual Patients, Proceedings of the KU KDM'09 Conference, Zakopane, Poland, 2009.
• A.A. Kononowicz, Th. Holler, The development of a tool for teaching and learning clinical pathways, „Bio-Algorithms and Med-Systems” 2008, No. 4 (8).
• A.A. Kononowicz, A.J. Stachoń, I. Roterman-Konieczna, Wirtualny pacjent jako narzędzie nauczania problemowego w kontekście europejskiego projektu eViP, „e-mentor” 2008, No. 1 (23), http://www.e-mentor.edu.pl/artykul_v2.php?numer=23&id=508.
• A.J. Stachoń, A.A. Kononowicz, I. Roterman-Konieczna, I. Hege, M. Holzer, M. Adler, M.R. Fischer, Scenarios for the implementation of VPs into the medical curriculum by the example of JUMC's participation in the eViP-Programme, AMEE Conference, Prague, Czech Republic, 2008.
• R. Tadeusiewicz, Application in VP systems individualization of distance learning process using student's psychological profiles obtained by means of artificial intelligence methods, „Bio-Algorithms and Med-Systems” 2009, No. 5 (9).
• N. Zary, I. Hege, J. Heid, L. Woodham, J. Donkers, A.A. Kononowicz, Enabling Interoperability, Accessibility and Reusability of Virtual Patients Across Europe - Design and Implementation, „Studies in health technology and informatics” 2009, No. 150.

Netography

• Dokeos, http://www.dokeos.com.
• DRB Pools, http://www.dbscripts.net/poll.
• electronic Virtual Patients, http://virtualpatients.eu.
• MedBiquitous Virtual Patient Format, http://www.medbiq.org/working_groups/virtual_patient/index.html.
• Reload Editor http://www.reload.ac.uk/.
• Virtual University of Bavaria (vhb), http://www.vhb.org.