Child pages
  • 2009-10-14
Skip to end of metadata
Go to start of metadata

Attending: Joel Farrell, Chair James Fiore, Dan Rehak, Carl Singer, Valerie Smothers, Tim WilletAgenda:

1. ADL dropping all profiles of Healthcare LOM
Valerie explains that Dan had sent her an e-mail explaining that ADL is dropping all profiles of LOM. She wanted to further understand the implications for Healthcare LOM.

Dan explained that there is no longer a requirement in SCORM to have metadata. There is a requirement for the ADL registry to have metadata. Valerie asked if the test suite would still test for metadata conformance. Dan commented that he is not sure. Valerie asked which version of SCORM dropped the metadata requirement. Dan commented that it was probably 2004 third edition. He recommended asking Jono questions about the test suite.

Valerie asked what in the healthcare LOM specification should change. Dan explained that in the meta-metadata field there was a reference indicating conformance to ADL. The healthcare lom specification needs to take out that reference.

2. Discussion with Tim and Rosalyn on the progress and issues encountered by the Competency Work Group, including:

Support of other competency definitions, where relations among competency definitions are defined

Valerie summarized the current situation in the competency working group. The group has built the specification that mainly utilizes the IEEE reusable competency definition data model and extends it allowing competencies to be arranged into a hierarchy and adding some healthcare specific fields. The problem is that many in the group find elements in reusable competency definition confusing, and we are questioning whether we should purely extends the IEEE standard or eliminate some of the optional fields. We also questioning where relations among competency definitions are defined: within the competency definition or in a separate map.

Joel commented that in the professional profile specification we did look at other specifications for name and address but we did not use them because we felt they were overkill. It comes down to what is important and how generic is RCD intended to be.

Dan summarized that the RCD is an ID, title, description, and everything else is optional. There are no vocabularies; most of the fields are text strings. Basically allows you to put an identifier on a piece of text so that you can refer to it in other places.

Dan provided an example. A competency definition might be "can drive the car." You have a title (driving), and identifier (number 17), an English-language description (has ability to drive car), and a competency statement (the state of Maryland defines this as...). The definition is meant to be more defined in the semantics of a particular organization. MedBiquitous could be the source and define a model with a more formal definition than the optional string.

Joel asked if we were doing that. Tim replied that we decidedly were not. Too many different organizations are doing competency frameworks using different models. We want a shell in which they can publish their frameworks.

Joel asked what the differences between RCD and our specification are. Tim replied that there are two additions: category and reference. Almost all frameworks have some kind of typing. For can meds, it's roles, key objectives, and enabling objectives. The category element would allow them to refer to that typing. Some frameworks refer to published papers to justify a competency. A references element would allow them to do that. It's the definition statements that the group is getting hung up on. We just don't see how would be used. And we've not seen an example of a published framework that would need it. Tim added that the group had decided relations will be outside the competency object. The framework would provide the relations among competencies that are related to one another.

Dan commented that metadata could be associated with the individual competency definition using the metadata element. He recommended looking at the IMS best practices and at the IEEE specification. The first metadata instance must be lom. There can be multiple metadata instances. He added that we could use metadata to define associations.

Tim asked the purpose of using Lom and a competency object. Dan explained that it is the source of the definition.

Tim commented that metadata like who published the competency could be in the metadata for competency framework. He asked if that was the type of information intended to go in the metadata fields of competency. Dan explained that if two similar competencies come from different sources, and both are referenced in the same framework, the framework metadata would not identify where those competencies were from.

Tim commented that the University of Ottawa was putting together a framework. Some of the competencies were new, some from can meds, and some from another framework. They wouldn't want to re-declare the competency within the framework but rather accuse the URI of those objects and indicate how they fit into the tree. He encouraged the group to look at individual competencies. He added that it's okay to leave metadata as an optional field. He added that it would help to see an example a the statement element being used.

Dan recommended looking at the IMS competency best practices guide. They provide a simple example: proficiency for admission to college in Oregon. The competency may be understands structures and systems of US government. The model consists of context area proficiency and criteria. He added that RCD comes directly from IMS with very few changes from IMS documentation.

Valerie asked Dan how widely the definition statements are used. Dan replied that he did not know. Valerie agreed that we would not need extensible info given the flexibility of the statements.

Tim asked if we should include competencies by reference in other words reference competencies outside the framework. Dan commented that no one could agree on how to put competencies into a framework. In addition, no one could agree on shared global naming. IEEE RCD was seen as the simplest component to be reused in other places.

Valerie commented that a URI reference to something external would be appropriate.

Dan asked for clarification on the goals of putting competencies in one or more documents. If you have definitions to share, the competencies should be an individual files. If you're looking for how to organize existing definitions into a structure that has meaning within a community, a specification on how to structure is appropriate. If you're looking to solve the use case of moving a collection of competencies from one place to another, that's a different use case. IMS/IEEE intentions were to have RCD as the definition, the framework undefined, and packaging is the exchange mechanism. If things are separate, you can reuse them build and smaller pieces and use things in unanticipated ways.

Tim describe that one use case is managing competencies within an undergraduate curriculum. This lecture addresses that competency, this learning object helps the learner to achieve this competency. Another use case would be for a nurse manager in ICU: which of my staff have achieved a given competency? How do I know they have achieved it i.e. what is their record or a test or performance. Cross mapping from one framework to another is another use case. All of these use cases have competencies is individual objects can be pointed to. Foremost, the organization would publish the framework describing have the competencies relate to one another. One document is more intuitive, but if it's a barrier to implementation, perhaps it's better to have the competency separate.

Dan commented that a physician has different specialties, and each specialty may be likely to have their own framework. For physicians educational trajectory, it might be important to list competencies from different specialties for single physician. Valerie commented that physicians would be more likely to have a full set of competencies for their profession assumed. Tim question that assumption. He asked if the framework would have to be repeated in Peter's portfolio.

Dan commented that the group should think about when they need the whole versus when they need only pieces. Some organizations are doing fairly elaborate things with competencies.

Joel commented that we can schedule a follow-up call. He is unavailable for the next scheduled call on the 28th. He Valerie agreed to work on rescheduling that call.

CORRECTION: Joel is available Oct 28th, so we will proceed with the regular call schedule.

  • No labels