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

« Previous Version 3 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.


Figure 1: components of the MVP architecture

3: MVP Components

There are five core MVP components:

1. Virtual Patient Data (VPD)

The VPD provides the personal and clinical data that is relevant to the clinical scenario being simulated. The VPD is a bit like a clinical chart, being divided into sections that correspond to the medical history, physical examination, laboratory and radiology data, and procedure and outcome data.

An XML model is being developed for this component that enables a flexible approach to the data. Data within each section is tagged with identifiers so that patient data can be disclosed progressively. The data can be disclosed to the learner en bloc, or the data can be structured so that it can be disclosed iteratively in response to specific learner requests, with the XML allowing the encoding of both the request and the response information as is logical for each section:

  • Medical History: questions and answers
  • Physical Examination: examinations and finding
  • Laboratory tests: tests and results
  • Radiographic tests: tests and results
  • Procedures: procedures and outcomes

Each of the sections may include subsections that further refine the information available. The Medical History section, for example, may include subsections for present illness, past history, family and social history, etc.

Most of the VPD data is provided in unstructured text, but certain sections may be highly structured and encoded with healthcare terminologies (RxNorm for medications and SNOMED for allergies, problems, and procedures). If this encoding is present, it could enable the learner to interact with clinical decision support systems during the virtual patient learning activity.

2. Media Resources (MR)

Media resources are all of the images, animations, videos, and audio files that are associated with the virtual patient at any point during the simulated patient scenario. As with the specific portions of the VPD data, the media resources are tagged with identifiers so that they the can be made available at the right time to the learner. IMS Content Packaging will be used to catalogue media resources and provide unique identifiers.

3. Data Availability Model (DAM)

This component enables the sequencing and progressive disclosure of data encoded in the VPD and associated media resources. The Data Availability Model references the identifiers within the VPD and sites specific media resources to allow for the targeted or progressive release of parts of the VPD or individual media resources.

Note that the state model defines whether the consuming player application is cumulative (items from lower state values remain available) or selective (only items within the current state are available). The state model also allows for the encoding of non-linear or branching activities, with user decisions (or indecisions) determining when and which state is reached next.

The Data Availability Model exists separately from the VPD and media resources components because it is quite possible that the same underlying clinical scenario could be used by very different player applications, each of which has a Data Availability Model that encodes the appropriate level of complexity.

4. Activity Model (AM)

This component encodes how the learner will be able to engage with the virtual patient. A number of different learner activities are possible with the same underlying virtual patient dataset, and the activity model component encodes the activities available, often including the narrative context. Examples of activity models are:

  1. Observation: The learner is presented with a 'page turner' and is allowed to observe how a clinical scenario unfolds. (This might be appropriate for beginner students that are not ready to make interventional decisions).
  2. Free Navigation: The learner is presented with clinical materials which are linking to a variety of references (journal articles, books, data sets, decision support systems, etc) that they are free to navigate in an unrestricted fashion.
  3. Diagnosis Formulation: The leaner is asked to formulate a differential diagnosis at each stage of the progressive disclosure of the clinical scenario.
  4. Decision Making: The leaner is asked to make clinical decisions based on current information and acquires new information as a result of different decisions.

For each of these activity models, the corresponding Data Availability Model must be designed in concert to support the activity, and these two components will typically work closely together. For example, the observation activity would work with a Data Availability Model that was cumulative and linear, whereas the decision making activity would require a Data Availability Model that is selective and branching.

Different players (see below) will need to interface with the VPD, Data Availability Model, and media resources components, but not necessarily all of them. It is a fundamental requirement of the MVP standard that VPD and activity model components are able to function independently of each other. Thus a paper case could be derived directly from a VPD and an activity based on clinical decision pathways could be designed without direct dependence on a particular VPD data set.

  • No labels