Amendment_0001 _Continuation_Pages.docx

Summary of Changes

Q1. After review of the RFP, L.11.1.2 below stood out as it suggests that a specific known system, or small number of systems is/ are being considered. Please clarify that L.11.1.2 is in fact a requirement or it is left over from a template. If it is a requirement, does this mean that a system built with COTS components that are individually implemented for 3+ years would not be considered?

Q2. As I read the RFP, Section L.11.1.1 (underlined below for your reference) something does not make sense and I am looking for clarification. Given CDC requires this proposed solution must already be implemented for 3 years, I interpret this RFP as an ‘off-the-shelf’ computer software solution. In essence, this seems contradictory. I am simply trying to determine if my company qualifies or not. Our Capabilities Statement is attached to this message. We are already a CDC contractor with an Electronic Health Record that has been utilized for 8 years now; www.SpinaBifidaEHR.com.

Q3. Will CDC revise L.11.1.1 to strike the word “public health,” replacing them with “public sector" and entirely strike the words “outbreak management and response”?

Q4. Will CDC reduce the three (3) year requirement in L.11.1.2 to a one (1) year requirement?

A1, A2, A3, and A4: The proposed solution will be used to support the current Ebola Virus Disease outbreak, so the proposed solution must be comprised of either a singular COTS product or a set of integrated COTS components that have been demonstrated to work together for at least three (3) years in order to be considered. CDC will not revise the wording to strike “public health” and replace with “public sector” nor remove “outbreak management and response”. CDC is specifically looking for real world experience in public health as it pertains to outbreak responses to rapidly respond to ongoing public health events.

Q5. L.11.1.1. Would the Government please name existing solutions that are already implemented in the US public health domain and provide documentation for those configured solutions for both functional and non-functional requirements?

A5. No.

Q6. L.11.1.2. Process and Activities require compliance to CDC Technical Architecture (TA). Would the Government please provide the TA as well as current configurations?

A6. The Technical Architecture will depend on which solution is selected and so cannot be determined by CDC in advance. Please refer to “Attachment 2, Appendix A”, Architecture Requirements NF-A-01 through NF-A-14 for additional information on the architecture required. The DCIPHER platform does not currently exist at CDC so there is no current configuration. See graphics provided in answer A10 for additional information.

Q7. There is not enough information (not sufficient level of detail in the PWS) to scope/price this on an FFP basis - More information on current staffing would be helpful in understanding the current baseline functionality used to maintain current service levels and the associated costs.

A7. DCIPHER is a new CDC project and current baseline functionality used to maintain current service levels and the associated costs are not available. It is up to Offerors to propose staffing levels and associated costs sufficient to support the required functionality.

Q8. There's also a good deal of open-ended system integration and data management support that is going to be difficult to bound, price, and mitigate delivery risk on a FFP engagement.

Please provide the DCIPHER architectural elements surrounding maintainability, scalability, and performance.

A8. Please refer to “Attachment 2, Appendix A”, Architecture Requirements NF-A-01 through NF-A-14, and Performance Requirements NF-P-01 through NF-P-09.

Q9. Has a formal test strategy and plan for requirements been implemented and documented for a Quality Assurance Plan, Integration Test Plan, Acceptance Test Cases, Acceptance Test Scenarios, System Test Cases, or should that be priced in the proposal?

A9. The expectation is that the vendor will deliver a working solution, based on the DCIPHER requirements. CDC will perform user acceptance test cases and acceptance test scenarios to ensure that the solution meets the requirements.

Q10. Please provide the DCIPHER Concept of Operations (ConOps) high-level overview of the envisioned system. The ConOps is based on business requirements and serves as a basis for the functional requirements. It identifies system characteristics and the operational environment to allow us to devise a proper staffing plan consistent with deployment planning and SLA Management in the CDC environment.

A10. See the following two (2) diagrams.

Q11. Does the Government expect full implementation within 90 days into the CDC data center or does the Government anticipate releases that bring new functionality gradually during this transition period? Please explain.

A11. As outlined in section ‘C.3, Schedule of Deliverables and Milestones’ of the RFP, “≥80% of functionality must be operational within 30 days of Kickoff meeting”, and “Final platform review” will be conducted at end of year one (1). The intention is to deploy the platform in the test/development environments during the initial 30-day post-kickoff period. The remainder of the functionality can be released on a schedule to be determined based on discussion between CDC and the awardee to be execute via contract modification.

Q12. Will the budget need to include hardware costs as well since the data is non-public or are you comfortable working with proper security controls and HIPPA-compliant cloud server platforms such as private cloud AWS? I see IAW Section C, Paragraph C.1.4.2.17 - can you specify? It must be hardware?

Per section C.1.4.2.17., Provision and management of dedicated CDC-compatible physical server hardware (i.e., vendor supplies physical servers that will not be shared across another project) to include the following environments: production, staging, test, development, and disaster recovery and software needed to support DCIPHER, including provision of, patches and updates to server software. The hardware for DCIPHER will be installed at CDC, within the CDC ITSO Applications Hosting Branch. Cloud hosting or private hosted platforms are not an option at this time.

Q13. Do hosting budgets have to be specified in relationship to expected performance benchmarks? Higher hosting cost would equal better performance, for example

A13. Hosting plan and associated budgets must be sufficient to meet the performance requirements outlined in “Attachment 2, Appendix A”, Performance Requirements NF-P-01 through NF-P-09.

Q14. How many vendors have confirmed that they will be submitting responses?

A14. CDC does not have this information.

Q15. Do you have a general ballpark in mind for the budget of this project?

A15. Exclusive of the optional items, CDC estimates the overall costs to be between $4 – 6 million. However, inasmuch as non-price factors are more important than price, it is recommended that Offerors provide their best solution for the requirements.

Q16. Is there a given programming language or stack that is preferred?

A16. No.

Q17. Does the CDC have a hosting infrastructure they would like to re-use for this project?

A17. Per section C.1.4.2.17., Provision and management of dedicated CDC-compatible physical server hardware (i.e., vendor supplies physical servers that will not be shared across another project) to include the following environments: production, staging, test, development, and disaster recovery and software needed to support DCIPHER, including provision of, patches and updates to server software.

Q18. What percentage of the process of developing and designing the GUI should be for mobile / smartphones, if at all? What percentage of the admin interface, if at all?

A18. See “Attachment 2, Appendix A”, Architecture Requirement NF-A-02. It is up to Offeror to provide a solution that meets this requirement; there is no percentage designated.

Q19. What format are you we using to input this data into the DCIPHER system? CSV?

A19. File formats can include but are not limited to xls/x, csv, txt, doc/x, pdf, ppt, vsd, html, ascii, unicode, accdb, mdb, mdf, xml, sas, sql, images, time-series, wav, etc.

Q20. Are we able to recommend / use Hadoop and a cloud-hosted version of Hadoop to handle the large data workload?

A20. Currently there are no CDC-approved cloud-hosting options so cloud-hosted Hadoop is not an option. Hadoop itself can be proposed.

Q21. Are you able to provide an example of an initial data set to review? We are curious about the current state of the data and the taxonomy used.

A21. No.

Q22. Can you describe an example of a COTS product used in another CDC project similar to this (referencing C.1.4.1)?

A22. No.

Q23. Does CDC require all software version control systems to be self-hosted?

A23. All data and platform software being developed for CDC must be hosted on physical servers within the CDC infrastructure.

Q24. In the spirit of fair and open competition, will the government consider any solution other than Palantir Disease Response? If no, is there a requirement for the offeror to be an approved Palantir provider?

A24. This solicitation is a full and open competition and any Offeror that meets the Solution Summary Requirements is invited to apply.

Q25. Please indicate the number of expected end users and CDC system administrators.

A25. Performance Measure 13, page 21, is amended to read as follows: “Must provide training to the following staff: Minimum 15 trained end users, Minimum 2 trained superusers, Minimum 2 trained platform administrators.” CDC cannot break down categories of users further than that. As outlined in “Attachment 2, Appendix A”, Performance Requirements NF-P-04 and NF-P-05, a minimum of 100 concurrent users must be able to use the platform in the base year, and it must be able to scale up to a minimum of 300 concurrent users. The total number of users is unknown at this time but is expected to increase over time.

Q26. Solicitation Page 65, L.5. FAR 52.232-28 Invitation to Propose Performance-Based Payments (March 2000): Please clarify where (volume and section) our proposal of performance-based payments should be included in our response.

A26. Please include this information in your Business Proposal.

Q27. Attachments 3, 4, and 5: Are these attachments included for information only? If any are to be completed and submitted with our proposal, please clarify which attachment(s) and in which volume it/they should be included.

A27. Attachments 3,4,5 are informational only.

Q28. Page 68, L.11.1.2: States “The proposed solution as configured in the proposal must be in use for at least three (3) years.” Please clarify if “in use” means previously used by CDC and/or for the same specific purpose, or that it will (future) be used for at least 3 years. If the solution is required to have already been in use for the past 3 years, please explain how this could be accomplished since the current system, with its unique purpose, uses a series of Excel spreadsheets. Will a system built with COTS components that have been individually implemented for at least 3 years be considered?

A28. The proposed solution will be used to support the current Ebola Virus Disease outbreak, so the proposed solution must be comprised of either a singular COTS product or a set of integrated COTS components that have been demonstrated to work together for at least three (3) years in order to be considered. It also must be currently implemented in a US public health jurisdiction, which can be CDC or any other jurisdiction described in L.11.1.1. No, a system built with COTS components that have been individually implemented for 3+ years will not be considered.

Q29. In Section B, please confirm whether the Government anticipates using Modules A & B once each (i.e. “single-use” optional CLINs), or as “orders CLINs” capable of being used more than once each during the period of performance in the event more than 3 Modules are required.

A29. These CLINs will be used once each.

Q30. In Section B for CLIN pricing purposes, should offerors assume Modules A & B are of similar scope to the DCIPHER Module? Or should Modules A & B be scaled to accommodate differing scopes of work (e.g. Module A = 50% scope of Module B). For CLIN pricing purposes, should offerors assume Modules A & B are of similar scope to the DCIPHER Module? Or should Modules A & B be scaled to accommodate differing scopes of work (e.g. Module A = 50% scope of Module B).

A30. Yes. Modules A and B represent additional development and/or configuration to the platform that has not been determined at this time. Additional Modules would leverage/reuse the existing DCIPHER platform functionality and tools. The level of development and/or configuration for additional Modules can be expected to be equal to or less than that done for the initial deployment. Examples of possible additional Modules are: 1-Configure 3 additional workflows for CDC programs (e.g., integrate/link patient data across multiple national healthcare surveys as one workflow); 2-Deploy the DCIPHER platform for mobile and smart devices; 3-Develop a data collection tool and interface; 4-Implement a data extraction, processing and transformation layer; 5-Implement electronic messaging for non-CDC laboratory data.

Q31. In Section C2, please confirm that proposals may refer to Attachment 2 in their Technical Approach (i.e. proposals do not have to respond to each individual requirement in Attachment 2).

A31. Yes.

Q32. In Section C.2.10.2, please confirm that the reference to “Attachment 3, Appendix A” should be corrected to "Attachment 2."

A32. The reference should have been “Attachment 2, Appendix A.”

Q33. In C.4 Performance Matrix, Item 6, please confirm that "within 30 days of Kickoff meeting" means 30 calendar days.

A33. Unless otherwise specified, any reference to days shall be interpreted as “calendar” days.

Q34. In Section C.2.3.14, please clarify the format and scale of the genetic and protein sequence data sets.

A34. The scale cannot be estimated at this time but will not be whole genome sequence-sized data sets, and standard file formats will include but not be limited to FASTQ and FASTA. The platform should also be able to interact with a record from the National Center for Biotechnology Information.

Q35. In Sections C.4.22 & C.4.23, please clarify the difference between C.4.22 and C.4.23. As written, they have the same Desired Outcomes and Required Services, but different SLA Performance Standards.

A35. The performance standards define CDC expectations for timely resolution of production support incidents.

All incidents reported are closed in 0-1 day 65% of the time All incidents reported are closed in 2-7 days 20% of the time All incidents reported are closed in 8+ days 15% of the time

Q36. In Section H.8.8, please clarify the seven security-associated requirements. These are missing from the document.

A36. Please see the following RFP sections: H.8.9, Position Sensitivity Designation; H.8.11, Privacy Compliance; H.8.12, Contractor’s Official Responsible for Information Security; H.8.13, Rules of Behavior; H.8.14, Information Security Training; H.8.15, HSPD-12 Compliance; and H.8.16, Encryption.

Q37. In Section H.8.8, please clarify what is meant by "in the application." Are offerors expected to include a response to "the seven security-associated requirements" in their proposals?

A37. Yes, offerors should address security controls compliance with all HHS security policy. Please see the following RFP sections: H.8.15, HSPD-12 Compliance; and H.8.16, Encryption.

Q38. In Section H.9.3, please confirm that the required HHS Section 508 Product Assessment Template and the binding statement of conformance should be included in the Business Volume.

A38. Yes.

Q39. In Section L.9 (a), please confirm that the “Contract Form found in Part I, Section A” is the Standard Form 33, and please confirm that the “Representations and Certifications” is Section K of the RFP (not Part IV, Section L as listed).

A39. Yes, the contract form refers to the Standard Form 33, and the Representations and Certifications are a reference to Section K.

Q40. In Section L.10, please clarify the instructions for the “Information Security” section of the Technical Proposal. What are offerors expected to provide for this section, other than the contact information required by H.8.12?

A40. Offerors should address security controls compliance with HHS security policy. Please see the following RFP sections: H.8.15, HSPD-12 Compliance; and H.8.16, Encryption.

Q41. In Section L.11.1, may graphics use Times New Roman font smaller than 12 point?

A41. It is permissible to use smaller but still clearly legible fonts for headers, footers, graphics, tables, and exhibits.

Q42. In Section L.12, given the extensive list of information required in Volume II: Technical Proposal, we respectfully request that CDC extends the page limit for this volume to 40 pages, and please confirm that the required Tables of Contents for Volumes II and III do not count toward the page limits of each volume.

A42. Tables of Contents will not be counted in the page limitation.

Q43. In Section 12.2, please confirm that the Small Business Subcontracting Plan should be included in the Business Volume, not the Technical Volume.

A43. The Small Business Subcontracting Plan should be included in the Technical Volume and will not count against the page limitation.

Q44. In Section L.13, Please confirm that it is acceptable to include a cover page for each volume and please confirm that cover pages do not count toward the page limit of each volume.

A44. Cover pages may be inlcuded in each volume and will not count in the page limitation.

Q45. In Sections I.1 and I.8, in the event an offeror’s solution meets the “commercial item” standards in FAR 15.403-1 (c)(3) and, accordingly, subject to solicitation provisions and contract clauses pursuant to FAR 12.301, please confirm the following provisions are non-applicable:

Non-applicable clauses incorporated by reference,

1. 52.215-2, Audit and Records-Negotiation; reference exception at: FAR 15.209 (b)(1)(iii)

2. 52.215-10, Price Reduction for Defective Certified Cost or Pricing Data; reference exception at: FAR 15.403-1(b)(3)

3. 52.215-11, Price Reduction for Defective Certified Cost or Pricing Data – Modifications; reference exception at: FAR 15.403-1(b)(3)

4. 52.215-12, Subcontractor Certified Cost or Pricing Data; reference exception at: FAR 15.403-1(b)(3)

5. 52.215-13, Subcontractor Certified Cost or Pricing Data -- Modifications; reference exception at: FAR 15.403-1(b)(3)

6. 52.215-21, Requirement For Certified Cost or Pricing Data Or Information Other Than Certified Cost Or Pricing Data – Modifications; reference exception at: reference exception at FAR 15.403-1(b)(3)

Non-applicable clauses incorporated in full text, 52.232-32 Performance-Based Payments. Pursuant to FAR 32.1000 Scope of Subpart, this clause is only applicable to “noncommercial purchases pursuant to Subpart 32.1.” Therefore, this clause is not applicable to solutions meeting “commercial item” standards.

A45. Although we are requesting COTS software, the bulk of the work is non-commercial. Therefore, the resulting contract will be considered non-commercial.

Q46. In Section I.6, please confirm that the data rights asserted by CDC in data management and implementation work are not intended to restrict intellectual property rights vendors may have in their commercial software, including ownership of their software and any updates, improvements, and modifications thereto pursuant to their commercial practices.

A46. The DCIPHER implementation work is not intended to restrict intellectual property rights contraqctors may have in their commercial software, including ownership of their software and any updates, improvements, and modifications thereto pursuant to their commercial practices. CDC will retain the rights and be provided access to the CDC specific configurations and data model.

Q47. In Sectioin I.9, we congratulate the Government on including a Performance Matrix to ensure quality delivery at fixed price. However, in the event an offeror proposes a commercial solution at firm fixed-price and subject to the C.4. Performance Matrix, will the Government provide an exception from the Earned Value Management (EVM) requirements? Doing so would be consistent with Government practice as reflected in the following:

· GSAM 534.201 – Policy (c)(1) states “…orders that are solely for commercial items or services, as defined at FAR 2.101, should not normally include EVMS.”

· 48 CFR Ch. 2 Subpart 234.2 – Earned Value Management System §234.201 Policy (1)(c) states “For firm-fixed-price contracts and subcontracts of any dollar value – (A) The application of earned value management is discouraged; and (B) Follow the procedures at PGI 234.201(1)(iv) for obtaining a waiver before applying earned value management.”

· PGI 234.201(1)(iv) states: “1)(iii) When the program manager decides to implement earned value management on contracts and subcontracts valued at less than $20,000,000, a cost-benefit analysis shall be conducted and the results documented in the contract file…(iv) In extraordinary cases where cost/schedule visibility is required and cannot be obtained using other means, the program manager shall request a waiver…”

Moreover, the use of EVM would be unnecessary for computer software publishers who are able to stand up a fully featured commercial software platform immediately upon commencement of the award of performance. Accordingly, EVM should not apply to offeror’s proposing this type of commercial solution. Will the Government confirm that the following do not apply in such cases:

· Earned Value Management Report (Deliverable/Milestone)

· 52.234-4 Earned Value Management System

· 52.234-3 Notice of Earned Value Management System – Post Award IBR

A47. It is required for the successful Offeror to adhere to use of an earned value management system (EVMS). A waiver must be granted by the Cognizant Federal Agency (CFA) for any changes to the EVMS.

Q48. In the event an offeror proposes commercial computer software or commercial computer software documentation under a license customarily provided to the public to the extent the license is consistent with Federal law and otherwise satisfies the Government's needs, will the Government be willing to modify the RFP to include FAR 52.227-19 Commercial Computer Software License pursuant to FAR 27.405-4 Commercial computer software, such that offeror’s proposal will not be adversely affected during evaluation if the offeror proposes the inclusion of such?

A48. CDC will not amend the RFP to include FAR 52.227-19. Nevertheless, an offeror will not be penalized in the evaluation merely for proposing the inclusion of FAR clauses as an alternative in its proposal as long as the offeror’s solution addresses the requirements of the RFP.

Q49. In the event an offeror’s solution meets the “commercial item” standards in FAR 15.403-1 (c)(3), will the Government honor alternate solicitation provisions and contract clauses pursuant to FAR 12.301 “Solicitation provisions and contract clauses for the acquisition of commercial items”? As the Government is aware, this request is fully consistent with FAR 12.302, as follows:

“The provisions and clauses established in this subpart are intended to address, to the maximum extent practicable, commercial market practices for a wide range of potential Government acquisitions of commercial items. However, because of the broad range of commercial items acquired by the Government, variations in commercial practices, and the relative volume of the Government’s acquisitions in the specific market, contracting officers may, within the limitations of this subpart, and after conducting appropriate market research, tailor the provision at 52.212-1, Instructions to Offerors-Commercial Items, and the clause at 52.212-4, Contract Terms and Conditions-Commercial Items, to adapt to the market conditions for each acquisition.”

A49. Although we are requesting COTS software, the bulk of the work is non-commercial. Therefore, the resulting contract will be considered non-commercial.

Q50. The requirement L.11.1.2 seems very restrictive and limiting. Our COTS framework has been deployed in US public health systems for many years helping with outbreak management and response; however, each program has used various configurations, as each program has unique requirements. Would a bid be disqualified if the deployment does not have the exact same configuration as what we are proposing for the DCIPHER program?

A50. The proposed solution will be used to support the current Ebola Virus Disease outbreak, so the proposed solution must be comprised of either a singular COTS product or a set of integrated COTS components that have been demonstrated to work together for at least three (3) years in order to be considered.

Q51. In regard to requirement L.11.1.2, we have continued to innovate and add to our offering during the last 3 years. We have added new modules/capabilities to our framework within the last 3 years. We are proposing several of these modules/capabilities to meet the requirements of DCIPHER. Should we propose only those components/capabilities that have been deployed over 3 years? (thus excluding DCIPHER from receiving some of our newer innovations and technology)

A51. The proposed solution must be comprised of either a singular COTS product or a set of integrated COTS components that have been demonstrated to work together for at least three (3) years in order to be considered.

Q52. Do vendor employees providing the services work need to be badged and if so how long does the process take?

A52. Yes, and the time needed to process staff varies because it requires a background check and is dependent on whether the employees are US citizens or not.

Q53. Will contractors be allowed to remotely connect into the provided servers via secure site-to-site VPN?

A53. Yes.

Q54.Will contractors be allowed to install monitoring agents on the provided servers for the purpose of monitoring software uptime and availability?

A54. No.

Q55. Are attachments/appendices allowed in the proposal?

A55. No attachments are allowed in the technical proposal (Volume II).

Q56. For 99% availability, does the CDC require hot or cold failover support?

A56. Hot or cold failover is permissible.

Q57. How does CDC define concurrent users? e.g., Total registered users, logged in users, total number of users activating application resource simultaneously.

A57. Concurrent users is defined as “logged in” users.

Q58. Data definition for sizing efforts

0. How many patient records?

0. How many patient case records?

0. How many laboratory records?

0. How many employee records?

0. How many hospitals records?

0. For each record type, what is the average record size and record schema? (i.e., number of columns and composition text, numeric).

0. For each record type, what is the rate at max, min, average which each record is required to be ingested?

0. How many unstructured text documents are ingested, and what is the total size of unstructured text to be analyzed, and what is the average size of each unique document?

0. How many years of historical data will be stored, and what is the anticipated data volumes for historical data?

A58. Due to the evolving nature of the Ebola Virus Disease response from case-finding and contact tracing to more long-term issues, it is not possible to make a final determination on which and how many business process areas, workflows, data sources and data elements will be included. All needed data streams to support the ongoing Ebola Virus Disease response are in scope for the first year implementation. Offerors are encouraged to list their parameters and assumptions (e.g., One business process workflow will consist of an average of 4-5 data sources, users will upload data 3-4 times per day, approximately 250 data elements, up to 5 KB per record, approximately 2500 records per year, etc.). File formats can include but are not limited to xls/x, csv, txt, doc/x, pdf, ppt, vsd, html, ascii, unicode, accdb, mdb, mdf, xml, sas, sql, images, time-series, wav, etc. The number and volume of unstructured records/text as well as the years of historical data will vary too much by event to be estimated but as outlined in “Attachment 2, Appendix A”, Performance Requirement NF-P-06, “The system shall be capable of scaling data volumes up to 2 terabytes.”

Q59. What is the definition of Module A and Module B? And does that definition impact the scope and sizing questions listed above? (e.g., number of records and number of current users)

A59. Modules A and B represent additional development and/or configuration to the platform that has not been determined at this time. Additional Modules would leverage/reuse the existing DCIPHER platform functionality and tools. The level of development and/or configuration for additional Modules can be expected to be equal to or less than that done for the initial deployment. Examples of possible additional Modules are: 1-Configure 3 additional workflows for CDC programs (e.g., integrate/link patient data across multiple national healthcare surveys as one workflow, which would generate additional data to be processed and stored); 2-Deploy the DCIPHER platform for mobile and smart devices; 3-Develop a data collection tool and interface; 4-Implement a data extraction, processing and transformation layer; 5-Implement electronic messaging for non-CDC laboratory data. Offerors are encouraged to list their parameters and assumptions.

Q60. “Appendix A Requirements” requests the application be both exclusively clientless (NF‐A‐01) as well as provided for an offline capability to reconnect after losing connectivity (NF-A-04). Can the CDC provide some insight on these differing requirements? Are there role-based needs that require both a clientless approach and a client approach for the use cases outlined?

A60. The primary user interface will be via a web browser (NF-A-01). However, CDC also desires an option for a stand-alone configuration on which to run a client as a separate disconnected unit (NF-A-04), or as a mobile application in the future. This sub-task is to allow some type of use of the proposed solution when disconnected from a network, allowing users to continue at least partial use of the system as necessary, and then syncing back up to existing network connections once the system is re-connected.

Q61. “Appendix A Requirements” NF‐P‐04 requires a concurrent user base of 100 users while NF-P-04 requires the capability for scaling up to a concurrent user base of 300 users. Does the base year sizing require the hardware to be in place and available to support 300 concurrent users or does the system architecture just need to support the addition of additional hardware?

A61. The hardware should support at minimum 100 concurrent users for the base year.

Q62. Can CDC provide the high level API for SAMS for applications that use industry standard authentication methods?

A62. SAMS provides authentication via two options – neither based on an API. The first, a more traditional approach, places a SAMS agent on an application forwarder sitting in the CDC’s DMZ. The agent intercepts incoming traffic, authenticates it, creates a security session and passes user information as part of header variables to the protected application. For this to work the application must reside on the internal CDC network. The second option is a Federated Partner approach where a SAML 2.0 token exchange happens between SAMS (the Identity Provider) and the application (the service provider), user information and authentication level is provided as part of the SAML token. The protected application must be SAML enabled for this to work. This method is primarily used for protection of applications that sit outside the CDC’s internal network.

Q63. The RFP states that the vendor is to procure the hardware. Is it acceptable for the vendor to acquire the hardware and transfer title to CDC per section C.2.11.2 of the RFP?

A63. Yes.

Q64. Is vendor responsible for installing and maintaining the physical hardware in CDC’s environment?

A64. Yes.

Q65. Is vendor responsible for physical and logical security of the deployed system in CDC’s environment?

A65. Yes, the awardee must comply with all of the security controls that protect systems deployed within CDC.

Q66. Is CDC looking for a vendor-hosted solution (as stated in H.8.1) or a solution to be installed at CDC’s location?

A66. The solution will be installed on vendor-provided hardware at CDC, within the CDC ITSO Applications Hosting Branch.

Q67. What is meant by real-time? What is the time that is needed to refresh data?

A67. “Real time” is when input data is processed and available within a few seconds of being ingested. DCIPHER users must be able to input their data and be able to access it within 5 seconds. In the case of continual data feeds from other systems, “real time” can mean bAttachment processing data 3 times per day, or whatever frequency is agreed to when establishing the continual data feed, but the data must still be processed and available within 5 seconds of being received. Please refer to “Attachment 2, Appendix A”, Data Integration Requirements F-DV-08 and F-DV-09.

Q68. In Section C.2.1.2, can the government clarify how will tag and metadata information be provided? What format?

A68. The proposed solution must have a way of assigning metadata to incoming data such that a piece of information’s lineage and system or origin can be traced. The format of such data should be suggested by the Offeror.

Q69. In Section C.2.2.1, can the government provide for each data source, what is the format, size, frequency, quality of each data source?

A69. No. Offerors are encouraged to list their parameters and assumptions (e.g., One business process workflow will consist of an average of 4-5 data sources, users will upload data 3-4 times per day, approximately 250 data elements, up to 5 KB per record, approximately 2500 records per year, etc.). File formats can include but are not limited to xls/x, csv, txt, doc/x, pdf, ppt, vsd, html, ascii, unicode, accdb, mdb, mdf, xml, sas, sql, images, time-series, wav, etc.

Q70. In Section C.2.3.2, can the government clarify what it means by “line list editor”? What additional information would a user be adding/modifying?

A70. A line list editor facilitates efficient data entry, and the viewing and editing of data in a grid format, with each epidemiological case as a row. This is similar to views provided by spreadsheets. Users could be adding/modifying any of the data.

Q71. In Section C.2.3, can the government quantify the number of reports, visualizations, dashboards?

A71. Offerors are encouraged to list their parameters and assumptions for visualizations, reports, dashboards, other data views, and forms for updating data. Since event responses have different needs during a response the number of reports, visualizations, and dashboards cannot be determined.

Q72. In Section C.2.7.1, can the government clarify what processes are data-related?

A72. An example of a data-related process that would need to be automated is the receipt of excel spreadsheet data that is sent daily to a user via email and that user manually opening the file, copying the data from the spreadsheet, and pasting it into a database. Instead of that manual daily process, CDC would like this to be an automated process.

Q73. In Section C.2.8.3, can the government provide the average level of increase in percentage for users and data?

A73. As outlined in “Attachment 2, Appendix A”, Performance Requirements NF-P-04 and NF-P-05, a minimum of 100 concurrent users must be able to use the platform the base year, and it must be able to scale up to a minimum of 300 concurrent users. The total number of users is unknown at this time but is expected to increase over time.

Q74. Can the [Government] provide more detail around the extent to which mobile device functionality is sought?

A74. At this time, the only mobile-related requirement CDC has is Architecture Requirement NF-A-02 in “Attachment 2, Appendix A”. A future Module A or B could be to possibly deploy the DCIPHER platform for mobile and smart devices.

Q75. If mobile device functionality is sought, can the Government clarify what mobile device form factors (i.e. smartphone, tablet) and mobile operating systems (i.e. iOS, Android) compatibility is desired?

A75. At this time, the only mobile-related requirement CDC has is Architecture Requirement NF-A-02 in “Attachment 2, Appendix A”. A future Module A or B could be to possibly deploy the DCIPHER platform for mobile and smart devices.

Q76. If mobile device functionality is sought, can the Government provide more information regarding whether a BYOD and/or MDM approach should be implemented?

A76. At this time, the only mobile-related requirement CDC has is Architecture Requirement NF-A-02 in “Attachment 2, Appendix A”. A future Module A or B could be to possibly deploy the DCIPHER platform for mobile and smart devices.

Q77. In Section C. 2.2.1.12 in terms of providing information regarding deployment from the strategic national stockpile, can vendors propose accessing a third party data vendor to provide vaccine and/or other drug data to address surveillance needs in the future?

A77. Yes.

Q78. In Section C.1.2, are there other specific infectious diseases that are considered a priority to be added to the functionality of this Event Response Platform?

A78. Yes, we have a list of individual programs now but we are also working through the details (data sources, workflows). If the system is properly designed, the program will not matter much and we do not have those specific details of what is required at this time. The information will be shared with the successful Offeror.

Q79. RFP section C.6, page 24. Within the proposal, the Government requests an Earned Value Management (EVM) approach as well as the use of Agile development methodologies. However, American National Standards Institute guidance for Earned Value are based upon waterfall project management, and no guidance exists within ANSI 748-C on the appropriate use within Agile software development engagements. Would CDC please provide the methodology it uses for Agile Earned Value Management Systems that compliment or contravene ANSI 748-C and other existing standards.

A79. It is required for the vendor to adhere to use of an earned value management system (EVMS) for all IT systems. A waiver must be granted by the Cognizant Federal Agency (CFA) for any changes to the EVMS.

Q80. RFP section C.4, page 19. The solicitation provides a comprehensive Performance Matrix. Please confirm that offerors may use an Appendix to respond to this table?

A80. The performance matrix is art of the technical proposal and therefore responses need to be part of the technical proposal page limit and not submitted as an appendix.

Q81. Attachment 2, Non-functional Requirements. Please clarify if this table is to be incorporated into the proposal submission? If this table is to incorporated, can the Government confirm that it will be excluded from page count?

A81. The requirements provided in “Attachment 2, Appendix A” are informational only and should not be incorporated into the proposal submission.

Q82. RFP section C.2.11, page 14. The requirements for this section refer to dollar amounts and elements of pricing not normally included in a technical volume. Can the Government confirm that this section is part of the technical response and that offerors will be in compliance by referencing elements normally associated with a price volume?

A82. Paragraph C.2.11 is merely instructional in guiding the contractor through the proper use of Other Direct Costs. No pricing information is included.

Q83. RFP section C.2.2.1.8, page 10. The Government refers to pathogen sequencing data in this requirement. Can the Government clarify what tools are being used to perform this activity now and is the expectation that the offeror’s proposed solution will provide storage for that data?

A83. Sequencing Laboratory Information Systems will provide storage for the data but the DCIPHER platform may need to link to the data.

Q84. RFP section C.2.3.9, page 11. The Government requires that offeror’s solution provide dendrogram/phylogenetic trees showing alignment (the genetic distances between whole genome sequences or snippets of sequences) that is based on user-defined thresholds and/or algorithms, and other hierarchical clustering techniques which would yield data on relatedness of sequencing data. Can the Government clarify what tools are being used to perform this activity now?

A84. CDC cannot provide a list of those tools in use at CDC for sequence analysis.

Q85. RFP section C.2.3.10, page 11. The Government requires that offerors solution display, manipulate, and store manipulated dendrogram trees, including naming or assigning/linking existing data to “leaves”, e.g., map epidemiological variables onto leaves or trees.

A85. CDC cannot provide a list of those tools in use at CDC for sequence analysis.

Q86. RFP section C.2.3.11, page 11. The Government requires that offerors solution provide subset data based on trees, e.g., be able to select a clade of the tree and pull all data from that clade for additional analysis. Can the Government clarify what tools are being used to perform this activity now?

A86. CDC cannot provide a list of those tools in use at CDC for sequence analysis.

Q87. RFP section C.2.3.12, page 11. The Government requires that offerors solution assign and perform analysis based on genotypic features, e.g., character or binary data, such as the presence/absence/type of antibiotic resistance genes present in an organism. Can the Government clarify what tools are being used to perform this activity now?

A87. CDC cannot provide a list of those tools in use at CDC for sequence analysis.

Q88. RFP section C.2.3.13, page 11. The Government requires that offerors solution conduct other genetic sequence data analyses, including basic multiple sequence alignment, sequence similarity searches, sequence mapping (output formats such as SAM/BAM, FASTA), variant files (VCF format), and the processing of phylogenetic trees (NWK format) and distance matrices. Can the Government clarify what tools are being used to perform this activity now?

A88. CDC cannot provide a list of those tools in use at CDC for sequence analysis.

Q89. RFP section C.2.3.14, page 11. The Government requires that offerors solution display and manipulate genetic and protein sequence datasets, including features and relevant metadata (GBK, ASN.1 formats). Can the Government clarify what tools are being used to perform this activity now?

A89. CDC cannot provide a list of those tools in use at CDC for sequence analysis.

Q90. RFP section C.2.4.9, page 12. The Government requires that offerors solution provide the ability to undo or revert back data manipulations via a logging interface that allows a user to select a modification to previous versions. Can the Government clarify what tools are being used to perform this activity now?

A90. CDC cannot provide a list of those tools in use at CDC for undoing/reverting back data manipulations.

Q91. RFP section C.2.4.10, page 12. The Government requires that offerors solution provide the ability to trace back lineage and pedigree of all changes made to every piece of information in the platform. Can the Government clarify what tools are being used to perform this activity now?

A91. CDC cannot provide a list of those tools in use at CDC for tracking lineage and pedigree of changes made to data in the platform.

Q92. RFP section C.2.5.3, page 12. The Government requires that offerors solution provide the ability to export all data in all data streams and all data types. Can the Government provide further clarification or other specifics on this requirement?

A92. The proposed solution needs to provide the ability to export all data for data sharing and archiving, i.e., a total data dump.

Q93. RFP section C.2.8.2, page 13. The Government requires that offerors solution support stand-alone configuration on which to run a client as a separate, disconnected unit, with auto-sync enabled once re-connected to a network. The offeror believes that this requirement conflicts with the requirement in C.2.8.1 for a solution that runs in a web-browser. Can the Government clarify the intention of this requirement and the overall requirement for a web-based solution?

A93. The primary user interface will be via a web browser (see Attachment 2, Appendix A”, Architecture Requirements NF-A-01). However, CDC also desires an option for a stand-alone configuration on which to run a client as a separate disconnected unit (NF-A-04), or as a mobile application in the future. This sub-task is to allow some type of use of the proposed solution when disconnected from a network, allowing users to continue use of the system as necessary, and then syncing back up to existing network connections once the system is re-connected.

Q94. RFP section C.2.8.8, page 13. The Government requires that offerors solution implement WebGL APIs to enable 3D and 2D dynamic graphics. Can the Government clarify the types of images that will be required? Can the Government clarify what tools are being used to perform this activity now?

A94. This is a requirement to support GIS functionality. CDC cannot provide a list of those tools in use at CDC that performs this activity now.

Q95. RFP section C.2.13, page 13. The Government requires technical support of the proposed solution. Because of critical nature for server uptime and availability, can the Government clarify its expectation in minimum availability?

A95. Per “Attachment_2, Appendix A”, Architecture Requirements NF-A-06, the platform shall have 99% availability. Technical support shall have 24/7 availability.

Q96. RFP section H.8.1, page 40. Will CDC take existing Authorities to Operate from other federal agencies in place of the lengthy work required to certify and accredit a vendor system?

A96. No, CDC must ensure all applicable security controls are implemented documented for the CDC environment. Therefore, DCIPHER must undergo the same Certification and Accreditation process that all other IT systems must undergo.

Q97. RFP section H.8.5, page 41. The Government outlines the ingestion of data from healthcare worker and travelers into this system. Since this data set contains a subset which must contain US citizens, how will that impact the system’s security posture? Which of the following: HIPAA, HL7, ANSI/ASCII X-12, ICD-10, and SNOMED CT standards will the system/solution need to satisfy?

A97. The intended security category is Low or Moderate, and likely to be Moderate. This will necessitate encryption of data while in transit. Different standards will apply to different types of data.

Q98. RFP section H.8.7, page 41. The Government refers to a ‘significant change” in the Deliverable table. Can the Government clarify if this includes the addition of new disease workflows and dashboards?

A98. A significant change (also known as a “Major Revision”) is defined by CDC’s Office of the Chief Information Security Officer as “A change to a CDC IT system which exceeds the limits of any residual operational risk already accepted by the organization or changes that potentially impact categorization of the system.” A new workflow might be considered a significant change if it involves a direct connection to an external system or incorporates a new technology layer. A new dashboard would not be considered a significant change.

Q99. RFP section H.8.7, page 41. Does the Government consider the major release of an open source product to be a “significant change” that requires recertification?

A99. Yes, typically major version number changes necessitate a security recertification.

Q100. RFP section H.8.7, page 41. Re-certifications require submission of completed documents to NCHHSTP’s ISSO 60 days prior to production, and the CDC CIO CISO’s office 45 days prior to production. If the offeror is to rapidly deliver new production capability to mAttachment new disease outbreaks, will CDC build in the 60 day task duration into the lifecycle delivery duration and offeror’s timeline expectations?

A100. All references to “NCHHSTP” should be replaced with “NCEZID”. An expedited C&A will be requested. Given the urgency of the current ongoing outbreaks the offerors solution must be ready to deploy within 30 days of the Kickoff Meeting to support the Ebola response.

Q101. RFP section H.8.7, page 41. Are the day durations quoted within this table based upon calendar days or working days?

A101. The duration of days shall be interpreted as working/business days.

Q102. RFP sections H.3 (e), page 34 and H.8.16, page 42. During the recent EVD crisis, the only connectivity at the majority of locations was through the local cellular infrastructure. Can the Government confirm that the proposed response platform must support mobile device access to platform capabilities and upload of data?

A102. At this time, the only mobile-related requirement CDC has is Architecture Requirement NF-A-02 in “Attachment 2, Appendix A”. A future Module A or B could be to possibly deploy the DCIPHER platform for mobile and smart devices.

Q103. General Solution Question. Can the Government provide an estimated number of transactions the solution will need to support under peak conditions and on the most representative use case for most critical, demanding, or frequent scenario?

A103. CDC cannot provide this information at this time. The number of transactions cannot be estimated due to the variability based on the functions being performed at that time, the number of concurrent users, and predicted actions (i.e. coding within the system) of the proposed solution.

Q104…