- Sharing our catalogue data is relatively easy: the data standards are well-established and most the data itself is published in the public domain on library OPAC's, etc. Which doesn't mean that it was all plain sailing and we've not got some more work to do.
- Sharing borrower data is obviously fraught with all sorts of information governance and data protection issues on top of the problem that there isn't any data standard save that imposed by the structure of our shared LMS and the commonalities we've discussed and agreed on a case-by-case basis.
- Virtually every circulation dataset is a back door into the borrower data.
I've been thinking through some of the questions we need to be asking ourselves on this journey. It's still early days so isn't exhaustive; at this stage I'm trying to work out what we need to worry about at a general level prior to starting work on a risk analysis.
I'd be interested to know if/how this analysis sits with the experience of established consortium libraries, especially if I've missed something that could cause us problems.
Purpose | Type of Information | Recipients | Data Controller | Notes/queries |
Membership information including contact details –voluntary service, customers will be asked if they want to opt in | Customer name, address and contact information, DOB. Disability, ethnicity and other demographic details Family relationship details Lending history |
Library staff (including all other authorised Spydus users) of approved Authorities within the scheme | Local Authority (Data Subject’s Local Authority will be the data controller) |
Which data is to be shared? Is it all or nothing?
Same question applies to who the data is being shared with
How do we switch sharing on/off?
What happens to the data held in loans, charges and reservations? What happens to any outstanding loans, fines and charges? Who owns (and is responsible for) the data? |
Loans information | Details of the loan including borrower, item, location and status of loan. Loans history |
Library staff Specific customers can see all details of their loan(s) All customers can see some details of the loan(s) |
Local Authority (which?) |
This is the crucial element to be managed:
There is a hierarchy of viewing permissions If a customer has said “no” to data-sharing, how is the borrower data in the loan, charges and reservation records expressed?
Who owns (and is responsible for) this data? Whose loan policies?
|
Overdue/pre-overdue notices | Contact details including borrower name, address, telephone and email; loan due dates and items involved | Library staff Specific customer |
Local Authority (which?) | Derived from loans data and subject to same questions It would make sense to aggregate these to improve efficiency and save costs (see notes on charges, etc.) |
Reservations | Contact details including borrower name, address, telephone and email and items requested | Library staff Specific customer |
Local Authority (which?) |
All the questions for loans apply for reservations (which are effectively loans-in-waiting) Whose charge régime applies? Would the Data Controller be the “owner” of the customer record, the library that placed the reservation or the library it will be picked up from (if a different library authority)? |
Requests | Contact details including borrower name, address, telephone and email and items/articles requested | Library staff Specific customer ILL system (bibliographic and/or article data only) |
Local Authority (which?) |
In nearly all respects as reservations, just more complicated charges [The operating procedures would probably need modifying in the light of the shared lending environment.] This will need to be revised in the event of a fuller integration with UnityWeb or equivalent third-party systems |
Notifications for any reserved items | Contact details including borrower name, address, telephone and email and items requested | Library staff Specific customer |
Local Authority (which?) |
Derived from reservations/requests data and subject to the same questions It would make sense to aggregate these to improve efficiency and save costs (see notes on charges, etc.) |
Charges/fines/fees | Contact details including borrower name, address, telephone and email; details of the transaction that generated the charge | Library staff Specific customer |
Local Authority (which?) |
Derived from loans and reservations/requests data and subject to the same questions How will these be managed:
In the event of recovery, who legally owns the charge? In the light of the above, what would be the effect (if any) of aggregated notices? |
Catalogue/ discovery records — bibliographic data | Title-level catalogue data | Library staff Library customers and general public |
Local Authority (which?) |
Bibliographic data – already shared data Don’t forget that there is a link to the borrower record from the review/rating in the bib data in Staff Enquiry
(Not all data are published for the public) |
Catalogue/discovery records — holdings/item-level data | Catalogue data, including electronic holdings | Library staff Library customers and general public |
Local Authority (Which?) |
Holdings data Links to personal data via loans/loan history and status/status history
(Not all data are published for the public) |
Management Information/ Business Intelligence | Reports detailing usage of service, per location | Library Managers | Local Authority (Data Subject’s Local Authority will be the data controller) |
Essentially should be summary data, though we’d need to have safeguards against breaches caused by very small sample data Proper safeguards and risk analyses are required before making this data available to third parties |
Demographic breakdowns | Library Managers Designated authorised analysts |
Local Authority (Data Subject’s Local Authority will be the data controller) |
Most would be summary data, though we’d need to have safeguards against breaches caused by very small sample data Some data (e.g. lists of postcodes) are granular enough to easily identify Data Subjects so safeguards need to be in place on the use and presentation of this data are required before making this data available to third parties |
|
Marketing databases | Library Managers Designated authorised marketing staff |
Local Authority (Data Subject’s Local Authority will be the data controller) | Is the “I agree to receive marketing” (or equivalent) field global or local? The selection of data explicitly must be limited to those customers who have agreed to contact so as to comply with Privacy and Electronic Communications Regulations. Proper safeguards and risk analyses are required before making this data available to third parties |
|
Stock management data | Library staff Designated authorised third-party service providers |
Local Authority (which?) | Nothing pertaining to Data Subjects should be included in this data. Stock ownership should be straightforward. Stock usage more problematic:
In the early days at least there will be pressure to be able to provide evidence that stock is being used “fairly” with local library customers having first dibs for local stock |
|
Ad hoc data requests | Library Managers Designated authorised third parties |
Local Authority (Data Subject’s Local Authority will be the data controller) | Most would be summary data, though we’d need to have safeguards against breaches caused by very small sample data Some data (e.g. lists of postcodes) are granular enough to easily identify Data Subjects so safeguards need to be in place on the use and presentation of this data Proper safeguards and risk analyses are required before making this data available to third parties FoI requests would be subject to the proper exclusions |
|
SIP2 data | Data used for interfacing between Spydus and third-party systems | Library staff Specific customer |
Local Authority (Data Subject’s Local Authority will be the data controller) | The particular case at the moment would be where data held in the customer record determines the access or not to third-party systems and services.
|
I'd be interested to know if/how this analysis sits with the experience of established consortium libraries, especially if I've missed something that could cause us problems.
No comments:
Post a Comment