Statement of Work - Library Sertvices_Alma Primo VE 11-14-2024.pdf

STATEMENT OF WORK

Alma/Primo VE Library Services Platform and Discovery System

November 11, 2024

Contents

1. Project Title

2. Background

3. Objectives

4. Scope of Work

5. Task Areas

A. High Level Requirements

General

Application Programming Interfaces (APIs)

Integrations

Job Management

User Interface

B. Acquisitions

General

Purchasing Workflows

Receiving

Invoices and Payments

Renewals

Claims

Trials and Evaluations

Funds Management

Vendors

C. Metadata Management (Cataloging)

Format Support

Editing

Authority Control

Holdings Management

Item Records

Print Serial Management

Record Updates

Staff Search

Indexing

Importing Records

Exporting Records

D. E-Resource Management

Central Knowledge Base

Link Resolution, Usage

Ordering and Activation

Licenses Management and Amendments

E. Digital Asset Management

F. Fulfillment (Circulation)

General

Fulfillment Policy Tables

Checkout/Check-in

Request Management

Renewals

Calendars

Notices

Patron Management

G. ILL (Resource Sharing)

H. User Management

I. Reporting and Analytics

J. Discovery System

General

Functional

User Interface

K. Support and Maintenance Services

L. Service Level Agreement

6. Contract Type

7. Place of Performance

8. Anticipated Period of Performance

9. Deliverables/Delivery Schedule

10. Post-Award Administration

11. Evaluation Criteria

12. Non-Personal Services and Inherently Governmental Functions…………………………………………………27

13. Organizational Conflicts of Interest ……………………………………………………………………………………………..28

14. Rights Data………………………………………………………………………………………………………………………………..28

15. Access to the National Institute of Health )NIH) Electronic Mail…………………………………………………29

16. Ackowledge of Federal Funding………………………………………………………………………………………………….29

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

Appendix B: Security

1. Project Title

Alma/Primo VE Library Services Platform and Discovery System

2. Background The mission of the National Library of Medicine (NLM) is to acquire, organize, preserve, and disseminate biomedical and health information to promote the progress of medicine and public health. The library fulfills this mission by (1) building and maintaining a comprehensive biomedical collection, currently the largest in the world; and (2) by providing onsite and desktop access to this collection to researchers across the nation.

NLM manages the rich bibliographic data of its collection using Alma, a cloud-based Library Services Platform (LSP); and the library provides desktop access to its collection through the Primo VE Discovery System (DS). In addition, Alma and Primo VE are the main tools that provide full support of the traditional library functions such as acquisition, circulation, holds, and user account management.

Both Alma and Primo VE were purchased by NLM from Ex Libris in 2020 to replace NLM’s legacy online public access catalog and integrated library system that had been in use since 1998.

NLM completed the migration from the legacy systems to Alma and Primo VE in June of 2021, modernizing its workflows and making use of the new technological capabilities of the acquired cloud-based systems. NLM aims to continue to rely on a modern, state-of-the-art LSP that supports managing bibliographic and holdings data in electronic, print, and other formats. NLM also searches for a DS that will improve researchers’ access to biomedical information and meet user expectations for information search and retrieval.

3. Objectives The objective of this Statement of Work (SOW) is the procurement of a FedRAMP-compliant cloud-based LSP and DS from an industry leader with technical expertise, experience, and resources for ongoing support for the National Library of Medicine as it strives to fulfill its mission.

4. Scope of Work The contractor shall provide a FedRAMP-compliant cloud-based LSP and DS as well as the technical, management, and support services for maintaining the platform.

https://www.govinfo.gov/content/pkg/USCODE-2011-title42/html/USCODE-2011-title42-chap6A-subchapIII-partD.htm

5. Task Areas The vendor shall be FedRAMP authorized to provide a cloud-based LSP and DS. It shall provide the most cost-effective library management solution in the industry. The LSP and DS 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 furnished by the vendor 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 LSP and DS 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 provide at least quarterly releases of new features and monthly bug fixes 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 Central Knowledgebase Analytics Digital Asset Management Discovery

6. 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 system at least twice a year.

7. The system shall support materials tracking, including, but not limited to, workflows that send records from acquisitions to cataloging, assign records to catalogers, and retain transient and temporal data in the workflow.

Application Programming Interfaces (APIs)

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 integration 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 for the management and scheduling of jobs.

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/remove/reorder widgets of report outputs on the dashboard.

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

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

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

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

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

10. 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

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 system.

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, GOBI, ProQuest, Harrassowitz, and others. Staff users shall be able to search online vendor systems for an item and then automatically transfer the order information to the system 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 at least the following purchasing workflows:

• 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 needs to accept donations.

8. 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.

9. 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 the availability of resources before placing orders via a vendor selection platform.

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

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

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

13. The system shall allow a variety of order templates to be created and used.

14. 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.

15. 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:

a. Single-title monograph

b. Serial monograph

c. Issues of a serial

d. Subscription

e. Monograph

f. Standing Order

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

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 the resources that are purchased in various formats such as physical and electronic, for example.

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 fund 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, and encumbrances.

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

8. 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 at minimum provide support for storing and managing records in BIFRAME format. In addition to storing and managing records in BIBFRAME, native support of BIBFRAME record creation should be on the roadmap with an expected completion by 2026.

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 the 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 record the history of activities on a holding record.

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

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

7. 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.

7. The system shall provide the ability to create item record templates.

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

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 the ability to create physical item description templates.

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

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

5. 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 record 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, or 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 the searching of 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 holding 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 a journal search 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. The system should include an electronic activation task list, and the ability to set a due date for each activation task.

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

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

8. Contact information for technical support billing/payment, licensing and other contacts

9. URLs and login information for resource administration

10. Access parameters

11. Type of purchase

12. 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.

3. The system shall potentially synchronize with the library's digital repository allowing updates in Alma to be published back to the repository that supports OAI-PMH harvesting.

F. Fulfillment (Circulation)

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.

4. The system shall offer the option to anonymize loans, fees, and resource sharing requests.

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/Check-in

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

2. The system shall provide a 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, or 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.

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.

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. The system will maintain an ongoing link between the role profile and the user record.

3. It shall be possible to purge user records.

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 aspects of the system’s data, including, but not limited to MARC fields, acquisitions, library holdings, fulfillment, and system administration data, for report creation and is an integral part of the system.

2. The system shall include functionality for visualizing data.

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

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

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

6. 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).

7. The system shall support the ability to export full MARC records in either XML or Binary formats.

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

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

10. 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.

11. 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.

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

13. 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).

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

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

16. The system shall provide a robust statistical reporting functionality for the library to create reports for monitoring and assessing usage of the discovery system.

17. Authorized library staff shall be able to distinguish statistics based on user groups – external (i.e., users who access the discovery system from outside of the NLM IP range), and staff users.

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

J. Discovery System

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

2. The discovery system 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 system 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 system 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 system session time-out limit shall be configurable by the library.

Functional

1. The discovery system 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 system 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 system shall allow users to perform browse search by author, subject heading, title, call number, and series.

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

5. The discovery system 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 system 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 available for the library to enable, including, including “Did you mean?”, auto complete, alternative spelling, vernacular search and retrieval, and character normalization.

8. The discovery system shall allow users to refine their searches to specific facets and limits.

9. The discovery system 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.

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

11. The discovery system 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.

12. The discovery system shall allow users to sort result sets by various parameters – e.g.:

relevance ranking, title, author, date (ascending and descending).

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

14. The discovery system shall allow users to output search results via email, printing, and citation managers. The system shall allow external software to export search results in MARC or another library metadata format.

15. The discovery system shall allow users to search and use it without signing in. The system 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.

16. When signed in, the discovery system 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.

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

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

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

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

21. The discovery system shall support integration with web-based analytics discovery, including, but not limited to Google Analytics, and survey tools like Qualtrics.

22. The discovery system 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 system shall provide a customizable look and feel consistent with current web design standards, such as responsive web design.

2. The discovery system shall use consistent navigational elements.

3. The discovery system 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 system shall identify and manage the display of duplicate records within search results.

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

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

7. The discovery system 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. Support and Maintenance Services

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 on 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.

4. The vendor shall provide Notification of scheduled downtime one week in advance at a minimum, and the downtime will be scheduled in low use periods—between midnight and 6:00 am EST Monday through Friday or 6:00 pm and 6:00 am EST on weekends.

6. Contract Type

This Task Order is Firm Fixed Price as described under Federal Acquisition Regulation (FAR) 16.202.

7. Place of Performance

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

8. Anticipated Period of Performance

This requirement consists of a 12-month Base Period with four (4) successive 12-month Option periods.

9. Deliverables/Delivery Schedule

The vendor shall follow NIH/NLM security rules to provide services, ensured application/system/web security, and fix security vulnerabilities within required time frame.

The vendor shall employ a technical approach, organizational resources, and management controls to achieve cost, schedule, and performance requirements throughout Contract execution.

The vendor shall meet with the NLM Project Officer/Manager on a regular basis and provide information that includes but is not limited to progress updates on implementation, schedule, training, testing, etc.

At the request of the Contracting Officer’s Representative, the vendor shall provide deliverables, including written reports, presentations to NLM staff, and other materials. Technical documentation shall adhere to the CMM level 3 standards of life cycle management and written clearly and correctly. All documents provided shall meet Section 508 compliance standards.

Electronic documents delivered must be made available in alternate formats when requested by the COR, including formats compatible with assistive technology, at no additional charge.

All documents required herein shall be submitted in electronic format. In addition, one hardcopy of each document shall be submitted to the COR.

All paper/hardcopy documents submitted under this SOW shall be printed or copied, double-sided, on at least 30 percent post-consumer fiber paper, whenever practicable, in accordance with FAR 4.302(b).

Requirements for accessibility based on Section 508 of the Rehabilitation Act of 1973 (29 U.S.C.

794d), with updates from the “Information and Communications Technology (ICT) Final Standards and Guidelines (36 CFR Parts 1193 and 1194), are determined to be relevant under this SOW for the following program needs:

The historic Section 508 Standards applicable to this SOW:

1194.22 Web-based intranet and internet information and applications

1194.23 Telecommunications products

1194.24 Video and multimedia products

1194.31 Functional performance criteria.

1194.41 Information, documentation, and support

The ICT Section 508 ‘refresh” also directs conformance with WCAG 2.0 standards (Levels A and AA).

All electronic documents submitted shall be conformant with Section 508 and the ICT. Additional information about testing documents for Section 508 compliance, including specific checklists, by application, can be found at: http://www.hhs.gov/web/508/index.html under "Making Files Accessible." Document formatting instructions and checklists can be found at . The Government reserves the right to inspect and evaluate any document for Section 508-conformance and accessibility.

Major contract deliverables and estimated due dates are…