Date: August 29, 2013
Author: Valerie Smothers
Author email: email@example.com
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
|0.3||29 Aug 2013||Valerie Smothers||Added information from eVip and edited sections on Conformance, Case Exchange, and Integrating Assessment Questions|
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.
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.
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)
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.
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
To be a conformant instance of MedBiquitous Virtual Patient, a content package:
NOTE: the definition above comes from the spec. I think we need to stick with that and delete the grayed out text from evip below. I don't want multiple definitions of conformance.
The eViP application profile of the MedBiquitous Virtual Patient standard defines four conformance levels:
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.
Conformant players must handle virtual patient data in the manner described in the document ANSI /MEDBIQ VP.10.1-2010 MedBiquitous Virtual Patient Player Specifications and Description Document.
You can use a stepwise approach to testing conformance of content packages. the following is adapted from documentation created by the eViP project for developing a shared repository of virtual patients.
Two test suites are available to assist with validating the content package (are these test suites up to date with v 1.0 of the spec, or will they accept things from previous versions?)
These tools go through several steps described below.
1 Package validation
Verify that the zip file contains the necessary files in the correct locations.
2 - XML/XSD Validation
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).
Examples of 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, including errors caused by wrong identifiers or missing references. For more detailed analysis of XML conformance, XML development tools like Altova XML Spy or <oXygen/> XML are recommended.
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 is displayed.
3 Import and Runtime validation
Tests on the import and runtime need to be verified in the context of the source and target virtual patient systems.
Potential problems may cause different encoding of special or national characters. In addition, systems may have different navigation models. When moving cases from a branching system to a non-branching system, the case editor will need to select the desired path through the content.
Before implementing the MedBiquitous Virtual Patient Standard, analyze the context in which it will be used and determine:
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.”
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.
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:
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:
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:
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.
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.
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.
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.
Describe the various VPD schemas and imported schemas. what schemas must be declared and where.
provide example XML showing those declarations and assigned prefixes.
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.
Add info about Alternative Path in DAM
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.
<?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"/>
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 following section is adapted from the eViP profile.
Virtual patient cases are used in both formative and summative assessments. A wide range of different question types is available in contemporary VP systems. In some cases information included in questions and their feedback might be vital for the case resolution. To demonstrate this, an exemplary case from the eViP inventory has been evaluated (evip:vp:1000132). Approximately 48% of the case's original text content has been lost after discarding questions. For that reason inclusion of assessment items into exported VP packages seems to be an important issue to cover. Representation of questions is at the present moment out of the scope of the core MVP specification.
The Question and Test Interoperability specification (QTI)    is the leading format for the exchange of assessment content and results produced by the IMS Global Learning Consortium. The specification defines the QTI information model and its XML data binding. Different question types can be encoded including multiple choice questions, sorting, filling gaps or hotspot. QTI is supported by many virtual learning environments including Moodle, Sakai or Ilias. The latest version available at the moment of writing was 2.1.
The first step is to add the appropriate schema definition file (in the case of QTI 2.1 it is imsqti_v2p1.xsd) to the exported package as it is shown (Fig. 15). (Get code example)
Next, the QTI's namespace is to be declared on top of the virtualpatientdata.xml: (Get code example)
Finally, the QTI conformant XML fragment needs to be inserted as child of the XtensibleInfo node.
Since the XtensibleInfo is by default ignored by MVP conformant VP systems, no negative consequences are to be expected in players that do not support QTI. The content of XtensibleInfo can be either discarded or a warning may be displayed about the fact that the content is not supported.
However, if QTI support is available in the target system, the question is detected and imported.
There are many other external specifications beyond QTI that could be potentially useful in virtual patient packages. A notable example is the W3C Timed Text format for encoding of multilingual subtitles in videos (covered in BPG 4). Some VP system builders may also wish to encode in the XtensibleInfo their systems' own distinctive features that are unlikely to be useful in other environments. As an example, part of patient description that is characteristic only for the CAMPUS system is presented in Fig. 19. A similar feature is also implemented in the Web-SP system.
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.