2024-02-05 Resource Access Meeting Notes - Gap List - Request anonymization
Date
Feb 29, 2024
Recordings
Find all recordings here: https://recordings.openlibraryfoundation.org/folio/resource-access-sig/ (pw: folio-lsp)
Zoom
https://zoom.us/j/337279319 (pw: folio-lsp)
Attendees
@Cornelia Awenius @Christine Tobias @Cheryl Malmborg @Amelia Sutton @Charlotte Whitt @David Bottorff @Dwayne Swigert @Kara Hart@Erin Weller@Karen White @Laurence Mini@lisa perchermeier@Magnus AnderssonOlga@Petra Schneider@Tara Barnett@Tobi Hines@Catherine Tuohy@Kimie Kester
Discussion Items:
Time | Item | Who | Description | Goals/Info/notes |
---|---|---|---|---|
5Min | Administrivia | @Cornelia Awenius | Meeting times | Note taker: @Catherine Tuohy
No meeting on Monday, February 19 (Presidents Day - US) Thursday, February 8 is joint meeting with Metadata Management SIG - starts at 11:30am. |
10Min | New Gap List Working Meeting - Planning | all | Magnus will take the lead for multiple items on requests notices reading room checkout will be a topic for the whole group, inviting people who are already involved | |
45Min | all | @Cornelia Awenius | Continuation of Gap List topic Request Anonymization |
|
Meeting Notes
notes from January meeting:
summary of loan anonymization
what we have:
on demand from a specific user record, not possible for loans with related fees/fines
through settings after a certain period, with different options for loans with related fees/fines and possible exceptions per payment method
patron name and barcode are removed from the loan, patron group at check out is retained
item search in the circ log shows loan actions without user information
what we don't have:
retaining patron custom fields and department field
request anonymization
we are not talking about:
removing patron information from open requests
workflows for confidential requests that should not show patron information at all
are there any workarounds?
the only one would be deleting closed requests, Swedish libraries are keeping them right now
open questions:
Do we need different settings for the four different closed requests statuses?
the group could see use cases for that, but could live without, most don't have access to closed requests in current/former systems
How to handle bulk anonymization?
should be talked over with Bulk edit group, automated anonymization would be more important for European libraries
Should anonoymization be possible for specific requests or for a list of search results?
to be discussed in connection with bulk actions
What patron information to retain (patron group, department, custom fields)?
to be discussed next time, suggestion: should be handled the same way as loan anonymization
How should anonymized requests show up in the circ log?
to be discussed next time
Should anonymized requests still be displayed when searching/filtering the request app, just without patron information?
to be discussed next time
notes from this meeting:
different options for the four different closed requests statuses are not necessary, agreed upon by Swedish and German libraries
automated anonomyization important for European libraries for legal reasons (GDPR)
requests that are still on the hold shelf (item status awaiting pickup) should not be anonymized!
retaining patron information: taking loans as an example, patron group in a first implementation, deciding on department and custom fields later accordlingly to loan anonymization
circ log: patron barcode removed as it is in loans, some discussion about source field, this should not be the patron who made the request but third party API
display in requests app: anonymized requests should still be there, just without patron information
for better handling of long lists, having a date range filter would be useful
manual anonymization (discussion not finished): could be in the Actions dropdown menu, possibly greyed out for result lists that contain open requests
deleting a user who wants their data cleared is not a workaround! User information is not displayed on the requests detail page anymore, but in results lists and in request JSON
after changing a user’s barcode, only requests made with that specific barcode show up in a search - how this could be improved is another topic