Context:

The Library of Congress (LoC) requires functionality to manage patron registration via a web-based form and integrate the data into FOLIO’s Users app. This feature will create new user records for patrons categorized as "distance patrons," who initially have no circulation privileges. When these patrons come onsite, their registration details will be verified, and their patron group will be updated to provide access to circulation privileges, reading rooms, and physical card issuance, featuring a profile picture..

While LoC needs this feature, it will likely be useful for other libraries (especially public and national).  The solution should be designed flexibly to accommodate libraries with similar requirements.

Purpose:

This feature, split from , addresses remote patron registration and the creation of LoC patron user records in FOLIO.

LoC patron registration workflow:

• A patron completes the pre-registration form online.

• Pre-registration patron data is processed and stored in the FOLIO.

• The patron visits the LoC in person to complete the registration process.

• Library staff verifies the patron's identity, updates registration data, captures a photo, and issues a library card.

Use Cases:

1. As a LoC patron, I want to fill out a registration form online, so that LoC has all the necessary data to create my full patron record when I visit onsite.

2. As a LoC registration staff, I want to search for a patron’s pre-registration record in FOLIO, verify their identity, and complete their registration, so that the patron can access the library’s services.

3. As a LoC patron, I want to register directly using a self-service kiosk at the Library of Congress, so that I can quickly complete my registration and receive my library card.

Mockups:

Out of scope:

• Validation of mandatory preregistration data. Data validation on mandatory preregistration fields will be part of the UI Locate implementation (agreed with Vijay).
  LC Reader Registration: Patron Photo Capture

• LC Reader Registration: Export User Data needed to for Library Card Printing

Proposed solution:

This feature involves a two-tiered patron registration process, allowing patrons to begin the registration process online in Locate and complete it onsite in FOLIO. The design separates the initial registration data from the final patron record by using a staging data storage. This staged approach ensures that a full patron record is only created after identity and registration data verification at LoC.

There are key stages in this process:

1. Remote initial registration (Tier1).

   • Patrons register online by filling out a basic form in the Locate system, providing their name and email. The data is temporarily stored in a staging table in FOLIO, and the patron receives an email for verification.

2. Remote patron LoC pre-registration (Tier2).

   • After email verification, patrons provide detailed information (e.g., name, phone, address) in a pre-registration form in the Locate system. This data is also stored in the staging table in FOLIO.

3. Onsite registration completion.

   • Patrons visit the LoC in person to complete the registration process. Library staff verify their identity, search for the patron's pre-registration record in the staging table, and finalize the patron record creation in FOLIO User app. The pre-registration record is then removed from the staging table.

4. Self-Registration Kiosk

   • Patrons who have not pre-registered online can a kiosk at LoC to fill out the Tier 2 form. In this case, email verification is bypassed, and patrons can proceed immediately to complete registration, including identity verification, card printing, and photo capture.

Detailed technical design can be found here:

Notes:

• Library staff who work with reader registration records should not have access to all user records. - Congressional User records should only be accessible to a subset of the staff who access User records (UXPROD-4119).

• Delete old reader registrations.  - LoC will not delete old/inactive User records.

• Assign a patron barcode - sequence generators can be used (barcode format: R+7 numeric, R5704559)

• Indicating via note if the User is banned - plan to use patron blocks

• Indicating that the User is minor (under age 18) - designating minors by placing them in a separate patron group will be sufficient to distinguish them within the User records.

OUTDATED (kept for reference)

Proposed solution:

1. Integration with LOCATE Functionality:

   1. Initial (basic) patron registration will be part of the LOCATE functionality.

   2. Verification and activation of patron email to be handled by LOCATE.

   3. FOLIO will send only API responses in integration with LOCATE.

   4. LOCATE will send email messages to the Patron.

2. Pre-Registration Form Submission:

   1. LoC patrons should fill out the pre-registration form in LOCATE.

3. FOLIO verification of patron records:

   1. FOLIO checks if a Patron record with the email specified in the pre-registration form already exists

      1. If email does not exist, FOLIO creates a new Patron record.

      2. For existing email, FOLIO performs additional verifications on patron group and account status:

         1. If Patron record is active, FOLIO responds to LOCATE with appropriate messages.

         2. If Patron record is inactive, FOLIO responds to LOCATE that Patron record needs renewal.

4. Details of newly created Patron's User Record:

   1. Newly created Patron’s User record should include:

      1. Details from pre-registration online form LOCATE

         1. First

         2. Last name

         3. Middle name (optional)

         4. Preferred first name (optional)

         5. Email address

         6. Phone

         7. Mobile phone (optional)

         8. Address

         9. Email communication preferences (optional)

      2. Default patron details generated by FOLIO:

         1. Patron group: "Remote Non-circulating", with an expiration date length of 2 years.

         2. Status: Active.

         3. Enrolled Date: the date of submission of pre-registration form

         4. External system ID

         5. User type: Patron

         6. Permissions: no default permissions

5. Handling Email Communication Preferences:

   1. Details for email communication preferences can be handled as FOLIO custom fields.

6. Account Renewal Process:

   1. As part of the Account Renewal, patrons will fill out the same pre-registration form in LOCATE.

   2. FOLIO should provide already defined personal data for displaying the LOCATE pre-registration form.

   3. After submission, FOLIO should follow the verification process described above (p. 3).

7. Protection of Sensitive PII Data:

   1. Ensure protection of Photo, Last Name, First Name, and Address data in compliance with FedRAMP regulations.

Links to additional info:

• Technical design

• UI mockups

• LoC Patron registration workflow (attachment)

• LoC Patron registration data (attachment)

Questions:

• Do we need to collect signatures?

  • [LoC]: LoC does not need to collect signatures.

• Would using a distinct patron group for minors' identification would be sufficient for visually distinguishing them in user records?

  • [LoC]: Yes, designating minors by placing them in a separate patron group will be sufficient to distinguish them within the User records. We will print the patron group (for all Users, not just minors) on the library card, and will explore the templates for other visual cues on the printed cards.

• Identification of banned user records. 

  • [LoC] We'd like to work with the IC's on options to accomplish this via Patron blocks and notes. The need is to indicate that someone is banned from the physical premises in addition to blocked from any circulation actions. There needs to be some indication that a staff member should not simply re-activate an Inactive patron that has been banned, but again that might be doable in a note?

• Consolidate multiple records – does this require any development?

  • [LoC] We would like the patron registration solution to validate (the text string of) and verify (make the user click a link sent to) the patron email addresses. If that is the case, the need to consolidate (or de-duplicate) is not critical. Our current system does not do this, so a patron can submit their data many times and has led to many duplicates.