AIRS Guidelines do not require a location where services are virtual. HSDS only tags virtual on the location

Technical
1

I ran into a little conundrum. AIRS guidelines, the most used guidelines for community resource data in the USA, does not require a location to be specified for virtual services. In some US based software solutions, this means that virtual services will not have a corresponding location record.

In HSDS however, the “type” of “virtual” is set on the location record.

So, per AIRS, virtual records won’t even have a location record, which is the only place for an HSDS spec record to gather the type=virtual flag.

When translating these AIRS compliant records into HSDS, at least one I&R vendor is considering adding an “is virtual” flag to their service records, which we can probably read and then turn into the appropriate location records for HSDS.

More of the I&Rs simply allow users to not include location data and throw no flags. I hesitate to just assume that any service without a location is virtual, but that’s outside the scope of Open Referral.

Nevertheless, the question here might be whether we want align OR with AIRS, or push AIRS to align with OR. Perhaps AIRS simply needs to clarify more specifically how to mark a service as virtual. I would prefer a solution that doesn’t rely on omitting data and making assumptions.

In fact, as I write this, I wonder if I shouldn’t be talking to AIRS instead.

@bloom do you have any feedback on this?

1 Like
2

I think this is a great suggestion to bring to AIRS. And they’re starting the process of updating their standards. (It will be a slow process.) I’ve been invited to their taxonomy committee, which is not the same group that would handle this, but I could probably route the feedback accordingly. Also we can ask @SarahP !

1 Like
3

I talked with Sarah S about this a bit. The way I understand it, they want the flag whenever the service can be completed virtually - likely either web or phone - independently of whether or not they have a public address. Many services will be marked as both. I don’t think AIRS allows you to have services without location records because it requires certain location fields. The fields don’t have to be filled out, but they need to be available.
Of course call centers that are not part of a system and are not interested in accreditation will always be less compliant with the airs standards or interpret them in varying ways.

4

Hi Skyler,

These are good points and timely, as there is a standards review on the horizon. I don’t have good answers for you right now - but will insure it’s a point of review/discussion when the time comes! Our current standards were last reviewed before COVID and the dramatic increase of virtual services, so they definitely need some tweaking.

1 Like
5

Hi all,

Thank you for starting this conversation @skyleryoung - here are my thoughts…

Virtual location is another type of location, that is different than a physical location. Physical location is traditional, brick and mortar - someone can walk-in (if allowed) and access said services. Virtual location is when there is no physical location to potentially access those services. Services are only accessible available online, through chat, text or phone, etc. The difference here, is that there is no physical location to access the services. Examples include web-based support groups, state wide or national helplines, etc.- the physical address is only a website, and not a recognized street, city, state, etc. address.

AIRS Standards states that it is mandatory to have location (site) data. But I am seeing many 211s and other information and referral programs omitting the location record, if the services for an organization are virtual as defined above. While the standards do not allow for this at this time, as long as it is defined in the organizations style guide, and done consistently throughout their data set, it is acceptable. I only know of one software application that allows users to mark a location record as virtual, allowing all services for that organizational record to inherit the virtual location for assigned services. (the ‘is virtual’ flag as mentioned by Skyler)

The additional issue is, if there is an organization that has a physical location and virtual location for different services offered. The options for a UI of the software applications available is to not connect the data to location data, and note in another data field that the service is accessed on the web only (ect). For example, one of the Public Health Agencies that services our area provides information about lead poisonings online only. If someone were to walk into their offices, they would be directed to access the information online - their staff will not, and cannot answer questions about this. It is a virtual only service.

With this in mind, I’ve shared this difference with one software vendor, and they are considering adding the ability to mark that a service is virtual at the service/program level rather than only on the location record.

So the question is, will this ‘is virtual’ at the service level meet HSDS and OR needs to capture needed location data to translate 211 and other information and referral virtual locations?

6

The UWW National Data Platform enforces the AIRS “mandatory Location record” standard. Organizations and Services without related Locations are dropped.

The thinking is that without a Location, useful search results can’t be returned (since they’re based on distance from the user’s location).

I’m looking at dozens of records from an accredited 211 that don’t follow this AIRS standard. They’re not excited about creating phantom Locations just to get them to show up in NDP search results (“But it doesn’t have a location!” :man_facepalming:). Flagging a Service as “virtual” does nothing to help this.

So yes, @skyleryoung, please push AIRS to align with OR on this.

7

@JamesCounihan thanks for that input!

@PollyM Where an organization has a service at a physical location and another service that is virtual, the existing way to express that in HSDS would be to have two locations: one physical and one virtual. It’s quite possible that vendors can create a user experience where the “check box” for “virtual” looks like it’s on the service record, but under the hood that’s being expressed as an associated virtual location. That would be an interesting discussion between developers. I think I know who you are talking about; would you mind introducing that topic between us :wink:

I agree with @JamesCounihan that enforcing the existence of at least one location record associated with every service record is best practice, mostly because that facilitates the creation of a “service at location” record, which is necessary for data aggregation across data sets with difference source schemas. But that is a different topic.

8

The UWW National Data Platform enforces the AIRS “mandatory Location record” standard. Organizations and Services without related Locations are dropped.

Hi! Is there somewhere we can access documentation on the specific standards and data validation UWW National Data Platform uses to enforce these standards? If data is being excluded because of how our feed is packaged, we can structure our feed differently (in light of Polly and Skyler’s comments).

9

Hi @JamieBono! I’m not going to speak for @JamesCounihan, but to some extent the standard is implicit, because connoting a type of “virtual” in HSDS is only possible through a location record. This would apply to use cases where the intake process is at least primarily) virtual, by phone, or otherwise exclusive of a physical address.

1 Like
10

Thanks, @skyleryoung! That makes a lot of sense. As we improve our processes, I am just always looking for better documentation for our development pipelines.