Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

MedBiquitous Virtual Patients (MVP)

An Architectural Model for MedBiquitous Virtual Patients

Draft White Paper
Version 6: September 11, 2006

Rachel Ellaway, Chris Candler, Peter Greene and Valerie Smothers - MedBiquitous Virtual Patient Working Group (with additional input from the MedBiquitous Technical Steering Group)

1: General Principles

MedBiquitous is developing a data standard for the exchange and reuse of virtual patients. This will be the MedBiquitous Virtual Patient (or MVP) standard. A working definition of a virtual patient is:
An interactive computer simulation of real-life clinical scenarios for the purpose of medical training, education, or assessment. Users may be learners, teachers, or examiners.

This document outlines a proposed structure and possible implementations of the MVP standard currently under development. The proposed structure allows for a wide variety of educational approaches and technologies. The appendix provides some exemplar use case scenarios, including the following:

  • Learners access virtual patient data and associated media resources in a self-directed fashion.
  • Learners participate in a problem-based learning activity which includes concomitant virtual patient data.
  • Learners access a longitudinal, activity-based virtual patient with integrated media resources and collaborative learning tools.
  • Learners participate in a multi-player game with integrated learning activities, virtual patient data, and media resources for each case.
2: Proposed MVP Architecture

There are many different ways that virtual patients can be created and employed. The MVP data standard must therefore be sufficiently abstract and adaptable so that it can accommodate a number of forms and uses.
The proposed architecture consists of five MVP components (see section 3), each of which can be accessed and assembled in a number of different ways (see section 4). These components are rendered for use through different kinds of players, depending on the activity at hand and other local choices and requirements. These five and other related (but out of scope) components such as user input and feedback, student profiles, and tracking are shown in figure 1.

  • No labels