Date: December 7, 2012
Author: Valerie Smothers
Author email: firstname.lastname@example.org
If you would like to contribute to this document, please contact Valerie Smothers for login credentials.
13 Nov 2012
7 Dec 2012
Modified the outline
MedBiquitous XML (including schemas, specifications, sample documents, Web services description files, and related items) is provided by the copyright holders under the following license. By obtaining, using, and or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.
The Consortium hereby grants a perpetual, non-exclusive, non-transferable, license to copy, use, display, perform, modify, make derivative works of, and develop the MedBiquitous XML for any use and without any fee or royalty, provided that you include the following on ALL copies of the MedBiquitous XML or portions thereof, including modifications, that you make.
- Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the following notice should be used: “Copyright © [date of XML release] MedBiquitous Consortium. All Rights Reserved. http://www.medbiq.org”
- Notice of any changes or modification to the MedBiquitous XML files.
- Notice that any user is bound by the terms of this license and reference to the full text of this license in a location viewable to users of the redistributed or derivative work.
In the event that the licensee modifies any part of the MedBiquitous XML, it will not then represent to the public, through any act or omission, that the resulting modification is an official specification of the MedBiquitous Consortium unless and until such modification is officially adopted.
THE CONSORTIUM MAKES NO WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED, WITH RESPECT TO ANY COMPUTER CODE, INCLUDING SCHEMAS, SPECIFICATIONS, SAMPLE DOCUMENTS, WEB SERVICES DESCRIPTION FILES, AND RELATED ITEMS. WITHOUT LIMITING THE FOREGOING, THE CONSORTIUM DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY, EXPRESS OR IMPLIED, AGAINST INFRINGEMENT BY THE MEDBIQUITOUS XML OF ANY THIRD PARTY PATENTS, TRADEMARKS, COPYRIGHTS OR OTHER RIGHTS. THE LICENSEE AGREES THAT ALL COMPUTER CODES OR RELATED ITEMS PROVIDED SHALL BE ACCEPTED BY LICENSEE “AS IS”. THUS, THE ENTIRE RISK OF NON-PERFORMANCE OF THE MEDBIQUITOUS XML RESTS WITH THE LICENSEE WHO SHALL BEAR ALL COSTS OF ANY SERVICE, REPAIR OR CORRECTION.
IN NO EVENT SHALL THE CONSORTIUM OR ITS MEMBERS BE LIABLE TO THE LICENSEE OR ANY OTHER USER FOR DAMAGES OF ANY NATURE, INCLUDING, WITHOUT LIMITATION, ANY GENERAL, DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, OR SPECIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF ANY USE OF MEDBIQUITOUS XML.
LICENSEE SHALL INDEMNIFY THE CONSORTIUM AND EACH OF ITS MEMBERS FROM ANY LOSS, CLAIM, DAMAGE OR LIABILITY (INCLUDING, WITHOUT LIMITATION, PAYMENT OF ATTORNEYS’ FEES AND COURT COSTS) ARISING OUT OF MODIFICATION OR USE OF THE MEDBIQUITOUS XML OR ANY RELATED CONTENT OR MATERIAL BY LICENSEE.
LICENSEE SHALL NOT OBTAIN OR ATTEMPT TO OBTAIN ANY PATENTS, COPYRIGHTS OR OTHER PROPRIETARY RIGHTS WITH RESPECT TO THE MEDBIQUITOUS XML.
THIS LICENSE SHALL TERMINATE AUTOMATICALLY IF LICENSEE VIOLATES ANY OF ITS TERMS AND CONDITIONS.
The name and trademarks of the MedBiquitous Consortium and its members may NOT be used in advertising or publicity pertaining to MedBiquitous XML without specific, prior written permission. Title to copyright in MedBiquitous XML and any associated documentation will at all times remain with the copyright holders.
The MedBiquitous Consortium wishes to acknowledge the MedBiquitous Curriculum Inventory Working Group members, invited experts, and other individuals that contributed to the creation of this document.
- J.B. McGee, M.D., University of Pittsburgh
- Nabil Zary, Ph.D., Karolinska Institutet
- Susan Albright, Tufts University
- David Davies, Ph.D., University of Warwick
- Michael Hagen, M.D., American Board of Family Medicine
- Michael Steele, Duke University
- Jeff Taekman, M.D., Duke University
- Luke Woodham, St. George's University of London
- Rachel Ellaway, Ph.D., Northern Ontario School of Medicine
- Dan Rehak, Ph.D.
Overview - Valerie
The MedBiquitous Virtual Patient Standard provides a data structure that allows one to represent …. This structure then enables ….
This implementation guide provides general guidance for common implementations of the MedBiquitous Virtual Patient Standard version 1.0. Specific adaptations for your environment may be necessary.
A broad description of the purpose of the standard and who it is for (FAQ for all, rest more technical). Incorproate white paper form website?
Importance of MVP standard for sustainability (also covered in PPT but good to stress this)
FAQ - The group will send in ideas and answers
Why bother adopting the spec?
How to write to the spec – i.e. Where to find the core information and greater details
How much extra work is it typically to do this for most implementers?
Where to find case studies on what others have done
How do you include multiple choice questions in a conformat virtual patient?
The best way to include multiple choice questions in a virtual patient is to use the extension capability of the VirtualPatientData file to include multiple choice question data represented using the IMS QTI specification. Different authoring tools handle multiple choice questions in different ways. If you plan to exchange cases with another organization, be sure to agree on the mechanism for representing multiple choice questions.
- Central essential aspects of the spec which some software authors may find hard to include or address
The MVP Architecture
Explain Virtual Patient Data, Data Availability Model, Activity Model, and Media, along with how they interact with one another
concise but only semi-technical description (1 page max) of how the pieces fit together (the DAM etc) - this will be hard to do
Notes on conformance
- What are the downsides of close adherence to the MVP format?
- What do you lose if 100% conformant?
- Some caveats about what you typically lose in porting cases from one system to another
The eViP application profile defines four conformance levels (for detailed definitions and
more information on conformance testing, we refer to chapter 3 of deliverable D2.2):
Level 1 - Package validation
The first and lowest level of conformance implies that the archive structure and content is
conformant with the eViP profile specifications. This means that the correct directory
structure and file names are used and that all required files are present. On this level, the
content of the files is not checked.
Level 2 - XML/XSD validation
The second level of conformance requires that the XML files are well-formed and validated
against their schemas. This includes validation of XML-id references inside and between
XML files in the package, references to media resources, and XPath references in the MVP
Level 3 - Import validation
The bottom-line for the third level of conformance is that the author has a clear profit from
importing the package into the system. It implies that the target VP player or authoring system
extracts and imports the content in a relatively meaningful way.
Level 4 - Runtime validation
The fourth level is the most demanding level of conformance. It states that the imported,
packaged virtual patient must run in an eViP-compliant system and is ready for use.
The process of testing for conformance levels 1 and 2 can be totally automated by one of the
eViP conformance suites. The third and fourth conformance level can be tested in the target
system and needs to be done manually by a learning technologist or subject matter expert. The
protocol for eViP conformance testing is summarised by the block diagram in Fig 2.
eViP conformance testing - Example
The process of eViP application profile testing at consecutive conformance levels is
illustrated by a practical example. As a test case a virtual patient package (evip:vp:1000007)
from OpenLabyrinth was taken with the aim to be imported into the CASUS system. This
process could also be shown on other combinations of cases and partner systems. For
demonstration purposes some typical errors encountered while importing cases have been
artificially added to the package. Two eViP test suites have been used to verify the package
(one developed by KI and one by HD). Both tools may be executed either as web applications
or standalone modules. The tools are freely available and can be downloaded (including
sources) from the Internet:
3.1.1 Level 1 – Package validation
First, the zip package obtained from the source system is verified by the conformance suite
developed by KI.
On the first level, only the package structure is verified, not the content of files. All
mandatory files need to be placed in correct folders in the zip archive beforehand. The most
important XML files (e.g. virtualpatientdata.xml, activitymodel.xml or
dataavailabilitymodel.xml) need to be placed in the root directory of the package. It is also
required to insert all relevant XML Schema Definition files ensuring that they are of the
appropriate versions. For the eViP application profile at least MVP version 0.48 is required.
In the Fig. 4 the test suite points to some problems with missing XSD files.
After insertion of the missing files into the packages, the conformance testing may be
resumed at the next level.
3.1.2 Level 2 – XML/XSD validation
The major part of the second conformance level is to check the XML files for syntactical and
structural errors. The files need to be well-formed (i.e. conform to the XML syntax rules) and
valid (i.e. conform to semantic rules defined in the given XML schema files).
Since the MVP specification is still evolving, many of the errors that have been encountered
while implementing the profile stem from conformance to outdated schemas.
For instance, up until version 0.47 MVP required the presence of an ItemID element in
DAMNodeItem. Afterwards, the element changed to ItemPath. If the VP package contains an
outdated element, both eViP conformance suites will detect it and display an error message
(as shown in Fig. 5).
Examples of other errors encountered on this stage involve problems with XML Data Types
like date and time (e.g. different time notations) or numerical fields (e.g. using text comments
instead of digits). Further problems encountered included typographic errors in text constants
or XHTML tags disallowed by MVP being present in text VPDText elements .
The role of the conformance suite is merely to indicate errors. For more detailed analysis of
the XML and XSD on the second level content editors like Altova XML Spy  or
<oXygen/> XML  are recommended (Fig. 6).
In addition, eViP test suites detect errors caused by wrong identifiers or missing references.
The results of detecting errors on this stage are demonstrated on the example of the test suite
developed by HD.
It is recommended that identifiers in XML documents are unique and do not start with a digit
References, either full XPaths or just identifiers, need to point to existing XML elements or
assets outside the XML document. If this is not the case (either due to a typing error or a
missing file in the package) an error message (like the one in Fig. 8) is displayed.
Level 3 – Import validation
Tests on the third and fourth conformance level need to be verified in the context of the
source and target VP system (in our case adequately OpenLabyrinth and CASUS). Guided by
the checklist from the previous chapter we validate the imported package. Since we have
already verified and corrected the package on the 1st and 2nd conformance level the import is
accomplished without any errors or warnings. Nodes from OpenLabyrinth are imported as
CASUS cards. After opening a card its content becomes visible and is legible and well
positioned (Fig. 9).
Potential problems may cause different encoding of special or national characters like in the
A side-by-side comparison of the OpenLabyrinth and CASUS authoring tools shows that all
nodes available in the original have been imported into the target system (Fig. 11).
The layout of the cards in CASUS, even though not identical to the layout in OpenLabyrinth,
retains the meaning of the original content (Fig. 12). The import definitely saves time in
comparison to manual extraction of text content and images from the package and step-bystep insertion into the target authoring system.
Regardless of the usefulness of the imported package demonstrated on the previous level, it
cannot be claimed that the package is ready to use by students at this stage. Due to the
differences in the navigation model between the systems (OpenLabyrinth has a branched
model, CASUS a linear), the navigation elements (even though visible) are inactive (Fig. 13).
In addition, the order in which the cards are displayed in the player is not yet perfect. It is the
task of the content author to select the desired path through the case and delete all the
branches. Since there is no reasonable way of doing that automatically we cannot say that the
import of this OpenLabyrinth package into CASUS is eViP conformant on the fourth level.
We expect that this will be the case for most OpenLabyrinth packages: and conclude that
OpenLabyrinth is not compatible at level four for export to CASUS. However, it is clear that
the third level of conformance can be achieved.
Context Specific Requirements
Before implementing the MedBiquitous Virtual Patient Standard, analyze the context in which it will be used and determine:
- Your pedagogical goals for the system.
- Which features your virtual patient will support, and what data elements and attributes correspond to those features.
- If you plan to exchange Virtual Patient cases with other partners, are there specific features or elements that they require?
Use the rest of this document to help you make decisions about your system and implement the standard in ways that support your goals.
The MVP XML schemas may be modified to support context-specific requirements and restrictions. For more information, see “Adapting the Schema to Meet your Requirements.”
Implementing MVP Features
Types of structured data
Include demographics, medication lists, physical exam, diagnostic test results, interview question, differential diagnosis, interventions. Discuss benefits of using structured data and when that is useful.
Support for medical vocabularies
Vocabularies enhance the analysis that can be done on aggregate curriculum data by providing clearly delineated terms from which users can select the terms most appropriate to describe a given characteristic of the curriculum. When users choose non-vocabulary terms, it can be difficult to identify trends and determine commonalities and inconsistencies. Suppose Institution A classifies a course using the MeSH term Quality Improvement, and Institution B classifies a similar course using the non-MeSH term Performance Improvement. Anyone compiling data using the term Quality Improvement will have an incomplete dataset because data from Institution B’s course will be omitted.
MedBiquitous recommends using agreed-upon vocabularies for the following elements:
Integration of Media resources
Organizing Virtual Patient Data
Interactive interview questions
Support for differential diagnosis providing feedback on the likelihood fo the diagnosis and the diagnosis attributed by the case author
Learners may select interventions and receive feedback on the appropriateness and results of the intervention
Using the DAM to provide feedback
Data display options
The ability to show the learner data upon selection
The ability to show the learner data at a later point in the activity
The ability to show the learner data if they previously selected (ie ordered a test, prescribed a medication, etc).
Section based navigation
Creating a content path
Some features the MVP standard supports include:
Transferring Data in Languages other than English
Many implementers may wish to use the MVP Standard to exchange virtual patient activities in languages other than English. The standard is designed to support the exchange of activities in languages other than English.
The following elements have a required vocabulary in English:
The Virtual Patient Working group recommends specifying:
- Which languages may be used for data exchange
- What vocabularies will be used for the following elements with recommended vocabularies in English: ….
Organizations may decide to translate the recommended vocabularies referenced in the standard into other languages. See the section “Using Vocabularies” for more information on the specifics of using translated vocabularies.
Finding and Sharing
What metadata is important to include to maximize discoverability of cases when stored in repositories or just generally online
What metadata helps with portability of cases between systems
NOTE: This section is adapted from the eViP Best Practice Guidelines for the eViP application profile and associated conformance metrics.
Virtual patient systems have varied underlying models and distinct features.
Allow the user to override an automatic export if the content is not foreseen by the MVP specification.
For important content for some systems that are not supported by the MVP
specification because of the complexity (e.g. QTI assessment items ), it may be
helpful to let the user decide whether the questions will be exported in the
XtensibleInfo and potentially ignored by the target systems or imported directly as
VPDText for a non-interactive display that need to be manually converted in the target
system. Such an option is available in, for example, the CASUS system.
• For optimal compatibility, both the sender and receiver VP systems should use the
same version of the MVP specification. In the MVP 0.48 , the use of Media elements directly in VPD items like
DiagnosticTest was allowed but this notation was deprecated in the MVP versions
higher than 0.48.
Recommendations for branched systems
• A straightforward import of a branched into linear or semi-linear model is difficult.
All the solutions investigated by the consortium during the implementation process
have led to the loss of information or have required human intervention. However, as
was demonstrated by the partners, achieving the third compliance level is feasible.
• Consider pre-processing of the activity node
One method of importing branched content into a (semi-)linear model is to take all
ActivityNodes and transform them using XSLT to one card. This includes also all
media resources grouped by DAM nodes referenced from the ActivityNodes. Next it
is the task of the author to redesign the content into a (semi-)linear structure.
• Consider transforming the activity model into a directed acyclic graph
The other possibility for converting a branched model into a (semi-)linear one is to
transform the activity model into a directed acyclic graph (DAG). This model enables
o Request of the start node
o Request of the end node(s) (list)
o Request of all previous nodes of a node (list or null if start node)
o Request of all next nodes of a node (list or null if end node)
o If available in the original system weightings can be included in the graph
The algorithm starts by importing a start node. The list of potential next nodes is
displayed in each imported card. The author can then decide about the order of cards.
Unused nodes can be imported as additional comments to the model or as feedback in
questions provided that the QTI feature is implemented.
• Assign weights to the edge between nodes prior to exporting a branched VP
If possible, it is recommended for the branched system to include in the export
function the weights (credit) assigned to the edges between nodes of the activity
model. This feature gives the possibility for importing systems to use algorithms for
finding the critical pathway through the graph that could aid the import process.
However there is no guarantee that the optimal path will reflect the intentions of the
original case, because a great deal of potentially interesting information that lies
outside the optimum path may be omitted.
• Provide a graphical model of the VP
If possible, it is recommended for the branched system to export a graphical model of
the case to support the orientation while repurposing the case in the target system with
a different system model. Fig. 1 presents an exemplary map created with the VUE tool
 for a VP (case evip:vp:1000007) from the OpenLabyrinth system.
Recommendations for (semi-)linear systems
• For systems with a (semi-)linear structure and no specialisation of cards in the data
model it seems to be a more pragmatic solution to export all content as VPDText
nodes rather than manually assign the cards to particular classes of VPD data (like
Diagnosis, Physical Exam or Intervention). However, if there is a way to map the data
elements to a specialised tag this method is encouraged.
2.4 Recommendations for terminology-based systems
• In terminology-based systems (e.g. CAMPUS), it is impossible to import unstructured
text (like that from VPDText) into a highly structured database model. For those
systems, often the only possibility for an import is to store the data externally and
develop a new MVP/eViP player (as it was done in the case of CAMPUS) that is
integrated with the legacy system.
• While exporting data from terminology-based systems, their implementers may face
the problem of losing some parts of case related data due to the less structured Virtual
Patient Data model in the MVP specification. In those cases, either exporting the
content as VPDText or the use of the XtensibleInfo elements is recommended,
containing any data that is too specific for general use. For the second option it is
recommended to define a separate namespace and a corresponding schema file.
External systems may take advantage of this data if they implement this particular
kind of extension. The remaining tools will automatically ignore the XtensibleInfo
Communicating with would-be users
- remind implementers to specify in broad terms that a non-techie can grasp to some extent what is needed
- Hardware, operating system, additional modules, server side software
- What the end user needs on their system: browser only, Java app, etc
- Is the service run from a central service, the institution's own servers, a public or cloud based server, or a hybrid of these
XML Tips - Valerie
Schema Locations edit
In order to validate Curriculum Inventory XML documents, you may wish to store all of the associated schemas on a local server and reference those local copies for validation. To use local copies, the schema locations of the following schemas must be changed within the curriculuminventory.xsd schema document.
Change the schemaLocation attribute of the import element to change the location used for validation. The following example shows import statements that have been changed to use local versions of the schemas. In this example, the xsd files are all in the same directory as the curriculuminventory.xsd file. The schemaLocation attribute may use relative referencing, so the example schemaLocation references the file name since the file is in the same directory.
<xsd:import namespace="http://ns.medbiq.org/member/v1/" schemaLocation="member.xsd"/>
<xsd:import namespace="http://ns.medbiq.org/competencyobject/v1/" schemaLocation="competencyobject.xsd"/>
<xsd:import namespace="http://ns.medbiq.org/lom/extend/v1/" schemaLocation="healthcaremetadata.xsd"/>
<xsd:import namespace="http://ltsc.ieee.org/xsd/LOM" schemaLocation="healthcarelom.xsd"/>
<xsd:import namespace="http://ns.medbiq.org/competencyframework/v1/" schemaLocation="competencyframework.xsd"/>
<xsd:import namespace="http://ns.medbiq.org/lom/vocab/v1/" schemaLocation="healthcarevocabularies.xsd"/>
Curriculum Inventory instance documents may then reference the local copy of the curriculuminventory.xsd schema in the schemaLocation attribute of the root element as in the example below. In this example, the curriculuminventory.xsd schema is in the same directory as the instance document.
<CurriculumInventory xsi:schemaLocation="http://ns.medbiq.org/curriculuminventory/v1/ curriculuminventory.xsd" xmlns="http://ns.medbiq.org/curriculuminventory/v1/" xmlns:lom="http://ltsc.ieee.org/xsd/LOM" xmlns:a="http://ns.medbiq.org/address/v1/" xmlns:cf="http://ns.medbiq.org/competencyframework/v1/" xmlns:co="http://ns.medbiq.org/competencyobject/v1/" xmlns:hx="http://ns.medbiq.org/lom/extend/v1/" xmlns:m="http://ns.medbiq.org/member/v1/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Please note that changing the location of the schemas used for validation does not affect the conformance status of Professional Profile instance document.
Declaring Imported Schema edit
Describe the various VPD schemas and imported schemas. what schemas must be declared and where.
provide example XML showing those declarations and assigned prefixes.
Adapting the Schema to Meet Your Requirements edit
Organizations implementing the MedBiquitous Virtual Patient may wish to further restrict the scope of data considered valid or add new data not addressed in the standard. The schemas are designed to support either of these scenarios.
Extending the MVP EDIT
Add info about Alternative Path in DAM
- How to sustainably extend the spec
EDIT The Curriculum Inventory schema allows for elements from other namespaces to be included under the root element. Use the steps that follow to extend the Curriculum Inventory schema to incorporate new data.
- Write a new XML schema for new data elements and declare a targetNamespace.
Develop a new XSD schema that defines the data elements that are missing from the Curriculum Inventory. All new elements must be associated with a namespace. This can be achieved by using the XSD targetNamespace attribute. The following example defines an element called CurriculumDean that can be used to identify the Dean in charge of curriculum. The schema defines http://ns.myurl.com/curriculumdean/ as the targetNamespace, so the CurriculumDean element is associated with that namespace.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://ns.myurl.com/curriculumdean/" xmlns="http://ns.myurl.com/curriculumdean/" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="CurriculumDean" type="xs:string"/>
- Place new namespace qualified elements below the root at the end of the XML instance document.
Declare the namespace of the schema with new data elements in the instance document. Usually this is done by declaring the namespace in the root element and assigning a prefix to the namespace. Then the prefix can be used when referencing the new elements. You may also declare a default namespace for an element and its subelements by declaring the namespace in the uppermost element belonging to that namespace. Then include the new element(s) just before the closing CurriculumInventory tag.
In the example below, the prefix cd is declared for the http://ns.myurl.com/curriculumdean/ namespace within the CurriculumInventory root element. The cd prefix is then used to label the CurriculumDean element before the closing CurriculumInventory tag.
The specification correctly makes no assumption about the underlying storage mechanism. However all the systems I know of seem to use SQL Databases. Translating the data from the specified xml structures into a working relational structure and back again is something of a challenge. The advent of NoSQL databases doesn’t really help this, because traversal between the structures is complex. The original assumption seems to have been that implementers would work directly from the xml files, but traversal is still complex.
ANSI/MEDBIQ LO.10.1-2008, Healthcare Learning Object Metadata (Healthcare LOM). MedBiquitous Website. http://www.medbiq.org/std_specs/standards/index.html#HCLOM. Accessed June 1, 2011.
To ensure clarity and consistency, we provide working definitions of the terminology we use in these guidelines.