Version 0.2 of Human Services Data Specification: what’s new, what’s ahead

UPDATE: Version 0.2 Version 0.4 of the Human Services Data Specification (i.e. the Open Referral model) is posted! 

While working through the ‘alpha’ specification (v0.1) we received in-depth feedback and suggestions from a great cross-section of perspectives, including community resource data specialists, social workers, veterans of data standardization initiatives, vendors of referral software, domain experts, and more. We want to give special thanks (in no particular order) to all the people who got hands-on with their comments:
Paul Mackay, Folk Labs
Caroline Caselli, Haven Connect
Moncef Belyamani, Ohana Project
Neil McKechnie, iCarol
Charles Koppelman-Milstein, Polaris
Jenn Stowe, DC Open 211
Andrew Lomax, Bread for the City
Sameer Siruguri, Open Referral Bay Area
Manik Bhat, Healthify
John Allec, FindHelp
Tricia Burmeister, Google
Akshai Prakash, Deloitte
Hailey Pate, Open Referral Working Group
Derek Coursen, Open Referral Working Group
Eric Jahn, Alexandria Consulting
Janae Futrell, Atlanta Regional Commission
Stéphane Guidoin, Open North

A complete log of comments and responses can be found here.

Many of the changes so far in this process have been pretty technical (like specifying UTF-8 encoding and ISO vocabularies for languages and countries) but a couple are notable for their reflection of our values.

For example, consider the issue of ‘programs.’ During the Open Referral workshop and in our email listserv, we’ve hosted a number of discussions about the importance of the concept of ‘programs’ to researchers and decision-makers. In short: organizations provide services to people, but funders fund programs through organizations. Programs may entail multiple services grouped around a common theme. (Say a community recreation center gets funding for a ‘health program’— which includes an exercise class, a nutrition class, and medical screenings.) Though information about a program is likely to be irrelevant jargon to a person seeking help, it’s very relevant to someone who is trying to understand the allocation of financial resources in a community. So we’ve added this element as an optional type of data in the Open Referral model.

Another issue that emerged in our conversations was the issue of data format. Should Open Referral develop just a ‘flat’ easy-to-edit format, or would a viable format need to be more complex and restrictive? Our original plan — inspired by the General Transit Feed Specification — was to simply produce a format in CSV (Comma Separated Values), which is easily usable by anyone with a modicum of technical skill. However, a number of our stakeholders observed that CSV is flexible to a point where it could yield all kinds of variation in how it gets used, which (in a domain as complex and variable as civic services) can create problems when trying to enable data to flow between systems. This conversation revealed a tension between our prerogative to make a format as accessible as possible, and our prerogative to ensure interoperability among different kinds of technologies. BTW, our response here is: let’s do both! We’ll develop a basic format (in CSV) that is generally accessible by anyone, but also work with the Open Referral community to develop more structured representations of the data which may be used by more sophisticated technologies, ensuring that we also produce clear documentation as to how to use these formats in effective ways.

We welcome this rich stream of feedback from the community, yet also acknowledge that a more complex approach takes longer.

So here’s a look at our anticipated schedule moving forward:

• This month, we’ll be testing and iterating a logical model which prescribes some structure to the Open Referral vocabulary. We’ll also be updating the Ohana API according to this model.
• In November, we will be developing a ‘taxonomic overlay mechanism’ to enable users to integrate various taxonomies (such as 211/AIRS or Open Eligibility) according to their interests.
• In December, we’ll open the specification up again for public comment.
• We expect to deliver a version 1.0 by the beginning of 2015, at which point we will freeze the spec — so that it can be deployed and tested at length — for a period of about a year.

Thanks again to everyone for their work so far. Stay tuned for more!