OpenRS Requirements

OpenRS Requirements for MOBIUS

Requesting and circu lation workflows

1. Patron uses a patron search application to search and make requests from OpenRS

   1. Primary use case supports a patron-initiated request UX without mediation by library staff.

   2. Secondary use case allows library staff to act as proxy requester on behalf of patron.

2. Patron authentication

   1. If not already authenticated, placing a OpenRS request requires the patron to authenticate via the method used by the patron’s library.

   2. Authentication requires the user to supply credentials to authenticate their library account and check eligibility against their library system.

   3. The patron’s ILS determines patron’s eligibility to request. If not found or eligible, OpenRS will display messages corresponding to the issue blocking a request

   4. If eligible, the patron selects a pickup location from the patron’s library and members participating in the pickup select program.

   5. Patron submits request and the item selection process begins

3. Item selection process

   1. Identify all items available for loan and on-shelf.

   2. Of those on-shelf, prioritize placing a request on a copy that is closest to the pickup location.

   3. When all items are either on loan or holds, place request on the one likely to be returned soonest (combination of number of holds and due date)

   4. If the instance record has volumes, allow the patron to select a volume and allow OpenRS to select the items using the same item selection process as for monographs

   5. Optional feature to allow staff to place a hold on behalf of a patron and to bypass  the standard item selection process in favor of requesting a specific copy.

4. Request sent to the lending library in near real-time (NRT)

   1. Request processing

      1. Request associated with an institutional patron

      2. Request added to pull list

      3. If library is unable to locate material, library uses ILS to cancel the request, OpenRS searches for another item (using same item selection algorithm for original request)

      4. If library locates material, prepares it for fulfillment/transit and using checkout, circulates the item to the borrowing library.

      5. Print transit slip

         1. The slip will include borrowing library name and code (for label making)

         2. Put into transit

      6. Lending library system automatically updates catalog

      7. In NRT, OpenRS updates union catalog

      8. In NRT, OpenRS updates the borrowing library OpenRS item status

   2. Both library and patron can track the status of their OpenRS transactions within their ILS and patron empowerment features

5. Courier picks up materials and delivers them to correct borrowing libraries [Not an ILS step]

6. Borrowing library scans and receives the delivered materials using ILS checkin capability

   1. If items is scanned at the wrong library destination, system to alert operator to route to intended destination and puts item in-transit to destination location

   2. Hold triggered; ILS directs user to put item on the physical hold shelf  

   3. ILS updates OpenRS item record

   4. Patron is notified via their ILS ((email, text, sms) via available notification methods of the library system notification capabilities.

7. Patron arrives at the pickup location to checkout OpenRS item(s)

   1. Circulation of OpenRS items via ILS using ILS circulation rules

   2. ILS updates OpenRS item record

8. Patron returns OpenRS items

   1. If a patron returns OpenRS item(s) to their library, the ILS updates the item(s) to a returned state

      1. In NRT, OpenRS updates the item library that the item is in-transit to the owning library

      2. In-transit slip produced (dependent upon the capabilities of the ILS)

      3. OpenRS Item shipped to home library

   2. Patron responsibility of OpenRS item(s) complete

9. Material arrives at home library

   1. Item is scanned using ILS check-in

      1. ILS updates local catalog status

      2. In NRT, OpenRS updates the union catalog 

Cataloging 

1. Automatic contribution of records to the OpenRS union catalog in NRT as records are cataloged/added, updated or deleted on the local system. 

2. Contribution of records applies on a per library basis and addressable by encoding on a record-by-record basis.

Patron search 

1. The ability to allow all libraries to enable or, in the case of Sierra and Polaris, create code to execute a pass-through search from the local patron search application to the  OpenRS union catalog.

2. The ability to facet locations by library (not shelving location) in the LOCATE union catalog and apply to both search results and item requesting.

3. The ability to visually associate an 856 field with the corresponding holding library in LOCATE on the OpenRS union catalog. This is dependent upon known location data stored within the 856 location subfield.

4. On the full record display, the ability to view libraries with holdings that are currently eligible for loan and are on-shelf at the library.

5. On the full record display, the ability to place a request.

Administration

1. As much as possible, provide MCO the means to administer and configure OpenRS tables, settings and parameters

2. A way to easily identify last copies in the system.

3. Ability to calibrate via configuration the match algorithm (multiple, definable, hierarchical, matchpoints) to identify matches

4. Ability to calibrate via configuration the algorithm for determining the best instance record used for “match and attach” of items to a union catalog.

5. Options on how the system chooses an item to fill a hold and when to prompt for more information from the user (i.e. volume and serial records).

6. The ability to visually associate an 856 field with the corresponding holding library in LOCATE on the OpenRS union catalog.

7. The OPAC must be responsive down to a hand-held device.

8. The ability to generate “Too Long reports” or something similar.

9. The ability for all MOBIUS members to access OpenRS circulation lending and borrowing statistical reports.

10. The ability to access OpenRS circulation transaction logs and download in one or more common output formats (e.g. csv).   

NOTES

• Wherever near real time (NRT) is mentioned, it equates to a range from one second to five minutes. This range is largely dependent upon finding the right frequency of updates allowed by the ILS network traffic controller.

• Where mentioned, ILS = FOLIO, Polaris, Sierra library service platforms. Unless a specific library system is mentioned,

• Unless specified to the contrary, all capabilities are required for the MOBIUS’ go-live offering. As part of an iterative development process, new capabilities may be identified and folded into go-live plan or post-go-live. This is expected that all parties will, in good faith, seek to balance existing project priorities and new capabilities.

• All workflows are intended to illustrate the user journey and are subject to change by K-Int and EBSCO.

• Unless others specified, circulation workflow and corresponding functionality heavily leverages the library ILS. That said, there may be cases where the only means for creating a capability is to request development from an ILS vendor. On-site borrowing is one such capability that we already know about. In all cases, it is incumbent upon all parties to consult on the issue and, define and take steps to address. Work as a team, succeed as a team.

• The refinement of match algorithms can be a significant investment. Collectively, we are collectively committed to moving at a speed relative to the impact and take measured steps to affect the best outcome for all. Generally speaking, rushing changes in this area of the system are likely to result in significant cost to the project.

Project OpenRS - Roadmap

A MOBIUS Project OpenRS roadmap will be detailed here when it is completed.

Created by MOBIUS on October 27, 2022.