Statement of Work: National Library of Medicine Discovery and Delivery Platform

STATEMENT OF WORK
National Library of Medicine Discovery and Delivery Platform

NIHLM2015369
Page 1 of 46
Contents
1. Project Title ............................................................................................................................................... 3
2. Background Information ........................................................................................................................... 3
3. Objectives.................................................................................................................................................. 3
4. Scope of Work ........................................................................................................................................... 3
5. Description of Work .................................................................................................................................. 3
6. Contract Type .......................................................................................................................................... 31
7. Place of Performance .............................................................................................................................. 31
8. Anticipated Period of Performance ........................................................................................................ 31
9. Deliverables/Delivery Schedule .............................................................................................................. 31
10. Invoicing Requirements ........................................................................................................................ 32
11. Post-Award Administration................................................................................................................... 32
12. Evaluation Criteria................................................................................................................................. 32
Technical Capability - 50% ...................................................................................................................... 32
Service Support - 30% ............................................................................................................................. 32
Corporate Related Experience - 20% ...................................................................................................... 32
APPENDIX A: NIH-Security-Acquisition-Provision ....................................................................................... 34
Page 2 of 46
STATEMENT OF WORK
1. Project Title
National Library of Medicine Discovery and Delivery Platform
2. Background Information
The National Library of Medicine (NLM) is constantly striving to maximize the visibility, use, and
value of the overall collections and make access to the library resources seamless and simple
for patrons to use. LocatorPlus, NLMs online public access catalog (OPAC), has been the frontend search interface to many NLM resources managed in the Voyager integrated library system
(ILS) since 1999. However, as information concepts and technology advance, the underlying
technology, functionality, and user interface of conventional OPACs become obsolete and are
therefore no longer aligned with user expectations. LocatorPlus is no exception.
In an age when most users are accustomed to powerful search engines, NLM needs to offer a
modern, comprehensive discovery and delivery interface that enables users to quickly and
seamlessly access the rich bibliographic data, electronic resources, and full text content of the
wide range of NLM collections. This procurement intends to enhance the NLMs search
interface by replacing LocatorPlus with a state-of-the-art discovery and delivery solution
produced by the library information system industry.
3. Objectives
NLM is issuing this Statement of Work (SOW) for purchasing web-based discovery and delivery
software. The Library seeks to acquire the software hosted by a vendor with the technical
expertise, resources, and experience to provide NLM with an industry-leading search platform.
4. Scope of Work
The scope of this procurement is the acquisition of web-based discovery and delivery software
as well as the technical, management, and support services for implementing and maintaining
the platform.
5. Description of Work
The vendor shall host discovery and delivery software that provides a single, modern, and
intuitive search platform for NLMs physical, electronic, and digital resources. It must
interoperate with the librarys ILS to enable users to remain in the search platform for research
and traditional OPAC functionality such as requests for physical materials in the NLM
collections. The software architecture should be open and extensively configurable,
customizable, and expandable for incorporation of additional collection resources and for
further NLM development in response to future needs. The vendor must establish security
policies, procedures, and practices that meet the relevant security requirements set forth by
the U.S. Federal Government.
Page 3 of 46
The requirements for the discovery and delivery platform are detailed in the table below. All of
the mandatory requirements have to be fulfilled by the vendors solution. For those desirable
requirements that the vendors software cannot currently meet, the vendor may opt to
propose an alternative approach or method.
Page 4 of 46
Priority
No.
Requirement
See sub-requirements
1.01
Simple search
Mandatory
1.01.01
Mandatory
1.01.02
Mandatory
1.01.03
Mandatory
1.01.04
Mandatory
1.01.05
1.02
Mandatory
1.02.01
Description
Vendors Response
1. FUNCTIONAL
System should provide simple one-box
searching. Searching by keyword
anywhere should be the default search.
Search keywords anywhere Allows users to search by keyword,
in the record
multiple keywords or keyword phrase
anywhere in the record.
Search using Boolean
Allows users to use Boolean operators
operators
(AND, OR, NOT) to search anywhere in
the record. This may optionally include
adjacency operators.
Target search fields
Allows users to target specific fields to
search. Available choices of fields should
be configurable by the library.
Simple search truncation
Allows users to truncate terms (i.e. use
options
wildcards) in the simple search box.
Target specific collection
Allow users to target collection resources
resources
to search. Users can specify the NLM ILS
catalog, articles only, licensed resources
only, etc. to search.
Advanced search
System should provide a separate
advanced search form. The advanced
search form should be expandable with
additional search rows.
Boolean searching
Allows users to use Boolean operators
(AND, OR, NOT) in the advanced search
form.
Page 5 of 46
Priority
Mandatory
No.
1.02.02
Requirement
Advanced search field
search options
Mandatory
1.02.03
Desirable
1.02.04
Advanced search
truncation options
Nesting, phrase and
proximity searching
Mandatory
1.02.05
Advanced search filtering

options
1.03
Browse search
Mandatory
1.03.01
Perform browse searches

by authors
Mandatory
1.03.02

by subject headings
Description
Allows users to choose which fields to
search in the advanced search form.
Available choices of fields should be
configurable by the library.
Allows users to truncate terms (i.e. use
wildcards) in the advanced search form.
Allows users to nest search terms and
perform phrase and proximity searching
in the advanced search form.
Allows users to filter items in the
advanced search form. Filtering options
should be configurable by the library.
Allows users to perform browse search
by author, subject heading, title, and
series, view resulting headings, view
"see" and "see also" references, navigate
previous/next result page on browse list,
view matching bibliographic and/or
authority records
Allows users to conduct browse searches
of authors and displays all authors in
bibliographic records plus any crossreferences in authority records as one
unified list.
of subject headings and displays all
subject headings in bibliographic records
plus any cross-references in authority
records as one unified list.
Vendors Response
Page 6 of 46
Priority
Mandatory
No.
1.03.03
Requirement
by titles
Mandatory
1.03.04

by series
Mandatory
1.03.05
Mandatory
1.03.06
Mandatory
1.04
Navigate results on browse

list
Utilize cross references
from authority records in
the browse search results
Searching across multiple
collection resources
Mandatory
1.05
Known item search
Description
of titles and displays all titles in
unified list.
of series and displays all series in
unified list.
Allows users to navigate to the previous
and next result pages on the browse list.
Allows users to link from a cross
reference to the preferred term in the
browse search results.
Allows users to search bibliographic level
information, article level information and
full text of resources (if available) across
data from the NLM ILS, digital
repositories, and other collection
resources as well as a web-scale
discovery service.
Allows users to search a specific title
using title or title abbreviation as well as
ISSN, ISBN, NLM Unique ID or other IDs
using keyword search in the simple
search box. An exact match should be
boosted above a keyword or phrase
match. e.g., if the user searches "Blood"
the periodical with this title should
Vendors Response
Page 7 of 46
Priority
No.
Requirement
1.06
Smart searching
Mandatory
1.06.01
"Did you mean?" and

autocorrect
Mandatory
1.06.02
Autocomplete
Mandatory
1.06.03
Autostemming
Desirable
1.06.04
Synonym expansion
Mandatory
1.06.05
Stop word filtering
Mandatory
1.06.06
Mandatory
1.06.07
Vernacular searching and

retrieval
Character normalization
1.07
Subject search term

explosion
Description
display at the very top of the search
results based on relevancy ranking.
System should include "Did you mean?",
autocorrect, autocomplete,
autostemming, synonym expansion, and
stop word filtering. The smart searching
options should be configurable by the
library.
System should present users with a "Did
you mean?" suggestion for spell check
and similarly spelled words.
System should present users with
suggested terms based on text entered.
Allows users to search a root word and
automatically search other words
containing the root.
System should search for synonyms as
well as the words entered in the query.
System should filter out library
configurable stop words from the search
query.
Allows users to retrieve results using
vernacular characters.
Characters entered should be input and
search neutral and normalized. e.g.,
search by either Quebec or Qubec
will retrieve both.
System should include subject heading
explosion and thesaurus matching. The
system should search for all subordinate
Vendors Response
Page 8 of 46
Priority
No.
Desirable
1.07.01
Desirable
1.07.02
Desirable
1.07.03
Desirable
1.07.04
1.08
Desirable
1.08.01
Requirement
Description
terms in the MeSH hierarchy by a search
on a higher-level term. The system
should refer users from a non-preferred
MeSH term to a preferred one.
Turn on/off subject
Allows users to turn on/off the entire
explosion
explosion or select individual narrower
terms to include or exclude from the
search. Exploded terms should be the
default.
Explode MeSH terms
When searching a MeSH term as a
subject, system should also retrieve all
records which contain narrower terms in
the subject heading.
Explode MeSH
When searching a MeSH subheading
subheadings
term, system should also retrieve all
records which contain narrower
subheading terms in the subject heading.
Map synonyms to
System should map all "see" cross
preferred MeSH term
references listed in the MeSH record to
the preferred term.
Authority record searching Allows users to search and retrieve
and retrieval
authority records via keyword search for
name heading, name/title heading, series
heading, and subject heading in authority
records.
Authority keyword
Allows users to search and retrieve
searching
authority records by keyword.
Vendors Response
Page 9 of 46
Priority
Desirable
No.
1.08.02
Requirement
Display links to authority
records in results from
browse search of
bibliographic records.
View authority record in a
textual display
Desirable
1.08.03
Desirable
1.08.04
Desirable
1.08.05
View authority record in

the MARC format
Authority record outputs
Desirable
1.09
Blank search
1.10
Search refinements
Mandatory
1.10.01
Customizable refinements
Mandatory
1.10.02
Facet/limit groupings
Mandatory
1.10.03
Apply single or multiple

refinements with a search
Description
System should include authority record
links in the results from browse search of
bibliographic records.
Vendors Response
Allows users to view a textual/labeled

display of the main heading, cross
references, and public notes of the
authority record.
Allows users to view the entire MARC
authority record.
Allows users to print, email, export,
download, and text message the
authority record in text, MARC and
MARCXML formats.
Allows users to perform a blank search
from the simple search box by hitting
enter that will retrieve a set of results
containing all records. Facets should
appear following a blank search or when
launching the system.
Allows users to limit their searches to
specific facets.
The placement and the types of facets or
limits presented to the user should be
The number of values that appear under
each facet or limit should be configurable
by the library.
Allows users to choose single or multiple
facets when searching.
Page 10 of 46
Priority
Mandatory
No.
1.10.04
Requirement
Select refinements after
search
Mandatory
1.10.05
Remove refinements from

a search result
1.11
Desirable
1.11.01
Perform additional
searches from a link in a
result record
Retrieve a single related
title from a result record
Desirable
1.11.02
Retrieve multiple related

titles from a result record
Mandatory
1.12
Record retrieval limit
Mandatory
1.13
Real-time item availability

status
Mandatory
1.14
OpenURL
Description
Allows users to select single or multiple
values within one or more facets after a
search has run.
Allows users to deselect any refinements
previously applied to a search. This can
be single or multiple de-selections.
Allows users to retrieve additional
records by clicking on an author, subject,
title, and series links in the result record.
Allows users to retrieve a related record
(e.g., earlier/later serial title) by clicking
on a link in a result record. NLM Unique
IDs or any other IDs included in result
records would be hyperlinked and should
retrieve a unique result.
Allows users to click on the author's
name, subject or series and retrieve all of
the records in the system which contain
that name, subject or series.
Allows users to retrieve an unlimited
number of search results.
Allows users to stay within the system to
view real-time item availability status
information from the NLM ILS in the brief
records and the detailed records of the
search results.
System should support OpenURL linking
to facilitate access from search results to
licensed or open access electronic full
text and related services. The OpenURL
Vendors Response
Page 11 of 46
Priority
No.
Requirement
Mandatory
1.15
Persistent URLs
Mandatory
1.16
De-duplication
Desirable
1.17
Record grouping
1.18
Relevancy ranking
Mandatory
1.18.01
Custom relevancy ranking
Mandatory
1.18.02
Boost relevancy ranking
Mandatory
1.19
Blended search results
Mandatory
1.20
Search result sorting
Description
Vendors Response
links should display within brief records in
the search results and within detailed
records.
System should provide short persistent
links to search result items, bookmarks,
saved search queries, and browse
categories. The primary ID used in a
persistent link should be configurable by
the library.
System should identify and manage the
display of duplicate records within search
results.
System should group different
manifestations of the same work
together in a single cluster.
Search results should be ranked based on
standard ranking criteria such as term
frequency and placement, format,
document length, publication date, user
behavior, scholarly value, etc.
Relevancy ranking criteria should be
Boost relevance ranking by specific
factors configurable by the library.
System should display one blended list of
search results including all collection
resources.
Allows users to sort the search results by
criteria that are configurable by the
library.
Page 12 of 46
Priority
Desirable
No.
1.21
Requirement
Search history
Mandatory
1.22
Saving search results
Desirable
1.23
Saving search queries
1.24
Search result output
Mandatory
1.24.01
Output results from

various record displays
configurable by the library
Mandatory
1.24.02
Print selected records
Description
Allows users to view, rerun and combine
previous search queries during a single
search session.
Allows users to select/deselect and save
search results, create lists, bookmark
items, etc. within individual records or
within results lists when logged in to My
Account.
Allows users to save or purge their search
queries, rerun and combine saved
queries when logged in to My Account
Allows users to select/deselect records
for output on the current page or all
pages of the search results. The system
should provide customizable output
options, including print, email, export,
download, and text message in text,
MARC21, and MARCXML formats, etc.
This includes both bibliographic and
authority records and holdings
information.
Allows users to output results from
various record displays (e.g., full records
with holdings, full records with no
holdings and brief records.)
Allows users to print selected records on
the current page or all pages of the
search results from various record
displays (e.g., full records, brief records,
with/without holdings, etc.)
Vendors Response
Page 13 of 46
Priority
Mandatory
No.
1.24.03
Mandatory
1.24.04
Desirable
1.24.05
Desirable
1.24.06
1.25
Desirable
1.25.01
Mandatory
1.25.02
Desirable
1.25.03
Requirement
Email selected records
Description
Allows users to email selected records on
the current page or all pages of the
search results from various record
Export selected records to Allows users to export selected records
citation managers
on the current page or all pages of the
search results to citation managers.
Download selected records Allows users to download selected
bibliographic or authority records.
Text message selected
Allows users to text message selected
records
records on the current page or all pages
of the search results from various record
ILS patron integration
The NLM ILS patron account allows
requests for use of physical materials.
This only applies to users within the NLM
domain, such as onsite users and library
staff.
Patron self-registration
System should allow the patron
interacts with the NLM ILS registration to create a patron account in
the NLM ILS automatically.
Patron user requests
Allows users to use their NLM ILS patron
account to request physical materials
from the collection.
Patron self-registration link System should link patron registration to
to "My Account"
"My Account" features. There should not
be a separate login for patron selfregistration versus "My Account".
Vendors Response
Page 14 of 46
Priority
No.
1.26
Requirement
Requesting for physical
materials
Mandatory
1.26.01
Request form default and

manual input
Mandatory
1.26.02
Request form changes
Mandatory
1.26.03
Request submission
Mandatory
1.26.04
Request limits
1.27
My Account
Desirable
1.27.01
My Account creation
Description
Allows onsite users to request physical
materials from a selected search result
record using a form that is configurable
by the library when logged in.
System should automatically populate
information of a selected search result
record on the request form including
bibliographic, item and user information.
Users should be prompted to enter
missing information, such as patron
identification or specific citation. Users
should be able to add additional notes.
Allows users to toggle from automatic
input to manual input on the request
form.
After the user submits a request the
system should automatically log the
request into the NLM ILS closed stacks
module (Voyager Callslip). The user can
view the processing status of the
request(s) submitted on the current date
when logged in My Account.
The limit for the number of requests per
user per day should be configurable by
the library.
Allows onsite and remote users to sign
into a "My Account".
Allows users to create a "My Account"
where they can log-in and log-out.
Vendors Response
Page 15 of 46
Priority
Mandatory
No.
1.27.02
Requirement
My Account preferences
Mandatory
1.27.03
Desirable
1.27.04
Mandatory
1.27.05
My Account retrieves
saved results lists and
queries
My Account password
reset
My Account requests for
physical materials
Desirable
1.27.06
My Account manage user

accounts
Mandatory
1.28
Guest access
1.29
Alerts
Description
Vendors Response
Allows users to customize preferences
which may include sorting, number of
results per page, etc.
Allows users to view and delete items
from previously saved results lists and
search queries.
Allows users to request a password reset
using an "I forgot my password" feature.
Allows users to view the requests for
physical materials placed in the same
day. The connection between My
Account and the requests is broken
overnight to protect patron privacy.
System should provide tools for the
library to manage users' My Accounts,
such as batch deleting inactive accounts.
Allows users to search and use the
system without logging in. Guest users
may not place requests, save search
results or save search queries. Once a
guest user logs in with My Account these
additional functions are available except
requests are limited to the NLM domain.
System should provide customizable
alerts or RSS feeds to inform users of new
items in the NLM ILS or other collections
related to their search queries.
Page 16 of 46
Priority
Mandatory
No.
1.29.01
Requirement
Save a search query as an
alert
Mandatory
1.29.02
Mandatory
1.29.03
Configurable alert
parameters
Manage alerts
Mandatory
1.29.04
Save search query as an

RSS feed
2.01
Look and feel
Mandatory
2.01.01
User-friendly design
Description
Vendors Response
Allows authenticated users to save a
search query as an email alert.
Authenticated users should be able to
create an alert based on their current
search criteria, including selected limits
and facets. The system should capture
the user's email address from the user's
"My Account" information.
Allows authenticated users to configure
the parameters of their email alerts.
Allows authenticated users to edit and
delete their alerts.
Allows users to create an RSS from the
search results. A user should be able to
generate an RSS feed URL with or without
logging in.
2. USER INTERFACE
System should provide an aesthetically
appealing look and feel consistent with
current web design standards.
System design should be simple,
uncluttered, aesthetically pleasing with
all elements of the interface easily
located. Dynamic elements (buttons,
boxes, menus, etc.) should be used
effectively to facilitate searching and data
retrieval.
Page 17 of 46
Priority
Mandatory
No.
2.01.02
Requirement
Customizable look and feel
Description
System should provide tools to allow for
customization of the design elements by
the library. This would include branding,
custom style sheets and posting ad hoc
library information.
The system should use industry-standard
and consistent navigational elements.
The system should use clear and intuitive
labeling so that users can easily
determine where a link or button will
lead. System should use mouse-over alt
text on images or tooltips to aid in
navigating the interface.
Mandatory
2.02
Navigation
Mandatory
2.03
Accessibility
System should meet ADA and Section 508

accessibility requirements and acceptably
pass a section 508 compliance evaluation.
Vendor should provide Voluntary Product
Accessibility Template (VPAT) or Government
Product Accessibility Template (GPAT) for the
system as an evidence of compliance.
2.04
Search result display
Mandatory
2.04.01
Search strategy display
Mandatory
2.04.02
Number of results
Record displays varying levels of

information (e.g., results page, brief view,
detailed view, staff MARC view, etc.) the
information in each view should be
System should display the search strategy
with every search result.
Allows users to change the default
number of records displayed per page
(e.g., 10, 25, 50, or 100).
Vendors Response
Page 18 of 46
Priority
Mandatory
No.
2.04.03
Requirement
Results page display
Mandatory
2.04.04
Brief view display
Mandatory
2.04.05
Detailed display
Desirable
2.04.06
MARC view display
Mandatory
2.04.07
Accentuate search terms
Mandatory
2.05
Indication of online access
2.06
Foreign language display
Mandatory
2.06.01
Diacritics and vernacular

characters
Mandatory
2.06.02
UTF-8
2.07
Help
Description
Results page display of search results
Brief view display of an individual record
selected from search results should be
Detailed display of an individual record
selected from search results should be
Allows users to view the entire MARC
bibliographic record after selecting a
result.
System should highlight, bold or italicize
the search terms entered by the user in
the results display.
System should provide an indication of
NLM online access to resources with
availability and location. This can be via
an icon or text display.
System should support display of foreign
language materials.
System should display diacritics and
vernacular characters in the appropriate
script.
System should be compatible with the
UTF-8 character set.
System should provide links to the
corresponding sections of the vendor's
online help documentation and an index
to access all help topics.
Vendors Response
Page 19 of 46
Priority
Mandatory
No.
2.07.01
Requirement
Customizable help
Desirable
2.07.02
Context-sensitive help
Mandatory
2.08
Links to informational
pages
Desirable
2.09
Spotlight NLM resources

from within the search
results
Desirable
2.10
Social media
2.11
Mobile access
Mandatory
2.11.01
Responsive design
Mandatory
2.11.02
Mobile version retains full

functionality
Mandatory
2.11.03
Bypass mobile version
Description
Modifying the help text for the system
and adding additional help information
System should provide specific help to
the user based on where the user is in
the system interface.
Adding customizable links on the system
interface should be configurable by the
library.
Indication of NLM resources to spotlight
or promote based on a user's search
criteria within the search results should
Allows users to seamlessly share search
result records via social media.
System should be accessible in a browser
on mobile devices and support
responsive web design.
System should support responsive web
design for mobile users.
Mobile version should include the same
features and functionality of the desktop
version.
Allows mobile users to bypass the mobile
version and access the full desktop
version on their mobile device.
Vendors Response
Page 20 of 46
Priority
Desirable
No.
2.12
Requirement
Embedded audio/video
player
Description
Allows users to listen and view audiovisual materials directly from the search
results. The embedded audio and video
player should be HTML5 compliant,
including Flash fallback. It should support
responsive design and keyboard control.
The video player should also support
subtitles.
3.01
System security
Mandatory
3.01.01
Secure Socket Layer (SSL)

certificates
Desirable
3.01.02
Password complexity
Desirable
3.01.03
Storing passwords
Mandatory
3.01.04
Encrypted connection
Mandatory
3.01.05
Web application attacks
Mandatory
3.01.06
Privacy policy
System should meet the HHS/NIH/NLM

security requirements.
System should support SSL server
authentication. The SSL certificate must
be specific to the URL used rather than a
wildcard certificate.
System passwords should meet minimum
complexity requirements. Passwords
must be at least 8 characters in length,
contain one upper case letter, one lower
case letter, one number and one symbol.
System should store a secure
cryptographic hash of a user's password.
If an external authentication service is
used, the connection between the system
and the service should be encrypted.
System should resist web application
attacks.
System should comply with the library's
privacy policy
Vendors Response
3. ADMINISTRATIVE
Page 21 of 46
Priority
No.
Requirement
Description
(http://www.nlm.nih.gov/privacy.html)
Mandatory
3.01.07
Mandatory
3.01.08
IT-Security-AcquisitionProvisions
Security Assessment and
Authorization (SA&A)
3.02
Multiple instances
Mandatory
3.02.01
Multiple instances for

development, testing, and
production
Mandatory
3.02.02
Multiple instances fault

tolerance and scaling
3.03
Platform support
Vendor needs to comply with IT-SecurityAcquisition-Provisions (Appendix A).

Vendor needs to complete Security
Assessment and Authorization (SA&A) for
the system/service based on NIST SP 80053A and NIST SP 800-115 within six
months after contract is awarded.
System should have the ability to deploy
multiple instances. System should allow
NLM to have a test instance/sandbox
separate from other libraries.
System should allow multiple instances
that are configurable by the library. Each
instance should not interfere with the
testing, development and performance of
the other instance.
System should support multiple instances
for scaling and fault tolerance. The library
should be provided with information on
how the architecture supports scalability
and fault tolerance.
System architecture should be
compatible with the library's
infrastructure and resources.
Vendors Response
Page 22 of 46
Priority
Mandatory
No.
3.03.01
Requirement
NLM provided domain
name
Mandatory
Mandatory
3.03.02
3.04
Internet protocol
Implementation
Mandatory
3.05
Administrative backend
3.06
Statistical reporting
Description
Vendors Response
System should utilize the library's
provided domain name. The main URL
and all underlying supporting pages of
the system should start with the NLM
domain name. All emails leaving the
system should have the reply to and
recipient addresses embedded with NLM
domain name. The vendor should provide
URLs of example implementations and
emails leaving the system that NLM can
review as evidence.
System should support IPv6.
System should be implemented within
the library's designated timeframe and
resources after contract award.
System should provide the library with a
robust administrative backend with tools
and utilities for access control,
customization, and ongoing maintenance.
System should support multiple
administrator logins and roles.
System should provide a robust statistical
reporting module for the library to create
reports for monitoring and assessing
usage. Authorized library staff should be
able to distinguish statistics based on
user groups -- external, internal (in the
NLM Reading Room), and staff users.
Page 23 of 46
Priority
Mandatory
No.
3.06.01
Requirement
Anonymized data
Desirable
3.06.02
Export report data
Desirable
3.06.03
Customizable reports
3.07
Support
Mandatory
3.07.01
Ongoing support
Mandatory
3.07.02
System upgrades and

patches
3.08
Training
Mandatory
3.08.01
Train trainers
Mandatory
3.08.02
Train administrators
Description
Vendors Response
System should anonymize the usage data
but distinguish between user groups
(external, internal, and staff users).
System should allow for export of report
data to third party software and/or in
CSV format by authorized library staff.
System should allow for customization of
statistical reports by authorized library
staff.
Vendor should provide technical support
and customer service.
Vendor should provide ongoing
comprehensive technical support. A point
of contact should be designated for NLM
support requests.
Vendor should routinely provide upgrade
versions and patches between upgrades.
Vendor should provide a history of
upgrades and patches in the past three
years as evidence.
Vendor should provide onsite and/or
online training.
Vendor should provide initial training for
the library staff who will in turn train staff
and end-users.
Vendor should provide onsite and online
training for NLM system administrators
on the initial customization and ongoing
maintenance.
Page 24 of 46
Priority
No.
3.09
Requirement
Documentation
Mandatory
3.09.01
Architecture
documentation
Mandatory
3.09.02
Technical documentation
Mandatory
3.09.03
User manuals
Mandatory
3.09.04
Security documentation
3.10
Desirable
3.10.01
Time-out for logged in

sessions
System time-out warning
Desirable
3.10.02
Session time-out re-login
Description
Vendors Response
Vendor should provide detailed up-todate system documentation.
Vendor should provide up-to-date
technical documentation of software
architecture.
documentation describing APIs, deep
links, plug-ins, and adapters available
with the system.
manuals for end-users, NLM system
administrators, and support staff.
documentation describing security
policies, procedures, and practices.
System time-out limit on sessions should
System should provide a pop-up window
in advance of a user being timed-out.
System should end the user session and
require re-login after the system time-out
warning expires.
4. INTEROPERATBILITY WITH RELATED SYSTEMS/APPLICATIONS

Mandatory
4.01
API for record download

from ILS
4.02
Interoperability with the
System should provide an API for

retrieving and downloading from NLM ILS
the bibliographic records, in MARC and
MARCXML formats, that correspond to
selected search result records.
System should have built-in mechanisms
Page 25 of 46
Priority
No.
Requirement
Integrated Library System
(ILS)
Mandatory
4.02.01
Initial ingest of ILS data
Mandatory
4.02.02
Incremental ingest of ILS

data
Mandatory
4.02.03
Real-time interactions
4.03
Interoperation with
DOCLINE
Desirable
4.03.01
DOCLINE users create

requests from
bibliographic information
Description
Vendors Response
that enable automatic harvesting,
normalization, and indexing of
bibliographic, holdings, item, and
authority data from the NLM ILS at an
interval configurable by the library.
System should harvest all bibliographic,
holdings, item-specific, and authority
data from the NLM ILS as an initial ingest
and index the data.
System should harvest new, changed, and
deleted bibliographic, holdings, item, and
authority records from the NLM ILS and
index the data. The frequency of this
transfer should be configurable by the
library.
System should present item availability
status information using a real-time lookup service and support processing closed
stack requests through interoperation
with the NLM ILS while enabling users to
remain in the system.
System should interoperate with
DOCLINE
(http://www.nlm.nih.gov/docline/), an
internally developed NLM system that
facilitates ILL requests among DOCLINE
member libraries.
Allows DOCLINE users to search the
system and retrieve specific fields in
order to initiate an ILL request.
Page 26 of 46
Priority
Desirable
No.
4.03.02
Mandatory
4.04
Mandatory
4.05
4.06
Mandatory
4.06.01
Mandatory
4.06.02
Mandatory
4.07
Requirement
DOCLINE communications
via SSL (Secure Socket
Layer)
Interoperability with link
resolvers
Description
System should allow for DOCLINE
communications via SSL to avoid issues
with a user's browser.
System should be compatible with
OpenURL link resolvers, including SFX.
OpenURL enabled as both a source (that
can build standards-compliant OpenURL)
and as a target.
Interoperability with NLM System should support initial metadata
digital repositories and
and full text transfer, continual updates,
other collection resources and indexing from the NLM's digital
repositories and other collection
resources. System should support various
harvesting and delivery methods,
including OAI-PMH and FTP.
Search engine integration System should support harvesting and
crawling of NLMs data by third-party
search engines.
Search engine crawling
System should guide third-party search
engines to harvest and crawl records
exposed through the system.
Search engine optimization System should provide SEO features for
(SEO)
catalog records that are configurable by
the library.
Metadata schemas
System should support various standard
metadata schemas and accommodate
any kind of structured XML.
Vendors Response
5. OTHERS
Mandatory
5.01
Development and
enhancement
System should support a progressive

development cycle. The vendor should
Page 27 of 46
Priority
No.
Mandatory
5.02
5.03
Desirable
5.03.01
Desirable
5.03.02
Mandatory
5.03.03
Mandatory
5.04
5.05
Requirement
Description
Vendors Response
supply as evidence a history of new
system releases and participation of user
libraries in decision making on
development in the past three years.
Technology roadmap
Vendor and developer community should
have an innovative technology roadmap
that defines a system evolution path. The
vendor should provide a history of
roadmaps in the past three years as
evidence.
Authentication/
System should be compatible with the
Authorization
library's policies for licensed resources
and physical materials.
My Account authentication Allows users to log in to "My Account" to
access certain functions
Automatic registration for When users log in via Federated Login,
Federated Login
there is no need for explicit
registration/sign-up.
Authorize users to request Sessions originating within NLM domain
use of physical materials.
may authenticate using an ILS patron
account to request materials. Note: NLM
does not use a PIN for patron
authentication.
Browser
System should be compatible with all
major web browsers.
System performance
System should be accessible 24x7 a week,
respond to user login and each query in 2
seconds, and allows system
administrators to monitor system
performance.
Page 28 of 46
Priority
Mandatory
No.
5.05.01
Requirement
Availability
Mandatory
5.05.02
Response time
Mandatory
5.05.03
Monitor system
performance
5.06
Scalability
Mandatory
5.06.01
Accommodate additional
collection resources
Mandatory
5.06.02
Increased access
Mandatory
5.07
Extensibility
Description
System should be accessible to users at
an uptime percentage of at least 99.5%
annually. If maintenance causing service
downtime, it must, to the maximum
extent possible, be scheduled in advance
and of extremely limited duration.
System should provide an average
response time not greater than two
seconds for user login and each query,
regardless of the number of concurrent
users on the system.
System should provide tools in the
backend to monitor system performance
and generate alerts and warnings to
NLM. Allows authorized NLM staff to
terminate user queries that affect system
performance.
System should allow the library to
broaden capacity, content and users
without requiring changes to its
deployment architecture.
System should allow the library to scale
and broaden discovery and delivery to
licensed digital and electronic resources
and published content.
System should accept increased user
access capacity as demand warrants.
System should allow the library to extend
the functionality via APIs and modifying
the code base.
Vendors Response
Page 29 of 46
Priority
Mandatory
No.
5.08
Requirement
Vendor viability
Mandatory
5.09
Vendor's user community
Mandatory
5.10
Developer community
Description
Vendors Response
Vendor should provide information on
viability and stability of funding sources
and resources.
Vendor should provide information on
their user community.
The vendor should provide information of
the development community on its size
and responsiveness to assist with
development-oriented problems.
Page 30 of 46
6. Contract Type
This is a fixed price contract.
7. Place of Performance
This is a vendor hosted service to be accessed over the Internet.
8. Anticipated Period of Performance

Base Year - 12 months
Option Year 1 - 12 months
Option Year 2 12 months
mm/dd/yyyy mm/dd/yyyy
9. Deliverables/Delivery Schedule
Major contract deliverables and milestones are outlined below.
Deliverables
Delivery
Deliverable Description
Estimated Weeks
Sequence
from Contract Award
1
Vendor and NLM hold a post-award meeting to determine
Week 1
implementation plan and timeline as well as points of
contact on both ends
2
Provide up-to-date general documentation (system manuals,
Week 2
users guides, etc.)
3
Set up a sandbox with NLM data
Week 4
4
Complete training
Week 6
5
Comply with NIH IT-Security-Acquisition-Provisions (refer to
Week 26
requirement 3.01.06 for details)
6
Complete Security Assessment and Authorization process
Week 26
(refer to requirement 3.01.07 for details)
7
Complete initial implementation
Week 30
8
Support IPv6
Week 39
9
Provide maintenance and service support
Ongoing
Notes: Final deliverable schedule to be determined once project plan and timeline are established
during the post-award meeting.
All major deliverables shall be provided to the NLM Contracting Officers Representative (COR)
or other program officials designated by the COR by close of business on the specified due date
identified in the deliverable schedule.
NLM will have 20 working days to complete its review for each of the deliverables. NLM will
accept or reject the deliverables in writing by email. In the event of rejection of any deliverable,
the vendor shall be notified by email by the NLM Contracting Officer, giving the specific
Page 31 of 46
reason(s) for rejection. The vendor shall have 20 working days to correct the rejected
deliverable and redeliver it to the NLM COR.
10. Invoicing Requirements

Invoices shall be submitted on an annual basis, reflecting charges incurred during the period of
time covered by the current year service. The vendor shall submit a copy of the corresponding
invoice to the COR.
11. Post-Award Administration

The following COR will represent the Government for the purpose of this contract:
COR:
TBA
The COR will be responsible for monitoring this service and coordinating work schedules with
NLM personnel. The COR or the other program officials designated by the COR will be the
vendors point of contact(s) for resolution of technical and administrative concerns.
12. Evaluation Criteria

This is best value procurement. The Government will make award to the responsive,
responsible vendor whose proposal is most advantageous to the Government, price and other
factors considered. Technical merit and related evaluation factors are considered to be of
significantly greater importance than price.
The proposal, excluding appendices, should address all the requirements and be no longer than
100 pages. It will be rated on its capabilities to meet the evaluation criteria on the scale as
follows:
Technical Capability - 50%
The vendor must submit a concise written response directly addressing each of the
requirements described in the table within section 5, indicating if and/or how the offered
product and service meets them in the Vendors Response column within the table.
Service Support - 30%
The vendor should describe their support and service level commitment to NLMs implementation
and ongoing maintenance of the discovery and delivery platform.
Corporate Related Experience - 20%
The proposal should include URLs and passwords, if needed, of at least three independent
implementations that are open to the public and similar in size and scope to NLM that NLM can
assess as evidence of corporate experiences. The vendor should include contact information for
the institutions who can describe the performance of the vendors organization. The proposal
should include resumes, of not more three pages each, of any personnel who will be involved in
planning, training, implementation, and ongoing support of the NLM implementation.
Page 32 of 46
NLM will perform a final best-buy analysis taking into consideration the results of the technical
evaluation, cost/price analysis, and ability to complete the work as described.
Page 33 of 46
APPENDIX A: NIH-Security-Acquisition-Provision
NIH Information and Physical Access Security
Acquisition/Solicitation Language
Rev. -- 10/15/2012
**** (INCLUDE THE ARTICLE BELOW IN ACQUISITIONS AND SOLICITATIONS

WHEN ANY OF THE FOLLOWING PRESCRIPTIONS APPLY.) ****
NOTE: When security requirements relevant to the acquisition need to be included, the
Project Officer (PO), I/C Information Systems Security Officer (ISSO), and I/C Privacy
Officer will assist the acquisitions staff in selecting the appropriate language
1.
FEDERAL INFORMATION AND INFORMATION SYSTEMS SECURITY:

Include when contractor/subcontractor personnel will (1) develop, (2) have the
ability to access, or (3) host and/or maintain Federal information and/or Federal
information system(s). For additional information, see:
HHS Information Security Program Policy at:
http://intranet.hhs.gov/infosec/docs/policies_guides/ISPP/Information_Secu
rity_Program_Policy.pdf and
HHS Contractor Oversight Guide:
http://intranet.hhs.gov/infosec/docs/policies_guides/COG/Contractor_Oversight_Guide.pdf
2.
PERSONALLY IDENTIFIABLE INFORMATION (PII):

Include when contractor/subcontractor personnel will have access to, or use of,
Personally Identifiable Information (PII), including instances of remote access to or
physical removal of such information beyond agency premises or control. For
additional information, see:
OMB Memorandum M-06-15, Safeguarding Personally Identifiable
Information (05-22-06):
http://www.whitehouse.gov/omb/memoranda/fy2006/m-06-15.pdf
OMB Memorandum M-06-16, Protection of Sensitive Agency
Information (06-23-06):
http://www.whitehouse.gov/OMB/memoranda/fy2006/m06-16.pdf
OMB Memorandum M-06-19, Safeguarding Against and Responding to the
Breach of Personally Identifiable Information:
http://www.whitehouse.gov/omb/memoranda/fy2006/m06-19.pdf
Page 34 of 46
Guide for Identifying Sensitive Information, including Information in

Identifiable Form, at the NIH:
http://ocio.nih.gov/security/NIH_Sensitive_Info_Guide.pdf
3.
PHYSICAL ACCESS TO A FEDERALLY-CONTROLLED FACILITY:

Include when contractor/subcontractor personnel will have regular or prolonged
physical access to a Federally-controlled facility, as defined in FAR Subpart 2.1.
For additional information, see:
Homeland Security Presidential Directive/HSPD-12, Policy for a Common
Identification Standard for Federal Employees and Contractors (08-27-04):
http://www.whitehouse.gov/news/releases/2004/08/print/20040827-8.html
OMB Memorandum M-05-24, Implementation of Homeland Security
Presidential Directive (HSPD) 12 Policy for a Common Identification
Standard for Federal Employees and Contractors (08-05-05):
http://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdf
Federal Information Processing Standards Publication (FIPS PUB) 201-1
(Updated June 26, 2006): http://csrc.nist.gov/publications/fips/fips2011/FIPS-201-1-chng1.pdf
ARTICLE H. . NIH INFORMATION AND PHYSICAL ACCESS SECURITY

This acquisition requires the Contractor to [select all that apply from the drop down box]
develop, have the ability to access, or host and/or maintain Federal information and/or Federal
information system(s).
access, or use, Personally Identifiable Information (PII), including instances of remote access to
or physical removal of such information beyond agency premises or control.
have regular or prolonged physical access to a Federally-controlled facility, as defined in FAR

Subpart 2.1.
The Contractor and all subcontractors performing under this acquisition shall comply with the
following requirements:
**** (INCLUDE THE FOLLOWING IN ACQUISITIONS AND SOLICITATIONS WHEN

Page 35 of 46
PRESCRIPTION 1 ABOVE APPLIES TO THE ACQUISITION. NOTE: Based on information

provided by the ISSO and PO, select the appropriate general information type(s) below, AND
list the specific element(s) within those information types that are relevant to the
acquisition. For additional information, see:
-
a.
For Administrative, Management, and Support Information, use NIST SP 800-60,

Volume II: Appendices to Guide for Mapping Types of Information and Information
Systems to Security Categories, APPENDIX C, Table 3, at
http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf
For Mission Based Information, use NIST SP 800-60, Volume II: Appendices to Guide for
Mapping Types of Information and Information Systems to Security Categories,
APPENDIX D, Table 5, at http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP80060_Vol2-Rev1.pdf ) ****
Information Type
[ ]
Administrative, Management and Support Information:

______________________________
______________________________
______________________________
[ ]
Mission Based Information:

______________________________
______________________________
______________________________
**** (INCLUDE THE FOLLOWING IN ACQUISTIONS AND SOLICITATIONS WHEN

PRESCRIPTIONS 1 AND/OR 2 ABOVE APPLY TO THE ACQUISITION. NOTE: Based
on information provided by the ISSO and Project Officer, select the Security Level for each
Security Category and the Overall Security Level, which is the highest level of the three factors
(Confidentiality, Integrity, and Availability).
For additional information, see NIST SP 800-60, Volume II: Appendices to Guide for Mapping
Types of Information and Information Systems to Security Categories, Appendices C and D, at
http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf ; and Table 1:
Security Categorization of Federal Information and Information Systems, at
http://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table1.aspx ) ****
b.
Security Categories and Levels

Page 36 of 46
Confidentiality
Integrity
Availability
Level: [X] Low

Level: [X] Low
Level: [X] Low
[ ] Moderate
[ ] Moderate
[ ] Moderate
[ ] High
[ ] High
[ ] High
Overall
Level: [X] Low
[ ] Moderate
[ ] High

PRESCRIPTIONS 1, 2, AND/OR 3 ABOVE APPLY TO THE ACQUISITION. NOTE: Based
on information provided by the ISSO and Project Officer, check all levels that apply. For
additional information, see Table 2, Position Sensitivity Designations for Individuals Accessing
Agency Information at:
http://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table2.aspx .) ****
c.
Position Sensitivity Designations

The following sensitivity level(s), clearance type(s), and investigation requirements apply to
this contract:
[ ]
Level 6: Public Trust - High Risk. Contractor/subcontractor employees assigned to

Level 6 positions shall undergo a Suitability Determination and Background
Investigation (BI).
[ ]
Level 5: Public Trust - Moderate Risk. Contractor/subcontractor employees assigned

to Level 5 positions with no previous investigation and approval shall undergo a
Suitability Determination and a Minimum Background Investigation (MBI), or a
Limited Background Investigation (LBI).
[X]
Level 1: Non-Sensitive Contractor/subcontractor employees assigned to Level 1

positions shall undergo a Suitability Determination and National Agency Check and
Inquiry Investigation (NACI).
The Contractor shall submit a roster by name, position, e-mail address, phone number and
responsibility, of all staff (including subcontractor staff) working under this acquisition where
the Contractor will develop, have the ability to access, or host and/or maintain a federal
information system(s). The roster shall be submitted to the Project Officer, with a copy to the
Contracting Officer, within 14 calendar days of the effective date of this contract. Any
revisions to the roster as a result of staffing changes shall be submitted within 15 calendar
days of the change. The Contracting Officer will notify the Contractor of the appropriate
Page 37 of 46
level of investigation required for each staff member. An electronic template, "Roster of
Employees Requiring Suitability Investigations," is available for contractor use at
https://ocio.nih.gov/InfoSecurity/public/acquisition/Documents/SuitabilityRoster_10-1512.xlsx
Suitability Investigations are required for contractors who will need access to NIH
information systems and/or to NIH physical space. However, contractors who do not need
access to NIH physical space will not need an NIH ID Badge. Each contract employee
needing a suitability investigation will be contacted via email by the NIH Office of Personnel
Security and Access Control (DPSAC) within 30 days. The DPSAC email message will
contain instructions regarding fingerprinting as well as links to the electronic forms contract
employees must complete.
Additional information can be found at the following website:
http://idbadge.nih.gov/background/index.asp
All contractor and subcontractor employees shall comply with the conditions established for
their designated position sensitivity level prior to performing any work under this contract.
Contractors may begin work after the fingerprint check has been completed.

PRESCRIPTIONS 1 AND/OR 2 ABOVE APPLY TO THE ACQUISITION.) ****
d.
Information Security Training
d.1
Mandatory Training
All employees having access to (1) Federal information or a Federal information system or (2)
personally identifiable information, shall complete the NIH Information Security Awareness
Training course at http://irtsectraining.nih.gov/ before performing any work under this
contract. Thereafter, employees having access to the information identified above shall
complete an annual NIH-specified refresher course during the life of this contract. The
Contractor shall also ensure subcontractor compliance with this training requirement.
d.2
Role-based Training
HHS requires role-based training when responsibilities associated with a given role or
position, could, upon execution, have the potential to adversely impact the security posture of
one or more HHS systems. Read further guidance at: Secure One HHS Memorandum on
Role-Based Training Requirement
For additional information see the following:
http://prod.ocio.nih.gov/InfoSecurity/training/MandatoryInfoSecTraining/Pages/RoleBasedTr
Page 38 of 46
aining.aspx
The Contractor shall maintain a list of all information security training completed by each
contractor/subcontractor employee working under this contract. The list shall be provided to
the Project Officer and/or Contracting Officer upon request.
e.
Rules of Behavior
The Contractor shall ensure that all employees, including subcontractor employees, comply
with the NIH Information Technology General Rules of Behavior, which are available at
http://prod.ocio.nih.gov/InfoSecurity/training/Pages/nihitrob.aspx .

PRESCRIPTIONS 1, 2 AND/OR 3 ABOVE APPLY TO THE ACQUISITION.) ****
f.
Personnel Security Responsibilities

1.
The Contractor shall notify the Contracting Officer, Project Officer, and I/C ISSO
within five working days before a new employee assumes a position that requires a
suitability determination or when an employee with a suitability determination or
security clearance stops working under this contract. The Government will initiate a
background investigation on new employees requiring suitability determination and
will stop pending background investigations for employees that no longer work under
this acquisition.
2.
The Contractor shall provide the Project Officer with the name, position title, e-mail
address, and phone number of all new contract employees working under the contract
and provide the name, position title and suitability determination level held by the
former incumbent. If the employee is filling a new position, the Contractor shall
provide a position description and the Government will determine the appropriate
suitability level.
3.
The Contractor shall provide the Project Officer with the name, position title, and
suitability determination level held by or pending for departing employees.
Perform and document the actions identified in the Contractor Employee
Separation Checklist (attached) when a Contractor/subcontractor employee
terminates work under this contract. All documentation shall be made
available to the Project Officer and/or Contracting Officer upon request.
g.
Commitment to Protect Non-Public Departmental Information and Data

1.
Contractor Agreement
The Contractor, and any subcontractors performing under this contract, shall not
Page 39 of 46
release, publish, or disclose non-public Departmental information to unauthorized

personnel, and shall protect such information in accordance with provisions of the
following laws and any other pertinent laws and regulations governing the
confidentiality of such information:
- 18 U.S.C. 641 (Criminal Code: Public Money, Property or Records)
- 18 U.S.C. 1905 (Criminal Code: Disclosure of Confidential Information)
- Public Law 96-511 (Paperwork Reduction Act)
2.
Contractor Employee Non-Disclosure Agreement

Each employee, including subcontractors, having access to non-public Department
information under this acquisition shall complete the Commitment to Protect NonPublic Information Contractor Employee Agreement A copy of each signed and
witnessed Non-Disclosure agreement shall be submitted to the Project Officer prior to
performing any work under this acquisition.

THE CONTRACTOR IS REQUIRED TO:
(1) DEVELOP A FEDERAL INFORMATION SYSTEM(S) AT THE
CONTRACTOR'S/SUBCONTRACTOR'S FACILITY,
OR
(2) HOST AND/OR MAINTAIN A FEDERAL INFORMATION SYSTEM(S) AT THE
CONTRACTOR'S/SUBCONTRACTOR'S FACILITY.
(Note: This item includes two paragraphs, NIST SP 800-53 Assessment and Information
System Security Plan.)
For additional information, see Table 3: Federal Information Security Safeguard Requirements
Summary, at http://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table3.aspx . ****
h.
NIST SP 800-53 Assessment

This contract requires the Contractor to develop, host, and/or maintain a Federal information
system at the Contractors or any subcontractors facility. The Contractor shall submit an
annual information security assessment using NIST SP 800-53, Recommended Security
Controls for Federal Information Systems. The assessments shall be due annually within 30
days after the anniversary date of the contract, with the final assessment due at contract
completion. The assessments shall be based on the Federal IT Security Assessment
Framework and NIST SP 800-53 at:
NIST SP 800-53, Rev. 3
Page 40 of 46
http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updatederrata_05-01-2010.pdf
Annex 1: Baseline Security Controls for Low-Impact Information Systems
http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3Annex1_updated_may-01-2010.pdf
Annex 2: Baseline Security Controls for Moderate-Impact Information Systems
Annex 3: Baseline Security Controls for High-Impact Information Systems
The Contractor shall ensure that all of its subcontractors (at all tiers), where applicable,
comply with the above reporting requirements.
i.
Information System Security Plan (ISSP)

The Contractor shall update the acceptable ISSP submitted in their proposal every three
years following the effect date of the contract or when a major modification has been made to
its internal system. One copy each shall be submitted to the Project Officer and Contracting
Officer.
**** (INCLUDE THE FOLLOWING IN SOLICITATIONS AND CONTRACTS WHEN

PRESCRIPTION 2 ABOVE APPLIES TO THE ACQUISITION.) ****
j.
Loss and/or Disclosure of Personally Identifiable Information (PII) Notification of Data

Breach
The Contractor shall report all suspected or confirmed incidents involving the loss and/or
disclosure of PII in electronic or physical form. Notification shall be made to the NIH
Incident Response Team via email (IRT@mail.nih.gov) within one hour of discovering the
incident. The Contractor shall follow-up with IRT by completing and submitting one of the
following two forms within three (3) work days:
NIH PII Spillage Report [ http://ocio.nih.gov/docs/public/PII_Spillage_Report.doc ]
NIH Lost or Stolen Assets Report [ http://ocio.nih.gov/docs/public/Lost_or_Stolen.doc
**** (INCLUDE THE FOLLOWING IN ACQUISITIONS AND SOLICITATIONS

WHEN PRESCRIPTIONS 1 AND/OR 2 ABOVE APPLY TO THE ACQUISITION.)
****
Page 41 of 46
k.
Data Encryption
The following encryption requirements apply to all laptop computers containing HHS data at
rest and/or HHS data in transit. The date by which the Contractor shall be in compliance will
be set by the Project Officer, however, device encryption shall occur before any sensitive data
is stored on the laptop computer/mobile device, or within 45 days of the start of the contract,
whichever occurs first.
1.
The Contractor shall secure all laptop computers used on behalf of the government
using a Federal Information Processing Standard (FIPS) 140-2 compliant whole-disk
encryption solution. The cryptographic module used by an encryption or other
cryptographic product must be tested and validated under the Cryptographic Module
Validation Program to confirm compliance with the requirements of FIPS PUB 140-2
(as amended). For additional information, refer to http://csrc.nist.gov/cryptval.
2.
The Contractor shall secure all mobile devices, including non-HHS laptops and
portable media that contain sensitive HHS information by using a FIPS 140-2
compliant product. Data at rest includes all HHS data regardless of where it is stored.
3.
The Contractor shall use a FIPS 140-2 compliant key recovery mechanism so that
encrypted information can be decrypted and accessed by authorized personnel. Use of
encryption keys which are not recoverable by authorized personnel is prohibited. Key
recovery is required by OMB Guidance to Federal Agencies on Data Availability and
Encryption, November 26, 2001,
http://csrc.nist.gov/drivers/documents/ombencryption-guidance.pdf.
Encryption key management shall comply with all HHS and NIH policies
(http://intranet.hhs.gov/infosec/docs/guidance/hhs_standard_2007.pdf) and shall
provide adequate protection to prevent unauthorized decryption of the information.
All media used to store information shall be encrypted until it is sanitized or destroyed
in accordance with NIH procedures. Contact the NIH Center for Information
Technology for assistance
(http://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media
+Sanitization+Service).

PRESCRIPTION 3 ABOVE APPLIES TO THE ACQUISITION.) ****
l.
Physical Access Security

In accordance with OMB Memorandum M-05-24, the Contractor shall ensure that
background investigations are conducted for all contractor/subcontractor personnel who have
Page 42 of 46
(1) access to sensitive information, (2) access to Federal information systems, (3) regular or
prolonged physical access to Federally-controlled facilities, or (4) any combination thereof.
OMB Memorandum M-05-24 is available at
http://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdf. Agency personal
identification verification policy and procedures are identified below:
HHS Office of Security and Drug Testing, Personnel Security/Suitability Handbook (02-0105): http://www.hhs.gov/oamp/policies/personnel_security_suitability_handbook.html

THE CONTRACTOR/SUBCONTRACTOR WILL HOST NIH WEB PAGES OR
DATABASES.) ****
m.
Vulnerability Scanning Requirements

This acquisition requires the Contractor to host an NIH webpage or database. The Contractor
shall conduct periodic and special vulnerability scans, and install software/hardware patches
and upgrades to protect automated federal information assets. The minimum requirement
shall be to protect against vulnerabilities identified on the SANS Top-20 Internet Security
Attack Targets list ( http://www.sans.org/top20/?ref=3706#w1 ). The Contractor shall report
the results of these scans to the Project Officer on a monthly basis, with reports due 10
calendar days following the end of each reporting period. The Contractor shall ensure that all
of its subcontractors (at all tiers), where applicable, comply with the above requirements.

THE CONTRACTOR/SUBCONTRACTOR WILL BE ACCESSING FEDERAL
INFORMATION BUT WILL NOT BE REQUIRED TO INSTALL, OPERATE, MAINTAIN,
UPDATE, AND/OR PATCH SOFTWARE.) ****
n.
Using Secure Computers to Access Federal Information

1.
The Contractor shall use an USGCB compliant computer when processing information
on behalf of the Federal government.
2.
The Contractor shall install computer virus detection software on all computers used to
access information on behalf of the Federal government. Virus detection software and
virus detection signatures shall be kept current.

THE CONTRACTOR/SUBCONTRACTOR WILL BE REQUIRED TO INSTALL,
OPERATE, MAINTAIN, UPDATE, AND/OR PATCH SOFTWARE.) ****
Page 43 of 46
o.
Common Security Configurations

1. The Contractor shall ensure new systems are configured with the applicable Federal
Desktop Core Configuration (FDCC) (http://nvd.nist.gov/fdcc/download_fdcc.cfm) and
applicable configurations from http://checklists.nist.gov, as jointly identified by the
Operating Division (OPDIV)/Staff Division (STAFFDIV) Contracting Officers Technical
Representative (COTR) and the Chief Information Security Officer (CISO).
2. The Contractor shall ensure hardware and software installation, operation, maintenance,
update, and/or patching will not alter the configuration settings specified in: (a) the FDCC
(http://nvd.nist.gov/fdcc/index.cfm); and (b) other applicable configuration checklists as
referenced above.
3. The Contractor shall ensure applications are fully functional and operate correctly on
systems configured in accordance with the above configuration requirements.
4. The Contractor shall ensure applications designed for end users run in the standard user
context without requiring elevated administrative privileges.
5. Federal Information Processing Standard 201 (FIPS-201)-compliant, Homeland Security
Presidential Directive 12 (HSPD-12) card readers shall: (a) be included with the purchase
of servers, desktops, and laptops; and (b) comply with FAR Subpart 4.13, Personal
Identity Verification.
6. The Contractor shall ensure that all of its subcontractors (at all tiers) comply with the
above requirements.
**** (INCLUDE THE FOLLOWING IN ALL ACQUISITIONS.) ****
p.
Special Information Security Requirements for Foreign Contractors/Subcontractors

When foreign contractors/subcontractors perform work under this acquisition at non-US
Federal Government facilities, provisions of HSPD-12 do NOT apply.
**** (INCLUDE THE FOLLOWING WHEN PRESCRIPTIONS 1 AND/OR 2 ABOVE

APPLY TO THE ACQUISITION.) ****
q.
REFERENCES: INFORMATION SECURITY INCLUDING PERSONALLY

IDENTIFIABLE INFORMATION
**** (INCLUDE THE FOLLOWING WHEN PRESCRIPTION 3 ABOVE APPLIES TO

THE ACQUISITION.) ****
Page 44 of 46
r.
REFERENCES: PHYSICAL ACCESS SECURITY
****SECTION L (Technical Proposal Instructions), SOLICITATION LANGUAGE****
**** (INCLUDE THE FOLLOWING WHEN CONTRACTOR/SUBCONTRACTOR

PERSONNEL WILL HAVE ACCESS TO, OR USE OF, PERSONALLY IDENTIFIABLE
INFORMATION (PII), INCLUDING INSTANCES OF REMOTE ACCESS TO OR PHYSICAL
REMOVAL OF SUCH INFORMATION BEYOND AGENCY PREMISES OR CONTROL. FOR
ADDITIONAL INFORMATION, SEE:
OMB Memorandum M-06-15, Safeguarding Personally Identifiable Information (05-22-06):
http://www.whitehouse.gov/omb/memoranda/fy2006/m-06-15.pdf.
OMB Memorandum M-06-16, Protection of Sensitive Agency Information (06-23-06):
http://www.whitehouse.gov/OMB/memoranda/fy2006/m06-16.pdf.
OMB Memorandum M-06-19, Safeguarding Against and Responding to the Breach of
Personally Identifiable Information:
http://www.whitehouse.gov/omb/memoranda/fy2006/m06-19.pdf.
Guide for Identifying Sensitive Information, including Information in Identifiable Form, at
the NIH: http://ocio.nih.gov/security/NIH_Sensitive_Info_Guide.pdf) ****
__.
Personally Identifiable Information (PII) Security Plan

The Offeror shall submit a PII Security Plan with its technical proposal that addresses each of
the following items:
1.
2.
3.
4.
5.
6.
Verify the information categorization to ensure the identification of the PII

requiring protection.
Verify the existing risk assessment.
Identify the Contractors existing internal corporate policy that addresses the
information protection requirements of the SOW.
Verify the adequacy of the Contractors existing internal corporate policy that
addresses the information protection requirements of the SOW.
Identify any revisions, or development, of an internal corporate policy to
adequately address the information protection requirements of the SOW.
For PII to be physically transported to or stored at a remote site, verify that the
security controls of NIST Special Publication 800-53 involving the encryption
of transported information will be implemented.
http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3Page 45 of 46
final_updated-errata_05-01-2010.pdf
7.
8.
9.
When applicable, verify how the NIST Special Publication 800-53 security
controls requiring authentication, virtual private network (VPN) connections
will be implemented.
When applicable, verify how the NIST Special Publication 800-53 security
controls enforcing allowed downloading of PII will be implemented.
Identify measures to ensure subcontractor compliance with safeguarding PII.
The details contained in the Offerors PII Security Plan must be commensurate with the size
and complexity of the contract requirements based on the System Categorization specified
above in the subparagraph entitled Security Categories and Levels. The Offerors PII
Security Plan will be evaluated by the Government for appropriateness and adequacy.
**** (INCLUDE THE FOLLOWING WHEN THE CONTRACT REQUIRES THE

CONTRACTOR TO:
(1) DEVELOP A FEDERAL INFORMATION SYSTEM(S) AT THE
CONTRACTOR'S/SUBCONTRACTOR'S FACILITY,
OR
(2) HOST AND/OR MAINTAIN A FEDERAL INFORMATION SYSTEM(S) AT THE
CONTRACTOR'S/SUBCONTRACTOR'S FACILITY.
For additional information, see Table 3: Federal Information Security Safeguard Requirements
Summary, at http://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table3.aspx
Information System Security Plan

The Offeror shall submit an Information System Security Plan (ISSP) with its technical
proposal using the current template in Appendix A of NIST SP 800-18, Guide to Developing
Security Plans for Federal Information Systems
(http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf). The details
contained in the ISSP must be commensurate with the size and complexity of the contract
requirements based on the System Categorization determined above in the subparagraph
entitled Security Categories and Levels. The Offeror shall also identify measures to ensure
subcontractor compliance with the ISSP. The ISSP will be evaluated by the Government for
appropriateness and adequacy.
The Contractor will be required to update and resubmit its ISSP every three years following
the effective date of the contract or when a major modification has been made to its internal
system.
Page 46 of 46

Statement of Work: National Library of Medicine Discovery and Delivery Platform

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Statement of Work: National Library of Medicine Discovery and Delivery Platform

Uploaded by

Copyright:

Available Formats

STATEMENT OF WORK

National Library of Medicine Discovery and Delivery Platform

Advanced search filtering

Perform browse searches

Perform browse searches

Perform browse searches

Navigate results on browse

Known item search

"Did you mean?" and

Stop word filtering

Vernacular searching and

Subject search term

View authority record in

Apply single or multiple

Allows users to view a textual/labeled

Remove refinements from

Retrieve multiple related

Record retrieval limit

Real-time item availability

Custom relevancy ranking

Boost relevancy ranking

Blended search results

Search result sorting

Saving search results

Saving search queries

Search result output

Output results from

Print selected records

Request form default and

Request form changes

My Account manage user

Save search query as an

Look and feel

System should meet ADA and Section 508

Search result display

Search strategy display

Record displays varying levels of

Brief view display

MARC view display

Accentuate search terms

Indication of online access

Foreign language display

Diacritics and vernacular

Spotlight NLM resources

Mobile version retains full

Bypass mobile version

Secure Socket Layer (SSL)

Web application attacks

System should meet the HHS/NIH/NLM

Multiple instances for

Multiple instances fault

Vendor needs to comply with IT-SecurityAcquisition-Provisions (Appendix A).

Export report data

System upgrades and

Time-out for logged in

Session time-out re-login

4. INTEROPERATBILITY WITH RELATED SYSTEMS/APPLICATIONS

API for record download

Interoperability with the

System should provide an API for

Initial ingest of ILS data

Incremental ingest of ILS

DOCLINE users create

System should support a progressive

(INCLUDE THE FOLLOWING IN ALL ACQUISITIONS.)

SECTION L (Technical Proposal Instructions), SOLICITATION LANGUAGE