SOW-DocumentDeliverySoftware-final.pdf

Statement of Work

National Library of Medicine Document Delivery and Interlibrary Loan Request Management System

1.0 BACKGROUND

The mission of the National Library of Medicine (NLM) is to collect, preserve, and disseminate biomedical information. In support of this mission, NLM has assembled one of the largest collections of biomedical literature in the world. NLM makes its collections available onsite as well as to the global library community by offering Inter-Library Loan (ILL) services. The Access Program of the NLM Engagement Branch is responsible for performing NLM’s ILL services.

NLM’s borrowing partners (hereafter, “customer(s)”) include health sciences, academic, government, and public libraries in the United States and other countries. Through ILL, NLM’s customers may request copies of journal articles, book chapters, conference papers, and other brief publications. NLM loans physical copies of monographs (books), audiovisuals, and microforms to U.S. institutions only. About 95% of the ILL requests are delivered via e-mail (PDF), web delivery, and Odyssey (software). Delivery options are based on the customers’ preferred delivery method and NLM’s licensing agreements with publishers.

2.0 OBJECTIVE

NLM processes approximately 100,000 interlibrary loan requests on an annual basis. To respond to these requests NLM intends to procure services for a document delivery and ILL request management system. This system will be managed by a contractor and interface with NLM’s DOCLINE system

3.0 SCOPE

The vendor shall provide a document delivery and interlibrary loan (ILL) request management system and related technical and customer support which will facilitate processing online requests from patrons interested in obtaining resource material held within NLM collections

4.0 REQUIREMENTS

4.1 General

NLM has very specific requirements for a document delivery and ILL management system.

The vendor shall provide a system to facilitate tracking of ILL requests from receipt to delivery.

The system shall also facilitate the scanning of documents on document scanning workstations and the automatic delivery of these documents via the Internet or the tracking of requests to be mailed to the requesting institution. Billing and reporting features are also essential requirements of the system.

There are two types of systems that may be considered for this contract, FedRAMP Authorized systems and non-FedRAMP Authorized systems.

The ILL management system shall accept orders from DOCLINE (DOCLINE® System User Resources (nih.gov)) by methods such as API/JSON or HTTPS POST Request and return the status of those orders by the same method. The vendor shall work with the DOCLINE team to establish either communication mentioned above before the system is implemented. DOCLINE is a NLM product run by a team of federal employees

The system shall also have the ability to automate ILL functions to the degree elaborated below to maintain and/or improve the library’s efficiency and the material turnaround time.

The system shall be able to identify and display requests that are clinical emergency requests or regular requests. Emergency requests or clinical emergency requests have a short service-level agreement (SLA) of two hours and shall be addressed within that timeframe. Regular requests have longer and varying SLAs. All SLAs should be easily identified and requests prioritized accordingly in order to address them efficiently. NLM currently has two library profiles in DOCLINE to address these two separate SLAs.

The vendor shall provide necessary software upgrades as needed as well as all the necessary technical support to keep the system functioning in collaboration with NLM internal technical support staff. The vendor shall respond to and address flagged security threats and provide ad hoc software patches, product development, and customer support. The vendor shall be able to provide custom workflow enhancements in a timely manner to support changing ILL needs and so that customer experience is not significantly impacted.

The vendor shall provide key personnel including a Project Manager, Lead Developer, and other technical staff as needed. The Contracting Officer’s Representative (COR) shall be notified of and approve changes in key personnel staffing after the award of the contract.

The vendor shall be able to make any required updates to the system via WebEx or other web conferencing through the COR.

The Project Manager shall meet with the COR once a month to discuss any problems, concerns, or needs related to policies and procedures, quality assurance, and performance

4.2 System Requirements:

https://www.nlm.nih.gov/docline/newdocline.html https://www.nlm.nih.gov/docline/newdocline.html

FedRAMP Authorized for the cloud or not FedRAMP Authorized to be hosted by NLM. For the vendor’s system to work for the NLM, the system shall be fully functioning at time of award, with minor customizations to be completed within a timeline agreed upon between the vendor and NLM

FedRAMP Authorized A cloud-based system shall be FedRAMP Authorized and shall be FedRAMP Authorized to provide a cloud-based ILL Document Delivery services. The system shall support access for Crystal Reports and similar reporting tools, or the system shall itself provide reports and support requests for custom reports, for purposes including but not limited to request tracking and billing.

Not FedRAMP Authorized The system shall be internally hosted by NLM. NLM requires that the system be MS Windows compliant and network-based. The vendor shall support a SQL Server Database internally hosted by NLM. The system shall support access for Crystal Reports and similar reporting tools.

The vendor shall provide monitored remote server and database system support to the NLM site as scheduled.

From this point, requirements related to FedRAMP Authorized systems shall be labeled as [Cloud-based]. Requirements related to non-FedRAMP Authorized systems shall by labeled as [Hosted by NLM]. Any paragraphs without those labels applies to both types of systems.

1. The system shall have record locking to prevent multiple users from accessing the same request at once. The system shall operate with scanners capable of reproducing journal articles at the rate of at least 40 pages per minute. The system shall be able to work with other third-party machines including but not limited to the following: laptops, printers, Fujitsu Document Scanner fi-7700, Konica Minolta SL1000 Microfilm, Konica Minolta ScanDIVA.

2. The system shall connect to the DOCLINE system via DOCLINE API/JSON or HTTPS POST Request and shall be able to identify and display requests that originate from DOCLINE as clinical emergencies or regular requests. NLM has two DOCLINE library accounts. One account creates only clinical emergencies and the other account creates only regular requests. Unsupported File Transfer Protocol (FTP) is not acceptable.

3. The system shall connect every 15 minutes at minimum to retrieve requests for NLM ILL and to update the status of NLM ILL requests in DOCLINE.

4. The system shall have record locking to prevent multiple users from accessing the same request at the same time. On average, NLM receives roughly 200 requests a day. This process shall be automated.

5. The system shall be able to communicate with other resource sharing systems, e.g., ILLiad, RapidILL, etc. This system shall be compatible with the various document delivery protocols used by NLM’s global patrons, including delivery methods such as Post to Web and Odyssey. If the request is fulfilled via Article Exchange or Post to Web, NLM’s customers shall have the ability to access their ILL requests in a secure manner.

6. When requests are submitted to NLM, the system shall be able to read NLM’s catalog, currently Alma/Primo by Ex Libris, to retrieve call numbers to allow processing of the request. If an exact match is found in the catalog, a pick slip containing a document number, patron identification, citation information, delivery method and cost, is printed without ILL staff needing to review the request. If an exact match is not found the request is sent to a queue for staff review. Alternate methods of achieving the same result are acceptable.

7. The system shall have the ability to assign requests to service levels and floors and filter them into queues. The system shall also track the status and the assigned staff member of each order in the system at all times. The system shall provide a complete tracking history for each document from the time it is transferred to the ILL request management system to the time it is delivered to the patron. List of current logs kept which shall be maintained are listed below; functions to be maintained over the lifetime of the contract are not limited to this list alone.

Current logs are kept for the following:

• The date/time that a request was submitted into the system

• The date/time a request slip was printed

• The date/time a request was assigned to a library staff member

• The specific point in the processing stream at which a request is currently located

• The date/time that a request arrived at its current status

• The next step in the workflow for a request

• The date/time that a request was processed by a library staff member and the number of pages scanned

• The User ID of the library staff who processed or updated the request

• Assign any rejection codes used to indicate the reason that a request is being filled outside of the scanning process

• The location of the TIFF/PDF document file created for a request during the scanning process

• For loans, the due dates shall be calculated and shipment date/time shall be recorded

• The date/time that a request was delivered; if delivery failed, the date, time and reason shall be recorded

• The date/time that the source system was updated with status information for a request

• History of delivery failed documents and attempted re-sends

8. A level of automation is expected within the system. There are several queues for ILL representing both the physical location of requested items in the library building and service level of each request. NLM should be able to filter requests for printing by either or both of these metrics. The print queues shall be sorted by call number according to the location of library materials within the library. As needed, it may be necessary to redirect orders to alternate locations when library materials are relocated either temporarily or permanently.

Other temporary queues may be created by NLM based on publication date, item type, item format, etc. These queues shall print on a pre-defined schedule without staff intervention.

NLM shall be able to set and adjust the print schedule as needed.

9. The system shall allow for the use of no-fill codes to be entered if the requested cannot be filled for any reason. A response to DOCLINE via the DOCLINE API/JSON or HTTPS POST Request shall be generated from the system to provide information on the processing of each request. NLM currently uses a variety of cancel codes and must retain the ability to keep these codes up to date and in line with the wider DOCLINE community’s best practices.

The OTH code must have the capacity for ILL staff to send a custom message that can be shared with requestors every time it is used. This message can be set as a default or edited on an individual basis as needed. For an overview of current DOCLINE cancel codes, see (DOCLINE Help: Reasons (nih.gov)).

10. The system shall be able to automatically manage rejection criteria such as cost or NLM holdings status, such as cost or whether NLM has the item in its collection, with no staff intervention (“auto- reject”) as well as by manual methods as needed. New exception codes shall be created as needed by internal staff. The system shall allow NLM to communicate the rejection reason to the customer, either by transmission to the input system, DOCLINE, or from the system to the customer.

11. The system shall meet the Federal government section 508 compliance requirements. All documents provided shall meet Section 508 compliance standards.

12. The system shall have the ability to support an array of delivery methods and to transmit documents to the customer via the requested delivery method (e.g. email, Post to Web, Odyssey). For electronic mail delivery, requests are sent to borrowers in the form of an email message with the pick slip and article as PDF/TIFF attachments. For Article Exchange or Post to Web delivery, the email to the customer shall contain a link to the article that can then be downloaded. The pick slip shall provide basic information on the request including but not limited to the title of the item requested, journal volume/issue number, and page numbers. The pick slip shall also include unique identifiers generated by the system and also from other input systems.

13. [Cloud-based] Vendor shall provide FedRAMP related documents for review by NLM Security

Team. Vendor shall meet Health and Human Services security requirements with FedRAMP authorization. The NLM Security Compliance team will review the security package of the Vendor, discuss any reported findings in their Security Assessment Report (SAR) as required by FedRAMP.

The COR and/or product owner will also work with the Vendor for the continuous monitoring and review of a Third Party Assessment Organization (3PAO) security package after annual assessment of the Vendor by 3PAO.

14. [Hosted by NLM] NLM shall have control of how a document is sent to the customer.

NLM shall host a public-facing site to complete the fulfillment loop for delivery methods such as Post to Web. All document delivery requiring a hosted server for documents https://www.nlm.nih.gov/docline/context_help/context_help_reasons.html?_gl=1*m4b9pr*_ga*MTAyMzIyNTc1OC4xNzEwMTYxMzA0*_ga_7147EPK006*MTcxMDE4NzMyNi40LjEuMTcxMDE4NzM1My4wLjAuMA..*_ga_P1FPTH9PL4*MTcxMDE4NzMyNi40LjEuMTcxMDE4NzM1My4wLjAuMA..

delivered via methods such as Post to Web shall utilize NLM’s preexisting public-facing site and shall not maintain another website for this purpose.

15. The vendor shall provide a test environment that can work with the DOCLINE QA environment.

16. The system shall allow for the creation of multi-page TIFF/PDF document files generated through the scanning process and the attachment of TIFF/PDFs to be transmitted to the customers and for the documents to be reprinted or re-transmitted in case of delivery problems. TIFF shall be converted to PDF in this process.

17. The system shall alert NLM regarding failed document deliveries and allow for resending of failed documents. The system shall also provide an alert for requests submitted without call numbers and allow for call numbers to be supplied manually by NLM staff.

18. In addition to article requests, NLM processes 15 to 25 book loan requests daily. The system shall be able to track due dates and issue overdue notices via DOCLINE or by direct email.

19. The system shall be able to determine billing amounts and produce billing reports. The system does not need to perform billing, just perform tasks supportive of the billing process.

20. The system shall provide real time, automatically updated views of the status and quantities of all requests in all queues in the system so that NLM can monitor the volume and workflow of requests.

21. The system shall meet NLM’s reporting requirements with the ability to query data in order to create reports and statistics of all kinds, to query on status of request, and to retrieve detailed data on processed requests. If it is not possible to query the data, reports should be made available, and NLM should have the ability to request custom reports and receive them in a timely manner.

22. The system shall have the flexibility to allow NLM to adjust/alter the degree of desired staff mediation.

23. The system shall be able to support an array of sizes of scanned items, including 8.5 by 11 inches, A4, B5 and 10x14 inches. The system shall allow operators to delete, rescan and insert scanned images and remove black borders from images during the scanning process.

24. NLM shall be able to control when articles stored in the system such as those stored for Post to Web and Article Exchange are purged. This process shall be automated.

25. For the purposes of Post to Web and Article Exchange, articles shall be stored on a secure server. In this case, a secure server constitutes a server that is not available to the public and is password protected via username and password or other approved authentication method.

26. The system shall be able to work with and send fulfilled requests via proprietary, industry-standard systems such as Odyssey and Ariel.

27. The system shall be able to retrieve NLM’s licensing information and make this information available to the NLM ILL staff in the pick slip and any pages detailing fulfillment details.

This may be done through OPAC number retrieved from DOCLINE via the DOCLINE API/JSON or HTTP POST. Licensing information pertains to what type of document delivery is acceptable (i.e. print/fax, FTP, Post to Web, Email, etc.) to the publisher and any geographic or for-profit restrictions.

28. The system shall allow for searching external databases through the online interface via

Z39.50. Z39.50: the international standard service and communication protocol for searching and retrieving information from a database over a TCP/IP computer network and is covered by NISO standard Z39.50. System shall be able to communicate with Alma/Primo by Ex Libris (LocatorPlus), to gather various details about the request such as call number, via the Z39.50 interface.

29. NLM shall have control over how a document is delivered, whether it be via Post to Web, Article Exchange, or some other means.30. NLM shall be able to control what fulfill/reject codes are available to users of the system. Requestors shall be notified of the status of their requests via email which shall be inclusive of these codes. NLM currently uses a variety of cancel codes and must retain the ability to keep these codes up to date and in line with the wider DOCLINE community’s best practices. The OTH code must have the capacity for ILL staff to send a custom message that can be shared with requestors every time it is used. This message can be set as a default or edited on an individual basis as needed. For an overview of current DOCLINE cancel codes, see (DOCLINE Help: Reasons (nih.gov)).

30. The system shall be compatible with third-party equipment specified below including but not limited to the following: laptops, printers, Fujitsu Document Scanner fi-7700, Konica Minolta SL1000 Microfilm, and Konica Minolta ScanDIVA

31. The vendor shall adhere to NIH and NLM policies concerning the Health Insurance

Portability and Accountability Act and personally identifiable information, PII.

4.3 Technical Support and System Maintenance

The vendor shall provide the following technical services so that NLM can provide interlibrary loan services to its customers without delays or disruptions:

1. Upgrade the ILL system software and applications as needed. This includes major releases, patches, and installing updated versions of individual applications.

2. Serve as a knowledge base for NLM to address any technical questions that may arise. The vendor shall respond to any programmatic failures or technical inconsistencies identified by NLM security measures.

3. Advise NLM on the necessary software upgrades and NLM shall work in collaboration with the vendor to complete the upgrades on an agreed upon schedule.

4. Provide input to NLM’s technical staff on ‘system health’ monitoring tools and processes including web forms, web services, system software updates and windows services for both production and test systems and assist NLM with implementing these changes.

5. [Hosted by NLM] The physical infrastructure shall be maintained by NLM.

6. [Hosted by NLM] All server data and software shall be retained for 30 days locally. Support for recovering data shall be available within 48 hours. The vendor may be asked to provide assistance if needed for performing this task and any data recovery. The production database shall be able to store at least 13 months of request data, for which the vendor maintains primary responsibility for purges, recalls, and reconstructions of data. NLM shall be responsible for the backup and restoration of data greater than 13 months old.

7. [Cloud-based] The system should have data recovery and disaster recovery in place. The system shall have availability 99.9% of the year. (Max downtime 8.76 hrs/yr, 43.2 mins/month, 10.1 mins/week)

8. [Cloud-based] The vendor shall monitor system reliability, proactively mitigate risks in operation disruption, maximize system availability, and notify customers of unplanned downtimes in a timely manner.

9. [Cloud-based] The vendor shall monitor system performance and workload and adjust to address competing needs.

10. Scanned images shall be stored on the production system for up to 60 days but no less than

10 days. Scanned images shall be purged according to NLM’s requirements. Article Exchange and/or Post to Web documents shall be stored and purged based on NLM’s requirements.

11. NLM requires hands-on support for enhancements to its existing system. The enhanced support shall maintain the workflow which allows the NLM ILL system to accept requests from DOCLINE, OCLC, and other ILL systems. As part of this enhanced support, the vendor shall provide ongoing support of system functions which include the following main features:

a) Remote day-to-day troubleshooting.

b) Installation of version upgrades, patches, and security updates.

[Hosted by NLM] To be able to perform the above tasks remotely, a limited number of vendor staff shall be given direct access to login to NLM via WebEx or other web conferencing tools shall be used as an alternative if needed. NLM shall set a mutually agreed upon time frame for upgrades based on the urgency and magnitude of the task. The NLM test system shall be upgraded first. Once NLM staff complete testing within the agreed upon timeframe, then vendor staff shall upgrade the software for the NLM’s ILL production system. These upgrades, patches, and updates should not affect NLM’s existing workflow or how NLM transmits requests unless approved by ILL systems product owner.

[Cloud-based] Two-week advanced notification of version upgrades, patches, and security updates. These upgrades, patches, and updates should not affect NLM’s existing workflow or how NLM transmits requests unless approved by ILL systems product owner.

c) Ensure operability of all newly added features relating but not limited to: ingesting unique institution records; obtaining ILL requests from DOCLINE and/or other sources;

functionality and performance of the ILL request form as well as staff and user portals;

and extraction of quarterly billing information.

Other maintenance and monitoring activities shall include:

• Assist with troubleshooting any critical issues causing significant work stoppage.

• Modify batch job schedules or help to create new ones.

• In the event that a NLM System Administrator is unavailable, ensure that system is still functional by actions such as clearing flags, closing hung apps, and other standard bug fixes.

• Resolving security vulnerabilities identified by NLM’s information technology staff.

• NLM staff shall monitor the ILL management system throughout NLM’s hours of operation and shall notify the vendor when problems are detected and troubleshooting assistance is required.

4.4 Customer Service Support

NLM’s hours of operation are from 8:30 AM to 5:00 PM, Monday through Friday, excluding Federal holidays and facility closures. NLM has a requirement to deliver regular articles to patrons within two business days of receiving the request in the system, and within two hours if it is a clinical emergency request. In order to facilitate this turnaround time, NLM requires that the vendor be available to provide needed support in case of system failures. The vendor shall respond to NLM’s technical issues within 60 minutes during normal business hours even though a solution may not be in place within 60 minutes.

4.5 Documentation

Upon request, the vendor shall provide documentation to describe the system, including upgrades and enhancements, bug fixes, release notes, upgrade instructions and install instructions, technical requirements, and other special documents. Proprietary documents remain the property of the vendor.

4.6. Privacy

The vendor may not use or disclose any of NLM’s customer data for any reason. It is understood that data is solely for the use of the NLM in carrying out its business.

The vendor shall not own any information provided by NLM. NLM shall maintain the right to manage its data on the vendor’s system and remove it at any time. NLM data shall not be shared with third parties unless the third party is actively engaged in ILL functions such as billing or borrowing within the vendor’s system, and the information being shared pertains to that type of transaction.

4.6 Government Responsibilities

COR shall communicate with the vendor if there are any issues in service or functionality that require troubleshooting.

5.0 PERIOD OF PERFORMANCE

The base period of performance shall be 12 months, followed by up to 4 option periods of 12 months each.

Period Dates Base September 1, 2024 through August 31, 2025

Option I September 1, 2025 through August 31, 2026

Option II September 1, 2026 through August 31, 2027

Option III September 1, 2027 through August 31, 2028

Option IV September 1, 2028 through August 31, 2029

6.0 TRANSITION PLAN

The vendor shall be required to provide NLM with technical support and advanced delivery of the system within 2 weeks of being selected by NLM so that NLM can plan for the implementation and integration of the system as well as any required training.

In the event that NLM ceases using the vendor’s product, the vendor shall be notified of the change within 30 calendar days of the last date of performance. The vendor shall provide the project oversight and technical support necessary to respond to all questions related to the transition to a new system and or provider of the ILL management system. The vendor shall create any requested non-proprietary documentation that NLM requests to aid with the transition.

Any documentation developed for this purpose shall be the property of the government.