Skip to end of metadata
Go to start of metadata

The table below summarizes the potential features of intra-competency relationships being considered by the group, as well as the proportion of reviewed outcome frameworks and survey respondents who wish to express the feature.

Relationship Element


% of organizations surveyed that use element (n=23)

% of reviewed frameworks that include element (n=11)

Proposed status for our specification

Other comments

Unique ID

A UID for the relationship itself



Required. alphanumeric.  one only.


The logical type of relationship

91 (hierarchical); 68 (non-hierarchical)

100 (hierarchical); 
9 (non-hierarchical)

Required. Controlled list.  One type only per relationship.

Consider using SKOS standard.  See table below for further discussion.


Data about the link itself (rather than about the competencies), e.g. strength of relationship




Have no concrete examples for this yet.


Groupings of competencies (under categories, roles, etc.)




This is better represented as a higher level in the hierarchy.

Competency Framework Metadata

Metadata fields to describe the framework itself (rather than the Competency Objects within it)



Include.  Specific elements not yet determined.

May include:

  • Framework title
  • Description
  • Version
  • Copyright
  • Authors
  • Publisher
  • etc.

Below is a running list of types of relationships that may exist between two competencies, as identified by the members of the working group.  This list will help the group to understand the nature of competency frameworks in use, and the kinds of relationships the MedBiq specification ought to facilitate.  Please note this list represents relationships between two competencies within the same framework only; we will later investigate the types of relationships that may exist between competencies and other data (eg. learning objects, curricula, etc.).

Please review the list as it exists and feel free to use the "Edit" tab of this page to add more items to the list!

All relationships are listed in the form "X has relationship to Y," which can be interpreted as "Competency X has relationship to Competency Y." 

Relationship Type


Logical Implications

Proposed status for our specification


X is a parent of Y

Standard logical hierarchical type of relationship.

Implies Y is a child of X (Y is a sub-competency of X; Y is a part of X).  Logically, also implies that attainment of Y contributes partially to the attainment of X.

Include.  Multiple children and/or parents allowed per competency.  Circular links prohibited (e.g. X is a parent of Y, which is parent of Z, which is a parent of X).

Do we need a way to quantify how much Y contributes to X?  Do we need to specify whether Y is necessary or sufficient for attainment of X?

X enables Y

Competency X must be attained before competency Y can be attained, because X enables Y, but there is not necessarily a hierarchical relationship.

Implies that someone who has attained Y has also attained X.


Represented by X being a child of Y.  Group could not think of an example where this was not sufficient.

X see also Y

Might be used to draw a user's attention to other competencies in the framework that are similar to X, but not logically related to X.

None.  Used only to inform the viewer of similar competencies that might be of interest.


For example, a competency related to IV insertion might be similar to a competency related to rehydration therapy.

X supports Y

Two distict competencies, where Y is performed better if X is also attained.



As suggested by Ronald Harden as a way to laterally relate the three circles of the Scottish Doctor.  On further discussion, it seemed too complicated (i.e. depends on the learner in question, context, etc.) to be hard-coded into the framework.

X and Y enable each other


Implies that someone who has attained X or Y has also attained the other.


As suggested by David Price.  Is this the same as X enables Y plus Y enables X?  Decision to exclude based on lack of example and complexity as per item above.

  • No labels