Skip to end of metadata
Go to start of metadata

In our initial assessment of the components of a competency framework for healthcare education, we've identified the following components of a competency framework.

  1. Competency Definition/Itemized Competencies
  2. Competency Structure (assembled competencies or relationships among competencies within a single structure)
  3. Competency Cross-walk (expresses relationships across different competency structures)
  4. Associations to content and other items

This structure is an initial draft presented for the consideration of the Competency Working Group. As discussion continues, this structure may change.

Existing Standards to Leverage

Several specifications and standards exist that could facilitate the development of this framework.

Healthcare Learning Object Metadata (Healthcare LOM) - An extension of the IEEE LOM standard customized for healthcare education. Healthcare LOM gives the ability to specify the educational objectives, competencies, or learning outcomes associated with a learning resource or activity. Healthcare LOM is being developed by MedBiquitous.

Associations - MedBiquitous and OHSU have developed a schema for associating content with competencies so that a single competency may be associated with many content items without altering the metadata for those items. This schema is in research and is not in development as a standard at this point.

Reusable Competency Definitions - IMS and the IEEE have developed specifications for reusable competency definitions that provide a structure for specifying the competency title, description, identifier, metadata, and other data.

Competencies - HR-XML has developed a schema for evidence used to substantiate competency as well as weighting and ranking of competencies to facilitate comparison and evaluation of competency.

Assessment Catalog - This HR-XML specification supports the discovery of tests within a catalog.

Overarching Data Requirements

Note: These requirements may be addressed by existing standards. They are itemized here for the purpose of determining what is in scope for the MedBiquitous Competency Working Group and which component of the architecture may or should address the data requirement. They are grouped based on the draft components but may be moved based on the input of the working group.

  1. Competency Definition/Itemized Competencies
    • Individual competency definition
  2. Competency Structure (assembled competencies)
    • How one competency relates to others in the same competency set
    • Needs to support hierarchies
    • Must express professional level (undergraduate, practicing, etc)
    • Other items for consideration (taken from Women's Health Competencies & Scottish Doctor):
      • Miller's Pyramid level (knows, knows how, shows how, does)
      • Recommended evaluation methods
      • References
      • Reference to other competency set (or best left for competency cross walk?)
  3. Competency Cross-walk
    • How one competency relates to others in different competency sets
    • How competency sets relate to one another

Versioning, status, and association with keywords in medical terminologies like MeSH will apply to each of these components.

Other data requirements that have been expressed may be more appropriate for a Curriculum model (see Opal presentation and University of Edinburgh Documentation on the Examples and Case Studies page).

  • Mode of assessment for a competency
  • Mode of instruction for a competency
  • Performance level that indicates competence (is this a requirement?)
  • What course(s) links to a particular competency
  • What competency (ies) links to a particular course
  • When a course is taught (semester, rotation, etc)

Currently the AAMC collects curricular information from US medical schools using CURRMIT on a voluntary basis. Software such as University of San Francisco's Ilios sends this data in an XML format.

A learner profile that indicates the extent of accomplishment and evidence of competence may be necessary as well. It's not clear if this information will be exchanged electronically, but use cases for such exchanges are easily envisioned.

  • No labels