Hi folks – overall, responses to the proposed version 3.0 have been very positive. We got some very thoughtful feedback from 360Giving that I’m going to share here, and @marion.galley can join the discussion here in the forum to elaborate.
See below, and I’ll also try to relay the subsections to other relevant threads here in the forum.
360Giving is pleased to see the updates made for version 3.0 of the Human Service Data Specifications. In particular, we welcome the addition of structures to support the inclusion of externally referenced organisation identifiers and geocodes.
Organisation identifiers
The ability to include organisation identifiers is a huge improvement for the HSDS and we at 360Giving are pleased to see it. This will make it possible to analyse referrals data together with other types of data such as grants data and government contracts data, increasing the ability of the sector to understand its impact in terms of the grants they give and receive, the contracts they win and the services they provide.
The inclusion of a separate entity for organisation identifiers seems to introduce excessive complexity. It now requires an additional identifier for the identifier, which would not be needed if the identifier was simply housed in the organisation entity directly without reference to its own entity. This model significantly increases the complexity for data sharing and data analysis, especially when linking parent organisations, and it reduces the usefulness and interoperability of this data.
We are also not clear on the purposes of some of the different fields. If the Identifier Scheme field allows users to declare a scheme for the third party identifier taken from org-id.guide, then what is the difference between that and the Identifier type, and where are the types drawn from?
Also, if the Organization Identifier field is intended to include third party identifiers, then what is the purpose of the Third Party Identifier field? Is the Organization Identifier expected to include the Third Party Identifier plus a prefix indicating the Identifier Scheme? If so, it is not necessary to create a separate field for this. In the 360Giving Data Standard, we have a single Organization Identifier field that includes both the prefix and the externally referenced identifier together, as this information allows data users to identify the scheme and the identifier.
2
Location updates
The ability to include third party identifiers for locations significantly increases the user-friendliness of sharing geographic data, as latitude and longitude are not always commonly used to describe service delivery locations.
However, we would recommend against highlighting what3words as an example of an external identifier scheme, as it is fraught with issues, and this may increase its perceived legitimacy.
It is not clear whether there are any limitations on the types of third party schemes that can be used for sharing location data. 360Giving has had some experience with this, and found that as a result of our geocode types list not being validated, it has suffered from poor data quality and a proliferation of codes which is now unwieldy, while the official codelist has become out of date. We would recommend defining a closed list of schemes and maintaining that list to reflect changing needs, rather than being permissive of any scheme being used, which makes the data harder to map and compare.
We would strongly recommend supporting the use of externally referenced geocodes for all entities that relate to location, for example service area. This would make the data more comparable to other datasets, including being able to compare the provision of services to the area of impact of grants, or to government administration and reference data. Consider introducing a concept of location scope or similar for indicating a reach of a wider area than a single place.
We welcome the addition of the ability to distinguish between virtual and physical locations, as this reflects the growing trend towards delivery of services online.
Funding
The Funding is defined as describing the source the funding, but it only supports the inclusion of data about the organisation in receipt of the funding, not the funder. This doesn’t really describe the source of funding, so if that is the intent, should the entity support sharing data about the funder(s)? More structured data about funding sources would support interoperability with other data standards and data uses.
Many thanks to Marion and 360Giving for their input! Eager to hear thoughts about whether these issues merit changes to the 3.0 proposal, or whether these concerns can be addressed by other means.