36C10B19R0014-009.xlsx
XLSX spreadsheet 23 KB Posted
- Solicitation number
- 36C10B19R0014
About this file
36C10B19R0014 VDIF EP RFI Q-A.xlsx
View the file
Other files
Show all 30
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| Veterans Data Integration and Federation (VDIF) Enterprise Platform (EP) Sustainment and Application Integration | |||
| Request for Information Questions and Answers | |||
| Item | Question | VA Response | PWS Revisions |
| 1 | Referencing PWS Sections 5.3 and 5.5, why does VA believe a scrum team size of seven individuals is optimal? | VA has revised its estimated scrum team size. The evaluation criteria may require Offeror's to propose a scrum team size as part of its technical approach. | Scrum team sizes in PWS Sections 5.2, 5.3 and 5.5 have been revised |
| 2 | Given the ongoing HealthShare integration advisory support performed under the following contracts, does the VA agree with our assessment that a potential Organizational Conflict of Interest (OCI) may exist for these contractors? |
- Booz Allen Hamilton—EHR Modernization Program Management Office and Technical Support Service (VA11816D1007/VA11817F10070007)
| -GovernmentCIO—Health Portfolio Program Management Office and Technical Support (VA11816D1003/36C10B18N10030020) | Potential bidders are required to assess potential organizational conflicts of interest. | |||
| 3 | Referencing PWS Attachment A, Section A.3.2, "The Contractor shall provide Tier 3 duties as outlined in the ESD help guides (refer to the ESD ITSM ServiceNow Guide)". To better scope/price level of effort required, would the Government please provide the ESD ITSM ServiceNow Guide with the final solicitation? | Yes. The guide is accessible online at: https://www.servicenow.com/success/champion/itsm-process-guide.html. This is referenced in PWS Paragraph 2.0, Applicable Documents. | PWS Section 2.0 revised accordingly. | |
| 4 | Referencing PWS Section 5.2 and Attachment A, Figure 1 and Table 1, "Refer to the shaded blue areas in Attachment A, Figure 1 for a depiction of the current main VDIF EP components". There are several shades of blue in Attachment A, Figure 1. Can the Government please confirm we should reference Table 1 for the definitive list of VDIF EP core components? | Attachment A has been revised. Attachment A contains Figure 1 only. PWS, Section 5.2, has been revised to include Table 1, previously in Attachment A as well as the requirement paragraphs. | PWS, Section 5.2.1, is revised to include Table 1, VDIF EP Core Components. | |
| 5 | Has the government developed an RTM for each interface based on ATTACHMENT_B_VDIF_EP_Integration document? If no, are there internal milestones the government would share to help the contractor meet them and build sprint teams that support the timelines already agreed to internally? | Attachment B has been revised to include the VDIF EP Application/System Interfaces now referenced as Table 4. The Government has a RTM for the applications listed Attachment B, Table 4 for the Enterprise HL7 and Regional HL7 Access types. For other access types and those indicated as TBD, some applications are in progress of RTM development; however, the scope of work in the PWS requires the contractor to perform the remaining RTM development. The Government will provide associated milestones for interface requirements and development upon award. | Attachment B has been revised accordingly | |
| 6 | Section 5.4.2.1 Design identifies a deliverable of the Technical Roadmap. “the contractor shall gather approved customer business requirements, evaluate VDIFs existing capabilities, products and services, and identify gaps in meeting established standards.” The PWS is structured for Waterfall, though the requirement is for Agile. Please clarify. | PWS Section 5.4 describes VA's VIP process which uses an Agile methodology. The Government plans to integrate small to medium size applications onto HealthShare in a 90-day increments. Larger systems may be added over a period of 90 - 180 days, however, a portion of the deliverable product will be required within 90 day increments. | ||
| 7 | What is the planned PoP for the 5.5 Optional Task? | The Optional Task may be exercised up to 25 times during each of the base and option years of the contract. These options will be executed based on the need for additional interface development (PWS 5.3) that is in the backlog or in the intake pipeline. These options may also be executed to support additional sustainment requirements (PWS 5.2). The Contractor should assume for pricing purposes that the exercise of each of the scrum teams will be for 12 months for each option exercise. | PWS 5.5 has been updated with the period of performance for each optional task at 12 months | |
| 8 | Will the planned ODC for licenses be a set amount or be dependent at time of award? | The VDIF-EP requirements do not include a requirement for the supply of licenses. | ||
| 9 | Referencing PWS Section 5.4.2.2.1, Item 13, Can the requirement prescribe the desired behavior for how HealthShare should deal with duplicate data elements from different VistA instances? Item 2 in this same list also talks about aggregation, but doesn’t indicate how duplicate data should be handled. For example, if two data sources report the Veteran as being allergic to penicillin, should the generated allergy list report the allergy to penicillin two times, or just one? | PWS, Section 5.3 has been revised to include the application integration backlog items. For Item 13, the contractor shall be required to support completion of backlog items based on VA prioritization under the scrum team approach. | PWS, Paragraph 5.3 has been revised accordingly | |
| 10 | Referencing PWS Section 5.4.2.2.1, Item 17, In addition to the systems listed in item 17, will the VDIF EP integrate with any other centralized services? ES, PPMS, and VAP seem probable, perhaps others? | PWS, Section 5.3 has been revised to include the application integration backlog items. For Item 17, yes, the VDIF will integrate will other centralized services through the intake process outlined in PWS 5.3. | PWS, Paragraph 5.3 has been revised accordingly | |
| 11 | Draft PWS 3.0 Scope of Work states that “The Contractor shall provide VA with Agile development of APIs and support for the VA API Gateway.” Can the government clarify if the VA API Gateway is a reference to the “Veterans Data Integration and Federation (VDIF) Enterprise Platform”, middleware Health Information Exchange, or something else? | There is no established VA API Gateway. VA is exploring commercial alternatives for a standard, COTS-based API Gateway to be used enterprise-wide. | ||
| 12 | Attachment A contains numerous tasks (e.g. 111 “contractor shall” statements), some of which appear to be similar or duplicative with task statements in the Draft PWS. For examples, both documents specify requirements to follow the VIP process, both documents specify tasks for defect management, and both documents specify configuration management and maintenance tasks. This organization and inclusion by cross-reference may cause confusion and an unnecessarily complex pricing/delivery schedule. As such, can the government consider reorganizing deliverables task descriptions and deliverables that avoids cross referenced tasks from multiple documents. | The PWS as well as the Attachments have been revised. The tasks and deliverables described previously in Attachment A have been incorporated into the PWS under Section 5.2 and its sub-paragraphs. | PWS and Attachments have been revised accordingly | |
| 13 | Draft PWS 5.3 VDIF EP INTEGRATION states that “PWS Attachment A.1, Table 2, represents the list of known completed or planned application interfaces based on requests prioritized via ESCP submission to date. In addition, there are internal and external applications/systems in the application integration (i.e., product) backlog currently being implemented.” Does this mean there are additional internal/external applications and systems not shown in A.1 Table 2? Can the government please clarify this statement. Does Table 2 represent the entire current backlog? | a. Yes; b. No, Table 2 does not represent the entire current backlog. The backlog evolves on a weekly basis to capture new intakes. Table 2 represents the backlog only during a snapshot in time. Note: Attachment B has been revised to include VDIF EP Application/System Interfaces and identified as Table 4 | Attachment B has been revised accordingly | |
| 14 | The number of developer and standard laptops specified in Draft PWS Section 4.5 Government Furnished Property, does not seem consistent with the VA anticipated support specified in PWS sections 5.2 and 5.3. PWS 5.2 specifies an O&M “scrum team comprised of 16 FTEs”. Draft PWS 5.3 VDIF EP Integration that calls for five (5) scrum teams in the base period with each team containing 7 members. Given that CAG does not provide the access performance required to execute the work specified in the PWS, can the government please clarify the apparent inconsistency between Government Furnished Equipment and the required staffing estimates? | The Government has revised its GFE estimates in Section 6.6 of the PWS. Upon award and as necessary to fulfill the requirements of the program, the Government will assign or remove GFE. | PWS has been revised accordingly | |
| 15 | Draft PWS 5.3 VDIF EP INTEGRATION states “See Attachment B for a description of the types of work to be performed and current contents of the interface backlog”, yet Attachment B does not appear to provide such a description as it is a VistA Data File Mapping Table. Can the government please clarify? | Attachment B has been revised. See revision to PWS Section 5.3 to reflect corrected references to Attachment B Tables 4 and 5, which reflects the backlog at a particular snapshot in time. The latest backlog will be provided at contract award. | PWS, Section 5.3 and Attachmet B have been revised accordingly | |
| 16 | Draft PWS 5.3 VDIF EP INTEGRATION states “The Contractor shall not make or perpetuate integration points between applications that do not have approved integration agreements in place”. Do integration agreements exist for all integration points specified as “Implemented” in Appendix A Table 1? Who is responsible for establishing and maintaining these agreements? Where will these agreements be maintained? | a. Yes, approval has been granted by the VDIF Technical Review Board (TRB) for the applications in Table 1 designated as implemented. |
b. The VDIF TRB is responsible for establishing and maintaining the agreements with respect to providing approval of each request to migrate to HealthShare. c. Integration Agreements are approved and maintained in Enterprise Services Collaboration Portal (ESCP) through an established workflow.
| 17 | Draft PWS 1.0 Background states “VDIF will support the integration of VistA data and JEHR data with Commercial Off-The-Shelf (COTS) and non-COTS products”. Likewise, Draft PWS 3.0 Scope of Work states “The goal is to integrate VistA data and JEHR data with COTS and non-COTS solutions requiring data access methods, governance and standardization of tools sets.” Can the government clarify or provide examples of the COTS and non-COTS solutions? | |||
| a. Related to the above question, in Draft PWS 5.4 VIP AGILE PROCESS sub-bullet 14 is states “The Contractor shall also support the onboarding of COTS data consumers (e.g., the EHR).” This statement in 5.4 seems to imply the EHR is a COTS data consumer. What EHR is being referenced here, the JEHR? If so, how does this reconcile with the statements in PWS 1.0 and PWS 3.0 specified above? | The reference to COTS products, also referenced as the EHR or EHRM system, is Cerner Millenium - they are synonyms. The PWS has been revised to remove references to JEHR. Additionally Attachment B has been revised, which includes Table 4 whereby references to COTS vs. Non-COTS products has been revised for clarification purposes. | PWS and Attachment B have been revised accordingly | ||
| 18 | Can the government indicate whether the VDIF EP or any of the core components of the VDIF EP have obtained an ATO or are in the process of obtaining an ATO? | ATO has been achieved for VDIF-EP. | ||
| 19 | Draft PWS 5.4.2.2.2 Configure HealthShare states that “The HS, FHIR server instances, and any other HS/HC Service Bus web services used shall be stood up on the VA production environment, albeit the AWS VAEC, AITC, or PITC.” Can the government clarify this sentence as the word “albeit” makes it unclear if VAEC, AITC or PITC are being specified as potential production environments? | VDIF-EP is currently stood up in AITC with a Development (Dev)/Software Quality Assurance (SQA)/Preproduction/Production environment. PITC is the Disaster Recovery site. Eventually, AWS VAEC will provide the Primary VA production environment, at which time AITC will provide the disaster recovery (DR)/failover environment. PITC's VDIF-EP environment(s) will be decommissioned after this transition. Estimated transition to be completed by March, 2020. | ||
| 20 | Can the government clarify where the current VDIF EP is being maintained? Is it in a production or preproduction environment? | See response to Q19. | ||
| 21 | In Draft PWS 5.4 VIP AGILE PROCESS it states that “The Contractor shall verify all integrated applications provide VDIF EP compliance to all security SSOi/SSOe remediation policies and support PIV 2-factor authentication in place of Access/Verify codes.” Can the government clarify if the current VDIF EP and all core components comply with SSOi/SSOe policies and support PIV 2-factor authentication? | Yes, the VDIF-EP and all core components comply with SSOi/SSOe policies and support PIV 2-factor authentication. | ||
| 22 | Draft PWS 3.0 SCOPE OF WORK states “The Contractor shall provide secure, high performance, governed access to JEHR data and VistA Legacy data allowing multiple client applications and the entire enterprise to access federated data.” Can the government refine the latter part of this requirement to align with the capabilities of the system that will be provided within this contract, and not obligate the contractor to provide the “entire enterprise to access federated data” as this is not feasible given the requirements of this PWS. | Please refer to revision to PWS Section 3.0 whereby it now states, The Contractor shall provide secure, high performance, governed access to EHRM system data and VistA Legacy data allowing multiple client applications and the entire enterprise to access federated data "for those applications connected to the VDIF-EP." | PWS, Section 3.0 has been revised accordingly. | |
| 23 | Attachment A.1.2 HEALTH LEVEL-7 (HL7) INTEGRATION states “The Contractor shall provide interoperability testing of HL7 interfaces to verify commercial devices connected to VistA comply with the HL7 standard.” This task appears to be beyond the scope specified in Draft PWS 3.0. Can the government clarify whether the contractor is responsible for testing and verifying HL7 compliance with all VistA instances across the VA enterprise? If so, can the government provide a list of commercial devices currently in use or planned so that the contractor can estimate a level of effort required to meet this requirement. | Attachment A has been revised to remove requirement paragraphs and Table. However, in respone to the questions: a. Yes, the Contractor is responsible for testing/verifying HL7 compliance with all (approximately 130) VistA instances across the VA enterprise; b. Please refer to an update to PWS, Paragraph, 5.2.1.3, Health Level-7 (HL7) Integration. | Attachment A has been revised as well as PWS under 5.2.1.3 Health Level-7 Integration | |
| 24 | Draft PWS 5.4.2.2.1 DEVELOP SUSTAINMENT AND APPLICATION INTEGRATIONS sub-bullet 13. States “The Contractor shall perform data integration, data mapping, and integrate VistA to EHR for the health component. The Contractor shall normalize and standardize data to include documents from multiple facilities and locations into a consistent, patient-centric record.” Can the government please clarify whether this requirement pertains to select VistA instances, all VistA instances, and or select VistA Data Files as specified in Attachment B? | The requirement for data integration, mapping, and integrating VistA to the EHR health component pertains to all ~130 VistA instances. For the VistA data files represented in Attachment B, the requirement for data integration, mapping, and integration VistA to the EHR health component may pertain to one or more of the referenced VistA data files. | ||
| 25 | Draft PWS 5.4.2.2.1 DEVELOP SUSTAINMENT AND APPLICATION INTEGRATIONS Sub-bullet 14 states “The Contractor shall implement web services information exchange hosted on a new Digital Veterans Platform (DVP).” Can the government clarify if the DVP is a reference to VA Lighthouse, the VA API Management Platform shown in Attachment A Figure 1, or the proof-of-concept system constructed a few years back, or something else? | Yes. This is in reference to VA Lighthouse and has been reflected in a revison to the PWS. PWS, Section 5.3, has been revised to include the application integration backlog items. Item 14 has been revised to include a reference to VA Lighthouse. | PWS, Section 5.3, Item 14, has been revised accordingly |
File details come from the government source that posted it.