Child pages
  • 2010-02-17
Skip to end of metadata
Go to start of metadata

Meeting Information

Date:

February 17, 2010

Time:

8 PST/11 EDT/16 GMT

Attending: Rosalyn Scott, Tim Willett, co-chairs; Valerie Smothers, staff; Susan Albright, Mary Pat Aust, Simon Grant, Ronald Harden, David Price

Agenda Items

1 Review minutes of last meeting

In the last meeting we decided to move forward with the development of a competency object specification. Competencies are related via the framework. Valerie will present that work  today.  The minutes were approved.

2 Review competency object specification

Valerie explained the overall architecture of the specification. Each competency is defined in a separate xml file. This can be defined using the competency object format that Valerie will discuss or it can be defined using the ims rdceo specification. Because competencies are defined individually, they can be mixed and matched to support multiple frameworks. For example, the VA is creating a competency framework for women's health. They will likely define competencies for physicians and nurses, some of which will overlap, some of which will be different. The competency framework specification allows you to reference these competency objects and describe the hierarchical and non-hierarchical relationships among them.

Ronald asked if we would recognize different versions of a competency object or framework. Valerie agreed to double check to make sure that a version element exists in LOM metadata.

Ronald asked if profession would be part of the ,etadata describing the competency. Tim replied that you could specify the inteneded audience for a competency object or frameowkr using metadata. Rosalyn added that if a competency is agnostic with regard to profession, it can be reused for multiplke professions. Ronald agreed that competencies may be static across professions, but who will have a competency may differ depending on what county one is in, as well as other factors.

Tim noted that for competencies to be referenced appropriately would require the use of URI's. Valerie agreed to change the competency object specification to require URI's.

Simon asked whether there was a default language for competencies. Valerie replied that there was not. The group decided to make the language attribute required so that the language of a competency is clear.

3 Review competency framework specification

Tim commented that the framework specification is very flexible. The framework organizes competency objects and is therefore highly reusable.  Because of flexibility, it is easy to put out new versions of a competency object or framework. You don't have to restate all 200 competencies, just declare 10 new ones and show how they relate to existing ones. Tim questioned whether title should be required. Title is a subelement of lom, others lom elements could be optional. Valerie replied that she could add the requirement to the specification for competency framework and competency object. She would also review to ensure no duplication of elements.

In reviewing the relationships within the competency framework, Tim commented that it would lead to redundancy (A is broader than b, b is narrower than a).  He questioned whether redundancy was intentional.

Simon commented that it is like the "triples" relationships in resource description framework. Each relation has a subject, relationship, and object.

Tim encouraged Valerie to take question of redundancy to the TSC. They may want to look at what MeSH does in this regard.

Simon commented that it would be easy to transform to different representations. Skos - simple knowledge organization, adds broader match, narrower match for matching across frameworks. Valerie commented that would be key for the next specification this group works on, for matching competencies across specifications.

Ronald commented that he was happy with the broader than and narrower than relationships. People will always add narrower relationships. What becomes tricky is when there are alternate definitions of the same relationships, as with professionalism.

Susan mentioned there were redundant competencies at Tufts.  Tim asked Susan to provide some background on how their program had come up with alternate definitions. Susan replied that each clerkship was given major categories and asked to define the major competencies within those categories. There was no reconciliation across the clerkships.

Ronald commented that he had seen definitions of professionalism that vary greatly. In one sense, professionalism relates to the relationship with individual patients. From a sociological perspective, professionalism relates to the social responsibility of the medical school. These are two very different aspects of professionalism and would have different "narrower" competencies.

Tim commented that professionalism may have a number of different narrower competencies that relate to context. If you say A is related to B, but leave the nature of the relationship open to the interpretation of the reader, then it is up to the user to decide how to use that information. It seems that relationship types that are more detailed than the ones already included (narrower, braoder and related) aren't necessary for the description of a single framework, but may be considered for inclusion in a specification for mapping two frameworks to each other, when it may become necessary to reconcile, for example, two different competencies that are both called 'professionalism'.  In addition, whether a medical school is competent is very different than whether an individual is competent. Different frameworks can have similar words that are used very differently.  We leave it to humans to determine which framework to use for their purpose.

Valerie agreed to make the non-hierarchical relationship clearer in the specification.

4 ANSI announcement

5 Open discussion

For the next call, we will think about whether "related" needs to be more controlled or up to human interpretation. We will specify more specific relationships when mapping one framework to another.

Simon added that worked examples would be helpful.

Ronald encouraged the group to recognize that different definitions of competencies do exist. A recent editorial in medical education pointed to the problem of jargon; competencies often mean different things to different people. Tim replied that was a great example of what we would tackle when mapping one competency framework to another.

For the next call we will also review the conversation with the technical steering committee, review the ANSI announcement, and review including competency frameworks and objects.

Decisions

The language attribute should be required for competency objects.

Action Items

  • Valerie agreed to double check to make sure that a version element exists in LOM metadata. (it does)
  • Valerie agreed to change the competency object specification to require URI's. The competency framework spec should require a uri as well.
  • Valerie will add changes to the specifications to require certain pieces of metadata and ensure that there is no duplication with lom.
  • Valerie will discuss redundancy of relationships with the TSC.
  • Valerie will clarify the language around non-hierarchical relationships In the specification.
  • No labels