Legend: NOT STARTED IN PROGRESS STALLED DECIDED
Recommendation
(In progress.) The committee has decided that Option 3 is not valid and is continuing to pursue the remaining options.
Reasoning
Background
Currently the Request/VDX system is used for both consortial resource sharing and ILL, with ILL being implemented through OCLC WSILL for all requests that cannot be filled within UC (or for CRL members, by UC or CRL).
In the SILS, we have decided that consortial resource sharing will be implemented using a fulfillment network; but we will still need ILL through OCLC if a request cannot be filled using consortial holdings.
Based on previous information (which should be validated), direct peer-to-peer integration with WSILL is not feasible in Alma because OCLC is not open to integration via ISO-ILL. A high-level decision has been taken to retain VDX as the UC ILL broker until after the SILS migration is complete. This means that we need to integrate VDX with Alma as a solution for WSILL interlibrary loan.
There are various options for integrating an ILL broker with Alma, as outlined in the following training videos:
https://knowledge.exlibrisgroup.com/Alma/Training/Resource_Sharing/B_Broker-Based_Resource_Sharing
Dependencies
A high-level decision has already been made by DOC that we are not going to change resource broker until after SILS migration, so VDX can be used as a stopgap solution for integration with WSILL.
We are assuming based on previous information that direct peer-to-peer integration with WSILL is not feasible.
We have decided to implement an Alma fulfillment network for consortial resource sharing.
Other partners, such as CRL, can be configured as peer-to-peer resource sharing partners in Alma at the institution level.
OCLC is committed to supporting VDX for several more years.
Options
Option 1: Direct integration between Alma and VDX
In this option patrons will place ILL requests through Alma, through Primo, Google Scholar, an A&I database, or through the Alma Citation Linker (Fetch Item) form. Patron supplies request information, including pickup location, in the Alma Request Item form. (See video above.)
VDX could be integrated with the Alma Request form using ISO-ILL (or email).
VDX would be integrated with the borrowing library circulation system using NCIP 2 messaging (as has been done at UC Davis).
In this scenario the Request system will be completely retired, and we would need to consider whether we need to find ways to recover special functions provided by Request, such as Elsevier Express requests and Hathi link lookup. These features might need to be implemented in some other way if they are to be preserved, such as Hathi Trust API integration with Primo (as currently implemented at UC Davis), and integration between Alma and a patron driven acquisition system of some type for alternative access.
Option 2: General Electronic Service Link to Request
In this option the Request interface will be retained in a simplified form as a patron interface to the ILL broker. Patrons would link to this interface using a Request link in Primo or Alma, or through the Alma Citation Linker (Fetch Item) form.
In this scenario patrons might need to provide a barcode to log into Request, although there may be a technical way around this, such as configuring the General Electronic Service to securely transmit patron data to Request.
This option could present a degraded patron experience if not well integrated with Alma in terms of look and feel, or patron authentication. It also requires UC resources to continue to maintain and develop custom code.
However, this option preserves existing custom features, such as special processing for alternative access requests and Hathi Trust fulltext links, eliminating the need to find alternatives in Alma, and possibly postponing such efforts until after the migration.
This option would still require a direct NCIP 2 integration with VDX to integrate it with the Alma circulation system at the borrowing library when loans are received.
Option 3: General Electronic Service Link to My ILL
Decision: the committee has decided not to pursue this option, as it has none of the advantages of either Option 1 or Option 2.
In this option, the patron will place ILL requests in the VDX My ILL (Zportal) interface. Patrons would link to this interface using a Request link in Primo or Alma, or through the Alma Citation Linker (Fetch Item) form.
In this scenario patrons might need to provide a barcode to log into My ILL, although there may be a technical way around this, such as configuring the General Electronic Service to securely transmit patron data to My ILL.
In this scenario the Request system will be completely retired, and we would need to consider whether we need to find ways to recover special functions provided by Request, such as Elsevier Express requests and Hathi link lookup.
Questions to consider
Based on previous information, we are assuming that a direct peer-to-peer integration with WSILL is not feasible. Has anything changed in this regard?
How important is it to have the patron experience be within Alma (as opposed to in the resource broker interface)?
Can a general electronic service securely transmit patron data to the service (esp. primary identifier)?
How important is it to keep custom features in Request (e.g. Elsevier requests and Hathi Trust links), and can these needs be met some other way?
Note that Hathi Trust link function in Request would not be of much utility for ETAS requests once Request is reduced to providing resource sharing outside the UC consortium, because the user will only encounter Request after they have determined that their item is not held at UC, and Hathi ETAS requests are available based on their being held at UC. This utility would be reduced to search for Hathi full text links. Surfacing these links earlier in the patron workflow would certainly be a better patron experience.
Alternative access requests (Elsevier or other special access content) could possibly be handled earlier in the patron workflow by an integration between Alma and Reprints Desk.
Action Log
Action/Point Person | Expected Completion Date | Notes | Status |
|---|---|---|---|