Introducing Profiles: customize our standard for your domain!

Open Referral designed the Human Service Data Specifications (HSDS)to make it easy to share information about human services of any kind. But given the many nuanced differences across human service sectors – and states and countries and etc – it’s just not feasible to standardize every possible kind of information associated with any kind of service anywhere. So we didn’t try to do that!

Instead, we designed HSDS to standardize the most common information elements that can be expected in virtually any service – which turns out to be a relatively small set of fields, especially when it comes to the core requirements. This ensures that HSDS is relatively practical to adopt; however, at the same time, we do want users to be able to share additional information that is important to their communities even if not specified in the core format. To strike this balance, we’ve encouraged adopters to develop extensions through which they could include information that HSDS does not specify.

Now, with the publication of the new and improved HSDS version 3.0, we’ve gone even farther in enabling users to customize the specification to meet their specific needs, while preserving interoperability across our diverse ecosystem.

HSDS 3.0 supports “Profiles” through which adopters can publish a formalized set of extensions, constraints, and enumerations that together amount to their own tailored version of the standard. This makes it possible, for example, to standardize specific domains of human services – geographic and/or topical – so that different sections of our network can deepen their capacity to share detailed information that may be uniquely important to their context and use cases, while remaining aligned and interoperable with others in the broader Open Referral ecosystem.

Profiles can extend HSDS by:

• adding new optional or mandatory fields
• adding new validation rules (including making optional fields ‘required’)
• adding new structures
• adding new API endpoints to the API specification
• recommending the use of particular value sets such as taxonomies or enumerations.

Profiles can also constrain parts of the HSDS specification:

• removing fields and their validation rules
• removing entire schemas/Tables/Objects
• remove API endpoints from the API specification

(Constraints are sometimes desirable in specific contexts because not all parts of the HSDS schemas may be relevant to a Profile’s use-cases and context. This wouldn’t prevent a publisher from publishing data that has been constrained in the spec, but tooling that is designed to work with the Profile might treat this as ‘additional’ data and could ignore it, for example, in validation and quality checks.)

In addition to adding or removing specific fields, we believe that this will make HSDS more useful to specific communities that use specific taxonomies to categorize services, organizations, and other critical attributes associated with human services. HSDS itself will remain taxonomy-agnostic, but communities can now develop versions of the standard that require taxonomies of various kinds – and can even specify which attributes should be associated with which entities – and can then develop tooling that expects or even requires such attributes to be present. This can enable more kinds of functionality to be standardized within a given sector, geography, network, etc – while preserving a core of interoperability across such contexts.

If you think your community might benefit from the development of a Profile, here’s what we recommend:

1. Engage and discuss with the Open Referral community about the problems you’re trying to solve and how best to address them. Include in this dialogue other implementers in your context who may also benefit from a more specific Profile. This can help affirm your assumptions and think through common challenges.
2. Reference the Example Profile repository as you begin to develop and document your profile. This provides a reference implementation, and all of the tools and guidance that you’ll need to generate your final Profile schemas. Be sure to document the changes that are made in your Profile! Sample data always helps.
3. Share your new Profile with the community, and support others in using it. If you’d like, we can create a space in our Forum specifically for the topic of your Profile, so you have a dedicated space to support and collaborate with others.

We already have an example of this in action: the Open Referral UK network has developed a UK-specific profile that reflects the subset of fields which are important to describing services sign-posted by public and community organisations in the UK. This profile can essentially serve as the UK national standard – which is important, as compliance with Open Referral UK is already referenced in policies and contracts for national and local data infrastructures.

We expect it may also be helpful to develop Profiles in specific Information-and-Referral networks that have particular conventions and/or standards of their own. Let us know how we can help!

Check out documentation of the profiling mechanism here. You can also join discussion about this feature here in our forum. (And please note that we now have standing technical meetings once a month – join the forum to request an invite!)