From Ellen Meiselman, University of Michigan
I work for the Learning Management team for University of Michigan Health System. We run a learning management system for all faculty and staff at UMHS. We also develop and create much of the online learning that is used in the LMS, and provide education and support for embedded educators throughout the health system.
There are many things we wish we could do that cannot be done with the LMS technology we have now. Among them:
- We can't easily use demographic and performance data within our online learning to drive adaptive learning.
- We can't track what people actually use to learn and perform better. Our LMS data is summary at best, and limited to activities it knows about up front.
- We can't provide data that could be used to correlate how people and teams learn and perform with outcomes in a systematic manner.
In addition, the SCORM 1.2 standard that we use for most of our trackable online learning has a variety of technical limitations which is what originally led me to participate in the early discussions of what SCORM 2.0 should look like.
Examples of the requirements typical of what I asked for in those SCORM 2.0 workshops and interviews include:
- The LMS should vanish from view for most learners. They have little or no interest in logging into a specialized site they visit once a year. We need to make the experience of taking their mandatories as lightweight as possible, and as focused as possible.
- Let us easily access demographic data in a standards-based manner.
- Security is non-existent with SCORM, it needs to be fixed, at least for high-stakes activities.
- There should be a place to store "a lot" of arbitrary data.
- We need to be able to track using third party and disconnected sessions.
- The LMS shouldn't be involved in judging outcomes.
- Get rid of assumptions about sequencing and the need for complex sequencing to be built into the standard. We build our own anyway.
Now that we have been working with the xAPI standard for a while, there are some areas I would particularly like to discuss with the people involved in Medbiquitous:
Agent Profile Standards
Besides the Statement API, there are APIs for the Activity Profile and Agent Profile.
We can now access any part of a user or team profile from a learning activity, using a standard! For example, we could access roles or attributes that would useful for delivering role-specific pieces in a larger training module, like "is a Clinician", "works in a Patient Care Area", "performs Central Line Insertion procedures", "works in an operating room", etc. This can be done to some degree within an LMS, but not on a granular intra-activity level. It is usually difficult to add new vocabularies and taxonomies, and there is certainly no standard. Each learning object would have to be customized individually to access that data from an LMS and use it within the learning object.
Besides roles, we could locate competencies in the Agent Profile. These values could be static information, or dynamic links to competencies and performance criteria maintained by other applications.
All of these Agent Profile properties take the form of key value pairs, and you can have as many as you like. This means the learning activity can be adaptive, based on aggregated data from numerous disparate sources and modalities. Although many of these properties will need to be ad hoc, I think at least some of these profile facets should be standards, so that applications can all access the same data the same way.
The Result object contains space for extensions. I think there is plenty of room for discussion here about what would constitute useful extensions for medical education and training, including HPML - Human Performance Markup Language - a way to encode performance data into xAPI statements, interoperably, so performance can be tracked somewhat uniformly across modalities.