LSP-SOW_7-25-19.pdf

STATEMENT OF WORK

Implement New Library Services Platform and Discovery Layer for National Library of Medicine

Contents

1. Project Title

2. Background Information

3. Objectives

4. Scope of Work

5. Requirements

6. Contract Type

7. Place of Performance

8. Anticipated Period of Performance

9. Deliverables/Delivery Schedule

10. Invoicing Requirements

11. Post‐Award Administration

12. Evaluation Criteria

Technical Capability ‐ 50%

Service Support ‐ 30%

Corporate Related Experience ‐ 20%

APPENDIX A: International and National Standards/Protocols (for Compliance)

APPENDIX B: Information and Physical Access Security …………………………………………………………………………33

STATEMENT OF WORK

1. Project Title

Implement New Library Services Platform and Discovery Layer for National Library of Medicine

2. Background Information

The National Library of Medicine (NLM) endeavors to maximize the visibility, use, and value of the NLM Collection, and strives to make its library resources accessible to NLM users.

LocatorPlus, NLM's online public access catalog (OPAC), and the Voyager integrated library system (ILS) have been in use since 1998. However, as information technology advances, the underlying functionality and user interface of conventional OPACs, such as LocatorPlus, become obsolete and are no longer aligned with user expectations.

NLM needs to offer a modern, comprehensive Library Services Platform and Discovery Layer that enables users to quickly and seamlessly access NLM’s rich bibliographic data, electronic resources, and full text content. This procurement intends to replace NLM's existing library system with a cloud-based state-of-the-art library management system which provides capabilities to better manage all formats, including, but not limited to, electronic resources and print materials.

3. Objectives

NLM is issuing this Statement of Work (SOW) to acquire a cloud based Library Services Platform and Discovery Layer from an industry leader with technical expertise, experience and resources for ongoing development.

4. Scope of Work

The scope of this procurement is the acquisition of cloud based Library Services Platform and Discovery Layer as well as the technical, management, and support services for implementing and maintaining the platform.

5. Requirements

The vendor shall be FedRAMP Authorized to provide a cloud based Library Services Platform and Discovery Layer. It shall be the most cost-effective library management solution in the industry. Its architecture should be configurable, customizable, and expandable for a variety of collection resources and for further NLM development in response to future needs.

The solution must meet security requirements, policies, procedures, and practices set forth by the U.S. Federal Government. It also must meet the Federal government section 508 compliance requirements.

The requirements for the Library Services Platform and Discovery Layer are detailed below.

A. HIGH LEVEL REQUIREMENTS

General

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

2. The system shall be able to integrate with the library’s existing systems in a robust and transparent manner allowing for ongoing updating from and to the system.

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

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

5. The system shall include in the base package, at the point of purchase, the following live components:

Acquisitions Request fulfillment & circulation Print & electronic resource management Metadata management Administration Link resolution Knowledgebase Analytics Digital Asset Management (optional) Discovery

6. The system shall ensure that the library can, upon migration, decommission the following local systems:

The Integrated Library System (Ex Libris Voyager) The Electronic Resource Management system (developed in-house) The Ex Libris SFX Open URL link resolution software The online catalog (Ex Libris WebVoyage Classic)

7. The system shall support a sandbox environment that provides a full replication of data and configurations from the production environment for both the staff environment and the discovery layer at least twice a year. The vendor should support a timely off-cycle refresh upon request from NLM.

8. The system shall support materials tracking, including, but not limited to, workflows that send records from acquisitions to cataloging, assign records to catalogers, cataloging reviewed/accepted statuses, and retains transient and temporal data in the workflow.

APIs (Application Programming Interfaces)

1. The system shall support and include robust and extensive APIs.

2. The vendor shall provide support (including documentation and online forums) for APIs and web services that enable the library to extend management system functionality.

3. The system shall support APIs for bi-directional data exchange (read/write).

4. The vendor shall provide change control processes for APIs.

Integrations

1. The system shall allow for integrations with webhooks.

2. The system shall support ANSI/NISO standard Z39.50 and ISO standard 23950 (see Appendix A: International and National Standards/Protocols).

3. The system shall allow external systems to search and retrieve records from the system via Z39.50 with various access points, including local data fields/subfields, such as NLM Unique ID in bibliographic field 035$9.

Job Management

1. The system shall allow scheduled jobs to be managed in the system.

2. The system shall identify who is running jobs/reports and the jobs/reports they are running at any given time.

3. The system shall report on the outcome of batch processes, including failures.

User Interface

1. The vendor shall provide a list of supported browsers and browser versions that are certified for the system.

2. The system shall be accessible across a variety of mobile devices.

3. When logging in to the system, the staff user shall be navigated to a personalized dashboard.

4. It shall be possible to post widgets of report outputs on the dashboard.

5. It shall be possible to add/remove/reorder the widgets on the dashboard.

6. It shall be possible to create customized widgets that can be added to the dashboard.

7. All edits and updates by staff users shall be logged by the system.

8. The system shall allow the staff user to customize the user interface (e.g., font size).

9. The system shall provide branding options for the library.

10. The system shall allow for a multi-tasking environment.

11. For streamlining labor-intensive or repetitive tasks, the system shall offer options including, but not limited to, native keyboard shortcuts and use of task-oriented macros created with third-party applications (e.g., MacroExpress).

B. Acquisitions

General

1. The system shall retain acquisition records until deleted by staff.

2. The system shall generate alerts and reminders for acquisitions staff.

3. The system shall allow the library to configure if items being acquired are displayed (or not) in the discovery tool.

4. The system shall support the ability to perform an overlap analysis report for electronic resources, including the ability to upload a list of titles (using an Excel file) that the library is considering acquiring to determine whether the titles are part of the library collection.

5. The system shall support integration with online vendors such as, but not limited to, Amazon.

Staff users shall be able to search in Amazon or other online vendor systems for an item and then automatically transfer the order information to the system in order to create a purchase order (PO) line for the item.

6. The system shall support an option to send/not send vendor letters for generated PO lines.

Purchasing Workflows

1. The system shall support the following purchasing workflows, but, not limited to:

Print approval Print firm order Electronic firm order (package or single-title) Print continuation Electronic subscription (package or single-title)

2. The system shall be able to automatically create purchase orders using Embedded Order

Data/Electronic Order Confirmation Records (EOD/EOCR) based on vendor-supplied MARC records for resources ordered in the external system.

3. The system shall manage the acquisition lifecycle such that:

an order that passes criteria will continue the lifecycle through creation and sending with no staff intervention library-defined criteria (such as incomplete order lines or prices above a threshold) will flag purchases for staff review

4. The system shall provide links from a purchase order to other related information such as, but not limited to, invoice, vendor, and linked bibliographic record.

5. The system shall allow a purchase order to be relinked from one bibliographic record to another.

6. The system shall allow the cost of an order to be split between funds.

7. The system shall accept donations.

8. The system shall handle exchange orders.

9. The Acquisitions workflow shall support a full EDI interface, using the EDIFACT standard (see Appendix A: International and National Standards/Protocols), with major library vendors for ordering, claiming, cancelations, and invoicing.

10. The system shall allow staff to select and purchase print and electronic resources through vendors, including, but not limited to, GOBI (EBSCO) and Harrassowitz, with the completed transactions being automatically reflected in the system. The system should allow staff to check availability of resources before placing orders via a vendor selection platform.

11. The system should allow RSS feeds for new orders be set up.

12. The system shall allow purchase orders to be deleted under certain conditions.

13. The system shall create an audit trail on orders.

14. The system shall allow for distinct levels of authorization for ordering workflows to be set.

15. The system shall allow a variety of order templates be created/used.

16. The system shall support adding interested users associated with a purchase, including, but not limited to:

The option to automatically notify the user(s) when the resource is available (received or activated) The option to automatically place a hold on a physical item on behalf of the interested user(s) once the item becomes available.

17. The system shall allow the operator to update PO line attributes after an order is created and sent to the vendor.

Receiving

1. The system shall allow print items to be received either as part of the invoicing process, or as a separate process.

2. The system shall allow for the receipt of the following item types:

Single-title monographs Serial monographs Issues of serials Subscription Monographs Standing Orders

3. The system shall support the display of notification messages for routing/binding when a PO line has associated resource.

4. The system shall allow the creation of custom publication pattern for the check-in of print serial issues.

Invoices and Payments

1. The system shall support the ability to automatically create an invoice from the purchase order.

2. It shall be possible to manually create an invoice, or to load invoices from an Excel file.

3. An invoice/license audit history shall be available in the system.

4. The system shall alert staff of duplicate invoices.

5. The system shall alert staff when invoices are linked to over expended budgets.

6. The system shall allow an invoice to be partially paid.

7. The system shall allow additional charges to be added to the invoice.

Renewals

1. The system shall support auto-renewal and manual renewal for e-resources.

Claims

1. The system shall provide automatic claiming for items not received within an expected number of days after placing the order; such intervals shall be based on library-defined parameters.

2. It shall be possible to manually generate claims (on demand).

3. The library shall be able to define claim grace periods.

4. The system shall notify staff when a volume or issue of a series has not arrived after a predefined interval and allow for claiming of missed items.

5. The system shall allow for claims to be sent automatically by email for continuous PO lines.

Trials and Evaluations

1. The system shall support setting up trials for both electronic collection packages and databases to evaluate e-resources before purchasing.

2. The system shall support the ability to evaluate existing e-resource subscriptions and decide to renew or cancel based on parameters such as usage and cost.

Funds Management

1. Real-time access to fund balances (including encumbrances and expenditures) shall be supported.

2. The system shall support a hierarchical fund structure that provides the ability to group and report on funds.

3. It shall be possible to define rules related to the fund (e.g., related to over- encumbrance, over-expenditure). These rules shall be inherited by funds on a lower level of the hierarchy. It shall also be possible to override rules defined at a higher level.

4. The system shall support fiscal year close processing including reporting on records that failed to properly process.

5. For each fund, the system shall provide links to invoices and purchase orders encumbered against that fund.

6. The system should support a graphic display of fund balance, allocation, expenditure, encumbrances.

7. The system shall support updated encumbrance estimations for foreign currencies based on daily conversion rates for foreign currencies stored as a central service.

8. The system shall support the ability to continually recalculate encumbrances based on the current date.

9. The system shall support the option of transferring money from one fund to another.

Vendors

1. The system shall provide the ability to maintain multiple accounts for a single vendor.

2. The system shall support different types of vendors – e.g. licensor, licensing agent, content owner, subscription agent, access provider, vendor/payee. The system should allow staff to customize vendor types.

3. The system shall provide the ability to maintain multiple physical and email addresses for a single vendor, with the potential to tie these addresses to individual accounts.

4. The system shall offer the ability to maintain discount, delivery and claim information in the vendor record.

5. The system shall allow a discount to be registered in the vendor record.

6. It shall be possible to include vendor-specific EDI information.

7. The vendor record should support copies of all communications between the vendor and the library. These should either be generated automatically by the system (e.g. claims), or created manually by library staff

8. Vendor records shall have links to all vendor related invoices, purchase orders, and order lines.

C. Metadata Management (Cataloging)

Format Support

1. The system shall support multiple metadata formats and be extensible to additional formats.

At a minimum, MARC21 and Dublin Core shall be available out-of-the-box for the library, with future support for other formats.

2. The system shall support native BIBFRAME record creation and editing. The system shall also support local, customized BIBFRAME profiles.

3. The system shall allow selecting Dublin Core as a target format for digital import.

4. The system shall allow staff to create, edit, and delete records in any supported format.

5. The system shall support import and export in all supported formats.

6. The system shall have embedded support for RDA (Resource Description and Access) including the indexing of RDA specific elements.

7. The system shall support customizable validation of appropriate use of elements, fields, subfields, and values, including, but not limited to, validation of controlled vocabularies and allowable values for fields. Validation tables shall be maintained and kept up to date.

8. The system shall update the MARC tag tables at least twice a year or when updated by Library of Congress. The system shall allow local changes to the tag tables.

9. Text in all records shall support Unicode encoding for indexing, search, importing, editing, storage, and export.

Editing

1. The system shall support the ability to edit all records through an online editor, including any element, field, subfield, or fixed field value as appropriate for the format.

2. The system shall have the same editing capabilities for all resource types (physical, electronic and digital).

3. The system shall notify the cataloger when a record being edited or saved matches an existing record in the catalog.

4. The system shall support relevant online help for elements cataloged.

5. The system shall support drop down lists for value vocabularies including, but not limited to, country codes, language codes, content types, media types, and carrier types.

6. The system shall support controlled vocabulary for defined fields.

7. Catalogers shall be able to save drafts of records without committing them to the catalog.

8. The system shall support the option to suppress records from the discovery tool.

9. The system shall support input and display of the full Unicode character set including, but, not limited to, diacritics and non-Roman characters.

10. The system shall support the creation and storing of record templates for use in creating and editing records, including, but not limited to, specifying default elements, fields, subfields, and values stored in these templates.

11. The system shall support record versioning, including, but not limited to, the ability to view and roll back to past versions of that record and maintain record history for tracking of and accountability for user editing and timestamp.

12. The system shall support hotkeys for navigation and actions that allow editing entirely with the keyboard.

13. The system shall support linking to and access of related records.

14. The system shall support the ability to perform changes in bulk against a set of records, including, but not limited to, the ability to alter any element, field, subfield, or fixed field value.

15. The system shall be able to support library-defined rules for manipulating records either on import, export, or in the online editor.

16. The system shall support the option of library defined merge routines that can be applied to records imported in bulk or one by one in the online editor.

17. The system shall provide a set of metadata management services that allows the library to easily and quickly define a set of records and perform actions against these records. For example, the library should be able to specify a group of records to be withdrawn from a collection or moved to an off-site storage facility.

18. It shall be possible to link an electronic, digital or physical item to one metadata record.

19. The system shall provide the ability to derive a new bibliographic record from an existing record.

20. The system should support EAD (Encoded Archival Description) as an exchange format, including, but not limited to, exporting collections as EAD files.

21. The system should support adding reminders to records.

Authority Control

1. The system shall provide access to global, shared authority files without the need for individual libraries to synchronize with the authorizing agency. The files shall include at a minimum Library of Congress Names and MeSH.

2. The system shall allow libraries to create or load local authority files and records for subjects (including genre terms) and names.

3. The system shall support authorization of bibliographic headings against local or global headings in authority records.

4. When a heading changes in a local or global authority record, the system shall automatically make the change in bibliographic records that are authorized against that heading without staff intervention. The system shall flag changes that require staff decisions, such as, but not limited to, heading splits, newly disambiguated names, and newly deleted headings.

5. It should be possible to search the authority database, and link back to bibliographic records in the local database from headings in the authority database.

6. The system shall allow linked 880 MARC fields to be used as fully-fledged access points for purposes of authority control.

7. The system should support authority record versioning, including the ability to view and roll back to past versions of that record.

Holdings Management

1. The system shall support the MARC21 format for holding records.

2. The system shall allow for the creation of holdings and item records for physical resources.

3. The system shall support the ability to perform changes in bulk against a set of holdings or items.

4. The system shall support the recording of missing/lost items.

5. The system shall support the suppression of holding records from the discovery layer.

6. The system shall support the ability to automatically generate a summary holdings statement

7. The system should be able to add new holdings records without opening and actively editing bibliographic records.

8. The system shall allow holdings along with any associated items to be moved from one bibliographic record to another bibliographic record.

Item Records

1. The system shall record the history of activities on an item - e.g. loans, item changes.

2. The library shall be able to define how items will be sorted.

3. The system shall allow items to be moved from one bibliographic/holdings record to another bibliographic/holdings record.

4. The system shall support the concept of temporary locations for items.

5. The system shall support printing labels and spine labels.

6. The system shall provide support for binding materials together.

Print Serial Management

1. The system shall support the use of serials prediction patterns, specifically allowing for the ease of creating complex customized patterns.

2. The system shall provide workflows for receiving serial issues and serials claiming.

3. The system shall support multiple levels of enumeration and chronology.

4. Routing of issues shall be possible in the system, including, but not limited to the ability to print routing slips.

Record Updates

1. The system shall allow global changes/additions of entire fields and subfields as well as specific strings within fields and subfields in all records types, including, but not limited to, purchase order, vendor, bibliographic, holdings, item, and authority records.

Staff Search

1. The system shall offer intuitive and easy to use search methods; both basic and advanced searching shall be supported.

2. Advanced search 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.

3. The system shall be delivered with a rich out of the box set of indexed fields, including, but not limited to:

author title subject series call number

ISBN/ISSN

publisher notes

4. The system shall allow for local and standard MARC tags that are not included in the out-of-the-box indexing to be indexed as separate searchable fields and all their subfields to be indexed and searchable.

5. Fields in the holdings and item records shall be indexed and searchable.

6. It shall be possible to search across all record types – bibliographic physical, digital, electronic in one search query.

7. It shall be possible to set a filter – including, but not limited by:

Format Location Date range Material type Language

8. It shall be possible to save and manage sets as well as the search query.

9. It shall be possible to search for electronic resources by, but not limited to: title (e.g. journal title), package, licensing information, ISSN/ISBN, and by provider.

10. Dependent on the search type, it should be possible – from the results list - to edit a record, create an order, view holdings, items.

11. It shall be possible to sort result sets by various parameters – e.g. ranked, title, author, date (ascending and descending). There should be more than one level of sorting.

Indexing

1. The system shall allow for indexing of local and standard MARC tags that are not indexed out-of-the-box.

Importing Records

1. The system shall allow for the loading of records singly or in bulk.

2. The system shall allow for searching external databases through the online interface via z39.50 or SRU/W and importing resulting records to the catalog.

3. When loading a record or set of records, staff shall have the following options for handling records detected as duplicate:

Add new records, ignoring duplicates Overlay one record with the other Merge the two records Not load new records when a duplicate is detected

4. The library shall be able, on import of metadata records from a specified source, to define a set of validation and normalization routines to be applied to the records on import

5. The system shall allow for the enhancement of incoming records according to library-defined bulk record change rules.

6. The system shall allow for mapping additional physical item-level fields from the import records into the system – for example, temporary location information, enumeration and chronology subfields, and notes subfields.

Exporting Records

1. The system shall allow for the export of individual, groups of records, or an entire catalog to a predefined target with no additional fees. The records to be exported may be based on a selected set, or records that have changed since the last export to that target.

2. The system shall allow for the enhancement of exported records according to library-defined normalization (reformatting) rules, including, but not limited to, the ability to enhance bibliographic records with holdings information.

3. The system shall allow for publishing on an item or portfolio level to allow for integration with external sources such as the HathiTrust.

D. E-Resource Management

Central Knowledge Base

1. The Knowledge Base shall be updated weekly.

2. The organization of the Knowledge Base shall accommodate the different levels of electronic resources information.

3. The Knowledge Base shall support accurate data that facilitates resource discovery.

4. The system shall allow for the addition of titles not currently in the Knowledge Base.

Link Resolution, Usage

1. The system shall support link resolution standards (e.g., Z39.88-2004, see Appendix A:

International and National Standards/Protocols) and be able to accept OpenURL and context sensitive services as well as resolving the services.

2. The system shall augment the OpenURL metadata.

3. The system shall handle cases where the OpenURL resolves to multiple records.

4. The system shall allow for the creation of dynamic URLs for local electronic collections and override linking provided by the Knowledge Base if desired.

5. The system shall provide users with the ability to link directly to full text content.

6. The system’s electronic journals shall be searchable via an A-Z list in the discovery layer.

7. The system shall allow customization of the resolver’s services menu by the library.

Ordering and Activation

1. The system shall obtain and record pricing, product descriptions and reviews for electronic resource products.

2. The system shall allow multiple purchase order lines for an electronic resource.

3. The system shall allow for the activation of approved purchases for electronic packages and titles.

4. Staff or Patrons shall be able to be notified when a collection has been activated.

5. When an electronic package or title is activated, descriptive records to describe the title(s) shall be added to the catalog automatically.

6. The system should include an electronic activation task list, and the ability to set a due date for each activation task.

7. The system shall provide an option for globally updating e-resources.

8. The system shall provide functionality for recording and tracking of:

Contact information for technical support billing/payment, licensing and other contacts URLs and login information for resource administration Access parameters Type of purchase Library-defined notes

Licenses Management and Amendments

1. The system shall be able to manage licenses and amendments, including, but not limited to attaching digital versions.

2. License management shall be included in the system and not require additional setup or fees.

3. The system shall support the Electronic Resources Management Initiative (ERMI) schema for licenses, including, but not limited to, the ability to display only those fields that the library uses, excluding the remainder if the library so chooses.

4. It shall be possible to add library defined license fields

5. The system shall enable license terms to be displayed to the end user. The terms that are displayed as well as the labels should be configurable.

6. All the electronic resources linked to a license shall be viewable from the license record.

7. The system shall support loading licenses in ONIX-PL format (see Appendix A: International and National Standards/Protocols).

E. Digital Asset Management

1. The digital objects currently managed by the library’s digital repository will continue to reside in their current storage environment, but the metadata should be managed by the unified resource management system.

2. Digital collections managed by the system shall be made discoverable in the discovery layer.

F. Fulfillment (Circulation)

General

1. The system shall have the capacity to fulfill all types of library material, e.g. books, serials, electronic resources, digital materials.

2. The system shall provide integration with third-party ILL systems (e.g., DOCLINE, Relais) using standard protocols, including ISO 10160: 2015, ISO 10161-1:2014 and ANSI/NISO z39.83 (NCIP) (see Appendix A: International and National Standards/Protocols).

3. The system shall include an offline circulation component.

Fulfillment Policy Tables

1. Libraries shall be able to define the policies by which their physical inventory is circulated to library patrons, for example, but not limited to – due date policy, maximum renewals policy.

2. The system shall provide extensive ability to set parameters including for loans, limits and calendar, globally or at the branch level.

3. The system shall allow pickup locations for requests to be specified.

4. The system shall allow the library to define loan limits by staff selected parameters, including, but not limited to material type, location, and user group.

5. Staff shall be able to override loan limits. This shall be limited to staff with override privileges.

6. The system shall support blocking options.

Checkout/Checkin

1. The system shall allow due dates to be manually overwritten when issuing an item.

2. The system shall provide way to generate a list of a patron's items out on loan.

3. It shall be possible for return receipts to be printed.

4. It shall be possible to create temporary item records.

5. It shall be possible for staff and patrons to be alerted when a loan's due date is shortened.

Request Management

1. The system shall support business rules that automatically manage patrons’ requests, requiring staff user mediation only when necessary.

2. When placing a request, it should be possible to define if the request is for digitization or for a physical item. The system shall support prioritizing electronic access over print access.

3. A patron-initiated digitization request shall trigger an alert and a pick slip at a specific digitization location.

4. The system shall automatically generate a notice to patrons when requested items are available. This notice should be in the form of an email or an SMS. This should be generated in real time.

5. The system shall support the administration of access rights for digital materials, based on patron group and collection.

6. The system shall support the administration of access rights for electronic materials, including the ability to restrict access by IP address.

7. The system shall allow for delivery of items to a specific circulation desk, or location, such as book repair, vault.

8. The system shall support hold queue priority.

9. The system shall support library configurable recall options.

10. The system shall support digitization on demand workflows. The system shall allow for configuration regarding digitization requests – e.g. which patron groups may make such a request, and whether the digitization will result in depositing the digitized material in the system or delivery to the end user who requested it.

11. The system shall display the reason for not allowing renewal for the patron, based on the information from the system, and not require staff intervention.

12. The system should allow direct transit for remote storage items.

Renewals

1. Renewal parameters shall be configurable by the library.

2. The system shall support configuration of automatic renewals by, for example, material type, item policy, user group.

3. Staff shall be able to see the current number of renewals for each item borrowed by the patron.

Calendars

1. The system shall provide the ability to define closed dates, opening hours, etc.

2. The library will be able to add special exceptions to standard opening and closing times.

Notices

1. Courtesy notices shall be supported by the system.

2. It shall be possible for staff to customize notices without vendor intervention.

3. It shall be possible to send ad hoc messages to all patrons or specific patron groups.

4. It should be possible to send notices to patrons by SMS.

Patron Management

1. The system shall provide the ability to create different patron types and set circulation parameters for each type of patron.

2. It shall be possible to define more than one patron identifier linked to a patron record.

3. The system shall allow authorized staff to create, modify, and delete patron records.

4. It shall be possible to globally update a set of patron records.

5. The system shall integrate with external identity management systems (e.g., SAML/CAS) for authentication. The system shall support external authentication using social authentication via Google, Facebook, or Twitter.

6. It shall be possible to update defined areas of each patron record (core information, addresses, and phone numbers). Patrons shall be able to have multiple addresses and different types of address (e.g., home, office).

7. When deleting or purging user records, it should be possible to determine whether to remove all data, retain all data, or retain only statistical data.

G. ILL (Resource Sharing)

1. The system shall support ILL (interlibrary loan) functionality – both for borrowing and lending.

2. The system shall support the ISO 1060/10611 ILL protocols.

H. User Management

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

2. It shall be possible to purge user records.

3. The system shall support generic users/passwords.

4. The system shall support the option of defining roles with access permissions and privileges which can then be easily assigned to new users.

5. The system shall integrate with external authentication methods (e.g., SAML/CAS) and mechanisms for user management.

I. Reporting and Analytics

1. The system shall include a comprehensive analytics component that covers all of the system’s data, including, but not limited to all MARC fields, acquisitions, fulfilment, and system administration data, for report creation and is an integral part of the system.

2. The analytics component shall form part of the standard package at no additional cost.

3. It shall be possible to utilize canned reports provided by the vendor.

4. It shall be possible to create custom reports without vendor intervention or assistance.

5. The system shall support a variety of output options including, but not limited to, viewable online, send to printer, email and export to a spreadsheet. The system shall allow for the automatic scheduling of reports at defined intervals (daily, weekly, or monthly).

6. The system shall support the customization of reports by staff; this includes, but is not limited to: changing of reports parameters, views, date/time range.

7. The system shall support the ability to collaborate and share reports with other users.

8. The system shall support role-based report generation and viewing such that a user will only be able to view reports and data according to his/her role.

9. The system shall include a dashboard in which it is possible to monitor performance, view user-specific tasks, and detect trends. Information in the dashboard shall be based on staff user roles, allow for customization, and support the embedding of widgets.

10. The system shall be able to analyze historical data and provide trends analysis (such as usage, expenditure).

11. The system should include sample reports to be used as a basis for creating the reports that need to be sent to library organizations such as ARL (Association of Research Libraries).

12. The system shall store records, data, and reports from library processes indefinitely at no additional charge.

13. The system shall support analyzing digital usage of its digital viewer.

14. The system shall provide a robust statistical reporting functionality for the library to create reports for monitoring and assessing usage of the discovery layer. Authorized library staff shall be able to distinguish statistics based on user groups – external (i.e., users who access the discovery layer from outside of the NLM IP range), users who access the discovery layer from the NLM Reading Room, and staff users.

15. The discovery layer shall anonymize the usage data but distinguish between user groups (i.e., external, Reading Room users, and staff users).

J. Discovery Layer

General

1. The system shall support a complete and transparent integration with a next-generation discovery solution.

2. The discovery layer shall have built-in mechanisms that enable automatic harvesting, normalization, and indexing of bibliographic, holdings, item, and authority data from the system.

3. The discovery layer shall present real-time information (e.g., bibliographic, item, acquisitions), including, but not limited to, item availability status and processing requests for physical materials through interoperation with the system while enabling users to remain in the discovery layer.

4. The discovery layer shall support import of records in Dublin Core, XML, or MARC21 format through FTP, file upload, or OAI (Open Archives Initiative) from local NLM sources for access through the discovery layer.

5. The system shall support seamless patron-driven workflows initiated from discovery and served by the system such as, but not limited to, digitization on demand, ILL requests.

6. The discovery layer shall support harvesting and crawling of NLM’s data by major web search engines.

7. The discovery layer session time-out limit shall be configurable by the library.

Functional

1. The discovery layer shall provide simple one-box searching. Searching by keyword anywhere shall be the default search, including, but not limited to, use of Boolean operators, truncation, and wild card.

2. The discovery layer shall provide a separate advanced search form. The advanced search form shall be expandable with additional search rows and include use of Boolean operators, specifying search fields and collections, truncation, wild card, nesting, phrase, and filtering options.

3. The discovery layer shall allow users to perform browse search by author, subject heading, title, call number, and series.

4. The discovery layer shall allow users to view resulting headings, view "see" and "see also" references, navigate previous/next result page on browse list, view matching bibliographic and/or authority records when selecting a heading.

5. The discovery layer shall allow users to search individually or across local collections, encompassing all resource types (physical, electronic and digital), and a central index of full text, citations, and metadata from publishers, open-access collections, aggregators, and subscription databases.

6. The discovery layer shall allow for standard and locally defined data not included in the out-of-the-box indexing to be indexed as separate searchable fields and all their subfields to be indexed and searchable.

7. The smart search options shall be configurable by the library, including “Did you mean?”, auto complete, alternative spelling, vernacular search and retrieval, and character normalization.

8. The discovery layer shall include explosion and matching descriptors and/or qualifiers. The discovery layer shall search for all subordinate descriptors and/or qualifiers in the MeSH hierarchy by a search on higher-level descriptors and/or qualifiers. The discovery layer shall refer users from a non-preferred term to a preferred MeSH descriptor and/or qualifier. Note:

MeSH is the National Library of Medicine’s controlled subject vocabulary thesaurus.

9. The discovery layer should allow users to search and retrieve authority records.

10. The discovery layer shall allow users to refine their searches to specific facets and limits.

11. The discovery layer shall allow users to retrieve additional records by clicking on hyperlinked metadata, including but not limited to author, subject, title, and series in a result record.

12. The discovery layer shall provide short persistent URLs to search result items, bookmarks, saved search queries, and headings resulted from a browse search.

13. The discovery layer shall allow the library to adjust the algorithm used for relevancy ranking, including but not limited to boosting by specific collections and exact match for a journal title over a keyword match.

14. The discovery layer shall include personalized ranking to tailor search results based upon end-user research preferences.

15. The discovery layer shall allow users to sort result sets by various parameters – e.g. relevance ranking, title, author, date (ascending and descending).

16. The discovery layer shall allow users to manage, select, and save their search queries and results.

17. The discovery layer shall allow users to output search results via email, printing, citation managers, and exporting in MARC or another library metadata format.

18. The discovery layer shall allow users to search and use the layer without signing in. The discovery layer shall allow users who have a patron account in the system to sign in, customize preferences, manage previously saved search queries and search results lists, manage alerts, and request physical materials and view processing status of the requests placed.

19. When signed in, the discovery layer shall allow users to request physical materials from a selected search result record using a form that is configurable by the library. It shall automatically populate information from the selected record on the request form including bibliographic, item and user information. Users shall be able to add additional notes.

20. The discovery layer shall provide customizable alerts to inform users of new items in the system or other collections related to their saved search queries.

21. The system shall include built-in views to access digital objects including text, video and audio.

22. The system shall support the International Image Interoperability Framework (IIIF, see Appendix A: International and National Standards/Protocols) and enables viewing digital images.

23. The system shall support the use of a third-party digital viewer.

24. The discovery layer shall support integration with web-based analytics discovery, including, but not limited to, Google Analytics.

25. The discovery layer shall be compatible with all major web browsers, including their last two full versions. Browser upgrades shall be supported within six months.

User Interface

1. The discovery layer shall provide a customizable look and feel consistent with current web design standards, such as responsive web design.

2. The discovery layer shall use consistent navigational elements.

3. The discovery layer shall allow multiple views of a record displaying varying levels of information, including MARC view, for NLM collection records. The information in each view shall be configurable by the library. Search terms shall be accentuated.

4. The discovery layer shall identify and manage the display of duplicate records within search results.

5. On the search result list, the discovery layer shall provide an indication of online access to applicable resources with availability, sources, authentication information, public notes, and license information.

6. The discovery layer shall support and display multilingual text which shall comply with the UTF8 character encoding.

7. The discovery layer shall allow NLM to modify and add Help information as well as configure where Help links are displayed and customize links to NLM informational pages.

K. Implementation and Migration Services

Migration

1. The vendor shall provide a detailed implementation plan that tailors to NLM’s specific needs.

a. The plan shall include, but not be limited to:

i. The data entities that can be migrated from Ex Libris Voyager, as well as other external systems, such as NLM’s local Electronic Resources Management System.

ii. How the integrity and quality of the data will be maintained during the migration process.

iii. Outline the roles and responsibilities of the library and vendor during the data migration process.

Implementation

1. The vendor shall outline the estimated timeline for implementation and the major steps in the project.

2. The vendor shall outline the best practices with regards to system configuration and customization by the library. This shall include the recommended tools for library staff to configure and customize the product.

3. The vendor shall provide online and on-site training programs and materials during the implementation process.

Support and Maintenance

1. The vendor shall provide a Service Level Agreement (SLA) that includes, but not limited to, up-time guarantees and levels of support.

2. The vendor shall provide the ability for libraries to report problems, both during the implementation period and once the system is in production.

3. The vendor shall provide detailed, up-to-date, and accessible system documentation, including, but not limited to, documents of software architecture, data dictionary, entity relationship diagrams, as well as administrator and user manuals.

4. The vendor shall provide information of the development community on its size and responsiveness to assist with development-oriented problems.

L. Service Level Agreement

1. The system shall have an uptime of at least 99% annually.

2. The vendor shall monitor system reliability, proactively mitigate risks in operation disruption, maximize system availability, and timely notify customers of unplanned downtimes.

3. The vendor shall monitor system performance and workload and adjust to address competing needs.

6. Technical Proposal/Solution Requirements

The technical proposal/solution shall describe/address following areas, but not limited to:

1. Describe short- and long- term development strategies for the system. How are these strategies determined?

2. Describe any activities surrounding BIBFRAME and Linked Data, and how your system will support these formats. Describe the extent to which Linked Data elements are integrated into the staff interface and discovery layer.

3. What types of messaging and alerts are supported for staff users? Are they customizable?

4. What role do customers play in the product enhancement process?

5. How are orders for electronic and print versions for the same title handled?

6. Describe the process for tag table and validation table updates. How are they kept up to date? Are they customizable?

7. How are 'bound withs' handled?

8. How are authority (local and global) records managed in the system?

9. Describe a typical subscription renewal workflow in your system.

10. How does the system create and store item level data in relation to other data?

11. How does the system support global changes to records?

12. How are indexes created and maintained?

13. How frequently are records newly added or edited in the system indexed for search by staff and in the discovery layer?

14. Describe how the Knowledge Base is maintained and updated to track changes made by providers and additions of resources to collections, as well as other changes. Describe the process for adding and maintaining local resource data. What is the user community involvement in the development of the Knowledge Base?

15. Describe the steps for activating and providing access to an electronic resource. Describe how your system supports evaluation and renewal of e-resource items.

16. Describe the subscription tracking process, and how subscription period, cost, payment (including pro rata payments), renewal, and cancellation information are stored.

17. Describe the functionality of your digital asset management system.

18. How does the system link to digital objects on other local and external systems?

19. How are loan rules defined in the system?

20. Describe ability for patron self-registration. And, can patron ID be used as barcode?

21. Describe a typical borrowing request workflow.

22. Describe a typical lending request workflow.

23. Describe interaction between and support for use of external reporting systems and/or data warehouses.

24. What kinds of planned downtimes are required, noting the frequencies, durations and purposes. How are jobs scheduled to run during planned or unplanned downtimes handled?

25. Describe your customer support venues, periods of coverage, and expected response times.

26. Describe how your user interface, including media player, supports WCAG 2.0 AA standards (refer to https://www.w3.org/WAI/standards-guidelines/wcag/).

7. Contract Type

This is a fixed price contract.

8. Place of Performance

This is a Cloud based service to be accessed over the Internet.

9. Anticipated Period of Performance

Base Year 09/30/2019 – 09/29/2020 Option Year 1 09/30/2020 – 09/29/2021 Option Year 2 09/30/2021 – 09/29/2022 Option Year 3 09/30/2022 – 09/29/2023 Option Year 4 09/30/2023 – 09/29/2024