Focus On Platform Projects

Open Referral is platform agnostic. We are not invested in Human Service Data Specific (HSDS) compliant implementations running on any single platfrom, or vendor. Our mission is that any human services implementation can run anywhere, and these are the platforms we are currently targeting with implementations and projects.

Heroku

The original Ohana implementation of Open Referral runs on Heroku, and we are looking to develop additional implentations that will deploy and operate via the Heroku cloud platform, and even potentially connect with SalesForce along the way.

Amazon Web Services

The Human Services API prototype in PHP currently runs on Amazon leveraging EC2, S3, and RDS for the backend. We are looking to develop additional solutions that run on AWS, and leverage a variety of AWS solutions like Labmda, API Gateway, and more.

Azure

We have begun to explore what it would take to design, deploy, and manage human services API implementations on the Azure platform. We'd like to have a working prototype, as well as specific implementations on Azure that we can showcase and help support future efforts on the cloud provider.

Google

We have also begun explore what it would take to design, deploy, and manage human service API implementations on the Google platform. We are looking for investment, developers, and potential implementations that would benefit from running on the Google platform. There are a wealth of services available on the platform, that the communitiy can put to use when providing access to data and other resources.

If there is another platform you'd like to see a Human Services Data Specification (HSDS) implementation target, please let us know. We are considering investing in platforms like Salesforce, WordPress, and others, but we don't like to start new projects without some support from a real world implementation and partners.

Develop Open Tooling

In addition to the platform projects, and the PHP demo, we are regularly investing in new open source tools, as well has help seed and encourage new projects developed on top of the Human Services Data API (HDSA), help service providers better serve their consistuents.

Ohana

Ohana is the original implementation of the Human Services Data Specification (HSDS), which began as a Code for America project. The project is still an active open source project with a number of forks and implementations. Ohana is a Ruby implementation, that runs on Heroku, but can be deployed anywhere.

Open Referral Playground

An open source tool developed by Chris Spilio, for validating the Open Referral schema, providing a dynamic registry of resource types based on latest schema, a visualization of a resource schema - this includes fields, keys, types, formats, etc., download sample CSV templates of resources, and upload and validation of a sample CSV file. A great example of the Open Referral community in action.

Human Services Jekyll

This is a prototype for running a Human Services Data API (HSDA) 100% on Github, using Github Pages, and Jekyll as the content and data management system. It is an ongoing work in progress, but would like to keep playing with a free, public, lite website edition that anyone can run as a low cost implementation. I'm also playing around with managing the data using Google Spreadsheet, which syncs with the YAML in the Github repository.

Define A Revenue Layer

One area I study as the API Evangelist is around the monetization, and access plans of leading API providers--studying how they are generating revenue around API consumption and even partnerships. I'm looking to extend this work to the human services industry, helping providers generate much needed revenue from their hard work, while still serving their consistuents. Here is an aggregation of all my stories regarding monetization of public data, and how this applies to my Open Referral work.

Setting a Precedent When Charging for High Volume Access to Government APIs

Continuing my work to help the federal government think about generating revenue using public data and APIs. This time it was specifically regarding the Recreational Information Database (RIDB), and how the Department of Interior, and Forest Service can rethink digital resources alonngside how they generate revenue from other physical government resources.

Thinking About The Monetization Layer For Public Data

This is an essay I wrote doing a deep dive on the subject. I'm currently reworking this as a blueprint for how I am approaching monetization around human services data. It will become the basis for some future discussions I am facilitating around helping 211 and human service providers generate sensible and fair revenue around their operations--helping them stay available, and offering their consituents a valuable service.

Taxation On Public Data Via The API Management Layer

Continuing my thoughts on generating revenue from public data, I am actually exploring how the future of tax revenue at the municipal, state, or federal level can be conducted using APIs, and modern approaches to API management. This is all very new thoughts, but I'm looking to keep the conversation, preparing for the future of digital government.

We are just getting started with the discussions around how human service providers can generate revenue using the public data they manage, while also acknowledging other commercial vendors also generate sensible and fair revenue by providing products, services, and tooling to providers. If you have an experience and thoughts to share, feel free to get involved--we'd love to hear your thoughts.

Improve Schema & API Definition

We have just released the alpha version for v1.1 of the Human Services Data API (HSDA) Sepcification. You can read all about this release on the Open Referral blog, but the primary objective of the release is about ensuring the API offers as much coverage of v1.1 of the HSDS schema as we can. These are some of the conversations we are having around future versions of the specification, which you can participate in via Github.

Schema Filtering

We are discussing how the user should be able to dictate how much, or how little of the schema they wish to receive with each request to the API. There are several approaches on the table, but would like to implement a solution in v1.2 or at least v1.3.

HTTP Status & Error Codes

One of the next big projects is to help figure out what guidance we will be providing with the HSDA specification in regards to which HTTP status codes should be returned, as well as developing a set of definitions for standardized error codes.

Hypermedia

One important discussion on the table is regarding the usage of hypermedia in future editions. This could be done side by side with a simpler implementation, but would bring lots of benefits to the table when it comes to pagination, relationships between elements, and alleviate some of the versioning concerns.

Response Structure

IN parrallel to the hypermedia discussion we are considering how the body should be structured, allowing for more structure to the response, even standardizing with a common media type like HAL or JSON API.

Taxonomy

Another aspect of the specification we have put on the road map is regarding the taxonomy in use for any single implementation. Ideally the platform is taxonomy agnostic, and allows for a variety of implementations supported.

Metadata

We will be working on a metadata, and operational level of APIs, and specification for any single human services implementation. This would handle change log, transactional, logging, auditing, and other aspects of operating an instance. There is much to be discussed regarding where things are going with this area.

The Github repository is the main place we are handling the final discussion as they are applied to the specification. The conversation also occurs on Google Groups, and the Slack channel, but the final thread should always be available here.

Evolve Towards Interoperability

Some interesting new additions to the Open Referral road map involves planning for the future of interoperability that will be possible when there are many disparate instances available that support the HSDS/A specification. We are discussing some key areas that will help human service providers better collaborate, crowdsource, and partner in a way that protects everyone interests. These are a handful of the core conversations going on.

Approval & Feedback

How will be allowing for an approval and feedback system for changes made to any record within an implementation, allowing for anyone to add and update information, but ensuring there is proper oversight and approval to ensure a certain quality of service.

Unique IDs

We would like to eventually accomodate a universal unique ID system that can be used across implementations, and provide some sort of provenance and history of the record. We are doing more research about best practices, as well as talking with all vendors in involved with the specification.

Webhooks

We are beginning discussions around what a webhooks system should look like for any single HSDA implementation. Opening up the external push and event aspects of operation, making things more event oriented, and a two-way street.

Messaging

This is a suggested thread to tackle the topic of messaging, and how it can be applied within a single implementation as well as across multiple human services API implementations.

The Github repository is the main place we are handling the final discussion as they are applied to the specification. The conversation also occurs on Google Groups, and the Slack channel, but the final thread should always be available here. We are also scheduling some virtual gatherings to help push these conversations forward, so