MedBiquitous Competency Framework
Specifications and Description Document

 

 

 

 

Version: 0. 5 4 1

Date:   May 6 July 28 , 2010

Author: Valerie Smothers

Author email: valerie.smothers@medbiq.org

 

 

 

 

Version History

 

Version No.

Date

Changed By

Changes Made

0.1

17 Jul 2008

Valerie Smothers

Initial draft

0.2

6 October 2009

Valerie Smothers

Added lom to replace/supplement framework title and identifier, renamed CompetencyDefinitions CompetencyObjects, made category and references subelements fo CompetencyObject, added XtensibleInfo, added CompetencyMap subelements.

0.3

23 December 2009

Valerie Smothers

Removed Competency objects (will be a separate spec) and competency map; put relation at the root.

0.4

25 March 2010

Valerie Smothers

Required elements form lom and eliminated any overlap. Required URI identifier. Changes to non-hierarchical relationships. Changed structure of relations to be 1 to 1 rather than 1 to many.

0.41

6 May 2010

Valerie Smothers

Further simplified relations. Eliminated references.

0.5

28 July 2010

Valerie Smothers

Added SupportingInformation element.

 

 

 

 

 

 

 

 

 


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 help of  the MedBiquitous Competencies Working Group members, invited experts, and other individuals that contributed to the creation of this document, including:

 

  • Rosalyn Scott, M.D., Department of Veterans Affairs, Co-Chair
  • Tim Willet, M.D., CRI Critical Care Education Network, Co-Chair

 

  • Susan Albright, Tufts University
  • Mary Pat Aust, American Association of Critical-Care Nurses
  • Theresa Barrett , New Jersey Academy of Family Physicians
  • Chris Candler, M.D., Association of American Medical Colleges
  • Allan Cumming, M.D., University of Edinburgh
  • Tom Doyle, METI
  • Rachel Ellaway, Ph.D., Northern Ontario School of Medicine
  • Maria Esquela, Advanced Informatics
  • Vladmir Goodkovsky, University of Virginia
  • Simon Grant, Ph.D., Jisc Cetis
  • David Hadden, TheraSim
  • David Hananel, METI
  • Ted Hanss, University of Michigan
  • Ronald Harden, M.D., IVIMEDS
  • Sean Hilton, M.D., St. George’s University of London
  • Matt Lewis, Outcomes, Inc.
  • Michael Mintzer, M.D., Department of Veterans Affairs
  • David Price, M.D., American Board of Family Medicine
  • Carla Pugh, M.D, Northwestern University
  • Doris Quinn, Vanderbilt University
  • Isarin Sathitruangsak, Tufts University
  • Valerie Smothers, MedBiquitous
  • Lesley Southgate, M.D., St. George's University of London
  • David Stern, M.D., University of Michigan
  • Lana Vukovljak, American Association of Diabetes Educators
  • Jeff Williamson, American Medical Informatics Association
  • Nabil Zary, Karolinska Institute

 

 

Specification authors also received technical guidance from members of the MedBiquitous Technical Steering Committee.

 

  • Joel Farrell , IBM, Technical Steering Committee Chair
  • James Fiore, American Board of Surgery
  • Andrew Rabin, CECity
  • Dan Rehak, Learning Technologies Architect

 

 

This specification would not be possible without the previous work of Claude Ostyn, in particular the Proposal for a Simple Reusable Competency Map. Claude paved the way for this specification and others related to advanced uses of learning technologies. For access to Claude’s work, visit: http://www.ostyn.com/resources.htm

 

 


Introduction

 

This document describes MedBiquitous Competency Frameworks specification in detail. It is intended for use by anyone who wants to develop tools or implement electronic systems for linking competencies to educational and performance data and resources. The status of the document is indicated at the bottom of the page; draft documents are subject to review and approval through the MedBiquitous and ANSI standards development processes (see http://www.medbiq.org/working_groups/consortium_process/MedBiquitousANSIProcess.pdf ).

 

The use of outcome and competency frameworks is a growing part of healthcare education and maintenance of certification. Many nations or states have accreditation frameworks for health professions schools and programs as well as requirements to demonstrate lifelong learning and competency in medical specialties/subspecialties .  Currently, there is no standard way to represent these competencies in healthcare, and therefore no easy way to import/export competencies across systems. Once competencies are expressed in a common format, they can be used as the backbone of education and performance management systems, enabling the following:

 

  • Learners and educators able to search for learning resources addressing a particular competency
  • Educators able to determine where specific competencies are addressed in a curriculum
  • Boards and hospitals able to track and manage competency data for the professional.
  • Administrators are able to map one competency framework to another.

 

The objective of the specification is to provide a consistent format and data structure for defining a competency framework. This, combined with other existing and emerging specifications, enables educational resources and activities to be tied to a competency framework.

 

The standard allows extensions so that data beyond the core set identified in this document may be communicated to other organizations. This specification is intended to work in concert with other specifications.

 

 

 


Documentation Conventions

 

This document uses the following conventions.

 

Documentation Conventions

Convention

Description

monospaced type

 

Sample XML tags, code, schema, or portion thereof

BoldText

When used with an XML tag name, indicates that the element contains sub-elements

Italicized Text

When used in an XML tag description, an attribute of the XML tag.

Tag description

Shading indicated that the tag is further described elsewhere in the document

 

The following graphical standards are used for the XML diagrams in this document.

 

 

Graphical Standards from TIBCO’s Turbo XML, Copyright TIBCO Software Inc.

 


Terminology

Much of the terminology in this area is ill-defined or ambiguous, often employed differently (and sometimes interchangeably) by different professionals. [i]   To ensure clarity and consistency we provide working definitions of the terminology we use in the context of this paper:

 

  • Competence – possession of sufficient and necessary knowledge, skill and attitude by an individual to allow her to safely and effectively perform a specific job.
  • Competency – a statement describing a specific ability, or set of abilities, requiring specific knowledge, skill and/or attitude.  Competencies are used to set performance standards that must be met. [ii]
  • Competency Framework – an organized and structured representation of a set of interrelated and purposeful competency objects.
  • Competency Object – an umbrella term used by the CWG to describe any abstract statement of learning or performance expectations, and information related to the statement.  Statements can be learning outcomes, competencies per se, learning objectives, professional roles, topics, classifications/collections, etc.  The Competency Object may include additional data to expand on or support the statement.  The Object is abstract in the sense that it does not inherently contain information about connections of the statement to individuals or events or other objects.
  • Learning Objective – the intended aggregate learner endpoint for an activity, typically directly linked to the means by which it is to be achieved.  Learning objectives may be derived from competencies or learning outcomes.
  • Learning Outcome – the intended aggregate learner endpoint for a program, typically independent of the means by which the outcome is achieved.  Used to identify, define and communicate the skills and qualities graduates should have. [iii]
  • Learning Object – a digital resource used to support learning.
  • Performance – a demonstration of practice, such as patient care. Can be used as evidence of one or more competencies.

 

Data Elements

 

The Competency Framework schema includes the following elements. In some cases these elements have subelements.

 

  1. CompetencyFramework
  2. lom

 

The root element is CompetencyFramework.

 

Other Schema Referenced

 

The Competency Framework leverages the IEEE Standard for Learning Technology-Data Model for Reusable Competency Definitions, 1484.20.1-2007, available from http://standards.ieee.org/ .

 


Competency Framework Schema Grammar

 

The following sections explain the Competency Framework Schema grammar. Values in bold under XML Tags column indicate that the element has sub-elements.

 

All the elements having sub-elements will be defined in separate sections. All elements without sub-elements will be defined within the appropriate element sections that use them.

 

1         CompetencyFramework

CompetencyFramework is the root element. It contains subelements that describe a set of related competency definitions as well as the relationships among those competency definitions, if applicable. CompetencyFramework must occur once within a competency framework document.

 

 

 

CompetencyFramework Element Information

Element

Description

Required

Multiplicity

Datatype

CompetencyFramework

CompetencyFramework is the root element. It describes a set of related competency definitions and their relationships.

Required

1

Container

For more information, see  ANSI/MEDBIQ LO.10.1-2008 Healthcare Learning Object Metadata Specifications and Description Document

lom

lom is the subelement of CompetencyFramework. It contains subelements that define title, publisher, and other descriptive information about this competency framework.

The lom element is defined in the Healthcare Learning Object Metadata standard defined by MedBiquitous. Please see the Healthcare Learning Object Metadata Specifications and Description document for more information on the sub-elements of lom.

The following sub-elements of lom are required in a competency framework:

identifier

Defines a unique identifier for the competency framework. For competency frameworks, identifiers must be in the form of a URI.

title

Defines the title for this competency framework in one or more languages.

 

Required

1

Container

For more information, see  ANSI/MEDBIQ LO.10.1-2008 Healthcare Learning Object Metadata Specifications and Description Document and IEEE Standard for Learning Technology-Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata, 1484.12.3-2005, http://ieeexplore.ieee.org/
servlet/opac?
punumber=10263.

SupportingInformation

SupportingInformation is the subelement of CompetencyFramework. It contains subelements that include or link to supporting information, such as descriptions of the rationale for developing the framework and its intended use. See section SupportingInformation for more information.

Optional

0 or more

Container

Relation

Relations is the subelement of CompetencyFramework. . It contains subelements that define a relationship between two competencies in a framework. See section Relation for more information.

Required

1 or more

 

Container

 

Example:

 

<CompetencyFramework>

<lom:lom>

. . .

</lom:lom>

<SupportingInformation>

. . .

</SupportingInformation>

<Relation>

. . .

</Relation>

<Relation>

. . .

</Relation>

<Relation>

. . .

</Relation>

 

SupportingInformation

SupportingInformation includes or links to supporting information, such as descriptions of the rationale for developing the framework and its intended use.

 

 

Element

Description

Required

Multiplicity

Datatype

SupportingInformation

SupportingInformation is the subelement of CompetencyFramework. It contains subelements that include or link to supporting information, such as descriptions of the rationale for developing the framework and its intended use.

Optional

0 or more

Container

Link

Link is the subelement of SupportingInformation. It provides a URL or URI reference to a supporting resource, such as a pdf or html file describing the purpose of the framework in detail.

Link must contain a valid URI.

Either Link or xhtml:div is required

0 or 1

Restricted

xhtml:div

A div element is a mixed type element referenced from XHTML. The div element can include a mix of text and XHTML tags as specified by the XHTML schema.

For more information, see XHTML™ 1.0 The Extensible HyperText Markup Language” at: http://www.w3.org/TR/xhtml1/  

Either Link or xhtml:div is required

0 or 1

Container

 

2         Relation

Relation defines a relationship between two competencies in a framework.

 

 

Element

Description

Required

Multiplicity

Datatype

Relation

Relation is the subelement of Relations. It contains subelements that define a relationship between two competencies in a framework.

Required

1 or more

Container

CompetencyReference1

CompetencyReference1 is the subelement of Relation. It identifies a single competency with a relationship to the competency specified in CompetencyReference2.

Required

1

Container

Relationship

Relationship is a subelement of Relation. It defines the nature of the relationship between CompetencyReference1 and CompetencyReference2. Valid values are: broader than, narrower than, related to.

Broader than and narrower than are converse relationships. If Competency1 is broader than Competency2, Competency2 must be narrower than Competency1. The converse relationship does not need to be explicitly encoded; it should be understood based on the nature of the relationship between the two competency objects.

Related to may be used for any relationship that is non-hierarchical.

Required

1

Restricted

CompetencyReference2

CompetencyReference2 is the subelement of Relation. It identifies the competency that has a relationship to the competency specified in CompetencyReference1.

Required

1

Container

 

Example:

< Relation >

< CompetencyReference1 >

< Catalog > URI </ Catalog >

< Entry > http://www.example.org/competency123 </ Entry >

</ CompetencyReference1 >

< Relationship > broader than </ Relationship >

< CompetencyReference2 >

< Catalog > URI </ Catalog >

< Entry > http://www.example.org/competency234 </ Entry >

</ CompetencyReference2 >

</ Relation >

3         Common Data Types

3.1     IdentifierType

 

Many of the elements in Competency Framework use the IdentifierType datatype, which allows competency framework developers to indicate the catalog or source of the identifier along with the identifier. This two-part approach facilitates the exchange of competency frameworks across systems by preventing identifier duplication. Competency references may reference MedBiquitous Competency Objects or IEEE Reusable Competency Definitions.

 

 

 

 

Elements using the IdentifierType have Catalog and Entry subelements, which are described in the table that follows.

 


IdentiferType Subelements

Element

Description

Required

Multiplicity

Datatype

Catalog

Catalog indicates the identification or cataloguing scheme for the entry. URIs may be used in many cases and are required for MedBiquitous Competency Objects. In others, organizations may wish to use an internal cataloguing scheme.

Required

1

Non-null string

Entry

Entry is the value of the identifier within the cataloguing scheme specified by the Catalog element.

Required

1

Non-null string

 

 

The following example shows an identifier for a competency definition that uses a URI cataloging schema.

 

<Identifier>

<Catalog>URI</Catalog>

<Entry>http://www.medschool.edu/competencies/kp87t</Entry>

</Identifier>

 

The next example shows an identifier for a competency definition that uses a local cataloguing schema.

 

<Identifier>

<Catalog> Medschool University </Catalog>

<Entry>2005.10.87</Entry>

</Identifier>

 

 

 

 


Sample XML Document s

 

<?xml version="1.0" encoding="UTF-8"?>

< CompetencyFramework xmlns =" http://ns.medbiq.org/competencyframework/v1/ " xmlns:lom =" http://ltsc.ieee.org/xsd/LOM "   xmlns:xsi =" http://www.w3.org/2001/XMLSchema-instance " xsi:schemaLocation =" http://ns.medbiq.org/competencyframework/v1/.xsd ">

< lom:lom >

< lom:general >

< lom:identifier >

< lom:catalog > URI </ lom:catalog >

< lom:entry > http://www.example.org/framework1 </ lom:entry >

</ lom:identifier >

< lom:title >

< lom:string language =" en "> The Competent Physician </ lom:string >

</ lom:title >

</ lom:general >

< lom:lifeCycle >

< lom:contribute >

< lom:entity > Association of Worldwide Physicians </ lom:entity >

< lom:role >

< lom:source > LOMv1.0 </ lom:source >

< lom:value > publisher </ lom:value >

</ lom:role >

</ lom:contribute >

</ lom:lifeCycle >

</ lom:lom >

< Relation >

< CompetencyReference1 >

< Catalog > URI </ Catalog >

< Entry > http://www.example.org/competency123 </ Entry >

</ CompetencyReference1 >

< Relationship > broader than </ Relationship >

< CompetencyReference2 >

< Catalog > URI </ Catalog >

< Entry > http://www.example.org/competency234 </ Entry >

</ CompetencyReference2 >

</ Relation >

< Relation >

< CompetencyReference1 >

< Catalog > URI </ Catalog >

< Entry > http://www.example.org/competency234 </ Entry >

</ CompetencyReference1 >

< Relationship > broader than </ Relationship >

< CompetencyReference2 >

< Catalog > URI </ Catalog >

< Entry > http://www.example.org/competency345 </ Entry >

</ CompetencyReference2 >

</ Relation >

</ CompetencyFramework >

 


References

 

To be completed


[i] Harden RM.  Learning outcomes and instructional objectives: is there a difference?  Medical Teacher 2002; 24(2):151-5.

[ii] Albanese MA, Mejicano G, Mullan P, Kokotailo P and Gruppen L.  Defining characteristics of educational competencies.  Medical Education 2008; 42(3):248-55.

[iii] Harden RM, Crosby JR, Davis MH and Friedman M.  AMEE Guide No. 14: Outcome-based education: Part 5 – From competency to meta-competency: a model for the specification of learning outcomes.  Medical Teacher 1999; 21(6):546-52.