DCB-1661 Polaris virtual patron analysis

This page documents the current state of the DCB Service's patron search functionality within Polaris library systems. The goal is to improve the reliability of finding virtual patrons and explore the viability of deleting them.

Scope: This document focuses solely on Polaris LMS.

Current Polaris Patron Methods

Finding Virtual Patrons

The DCB Service utilizes the PAPI Service API method "Patron Search" to locate virtual patrons. This method relies on the "PATNF" field (Name - First, Middle, Last) and the "real" patron's barcode. Documentation for this API can be found here: PatronSearch

Creating Unique Virtual Patrons

The DCB Service creates virtual patrons using the "PatronRegistrationCreate Version 1" method within the PAPI Service API. Details and request body example can be found here: PatronRegistrationCreate Version 1

Patron Field Usage in DCB Polaris Patron Creation

PatronBranchID:

  • Usage: Specifies the item location ID.

  • Source: Derived from the items assigned branch ID.

NameFirst:

  • Usage: Stores the original patron's barcode.

  • Source: Extracted from the original patron's information.

NameLast:

  • Usage: Stores the UniqueID[0] value, a combination of the local patron ID and agency code.

  • Source: DCB constructed.

PatronCode:

  • Usage: Specifies the local patron type.

  • Source: Mapped from the original patron type.

Barcode:

  • Usage: Generates a unique barcode for the virtual patron.

  • Formula: Prefix (from configuration) + Original Patron Barcode

Birthday (Required):

  • Usage: A mandatory field in Polaris.

  • Value: A fixed date "1999-11-01".

Potential Issues with Patron Search

Missed Patrons

Ambiguous Matches

False Positives

  • There's a possibility of finding the wrong virtual patron due to limitations in barcode-based searching. If the initial search returns a single (incorrect) match, the DCB Service might proceed with that patron, potentially leading to issues with supplier-side requests.

Improving Patron Search Reliability

Addressing Ambiguity

  • Leverage Unique Identifiers that DCB currently holds such as; Existing Local patron ID (Patron Identity), DCB’s Patron UniqueId and DCB Patron UUID.

  • Expand the search criteria to include checks when multiple patrons are found to improve accuracy and reduce ambiguity.

  • Implement a strategy to validate exact matches by cross-checking multiple criteria, helping to minimise false positives.

Improving Diagnostics

  • Enhance patron search logging to capture specific details about search failures, including search criteria, results, and potential reasons for mismatches.

  • Monitor the performance of patron search queries to identify success rate/failure rate.

  • Develop more rigorous testing strategies for testing current known issues.

Identifying DCB Virtual Patrons

  • Consider using the PATNL field to search by DCB’s Patron Unique Id.

  • Consider using the existing Patron identity local ID if it already exists in DCB.

  • A script querying the patron barcode prefix can potentially identify all virtual DCB patrons that exist in a local Polaris system. 

Assessing the Viability of Virtual Patron Deletion

Prerequisites

  • A reliable patron search mechanism is essential to accurately identify and target virtual patrons for deletion.

  • Conduct a thorough impact assessment to understand the potential consequences of deleting virtual patrons, including data loss and system disruptions.

Key Considerations

  • In-Flight Requests: Identify and address any in-flight requests associated with the virtual patron before deletion.

  • Data Retention Policy: Establish a clear data retention policy to determine how long virtual patron records should be retained before deletion.

  • Backup and Recovery Strategy: Develop a robust backup and recovery strategy to minimise data loss risks associated with deletion.

  • Testing and Pilot: Implement a phased approach with rigorous testing and a pilot program to evaluate the feasibility and impact of virtual patron deletion.

Outstanding questions:

  • How can we ensure that the correct UniqueId is used from the list of UniqueId's that DCB stores to find the virtual patron? I.e., the UniqueId stored on the virtual patron record matches the one DCB chooses to search by.

  • Are local patron IDs reused in Polaris? If so, could this lead to matching the wrong patron?

  • Which field in the patron record would be best suited for storing our chosen unique identifier? Is the PATNL field a valid option? Which is currently in use.

  • If multiple virtual patrons are found, what criteria should we use to identify the correct one?

  • What cross-checking criteria can we apply to minimise the risk of false positives?

 

Related Issues

 

Operated as a Community Resource by the Open Library Foundation