Modeling Virtual Patients and Virtual Cases

Rachel Ellaway
e-Learning Manager, Learning Technology Section
College of Medicine and Veterinary Medicine
The University of Edinburgh
Edinburgh, Scotland, UK

Last Updated: 23 November 2004

What’s the Problem?

There are at present many initiatives developing virtual patient and case materials for many different purposes and applications. However there is no common reference framework against which these developments are being made. Not only is this leading to fragmentation, with many wheels being reinvented over and again, but it also means that there is no interoperability, scalability or any other dimension of transparency between these developments. In other words virtual cases or patients developed for one application cannot be transferred to any other without substantive transformation and reworking.

This is not a new state of affairs. In almost every area of information science, particularly those that use models and frameworks expressed in computing technologies, issues of interoperability and standardization have become common currency. It is high time that common specifications for virtual patients and cases were developed and shared across the range of applications that use them. An open and inclusive process for developing such specifications is now a major priority for educationalists, informatics specialists and researchers across all healthcare disciplines. This paper is presented as a call for the community to engage in these developments and it presents some of the ways they might be approached and developed.

Virtual Patients, Virtual Cases

Virtual patients (VPs) have been used for many years. Paper-based cases and patients have been used for many years and certainly since the explosive growth of the web in the ‘90s the use of virtual patients has spread into many areas of healthcare delivery and education. Performing a web search on ‘virtual patients’ will find three distinct forms of VP applications:

Research: these are computer simulations of the effect of drugs in humans. In these scenarios the VP is reduced to a complex series of algorithms that model the pharmacological behaviour of new drugs without the risks of using real human test subjects and with the benefits of many simultaneous virtual drugs trials.
Electronic Patient Records (EPRs): this use of VPs is in respect of standard patient records and patient data stored and managed electronically. The concept of virtuality in this form of VP is the reflection of the real patient in their electronic records.
Education: these are where a patient case or presentation is used for educational purposes allowing students to work with real world problems and scenarios. VPs for education are often hypothecated and designed to address particular topics or educational objectives and they are the key component of the problem-based learning (PBL) approaches exemplified by Universities such as McMaster or Maastricht. Although the other two forms of VP applications will be considered, it is the educational use of virtual patients and cases that I will concentrate on in this paper.

A virtual patient therefore is a set of data that describes an individual as a patient (i.e., the subject of some kind of healthcare activity). This may be data about a real patient, a hypothecated patient or some combination of the two. The concept of virtuality is based on the patient being modeled in data rather than as an embodied entity. The concept of ‘virtual case’ is often interchangeable with that of virtual patient in healthcare although a case is in fact a slightly broader concept. A case may involve several individuals and outside medicine it has a number of domain-specific meanings, for instance in law, engineering and sociology. One particular aspect therefore about cases is that they include the context of a scenario as well as its subject.

Educational Approaches to Using Virtual Patients and Cases

There are many different ways that a virtual patient may be used in an educational setting. For instance:

The role of the learner may take many forms with respect to the patient: the student may take the role of the physician, the patient (or their family or friends), a third-party observer, a tutor, another participant in the healthcare process (nurse, dietician, surgeon, manager etc) or any other active or passive role in the scenario.
The learner may be acting independently, or under the guidance of a tutor or instructor, or in a collaborative setting with their peers. If there is any amount of longitudinal activity then different combinations of all three may be involved.
The virtual patient/case learning process may be set up to take many different and distinctive forms:
- The learner may progress through a predetermined scenario where each step is predetermined and interaction prescribed (directed mode).
- The learner may start from scratch with a first patient presentation clerking their patient and building up the patient or case data from observations and interactions with the scenario or patient (blank mode).
- The learner may view and appraise or review an existing patient or scenario. For instance this may be as an example of good (or bad) patient management in a case conference (critique mode) or as a means to rehearse skills such as diagnosis or prescription (rehearsal mode).
- The learner may use a case or patient as a mechanism to address particular topics. For instance the patient may be a means to present scientific topics, particular clinical skills or management issues. In this situation the case or patient is the secondary medium rather than the primary substance of the activity (context mode).
- The learner may use a scenario or patient to explore personal/professional aspects of the patient-doctor relationship. In this situation the case is intended to promote and guide reflective thinking regarding issues such as conduct, communication and ethics (reflective mode).
- Banks of patients or scenarios may collectively address broad issues of healthcare such as patient management, clinical governance or public health (pattern mode).
The virtual patient/case learning process may be naturalistic or formalized. For instance a case activity that was set up to deal with issues of communication would be concerned with the naturalistic nuances of a consultation whereas one that was set up to address issues of diagnostic pathways would consider the formal evidence and decision aspects of the same consultation.
Pedagogical modalities may include explorative or didactic approaches and they may or may not include aspects of problem-based learning (for instance see Generic Problem-based Learning Essentials from Southern Illinois University).

Whatever specifications are drawn up they will need to attempt to cover as many of these dimensions as is both practicable and possible or they should provide a profile for a more generalized case or patient scenario centered approach to teaching and learning.

Architectural Principles

Given that a virtual case/patient specification will need to cover many if not all of the dimensions outlined in the previous section, there are a number of architectural considerations that need to be outlined:

The patient/case data needs to be separate from the applications through which they are rendered and manipulated. One data framework should be able to be connected to many different applications – each related to the activity modes outlined in the previous section: directed, blank, critique, rehearsal, context, reflective, pattern (see Figure 1).
Architectural elements need to be adaptable and interchangeable independent of any other element.
There is a major difference between modeling a case or a patient as a static 'blob' of data and modeling it as a dynamic time-based activity. The latter implies concepts of 'state' of the scenario, i.e. what the items of data there are that are available at the outset and what the student has added or changed at any particular point. Management of the state of a case activity is therefore also important component of any specification.
Wherever possible the data model for patient/case information should be shared with other applications, in particular the many (and as yet divergent) frameworks being developed for electronic patient records by hospitals, professional bodies and occasionally even national bodies.
Any specification should, as far as is practicable, relate to existing specifications for medical data and for learning activities and pedagogy.

A number of individuals and groups are already working towards just such specifications – the next section will outline just such a specification, one that is based on just the principles outlined so far in this paper.

Figure 1. Abstracted Case/Patient Framework

CaseML

Case Markup Language (or CaseML) is an open exploratory project to discuss and develop a common architecture for virtual patients and cases. It is intended to provide a means to develop a reference data model for patient and case scenarios expressible in XML, a database or in an API that can encompass the different modes of use and the types of applications that cases and patients may be put to.

CaseML is conceptually built around an existing activity description framework, that of IMS Learning Design (which was in turn adapted from ‘Educational Modeling Language’ developed by the Open University of the Netherlands). The main elements of IMS Learning Design are essentially the same for CaseML, as shown in Figure 2.

Figure 2. CaseML Root Elements

Objectives: are the intended outcomes of the case
Prerequisites: are the starting conditions required to start the case
Triggers: are the events or conditions that start and stop the activity
Actors: the individuals involved in the case (‘roles’ in IMSLD)
Primary activities: the activities directly part of the case activity (such as clerking, consulting, diagnosing or prescribing)
Support activities: the activities that support the case activity (such as searching for primary evidence, using note taking facilities etc.)
Environment/scenario: the context in which the case is conducted
Services: the tools required to conduct the case

It is the ‘actor’ branch where the patient case information sits – the rest of the branches are essentially intended to be IMSLD elements and controls; see IMSLD or the UNFOLD Project in the links and resources section of this paper. The main ‘actor’ root elements are shown in Figure 3:

Main CaseML Actor Root Elements

Figure 3: Main CaseML Actor Root Elements

Metadata: the base information about an individual that is not particularly medical in nature
Personal: the personal, social, family and economic descriptors of the individual
Records: the specifically medical data about the individual
Statements: contributions from the individual such as answers to questions or general comments or statements they make.

CaseML Data

CaseML should be renderable as XML and in this format it should be able to be transferred between applications. To that end a CaseML data model is required as is an XML binding. Although CaseML is conceptually based on IMS Learning Design (IMSLD), its current implementation is sufficiently different from the needs of CaseML that a separate specification is more workable than fitting all of CaseML to IMSLD. This is particularly the case with respect to modeling and managing roles. In IMSLD, roles are limited to learner and staff. In CaseML these need to be augmented by the other roles in the scenario even if they are hypothecated or in any other sense ‘virtual’. In CaseML these have been renamed ‘actors’ both to fit in with the ‘act’ metaphor of IMSLD and to be include the patient and other case roles.

The role metadata, which would need to be both extensible and keyed to external patient data frameworks, could look something like the following XML code snip:

CaseML Role Metadata

Other CaseML-specific aspects would include the descriptors for the scenario/context and for describing the modality of the case or patient activity.

Controlled vocabularies such as MeSH or SNOMED and other medical reference projects such as HL7, HEAL and MedBiquitous should all be referenced as sources for the classification structures for CaseML.

In some respects, CaseML could act as a self-contained set of extensions to IMSLD or any other activity specification (for instance another candidate runtime specification could be ADL SCORM).

CaseML Applications

Any CaseML application would be able to parse a CaseML file and dynamically populate itself with the actor, activity and scenario information it contained at run time (for more on this approach see Ellaway et al, 2004). It is at this application level that the specificity of pedagogical activity would be expected to differentiate. Some proposed CaseML applications include:

CaseML Viewer: allowing users to view the various aspects of a patient or case this could take the form of patient notes, or hospital records and be used in support of activities that are not directly connected to the case information and therefore any interaction with the case data is relatively passive. For instance the Viewer could be used as part of a face to face PBL session or simulated case conference. Rendering options could also include mobile devices allowing collaborative and situated learning activities in a variety of contexts.
CaseML Recorder: similar to the viewer but allowing data to be input and maintained in a state-sensitive fashion relative to the case and the learner’s profile. The Recorder could be used as part of a simulation, as part of a consultation skills session or as part of medical informatics teaching. The Recorder relates activities much more directly to the case data than the Viewer but is more complicated because it needs to be able to write as well as read data and it needs to be able to track and maintain state.
CaseML Learning Environment: this is the most extensive form of proposed CaseML tool, and it is where case and patient focused activity provides the primary heuristic of the whole learning environment. In the CaseML learning environment all other applications and tools play a support and scaffolding role to the primary activities based on the negotiation of and engagement with cases and patients in support of learning. Examples could include the a completely case and patient focused curriculum that is run online or it could include a simulated hospital in the form of a game environment where different ‘players’ took on roles and worked through problems and scenarios together.

Any real-world CaseML application might combine some or all of these aspects and potentially many others as well. Whatever CaseML applications are built or used, their abstraction from the CaseML data level is a key aspect of managing scalable, extensible and interoperable case- and patient-based learning activities.

Conclusions

CaseML is presented here as work in progress in the hope that it will help to clarify the idea of virtual patient and case interoperability for some, while stimulating others to engage with the processes of developing and adopting common specifications for describing patient and case data. The principles of abstraction, of integrating educational applications with those from medical informatics and research, and of encompassing the wide range of heuristics and pedagogical approaches are essential, independent of whatever specification finally emerges.

CaseML is in its early stages of development. It will need significantly more work and input and engagement from across the healthcare education community before it can be used in anger. Indeed it is possible that its sole use will be in advancing thinking and development activity around the use of interoperable patient and case information in healthcare education. Whatever the future holds for CaseML, the need for common interoperable specifications for patient and case information is undeniable. However in the absence of the community defining its needs it is more than likely that less than ideal commercial or partisan approaches will be adopted and tend to dominate in the healthcare sector. The time to engage in a substantial and collective effort is now.

Links and Resources

Ellaway, R., D. Dewhurst, et al. (2004). Challenging the Mortality of Computer Assisted Learning Materials in the Life Sciences: The RECAL Project. Bioscience Education E-journal
http://bio.ltsn.ac.uk/journal/vol3/beej-3-7.htm
[Last accessed 23 November 2004].

What Makes a Good Case? From the National Center for Case Study Teaching in Science, University at Buffalo, State University of New York
http://ublib.buffalo.edu/libraries/projects/cases/teaching/good-case.html
[Last accessed 23 November 2004].

Aha, D. W. (1991). Case-based learning algorithms. In Proceedings of the DARPA Case-Based Reasoning Workshop (pp. 147--158). Washington, D.C.: Morgan Kaufmann
http://citeseer.ist.psu.edu/aha91casebased.html
[Last accessed 23 November 2004].

IMS Global: http://www.imsproject.org/
IMS Learning Design: http://www.imsglobal.org/learningdesign/index.cfm
The Open University of the Netherlands (OUNL): http://www.ou.nl
The Open University of the Netherlands Learning Networks Educational Modeling Language: http://learningnetworks.org/eml-ou-nl.htm
HL7: http://www.hl7.org/
HEAL: http://www.healcentral.org/index.jsp
MedBiquitous: http://www.medbiq.org/
UNFOLD: http://www.unfold-project.net:8085/UNFOLD
XML: http://www.org/XML/
ADLNet (Advanced Distributed Learning Network) SCORM: http://www.adlnet.org

This work remains the copyright of the author and The University of Edinburgh and the author reserves the right to be identified as the author of this work.