In this post -- the second in a three-part series (read Part 1) -- we'll take a closer look at the inBloom data model and API, including several elements that triggered debate and concern, and examine the differences between their definition and possible usage.

Scheme vs. Schema

Much of the controversy surrounding inBloom appeared to stem from its comprehensive API (an Application Programming Interface enables one system to communicate with another). Through inBloom’s platform, school districts and third-party application providers would publish selected data to, and read selected data from, the inBloom database via this API. From a recent New York Times article on inBloom:

The inBloom database included more than 400 different data fields about students that school administrators could fill in. But some of the details seemed so intimate—including family relationships (“foster parent” or “father’s significant other”) and reasons for enrollment changes (“withdrawn due to illness” or “leaving school as a victim of a serious violent incident”)—that parents objected, saying that they did not want that kind of information about their children transferred to a third-party vendor.

In the ELL space, educators might also see students with interrupted education, students with an IEP, or refugees seeking asylum. Whatever the case, there’s no question that the parents’ concerns are completely understandable and legitimate. 

Educational data is complex and wide-ranging. Not only is there student data, but also information on courses and scheduling, teachers and educators, grades and assessments. Furthermore, we need to be able to define important entity relationships -- linking teachers to students, students to grades, etc. -- in a consistent way so that these elements are part of a common vocabulary regardless of school or organization. It’s no surprise, then, that any useful API must be comprehensive and specific.

Unfortunately, the debate around the inBloom API clouded a critical distinction: Just because the API supports certain fields, such as family relationships and student discipline, doesn’t mean that they are going to be used.

It’s important not to confuse definition -- a well-documented slot in the API -- with usage. Today, school districts and companies like Ellevation face challenges when sharing even basic student demographic data -- names and grade levels. My guess is that very few, if any, school districts would elect to share family relationships and student discipline. There may not even be a need today to share information related to family relationships or student discipline. But make no mistake -- this data is probably already stored in the school district’s SIS.

Other factors, such as timing, connections and communication challenges, contributed to inBloom’s fate, but their API and data model shouldn’t be at fault. Indeed, other common data models (CEDS, SIF) have also made it possible to share the same data elements that raised eyebrows among inBloom critics. When it comes to data integration, school districts and ed-tech companies continue to struggle. Wider adoption of an open data standard -- one that is comprehensive, secure and based on industry best practices -- is essential.

Ultimately it is up to school districts to enforce student data oversight at a very specific level and provide full transparency to parents and guardians. It’s not enough to just say that “some student data” will be shared. Likewise, partners and service providers need to be upfront about the data elements they need to consume and how they are handled.

The last part of this series will provide recommendations for school district leadership and educational technology companies when it comes to data sharing, disclosure and privacy.

Disclosure: Ellevation Education was one of many ed-tech partners who participated in the inBloom launch demos last year. The company has no current affiliation with inBloom.