Skip to end of metadata
Go to start of metadata

The CAMPUS-System

The CAMPUS-Systems consists of the following parts

  • Authoring system
    • Authoring module for virtual patients
    • Authoring module for key feature cases
  • Classic-Player for simulative work through virtual patients
  • Card-Player for a card based approach (rapid e-learning)
  • Assessment software

Authoring system for virtual patients

In the VP authoring system you can set information about the patient, including:

  • Medical history questions
  • Physical examinations
  • Technical examinations
  • Laboratory tests
  • Diagnosis
  • Therapies
  • General information (information about the patient, prognosis, summary etc.)

The system reflects the path through the case:

  1. Introduction
  2. Medical history taking
  3. Physical examination
  4. Suspected diagnosis

This is the first block where you can (in the simulative Player) switch from one point to the other. The first block ends after you have decided which suspected diagnosis you think is correct. After that you will get:

  1. Feedback about the similarities between your choices and the choices of the author (medical history, physical exam, diagnosis)
  2. Possible emergency therapy
  3. Question about the treatment way (out-patient, in-patient, intensiv care)

With the last point you start the so called diagnostic therapy loop. In a loop you can concentrate on one aspect of the treatment, e.g. to stabilize the patient first. You can have one or many loops. When a loop ends the VP can be closed or the question about the treatment for the next loop is asked again. For that a loop consists of:

  1. Question about the treatment way (out-patient, in-patient, intensiv care)
  2. Physical exam
  3. Technical exam
  4. Laboratory test
  5. Working diagnosis

All items except the first question can be used in any order here again (in the Classic-Player). After choosing the working diagnosis you will get:

  1. Feedback about similarities between your choices and the choices of the author (physical, technical exams, laboratory tests, diagnosis)
  2. Treatment
  3. Feedback about the feedback
  4. Possible follow-up examination (physical, technical or laboratory tests)
  5. Feedback about the follow-up examination

Then, the next loop starts or if the VP ends you will get:

  1. A prognosis
  2. A summary

One specialty of CAMPUS is that it is vocabulary based. So, there are predefined questions and normal answers for medical history, physical exams, technical exams, laboratory tests, treatments (several thousand items) and we use ICD-10 for diagnosis.
That's a major problem for MVP as we cannot import VPs from MVP here as MVP only supports free text for those items.

The second specialty is that CAMPUS supports knowledge question at every point (to an exam or to a block), media files and links.

Authoring system for key feature cases

This module acts differently. It's originally designed for exams where you can have different cases with different sections. Each section is a screen (card) containing text, questions and media files. We currently support the following question types:

  • MC (single, multiple)
  • Matrix (single, multiple)
  • Freetext
  • Gap text
  • Interval (to ask for a special number inside a predefined interval)
  • Long menu
  • Hotspot
  • Region of intrest

Although original designed for exams the key feature editor is also used for any possible MVP VP, as this is also card-based and the import in a vocabulary based system is impossible. So we use this editor for import and export a MVP VP card and linear based. As there's no differentiation between text and for instance physical exams, those items are transformed to plain HTML and imported as a whole in a card in which they are referenced.

The Classic-Player

The Classic-Player was the first player which was developed for CAMPUS and uses a semi-linear (see VP authoring system), simulative approach, so each student can ask or do whatever he wants to do (no restriction here). As it's vocabulary based we can give feedback about the similarities between his choices and the ones from the author.

The Card-Player

Because students told us that working in a simulative way is sometimes to time consuming (e.g. for quick knowledge tests before an exam) we developed a second player for rapid e-learning (HTML based, Card-based). Using the VP authoring system you can use both players depending on the kind of teaching you prefer at the moment (for instance the simulative way gives greater success but takes more time).

The Card-Player supports the CAMPUS VP mode where the way of the Classic-Player is exported to cards and the possible choices are reduced but it also is capable of playing any possible MVP file natively (currently in development).

Depending on the mode people can navigate one card after the other with the ability to look back (CAMPUS mode) or jump at any card at any time (CAMPUS mode). In the MVP mode the activity model decides that.

The Assessment system

Just to be complete the assessment system uses its own standalone player for exams which focuses on security (legal and technical) so it's for instance independent on the server after uploading the exam so a network-, server or database failure does not end the exam.

Current state of supporting MVP

The import

As described before we can import a CAMPUS case directly in the VP authoring system but because of the vocabulary based approach we cannot import any other MVP VP in the VP authoring system. Instead we import the VP in the key feature authoring system where each card is a section which one text block, questions and media files. All referenced VPD elements are transformed into one HTML text block for each card. As the cards are linear ordered each activity node is just imported as a card with the order in the XML file.

The export

There are two export possibilities: An export from the VP authoring system or the key feature editor.

Export from the VP authoring system

The export uses all the possibilities of the VPD elements (physical exam, diagnosis, labs etc.) as the VP is strict structured. In the DAM we put in the knowledge question in QTI with an alternative (path) which shows them in HTML for the information only. The activity model is ATM quite simple - just one card after each other with no way back (we might change that). Each card reflects a new situation in the Classic-Player (e.g. one card for medical history, one card for feedback and so on).

Export from the key feature editor

The export here is even easier: One card is one activity node in a linear approach containing a VPD Text, questions in QTI and media files.

  • No labels