Users App (UXPROD-784)

[UXPROD-2569] UM needs report of active borrowers in calendar year Created: 24/Jun/20  Updated: 20/Jun/23

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Users App

Type: New Feature Priority: TBD
Reporter: Ingolf Kuss Assignee: Amelia Sutton
Resolution: Unresolved Votes: 0
Labels: Folijet-UI-candiate, reporting, resourceaccess, usermanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by CIRC-828 Count active borrowers in calendar year Open
Relates
relates to CIRC-617 Support Reporting for Number of Activ... Open
relates to REP-260 UM needs report of active borrowers (... Open
relates to REP-23 General Information about the library Closed
Epic Link: Users App
Kiwi Planning Points (DO NOT CHANGE): 2
PO Rank: 0
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R5
Rank: Cornell (Full Sum 2021): R5
Rank: Duke (Full Sum 2021): R4
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R2
Rank: MO State (MVP June 2020): R2
Rank: U of AL (MVP Oct 2020): R1

 Description   

As a member of library management, I need to get the number of users who have borrowed at least one item within a calendar year.

More than 7000 German libraries count the number of active users (patrons with at least one loan in the reporting year) for Deutsche Bibliotheksstatistik (DBS) (German Library Statistics). DBS 2018 total numbers: https://service-wiki.hbz-nrw.de/download/attachments/99811335/dbs_gesamt_engl_2018.pdf?version=1&modificationDate=1564558387167&api=v2

Loan record deletion, patron record deletion

Many of them delete loan data when the item is returned or a few days or weeks after it is returned to comply with GDPR.

In addition the Right to erasure (GDPR Article 17) requires them to remove a patron record on request if all loans have been returned and all fees have been paid. Some libraries automatically delete the patron record of students that have left the university.

As some loan records and some patron records no longer exists at the end of the year the tenant's "active borrowers count" cannot be calculated at the end of the year, it has to be incremented when the loan is opened.

Therefore the tenant's "active borrowers count" needs to be incremented the first time a patron loans something in a year; at least one of these in-app counting algorithms are needed:

Date/Time and GDPR

European Court of Justice has ruled that date and time are "personal data" and are protected by GDPR. Therefore tenants need to evaluate which date/time components (year, month, day, hour, minute and seconds) they actually need and ensure that only the needed components are stored.

Judgment of the Court (Third Chamber), 30 May 2013 in case C-342/12: https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:62012CJ0342 After this judgment the European Parliament has moved the definition of "personal data" from Article 2 of Directive 95/46 to Article 4 of GDPR.

"further processing for [...] statistical purposes shall [...] not be considered to be incompatible with the initial purposes (‘purpose limitation’)" – Article 5 1. b) GDPR.

"Processing for [...] statistical purposes, shall be subject to appropriate safeguards [...]. ". Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner." – Article 89 1. GDPR

Active borrower flag algorithm

Remove the "active borrower" flag from all patron records on January 1st.
When opening a loan check the patron's "active borrower" flag.
If not active: Set to active and increment the tenant's "active borrowers count" of the current year.
If active: Do nothing.

Last loan date algorithm

The tenant can configure the "last loan date" granularity to be year, quarter or month (or full date+time if no GDPR compliance is needed).
When opening a loan update the "last loan date" of the patron record. Use this date:
If granularity is year use January 1st of the current year.
If granularity is quarter use the first day of the current quarter (January 1st, April 1st, July 1st, or October 1st).
If granularity is month use the first day of the current month.
When updating check the previous "last loan date" in the patron record.
If it is a date within the current year don't update the tenant's "active borrowers count". Otherwise (no "last loan date" or "last loan date" before the current year) increment the tenant's "active borrowers count" of the current year.
Some libraries also use the "last loan date" to delete patron records without any activity (no loan, no login) within a configurable number of years, quarters or months. Therefore this algorithm has the advantage to use one field for both purposes and avoids the additional "active borrower flag" field.



 Comments   
Comment by Sharon Beltaine [ 30/Jun/20 ]

Met with patty.wanninger to discuss building this in the UM app as a feature and she recommended we see if it is a better fit for the Resource Access Circulation Log. Next step will be for the Reporting Data Privacy subgroup to meet with Emma Boettcher to discuss possibilities. @Sharon to set up meeting with Ingolf, Vandana, Julian, and Nassib.

Comment by Sharon Beltaine [ 07/Jul/20 ]

Holly Mistlebauer will work on figuring out the next steps for this issue.

Comment by Holly Mistlebauer [ 08/Jul/20 ]

Holly met with Cate Boerema today and these are the next steps:

  1. Move UXPROD-2569 Open to the UXPROD project (done, it is now UXPROD-2569 Open )
  2. Clone UXPROD-2569 Open to create a CIRC user story (done, it is CIRC-828 Open )
  3. Have the Core: Functional team point the CIRC-828 Open user story (next week)
  4. Find out when this feature needs to be completed (Holly has asked Ingolf)
Comment by Holly Mistlebauer [ 08/Jul/20 ]

This feature needs to be completed in Q4 2020 at the latest...

Hi Holly!

We do not know the plans of all German implementers, yet.

But we already know that the feature "active borrowers count increment" will not be needed before January 1st, 2021.

I will inform you as soon as I can give you a more concrete date for that it will really be needed for the first time.
I hope that in the meantime it is O.K. for you to schedule it for Jan 1st, 2021.

Best,
Ingolf

Comment by Brooks Travis [ 11/Oct/20 ]

Having multiple active borrower counters (monthly, quarterly, semesterly, other custom, etc.), definable via settings could be very useful. The last loan date algorithm is probably the most generally useful method for accomplishing this feature.

Comment by Brooks Travis [ 12/Oct/20 ]

Ingolf Kuss In Sierra, the closest equivalent for "last loan date" would be the "CIRCACTIVE" fixed field on the patron record, but that also accounts for renewals, requests, checking your account via the catalog or another API interface (eg. discovery), or using SIP2 checkout. Do those need to be accounted for in this stat, as well, or do we just care about new loans? I would think having this attribute present on the user record would be very helpful in a mid-year migration, too.

Comment by Ingolf Kuss [ 13/Oct/20 ]

Hi Brooks Travis, renewals are not counted in DBS 4 (this report). (They are counted in DBS 170).
Request are also not counted here (but in DBS 172).
If you mean by "checking your account" just looking at it (e.g. checking my open loans via a discovery), that would not be counted here.
If you check out by SIP2, I would say that would be a checkout which would create a new loan in the ILS and would be counted here.
DBS 4 is actually only about new loans.

Comment by Kristin Martin [ 04/Feb/21 ]

Hi Ingolf Kuss, from our Chicago RA folks, "We don't currently need a report like this, though having something like "Last CKO date" might be useful (if that doesn't already exist)." So we've ranked this R5. Let us know if there is something out there for the Last CKO date. Thanks.

Comment by Molly Driscoll [ 14/Sep/21 ]

Have there been any recent developments on this feature, patty.wanninger? Are there plans for a last activity date on the user record?

Comment by Ann-Marie Breaux (Inactive) [ 19/Nov/21 ]

Hi patty.wanninger There's no mockups for this. Do you have some? Also, while there's lots of description, there's not really clear scenarios for the UI devs

Comment by patty.wanninger [ 03/Dec/21 ]

Ann-Marie Breaux I will take this back to the SIG and get some wireframes.

Comment by Brooks Travis [ 09/Dec/21 ]

Julian Ladisch patty.wanninger Would using a one-way hash of the user UUID with the date-based counter be sufficient to satisfy GDPR, since all we care about is the count of users, not the actual users? The only way you could deanonymize would be to run every user UUID through the same hashing algorithm and if the user has been deleted you wouldn't even be able to do that. Otherwise, I don't really see a way to reliably provide this data (reliably) AND comply with GDPR.

Comment by Julian Ladisch [ 10/Dec/21 ]

The UUID (id of user record) is already a pseudonymisation. A hash of that UUID is a pseudonymisation of the pseudonymisation and therefore is not exempted from GDPR. Most users records don't get deleted and therefore this is not anonymisation, only pseudonymisation, and pseudonymisation reduces risk but GDPR still applies.

For a given user simply hash the UUID and you get last loan date.

Therefore I don't see how the additional hashing can give significant advantages to be an "appropriate" safeguard and "appropriate" measure.

Can you explain why the "last loan date algorithm" doesn't comply with GDPR?

Generated at Fri Feb 09 00:25:03 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.