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 8 Next »

Version: 0.2
Date: December 7, 2012
Author: Valerie Smothers
Author email: vsmothers@jhmi.edu

If you would like to contribute to this document, please contact Valerie Smothers for login credentials.

Version History

 

Version No.

Date

Changed By

Changes Made

0.1

13 Nov 2012

Valerie Smothers

Initial outline

 0.2

7 Dec 2012 

Valerie Smothers 

Modified the outline 

 


MedBiquitous Consortium XML Public License and Terms of Use

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.

  1. 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”
  2. Notice of any changes or modification to the MedBiquitous XML files.
  3. 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.

 

 

Acknowledgements

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.

Co-chairs

  • J.B. McGee, M.D., University of Pittsburgh
  • Nabil Zary, Ph.D., Karolinska Institutet

Members

  • 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

Invited Experts

  • Rachel Ellaway, Ph.D., Northern Ontario School of Medicine
  • Dan Rehak, Ph.D.

Overview - Valerie

Background...

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)

 

 

For Educators

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?

 

For Programmers

General Guidelines

    • 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

  1. 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

 

Context Specific Requirements

Before implementing the MedBiquitous Virtual Patient Standard, analyze the context in which it will be used and determine:

  1. Your pedagogical goals for the system.
  2. Which features your virtual patient will support, and what data elements and attributes correspond to those features.
  3. 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

Data 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:

Formatted text

Integration of Media resources

Organizing Virtual Patient Data

 

Feedback

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).

 

Navigation

Section based navigation

Global navigation

Creating a content path

Branching logic

Probabilistic navigation

Rule-based navigation

Using Timers

 

Scoring Learners

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

Metadata

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

Case Exchange

 

Communicating with would-be users

  1. 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.

  • competencyframework.xsd
  • competencyobject.xsd
  • healthcarelom.xsd
  • healthcaremetadata.xsd
  • healthcarevocabularies.xsd
  • member.xsd

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

  1. 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.

  1. 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"/>

</xs:schema>

 

  1. 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.

 

Example

 

Persistance

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.

 

References

Healthcare LOM
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.

 

 

 

Glossary

To ensure clarity and consistency, we provide working definitions of the terminology we use in these guidelines.

 

  • No labels