2019-07-03 Reporting Data Privacy Working Group Meeting Notes

Date

03 Jul 2019

Attendees

We will use Joyce's webex account for our weekly meetings:

https://dukeuniversity.webex.com/join/jcc81

Goals

Precisely formulate our question to the Reporting SIG about asking them for help in analyzing the LDP reports for dependency on personal data. Present this to the Reporting SIG on Monday, July 8th, 2019.

We are asking the Reporting Sig to help us with scanning all LDP reports, identifying which ones contain personal attributes, and determining whether the report can remain functional if these are removed. If not, what personal attributes are absolutely essential for the report? At the last Reporting SIG meeting, Sharon Beltaine suggested that we (the Data Privacy sub-group) could look through all the reports and flag those containing personal data. Also, several questions were raised about audit trails (staff data privacy).

Discussion items

Time

Item

Who

Notes

Look at list of personal data attributes, make sure we have covered them all

all

Potential personal data: List of FOLIO attributes

Meeting Notes

Based on Ingolf's conversations with a data privacy officer, we formulated a list of attributes considered personal data, which should not be included in the LDP. A few attributes were flagged as unnecessary for reporting purposes, and should also be excluded (see Table 1 below).
As well, we flagged several attributes that can only be included if they are formulated in a specific way (see Table 1A below).
Tables 1 and 1A should be shared with the Reporting SIG.
We all agreed that it would be very time-consuming for this small group to look through all the reports and flag them. As well, as the reports are often described at a higher level, without an actual list of attributes included. Each report needs to be understood in depth, to determine whether it contains personal data attributes or not. We need to crowd-source the process of flagging reports.
Update on 7/8/19: Joyce Chapmanlooked through the reports and found that "There are 32 that I found that could have personal data. Some I don't have enough info about, others it's very clear. Basically every single report on the user mgmt tab of the reporting master spreadsheet is for sure personal data -- these are all reports that call up different types of lists of patrons. 18 of the 32 I marked as "definitely" including personal data, and 11 of those are the "user mgmt" tab of reports." These are at https://docs.google.com/spreadsheets/d/1nR9frGMUgWq6TNKJFhY84FJx2Cwnlndnd2iq6p0wDx4/edit#gid=0
Before taking on the issue of staff data privacy, we want to ascertain whether any reports of audits will ever need to be run from the LDP, instead of in-app. This may not be an LDP problem at all.

Table 1: List of FOLIO attributes considered personal data, which should NOT be included in the LDP:

attribute	description	example	comment
username	id name given to patron by system or institution	jhandey
lastName	last name of patron	Handey
firstName	first name of patron	Jack
middleName	middle name of patron (if any)	Michael
last_login_date	Date the patron last logged in	01 Jan 2011	This attribute does not have any reporting purpose for LDP reports
phone	patron's phone number	+1 (212) 567-8912
mobilePhone	patron's mobile phone number	+1 (212) 678-9123
email	patron's email address	jhandey@biglibrary.org
addresses/addressLine1	First line of patron's address	1001 Sunrise Blvd.
addresses/addressLine2	Second line of patron's address	Apt. 2D
addresses/city	Name of city associated with address	Tombstone
addresses/primary Address	Is this the user's primary address?	Yes OR No	Since actual addresses may not be included, this attribute becomes irrelevant. This attribute is useful only for in-app reports, along with actual addresses, as needed to contact patrons.
addresses/description	Type of physical addresses associated with the user	permanent OR temporary OR some other sort	Same as above; it is irrelevant
addresses/addressTypeID	A UUID that corresponds with an address type object	89402743204xdh980284	Same as above; it is irrelevant

Table 1A: List of FOLIO attributes that could be considered personal data, and which can be used only if they fulfill certain conditions:

attribute	description	example	comments
patronID	unique id number given to patron by system or institution	7261ecaae3a74dc68b468e12a70b1aec	An id number can be used only if it has been anonymized, or if it used for internal communication with the database (it can't be outputted in any report).
patronGroup	type of user group the patron belongs to	graduate student	If there are cases when using this attribute will result in very small numbers through which individuals can be identified, then those records should be set up to not display.
patronGroupID	Id of the type of group the patron belongs to	89765gx89	Same as above: If there are cases when using this attribute will result in very small numbers through which individuals can be identified, then those records should be set up to not display.
dateOfBirth	birth date of patron	1965-07-08 (year/mo/day format or year/day/mo format?)	We can keep year of birth for reporting purposes. However, a report should show only counts within an age range (5 year ranges are o.k.). - If any age range group will result in very small numbers through which individuals can be identified, then those records should be set up to not display.
addresses/id	A unique id for this address given by system or institution	8974912053vh90	An id number can be used only if it has been anonymized, or if it used for internal communication with the database (it can't be outputted in any report).
addresses/region	Name of region or state associated with address	AZ (Arizona)	State codes and ZIP codes can be kept in the LDP. - If there are cases when using this attribute will result in very small numbers through which individuals can be identified, then those records should be set up to not display.
addresses/postalCode	Postal code associated with address	85638	Postal codes can be kept in the LDP. - If there are cases when using this attribute will result in very small numbers through which individuals can be identified, then those records should be set up to not display.
addresses/countryId	The country code for this address (ISO codes? system codes?)		Country codes can be kept. - If there are cases when using this attribute will result in very small numbers through which individuals can be identified, then those records should be set up to not display.

Action items

Present the above discussion to the Reporting SIG on Monday, July 8th.