b. Attachment 1_Library Services Platform (LSP) Statement of Work (SOW).pdf

Library Services Platform (LSP) Statement of Work (SOW)

Background

The James A. Zimble Learning Resource Center (LRC) supports the Uniformed Services University (USU), the readiness of America’s Warfighter and the military community by providing comprehensive world-class and world-wide access to current and historical military medical information sources. The LRC supports the University’s current scholarship and learners through efficient research methods and tools, education, bibliometrics, and first-rate technology experiences; facilitates cutting-edge, military-relevant research and academic writing, and preserves the legacy of the University’s impact.

Scope

To support USU’s educational mission, the LRC requires a state-of-the-art, turn-key library services platform (LSP) to manage its collection of print and online resources. In 2020, the LRC migrated from an outdated integrated library system (ILS) to a modern LSP. LRC personnel invested considerable time and funding into training and moving resources into its current system, which has been critical to achieving the mission. This system supports the management and data augmentation of all forms of academic resources (e.g., print and electronic books, serials, media, databases). It also allows for management of patron and vendor information and integrated searching. The LRC requires the continuation of using an LSP for its collection management and access services. This LSP must meet system security requirements as well as maximally streamlining and automating workflows. It is required to be cloud-based and FedRAMP compliant. Constituent to the system is a non-modularized and seamlessly integrated institutional repository component and discovery/search component.

Requirements / Application Components

The LRC has a requirement for a cloud-based, FedRAMP compliant library services platform (LSP) encompassing the following features:

High Level Requirements

1. The system shall provide unified management of all print and online resources that the LRC owns, licenses, stewards, and makes available to users for discovery and delivery.

This includes metadata management and circulation for all resource types.

2. The system shall be a Web-based SaaS multi-tenant solution that requires only a Web browser, not the installation of staff clients.

3. The system shall feature at least quarterly updates to all customers, released by the vendor and requiring no library IT intervention.

4. The system shall be designed to leverage true cloud technologies.

5. The system shall support single sign-on.

6. The system shall include the following components:

○ Circulation

○ User Management

○ Cataloging

○ Electronic Resource Management

○ Discovery Layer

○ Link Resolution

○ Administrative Interface

○ Reporting

7. The system shall also provide:

○ Web Development

○ Software Version Maintenance

○ System Administration and Security

○ Support

○ Documentation

○ Installation

Circulation

● Circulation management. Ability to define different item types in the print collection.

Support of distinct borrowing rules (loan and renewal periods) and permissions based on item types and other criteria. Support for institution calendar dependencies to take closures into consideration. Ability for staff to override circulation rules when deemed necessary.

● Check-in and Check-out. Easy-to-use administrative interface to support checking items in and out of the collection. Ability for staff to check out or renew multiple items in a single session.

● Hold requests. Ability for patrons to submit hold requests for items in the collection.

Support of a workflow to facilitate hold transactions, including notifications and reminders (for staff and patrons) as well as cancellations.

● Overdue materials. Support of a workflow to manage overdue items, including notifications and reminders for staff and patrons.

● Missing items. Ability for staff to manually change an item’s status to missing and to reverse that status when the item is found.

● Course reserves. System for managing course reserves of print and electronic materials.

● Borrowing statistics. Ability to track circulation statistics of items and patrons, including the total number of times an item has been checked out and the date of most recent check-out and check-in of an item.

● Print collection management. Support of a workflow to facilitate inventorying the print collection. Support of a workflow to process deaccessioning of items.

● Self-service module. Support for patron self-service stations, with the ability to process circulation transactions such as check-ins, check-outs, and renewals.

● Barcode scanning. Support for universal barcode scanning for item barcodes.

User Management

● Patron records. System of patron records with ability to store information including usernames, patron names, e-mail addresses, telephone numbers, affiliations, expiration dates, patron notes, etc. Ability to define patron groups with distinct circulation and e-resource privileges.

● Single Sign On (SSO) and CAS Support. Patrons and administrators must be able to authenticate with an integrated Single Sign On (SSO) architecture based on USU’s implementation of Central Authentication System 2.0.

● Record Updates. Patrons records must be dynamically synchronized with a local user information system that exports a matching CAS key identifier via SFTP and uses XML or another standardized, structured file format. Records that match on this key should be updated. Records that have no match should be created. These updates must be available both on-demand and automated.

● SFTP Service. The SFTP service must be provided by the vendor and integrated with the synchronization tool

● Audit Trails. Updates must include an audit trail so that staff may monitor data synchronization failures or errors and view reports of these audit trails.

● API Support. In addition to this required “batch” update model, APIs for patron updates would be a “plus.”

● Staff Roles. The system shall provide granular access control rights for staff accounts and be able to facilitate multiple profiles accessing different combinations of functional areas.

Cataloging

● Basic and Advanced Searching. The system shall offer intuitive and easy to use search methods; both basic and advanced searching shall be supported.The advanced searching shall allow for the option of searching multiple fields simultaneously for words or phrases. Staff should be able to define their own search conditions – based on standard indexed options. Search shall support Boolean operators. Dependent on the search type, it should be possible – from the results list - to edit a record, create an order, view holdings, items, and other connected information.

● Indexed Fields. The system shall be delivered with out-of-the-box set of indexed fields, including, but not limited to: author, title, subject, call number, ISBN/ISSN, publisher.

● Integrated Search. It shall be possible to search across all types – bibliographic, physical, online – in one search query.

● Saved Searches. It shall be possible to save and manage sets of staff queries.

● Metadata editor. Ability to create, modify, manage, and delete bibliographic records in

MARC and Dublin Core formats. Ability to perform global edits to fields and subfields based on complex search criteria. Ability to track version changes to bibliographic records. Conforms to national library industry standards for bibliographic data such as OCLC and Library of Congress. System should have a plan for support of emerging formats such as BIBFRAME.

● Importing from external sources. Ability to import metadata records from external sources such as national bibliographic utilities (including OCLC) and national libraries (including the National Library of Medicine and Library of Congress). Support for load profiles to define which fields to import or overlay. Support for record matching with the ability to define matching criteria and resulting actions, such as overlay or replacement of existing records.

● Database of metadata. Access to a shared database of metadata records (bibliographic and authority) collaboratively maintained by a community of libraries. Ability to maintain control over local institution records.

● Record visibility. The LSP must provide the ability to control the visibility of bibliographic and holdings records, such that individual records are able to be suppressed from view in the discovery layer yet retained in the LSP for staff view. This is necessary to track past subscription activity and retain obsolete records for posterity.

● Metadata visibility. Ability to customize the visibility of bibliographic records and of individual metadata fields on the public-facing discovery layer.

● Track edits. Ability to track staff interaction with bibliographic, holdings, and item records. The system shall display ‘created by’, ‘last updated by’, and (where applicable) ‘modified by’ information for various types of records.

● Internal notes. The system should come with the ability to add notes to various resources managed in the system.

● Authority control. Ability to create, modify, manage, and delete authority records in MARC format representing names, subjects, and uniform titles. Conforms to national library industry standards such as OCLC and Library of Congress. Active linking between bibliographic and authority records.

Electronic Resource Management

● Electronic collection management. Ability to manage collections of online, subscribed resources such as e-journals, e-books, and databases.

● Standard collections. The LSP must provide an extensive knowledge base of standard, off-the-shelf collections (which are the same for any subscribing institution). LRC staff should be able to simply activate these collections for the LSP. The LSP provider should establish a data exchange between the LSP and various content providers to ensure that these standard collections are automatically updated in a timely manner to reflect additions and removals, obviating the need for LRC staff to manually update these collections. The knowledge base should include standard collections commonly available for subscription to academic libraries from major scholarly publishers including, but not limited to: EBSCO, Elsevier, Gale, Lippincott, ProQuest, Sage, Springer, Wiley, and Wolters Kluwer (Ovid).

● Autoholdings for custom collections. The LSP should provide a function that allows participating content providers to establish a data exchange between the LSP and content provider systems, such that certain LRC-specific collections are able to be automatically updated in a timely manner to reflect additions and removals. This would obviate the need for LRC staff to manually update these collections. This function should be compatible with as many major scholarly publishers as possible, such as EBSCO, Elsevier, ProQuest, Springer, Wiley, and Wolters Kluwer (Ovid).

● Manually updated custom collections. The LSP must also allow LRC staff to manually manage collections of online, subscribed resources such as e-journals, e-books, and databases, representing packages which are unique to the LRC.

● Quality metadata. Access to high quality metadata for online, subscribed resources (e-journals, e-books, databases), such as metadata edited by the Library of Congress CONSER cooperative program.

● Holdings management. Support for holdings management of separate instances of the same title from different providers. Ability to specify ranges of subscribed dates and volumes for each instance.

● Scoped access management. Support for different access requirements for each collection, including distinguishing access privileges for different patron groups. This is necessary to accommodate different user groups at USU who have access to different sets of subscribed resources. Ability to distinguish subscribed resources from freely available resources.

● Usage statistics. Ability to track usage of online, subscribed resources (e-journals, e-books, databases) by collection and by title.

Discovery Layer

● Unified public catalog. The LSP must provide a unified public-facing site for patrons to search the entirety of the LRC collections, both print and online, in one place. It should combine the features of traditional library public access catalog (OPAC) with next generation discovery service.

● Comprehensive index. The LSP must provide access to an extensive, searchable index covering citation metadata for a wide range of the bibliographic universe, including resource types such as books, academic journals and individual articles, and other scholarly resources. For academic journals, the index should also provide full text indexing of published resources to the extent possible.

● Advanced search faceting. Ability for patrons to limit search results by a variety of factors, including resource type, collection, journal title, physical location, author, subject, publication date, language, and whether the resource is available in the LRC collection or not. Patrons should be able to expand the search to include resources outside the LRC collection.

● Catalog integration. The LSP must provide a fully integrated workflow for the catalog and discovery layer. That is, resources which have been selected and cataloged by the LRC, and which are covered by the comprehensive index, should have full-text searching enabled in the public catalog as part of an integrated workflow.

● Interlibrary loan (ILL) integration. The discovery layer must provide integration with the LRC’s ILL system. Ability for patrons to generate ILL requests from individual results in the discovery layer to auto-populate ILL request forms with citation information.

● Patron holds. Provide a configurable “place hold” button that does not display if items are non-circulating.

● Scoped instances. The LSP must provide the ability to create separate instances, with each instance scoped to provide access to a specified subset of resources in the LRC collection. This is necessary to accommodate different user groups at USU who have access to different sets of subscribed resources.

● Curated resource lists. The LSP should provide the ability to create collections of LRC resources to be displayed together in the discovery layer. This allows LRC staff to curate lists of resources for specific topics or classes.

● Widgets. The LSP should be able to accommodate widgets that enable third party software to display for users in the discovery layer, including library online chat systems.

● Citation tools. The LSP should provide the ability for users to generate citations for any search result using common citation formats (such as AMA, APA, MLA, and Chicago) and for export to common reference manager software (including EndNote).

● Persistent links. The LSP should provide the ability for users to generate persistent link (URL) to each search result to facilitate sharing and re-visiting any particular resource.

● Third party data sources. Ability to incorporate records from third party LRC-managed sources, including SpringShare LibGuides and OCLC ContentDM.

● License terms. Ability to display license terms and access restrictions to users for each discovery layer search result, communicating key usage terms to users and staff.

● Open web development for customizing resources and services for local library.

● SSL options and support for PKI certification of server.

Link Resolution

● OpenURL Support. HTTP(S) based OpenURL link resolution for external queries to link to full text.

● Locally-maintained, easy-to-use database of holdings and publishers for article resolution.

● Multiple EZProxy Support. Groupings of electronic resources must support multiple instances of hosted EZProxies to facilitate seamless access to full text using IP address access control.

● Path Resolution. Resolved links must be able to match resources identified in holdings records and provide an automated path to either full text or an bibliographically autofilled request for Interlibrary Loan using OCLC Illiad.

Administrative Interface

● Integrated system. The LSP must provide an easy-to-use interface for LRC staff to manage all functions of the system from one centralized location, including circulation, electronic resources management, and system admin functions.

● Web-based. The administrative interface must be fully web-based without the need for local client software.

Reporting

● Standard Reports. The LSP must offer fully integrated reporting capabilities, including the ability to generate standard reports containing statistics about the collection (at the title, holdings, and item levels), circulation transactions, resource usage, and user records.

● Customized Reports. The LSP should offer the ability to create customized reports based on search criteria that allow the library staff to craft reports targeting specific collections.

Web Development

● Support for staff-mediated web development with easy integration with underlying database systems, customizable web reports and forms.

● Development infrastructure for upload, download, modification and testing of web content including development staging spaces.

Software Version Maintenance

● Automated Client Updates on a quarterly basis.

● Staff-initiated Server Updates.

System Administration and Security

● TCP/IP protocol suite for interconnection of systems and services.

● Multi-layered, role-based accounts for all systems and modules controllable by library staff.

● Network access controls for all systems and services in an easy to use interface (firewall services and Access Control Lists).

● FedRAMP Authorization: awarded.

● Menu-driven process control and interprocess communication.

Support

● Experienced customer support. Access to 24/7/365 support by web-based, asynchronous ticketing system or by telephone.

● Real-time support. Access to real-time, online chat support during normal business hours in the U.S. Eastern time zone.

● Flat-fee based. No emergency fees.

Documentation

● System documentation. The LSP provider should have a complete, indexed, and searchable website with training materials and detailed articles describing the features of the LSP. Customers should be able to look up specific functions, settings, and options to understand the behavior of any component of the LSP.

● Change alerts. Documentation changes should be tracked with optional alerts.

● Training materials. Customers should also be able to engage in self-directed learning to understand the LSP.

Installation

● Transition process. Any processes necessary to transition to the LSP should not present an unreasonable disruption to ongoing LRC services and functions, nor should they present an undue burden on LRC staff.

● Transition support. The LSP provider must work with LRC staff to complete any necessary processes to transition to the LSP and supply adequate training to LRC staff in its use.

● Data transfer. The LSP must be able to accept bulk import of the LRC’s existing data, including bibliographic records, holdings records, item records, collection-specific data, patron data, and any institution-specific settings and configurations that the LRC currently uses.