Skip to end of metadata
Go to start of metadata

1. System Description

The system is written in perl/mason and consists of the following components:

  1. Administrative system to create patient types and tests (physical exams, diagnostic tests)
  2. Authoring system
  3. Player
  4. Assessment system (enables expert to review a student's selections, textual input, navigation pathway, quiz interaction)


The TUSK player has two major navigation approaches: linear and global.

  • Linear navigation enables a user to navigate to the next "phase" (activity node) or any previously visited phase. Navigation to the next phase is made available by a button in the central part of the screen. Navigation to a previously visited phase is made possible by a navigation on the left-hand side of the screen.
  • Global navigation enables a user to navigate to any phase at any time. Navigation to a new phase is made possible only through interaction with a navigation on the left-hand side of the screen

Cases created with either type of navigation can contain as many phases as they like, and phase types can be presented in any order. For example, an author could have chief complaint be the first node visited, or the fifth.

From any given phase, there might be hyperlinks to content from within the TUSK system (images, videos, webpages, etc.) or to any external web address. Alternately, TUSK content can be presented inline.

Certain pieces of data (physical exams, diagnostic tests, diagnoses, etc.) can have "expert feedback" affiliated with them. Sometimes this is presented inline, sometimes it is made available via a hyperlink.

3. Pedagogical Approach

The TUSK case simulator strives not only to provide students with an educationally valuable environment for patent case simulation but also to give faculty a streamlined and user friendly interface to design and provide cases. The objective of the case tool is to provide a concise, yet information rich experience, limiting the total interaction to something as short as ten to fifteen minutes and perhaps as long as 30 minutes.  Each module will provide students with information, solicit input, optionally provide feedback, and record the input into logging and scoring mechanisms as appropriate. A given phase may provide students with the ability to interact, or it may take only a single round of feedback, but in the end move the student along to the next phase.  Faculty envisioned the use of this tool as a way to reinforce knowledge for naïve learners as well as to model appropriate interactions.  Phases could be reused such that the stem of a simple case could easily be made more complicated for more advanced learners.  Also for more advanced students it was seen as a mechanism to work on clinical reasoning skills through multiple trials in a safe environment and through rich feedback from experts.

4. Data Representation

Our data is generally highly structured, although the option exists for the author to eschew this structure. For example, an author could create a phase with interview questions or with physical exams, or they could avoid these structured elements and have a phase that contains only free text. While a highly structured package would be helpful for us when importing from another system, we could also handle a package where data is represented solely as VPDText; furthermore, it is likely that even with a structured import, there might be occasions where we would need to translate some data into VPDText due to system incompatibility. We have several "types" of data that map well to the Medbiq spec. For transfer between TUSK systems, we will take advantage of the following MVP elements that map to our own internal data types:

  • VPDText
  • InterviewItem
  • PhysicalExam
  • DiagnosticTest
  • Diagnosis
  • Intervention 

While most of our data types map well to the spec, there are some outliers that will have to take advantage of Extensible Info. For example, we allow users to rank diagnoses as a part of a differential diagnosis interaction. While we can represent the various diagnoses with the Diagnosis element, the data describing the ranking activity will need to be extended. For our export, we will likely provide an AlternativePath to a textual representation of this interaction.

Finally, we also have integrated our internal quiz tool. This enables case authors to present various question types to users for assessment. The quizzes are presented between case phases, and are presented as if they were a distinct phase. Quizzes are not currently integrated into "global navigation" cases. The types of questions we support currently are:

  • True/False
  • Multiple Choice
  • Short text answer
  • Multiple short text answers to one question
  • Essay answer
  • Matching

5. Screenshots

Here are a few sample screen shots of our system. Not comprehensive, but representative.

  plain text phase with TUSK content (image) included.

 history phase with some questions toggled to review answers

 physical exam

 differential diagnosis (rank likelihood)

note: the phase navigation is collapsed to better illustrate the contents of the left nav


  • No labels