Data Ownership and Learner Control
6 min read
This post started off as a comment in reply to Leonie Haimson, but it morphed into something more substantial so I made it a separate, new post.
Hello, Leonie,
I'm glad that we agree about the need to safeguard student privacy.
I see the issues related to privacy and data collection playing out against a backdrop where the rights of learners are systematically downplayed and ignored. If we limit our work to stopping data from being shared in a single instance - to a single entity, in one type of datastore - we've delayed the problem but we haven't solved it. Students are still exposed to the next collection effort that comes along, and they have no new rights.
If, however, we shift the frame to include and emphasize the rights of the learner to own their own data, we are having a different conversation that empowers learners over time, across systems, and - most importantly - doesn't objectify learners as a set of data points to be shared or not shared. If we look at this as only a privacy issue, we risk not fully acknowledging the agency and rights of learners.
As I have discussed in earlier posts, this paradigm shift is actually in the best interests of organizations looking to build datastores, and clearly in the best interests of learners. With that said, I'm not naive, and the folks building and running datastores will likely need significant encouragement and assistance in becoming vocal advocates for learner control.
RE:
I think you underestimate what madeinBloom more dangerous than the rest. It was built to store a maximum amount of personal student data, aggregate it make it easily digestible to vendors and others.
Every data specification, and every datastore built to implement a specification, is designed to hold data - ideally, as much as possible, and at scale - and to simplify the transfer of that data, and to streamline making queries against that data. That's what datastores do; it's why they are useful. With regards to inBloom specifically, what inBloom is doing for data storage and data transfer isn't new by any stretch. Within education, the SIF spec - which has been around with ">some well known partners since at least 2000, is designed to collect data in a standardized form so it can be used in other applications, by other vendors. It includes comparable data points as other data standards, including the Ed-Fi standard which inBloom implemented.
Pearson's SchoolNet for PowerSchool does exactly what you describe - it collects data, stores it on Pearson's servers, and makes that data available to other apps (although the bulk of these apps are part of the Pearson ecosystem). And, Schoolnet is SIF compliant to streamline the data transfer between apps.
Both eScholar and Infinite Campus have also been used as state level solutions to facilitate data collection, going back 7-10 years in some cases. In New York State, according to eScholar case studies, schools and districts were collecting and storing information as detailed as individual student responses on test items - and they were doing this, in New York, before the Shared Learning Collaborative existed.
Clever is a company that exists solely to facilitate data transfer into vendor-supplied apps. Clever integrates with several student information systems, including Powerschool and Infinite Campus.
Additionally, solutions built on Ed-Fi are currently powering several statewide datastores. Ed-Fi explicitly pitches their spec to third-party vendors.
Starting in 2005, the federal government has given grants to 47 states, the District of Columbia, Puerto Rico, and the Virgin Islands to support building statewide longitudinal data systems. The solutions I describe here, in this post, are used in many of them. In light of the nationwide development and use of district and statewide longitudinal data systems that predate the Shared Learning Collaborative, the claim that inBloom is unique in exposing the potential for data exploitation just doesn't hold up. That potential existed - and was being exploited - well before inBloom came along.
The functionality of inBloom isn't new or novel; for inBloom to develop into a monopoly (as some people fear), every state would need to begin the time consuming and technically complex process of migrating off their current data systems, and into inBloom. But right now, Pearson's SchoolNet, Infinite Campus, or eScholar are a lot closer to the monopoly that people fear. The fear of all student educational data flowing through a single system is a horrifying thought - and that is part of the reason why it's necessary to understand the current lay of the land, where there are several established major players already controlling the data of millions of learners.
The one thing that does make inBloom different are the funding streams and development partners. The combination of Gates funding, and a Murdoch subsidiary run by Joel Klein as a development partner, is toxic. That, combined with some really tone-deaf PR about the value of data for vendors of personalized learning products, made for an incredibly messy launch. inBloom's communication since it's launch has not been particularly effective either, and has done little to dispel the mistrust that was generated at the launch.
On the positive side, inBloom has gotten the open source implementation of their software better than any of the other players in the space. If we're serious about local control, a viable open source option that doesn't require any interactions with any vendors is a step in the right direction.
But really, all of this is noise against the backdrop of federal regulations defining accountability reporting requirements that were put into place with NCLB. These reporting requirements include the need for state level report cards, and the state report cards are mandated to include district and school level information. These reporting requirements drive data collection, thus fabricating the need for data collection as a central obligation of public education. Please note - I'm not saying (in this post, anyways) whether this is right or wrong.
And this brings us back to learner autonomy and learner control. The reporting requirements of NCLB tacked "data collector" onto the job description of every teacher, and made students and the processes by which they learn in school objects of scrutiny. By acknowledging a student's rights to own the data they generate as part of their education, we can begin to shift the conversation back to developing a truly progressive, learner-centered system of public education. Opposing data collection isn't enough. Opposing increased testing isn't enough. If we're serious about empowering this generation of students to learn, grow, and thrive, we need to support learning environments that are built around learner agency. Privacy is a part of the conversation, but privacy is predicated on a learner's right to own their education.
