specification
specification copied to clipboard
The Human Services Data Specification - a data exchange format developed by the Open Referral Initiative
The phone and contact entities are child records of several different kinds of parent entities. This is implemented by these entities having multiple foreign keys, most of which will be...
I'm hearing feedback that people want to better understand which fields are required vs optional in various contexts. This might not be one fix, so much as a set of...
Expand phones “type” to include TTY and other phone types (Toll free, free call).
As per “Location” entity, particularly confidentiality Expand email to include name, description and confidentiality Expand eligibility to at least same as ISS Incorporate ineligibility Consider “intake” information, including location (may...
Consider provider type and organisation type as per ISS. Expand email as per ISS Consider adding a dataset objects field Add a last updated field Consider expanding locations Consider incorporating...
Consider temporary or short lived services (ISS calls these events) Consider localisation for all records
Modelling whether a service is open for the public or needs an appointment/application process etc
Suggest an amendment to the schema where a `service_accessibility` table or column (or a better named one) is introduced where details on whether the service is open for the public...
The Library of Congress has a [format called MARC 21](https://www.loc.gov/marc/community/) for community information that should maybe be included in the "Related standards" section. It was referenced in a library science...
I have been implementing the Open Referral API and would like to question the approach taken in the HSDA Specification to returning objects. For example, as single /services/{id} request returns...
* Add a bit more information about using datapackage for sharing data * Add placeholder for link to example datapackage