The capabilities of xAPI (Tin Can) mean that learning professionals could become accumulators and analysers of ‘big data’, with all the implications for handling data responsibly that come with this.
In a previous blog I unpacked some of what that might mean for us as instructional designers by using a specific example we have been working on. Here's how it concluded:
"Although as instructional designers and learning interaction engineers we don't have total control over student privacy, establishing and maintaining trust with the student should always be a vital concern for us.
"By only recording data that is relevant and purposeful, optimising the amount of personalised data, and communicating very clearly and honestly with the learner what we're doing with the data, we establish trust and contribute towards a solid contract for learning with the student."
As well as this issue of establishing trust with the learner, it is good to distinguish another issue, namely the fulfilment of legal obligations for data privacy.
Well, let's think through the second of these two issues a bit more. For now, we're restricting our discussion to HTTP/S based learning engagements delivered over the internet or an intranet, though xAPI is capable of much beyond this.
xAPI Gives Us Options
xAPI has the concept of Registration. Although this is a complicated detail, to think about this also illustrates how flexible xAPI lets us be, and actually the complexity just arises naturally out of the scenario requirement.
In the xAPI world a Registration is an instance of a learner undertaking a particular learning activity. With xAPI, a registration could be considered to be an attempt, a session, or could span multiple activities. There's no expectation that completing an activity ends a registration, nor that a registration is necessarily confined to a single agent.
xAPI allows for a flexible definition of registration which we can tailor to suit the needs of the particular learning engagement. It's also worth noting that the registration property is not required by xAPI; it's optional, dependent on the requirements or on the platform being used to deploy the xAPI object.
Let's look at this in a scenario:
Suppose I am a student and this registration property (a Universally Unique Identifier - UUID) is set at the beginning of my session. I take the test four times and succeed in achieving a pass on the fourth attempt. Even though you don't record my name against the records of the three failed attempts, if the registration UUID is the same for the failing statements and the passing statements it would be a very easy thing for you to find out about my failures! You wouldn't be able to make an honest declaration that statements related to a failure are held anonymously.
xAPI gives a lot of flexibility in the way we report and specify data, so there are lots of strategies we could conceive to resolve this issue. Here are four ways to consider:
Let's start with the simplest approach. Why is the registration UUID being used in this application? Can it be removed completely?
When I pass, change the registration UUID to a new one and report the statement stream to the LRS. Changing the UUID from those on the failed attempt statements breaks the trail of data that leads back to my name.
Set the registration UUID to some static value for this test (or this version of this test) so that the statements for everyone who takes this test all have the same registration UUID on them. My failures would get lost in the crowd.
Accept that there is a registration UUID trail; restrict access so that only technical administrators can see it; and only present extracted failure statements to the instructional design and stakeholder teams which does not contain any traceback data identifying the individual students.
It may be that you have no control over the registration UUID as it's being set by the LMS, probably for the session. If that's true then 1 and 2 aren't possible and you need to consider how to be honest with your student about the situation. One thing you could do is to give the student access to the same extracted data as is given to the instructional design and stakeholder teams so that there's some transparency.
If you take option 1 or 2 then it's significantly harder to maintain data about the length of time a student spent studying the course or taking the test. However, you can still get an average number of 'attempts before passing' from the data even though you're avoiding finding out how many attempts an individual student made for privacy policy reasons.
This much is probably the limit of our control as xAPI instructional designers. However, other things can impact privacy which as an instructional designer you are not in full control of, like web servers and IP and http logging.
Where there is a real concern about sensitivity of data either for personal privacy or for organisational security, it should be dealt with as a multi-disciplined team project including legal advice, as failure to handle it well could represent a significant business risk.
But in a large proportion of learning applications, there is little data that is likely to be of legal or critical concern for data privacy. Yet where you're using the power of xAPI to track a learner's behaviours there are probably going to be concerns about what is being recorded and why. Transparency about your data tracking is a good policy to pursue with your learners. Here are some things to consider sharing:
What data is being recorded
How long it will be kept
Who will see it
The intentions of the learning designers and sponsors of the programme
How this benefits the learner themselves in their quest to learn
To talk more about xAPI, data privacy, instructional design, or any other elearning issue, give us a call on 01959 543900. We're looking forward to hearing from you!