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

8/10/2019 Statement of Work: National Library of Medicine Discovery and Delivery Platform

1/46

Page 1of 46

STATEMENT OF WORK

National Library of Medicine Discovery and Delivery Platform

NIHLM2015369


2/46

Page 2of 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


3/46

Page 3of 46

STATEMENT OF WORK

1. Project Title

National Library of Medicine Discovery and Delivery Platform

2. Background InformationThe 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, NLMsonline public access catalog (OPAC), has been the front-

end 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 amodern, 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. ObjectivesNLM 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 WorkThe 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 WorkThe 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.


4/46

Page 4of 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.


5/46

Page

riority No. Requirement Description Vendors Response

. FUNCTIONAL

ee sub-requirements 1.01 Simple search System should provide simple one-box

searching. Searching by keyword

anywhere should be the default search.

Mandatory 1.01.01 Search keywords anywhere

in the record

Allows users to search by keyword,

multiple keywords or keyword phrase

anywhere in the record.

Mandatory 1.01.02 Search using Boolean

operators

Allows users to use Boolean operators

(AND, OR, NOT) to search anywhere in

the record. This may optionally include

adjacency operators.

Mandatory 1.01.03 Target search fields Allows users to target specific fields to

search. Available choices of fields should

be configurable by the library.

Mandatory 1.01.04 Simple search truncation

options

Allows users to truncate terms (i.e. use

wildcards) in the simple search box.

Mandatory 1.01.05 Target specific collection

resources

Allow users to target collection resources

to search. Users can specify the NLM ILS

catalog, articles only, licensed resources

only, etc. to search.

ee sub-requirements 1.02 Advanced search System should provide a separate

advanced search form. The advanced

search form should be expandable with

additional search rows.

Mandatory 1.02.01 Boolean searching Allows users to use Boolean operators

(AND, OR, NOT) in the advanced search

form.


6/46

Page


Mandatory 1.02.02 Advanced search field

search options

Allows users to choose which fields to

search in the advanced search form.

Available choices of fields should be

configurable by the library.

Mandatory 1.02.03 Advanced search

truncation options

Allows users to truncate terms (i.e. use

wildcards) in the advanced search form.

Desirable 1.02.04 Nesting, phrase and

proximity searching

Allows users to nest search terms and

perform phrase and proximity searchingin the advanced search form.

Mandatory 1.02.05 Advanced search filtering

options

Allows users to filter items in the

advanced search form. Filtering options

should be configurable by the library.

ee sub-requirements 1.03 Browse search 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

Mandatory 1.03.01 Perform browse searches

by authors

Allows users to conduct browse searches

of authors and displays all authors inbibliographic records plus any cross-

references in authority records as one

unified list.


by subject headings


of subject headings and displays all

subject headings in bibliographic records

plus any cross-references in authority

records as one unified list.


7/46

Page



by titles


of titles and displays all titles in

bibliographic records plus any cross-

references in authority records as one

unified list.


by series


of series and displays all series in

bibliographic records plus any cross-references in authority records as one

unified list.

Mandatory 1.03.05 Navigate results on browse

list

Allows users to navigate to the previous

and next result pages on the browse list.

Mandatory 1.03.06 Utilize cross references

from authority records in

the browse search results

Allows users to link from a cross

reference to the preferred term in the

browse search results.

Mandatory 1.04 Searching across multiple

collection resources

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

Mandatory 1.05 Known item search 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


8/46

Page


display at the very top of the search

results based on relevancy ranking.

ee sub-requirements 1.06 Smart searching 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.Mandatory 1.06.01 "Did you mean?" and

autocorrect

System should present users with a "Did

you mean?" suggestion for spell check

and similarly spelled words.

Mandatory 1.06.02 Autocomplete System should present users with

suggested terms based on text entered.

Mandatory 1.06.03 Autostemming Allows users to search a root word and

automatically search other words

containing the root.

Desirable 1.06.04 Synonym expansion System should search for synonyms as

well as the words entered in the query.

Mandatory 1.06.05 Stop word filtering System should filter out library

configurable stop words from the search

query.Mandatory 1.06.06 Vernacular searching and

retrieval

Allows users to retrieve results using

vernacular characters.

Mandatory 1.06.07 Character normalization Characters entered should be input and

search neutral and normalized. e.g.,

search by either Quebec or Qubec

will retrieve both.

ee sub-requirements 1.07 Subject search term

explosion

System should include subject heading

explosion and thesaurus matching. The

system should search for all subordinate


9/46

Page


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.

Desirable 1.07.01 Turn on/off subject

explosion

Allows users to turn on/off the entire

explosion or select individual narrower

terms to include or exclude from the

search. Exploded terms should be thedefault.

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

Desirable 1.07.03 Explode MeSH

subheadings

When searching a MeSH subheading

term, system should also retrieve all

records which contain narrower

subheading terms in the subject heading.

Desirable 1.07.04 Map synonyms to

preferred MeSH term

System should map all "see" cross

references listed in the MeSH record to

the preferred term.

ee sub-requirements 1.08 Authority record searchingand retrieval

Allows users to search and retrieveauthority records via keyword search for

name heading, name/title heading, series

heading, and subject heading in authority

records.

Desirable 1.08.01 Authority keyword

searching

Allows users to search and retrieve

authority records by keyword.


10/46

Page 1


Desirable 1.08.02 Display links to authority

records in results from

browse search of

bibliographic records.

System should include authority record

links in the results from browse search of

bibliographic records.

Desirable 1.08.03 View authority record in a

textual display

Allows users to view a textual/labeled

display of the main heading, cross

references, and public notes of the

authority record.Desirable 1.08.04 View authority record in

the MARC format

Allows users to view the entire MARC

authority record.

Desirable 1.08.05 Authority record outputs Allows users to print, email, export,

download, and text message the

authority record in text, MARC and

MARCXML formats.

Desirable 1.09 Blank search 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.

ee sub-requirements 1.10 Search refinements Allows users to limit their searches tospecific facets.

Mandatory 1.10.01 Customizable refinements The placement and the types of facets or

limits presented to the user should be


Mandatory 1.10.02 Facet/limit groupings The number of values that appear under

each facet or limit should be configurable

by the library.

Mandatory 1.10.03 Apply single or multiple

refinements with a search

Allows users to choose single or multiple

facets when searching.


11/46

Page 1


Mandatory 1.10.04 Select refinements after

search

Allows users to select single or multiple

values within one or more facets after a

search has run.

Mandatory 1.10.05 Remove refinements from

a search result

Allows users to deselect any refinements

previously applied to a search. This can

be single or multiple de-selections.

ee sub-requirements 1.11 Perform additional

searches from a link in aresult record

Allows users to retrieve additional

records by clicking on an author, subject,title, and series links in the result record.

Desirable 1.11.01 Retrieve a single related

title from a 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.

Desirable 1.11.02 Retrieve multiple related

titles from a result record

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.

Mandatory 1.12 Record retrieval limit Allows users to retrieve an unlimited

number of search results.Mandatory 1.13 Real-time item availability

status

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.

Mandatory 1.14 OpenURL System should support OpenURL linking

to facilitate access from search results to

licensed or open access electronic full

text and related services. The OpenURL


12/46

Page 1


links should display within brief records in

the search results and within detailed

records.

Mandatory 1.15 Persistent URLs 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 bythe library.

Mandatory 1.16 De-duplication System should identify and manage the

display of duplicate records within search

results.

Desirable 1.17 Record grouping System should group different

manifestations of the same work

together in a single cluster.

ee sub-requirements 1.18 Relevancy ranking 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.

Mandatory 1.18.01 Custom relevancy ranking Relevancy ranking criteria should beconfigurable by the library.

Mandatory 1.18.02 Boost relevancy ranking Boost relevance ranking by specific

factors configurable by the library.

Mandatory 1.19 Blended search results System should display one blended list of

search results including all collection

resources.

Mandatory 1.20 Search result sorting Allows users to sort the search results by

criteria that are configurable by the

library.


13/46

Page 1


Desirable 1.21 Search history Allows users to view, rerun and combine

previous search queries during a single

search session.

Mandatory 1.22 Saving search results 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.Desirable 1.23 Saving search queries Allows users to save or purge their search

queries, rerun and combine saved

queries when logged in to My Account

ee sub-requirements 1.24 Search result output 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.Mandatory 1.24.01 Output results from

various record displays

configurable by the library

Allows users to output results from

various record displays (e.g., full records

with holdings, full records with no

holdings and brief records.)

Mandatory 1.24.02 Print selected 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.)


14/46


15/46

Page 1


ee sub-requirements 1.26 Requesting for physical

materials

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.

Mandatory 1.26.01 Request form default and

manual input

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.

Mandatory 1.26.02 Request form changes Allows users to toggle from automatic

input to manual input on the request

form.

Mandatory 1.26.03 Request submission 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 datewhen logged in My Account.

Mandatory 1.26.04 Request limits The limit for the number of requests per

user per day should be configurable by

the library.

ee sub-requirements 1.27 My Account Allows onsite and remote users to sign

into a "My Account".

Desirable 1.27.01 My Account creation Allows users to create a "My Account"

where they can log-in and log-out.


16/46

Page 1


Mandatory 1.27.02 My Account preferences Allows users to customize preferences

which may include sorting, number of

results per page, etc.

Mandatory 1.27.03 My Account retrieves

saved results lists and

queries

Allows users to view and delete items

from previously saved results lists and

search queries.

Desirable 1.27.04 My Account password

reset

Allows users to request a password reset

using an "I forgot my password" feature.

Mandatory 1.27.05 My Account requests for

physical materials

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.

Desirable 1.27.06 My Account manage user

accounts

System should provide tools for the

library to manage users' My Accounts,

such as batch deleting inactive accounts.

Mandatory 1.28 Guest access 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 theseadditional functions are available except

requests are limited to the NLM domain.

ee sub-requirements 1.29 Alerts 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.


17/46

Page 1


Mandatory 1.29.01 Save a search query as an

alert

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.Mandatory 1.29.02 Configurable alert

parameters

Allows authenticated users to configure

the parameters of their email alerts.

Mandatory 1.29.03 Manage alerts Allows authenticated users to edit and

delete their alerts.

Mandatory 1.29.04 Save search query as an

RSS feed

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.

. USER INTERFACE

ee sub-requirements 2.01 Look and feel System should provide an aesthetically

appealing look and feel consistent with

current web design standards.

Mandatory 2.01.01 User-friendly design 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.


18/46


19/46

Page 1


Mandatory 2.04.03 Results page display Results page display of search results


Mandatory 2.04.04 Brief view display Brief view display of an individual record

selected from search results should be


Mandatory 2.04.05 Detailed display Detailed display of an individual record

selected from search results should be


Desirable 2.04.06 MARC view display Allows users to view the entire MARC

bibliographic record after selecting a

result.

Mandatory 2.04.07 Accentuate search terms System should highlight, bold or italicize

the search terms entered by the user in

the results display.

Mandatory 2.05 Indication of online access System should provide an indication of

NLM online access to resources with

availability and location. This can be via

an icon or text display.

ee sub-requirements 2.06 Foreign language display System should support display of foreign

language materials.

Mandatory 2.06.01 Diacritics and vernacularcharacters

System should display diacritics andvernacular characters in the appropriate

script.

Mandatory 2.06.02 UTF-8 System should be compatible with the

UTF-8 character set.

ee sub-requirements 2.07 Help System should provide links to the

corresponding sections of the vendor's

online help documentation and an index

to access all help topics.


20/46

Page 2


Mandatory 2.07.01 Customizable help Modifying the help text for the system

and adding additional help information


Desirable 2.07.02 Context-sensitive help System should provide specific help to

the user based on where the user is in

the system interface.

Mandatory 2.08 Links to informational

pages

Adding customizable links on the system

interface should be configurable by thelibrary.

Desirable 2.09 Spotlight NLM resources

from within the search

results

Indication of NLM resources to spotlight

or promote based on a user's search

criteria within the search results should


Desirable 2.10 Social media Allows users to seamlessly share search

result records via social media.

ee sub-requirements 2.11 Mobile access System should be accessible in a browser

on mobile devices and support

responsive web design.

Mandatory 2.11.01 Responsive design System should support responsive web

design for mobile users.

Mandatory 2.11.02 Mobile version retains fullfunctionality

Mobile version should include the samefeatures and functionality of the desktop

version.

Mandatory 2.11.03 Bypass mobile version Allows mobile users to bypass the mobile

version and access the full desktop

version on their mobile device.


21/46

Page 2


Desirable 2.12 Embedded audio/video

player

Allows users to listen and view audio-

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

. ADMINISTRATIVE

ee sub-requirements 3.01 System security System should meet the HHS/NIH/NLM

security requirements.

Mandatory 3.01.01 Secure Socket Layer (SSL)

certificates

System should support SSL server

authentication. The SSL certificate must

be specific to the URL used rather than a

wildcard certificate.

Desirable 3.01.02 Password complexity 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.

Desirable 3.01.03 Storing passwords System should store a securecryptographic hash of a user's password.

Mandatory 3.01.04 Encrypted connection If an external authentication service is

used, the connection between the system

and the service should be encrypted.

Mandatory 3.01.05 Web application attacks System should resist web application

attacks.

Mandatory 3.01.06 Privacy policy System should comply with the library's

privacy policy


22/46

Page 2


(http://www.nlm.nih.gov/privacy.html)

Mandatory 3.01.07 IT-Security-Acquisition-

Provisions

Vendor needs to comply with IT-Security-

Acquisition-Provisions (Appendix A).

Mandatory 3.01.08 Security Assessment and

Authorization (SA&A)

Vendor needs to complete Security

Assessment and Authorization (SA&A) for

the system/service based on NIST SP 800-

53A and NIST SP 800-115 within sixmonths after contract is awarded.

ee sub-requirements 3.02 Multiple instances System should have the ability to deploy

multiple instances. System should allow

NLM to have a test instance/sandbox

separate from other libraries.

Mandatory 3.02.01 Multiple instances for

development, testing, and

production

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.

Mandatory 3.02.02 Multiple instances fault

tolerance and scaling

System should support multiple instances

for scaling and fault tolerance. The library

should be provided with information onhow the architecture supports scalability

and fault tolerance.

ee sub-requirements 3.03 Platform support System architecture should be

compatible with the library's

infrastructure and resources.
http://www.nlm.nih.gov/privacy.htmlhttp://www.nlm.nih.gov/privacy.htmlhttp://www.nlm.nih.gov/privacy.htmlhttp://www.nlm.nih.gov/privacy.html


23/46

Page 2


Mandatory 3.03.01 NLM provided domain

name

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 provideURLs of example implementations and

emails leaving the system that NLM can

review as evidence.

Mandatory 3.03.02 Internet protocol System should support IPv6.

Mandatory 3.04 Implementation System should be implemented within

the library's designated timeframe and

resources after contract award.

Mandatory 3.05 Administrative backend 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.ee sub-requirements 3.06 Statistical reporting 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.


24/46

Page 2


Mandatory 3.06.01 Anonymized data System should anonymize the usage data

but distinguish between user groups

(external, internal, and staff users).

Desirable 3.06.02 Export report data System should allow for export of report

data to third party software and/or in

CSV format by authorized library staff.

Desirable 3.06.03 Customizable reports System should allow for customization of

statistical reports by authorized librarystaff.

ee sub-requirements 3.07 Support Vendor should provide technical support

and customer service.

Mandatory 3.07.01 Ongoing support Vendor should provide ongoing

comprehensive technical support. A point

of contact should be designated for NLM

support requests.

Mandatory 3.07.02 System upgrades and

patches

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.

ee sub-requirements 3.08 Training Vendor should provide onsite and/oronline training.

Mandatory 3.08.01 Train trainers Vendor should provide initial training for

the library staff who will in turn train staff

and end-users.

Mandatory 3.08.02 Train administrators Vendor should provide onsite and online

training for NLM system administrators

on the initial customization and ongoing

maintenance.


25/46

Page 2


ee sub-requirements 3.09 Documentation Vendor should provide detailed up-to-

date system documentation.

Mandatory 3.09.01 Architecture

documentation

Vendor should provide up-to-date

technical documentation of software

architecture.

Mandatory 3.09.02 Technical documentation Vendor should provide up-to-date

documentation describing APIs, deep

links, plug-ins, and adapters availablewith the system.

Mandatory 3.09.03 User manuals Vendor should provide up-to-date

manuals for end-users, NLM system

administrators, and support staff.

Mandatory 3.09.04 Security documentation Vendor should provide up-to-date

documentation describing security

policies, procedures, and practices.

ee sub-requirements 3.10 Time-out for logged in

sessions

System time-out limit on sessions should


Desirable 3.10.01 System time-out warning System should provide a pop-up window

in advance of a user being timed-out.

Desirable 3.10.02 Session time-out re-login System should end the user session and

require re-login after the system time-outwarning expires.

. INTEROPERATBILITY WITH RELATED SYSTEMS/APPLICATIONS

Mandatory 4.01 API for record download

from ILS

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.

ee sub-requirements 4.02 Interoperability with the System should have built-in mechanisms


26/46

Page 2


Integrated Library System

(ILS)

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.

Mandatory 4.02.01 Initial ingest of ILS data System should harvest all bibliographic,

holdings, item-specific, and authority

data from the NLM ILS as an initial ingestand index the data.

Mandatory 4.02.02 Incremental ingest of ILS

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.

Mandatory 4.02.03 Real-time interactions System should present item availability

status information using a real-time look-

up service and support processing closed

stack requests through interoperation

with the NLM ILS while enabling users to

remain in the system.ee sub-requirements 4.03 Interoperation with

DOCLINE

System should interoperate with

DOCLINE

(http://www.nlm.nih.gov/docline/), an

internally developed NLM system that

facilitates ILL requests among DOCLINE

member libraries.

Desirable 4.03.01 DOCLINE users create

requests from

bibliographic information

Allows DOCLINE users to search the

system and retrieve specific fields in

order to initiate an ILL request.
http://www.nlm.nih.gov/docline/http://www.nlm.nih.gov/docline/http://www.nlm.nih.gov/docline/http://www.nlm.nih.gov/docline/


27/46

Page 2


Desirable 4.03.02 DOCLINE communications

via SSL (Secure Socket

Layer)

System should allow for DOCLINE

communications via SSL to avoid issues

with a user's browser.

Mandatory 4.04 Interoperability with link

resolvers

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.Mandatory 4.05 Interoperability with NLM

digital repositories and

other collection resources

System should support initial metadata

and full text transfer, continual updates,

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.

ee sub-requirements 4.06 Search engine integration System should support harvesting and

crawling of NLMs data by third-party

search engines.

Mandatory 4.06.01 Search engine crawling System should guide third-party search

engines to harvest and crawl records

exposed through the system.Mandatory 4.06.02 Search engine optimization

(SEO)

System should provide SEO features for

catalog records that are configurable by

the library.

Mandatory 4.07 Metadata schemas System should support various standard

metadata schemas and accommodate

any kind of structured XML.

. OTHERS

Mandatory 5.01 Development and

enhancement

System should support a progressive

development cycle. The vendor should


28/46

Page 2


supply as evidence a history of new

system releases and participation of user

libraries in decision making on

development in the past three years.

Mandatory 5.02 Technology roadmap Vendor and developer community should

have an innovative technology roadmap

that defines a system evolution path. The

vendor should provide a history ofroadmaps in the past three years as

evidence.

ee sub-requirements 5.03 Authentication/

Authorization

System should be compatible with the

library's policies for licensed resources

and physical materials.

Desirable 5.03.01 My Account authentication Allows users to log in to "My Account" to

access certain functions

Desirable 5.03.02 Automatic registration for

Federated Login

When users log in via Federated Login,

there is no need for explicit

registration/sign-up.

Mandatory 5.03.03 Authorize users to request

use of physical materials.

Sessions originating within NLM domain

may authenticate using an ILS patron

account to request materials. Note: NLMdoes not use a PIN for patron

authentication.

Mandatory 5.04 Browser System should be compatible with all

major web browsers.

ee sub-requirements 5.05 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.


29/46

Page 2


Mandatory 5.05.01 Availability 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.

Mandatory 5.05.02 Response time System should provide an average

response time not greater than twoseconds for user login and each query,

regardless of the number of concurrent

users on the system.

Mandatory 5.05.03 Monitor system

performance

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.

ee sub-requirements 5.06 Scalability System should allow the library to

broaden capacity, content and users

without requiring changes to its

deployment architecture.Mandatory 5.06.01 Accommodate additional

collection resources

System should allow the library to scale

and broaden discovery and delivery to

licensed digital and electronic resources

and published content.

Mandatory 5.06.02 Increased access System should accept increased user

access capacity as demand warrants.

Mandatory 5.07 Extensibility System should allow the library to extend

the functionality via APIs and modifying

the code base.


30/46

Page 3


Mandatory 5.08 Vendor viability Vendor should provide information on

viability and stability of funding sources

and resources.

Mandatory 5.09 Vendor's user community Vendor should provide information on

their user community.

Mandatory 5.10 Developer community The vendor should provide information of

the development community on its size

and responsiveness to assist withdevelopment-oriented problems.


31/46

Page 31of 46

6. Contract TypeThis is a fixed price contract.

7. Place of PerformanceThis is a vendor hosted service to be accessed over the Internet.

8. Anticipated Period of PerformanceBase Year - 12 months mm/dd/yyyymm/dd/yyyy

Option Year 1 - 12 months mm/dd/yyyymm/dd/yyyy

Option Year 212 months mm/dd/yyyymm/dd/yyyy



9. Deliverables/Delivery ScheduleMajor contract deliverables and milestones are outlined below.

Deliverables

Delivery

Sequence

Deliverable Description Estimated Weeks

from Contract Award

1 Vendor and NLM hold a post-award meeting to determine

implementation plan and timeline as well as points of

contact on both ends

Week 1

2 Provide up-to-date general documentation (system manuals,

users guides, etc.)

Week 2

3 Set up a sandbox with NLM data Week 4

4 Complete training Week 65 Comply with NIH IT-Security-Acquisition-Provisions (refer to

requirement 3.01.06 for details)

Week 26

6 Complete Security Assessment and Authorization process

(refer to requirement 3.01.07 for details)

Week 26

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


32/46

Page 32of 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 RequirementsInvoices 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 AdministrationThe 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 CriteriaThis 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 Responsecolumn 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.


33/46

Page 33of 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.


34/46

Page 34of 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 Federalinformation 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. Foradditional 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 AgencyInformation (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
http://intranet.hhs.gov/infosec/docs/policies_guides/ISPP/Information_Security_Program_Policy.pdfhttp://intranet.hhs.gov/infosec/docs/policies_guides/ISPP/Information_Security_Program_Policy.pdfhttp://c/Users/zunigalu/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/0RQLXCZB/%09%09%20%20%20%20%20%20%20%20%20%20%20%20%20%20http:/intranet.hhs.gov/infosec/docs/policies_guides/COG/Contractor_Oversight_Guide.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2006/m-06-15.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2006/m-06-15.pdfhttp://www.whitehouse.gov/OMB/memoranda/fy2006/m06-16.pdfhttp://www.whitehouse.gov/OMB/memoranda/fy2006/m06-16.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2006/m06-19.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2006/m06-19.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2006/m06-19.pdfhttp://www.whitehouse.gov/OMB/memoranda/fy2006/m06-16.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2006/m-06-15.pdfhttp://c/Users/zunigalu/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/0RQLXCZB/%09%09%20%20%20%20%20%20%20%20%20%20%20%20%20%20http:/intranet.hhs.gov/infosec/docs/policies_guides/COG/Contractor_Oversight_Guide.pdfhttp://c/Users/zunigalu/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/0RQLXCZB/%09%09%20%20%20%20%20%20%20%20%20%20%20%20%20%20http:/intranet.hhs.gov/infosec/docs/policies_guides/COG/Contractor_Oversight_Guide.pdfhttp://intranet.hhs.gov/infosec/docs/policies_guides/ISPP/Information_Security_Program_Policy.pdfhttp://intranet.hhs.gov/infosec/docs/policies_guides/ISPP/Information_Security_Program_Policy.pdf


35/46

Page 35of 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) 12Policy 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/fips201-

1/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
http://ocio.nih.gov/security/NIH_Sensitive_Info_Guide.pdfhttp://ocio.nih.gov/security/NIH_Sensitive_Info_Guide.pdfhttp://www.whitehouse.gov/news/releases/2004/08/print/20040827-8.htmlhttp://www.whitehouse.gov/news/releases/2004/08/print/20040827-8.htmlhttp://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdfhttp://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdfhttp://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdfhttp://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdfhttp://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdfhttp://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdfhttp://www.whitehouse.gov/news/releases/2004/08/print/20040827-8.htmlhttp://ocio.nih.gov/security/NIH_Sensitive_Info_Guide.pdf


36/46

Page 36of 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:

- 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, athttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-

60_Vol2-Rev1.pdf) ****

a. 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 MappingTypes 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
http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table1.aspxhttp://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table1.aspxhttp://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table1.aspxhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdfhttp://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf


37/46

Page 37of 46

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

Integrity Level: [X] Low [ ] Moderate [ ] HighAvailability Level: [X] Low [ ] Moderate [ ] High

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

**** (INCLUDE THE FOLLOWING IN ACQUISITIONS AND SOLICITATIONS WHENPRESCRIPTIONS 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. Foradditional 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 toLevel 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 aLimited 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 andInquiry Investigation (NACI).

The Contractor shall submit a roster by name, position, e-mail address, phone number andresponsibility, 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. Anyrevisions 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
http://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table2.aspxhttp://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table2.aspxhttp://prod.ocio.nih.gov/InfoSecurity/public/acquisition/Pages/table2.aspx


38/46

Page 38of 46

level of investigation required for each staff member. An electronic template, "Roster of

Employees Requiring Suitability Investigations," is available for contractor use athttps://ocio.nih.gov/InfoSecurity/public/acquisition/Documents/SuitabilityRoster_10-15-

12.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 employeeneeding a suitability investigation will be contacted via email by the NIH Office of PersonnelSecurity 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.

**** (INCLUDE THE FOLLOWING IN ACQUISITIONS AND SOLICITATIONS WHENPRESCRIPTIONS 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 AwarenessTraining course athttp://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. TheContractor 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 onRole-Based Training Requirement

For additional information see the following:

http://prod.ocio.nih.gov/InfoSecurity/training/MandatoryInfoSecTraining/Pages/RoleBasedTr
https://ocio.nih.gov/InfoSecurity/public/acquisition/Documents/SuitabilityRoster_10-15-12.xlsxhttps://ocio.nih.gov/InfoSecurity/public/acquisition/Documents/SuitabilityRoster_10-15-12.xlsxhttps://ocio.nih.gov/InfoSecurity/public/acquisition/Documents/SuitabilityRoster_10-15-12.xlsxhttp://idbadge.nih.gov/background/index.asphttp://idbadge.nih.gov/background/index.asphttp://irtsectraining.nih.gov/http://irtsectraining.nih.gov/http://irtsectraining.nih.gov/http://intranet.hhs.gov/infosec/docs/policies_guides/RBT/Definition_of_SSR_Security_RBT_Implementation_FINAL_(3).htmlhttp://intranet.hhs.gov/infosec/docs/policies_guides/RBT/Definition_of_SSR_Security_RBT_Implementation_FINAL_(3).htmlhttp://intranet.hhs.gov/infosec/docs/policies_guides/RBT/Definition_of_SSR_Security_RBT_Implementation_FINAL_(3).htmlhttp://intranet.hhs.gov/infosec/docs/policies_guides/RBT/Definition_of_SSR_Security_RBT_Implementation_FINAL_(3).htmlhttp://prod.ocio.nih.gov/InfoSecurity/training/MandatoryInfoSecTraining/Pages/RoleBasedTraining.aspxhttp://prod.ocio.nih.gov/InfoSecurity/training/MandatoryInfoSecTraining/Pages/RoleBasedTraining.aspxhttp://intranet.hhs.gov/infosec/docs/policies_guides/RBT/Definition_of_SSR_Security_RBT_Implementation_FINAL_(3).htmlhttp://intranet.hhs.gov/infosec/docs/policies_guides/RBT/Definition_of_SSR_Security_RBT_Implementation_FINAL_(3).htmlhttp://irtsectraining.nih.gov/http://idbadge.nih.gov/background/index.asphttps://ocio.nih.gov/InfoSecurity/public/acquisition/Documents/SuitabilityRoster_10-15-12.xlsxhttps://ocio.nih.gov/InfoSecurity/public/acquisition/Documents/SuitabilityRoster_10-15-12.xlsx


39/46

Page 39of 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, complywith the NIH Information Technology General Rules of Behavior, which are available at

http://prod.ocio.nih.gov/InfoSecurity/training/Pages/nihitrob.aspx.

**** (INCLUDE THE FOLLOWING IN ACQUISITIONS AND SOLICITATIONS WHENPRESCRIPTIONS 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 daysbefore a new employee assumes a position that requires a

suitability determination or when an employee with a suitability determination orsecurity 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 contractand 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 madeavailable 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
http://prod.ocio.nih.gov/InfoSecurity/training/MandatoryInfoSecTraining/Pages/RoleBasedTraining.aspxhttp://prod.ocio.nih.gov/InfoSecurity/training/MandatoryInfoSecTraining/Pages/RoleBasedTraining.aspxhttp://prod.ocio.nih.gov/InfoSecurity/training/Pages/nihitrob.aspxhttp://prod.ocio.nih.gov/InfoSecurity/training/Pages/nihitrob.aspxhttp://prod.ocio.nih.gov/InfoSecurity/training/Pages/nihitrob.aspxhttp://prod.ocio.nih.gov/InfoSecurity/training/MandatoryInfoSecTraining/Pages/RoleBasedTraining.aspx


40/46


41/46

Page 41of 46

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-

errata_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-rev3-Annex1_updated_may-01-2010.pdf

Annex 2:Baseline Security Controls for Moderate-Impact Information Systemshttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex2_updated_may-01-2010.pdf

Annex 3:Baseline Security Controls for High-Impact Information Systemshttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-

Annex3_updated_may-01-2010.pdf

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

**** (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 NIHIncident Response Team via email ([email protected])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.)

****
http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex1_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex1_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex1_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex2_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex2_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex2_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex3_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex3_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex3_updated_may-01-2010.pdfmailto:[email protected]:[email protected]:[email protected]://ocio.nih.gov/docs/public/PII_Spillage_Report.dochttp://ocio.nih.gov/docs/public/PII_Spillage_Report.dochttp://ocio.nih.gov/docs/public/PII_Spillage_Report.dochttp://ocio.nih.gov/docs/public/Lost_or_Stolen.dochttp://ocio.nih.gov/docs/public/Lost_or_Stolen.dochttp://ocio.nih.gov/docs/public/Lost_or_Stolen.dochttp://ocio.nih.gov/docs/public/Lost_or_Stolen.dochttp://ocio.nih.gov/docs/public/PII_Spillage_Report.docmailto:[email protected]://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex3_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex3_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex2_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex2_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex1_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/800-53-rev3-Annex1_updated_may-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdfhttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf


42/46

Page 42of 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 willbe 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 othercryptographic 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 tohttp://csrc.nist.gov/cryptval.

2. The Contractor shall secure all mobile devices, including non-HHS laptops and

portable media that contain sensitive HHS information byusing a FIPS 140-2compliant 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 ofencryption 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 shallprovide 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 InformationTechnology for assistance

(http://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media

+Sanitization+Service).

**** (INCLUDE THE FOLLOWING IN ACQUISITIONS AND SOLICITATIONS WHENPRESCRIPTION 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
http://csrc.nist.gov/cryptvalhttp://csrc.nist.gov/cryptvalhttp://csrc.nist.gov/cryptvalhttp://csrc.nist.gov/drivers/documents/ombencryption-guidance.pdfhttp://csrc.nist.gov/drivers/documents/ombencryption-guidance.pdfhttp://intranet.hhs.gov/infosec/docs/guidance/hhs_standard_2007.pdfhttp://intranet.hhs.gov/infosec/docs/guidance/hhs_standard_2007.pdfhttp://intranet.hhs.gov/infosec/docs/guidance/hhs_standard_2007.pdfhttp://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media+Sanitization+Servicehttp://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media+Sanitization+Servicehttp://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media+Sanitization+Servicehttp://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media+Sanitization+Servicehttp://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media+Sanitization+Servicehttp://cit.nih.gov/ProductsAndServices/ServiceCatalog/Services.htm?Service=Media+Sanitization+Servicehttp://intranet.hhs.gov/infosec/docs/guidance/hhs_standard_2007.pdfhttp://csrc.nist.gov/drivers/documents/ombencryption-guidance.pdfhttp://csrc.nist.gov/cryptval


43/46

Page 43of 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-01-

05): 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 Contractorshall conduct periodic and special vulnerability scans, and install software/hardware patches

and upgrades to protect automated federal information assets. The minimum requirementshall be to protect against vulnerabilities identified on the SANS Top-20 Internet Security

Attack Targetslist (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 10calendar 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 FEDERALINFORMATION 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 toaccess 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.) ****
http://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdfhttp://www.hhs.gov/oamp/policies/personnel_security_suitability_handbook.htmlhttp://www.hhs.gov/oamp/policies/personnel_security_suitability_handbook.htmlhttp://www.sans.org/top20/?ref=3706#w1http://www.sans.org/top20/?ref=3706#w1http://www.sans.org/top20/?ref=3706#w1http://www.sans.org/top20/?ref=3706#w1http://www.hhs.gov/oamp/policies/personnel_security_suitability_handbook.htmlhttp://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdf


44/46

Page 44of 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 fromhttp://checklists.nist.gov,as jointly identified by theOperating 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,PersonalIdentity 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.) ****
http://nvd.nist.gov/fdcc/download_fdcc.cfmhttp://nvd.nist.gov/fdcc/download_fdcc.cfmhttp://nvd.nist.gov/fdcc/download_fdcc.cfmhttp://checklists.nist.gov/http://checklists.nist.gov/http://checklists.nist.gov/http://nvd.nist.gov/fdcc/index.cfmhttp://nvd.nist.gov/fdcc/index.cfmhttp://nvd.nist.gov/fdcc/index.cfmhttp://ocio.nih.gov/docs/public/references_information_security.htmlhttp://ocio.nih.gov/docs/public/references_information_security.htmlhttp://ocio.nih.gov/docs/public/references_information_security.htmlhttp://ocio.nih.gov/docs/public/references_information_security.htmlhttp://ocio.nih.gov/docs/public/references_information_security.htmlhttp://nvd.nist.gov/fdcc/index.cfmhttp://checklists.nist.gov/http://nvd.nist.gov/fdcc/download_fdcc.cfm


45/46

Page 45of 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 IDENTIFIABLEINFORMATION (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. Verify the information categorization to ensure the identification of the PII

requiring protection.

2. Verify the existing risk assessment.

3. Identify the Contractors existing internal corporate policy that addresses theinformation protection requirements of the SOW.

4. Verify the adequacy of the Contractors existing internal corporate policy thataddresses the information protection requirements of the SOW.

5. Identify any revisions, or development, of an internal corporate policy to

adequately address the information protection requirements of the SOW.

6. For PII to be physically transported to or stored at a remote site, verify that thesecurity 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-rev3-
http://ocio.nih.gov/docs/public/references_physical_access_security.htmlhttp://ocio.nih.gov/docs/public/references_physical_access_security.htmlhttp://www.whitehouse.gov/omb/memoranda/fy2006/m-06-15.pdfhttp://www.whitehouse.gov/omb/memoranda/fy2006/m-06-15.pdfhttp://www.whitehouse.gov/OMB/memoranda/fy2006/m06-16.pdfhttp://www.whitehouse.gov/OMB/memoranda/fy2006/m06-16.pdfhttp://www.whitehouse.gov/omb/me