75N95020R00005_NCATS_Scientific_Environment.pdf

Combined Synopsis/Solicitation 75N95020R00005

COMBINED SYNOPSIS / SOLICITATION FOR COMMERCIAL ITEMS

NONCOMPETITIVE

Title: NCATS Secure Scientific Platforms Environment

(i) This is a combined synopsis/solicitation for commercial items prepared in accordance with the format in Subpart 12.6 as supplemented with additional information included in this notice.

This announcement constitutes the only solicitation; proposals are being requested and a written solicitation will not be issued.

(ii) The solicitation number is 75N95020R00005 and the solicitation is issued as a request for proposals.

This acquisition is for a commercial item or service and is conducted under the authority of FAR Part 12—Acquisition of Commercial Items, and is expected to exceed the simplified acquisition threshold.

THIS IS A NON-COMPETITIVE (NOTICE OF INTENT) COMBINED SYNOPSIS/ SOLICITATION TO

AWARD A CONTRACT WITHOUT PROVIDING FOR FULL OR OPEN COMPETITION.

The National Institutes of Health (NIH) intends to award a contract without providing for full and open competition to Palantir Technologies, Inc., 100 Hamilton Ave., Suite 300, Palo Alto, CA 94301.

This acquisition is conducted as non-competitive for a commercial item. The determination by the Government to award a contract without providing for full and open competition is based upon the market research conducted that produced no other sources capable of providing this Government requirement. However, all responsible sources may submit a bid, proposal, or quotation which shall be considered by the agency.

(iii) The solicitation document and incorporated provisions and clauses are those in effect through Federal Acquisition Circular 2020-07 dated 8/31/2020.

(iv) The associated NAICS code 511210 and the small business size standard is $41.5 million.

DESCRIPTION

(v) The National Center for Advancing Translational Sciences (NCATS), NIH requires a specialized cloud-based data aggregation and analytics enclave that can integrate, manage, secure, and analyze any kind of scientific data, and provide secure, controlled access to internal and external collaborators.

See attached Statement of Work and Detailed Technical Specifications for a full description of project requirements.

(vi) The Government plans to award a single Indefinite Delivery/Indefinite Quantity (IDIQ) contract that uses firm-fixed price task orders. The contract will include a one-year ordering period with a minimum of $960,000 and a maximum total contract value of $36,000,000. The first FOUR task orders will be issued concurrently with the IDIQ award, and Task Order Request for Proposals (TORFP) No. 1-4 are attached.

(vii) The anticipated award date is September 25, 2020.

INSTRUCTIONS, EVALUATION AND AWARD

(viii) The provision at FAR clause 52.212-1, Instructions to Offerors – Commercial Items, applies to this acquisition, and is incorporated by reference. Offerors must submit a technical proposal addressing the requirements listed in the attached Statement of Work, a task order proposal for each of the attached TORFPs No. 1-4, and a business proposal that includes, at a minimum, price and past performance information.

The business proposal shall include a price list consisting of fixed-price line items that can be applied to any order. This price list will form the basis for pricing invidual task orders, but individual orders may be discounted or priced as a lump-sum to accommodate a set volume of licenses, volume of data, processing load, quantity of seats, or other cost elements.

(ix) FAR 52.212-2, Evaluation – Commercial Items.

EVALUATION-COMMERCIAL ITEMS (OCT 2014)

(a) The Government will award a contract resulting from this solicitation to the responsible offeror whose offer conforming to the solicitation will be most advantageous to the Government, price and other factors considered. The following factors shall be used to evaluate offers: (i) Technical capability of the time offered to meet the Government requirement; (ii) past performance; (iii) price. Technical and past performance, when combined, are significantly more important than price.

(b) Options. The Government will evaluate offers for award purposes by adding the total price for all options to the total price for the basic requirement. The Government may determine that an offer is unacceptable if the option prices are significantly unbalanced. Evaluation of options shall not obligate the Government to exercise the option(s).

(c) A written notice of award or acceptance of an offer, mailed or otherwise furnished to the successful offeror within the time for acceptance specified in the offer, shall result in a binding contract without further action by either party. Before the offer’s specified expiration time, the Government may accept an offer (or part of an offer), whether or not there are negotiations after its receipt, unless a written notice of withdrawal is received before award.

(End of clause)

(x) Offerors are to include a completed copy of the provision at FAR clause 52.212-3, Offeror

Representations and Certifications—Commercial Items, with their business proposal.

PROVISIONS AND CLAUSES

(xi) FAR clause at 52.212-4, Contract Terms and Conditions – Commercial Items, applies to this acquisition. An addendum to this clause incorporating additional clauses by reference and in full text applies to this acquisition and is attached.

(xii) FAR clause at 52.212-5, Contract Terms and Conditions Required to Implement Statutes or

Executive Orders–Commercial Items, applies to this acquisition and is attached.

(xiii) There are no additional contract requirement(s) or terms and conditions applicable to this acquisition.

(xiv) Individual task orders under this requirement may be subject to priorities, allocations, and allotments. "Priorities, allocations, and allotments” are procedures used to prioritize national defense-related contracts and orders throughout the U.S. supply chain under the Federal Priorities and Allocations System. See, e.g., the Health Resources Priorities and Allocations System, 45 CFR Part 101. Task Order No. 3, Support for the National COVID Cohort Collaborative, may be subject to priorities and allocations, and will include the following language required by HHS Acquisition Alert no. 2020-10, “HHS reserves the right to exercise priorities and allocations authority with respect to this contract, to include rating this order in accordance with 45 CFR Part 101, Subpart A—Health Resources Priorities and Allocations System.”

VENDOR AND SUBMISSION REQUIREMENTS

(xiv) Offerors must have an active registration in the System for Award Management (SAM) www.sam.gov.

(xv) Responses to this solicitation must include sufficient information to establish the interested parties’ bona-fide capabilities of performing the required service. Responses must also include the Dun & Bradstreet Number (DUNS), the Taxpayer Identification Number (TIN), and the certification of business size.

(xvi) All responses must be received by 11:00 a.m. Eastern time on September 24, 2020, and reference number 75N95020R00005. Responses must be submitted electronically to Stuart http://www.sam.gov/

Kern, Contract Specialist, stuart.kern@nih.gov, tel. 301-402-3334.

ATTACHMENTS

1. Statement of Work, NCATS Collaborative Scientific Platform Pilot Continuation

2. Detailed Technical Specifications

3. 52.212-4 Addendum, additional clauses incorporated by reference or provided in full text.

4. FAR 52.212-5 Contract Terms and Conditions Required to Implement Statutes or Executive

Orders – Commercial Items (Oct 2019)

5. NIH Invoice and Payment Provisions (2/2014), including interim instructions for submitting invoices by email.

6. 52.204-24, Representation Regarding Certain Telecommunications and Video Surveillance

Services or Equipment (Aug 2020)

7. TORFP No. 1, Support for NCATS Integrated Data Analytical Platform (NIDAP), NCATS Instance

8. TORFP No. 2, Support for NCATS Integrated Data Analytical Platform (NIDAP), NCI Instance

9. TORFP No. 3, Support for the N3C Data Enclave

10. TORFP No. 4, Support for the PEPFAR Data Innovation Project mailto:stuart.kern@nih.gov

Statement of Work NCATS Secure Scientific Platforms Environment

Solicitation No. 75N95020R00005

1. Background and Objective

The NCATS Secure Scientific Platform Environment (the “Environment”) is a specialized cloud-based data aggregation and analytics enclave sponsored by the National Center for Advancing Translational Sciences (NCATS) that can integrate, manage, secure, and analyze any kind of scientific data, and provide secure, controlled access to internal and external collaborators.

Within the Environment, multiple institutes and centers (ICs) of the National Institutes of Health (NIH), Federal agencies, and Federal task forces integrate, manage, secure, and analyze all types of scientific data using dedicated platforms, and, equally importantly, make that data available in specific and controlled collaborations with each other and with external collaborators such as research hospitals, academic institutions, and industry stakeholders. The Environment is established through an indefinite delivery, indefinite quantity contract, with task orders issued to support the requirements of individual groups.

2. Requirements

2.1. Independently and not as an agent of the Government, the Contractor shall furnish all the necessary services, qualified personnel, material, equipment, and facilities, not otherwise provided by the Government, as needed to perform the following.

2.2. In accordance with the software requirements described below and in accordance with the Detailed Technical Specifications included herein, the Contractor shall provide the following:

a. Access to the base NCATS Secure Scientific Platforms Environment using a term license approach, with fixed-price pricing defined per task order;

b. Server core-based licensing to be utilized for specific project-based requirements under individual task orders;

c. Additional per-user licensing for access to the base platform;

d. Access to professional services as needed to support these requirements;

e. Cloud hosting infrastructure and/or hardware to support the above installation.

2.3. User access:

a. User access shall include:

• Installation;

• Implementation;

• System configuration;

• Mutually agreed-upon training; and

Statement of Work 75N95020R00005

• Operations and maintenance.

b. User access does not include:

• A configuration for raw image management and processing;

• Other direct costs; and

• User-specific configurations unless mutually agreed-upon.

2.4. Software Requirements

The contractor shall provide its commercial software for enterprise data integration and management to meet the following requirements:

a. A commercial software solution deployable on day one of the project and that can be configured within expedited timelines. Respondents must possess FedRAMP authorization so that an agency ATO (authority to operate) can be granted upon award of a contract.

b. An open data architecture, where data always remains under the full control of NCATS and can be easily exported in open, non-proprietary data formats via open application programming interfaces (APIs). The software should be built on an open, distributed microservices architecture with open, well-documented REST APIs that are designed to seamlessly interface with other systems, adapt to meet evolving needs, and avoid system lock-in.

c. Proven data integration capabilities, including the ability to rapidly ingest unprocessed high-throughput drug screening (HTS) outputs, genomic data (including DNA sequencing, RNA-Seq, miRNA, etc.), mass spectrometry, flow cytometry, imaging, electronic health records (EHR), synthetic and other data types used in basic and translational biosciences research.

d. Proven tool integration capabilities, including the ability to deploy open source packages and code written in python, R, SQL, Spark, Java, and others. This should include the ability to automatically link code and packages to repositories such as GitHub.

e. The ability to maintain data and scientific provenance and reproducibility of all integrated data sources where every resource (dataset, analysis, code, plot, report) contains provenance, metadata, and can be both traced back to the exact version of all upstream dependencies, and where the dependency tree can be easily replayed given new data or updated analysis logic, while still retaining prior versions and branches.

f. Dynamic data model, object-based search/discoverability and analysis workflows, allowing easy definition of objects, properties, and links that propagate from a source table, and provide natural ways to move between tabular and object-oriented interfaces and data analyses.

g. Intuitive, highly configurable user interfaces that have been effectively utilized by technical bioinformaticians, cheminformaticians, and data scientists, as well as less technical

Statement of Work 75N95020R00005 biologists, chemists, and other scientists.

h. Ability to perform advanced analytics and informatics in a user's preferred coding language, as well as in non-code-based point and click tools, all within the same environment.

i. Collaboration capabilities enabling teams comprising of a range of technical and less technical roles to work seamlessly and concurrently on the same data, build on insights, merge similar analytical paths, and track progress in one place.

j. Ability to scale flexibly with increasing users, data, and pipeline complexity, while providing fine-grained ways to adjust resource consumption. Proven ability to scale up to thousands of users (including thousands of potential outside collaborators globally), petabytes of raw and processed data, daily updates in the terabytes, and complex bioinformatic pipelines requiring processing components developed in a variety of languages and environments.

k. Proven granular, security controls with the ability for data owners to easily control all downstream uses of the originating data, and the ability to conform to NCATS security policies.

l. Proven interoperability with NCATS current IT investment landscape and includes omnipresent APIs and plugin points that allow the system to keep up with the changing needs of NCATS, and support both third-party software and other analytic applications. NCATS also requires the ability to independently develop new configurations, plugins, integrations, and extensions to meet new and unforeseen needs and interface with external systems.

m. Adherence to Detailed Technical Specifications: the solution shall incorporate the specifications listed in the Detailed Technical Specifications document, attached to this SOW.

3. Attachments

Attachment 1, Detailed Technical Specifications

Detailed Technical Specifications 75N95020R00005

Detailed Technical Specifications NCATS Secure Scientific Platforms Environment

National Center for Advancing Translational Sciences

(NCATS)

National Institutes of Health

9/2/2020

Table of Contents

Technical Solution Requirements

1. Solution Architecture, Data Integration, and Data Management

1.1 Unified, Commercial Software Data Management Architecture

1.3 Flexible Data Integration Engine & Bioscience Data Experience

1.4 Data Storage, Access, and Catalog

1.5 Full Data Provenance and Schema

1.6 Data Transformation Management

1.7 Data deposition back to established repositories

1.8 Cohesive User Interfaces for Data Management

2. Data Analysis, Discovery, and Bioscience Workflows

2.1 Analytic Tool Suite

2.2 Search and Exploration

2.3 Web Application Builder

3. Security and Administration

3.1 Security and Access Controls

3.2 Platform Management and Administration

3.3 End – nothing follows

Technical Solution Requirements

1. Solution Architecture, Data Integration, and Data Management

1.1 Unified, Commercial Software Data Management Architecture

1. A core architecture that consists of a suite of distributed microservices that perform fundamental tasks that the rest of the platform, external plugins and integrations depend on.

2. Where a dataset should operate as a high-level conceptual container that manages the full versioned history of a data file (or files) including its history of changes, branches, and access policies.

3. Where each dataset maintains a series of transactions, which are the records of the varying logic which has modified the underlying data files over time, with pointers to the specific versions or views of those data files that are physically stored in a distributed file system.

4. Where a dataset may contain branches that allow transactions to modify data files in a sandboxed fashion.

5. Provide the ability for development and analysis on different versions or subsets of a dataset to occur simultaneously without conflicting.

1.2 Scalability and Hosting

1. A solution that can be offered in the cloud as software as a service, or as an on-premises installation. The preferred deployment method is in the cloud.

2. The solution's cloud architecture should provide:

a. Separated cloud, customer, and management networks

b. Isolated virtual private clouds (VPCs) that prevent commingling of data

c. Hardened and filtered entry and egress points between cloud, customer, and management networks

d. Sophisticated provisioning, patching, and monitoring tooling

e. 24/7/365 support and incident response team

f. Automated backups and robust disaster recovery

g. Events logging and log aggregation from services across hosts

h. Interface providing access to consolidated logs and performance metrics allowing standardized monitoring and tuning of services

3. By design, all components of the solution should be horizontally scalable, allowing additional user scale, data scale, data complexity, and compute complexity.

4. All core services should operate in a high-availability clustered environment using commodity hardware or cloud node hosting on Linux platform

5. All data should be stored in one of several highly available and redundant distributed data stores

6. All compute is scheduled and run on open-source cluster-computing frameworks and schedulers, with wrapper libraries and appropriate APIs to allow any plugin or integrated application to run on the same infrastructure

7. The government reserves the right to select/determine the cloud provider of our choice

1.3 Flexible Data Integration Engine & Bioscience Data Experience

1. Data ingestion, integration, transformation, and orchestration tools that include:

a. Data Ingestion

1. Support for programmatic (automated and either push/pull) ingestions and ad-hoc ingestions (user-initiated, either via user-interface, or backend script)

2. Support for a broad range of source systems, including, but not limited to HDFS, S3, local file systems, RDBMs, streaming systems, JDBC-enabled systems, etc.

3. Provide an API for writing new ingestion adaptors from novel or custom data systems

4. Ability to install a daemon in a source system environment entirely within the control of the data owner. This daemon should let the system owner manage credentials, connection details, and files.

5. A central coordinator service that manages the configuration and execution of ingestion jobs through communication with the agent. The coordinator compiles all job specifications and provides them to the agent, which then performs the system-side aspects of the ingestion task.

6. High resilience to provide robustness in the face of common failure modes during ingestion – poor network connectivity, disk failures, time outs, and more. Users can choose to configure whether to triage failures in an automated way, or force manual intervention via alerts.

7. A user interface where syncs and jobs can be monitored and configured, and open-ended queries can be performed to test ingestions.

Configurations should include the nature of the source system, the relevant destination dataset in the solution, the path that the data should take in transit, and any in-flight modifications to the data.

b. Data Transformations

1. Pluggable modules to let users write data transformation code in the language of their choice (Java, Python, R, SQL, etc.).

2. Templating tools allow users to catalog and parameterize commonly used code

3. Integrated version control and branching ensure that individuals across an organization can collaborate on logic development without disrupting existing production workflows

4. Deep branching enables code and underlying data to be experimented with in parallel. Data not requiring any changes while experimenting can be configured to default using a “fall-back” branch to avoid unnecessary data duplication.

5. Unique branching of the data itself means that logic branches with disparate transformation approaches can co-exist

6. Incremental or snapshot transactions available to support regular syncing with a diverse set of source data systems

7. Web-based integrated development environment (IDE) allowing the writing of data transformation code

8. Compilation module that is able to transform the code into distributed compute operations on the distributed execution environment

9. Continuous integration backend allowing each change to be committed to a distributed version control system, and versioned artifact to be produced

10. A distributed environment execution manager that provides simplified access to the distributed cluster, and fully manages necessary dependencies, libraries, and conflicts

c. Data Orchestration

1. Ability to add data health checks (including, but not limited to: null checks, distribution as expected, no duplicates, reasonably partitioned for optimal performance, foreign-key relationships)

2. Ability to add triggers, to run certain data operations upon receiving an alert from a message queue

3. Open APIs that enable outside services to trigger actions and updates within platform

4. Advanced queuing and resource channels allow for intelligent sharing of resources among simultaneous transformations and prioritization of critical jobs

5. User interface for context on running jobs and rich metrics on the performance of historical transformation activity to inform scheduling and refactoring

2. Ability to ingest bioscience data type:

a. The solution must be designed to integrate any type of data out-of-the-box.

Additionally, the solution must be preconfigured with specialized tooling to work with the following types of data:

1. High-throughput drug screening (HTS), including raw plate reader output

2. Mass spectrometry (MaxQuant, PD, Peaks, etc.)

3. Expression data (RNA-Seq, DNAse-Seq, miRNA, etc.)

4. DNA sequencing

5. Flow Cytometry

1.4 Data Storage, Access, and Catalog

1. Distributed data storage via preferably S3 or Cassandra that provides unique IDs and a REST API, and integrates with the core security and auditing control subsystem.

2. Key-value storage that provides:

a. Seamless integration with the security and auditing subsystem so that all resources stored are security-aware throughout their lifecycle.

b. REST API with bucket/path-based addressing system, allowing applications to easily register, store, and retrieve resources throughout their lifecycle.

c. Reliable via highly available and scalable architecture

3. Indexing that:

a. Provides a search mechanism as well as a generalized high-scale index layer for the solution and its ecosystem.

b. Is security-aware and is closely tied to the core security and auditing subsystem so that search requests – regardless of origin – can be securely managed.

c. Makes tasks such as live re-indexing and security accessible.

d. By default, will perform search optimizations, such as pre-filtering for paged searches that provide sparse results.

e. Can work with the solution's core build service to implement a distributed indexing worker that allows for systematic indexing of jobs as they build and promote new resources.

4. A data access API that provides a simplified interface for user ‘PUT’ and ‘GET’ requests for data by managing the underlying File System requests among the solution services in a particular installation.

a. The Data Access API is required to interface with the underlying distributed file store that is being used as part of the solution installation to return the actual resource byte array when requested.

5. A Data Catalog that provides:

a. Highly available metadata store that keeps track of datasets, as well as being able to handle datasets composed of multiple data files, and the associated transactions to maintain ACID properties on datasets.

b. Virtual access to a complete dataset that may be composed of many underlying files via many transactions.

c. Reconstruction of the full dataset via negotiation of transactions, whether they be a point-in-time exact view of the data, an append or to an existing dataset, or a deletion from a dataset.

d. A locking mechanism for managing concurrent access to the same dataset, via vector clock and operational transforms (OT).

e. API access to metadata, complete constructed datasets, or files and transactions therein.

1.5 Full Data Provenance and Schema

1. Data in the solution should be inherently schema-less, with additional schema and provenance information provided by dedicated services.

2. A schema management service that:

a. Stores and provides the schema definition for each data file, including variations in the schema that may have occurred across the versioned and branched history of the resource

b. Stores type information that is used in the compute environment. The types can be inferred with an advanced type inference engine; the service should also have a graphical interface for the user to validate, correct, or modify the types manually.

c. Tags and “typeclasses” on tables and columns, allowing semantic meaning to be conveyed and propagated. As an example, a column marked “chemical-compound” will result in all downstream datasets using that column knowing that they also contain a column containing a “chemical-compound,” which can then be associated with specific actions.

3. Ability to generate interactive graphical visualizations of the live updating data dependency and provenance tree for all datasets in the solution (while respecting access controls) and provides for any dataset:

a. The ability for users to inspect the transformations that led to it.

b. All upstream and downstream datasets to be viewed as well.

c. The pipeline graph to be manipulated by users including labeled in various ways.

1.6 Data Transformation Management

1. A data transformation management service that provides:

a. A resilient topological graph of dataset dependencies, using metadata captured in the Data Catalog, Provenance, and Schema information, consisting of virtual build nodes with job specifications (via a worker process) on how to update a given dataset and dependents.

b. A way to dynamically compute staleness of datasets, in order to determine what needs to be run.

c. Advanced topological sorting of datasets to determine the optimal order of job runs, and to allow parallelization of job runs.

d. Modular dispatch in order to dynamically bind and dispatch a worker and an associated executor environment appropriate for the task. This would allow a multi-step build to be run cohesively in a variety of languages in the same run.

e. A way to perform efficient selective insert or replacement of data at the row level, pursuant to access controls.

1.7 Data deposition back to established repositories

1. A data transformation management service that provides:

a. A mechanism to intermittently synchronize select data with external relational database management systems (RDMS).

b. A mechanism to intermittently synchronize select data with external services through application programming interfaces (API).

c. Support for the persistence of complex object models through RDMS and API.

d. Robust transactional framework to ensure the integrity of the data transfer process.

e. Data management process to track staleness and synchronization of datasets, in order to determine what data needs to be deposited.

1.8 Cohesive User Interfaces for Data Management

1. The solution provides intuitive access to virtually all services through any modern web browser, and includes:

a. A unified web environment sharing an application frame and common design language

b. Ability to register actions and pluggable capabilities via API plugin points. As an example, a developer can add to the context menu for a dataset in order to analyze it using that custom application.

c. Granular permissioning of actions via integrated access control

d. Interface components that facilitate easy use by both technical and non-technical analysts alike.

2. The solution should focus on the ability for technical users (bioinformaticians, cheminformaticians, data engineers) to be able to collaborate on the same data management and analytic infrastructure as non-technical users (biologists, chemists, analysts), and should provide:

a. The ability to comment on any resource (dataset, analysis, dashboard, compute node, etc.) in a collaborative chat environment, including the ability to tag and notify.

b. A fully integrated data issues interface where users can file, discuss, and resolve data quality issues in an interface that can embed flagged datasets, columns, and more.

c. Ability to selectively share any analysis, dashboard, or workflow across the platform and choose what permission level to grant (viewer, editor).

d. Shared source of truth with robust change tracking for inventories, protocols, and other data that would otherwise be shared across teams manually by email or spreadsheet.

e. Allows analyses and artifacts of analyses to be discoverable and reused across other applications on the platform.

f. Ability in the UI to easily create templates and/or macros that allow a non-technical user to apply complex analysis workflows and code paths.

2. Data Analysis, Discovery, and Bioscience Workflows

2.1 Analytic Tool Suite

1. A solution that enables individuals across NCATS to work with the same data by providing a suite of analytical tools appropriate for the full range of technical ability. The suite should provide the following functionality:

a. Reporting

1. Ability to unify live views of charts, visualizations and datasets from various solution services in a single location.

2. Allow users to write collaborative documents, include more context by attaching images or rich text descriptions, and create long-lived, real-time dashboards of key metrics.

3. Ability for reports to link to live data backing those reports, allowing users to inspect the live provenance of the data in the user interface, as well as all data backing the report.

b. Top Down Analysis at Scale

1. An intuitive and visual path-based, point-and-click environment for tabular manipulation and enrichment.

2. Flexible widgets that allow users to apply a broad range of filters, manipulations, expressions, enrichments, joins, and visualizations (including heatmaps, distributions, histograms, bar charts, scatterplots, regressions, PCA, Venn diagrams, time series, dendrograms, and more).

3. A path-based model that allows for previous steps to be modified and all subsequent steps to be rebuilt based on those new parameters.

4. The ability for paths to be cloned, branched, and saved as their own objects.

5. The ability for iterative steps to be saved automatically while allowing users to undo actions and return to a previous state of the analysis.

6. Have a documented API, allowing developers to add boards as external plugins without requiring downtime.

c. Code Workbooks

1. A visual directed acyclic graph, where each node is a raw dataset, a dataset resulting from a code manipulation depending on any of a number of upstream datasets, or a visual plot.

2. The code should be able to be written in Python, R, SQL or other common languages, and have direct API bindings to the underlying distributed compute infrastructure (e.g. Spark).

3. Resulting data from code workbook computation nodes should:

1. Automatically become part of the solution's data environment,

2. Be registered in the data catalog, and

3. Immediately available for access in all other applications.

d. Modular Code Templates

1. Ability to save common code segments or paths as templates or macros, thereby very quickly enabling any user to express complex analytical ideas with point-and-click tooling.

2. The solution should support for multi-tenant usage of Code Workbooks and Top Down Analysis, including supporting of full branching log, whereby a user can apply their analytical methods on a branch (with code and relevant datasets all respecting the branching mechanism), and later propose a merge back to the master branch.

3. Resulting data from path-based analyses automatically become part of the solution data environment and immediately available for access in all other applications.

4. Ability to selectively share and collaborate throughout the solution's services, including the ability to add comments, tag and notify users and report and track issues on identified data columns.

2.2 Search and Exploration

1. Beyond simply curating datasets in a central data catalog, the solution must also index analysis and reports such that a user can easily discover data and insights about a topic of interest without knowing beforehand where to navigate.

2. Access control settings at the project and individual resource level need to ensure that a user only sees information they are approved to discover.

3. Robust data tagging and project hierarchies need to allow users to then narrow global search results down to the information most relevant to their task at hand.

4. In addition to global search, the solution should provide a variety of exploratory interfaces to understand the data available, the logic applied to it, and the relationships among different pieces of information:

a. An interface that allows all resources within the solution to be inherently linked to the logic applied to transform the raw information into the subsequent ontology tables.

b. An interface that allows search across all raw and transformed datasets so that it is straightforward to search globally by column names to identify where particular information is present

c. An interface (beyond tabular data) to facilitate mapping of information onto conceptual objects with attributes, behavior, and relationships to other objects within the data model.

d. An interface that allows users to quickly author a standalone web application which pulls cached data into an interface optimized for carrying out a particular workflow. This interface should thereby streamline workflows for when certain information is accessed repeatedly in the same manner.

2.3 Web Application Builder

1. Beyond native data exploration, code authoring, and analysis interfaces, the solution should include the following features:

a. A development environment which allows any user to create data-driven interactive applications.

b. Includes a rich “what you see is what you get” environment, allowing the composing of an interface using extensible “widgets,” including charts, controls, containers, text, images, time series, and others.

c. Each widget can be synchronized to live data with straightforward SQL queries, and complex workflows can be built by defining JavaScript functions that determine interaction between widgets and reaction to user triggered events.

d. Is natively compatible with reading from a SQL connection, via REST API, or anything that provides a JSON response, offering the ability to tie in external systems or APIs.

2. As all other solution components, applications built in this web interface should fully respect the propagated dynamic access controls of the data dependencies.

3. Security and Administration

3.1 Security and Access Controls

1. The solution shall have a security and auditing subsystem to enforce security in the solution. The solution must provide authorization of resource access to users who have been authenticated.

2. Security and access controls that include:

a. Multi-source authentication (enterprise LDAP, PKI, Active Directory, etc.) as well as Single Sign-On (SSO) capabilities.

b. Access controls to secure each piece of information individually in addition to traditional blanket permissions across entire data sources.

c. Ability to assign individual users granular permissions to data access (including ownership, read, write, access denied, etc.).

d. Role-based access controls (RBAC) are assignable to individual users or group of users.

e. Allow for conditional policies based upon defined criteria. For example, applications and individual actions (termed “resources”) can each be given a policy, taking the form of statements that express a (Condition, Verb, Operation) tuple, such as “if User X is a member of Group Y (condition) they are Allowed (verb) to Edit (operation) resource Z.”

f. Access and role-based access controls that can be:

1. assigned by administrators and/or

2. inherited from source systems and updated at any time.

3. Role-based access control based on least privilege and privileged access for access administration.

g. Propagation and inheritance of access controls to all data and analyses derived directly or indirectly from the originating data, whether those data transformation or analyses are performed:

1. In a standard coding language (Java, SQL, Scala, Python, etc.)

2. As technical scripting language (R, SAS, etc.), or

3. A point-and-click analytical environment

h. Data is encrypted at rest via compliant mechanisms (e.g., full disk encryption, LUKS, TrueCrypt).

i. Data in transit from client-to-server or server-to-server is end-to-end encrypted (via SSL/TLS).

3. FedRAMP Compliant ATO. Comply with FedRAMP Security Assessment and Authorization (SA&A) requirements and ensure the information system/service under this contract has a valid FedRAMP compliant (approved) authority to operate (ATO) in accordance with Federal Information Processing Standard (FIPS) Publication 199 defined security categorization. If a FedRAMP compliant ATO has not been granted, the Contractor shall submit a plan to obtain a FedRAMP compliant ATO as determined by the contract officer.

3.2 Platform Management and Administration

1. Continuous Integration and Monitoring, including:

a. Live downtime-less upgrades enabled by high availability services.

b. Centralized monitoring of errors and performance.

c. Dynamic scaling of compute and storage to handle changes in usage in a resource efficient manner.

2. Platform Administration and a solution Configuration Manager that allows:

a. Maintaining a complete understanding of the state of the environment always:

1. Including the hosts, the services, the nodes for distributed and High

Availability services

2. Where those nodes are deployed

3. What versions they are on

4. Version compatibilities, etc.

b. Secure management of cryptographic secrets.

c. The concept of ‘roles’, which declare which services and APIs produce and consume in a declarative manner.

d. All services must have a ‘Life Cycle Model’ to indicate the expected or target state at any given time along with the current state (for example, running or upgrading). Service status is a more detailed reporting of the per-host service state that is updated with each agent action.

e. Backend command line interfaces (CLIs) that provide full management functionality.

f. Front-end graphical interface that provide full management functionalities

3. Standardized microservices:

a. Layout in the filesystem is standardized, allowing a platform administrator to easily find service information and logs.

b. Microservices can be deployed via the platform management services directly onto hosts, or, ideally, as lightweight containers using standard container deployment orchestration libraries.

c. The orchestration framework should tightly integrate with the security and auditing subsystem.

d. These containers allow only a limited number of gateways into the host environment, greatly limiting the potential vectors that could compromise one or more hosts.

3.3 End – nothing follows.

Addendum to FAR 52.212-4 Terms and Conditions – Commercial Items

(s) Order of precedence. Any inconsistencies in this solicitation or contract shall be resolved by giving precedence in the following order:

(1) The schedule of supplies/services

(2) The Assignments, Disputes, Payments, Invoice, Other Compliances, Compliance with Laws Unique to Government Contracts, Unauthorized Obligations, and Commercial Supplier Agreements – Unenforceable Clauses paragraphs of this clause.

(3) The clause at 52.212-5.

(4) Addenda to this solicitation or contract, including any commercial supplier agreements as amended by the Commercial Supplier Agreements – Unenforceable Clauses provision.

(5) Solicitation provisions if this is a solicitation.

(6) Other paragraphs of this clause.

(7) The Standard Form 1449.

(8) Other documents, exhibits, and attachments.

(9) The specification.

(w) Commercial supplier agreements–unenforceable clauses.

(1) Definition. For the purpose of this contract, “Commercial supplier agreements” (referred to at FAR 12.216 as “Supplier License Agreements”) means terms and conditions customarily offered to the public by vendors of supplies or services that meet the definition of “commercial item” set forth in FAR 2.101 and intended to create a binding legal obligation on the end user. Commercial supplier agreements are particularly common in information technology acquisitions, including acquisitions of commercial computer software and commercial technical data, but they may apply to any supply or service. The term applies–

(a) Regardless of the format or style of the document. For example, a commercial supplier agreement may be styled as standard terms of sale or lease, Terms of Service (TOS), End User License Agreement (EULA), or another similar legal instrument or agreement, and may be presented as part of a proposal or quotation responding to a solicitation for a contract or order;

(b) Regardless of the media or delivery mechanism used. For example, a commercial supplier agreement may be presented as one or more paper documents or may appear on a computer or other electronic device screen during a purchase, software installation, other product delivery, registration for a service, or another transaction.

(2) When any supply or service acquired under this contract is subject to a commercial supplier agreement, and notwithstanding any other provision of this agreement, when the end user is an agency or instrumentality of the U.S. Government, the following language shall be deemed incorporated into the commercial supplier agreement. As used herein, “this agreement” means the commercial supplier agreement.

(i) Applicability. This agreement is a part of a contract between the commercial supplier and the U.S. Government for the acquisition of the supply or service that necessitates a license or other similar legal instrument (including all contracts, task orders, and delivery orders under FAR Part 12).

(ii) End user. This agreement shall bind the ordering activity as end user but shall not operate to bind a Government employee or person acting on behalf of the Government in his or her personal capacity.

(iii) Law and disputes. This agreement is governed by Federal law.

(A) Any language purporting to subject the U.S. Government to the laws of a U.S. state, U.S. territory, district, or municipality, or a foreign nation, except where Federal law expressly provides for the application of such laws, is hereby deleted.

(B) Any language requiring dispute resolution in a specific forum or venue that is different from that prescribed by applicable Federal law is hereby deleted.

(C) Any language prescribing a different time period for bringing an action than that prescribed by applicable Federal law in relation to a dispute is hereby deleted.

(iv) Continued performance. The supplier or licensor shall not unilaterally revoke, terminate or suspend any rights granted to the Government except as allowed by this contract. If the supplier or licensor believes the ordering activity to be in breach of the agreement, it shall pursue its rights under the Contract Disputes Act or other applicable Federal statute while continuing performance as set forth in subparagraph 52.212-4(d) (Disputes).

(v) Arbitration; equitable or injunctive relief. In the event of a claim or dispute arising under or relating to this agreement, a binding arbitration shall not be used unless specifically authorized by agency guidance, and equitable or injunctive relief, including the award of attorney fees, costs or interest, may be awarded against the U.S. Government only when explicitly provided by statute (e.g., Prompt Payment Act or Equal Access to Justice Act).

(vi) Updating terms.

(A) After award, the contractor may unilaterally revise commercial supplier agreement terms if they are not material. A material change is defined as:

(1) Terms that change Government rights or obligations;

(2) Terms that increase Government prices;

(3) Terms that decrease overall level of service; or

(4) Terms that limit any other Government right addressed elsewhere in this contract.

(B) For revisions that will materially change the terms of the contract, the revised commercial supplier agreement must be incorporated into the contract using a bilateral modification.

(C) Any agreement terms or conditions unilaterally revised subsequent to award that are inconsistent with any material term or provision of this contract shall not be enforceable against the Government, and the Government shall not be deemed to have consented to them.

(vii) No automatic renewals. If any license or service tied to periodic payment is provided under this agreement (e.g., annual software maintenance or annual lease term), such license or service shall not renew automatically upon expiration of its current term without prior express consent by an authorized Government representative.

(viii) Indemnification. Any clause of this agreement requiring the commercial supplier or licensor to defend or indemnify the end user is hereby amended to provide that the U.S.

Department of Justice has the sole right to represent the United States in any such action, in accordance with 28 U.S.C. 516.

(ix) Audits. Any clause of this agreement permitting the commercial supplier or licensor to audit the end user’s compliance with this agreement is hereby amended as follows:

(A) Discrepancies found in an audit may result in a charge by the commercial supplier or licensor to the ordering activity. Any resulting invoice must comply with the proper invoicing requirements specified in the underlying Government contract or order.

(B) This charge, if disputed by the ordering activity, will be resolved in accordance with subparagraph (d) (Disputes); no payment obligation shall arise on the part of the ordering activity until the conclusion of the dispute process.

(C) Any audit requested by the contractor will be performed at the contractor's expense, without reimbursement by the Government.

(x) Taxes or surcharges. Any taxes or surcharges which the commercial supplier or licensor seeks to pass along to the Government as end user will be governed by the terms of the underlying Government contract or order and, in any event, must be submitted to the Contracting Officer for a determination of applicability prior to invoicing unless specifically agreed to otherwise in the Government contract.

(xi) Non-assignment. This agreement may not be assigned, nor may any rights or obligations thereunder be delegated, without the Government's prior approval, except as expressly permitted under subparagraph (b) of this clause.

(xii) Confidential information. If this agreement includes a confidentiality clause, such clause is hereby amended to state that neither the agreement nor the contract price list, as applicable, shall be deemed “confidential information.” Issues regarding release of “unit pricing” will be resolved consistent with the Freedom of Information Act. Notwithstanding anything in this agreement to the contrary, the Government may retain any confidential information as required by law, regulation or its internal document retention procedures for legal, regulatory or compliance purposes; provided, however, that all such retained confidential information will continue to be subject to the confidentiality obligations of this agreement.

(3) If any language, provision, or clause of this agreement conflicts or is inconsistent with the preceding paragraph (2), the language, provisions, or clause of paragraph (2) shall prevail to the extent of such inconsistency.

(End of clause)

(5/1/2019)

Invoice and Payment Provisions (2/2014) The following clause is applicable to all Purchase Orders, Task or Delivery Orders, and Blanket Purchase Agreement (BPA) Calls: Prompt Payment (Jul 2013) FAR 52.232-25. Highlights of this clause and NIH implementation requirements follow:

I Invoice Requirements

A. An invoice is the Contractor's bill or written request for payment under the contract for supplies delivered or services performed. A proper invoice is an "Original" which must include the items listed in subdivisions 1 through 12, below, in addition to the requirements of FAR

32.9. If the invoice does not comply with these requirements, the Contractor will be notified of the defect within 7 days after the date the designated billing office received the invoice (3 days for meat, meat food products, or fish, and 5 days for perishable agricultural commodities, dairy products, edible fats or oils) with a statement of the reasons why it is not a proper invoice. (See exceptions under II., below.) Untimely notification will be taken into account in the computation of any interest penalty owed the Contractor.

1. Vendor/Contractor: Name, Address, Point of Contact for the invoice (Name, title, telephone number, e-mail and mailing address of point of contact).

2. Remit-to address (Name and complete mailing address to send payment).

3. Remittance name must match exactly with name on original order/contract. If the

Remittance name differs from the Legal Business Name, then both names must appear on the invoice.

4. Invoice…