Add Location-feature extension to fix #21

[jmandel]

@bionicscott would love a quick look and thoughts on the value set.

[nickrobison-usds]

Hey folks. Sorry for missing this earlier. Let me check with some folks on our end and see how useful this would be. Might give us an idea of some real use cases.

[alexhooverUSDS]

Hello all! I am a designer with USDS and thought I'd chime in with some UX considerations.

I agree with some of the comments that "interpreter services" is a bit too vague. If you are interested in interpreter services, you will undoubtedly want to know which languages are supported.

I have a few insights from user research on vaccines.gov on language barriers. I talked to predominantly Spanish speakers that could speak some English but were more comfortable in Spanish. Knowing a location has Spanish interpretation would probably be useful information, but not the determining factor. The people I talked to were still looking for the most convenient location. That is obviously not representative of all people. Just a little slice of observation. I imagine the balance of factors (vaccine availability, convenience, language) would be much different if someone did not speak any English and didn't have any friends/family available to help them.

The only other thing I'd call out as a potential issue in just saying "interpreter services" is the availability of those services. Maybe a location has someone who speaks Tagalog, but they're obviously not there on every shift. It wouldn't be great if someone traveled further because someone spoke their language only to find out that that interpreter wasn't there that day. If a location is marked as having "interpreter services," what does that mean for the public? Does that mean there is always someone at the location that can interpret? Someone on call? It'd be good to specify some parameters, and I am not able to do that at this moment. I don't know enough about interpretation standards/processes in healthcare.

All of that being said, I don't think I would completely ignore the proposed extension in the UI. It's just that the proposal leads the user down another information finding path to see which languages are supported. It would be nice to surface that information in the consuming UI. I'd probably put the proposed "interpretation services" info on the location details page as something like "Has interpreter services. Check with provider on languages and availability." That way, the person searching at least has some idea of where they can get interpretation help. I have not tested that idea at all with usability testing. So take it with the smallest grain of salt possible.

Thank you all for everything you're doing on this spec and for constantly pushing the spec to surface this kind of information so the public can have a better experience.