I work for the University of Michigan Health System, on the Learning Management Team. We run the enterprise LMS, create online learning activities for use across UMHS, and offer innovative solutions and training for educators embedded throughout the system.

Back in 2008, I attended a SCORM 2.0 requirements gathering workshop hosted by LETSI in Pensacola. My participation was driven by the hope we could improve SCORM and maybe move it toward some of the capabilities that we particularly wanted:

• Make the LMS disappear from the user’s view where it wasn’t absolutely needed, yet track everything that needs to be tracked.
• Open up the data inside the LMS to any application that needed to consume it using standards, so this wouldn’t be a custom project for every application.
• Track and use demographic, role and other types of non-SCORM data for consumption by adaptive learning applications.
• Eliminate technical limitations of SCORM, including cross-domain issues, the requirement for an open SCORM session to be present before communication could occur, and allow third party participation in tracking for use cases like mentoring and checklist-driven demos.

Fast-forward to a few months ago, we finally got the chance to unwrap our shiny new LRS and try it out! An xAPI LRS came with the Rustici SCORM Engine we integrated with our LMS. This was very exciting for us, since we had lots of ideas that could now be tested.

Unfortunately, experimentation with new technologies is challenging in our production environment due to high-availability requirements and clinical dependencies on the LMS, so we installed the LRS in a test environment instead, and started to build prototype xAPI projects.  We are currently in the process of implementing a stand-alone LRS in its own production environment, and that will enable the real pilots to begin without affecting the LMS.

Projects we are working on tend to fall into two categories: ones that involve the Learning Management System and ones that don’t. I think xAPI projects that involve integration with the LMS are only really interesting where xAPI can solve a technical problem or provide an LMS-related use-case that SCORM or AICC cannot fulfill. If it’s already working well, why fix it? Over the last few years, LMS’s have developed workarounds for some of the technical limitations of SCORM on their own, albeit in a non-standards sort of way, so the case for a LMS/LRS integration is somewhat diminished, but it is still worth doing, if only because it is a STANDARD.

However, the typical LMS is not truly an all-encompassing learning universe and there isn’t really a compelling reason to make it that. xAPI has quite a self-standing role to play. We need to bring the tracking to where people learn, not hope that people will come to where the tracking is for their not-explicitly-required learning. Truly, the use of the word “tracking” when used with xAPI is misleading –  since some of the best uses for xAPI have absolutely nothing to do with tracking completions and scores.

We may want to aggregate results, but it is not clear that the LMS will be the best place to do that after a while, since its data is a subset of the kind of data that could be collected with xAPI.

The reality is that people that have a choice will never go to the LMS for all of their learning, and especially not their “real” learning, no matter what LMS vendors would like us to believe, and despite vendor attempts at providing social learning and communities within Learning Management Systems.  But there are plenty of reasons for exposing, analyzing, or otherwise “tracking” some of that currently invisible learning in ways that don’t involve the LMS at all.

In case anyone is interested in getting our code, or taking projects further than we are able to at the moment,  some of the projects our team has worked on are listed below.