SOW Library Services Platform 3-17-2022 - NIST-AMDSS-F-22-02.docx

Statement of Work (SOW) For Cloud-Based Library Services Platform (LSP)

Contents

1.0 Background

The NIST Research Library and Museum seeks to improve library users and staff experiences with enhanced interoperability, resource discovery, and streamlined workflows for the management of its electronic and physical information resources and collections by acquiring and implementing a comprehensive, integrated, cloud-based Library Services Platform (LSP), also referred to as “the system” to replace the current set of disparate systems including:

a) Integrated Library System (ILS)

b) Online Catalog

c) Discovery Layer

d) Electronic Resource Management System (ERM)

e) OpenURL (Uniform Resource Locator) Link Resolver

f) Digital Archive Repository

g) Museum Collection Management

2.0 Objectives

The system shall provide unified and efficient management of all resources that the NIST Research Library and Museum owns, licenses, stewards, and makes available to end users for discovery and delivery. In addition, the comprehensive solution shall enable library users to quickly and accurately access NIST’s electronic, physical and local collections, bibliographic data, and full text content of its electronic assets.

This requirement is intended to replace an existing set of disparate legacy library systems with a cloud-based, state-of-the-art solution that integrates a wide-range of required functionality.

Identified below are additional areas to consider ensuring project success:

· Data migration from multiple sources

· Outages or disruption to operations

This requirement is issued by NIST for the purpose of soliciting fully priced proposals in the provision of an LSP with the following objectives:

2.1 Provide a fully implemented solution together with software licenses and professional services to design, configure, and implement an LSP.

2.2 Replace existing Integrated Library System (ILS), online catalog, Discovery Layer, Electronic Resource Management System (ERM), OpenURL Link Resolver, Digital Archive Repository, and Museum Collection Management capabilities as deployed into a unified system.

2.3 Support the following library processes within the unified system: Acquisitions Management, Cataloging and Authority Control, Circulation, Metadata Management, Holdings management, Serials management, Local collection/asset management, and Interlibrary loan.

2.4 Support the following library patron processes within the unified system: Self-service portal, account settings options, request initiation, and past usage.

2.5 Standardize on a common set of procedures used to provide insight into the operations of library collection and user management.

2.6 Implementation shall consist of a phased deployment schedule recommended by the Offeror in accordance with NIST’s specified short-term and long-term goals.

2.7 Provide a browser agnostic system with access configuration capabilities by user type.

2.8 Provide multiple instances or environments of the LSP for change management/test, user acceptance testing (UAT), and production to ensure testing consistency and to reduce upgrade risks.

2.9 The successful LSP will be aligned to the key business goals to improve efficiency, increase satisfaction, and use of self-service, produce accurate, real-time results.

2.10 NIST expects to yield these outcomes:

· A contemporary, cloud-based system to function as the go-to library interface for patrons and staff, while growing and adopting new technology advances and capabilities for the long-term.

· A comprehensive system that integrates discovery, print and electronic resource management, acquisitions, interlibrary loan functions, and museum and digital artifacts management into one platform.

· A feature-rich , and logical self-service interface for patrons to gain capabilities currently beyond their reach, as well as experience increased accuracy in searching information resources.

· Optimized interfaces and efficient workflows to provide Library staff with more time to focus on enhancing customer services.

3.0 Scope

The Offeror shall provide a LSP system, such that a fully functioning solution is provided to NIST to perform day-to-day functions as patrons (~3,000 people), library staff and system administrators (~25 people), as outlined in the requirements. NIST expects this contract effort to successfully implement the configuration, deployment, training, support, and maintenance of the solution.

4.0 Specifications

The Offeror shall provide an LSP that is preconfigured to support library processes and environments.

4.1 General Requirements

4.1.1 Offeror Role

The Offeror is required to:

a) Provide a test environment/sandbox for testing customizations and batch data modifications.

b) Proactively communicate scheduled downtime and unplanned downtime occurrences.

c) Provide a transparent product enhancement-request process, soliciting input from customers.

d) Track trends and technological advancements in the library and archives professions and incorporate these advancements into the system long-range design.

e) Provide upgrade schedules and notifications with documentation in advance of upgrades or changes to the system.

f) Provide all license agreements related to the system.

4.1.2 Interoperability

The system should maximize options for communications and exchange of data with other systems. The government would issue a separate contract for integrations beyond the scope of this implementation. External systems might include financial systems, customer interaction systems, union catalogs, registries, or NIST-developed systems.

The system shall:

a) Support bi-directional APIs (Application Programming Interface) and web services that enable the library to extend functionality.

b) Provide documentation and support for APIs and web services.

c) Support current and future standards and frameworks (see appendix) for all record and data types including, but not limited to, acquisitions, licensing, and bibliographic and authority control formats.

4.1.3 Staff Workflow

The system shall provide the following:

a) Allow library staff to work in multiple record types/functions/system components concurrently, without losing current work.

b) Provide customizable workflow notifications across the platform, such as dashboards, emails, and alerts.

c) Support customizable relational views of system data across record types (e.g., bibliographic, acquisitions, patrons, usage data) without requiring administrator assistance.

d) Support data selection by Boolean operators and regular expressions in searching, modifying, and reporting out on data.

e) Support customizable, automatic, and ad hoc email notifications to patrons and library staff

f) Support the assignment of granular roles and permissions for staff users including view only or edit permissions.

4.1.4 Support

The Offeror shall provide the following documentation and services:

a) A test environment which facilitates applying configuration changes without impacting the production system or interfaces. The test environment shall duplicate the NIST production system and interfaces to facilitate quality testing.

b) Routine tasks, potential customizations, and updated systems functions are well documented and provided to the library staff. All documentation and knowledge base articles are searchable.

c) Provide backup and restore services.

d) Customer support is available through multiple channels including phone (7:00 AM – 7:00 PM Eastern Time, Monday – Friday), web-based ticketing system (24/7/365), and email (24/7/365) and should include direct access to technical support engineers

e) Response time to system outages or incidents which render the system or system components unusable is within 2 hours with updates every 4 hours until resolved. Response time to incidents with lesser impact is within 8 hours with daily updates until resolved.

f) Prioritization and tracking of support requests are transparent. Customers determine when to close a ticket or can easily re-open it.

g) Provide documentation on known issues.

h) Provide a communications infrastructure for user groups.

4.2 Patron Interface

The system shall provide a discovery layer that supports searching across all electronic and print content, including NIST-created assets. It must be an intuitive interface and support library-staff customizations. It must provide an interface to patrons’ authenticated accounts where they can track their activity as well as set personal preferences.

4.2.1 Discovery

The system shall support integration with Google Scholar so that library holdings display alongside Google Scholar results.

In addition, the discovery interface must:

a) Provide a 508-compliant, intuitive, and easily navigated, search interface.

b) Be in a responsive design format.

c) Display cover images, supplemental information (e.g., tables of contents, reviews), and the context of search term.

d) Reflect updates to metadata records and holdings in real time.

e) Display search suggestions (“did you mean”).

4.2.2 Searching

The system shall provide a single search interface that draws from the following sources:

a) A central index that includes electronic content from a wide variety of sci/tech publishers and databases, such as, but not limited to: ASME (American Society of Mechanical Engineers), Elsevier, IEEE (Institute of Electrical and Electronics Engineers), Springer-Nature, Royal Society of Chemistry, Wiley, Web of Science, Knovel Engineering, Association for Computing Machinery (ACM).

b) NIST's historical collections including museum artifacts, archives, and digital assets.

c) Print collections.

d) NIST produced content, such as NIST Technical Publications

e) Search results must be driven by relevancy rather than Offeror preferences.

Searchers must be able to:

a) Limit and refine search results by delivered and library-created facets.

b) Choose to search full-text, metadata only, or by specific fields.

c) Conduct complex searches including the use of Boolean operators, wildcards, and exact string matches.

d) Sort results by relevancy, publication date, title, author, or collection.

e) Limit searches by the type of content such as journal, article, or book.

f) Browse the collection by call number.

g) View an A-Z list of the library’s collections.

4.2.3 Search Results

a) Seamlessly link to electronic content.

b) Seamlessly link to NIST’s digital repository collections.

c) Clearly identify the source of articles and book chapters in search results.

d) Display licenses, terms, and conditions and any limits on simultaneous users of electronic resources.

e) Provide an option to display the full MAchine Readable Cataloging (MARC) record.

4.2.4 Library Customizations

The system shall allow Library staff to:

a) Configure the discovery interface without Offeror intervention including branding and styling.

b) Showcase specific collections.

c) Suppress the display of missing and lost items, and individual titles selected by Library staff.

d) Designate which fields and the order of fields that display in an item detail record.

e) Disable the display of fines and fees information in the patron’s account interface.

f) Customize which fields of bibliographic records are indexed and available for search.

g) Modify search algorithms to fit its patron’s research needs.

h) Create patron-facing announcements at the resource/title level.

4.2.5 Patron Accounts

The patron must be able to:

a) Access their own account to track checkout history, renew items, submit and track requests (including purchase requests), and set preferences.

b) View and track two-way communication between Library staff and patrons.

c) Checkout items with their mobile devices.

d) Save search results to personal lists as well as export those lists to reference management tools.

e) Create and store queries/search strategies for future use.

f) Set up push notifications based on preferences such as subject, author, or saved search strategies.

g) Auto populate interlibrary loan requests based on search results.

h) Receive immediate feedback on why a checkout or renewal of an item is disallowed.

4.3 Collection Maintenance

The system shall manage and support the collection maintenance lifecycle and processes, including tracking, check-in/check-out, loaning, resource history, manage holdings, and obtain collection information on-demand to ensure accurate collection maintenance and metrics of electronic and physical resources. The solution must have the ability to customize and automate workflows, templates, and notifications for various roles in collection maintenance, such as serials technician, library technician, and circulation desk staff.

4.3.1 Circulation

The system shall include functionality in support of circulation functions and activities to include:

a) Generate and print a list of items a patron has checked out at point of service.

b)

c) Retrieve borrower records via specific bibliographic, item, or patron fields.

d) Assign no due date and the override loan and renewal limits including for items identified as non-circulating.

e) Allow global changes to due dates for items currently checked out.

f) Track “in-house use” for physical items that are used within the library but not physically removed from the library.

g) Check-out or change status of an item without requiring that it be discharged first.

h) Retain individual book checkout histories and patron circulation histories.

i) Support capture of offline circulation activities.

j) Manage patron records, including creation, modification, and deletion in batches or as single records.

k) Tag items as non-circulating.

l) Integrate interlibrary loan directly into circulation workflow by including processing of incoming and outgoing interlibrary loan items.

The library must be able to:

a) Define loan periods and renewal limits based on material type, location, and user profile.

b) Customize patron blocking option to prevent check-out.

c) Customize alerts, such as, queue priority alerts to staff when items with holds are available (checked-in)

d) Automate real-time alerts to patrons when holds are available for pickup.

e) Customize patron record fields including field labels, length, and number of fields.

4.3.2 Holdings Management

The system shall support holdings management to include:

a) Holdings that are updated in a single interface, are automatically pushed to the discovery layer, electronic resource manager, and WorldCat as applicable.

b) Batch changes can be applied to a set of holdings or items.

4.3.3 Print Serials Management

The system shall support the processing of serials, including receiving and claiming, generating items, labeling, and routing including:

a) Searching by ISSN (International Standard Serial Number), ISBN (International Standard Number) or Title during the check-in process

b) Routing of print materials including, but not limited to the ability to print routing slips

c) Automatically send electronic claims of missing serial issues to publishers.

d) Generate statistics from serial records (such as the number of active subscriptions, number of pieces received, etc.)

e) Support the use and customization of serials prediction patterns.

4.4 Metadata

The system shall serve as the central location to manage and support metadata lifecycle and processes, including editing, formatting, and converting to different metadata formats. The solution must have the ability to customize and automate workflows, templates, and notifications for library staff. In addition, specific requirements are elaborated below.

4.4.1 Creating and editing metadata records

The system shall:

a) Provide standard catalog format templates and support the creation of local templates including pre-populated MARC fields and subfields.

b) Automatically append MARC fields into records that are copy cataloged.

c) Edit records individually and in batches without using external tools.

d) Support overlaying existing records with records pulled from external sources such as Library of Congress, OCLC, or vendor records, both individually and in batches.

e) Provide context-sensitive links to external metadata reference tools such as Cataloger’s Desktop, RDA (Resource, Description, and Access) Toolkit, or Classification Web.

f) Support flagging of brief records for further editing.

g) Support record validation:

a. h.1 Metadata editor supports validation of fields

b. h.2 Include an URL checker

4.4.2 Identifying and extracting metadata records

Cataloging staff must be able to:

a) Identify and pull records that are missing specific fields

b) Identify and gather records with regular expressions

c) Extract records in lists and raw MARC by the following criteria:

i. Any MARC field, call number or call number range, publication date

ii. Date and range of dates of cataloging, modifying, and deleting records

iii. Staff member who worked on the record

iv. Item information (e.g., type, location, date last inventoried)

4.4.3 Importing/Exporting

The system shall support the following functions:

a) Import of catalog records from any MARC or RDA based cataloging source, in both single record and batch modes.

b) Automated process to push updated MARC records from the solution out to other repositories in a variety of schema.

c) Conversion tools or utilities within the solution that translate one metadata schema to another for import and export. Example of schemas include: MARC21, MARCXML, BIBFRAME, Dublin Core, JSON, RDF, MODS, METS, PREMIS, EAD, Crossref MDR schema (see glossary), delimited text file.

4.5 Electronic Resources

The system shall provide a fully integrated mechanism for the management of the entire life cycle of electronic resources, including trials, selection, activation, delivery of content and cancellation. The system shall provide for a variety of efficient workflows and integrate print and electronic resource processes. It must integrate with acquisition workflow elements and eliminate the need to have a supplemental tracking system outside of the solution.

4.5.1 Electronic Resource Management (ERM)

The system shall provide workflow management of electronic resources, such as reminders for renewal or the ability to track new resources from trials through to rollout.

The system shall manage the following types of administrative information:

a) Vendor description and contact information, including multiple contacts and roles for a single vendor.

b) Customized templates for licenses.

c) Associate license agreements with resources. The system shall be able to handle prevailing licenses and have the ability for staff to select to which license to display to the patron.

d) The ability to output electronic resource records for integration into library websites and discovery solution.

e) Store IP ranges, general information such as the library’s address, email addresses, and relevant URLs (such as link resolver, library website, etc.)

4.5.2 Alerts, Menus, Notes

The system shall have the ability to customize and automate workflows, templates, notifications, menus and dropdowns, and notes for various electronic resources roles. The system shall have the ability to create notes and export these notes in the form of a report, Examples for filtering are:

a) Contacts, licenses (authorized users, physical location, remote access, status, terms of use, license type).

b) Payment information (consortium, payee information, payer information, payment types, currency codes).

c) Renewal status.

d) Resource status (current subscription, cancelled, discontinued, free, open access, archived, etc.).

4.5.3 Knowledge Base

The system shall provide the following knowledge base support:

a) Provide an extensive repository of authoritative e-resource metadata for full-text journals and e-books.

b) Maintain the integrity of this metadata to ensure the accuracy of the library’s content providers.

c) Normalize resource metadata between different providers that offer the same journal or e-book, allowing for different representations of the same resource to be found and accessed through an A-Z list and link resolver.

d) Provide accurate data that facilitates resource discovery, including accurate linking from referring sources (databases, Google Scholar) to full text to journals and books when the naming conventions are inconsistent.

e) Allow for the creation of titles not currently in the Offeror-provided Knowledge base.

f) Allow for activation of library resources at the package and title level.

g) Alert library staff when changes are made to the Knowledge base, such as, moving a database from one provider to another, moving some or all titles from one database to another, removing some or all titles from a database.

h) Provide a periodic summary of changes to the knowledge base.

i) Allow for the legacy information about database changes to be migrated for historical need. Examples are contact information, title lists, license information, cost, payment, usage information, etc.

4.5.4 Link Resolution

The system shall ensure reliable links to electronic resources by supporting link resolution standards including OpenURL, context sensitive services and resolving the services.

In addition, specific requirements are elaborated below:

a) Augment the OpenURL metadata with Crossref, OAI, or PubMed data, when available.

b) Allow for the creation of dynamic URLs for local electronic collections and override linking provided by the Knowledge base if desired.

c) Allow the library to customize the resolver’s services menu.

4.5.5 Usage and Cost

The system shall produce accurate usage and cost information. Specific requirements are elaborated below:

a) Provide monthly auto-harvesting of usage data for collection analysis, either through a direct retrieval service or automated SUSHI harvesting, preferably according to the Code of Practice Release 5.

b) Track cost and usage data at the database, package, and title level and provide cost per use and other collection analysis in a variety of reports and/or charts and graphs,

c) Track publisher information for obtaining access to statistics at the publisher website such as the website URL, username, and passwords.

d) Retain cost and usage data indefinitely.

4.5.6 Activation

The system shall provide a streamlined workflow for the selection and activation of a resource. The activation of a resource should be in real-time and be available immediately. This activation process should extend throughout the system including the patron interface.

The system shall:

a) Display changes in holdings, activation, cancellations, trials, and license terms in real-time.

b) Obtain and record pricing, product descriptions and reviews for electronic resource products.

c) Notify library staff when a collection has been activated.

d) Automatically add bibliographic metadata to the catalog upon package or title activation.

e) Include an electronic activation task list, and the ability to set a due date for each activation task.

f) Allow for exporting and importing library title list for ingesting information into the system as well as exporting title lists for analysis and collection development decisions.

g) Provide an option for globally updating electronic resources.

h) Support Knowledge Bases and Related Tools (KBART) automation.

4.5.7 License Management and Amendments

The system shall allow for uploading of licenses and allow for the linking of addendums, and year-over-year linking to contracts, as well as:

a) Viewing all the electronic resources linked to a license

b) Support loading licenses in ONIX-PL format.

c) Provide license templates that can be customized as needed.

4.5.8 Managing Shared Resources

The system shall have the ability to differentiate ownership, manage access, and display content and license information for resources that are shared and non-shared.

4.6 Acquisitions

The system shall manage and support the acquisition lifecycle and acquisition processes, including ordering, receiving, invoicing, claiming, auditing, and payment to ensure acquisitions management of electronic and physical resources. The system shall have the ability to customize and automate workflows, templates, and notifications for various user roles in acquisitions, such as acquisitions librarian, serials technician, and bank card holders.

In addition, the system shall:

a) Support Electronic Data Interchange (EDI) and importing/exporting information needed for automated ordering and invoicing.

b) Store acquisitions data in relationship to bibliographic and item data, such as linking an order to multiple bibliographic records. Information and bibliographic data must be readily available for both physical and digital resources.

c) Include overlap analysis reports for electronic resources, allowing the library to see duplication of resources to assist with making collection development decisions. The system must have the ability to upload a list of titles that the library is considering acquiring to determine whether the title(s) are part of the library's collection.

d) Support subscription management by storing multiple entries for different types of contacts within a subscription provider’s record, for example, adding or subtracting resources per a given year, changes in title lists, amendments to contracts, etc.

4.6.1 Purchasing, orders/contracts

The system shall:

a) Support one-time and continuous or subscription orders and support auto-renewal and manual renewal for electronic resources.

b) Automatically create purchase orders based on vendor-supplied MARC records.

c) Allow for searching bibliographic records in external databases through an online interface via Z39.50 or SRU/W and importing resulting records to the catalog.

d) Support tracking the acquisition of gifted or gratis items.

e) Have ability to upload and/or scan information such as statement of work, contracts, license agreements, titles lists, and other documents.

f) House addendums to contracts and licenses and maintain relationships between parent and child contracts for various years.

g) Display purchase order history for each electronic resource.

4.6.2 Receiving, invoices and payments

The system shall have an integrated invoice management capability to store invoices from the purchase order, or to load invoices from a spreadsheet. It must retain invoice and license history and alert staff to duplicate invoices.

4.6.3 Claims

The system shall:

a) Automatically generate notifications/alerts when items have not arrived after a library-defined grace period.

b) Support automatic claiming as well as manually generated claiming.

4.6.4 Funds management

The system shall:

a) Support accrual accounting by allowing the cost of an order to be split between funds or fiscal years.

b) Support end-of-fiscal year activities including transferring encumbrance amounts into the new year.

c) Alert staff when invoices are linked to over expended budgets and allow for partial payments and additional charges to be added to the invoice, when authorized.

d) Display contract information for resources, either in a customizable template, or a vendor delivered template with NIST-specified fields.

e) Link contract information to resources at the title level, including links to all supporting order history, financial history, funding source, and to other related acquisition information and data, such as vendor information.

f) Have the ability to upload the history and supporting documents to a base contract, (e.g., invoices, contracts, supporting documents) all linked together in a logical manner with the ability to recall individual, title-level information, as needed.

4.6.5 Trials and evaluations

The solution may support the configuration of trials for both electronic collection packages and databases to evaluate electronic resources before purchasing. 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.

4.6.6 Resource Vendors

The system shall integrate with online vendors such as Amazon, Gobi, etc., including the ability to find items for purchase from multiple vendors, and the ability to import complete MARC records (when available) for ordered items prior to receipt.

Library staff must be able to:

a) Create, store, and share vendor records, including contact information for multiple accounts to a single vendor.

b) Designate vendor type (e.g., licensor, licensing agent, content owners, subscription agent, access provider, vendor/payee).

c) Retain copies of all communications between the vendor and the library staff, which are either generated by the system, such as claims, or by library staff.

4.7 Reporting and Analytics

The system shall provide Library staff the ability to use canned reports or manually generate reports and dynamic dashboards without requiring programming knowledge and without Offeror intervention or assistance. Customization of reports by staff includes, but is not limited to, change of reports parameters, views, date range, time range, and organizational layers. The system shall store records, data, and reports from library processes indefinitely.

In addition, specific requirements are elaborated below.

The system shall provide:

a) A comprehensive and integrated reporting and analytics component that covers all the solution’s data, including, but not limited to all MARC fields, item level records, acquisitions, fulfilment, digital assets, e-resource management functions, usage and histories by organization and user, and system administration data, for report and/or dashboard creation.

b) Reports that distinguish statistics based on type of user, such as, patron, library staff, organizational attributes, and groups of users.

c) A variety of output options including, but not limited to, viewable online, print, email, and export to XML, CSV, TXT, PDF, and XLS.

d) Support of one-click drill-down reporting from a graphic or gauge to a list of those results.

e) Offer automatic scheduling of reports (static and real-time) at defined intervals (daily, weekly, or monthly).

f) Role-based report generation and viewing such that a user will only be able to view reports and data according to their role.

g) Dashboard options in which it is possible to monitor status, view user-specific tasks, and detect trends. Information in the dashboard shall be based on staff user roles, allow for customization, and support embedding of charts, gauges, or information.

h) Trend analysis of historical data (such as usage, expenditure, views).

i) Statistical reporting functionality for monitoring and assessing usage of the discovery layer.

j) Acquisitions analytics for performing overlap analysis and budgeting reports with full data access and a graphic display of fund balance, allocation, expenditure, and encumbrances. For example, report with data visuals, year-over-year comparisons with cost data and usage trends for a multiyear period.

k) Electronic resource analytics for performing management functions of print and electronic resources, such as, title lists from subscribed packages and databases, e-book reports: deselection reporting features to compare physical book usage with e-books to assist with identifying low use titles, summary view of metadata, subscription reports, duplicate titles reports, license data reports, and link resolver reports

4.8 Training

The Offeror shall provide training to all users on how to use the system. Training shall be offered to users on an ad-hoc basis. More detailed training shall be developed and provided to users who request such training. Group training, such as administrative training and portal training, shall also be provided. The Offeror shall develop and provide additional training as necessary based on Library staff and testing needs.

The Offeror shall provide a comprehensive training program that shall include the following but not be limited to:

a) Onsite, or webinar-based training for all functions to library staff and patrons on applicable functions.

b) List the training that the Offeror shall provide pre-implementation, post-implementation, and throughout the use of the system.

c) Complete system documentation and training materials including on-demand print and videos available online.

d) Marketing materials, which can be customized by the Library with its own branding.

e) Training materials available as context-based help within each system module.

5.0 Deliverables

Delivery Schedule

5.1 General

NIST requires the delivery of a plan for providing professional services for the configuration, deployment, training, support, and maintenance of an integrated LSP solution that includes:

a) Implementation plan

b) Application architecture and design (hardware and software) including licenses.

c) Pragmatic subject matter implementation expertise (process and data).

d) Application and interface configuration.

e) Application testing and deployment.

f) Support & maintenance.

g) Upgrade assurance.

h) Training.

5.2 Implementation and Quality Assurance Plan

The Offeror shall provide a plan for:

a) Assessment of NIST Research Library systems and processes.

b) Design, configuration, installation and testing to ensure the application meets requirements as set out in this request.

c) System integration (e.g., user records, email).

d) Data migration and testing such as bibliographic, historical usage and historical acquisition data

5.3 Training

Provide a comprehensive training program including all system functionality needed to hand-off the system to NIST. Conduct training and supply materials as specified in section 4.9 above.

5.4 Reporting and Analytics

Provide the customized reports and dashboards outlined in Appendix A – List of Reports.

5.5 Technical Support

Provide details on customer support operations as specified in section 4.1.4.

5.6 IT Security

If an Authorization to Operate (ATO) letter or a 3rd party audit is used as evidence that the Offeror has been assessed and authorized, it must be provided within 30 days of the contract award. (See Section 7.0 Security Requirements for deliverables.)

6.0 Government-Furnished Property (GFP)/Equipment (GFE)/Information (GFI) NIST will provide documented information of procedures, notifications, and workflows to explain existing application connectivity, integrations, and manual actions to support the implementation process and to inform the Offeror of integrations

7.0 Security Requirements

The LSP solution shall be a cloud-based solution which adheres to definitions per the NIST Special Publication 800-145 (https://doi.org/10.6028/NIST.SP.800-145) for a Software as a Service (SaaS), and Deployment Model

7.1 IT Security

The Contractor shall have FedRAMP authorization or an Authorization to Operate (ATO) letter issued by a Federal Government agency as evidence that they have been assessed and authorized. If using an ATO letter, that letter shall clearly state the impact level (low, moderate, or high) at which the Contractor has been assessed and authorized. If subcontractors are involved, each party shall have the above stated FedRAMP authorization or Federal agency-issued ATO letter stating the authorization. While FedRAMP authorization or ATO is preferred, in lieu of the above the Contractor, and/or its subcontractors, may demonstrate that they have passed an independent security audit (e.g., Statement on Standards for Attestation Engagements (SSAE), Service Organization Control (SOC 2) ). Within 30 days of contract award, the Contractor shall provide to NIST, as a deliverable, evidence of the audit or instructions on how to obtain evidence of the above, if the Contractor has had any audits described above or other security audit.

In lieu of FedRAMP authorization, the contractor must undergo an Assessment and Authorization of security and privacy controls and receive an Authority to Operate from NIST and DOC.

Post contract award, the Government will perform a review for a local ATO decision, required for go-live, and ongoing security and privacy assessments for continuous monitoring thereafter. The Government will determine the risk rating of identified vulnerabilities. The Contractor shall respond to the Government with an action plan and schedule to mitigate security or privacy risks found within 10 business days of notification of security or privacy risks. The Government will notify the Contractor of whether or not the action plan and schedule are acceptable. The Contractor shall implement the action plan according to the agreed-upon schedule.

The solution’s security controls must meet the requirements laid out in Security and Privacy Controls for Information Systems and Organizations NIST Special Publication 800-53 Revision 5. The level of security controls is based on the impact rating as defined in Standards for Security Categorization of Federal Information and Information Systems (FIPS Pub 199). The impact rating levels for this solution, based on NIST use cases (by security objective), are Integrity = Low, Availability = Low, and Confidentiality = Low.

7.2 Incident Response

The Contractor shall ensure coordination of its incident response team with the NIST Security Implementation and Incident Team (SIIRT), ensuring that incidents are reported consistent with NIST SP 800-61, Computer Security Incident Reporting Guide, and the United States Computer Emergency Readiness Team’s (US-CERT) Concept of Operations for reporting security incidents. Specifically, any confirmed incident of a system containing NIST data or controlling NIST assets shall be reported to NIST Security Implementation and Incident Team (SIIRT) within 48 hours that results in unauthorized access, loss or modification of NIST data, or denial of service affecting the availability of NIST data. The Contractor shall be able to provide any application and operating system logs associated with an incident as well as a file system timeline for potentially compromised hosts and any additional files referenced during forensic analysis upon request. Logging must be enabled and available for up to 90 days. If possible, the Contractor shall be able to provide memory dumps and forensic images of any NIST systems that were possibly compromised.

7.3 Authentication

The Contractor shall work with NIST’s IT department to configure its IT solution to implement to integration with NIST’s Single Sign On (SSO) solution for NIST users. The preferred integration is via SAML to the NIST Active Directory Federation Services (ADFS). The NIST ADFS instance can provide both Kerberos based SSO and Personal Identify Verification (PIV) card authentication for NIST users.

7.4 Internet Protocol Version 6 (IPv6)

The IT solution shall be accessible through both Internet Protocol Version 6 (IPv6) and IPv4. If not already compliant, the Contractor shall provide the NIST with a statement regarding its plans to implement IPv6, including timeframe.

7.5 Section 508

The IT solution shall comply with Section 508 of the Rehabilitation Act (www.section508.gov ).

9.0 Place of Performance

The system will reside with the Offeror.

10.0 Anticipated Period of Performance

August 1, 2022 through July 31, 2023

Options “if exercised” are as follows;

Option Period. 1: August 1, 2023 – July 31, 2024 Option Period. 2: August 1, 2024 – July 31, 2025 Option Period. 3: August 1, 2025 – July 31, 2026 Option Period 4: August 1, 2026 – July 31, 2027

Appendix A – List of Reports

1. List of on-order journals

2. Journals flagged as having a change to access, such as a publisher change.

Appendix B – Standards

https://www.dublincore.org/

Appendix C – Definitions and Acronyms

Authorization to Operate (ATO): Approval to use an IT resource by a Designated Authorizing Official after all security assessment activities have been performed

Crossref: Digital Object Identifier (DOI) registration agency of the International DOI Foundation

Electronic Data Interchange (EDI): Electronical transfer of purchasing documents such as purchase orders or invoices

Electronic Resources: Material accessed through a web browser

FedRAMP: Federal Risk and Authorization Management Program, a government-wide program that provides a standardized approach to security assessment

LCSH: Controlled vocabulary system, Library of Congress Subject Headings

MeSH: Controlled vocabulary system, Medical Subject Headings

Patron: Consumer of Library services

Physical Resources: Printed materials and other physical assets (e.g. equipment or devices)