While working on a couple transformation projects these past weeks, I was reminded of a fairly urgent need in the spec: the ability to denote when an address is confidential, or should otherwise be hidden from public view.
For example, I may want to store the address for a domestic violence shelter on the backend for call-centers to reference, but in many cases I will not want to display that address publicly. I need a way to communicate that detail to consuming applications.
I can think of two methods for solving this off the type of my head:
Add a fourth enum to
address.type with value of “confidential” or “hidden”. This takes advantage of an existing convention, which is good, but may be too ambiguous in defining what type of address is hidden. Is it a physical, mailing, or virtual address that is being hidden? In practice, I have only encountered a use case of physical addresses being hidden, but I’m not sure if that can be generalized as an implicit rule or not.
Add a boolean “confidential” or “hidden” field to the
address table. I don’t love adding another field unless we have to, but it does disambiguate what type of field is being hidden, if that matters.
I’m very nervous about such a change because I only consider a publisher to be compliant with Open Referral if they have an open public API feed complying with the minimum API specification. So we can’t have an open feed with all data and a flag to show what’s confidential.
I’m also wondering if there are other fields or whole records in addition to address that should not be public.
Might we suggest that a private feed could add a field such as you suggest and include extra information but this is not to detract from the fact that non-confidential live data should be kept open?
We handle confidential contact information as well. Or rather: contact information that is only available to a subset of logged in users.
I understand Mike’s point about public APIs and think it’s a good one.
Maybe better for us to address confidential info in a section of the Guidance document?
Another issue similar to this, for us, is publishing/verification. Our users are creating these directories and they want to be able to save drafts of information, put it up for review, and then publish. HSDS doesn’t address that type of workflow but it does offer a format for the final product.
So, in summary, HSDS is strictly to be used as a standard for exchange of public data. When used for back-end or administrative purposes, it will need to be extended, and that’s a matter of implementation choices.
I can almost live with that, but I feel like this particular use case has come up quite a bit, and will be a necessary component of all federation attempts. Organizations will want to swap confidential addresses (and probably contacts, to Devin’s point), but keep that from being publicly viewable.
I think we should say that may also suitable for separate interchange of non-public information but this should not be seen as an alternative to making open all data that is not sensitive.
Perhaps we can define a Profile for exchange and collaboration of data between enterprise organizations. In such a case, the goal is still the exchange of data (and a positive move towards more openness), but they will need to collaborate on private information. I would prefer that such things are still standardized as much as possible since the goal remains interoperability.