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:
- Program - a discrete phase of educational activity, for instance MD, BSc or professional certificate.
- Course - a discrete component of a program; not all programs will have courses (e.g. European PhDs).
- Educational Activity - a discrete temporal component of a program or course, typically an event but also including self-study and project work.
- Syllabus/Curriculum - the content and organization of a program describing the subjects/topics/disciplines covered and to what depth. It may also include the order in which content is covered or educational methods used. The curriculum may be organized into courses/modules/units etc.
- Scheduling - the allocation of time within a program to cover the curriculum. It may include session title, date and time, location, instructors, learning materials, etc.
- 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.
- 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.
- 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.
- 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 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.
- Competency Framework - an organized and structured representation of a set of interrelated and purposeful competency objects.
- Professional Activity - a task performed as part of a professional's work (in our instance, patient care) or continuing development. Can be used as evidence of attainment of one or more competencies, or could specify certain competencies required by a professional to perform it.
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:
- What's in the node - this is the representation of the base unit that makes up a framework. A node may have many properties including:
- Content, such as title, type, description, details, or other kinds of discrete objects such as other XML constructs. Content is not mandatory for a node as some nodes may exist purely to denote structure, such as in the early branches of a tree.
- Metadata, such as author, date, etc. This is information about the node, distinguished from the content of the node itself. As before metadata is not mandatory.
- How are the nodes connected - this is the representation of the links between nodes. Each link can have a number of properties including:
- Topological coordinates, typically expressed as two node IDs: the 'to' and 'from' nodes for a link. Note that in acyclic graphs a link from node A to node B is a separate entry from the link from B to A. This is a mandatory, even definitive, property of a link.
- Metadata - information about the relationship itself, e.g., type (child, parent), functionality, presentation properties, etc.
Different types of frameworks - such as competency, or outcome frameworks - can be represented using an acyclical graph model; the differences are in the content and intent of the frameworks (i.e. nodes and links), not the structure of data contained within the frameworks.
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):
- 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.
- 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.
- 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:
- Curriculum audit - CurrMIT
- Reusable definitions of competency (RDCs)
- Activity models including IMS Learning design, SCORM and MedBiquitous' Virtual Patient
- MedBiquitous Healthcare Learning Object Metadata (Healthcare LOM)
- MedBiquitous Professional Profile, which describes a healthcare practitioner and her credentials
- MedBiquitous Activity Report, which can be used to express the continuing professional development distributed to learners by attending accredited learning activities.
The CWG has reviewed a number of well-established published competency and outcome frameworks in health care, including:
- Accreditation Council on Graduate Medical Education (ACGME) Competencies
- Acute Care Nurse Practitioner Competencies
- American Association of Critical-Care Nurses (AACN) General Patient Care Competencies
- CanMEDS 2005
- CanMEDS Specialty Competencies
- Good Medical Practice (UK)
- Good Medical Practice (USA)
- The Scottish Doctor
- Tomorrow's Doctors
- Women's Healthcare Competencies
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.
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.
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:
- Curricular elements
- Learning objects (e.g. in a Learning Object Repository)
- Learning or assessment events (e.g. in a scheduling system)
- Other competency objects from other frameworks
- Professional activities
- Professional portfolios
- Taxonomies of topics
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:
- The data is independent of the curriculum framework and the external objects linking to the framework, so it can be modified without affecting the others
- The competency framework and the external objects can be modified without affecting the mapping
- If the competency object and the external object both have Unique Resource Identifiers (URIs), connections can be made even if they sit in different systems
- Users can link objects to competencies without having to possess a copy of the framework in their own system, but this does not preclude users from importing a copy into their system if desired
- Searches in either direction (e.g. find objects that are linked to competency X or find competencies linked to object Y) are possible
- Federated searches across multiple databases/repositories become possible
- Data access to various users can be controlled (e.g. a public user may be able to search for learning objects that address a particular competency and retrieve a list of learning object titles, but only authorized users will have access to the actual object)
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.