|
|
| Notes from that meeting (June 29th): - A user in Folio can belong to different groups (staff patrons vs. staff library members)
- Employees have different legal bases depending on whether they work for the library or not: employee data protection
- Users sign a contract with the library and based on this we process their data
- Each user can be assigned a user type in Folio. What if the user is both an employee and a user of the library ? => is user of the library / patron
- Ingolf shows list of potential personal data in the Folio-Wiki
- Contacts in organizations: Personal data is also included there, which is recorded based on a contractual relationship with a supplier, etc. (purchase of media). Sven: it is not critical to store and process this data in the live system, but this personal data may not be stored in the LDP. Differentiate according to public and non-public data of people.
- Data in LDP: There is no deletion mechanism, which is why all personal data must be anonymized in the LDP
- U.S. libraries also use the LDP for quality management. For European libraries, we propose the following: A database (QM system) where the data can be deleted after a defined period of time (e.g. 1 year) and for which personal data should be included. Sven: This approach would be compatible with GDPR because it is needed for quality control and it can be legally justified to employees and patrons.
- Then one could differentiate: 1. Live system, 2. LDP (without personal data) and 3. QM-DB also with personal data, which MUST be deleted after a defined period of time.
- Sven: Have our own module for quality management - Ingolf: probably no capacity
- GDPR says: Data protection by default. Have to make it clear when defining the field whether the fields contain personal data
- Sven: How does anonymization work in the LDP? Ingolf: User records are not stored in the LDP at all. Whenever there is a reference to users, "0" or NULL is entered => to do Ingolf: find out what it says, because it is important if you want to find out later what has really been anonymized. Can you search for it? Instead of "0" there should be an explicit value, e.g. B. "anonymized".
- Suggestion: Create a list that contains personal data fields, regardless of storage and module. Maintenance of the list by developers of the respective modules in data base conception, i.e. think about data protection right from the start (privacy by design).
- Names of book authors do not have to be anonymized in the LDP! Not everything has to be removed wherever "name" is written.
- Our suggestion: Clear naming for the DB fields, e.g. both "userID" and "user_id" appear in the data.
- Sven: Shouldn't the consideration be the other way around? Think about which fields are required in the LDP instead of transferring all fields into the LDP and then looking at which of these contain personal data?
File: foreign_keys_ldp-AZ
- po_purchase_orders -> billTo and shipTo => do not contain any personal data
- organizatons_urls => do not contain any personal data
- inventory_items => does not need to be anonymized if the borrower has already been anonymized
- po_lines => => does not need to be anonymized if the borrower has already been anonymized
- address.raml: table usually contains no personal data |
Date