2019-07-03 Reporting Data Privacy Working Group Meeting Notes
Date
Jul 3, 2019
Attendees
@Joyce Chapman
@Ingolf Kuss
@Nassib Nassar
@Vandana Shah
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 Markus 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 | Jan 1, 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 |
|
patron's email address |
| ||
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.