Loans
(UXPROD-788)
|
|
| Status: | Open |
| Project: | mod-circulation |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Loans |
| Type: | Story | Priority: | P3 |
| Reporter: | Julian Ladisch | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | reporting, resourceaccess | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||
| Development Team: | Vega | ||||||||||||||||||||||||
| Epic Link: | Loans | ||||||||||||||||||||||||
| 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 deletionMany 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: Active borrower flag algorithmRemove the "active borrower" flag from all patron records on January 1st. Last loan date algorithmThe tenant can configure the "last loan date" granularity to be year, quarter or month. |
| Comments |
| Comment by Marc Johnson [ 16/Jul/20 ] |
|
This seems like a reporting activity, why does the transactional part of FOLIO need to do this? |
| Comment by patty.wanninger [ 16/Jul/20 ] |
|
This functionality was presented to the User Management SIG as a requirement from the Reporting SIG because, as I understand it, at this time the LDP cannot properly anonymize user data and this report is needed by particularly German libraries so the functionality is on the FOLIO side. Is that correct Ingolf Kuss and Sharon Beltaine? |
| Comment by Julian Ladisch [ 17/Jul/20 ] |
This has been considered and pondered by the reporting SIG, the Reporting Data Privacy subgroup and the User Management SIG (
|
| Comment by Marc Johnson [ 21/Jul/20 ] |
|
patty.wanninger Julian Ladisch Cate Boerema Sharon Beltaine Emma Boettcher (including additional folks due to involvement in the conversation on
Firstly, apologies for my rushed comment on this issue, it was inappropriate and disrespectful of the work that has already gone into this feature. The Core Functional team tried to estimate this story in a recent refinement session and found itself unable to follow the story sufficiently to do so. With that in mind, I'm going to try to reflect my current understanding of this work, to try to reconcile that, before we move on with that effort. I'd appreciate your feedback on whether my summary below matches your understanding and expectations. Need Libraries need to know how many patrons have borrowed at least one item within a configurable period of time Time Period The reporting periods for this information could be a month, quarter or year Constraints
Timeline Some libraries need this to be usable in production by the 1st January 2021 Questions
|
| Comment by Cate Boerema (Inactive) [ 30/Jul/20 ] |
|
Holly Mistlebauer can you please respond to Marc Johnsons questions above so we can keep progressing on this? |
| Comment by Julian Ladisch [ 31/Jul/20 ] |
|
The tenant's "active borrowers count" reporting period is calendar year only. This period is required by many German libraries. A different granularity of tenant's "active borrowers count" (for example quarter) and a different start of the year (for example fiscal year starting in July) for the tenant's "active borrowers count" is out of scope of this issue and may be added at a later time. While for now the tenant's "active borrowers count" reporting period is only calendar year the "last loan date" of the patron record has a configurable granularity. "verified as accurate": Verification of live data is neither needed nor possible. We assume that the software counts correctly, tests with test data can be executed to prove that this is true. |
| Comment by Marc Johnson [ 31/Jul/20 ] |
|
Julian Ladisch Thank you for your follow up comments
I'm aware that you (and folks like Holly Mistlebauer patty.wanninger and Sharon Beltaine) have much more context about this work than I do. I think I'm finding it challenging to understand the scope of this work, as the story seems to mix multiple concerns together to me. Is the scope of this feature to store an active borrowers count by calendar year, in order for German libraries to comply with local regulations?
Does that mean that 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. is not relevant to this story?
Why is there a granularity for the last loan date? Why could this not be changed for every loan to the actual loan date irrespective of any reporting granularity? |
| Comment by Julian Ladisch [ 31/Jul/20 ] |
|
> Is the scope of this feature to store an active borrowers count by calendar year Some libraries also use the "last loan date" to delete patron records without any activity. This is only relevant to this story when deciding which of the two algorithms to implement. The functionality of the Active borrower flag algorithm cannot be reused, whereas the Last loan date algorithm has the advantage to implement functionality that is needed for deleting stale patron records. For me this advantage is worth the additional complexity of the last loan date. > Why is there a granularity for the last loan date? If granularity is year both algorithms are almost the same. Some libraries need a different granularity for other purposes. |
| Comment by Marc Johnson [ 03/Aug/20 ] |
Thank you for clarifying that trade off and why this information is relevant to this work. That did not come across clearly to me in the description.
I'll admit to being really surprised that the full date would be considered too much information from a GDPR perspective. Is there any reference material you can refer to for that policy? This strictness suggests that for this initial work that the last loan date should always be only a year. As the focus is on regulatory compliance for the German libraries and their needs are only about a whole calendar (that is always between 1st January and 31st December, which surprises me a little given these are academic libraries). Have I interpreted that correctly? |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
This is for reporting and the German DBS statistics reports always per calendar year. |
| Comment by Marc Johnson [ 03/Aug/20 ] |
Thank you for confirming this. |
| Comment by Marc Johnson [ 03/Aug/20 ] |
|
Thanks to Julian Ladisch and Ingolf Kuss who have patiently answered my questions. Below is a summary of my understanding of this work. I would appreciate feedback from folks, both in terms of whether it is a clear description and that it fits your understanding of the work. I would especially like feedback on the requirements from Holly Mistlebauer patty.wanninger Sharon Beltaine Cate Boerema Ingolf Kuss Emma Boettcher and Julian Ladisch who likely understand the domain better than I. I would especially like feedback on the clarity of description from Zak Burke and Cate Boerema given it is likely that the Core Functional team is going to be asked to develop this, and when we last tried to discuss it we found we could not understand it sufficiently. Audience German libraries needing to comply with GDPR and with regulatory requirements from Deutsche Bibliotheksstatistik (DBS). Scope To remember the count of the active borrowers for each calendar year (irrespective of anonymization or erasure). A patron (users in FOLIO) becomes an active borrower when they borrow their first item within in a calendar year. Timelines This needs to be in production use within German libraries by 1st January 2021. Which means that development must be completed with 2020 Q3 Constraints
General Process
Options Whether a patron has been an active borrower could be remembered either by:
Questions
|
| Comment by Cate Boerema (Inactive) [ 03/Aug/20 ] |
|
Thank you for writing this up so clearly, Marc Johnson. It seems sensible to me, but I will defer to others who are more familiar with the functional need. I just want to be clear that, when we are talking about borrowers being active or not, we are not talking about the standard user status = active/inactive? This is a separate flag, right? if it is, indeed, separate, we should try to use different language to avoid confusion. For example, we could say "Active borrower = Yes" instead of "Borrower = Active" (or something along those lines). Also, I think Holly Mistlebauer mentioned to me that this flag would only be set on the back end (nothing displayed in the UI). Did I get that right? Finally, Marc Johnson, did you get an answer to this question:
|
| Comment by Zak Burke [ 03/Aug/20 ] |
If the first loan has been anonymized, how is possible to track that this patron is borrowing another item? |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
The active borrower flag on the patron is only needed for the current calendar year. Whether this patron was active or inactive in previous years does not need to be remembered (an, in fact, it _must _not be remembered because of data privacy). |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
Cate Boerema, yes, that is a separate flag. Users with user status "inactive" can not make a loan or a check-out nor a loan request. So, they are in a dfferent state than an "active" user who has just not made a loan, yet, in this year. I agree that the language is confusing. The "inactive" users might be called "deactivated", instead. Or we might call the new flag not "active borrowers" but "recent borrowers", for example. |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
Zak Burke, first, I don't know what you mean by "the loan has been anonymized". As far as I know, anonymization takes place in the LDP, not in the circ app. Secondly, the "active borrower" flag (or call it "recent borrower" flag) belongs to the patron data, not to the loan data. |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
|
Marc Johnson, I am trying to answer all your questions of 4 hours ago and gave them to a DBS guru.
No German library will use Circulation in production by Jan 1st, 2021. |
| Comment by Marc Johnson [ 03/Aug/20 ] |
|
Ingolf Kuss thanks
My understanding was that this work was considered a high priority change for the German libraries for compliance reasons. Cate Boerema Holly Mistlebauer patty.wanninger If none are going to be in production using circulation at the start of the next calendar year, please could someone explain to me the urgency of this change? |
| Comment by Cate Boerema (Inactive) [ 03/Aug/20 ] |
|
Thanks Ingolf Kuss! I really like the idea of calling this flag "Recent borrower". If no German library will use Circ in production by Jan 1st, 2021, does this mean we have more time to make this change? When do the first German libraries plan to use Circulation in production? |
| Comment by Marc Johnson [ 03/Aug/20 ] |
Good question. This was deliberately left a little vague in that process, as it relates to the options. My understanding is that the presence of either the active / recent borrower flag or an indicator that the patron had borrowed an item in a given calendar year implies to the system that the patron has borrowed previously in the current calendar year, irrespective of the loans for that patron. That is what I have deciphered from the description and my questions answered by Julian Ladisch and Ingolf Kuss
In FOLIO anonymization is done entirely within the transactional part of the system, the LDP plays no part in it (though it might also need to react the to the fact that the loan has been anonymized, otherwise it might undermine the intent). |
| Comment by Marc Johnson [ 03/Aug/20 ] |
I asked this question prior to some of the understanding I've gained from Julian Ladisch and Ingolf Kuss answers. I think we are still exploring this |
| Comment by Marc Johnson [ 03/Aug/20 ] |
That is interesting. My interpretation from Julian Ladisch previous answers was that he considered either the last loan date or active / recent borrower algorithms (to use his terms) to be equivalent, yet the former can be also used for more in-depth and longer term reporting. That seems to be conflicting with your statement above, which suggests that any last loan date (which can only be the year, for German libraries) older than the current calendar year must not be kept and should be removed. Is that the case? If so, that would make keeping only the year portion of that information no more useful than a flag that is reset at the beginning of every calendar year.
Is this the case, or does the overall count also have to be deleted once the count has been submitted to the authorities? |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
|
I think there has been a misunderstanding in priorization of this issue. I don't think this has high urgency in the sense that it needs to be part of the December 2020 release. This has appeared in-app in Circ now, because we noticed that we can not do this as an LDP report. This is why it appeared here now, not because of urgency. Or at least I don't know who set the priorizations. |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
Yes, I agree. |
| Comment by Marc Johnson [ 03/Aug/20 ] |
I don't know either, only that it arrived for my team to estimate due to IIRC it needing to be done by the end of this year. I'll admit to being confused as to the need for analysis, let alone design, prior to knowing the importance / urgency of the feature.
Thank you for being willing to investigate this further and come back to us. |
| Comment by Ingolf Kuss [ 03/Aug/20 ] |
I was also confused about this. I think the point of the last loan date algorithm is that is has "higher granularity", which means that it can be the base of reports for different reporting periods (a quarter year, half a year etc.). But I understood that later on, Julian Ladisch says that the higher granularity is not needed for DBS 4 (this issue), so I only commented on the "recent borrower flag algorithm".
I think the "last loan data algorithm" should not be used beacuse of privacy reasons, yes. But I will check with a DPO if this is really the case. I know that German libraries do not keep a loan history, only the latest (active) loan of a borrower. So, consequently, any last loan date should be removed. Actually, I see no reason to implement the "last loan date algorithm", once the "recent borrower flag algorithm" has been implemented.
The tenant's count can (and should) be kept forever, because it contains no personal data (it is an aggregate count). |
| Comment by Marc Johnson [ 03/Aug/20 ] |
Firstly, thank you for clarifying this with the DPO. I'll admit I was a little bit surprised when it was revealed that the last loan date in it's entirely was considered too much information to keep about a patron under GDPR and that only the year could be kept. When you then suggested that could only be the current year, I agree that the two algorithms become identical in both implementation and granularity of information. Which suggests to me that rather than there being complementary work here, it raises questions to me about how FOLIO will implement both algorithms side by side effectively (if my understanding from Julian Ladisch is correct, about
(Aside: I tried to learn about library policies in general in this area, by reading some of Alma's documentation, and came away a little confused. I do find it interesting that the policies in place for libraries seem much stricter than what many retailers apply, who seem to keep many years of purchase history on record) |
| Comment by Ingolf Kuss [ 04/Aug/20 ] |
In all three cases the answer is "No". Neither of this makes the borrower "active" or "recent" in the current calendar year. |
| Comment by Marc Johnson [ 04/Aug/20 ] |
Thanks for answering my questions |
| Comment by Ingolf Kuss [ 05/Aug/20 ] |
|
Hi Marc Johnson,
As I said, I asked our DPO about that and here is the answer (thanks to Google translator):
|
| Comment by Marc Johnson [ 10/Aug/20 ] |
|
Ingolf Kuss Thank you for the additional research. Apologies for the delay in responding.
This is more aligned with my understanding of data protection and GDPR regulation.
This is why I think this decision really needs to be made very explicitly by the SIGs / POs for FOLIO and documented.
I really sympathise with this. I still find it fascinating that loans in a library context are considered so differently to purchasing an item. |
| Comment by Holly Mistlebauer [ 03/Oct/20 ] |
|
Cate Boerema and Ingolf Kuss: What is the latest status on this? |
| Comment by Cate Boerema (Inactive) [ 05/Oct/20 ] |
|
Hi Holly Mistlebauer. I had to re-read the comments here to refresh my memory on where this stands. Basically, I think there are a number of open questions still about design and priority of this feature. I don't have time to PO this feature. If you don't either, I think we should tap Emma Boettcher or patty.wanninger to see if they can derive a clearer picture of what needs to be done and by when. |
| Comment by Holly Mistlebauer [ 05/Oct/20 ] |
|
Cate Boerema: I definitely don't have time. I will put it on the agenda for Friday's CIRC PO meeting. Thanks! |