The following conceptual model is based on discussions of the working group to date and serves as the basis for development of a technical specification.  The model is further detailed in the white paper being authored by the working group.  The text below represents a summary of the important points in the model.


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:

Abstract models

One of the most common models for representing conceptual frameworks is the acyclic graph consisting of interlinked nodes where both nodes and links have properties. Examples of their use include thesauri, ontologies, organizational structures, concept maps and Linnaean-style classifications.
Nodal frameworks have two essential aspects:

From an informatics perspective this is a basic proof that (a) one acyclic graph model can accommodate a wide range of applications and (b) metadata is key for rendering an inclusive common model.

There are also clear similarities and links between competency/outcome frameworks and other, as yet unidentified models, such as learning objectives for a curriculum, hierarchies of topics, the curriculum structure itself, and professional practice. Some examples might be:
(1) A profession has a number of defining aspects; these are used to define professional scope for the accreditation and licensing bodies. These bodies issue frameworks to guide evaluation for accreditation.
(2) To remain compliant, educators derive their curricular learning outcomes from the professional competencies then design the operational curriculum (learning activities and associated objectives) to support their learners in achieving the outcomes.
(3) Teachers and learners engage the curriculum through a series of curricular activities, including assessment of the learners' achievement of the required outcomes. The learners traverse a path from novice to expert by achieving learning outcomes and obtaining competences.
(4) In doing so they enter the profession and begin to revalidate and redefine the factors essential to the profession. They reflect, engage in continuing professional development and recertify based on the expressed standards of the profession, but also contribute to redefining those standards (competencies) as the profession evolves.


For the purpose of approaching development of a Competency Environment, the CWG has identified three separate, but related, concepts (Figure 1):

  1. The Competency Object - also referred to as a competency definition, a competency object is a single statement and information to detail, clarify or support the statement.  It exists in isolation as an abstract object.
  2. Inter-Competency Relationships - links between competency objects that allow the formation of a competency framework.  The framework itself may contains additional data, such as an introduction, justification, categories, etc.
  3. Extra-Competency Relationships - links between a competency object (that is part of a competency framework) and objects external to the framework, such as curricular elements, learning objects, portfolio entries, performance events, competencies from other frameworks, etc.

Concerning objects to which competencies may be linked, there exist some formal specifications (e.g. learning objects) but for many there are no widely-accepted specifications (e.g. portfolio, curriculum).  Rather than propose a specification for each of these objects, we propose specifying a way to which any object can refer to one or more competencies from one or more frameworks.

There are a number of coincident standards and specifications and representational themes with these frameworks:


The CWG has reviewed a number of well-established published competency and outcome frameworks in health care, including:

Discussions have also taken place regarding the local frameworks being developed and implemented by working group members. Additionally, our survey inquired as to what types of information (information about the competencies themselves and the competency framework) ought to be captured.

Compency Object elements

A working page is available on this wiki that lists candidate elements for inclusion in the specification, and information about which pubshished frameworks currently make use of such an element.

Inter-competency relationships

Individual competencies, individually defined but unrelated, are of little use. Typically, multiple competencies are organized in a hierarchical manner (displayed on paper as nested lists). However, other types of relationships among competencies within a framework might exist. Again, the survey addressed this and published frameworks were reviewed; a list of candidate types and metadata about competency frameworks is available on a separate working page. A graphical representation of a competency framework according to this model is provided in Figure 2.

Extra-competency relationships

A competency framework, expressed abstractly and published independent of persons or educational content, must then be linked to other data in order to be operationalized. For example, CWG members have expressed the need to link competency frameworks to:

There are three ways competency data could be linked to other external objects: the linking statement could occur in the competency framework document, in the metadata of the external objects, or in a separate "mapping" document. Each option has advantages and disadvantages. Given the use cases envisioned by the CWG, it seems the former option is too restrictive, but either of the other options may be feasible. The latter option provides the best solution (see Figure 3). Advantages include:

Based on our model as shown in Figure 3, data in the Competency Object, competency framework and mapping documents fall within the scope of the MedBiquitous specification. However, to enable users who wish to reference competencies directly in the metadata of external objects (e.g. within Learning Object Metadata ), we will also provide a standard for such references.