Loans (UXPROD-788)

[CIRC-828] Count active borrowers in calendar year Created: 08/Jul/20  Updated: 12/Oct/23

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:
Defines
defines UXPROD-2569 UM needs report of active borrowers i... 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
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 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:

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.
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 Marc Johnson [ 16/Jul/20 ]

Julian Ladisch Cate Boerema

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 seems like a reporting activity, why does the transactional part of FOLIO need to do this?

This has been considered and pondered by the reporting SIG, the Reporting Data Privacy subgroup and the User Management SIG ( UXPROD-2569 Open , REP-260 Open ). The reasoning and the result has been explained in detail in the "Loan record deletion, patron record deletion" section of this issue's description. Can you explain why the decision to implement it in the transactional part (as it is in existing systems like OCLC Pica LBS) might be wrong?

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 UXPROD-2569 Open )

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

  • The count should include patrons who acted as borrowers yet whose user record has subsequently been deleted following a request to be erased (has this been implemented?)
  • The count should include patrons who acted as borrowers yet whose user record has subsequently been deleted for other reasons
  • The count should include patrons whose loans have since been anonymized (removing the relationship between the loan and the patron)

Timeline

Some libraries need this to be usable in production by the 1st January 2021

Questions

  • Given the privacy constraints, how are these figures verified as accurate by the library or external body?
  • How is this information to be used if it the counter is reset immediately after the end of the period (as stated in the active borrower flag algorithm section)? Is the intention that multiple periods are remembered for posterity?
  • The last loan date algorithm section refers to a last loan date property for a user, is the intention that this feature would introduce that property?
  • Is the use of active when referring to a patron shorthand for a new active borrower property, or is this feature intended to disable users (which would stop them borrowing)?
  • This issue is related to REP-260 Open which asks for a list of patrons, is this possible, given the privacy constraints expressed within this issue?
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.
"counter reset": A tenant's "active borrowers count" entry consists of a year and a count. When the first loan of a year is opened the software creates a new entry with count 1, all following loans opened increment it. The tenant's "active borrowers count" entries of past years are kept forever.
"last loan date": This is a new patron property that this story introduces.
"active": Active in scope of this feature refers to patrons that open loans (active borrowers). It does not refer to the "active" property of the user record. This story is about collecting the user's "last loan date" and the tenant' "active borrowers count" statistics; there should be a front-end feature for displaying them. Triggering further actions (for example disabling users after some time without loans) is out of scope of this story.
REP-260: This story ( CIRC-828 Open ) uses a single predefined reporting period (calendar year) and allows loan records and user records being anonymized and deleted during the reporting period. In contrast REP-260 Open allows to query any reporting period (no predefined reporting period) and therefore needs to keep the loan and user data – this is for institutions with less strict data privacy requirements than most German/GDPR libraries.

Comment by Marc Johnson [ 31/Jul/20 ]

Julian Ladisch Thank you for your follow up comments

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.

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?

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.

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?

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.

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
Yes

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?
GDPR requires the library not to store those parts of the full date that is not needed. Some non-GDPR libraries probably want to store full date (year, month, day), or date+time; this may be added to the list of possible granularity options in this story or at a later time.

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 ]

Julian Ladisch

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.

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.

GDPR requires the library not to store those parts of the full date that is not needed.

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 ]

that is always between 1st January and 31st December, which surprises me a little given these are academic libraries

This is for reporting and the German DBS statistics reports always per calendar year.

Comment by Marc Johnson [ 03/Aug/20 ]

Ingolf Kuss

This is for reporting and the German DBS statistics reports always per calendar year.

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

  • Loans may be anonymized (disassociated from the patron) at any point after they are closed
  • Patrons may be deleted at any point during a calendar year, if they have no open loans and no open fees or fines
  • Reporting may not have access to loans prior to anonymization and/or deleted patrons and so may not perform this calculation
  • Only the year in which the patron is active may be stored and not when the patron last borrowed an item, due to GDPR compliance

General Process

  • Given a patron who has not borrowed an item during this calendar year
  • When the patron borrows an item
  • Then they are marked as an active borrower for that calendar year
  • And the overall active borrower count for that calendar year is incremented
  • Given a patron who has already borrowed an item this calendar year
  • When the patron borrows another item
  • Then the overall active borrower count for that calendar year is not incremented
  • Given a patron who has already borrowed and returned an item during this calendar year
  • And that loan has been annonymized
  • When the patron borrows another item
  • Then the overall active borrower count for that calendar year is not incremented
  • Given a patron who has already borrowed an item during this calendar year
  • When the patron is deleted
  • Then the overall active borrower count for that calendar year is not incremented or decremented
  • Given a patron who has not borrowed an item during this calendar year
  • When the patron is deleted
  • Then the overall active borrower count for that calendar year is not incremented or decremented

Options

Whether a patron has been an active borrower could be remembered either by:

  • marking them as an active borrower; all patrons become inactive at the beginning of the calendar year
  • marking them as an active borrower within a particular calendar year

Questions

  • Is a borrower active if they have an outstanding loan that crosses between calendar years?
  • Is a borrower active if they renew an outstanding loan such that it extends into the new calendar year?
  • Is a borrower active if they renew an outstanding loan during a different calendar year?
  • Which German libraries are going to have circulation in production use by 1st January 2021?
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:

How is this information to be used if it the counter is reset immediately after the end of the period (as stated in the active borrower flag algorithm section)? Is the intention that multiple periods are remembered for posterity?

Comment by Zak Burke [ 03/Aug/20 ]

Given a patron who has already borrowed and returned an item during this calendar year
And that loan has been annonymized
When the patron borrows another item
Then the overall active borrower count for that calendar year is not incremented

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 ]

How is this information to be used if it the counter is reset immediately after the end of the period (as stated in the active borrower flag algorithm section)? Is the intention that multiple periods are remembered for posterity?

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 ]

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).

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 ]

If the first loan has been anonymized, how is possible to track that this patron is borrowing another item?

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.
I can already answer the 4th question:

Which German libraries are going to have circulation in production use by 1st January 2021?

No German library will use Circulation in production by Jan 1st, 2021.

Comment by Marc Johnson [ 03/Aug/20 ]

Ingolf Kuss thanks

No German library will use Circulation in production by Jan 1st, 2021.

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 ]

Zak Burke Ingolf Kuss

If the first loan has been anonymized, how is possible to track that this patron is borrowing another item?

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

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.

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 ]

Cate Boerema

How is this information to be used if it the counter is reset immediately after the end of the period (as stated in the active borrower flag algorithm section)? Is the intention that multiple periods are remembered for posterity?

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 ]

Ingolf Kuss

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).

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.

The tenant's "active borrowers count" entries of past years are kept forever.

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.
Concerning the needs of German libraries, it is complicated. The early implementers are all "ERM-focused" and won't use Circulation at first. At least one library will use Circ in early 2021, but does not take part in the DBS survey. So, the question is about "Circ AND DBS". Leipzig won't use LDP (and thus reporting) plus Circ (full implementation) "within the next two years". – I am doing another survey to the German libraries about "Circulation and Reporting" and will post the result here.

Comment by Ingolf Kuss [ 03/Aug/20 ]

Marc Johnson

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.

Yes, I agree.

Comment by Marc Johnson [ 03/Aug/20 ]

Ingolf Kuss

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.

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.

Concerning the needs of German libraries, it is complicated. The early implementers are all "ERM-focused" and won't use Circulation at first. At least one library will use Circ in early 2021, but does not take part in the DBS survey. So, the question is about "Circ AND DBS". Leipzig won't use LDP (and thus reporting) plus Circ (full implementation) "within the next two years". – I am doing another survey to the German libraries about "Circulation and Reporting" and will post the result here.

Thank you for being willing to investigate this further and come back to us.

Comment by Ingolf Kuss [ 03/Aug/20 ]

Marc Johnson

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.

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".

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?

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 "active borrowers count" entries of past years are kept forever.

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 ]

Ingolf Kuss

I think the "last loan data algorithm" should not be used because 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.

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 REP-260 Open ).

(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 ]

Marc Johnson,

Questions

Is a borrower active if they have an outstanding loan that crosses between calendar years?
Is a borrower active if they renew an outstanding loan such that it extends into the new calendar year?
Is a borrower active if they renew an outstanding loan during a different calendar year?

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 ]

Ingolf Kuss

In all three cases the answer is "No". Neither of this makes the borrower "active" or "recent" in the current calendar year.

Thanks for answering my questions

Comment by Ingolf Kuss [ 05/Aug/20 ]

Hi Marc Johnson,

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?

As I said, I asked our DPO about that and here is the answer (thanks to Google translator):

In principle you can save the date of the last loan if you use it e.g. want to calculate a retention period for information or the validity of accounts.

You can only save as much information as long as is necessary. E.g. if I need information about a loan for one year, e.g. to calculate the validity of an account (e.g. the validity of the account could be extended to one year with each loan), then you probably need the full date.

If you want to delete something after 3 years, the month and the year could be enough. If you want to delete something after 10 years, it might be enough at the end of a quarter / half-year or even at the end of the 10th year. The less information you store, the better it is for the protection of the data subject's personal data (in this case: loan date) - you always have to weigh your own purpose against the interests of those affected according to informal self-determination.

I.e. It always depends on the purpose, what you can save and for how long - the purpose must of course be legitimate.

If one stores such information, it must be pointed out in the terms of use or the data protection information.

Of course, these answers concern the live system, but the question is then for what purpose this information should be saved permanently in a report - this will then be problematic.

I hope that answers your questions - in data protection, unfortunately, this cannot be answered unambiguously, since there are no statutory retention periods for this information from the loan.

Comment by Marc Johnson [ 10/Aug/20 ]

Ingolf Kuss Thank you for the additional research. Apologies for the delay in responding.

In principle you can save the date of the last loan if you use it e.g. want to calculate a retention period for information or the validity of accounts.

It always depends on the purpose, what you can save and for how long - the purpose must of course be legitimate.

This is more aligned with my understanding of data protection and GDPR regulation.

If one stores such information, it must be pointed out in the terms of use or the data protection information.

This is why I think this decision really needs to be made very explicitly by the SIGs / POs for FOLIO and documented.

in data protection, unfortunately, this cannot be answered unambiguously, since there are no statutory retention periods for this information from the loan.

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!

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