I was curious does the current schema/processes consider GDDPR as I could not find a single mention of it.
In the nutshell if you manage your own data it’s easy to remove if something was published, just remove from your database. In the Open Referral case the entire ecosystem would work like Google Search Engine, meaning directories provide open data that can be copied, merged & replicated elsewhere so the data is no longer in one central place.
In terms like how Google handles: they have content removal requests that would remove any cached references to your data. Is there any plans to address this or there is already existing process that covers it?
Given that information in a resource directory is public information, about organizations – not about individual people – I’m not sure whether or how GDPR provisions pertain to it. Maybe contact information for staff would be covered. PErhaps we can learn more about this.
I do assume most implementations would have their own policies for managing takedown requests with or without GDPR. That said, it’s not immediately obvious to me what issues pertaining to this might be important to address at the specification level, other than provenance. Eager to hear what others think.
I was thinking about cases where organisations for very small charities can actually be “domestic” addresses and people can mix-up private & public details.
Posting private information in the public information fields - Some directories could have private fields for office use or whatever reasons.
Service provider could simply disclose too much information in description etc
So there’s currently a thread about the issue of private fields, and to a certain extent this seems to be related to implementation guidance that we could give pertaining to that (proposed) feature.
Otherwise, these seem like they may perhaps be implementation-level issues that’d presumably need to be addressed by data governance processes as per the responsibility of any given directory maintainer.
I’d agree with Greg on this sitting at an implementation-level. I think it’s useful to keep sight of HSDS as an interchange format and think of it in terms of form design: HSDS describes what the fields are and what format the answers have to be in, but it’s up to the person processing the form to make sure that what they’re doing with the data complies with the relevant laws.
Ultimately, GDPR compliance is for the individual data controllers and processors within the ecosystem to ensure compliance with; the standard just gives them a language to use to communicate with each other.
Please correct me if I am wrong but anyone who process data is liable in terms of GDDPR. Anyone who is reading one directory listing data to merge with other directories data would still be liable in terms of dealing with GDDPR data.
The problem is would “Open Referal” be able to set standard to communicate what sort of updates/changes in the service listing occurred.
There is a big difference between somebody removed phone number from contacts vs somebody removed it because of GDDPR.
Would it be easier just flag entire service and removed due to GDDP rather than blanking fields and create a new one? As this could get tricky fast.
This issue is manly for automated process of data removal for anybody who used GDDPR non-compliant data.
This is a topic I’d like to learn more about, so thank you for bringing it up.
I’ll offer some responses given my limited knowledge:
Please correct me if I am wrong but anyone who process data is liable in terms of GDDPR.
My impression is that it depends on the kind of data; personal information yes, but I’m not sure whether this pertains to information about an organization and even the point of contact for people who work there. The examples you give upthread seem to me to be instances of mistakes that presumably would be addressed through data governance policies in any given implementation.
The problem is would “Open Referal” be able to set standard to communicate what sort of updates/changes in the service listing occurred.
We have some specs for this in the metadata table, and there’s ongoing discussions about what else is needed to track changes. See here for instance.
There is a big difference between somebody removed phone number from contacts vs somebody removed it because of GDDPR.
Can you speak more to the nature of this difference? What might need to be specified beyond the record of a change?
Would it be easier just flag entire service and removed due to GDDP rather than blanking fields and create a new one? As this could get tricky fast.
I imagine it could get tricky, but again it seems like a question for data governance in any given implementation. Members of the Open Referral community are certainly positioned to offer guidance on best practices pertaining to data governance; perhaps eventually we could produce some content offering such guidance from the initiative.
However, when it comes to HSDS itself, I’m not yet seeing any dimension of this problem that requires specification of particular kinds of information that can’t already be produced. Curious what others in the EU think, as we just haven’t had much need to figure this out over here in the wild wild US.
This is a topic I’d like to learn more about, so thank you for bringing it up.
I’ll offer some responses given my limited knowledge:
Please correct me if I am wrong but anyone who process data is liable in terms of GDDPR.
My impression is that it depends on the kind of data; personal information yes, but I’m not sure whether this pertains to information about an organization and even the point of contact for people who work there. The examples you give upthread seem to me to be instances of mistakes that presumably would be addressed through data governance policies in any given implementation.
The problem is would “Open Referal” be able to set standard to communicate what sort of updates/changes in the service listing occurred.
We have some specs for this in the metadata table, and there’s ongoing discussions about what else is needed to track changes. See here for instance.
There is a big difference between somebody removed phone number from contacts vs somebody removed it because of GDDPR.
Can you speak more to the nature of this difference? What might need to be specified beyond the record of a change?
Would it be easier just flag entire service and removed due to GDDP rather than blanking fields and create a new one? As this could get tricky fast.
I imagine it could get tricky, but again it seems like a question for data governance in any given implementation. Members of the Open Referral community are certainly positioned to offer guidance on best practices pertaining to data governance; perhaps eventually we could produce some content offering such guidance from the initiative.
However, when it comes to HSDS itself, I’m not yet seeing any dimension of this problem that requires specification of particular kinds of information that can’t already be produced. Curious what others in the EU think, as we just haven’t had much need to figure this out over here in the wild wild US.
We have some specs for this in the metadata table, and there’s ongoing discussions about what else is needed to track changes. [See here for instance.]
It’s interesting to see a possible implementations of how changes could be tracked. It might just be enough for most cases.
There is a big difference between somebody removed phone number from contacts vs somebody removed it because of GDDPR.
Can you speak more to the nature of this difference? What might need to be specified beyond the record of a change?
My only worry is that change to be flagged in a clear way to know that change is related to the GDDPR rather than inaccurate or misleading data. Maybe have some predefined options as people can sometimes get too creative and long winded.
I think main point is to see how severe the impact of changes is based on ‘change type’ as administrator could address changes flagged by severity of it.
From audit perspective, it would be useful if something was flagged as GDDPR or something else in case it goes wrong e.g. GGPR flagged data was not removed or some other issue related to record keeping