2009-03-04

Meeting Information

In addition to the usual teleconference we will be hosting a web conference so we can view and revise a document as a group. Use any web browser to log in at http://webmeeting.dimdim.com/portal/JoinForm.action?confKey=twillett. (Holding down Shift while clicking on the link will open it in a new window). If prompted for a meeting name, use "twillett". No downloads or software installation are necessary.

Agenda Items

1. Review minutes from last meeting

The minutes were approved.

2. Review conceptual model for MedBiq Competency Environment

Tim circulated the White Paper, "A Model for the MedBiquitous Competencies Environment (MCE)" for review prior to the meeting and asked members to pinpoint any concerns or confusion in the definitions.  Susan questioned the difference between learning outcome verses learning objective.  Peter referenced the Hardin article that makes that distinction.  He suggested we might not agree on the distinction between the two but we can still use them whether they are agreed upon or not.  He stated these are more working definitions to approach the technical model.  The group unanimously agreed to accept the model after further discussion, provided the model is structured such that organizations can sue 'objectives' or 'outcomes' according to how their own definitions.

Definition of a Competency Object.

Mary Pat mentioned the definition in the introduction was unclear; however, the one under conceptualization seemed more straight forward.  Peter noted it was definitely shorter but referenced a competency definition that is not defined. 

Tim explained this is based on the IEEE's RCD spec.  He asked Mary Pat if it would be helpful to omit the second set "statements are not limited to" phrase and she agreed.  Tim mentioned there are different types of frameworks speaking to each other and they may have objectives and outcomes together in a topic list.  Susan agreed that flexibility can fit into a higher data and the XML metadata reflects this. 

Do we limit the "types" of Competency Objects to a controlled list? If so, what types are there?

Tim offered the choice of choosing from a limited list or allowing users to add whatever they want to the list, making sure all types of users are covered.  Peter agreed we wouldn't be limiting what they would put in content just the categories.  Susan commented if you want to limit the list, then she is all for it.  Tim mentioned there are ten to twelve very commonly used classes, and we need to make sure we capture them all.  Peter shared if you had the six of them in a document, then other people would want to add a couple, but on the other hand, limiting the list assists you in ending up with something that is better or different than other statements.  The group consensus was to proceed with the intention to make a limited list.  Peter cautioned not to impose rules on how end users define or use different types.  He would hesitate to impose a rule where objectives could not be children of outcomes or vice versa.  Tim acknowledged and agreed to steer clear of that. 

Competency Object elements

Tim further described the tables having a number of different elements that could be included in the competency object framework, and how frequently they occur.  He explained that competency object centers on type of statement and data that can describe it further.  Mary Pat noted one competency statement can have many conditions for performance.  Tim described Table 2 as having one unique ID and one type but the rest of the elements can have many.  Mary Pat asked where the scales come in?  Tim mentioned the scale of 1-4 define what is 1, 2,3 and 4 all levels, and references performance criteria perhaps.  Tim asked Susan for her thoughts on rules.  Susan will try to find a term for that.  Tim will add something referencing "degree of competency standards to be met".  

Competency Object relationships

Tim continued with a discussion on competency object linking to each other to form a framework, the most obvious one is the hierarchical link. A discussion followed on the distinction between equivalence and similarity.  Tim shared similarity implies nothing about the children of one or the children of the other, its two statements that mean the same thing.  "Similar to" would direct to this competency but not how they are related.  Mary Pat questioned why that is important to include?  Tim shared an example of competency as it relates to diagnosis of acute coronary syndrome. 

Which types of relationships do we want to allow within a competency framework? What logically does a parent-child relationship really mean?  Is it different than an "enabling" relationship?

Peter described the types of relationships beginning with the parent child, and any item can have multiple relationships.  The framework is a massive hierarchy.  Peter mentioned when using "related to" you can put on any kind of relationship.  He would prefer similar to.  Tim thought it would make sense to say, "see also".  Tim gave the example of a curriculum search to find out where competency was addressed, and how it would be helpful to see what similar competencies exist within the framework. 

Tim mentioned the possibility of including Qualifier/Quantifier information about a link, but there is little demand for that, so it was agreed to omit it.  

What other metadata about a competency framework itself do we want to enable?

To group competencies it is easy enough to build the groupings into the hierarchy, rather than have additional data elements in the Competency Objects.  Peter articulated this as drawing a box around certain number of nodes, some that might have a common parent, some that don't.  He asked how groups that have many different parents get represented in the model.  Peter questioned the need for metadata item within the competency object itself.  Tim answered that the model would allow for multiple parents, so a given competency can be classified in multiple ways using the hierarchy itself.  Susan asked if you wanted to not use the whole parent but only use one of the children (i.e. a specific competency statement) and add it in to another group, do you have to take the whole parent?  Tim answered no.  Peter shared examples from the Scottish Doctor, the first level is twelve learning outcomes and each of those has second levels with eight to twelve sub-competency levels. Peter suggested we allow a "group" to be a type of Competency Object.

Extra-competency relationships

Tim quickly presented the conceptualization of how a competency can be linked to things outside of the framework (e.g. learning objects).  The link data can be stored in one of three places:

• the competency framework document
• the metadata of the learning object
• a third 'mapping' document

Tim proposed the group develop a spec for the second and third option, but not the first.  The group agreed.

Decisions

• The conceptualization of the model as a directed acyclic graph (nodes with links) was endorsed by the group
• The model must accommodate different definitions of 'objectives' and 'learning outcomes,' etc.
• Hierarchical and 'see also' intra-competency relationships are sufficient
• Competencies from different parts of the hieraarchy can be grouped by giving them a common parent of type 'Group.'

Action Items

Update MedBiq Competency Environment document - Tim

Next steps

• Decide which elements to include in a Competency Object
• Decide on which types of Competency Objects to allow
• Decide on which types of intra-competencies to allow and the logical rules of such relationships
• Decide on how to structure a competency mapping document or metadata references to competencies