1

Topic: GDPR Reporting

I am very aware of the financial situation relating to Recorder 6 at the moment so i am adding this more as a point of consideration to see how the community feel about it, whether they would support it, than anything else.

One of the aspects of the new GDPR will be that a recorder has a right to request information on how their data have been used by an organisation. As a LERC i can see this as being of particular interest and we have had such requests in the past.

However, the only way this can currently be achieved is if i was to track back through the data services we have provided and where a particular dataset relating to an individual has been sourced.

If there were a feature (perhaps optional activation) that enforced the entry of use details joined to the obs_key this should enable us to track and report on all uses of a particular record via Recorder 6 and would be incredibly useful in servicing GDPR requests in addition to more general interest on how and what records are being used for what purposes.

Richard Burkmar has implemented a similar functionality in his Gilbert21 SQL based personal recording software the code and/or experience in which may be worth calling on?

Given the potential impact to the recording community and the number of 'data collators' using Recorder 6 i assume this would be of interest as a feature. It would also help ensure R6 users deliver on GDPR compliance and so may, for some, help in future funding decisions.

Natural History & Biodiversity Data Enthusiast

2 (edited by stevemcbill 19-03-2018 12:15:48)

Re: GDPR Reporting

I would support you in this request Ben - a useful idea which I feel would greatly help in full GDPR compliance by LRCs.

Steve

Steve J. McWilliam
www.rECOrd-LRC.co.uk
www.stevemcwilliam.co.uk/guitar/

3

Re: GDPR Reporting

I would also support this request but I'm not sure how you would "enforce" the entry of details about how data is being used.  You might be able to do this via the report wizard (i.e. require a "reason for use" to be entered when running a report) but there might be some issues:

  1. Subsequent uses of the data once exported out of R6 wouldn't be recorded

  2. Recording against individual observations could generate huge numbers of records over the years

  3. There would be no way to enforce entry when using data accessed directly from the database

Perhaps it would be easier to enable entry of use details at the sample or survey event level as this is how recorders are associated with observations in the database.  It would be more generic than at the observation level but would be much simpler to record, would generate far fewer database records and would be easier to query/summarise later.

Andy Foy
Systems Manager
Greenspace Information for Greater London (GiGL) CIC
www.gigl.org.uk

4

Re: GDPR Reporting

Hi Andy,

In my head this would work on export via the wizard (there are appreciably issues here for those working outside the R6 interface, 3).

1. I think we do have to be realistic in this. R6 is software developed to work within it's framework, if people work outside that, which is fair enough, then they can devise their own solution and actually if the logging facility is in place then it may help them to do so if not provide an absolute solution. This should also be true when following up on onward use (as applicable) as a LERC these would often be limited by agreement anyway, but where not at least you would have a list of people to inform which i would argue as reasonable effort as per the requirement.

2. SQL db's appear to me to be pretty efficient at storing data our db has around 1 million 'records', alongside site locations, personal details, habitat info and associated documentation URLs etc... The file-size amounts to 4MB. I agree there will be additional space requirements but i don't think they will be insurmountable for most. Something to consider though (hence the 'optional feature).

Rich's Gilbert21 enforces a reason on export of any kind from the database i have been using it for several years and the file size is minimal (it happily sits on my Google Drive). It has already proved incredibly useful for me personally tracking who i have sent to what and why.

Natural History & Biodiversity Data Enthusiast

5

Re: GDPR Reporting

BDeed wrote:

1 million 'records', ... 4MB.

This is a slight aside, but the taxon occurrence keys alone for 1 million records amounts to ~15mb; our database holds around 8 million and is over 13gb. We do have a some extra data (grid refs, individuals), but not that much.

Charlie Barnes
Information Officer
Greater Lincolnshire Nature Partnership

6

Re: GDPR Reporting

You are quite right Charlie. I retract my earlier statement! (4gb, slight difference...). However, i still feel the feature would be worth the additional space required.

Natural History & Biodiversity Data Enthusiast

7

Re: GDPR Reporting

If you can get an estimate of the number of records output (i.e. including when used multiple times) its a trivial exercise to work out the storage costs. I guesstimate we output 800,000 "records" a year - using the structure in TAXON_OCCURRENCE_RELATION as an example, this equates to around 100-500mb additional data a year.

A bigger concern might be running out of keys - but you'd have be "outputting" an order[s?] of magnitude more data each year to even come close to the limit.

Charlie Barnes
Information Officer
Greater Lincolnshire Nature Partnership

8

Re: GDPR Reporting

I think to move forward with this we would need a detailed user requirement which has broad agreement of sufficient users to make it worthwhile.  I think there might be the resources avaiable to actual make the changes, but it we need a user requirement first.

Mike Weideli