MedBiquitous
MedBiquitous creates technology standards to advance healthcare education and competence assessment. Our standards make it easy to exchange educational content and track learner activities and profiles.
and in particular, the MedBiq Competencies Working Group
The mission of the MedBiquitous Competencies Working Group is to develop XML standards and supporting guidelines for competency data enabling educational resources and activities to be tied to a competency framework.
Introduction
MedBiq's information model is based on the distinction between what they call the "Competency Object", which is
... 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.
and what they call the "Competency Framework", which is
an organized and structured representation of a set of interrelated and purposeful competency objects.
This is the same distinction that runs through much recent work, and is reflected in InLOC thinking.
The Competency Object is kept as lean as possible, so that it can be reused in any applicable different Frameworks.
The specs partly rely on MedBiq's version of LOM, called Healthcare LOM (standardised through ANSI).
General information
(see Example source guidance)
| information to be gathered | details |
|---|---|
| Name / title of source/model and version if applicable | MedBiquitous Competency Framework and Object |
| Stakeholder | MedBiquitous |
| URL | Framework spec PDF; Object spec PDF |
| Orientation | professional education |
| Explicit model or implicit model? | explicit |
| Can organisations have competence? | no |
| Number of people currently affected | none currently, but potentially large numbers in healthcare education in North America and elsewhere. (roughly?) |
| User communities | medical students and professionals; could be much wider |
| Significant use cases | The main 'use' for this information will be to provide structured definitions that are referred to from learning resources and learner records. The obvious use case for these specs themselves will be creation and editing of competency definitions and structures. |
| Significant business cases | [MedBiquitous activity as a whole] "makes healthcare education more effective, measurable and accessible, saving organizations time and money in the process." |
| Sample materials | not yet available |
| Key features influencing their uptake of InLOC outputs | This is a well-defined existing spec, although not yet finalised through the Standards track, and it may have more detail to be added. InLOC's IM should be able to represent all the significant features of these specs, as they cover very similar ground. Thanks to good professional links, collaboration towards alignment is able to continue at a very effective informal level. |
Competency information in general is seen as 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.
Features for Object spec
Based on the version of 2010-09-14 (current as of 2012-03-19)
| N | Features | ? | notes |
|---|---|---|---|
| 00 | More than one model | 1 | There are two distinct models: "Object" and "Framework" (this table deals with the Object – Framework is below) |
| 01 | Identifiers | 1 | Expected to be URIs |
| 02 | Hierarchy (internal) | 0 | |
| 03 | Internal relationships | 0 | |
| 04 | External relationships | 0 | |
| 05 | Conditionality / optionality | 0 | |
| 06 | Text syntax | 0 | |
| 07 | Structured identifiers | 0 | following LOM, the identifier formally has two parts, Catalog and Entry, but the Catalog part examples may have just "URI" as their content, leaving the identifier effectively without any particular defined structure – implementers may also define further structure |
| 08 | Classification | 1 | modelled on Atom – any number possible; no particular ones mandated |
| 09 | Level attribution | 0 | if this happens, it is expected in the framework, not in the object |
| 10 | Level definition | 0 | |
| 11 | Context | 0 | Objects thought of as reusable, so no desire to restrict context |
| 12 | Evidence and assessment | 0 | designed to be referred to from these |
| 13 | Extensions | 1 | spec is extensible |
| 14 | Profiles | 0 | though, naturally, lists of objects can be compiled for any purpose |
| 15 | Adaptation | 0 | |
| 16 | Definition by example | 0 | Examples could be noted in the lom:description field |
| 17 | Learning resources | 0 | designed to be referred to from these |
| 18 | Learner records | 0 | designed to be referred to from these |
| 19 | Multilinguality | 1 | through the LOM langstring construct |
The CompetencyObject element has 5 constituent elements:
- lom:lom
includes identifier, title, description, publisher, all defined in Healthcare LOM - Category
similarly to Atom, this has term, scheme and label - References
for references to the literature - SupportingInformation
"such as formatted or lengthy descriptions of the competency object" - XtensibleInfo
as with most extension points, this is left for use by any implementing organisation
One reason for SupportingInformation is that LOM allows only plain text descriptions. SupportingInformation can either be a URL link, or an xhtml div element similarly to xhtml content in Atom.
Features for Framework spec
Based on the version of 2011-12-14 (current as of 2012-03-19)
| N | Features | ? | notes |
|---|---|---|---|
| 00 | More than one model | 1 | There are two distinct models: "Object" and "Framework" (this table deals with the Framework – Object is above) |
| 01 | Identifiers | 1 | expected to be URIs |
| 02 | Hierarchy (internal) | 1 | skos:broader and skos:narrower |
| 03 | Internal relationships | 1 | skos:related (only) |
| 04 | External relationships | 0 | not at present, but under consideration |
| 05 | Conditionality / optionality | 0 | |
| 06 | Text syntax | 0 | not applicable to frameworks |
| 07 | Structured identifiers | 1 | identifiers for Competency Objects referred to in a Framework also have Catalog/Entry structure: Catalog have just "URI" as its content with a URI as Entry, or Catalog may be a string designating a particular local cataloguing schema, with corresponding Entry |
| 08 | Classification | 1 | same as with Object, but with a different range of categories |
| 09 | Level attribution | 1 | Healthcare LOM has educational level information and other relevant information |
| 10 | Level definition | 1 | under development – will fit into a performance framework specification that will specify levels of performance or competence for a framework – there may be several performance frameworks for each competency framework |
| 11 | Context | 1 | Framework gives context to Objects |
| 12 | Evidence and assessment | 0 | designed to be referred to from these |
| 13 | Extensions | 1 | Extensible |
| 14 | Profiles | 0 | not designed for this use |
| 15 | Adaptation | 1 | EffectiveDate; RetiredDate; Replaces; IsReplacedBy (see below) |
| 16 | Definition by example | 0 | |
| 17 | Learning resources | 0 | designed to be referred to from these |
| 18 | Learner records | 0 | designed to be referred to from these |
| 19 | Multilinguality | 1 | through the LOM langstring construct |
The CompetencyFramework IM currently contains the following elements:
- lom:lom
similarly to Competency Object, but the nature of a Framework is distinct from the nature of a Competency Object, even if the Framework in effect serves to detail one particular Object - EffectiveDate
- RetiredDate
- Replaces
- IsReplacedBy
these four useful self-explanatory elements are not present in LOM, so are given separately - SupportingInformation
for formatted information about the Framework, potentially including links, etc. - Includes
here are given the CompetencyObjects included in this Framework - Relation
here are specified the relations between the included Objects - other
Any other or longer information
Guidelines requirements
InLOC consultation with MedBiquitous is through Simon Grant.