36C10A18R0043-A00002002.docx
DOCX document 197 KB Posted
- Solicitation number
- 36C10A18R0043
About this file
36C10A18R0043 A00002 S06 36C10A18R0043 A00002 Attach 1 PWS.docx
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 36C10A18C0067-000.docx | DOCX document | |
| 36C10A18R0043-A00004000.docx | DOCX document | |
| 36C10A18R0043-A00003000.docx | DOCX document | |
| 36C10A18R0043-A00002000.docx | DOCX document | |
| 36C10A18R0043-A00002001.docx | DOCX document | |
| 36C10A18R0043-A00001000.docx | DOCX document | |
| 36C10A18R0043-A00001001.docx | DOCX document | |
| 36C10A18R0043-A00001002.docx | DOCX document | |
| 36C10A18R0043-003.docx | DOCX document | |
| 36C10A18R0043-002.docx | DOCX document | |
| 36C10A18R0043-001.docx | DOCX document | |
| 36C10A18R0043-004.xlsx | XLSX spreadsheet | |
| 36C10A18R0043-000.docx | DOCX document |
Show all 13
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
Addendum B Addendum B
PERFORMANCE WORK STATEMENT
DEPARTMENT OF VETERANS AFFAIRS
Substance Use Disorder Treatment Proof of Concept Support for the
Center for Compassionate Innovation
Date: December 727, 2017 Version 1.01
Contents
| 1.0 | BACKGROUND | 4 |
| 2.0 | APPLICABLE DOCUMENTS | 5 |
| 3.0 | SCOPE OF WORK | 8 |
| 4.0 | PERFORMANCE DETAILS | 9 |
| 4.1 | PERFORMANCE PERIOD | 9 |
| 4.2 | PLACE OF PERFORMANCE | 10 |
| 4.3 | TRAVEL | 10 |
| 5.0 | SPECIFIC TASKS AND DELIVERABLES | 10 |
| 5.1 | PROJECT MANAGEMENT | 10 |
| 5.1.1 | CONTRACTOR PROJECT MANAGEMENT PLAN | 10 |
| 5.1.3 | REPORTING REQUIREMENTS | 11 |
| 5.1.3.1 | WEB & MOBILE POLICY FOR SOFTWARE BUILDS | 12 |
| 5.1.3.2 | RELEASE NUMBERING SCHEME | 13 |
| 5.1.4 | RATIONAL TOOLS TRAINING | 14 |
| 5.1.5 | PRIVACY AND HIPAA TRAINING | 14 |
| 5.2 | MANAGEMENT AND OVERSIGHT STRUCTURE RECOMMENDATIONS | 15 |
| 5.3 | MOBILE MEDICAL DIGITAL APPLICATION DEVELOPMENT | 16 |
| 5.3.1 | VIP DEVELOPMENT LIFECYCLE | 16 |
| 5.3.1.1 | AGILE REQUIREMENTS ELABORATION | 16 |
| 5.3.1.2 | BUILD AND DEVELOPMENT | 17 |
| 5.3.1.3 | BUILD PLANNING | 17 |
| 5.3.1.4 | SPRINT PLANNING | 18 |
| 5.3.1.5 | SPRINT EXECUTION | 18 |
| 5.3.1.6 | TESTING | 20 |
| 5.3.1.7 | USER ACCEPTANCE TESTING AND BUILD DELIVERY | 21 |
| 5.3.1.8 | RELEASE SUPPORT | 21 |
| 5.3.1.9 | RELEASE TO OPEN SOURCE | 21 |
| 5.3.2 | SUD MOBILE APPLICATION FUNCTIONAL REQUIREMENTS | 22 |
| 5.4 | PATIENT CARE MODEL SUPPORT | 23 |
| 5.4.1 | CASE MANAGEMENT SERVICE | 25 |
| 5.4.2 | 24-HOUR SUPPORT CENTER | 26 |
| 5.5 | POST-PROOF OF CONCEPT RESULTS | 27 |
| 5.6 | OPTIONAL TASK: PROOF OF CONCEPT TRAINING | 27 |
| 5.7 | OPTION PERIOD: FOLLOW ON OF BASE YEAR TASKS | 28 |
| 6.0 | GENERAL REQUIREMENTS | 28 |
| 6.1 | ENTERPRISE AND IT FRAMEWORK | 28 |
| 6.2 | SECURITY AND PRIVACY REQUIREMENTS | 30 |
| 6.2.1 | POSITION/TASK RISK DESIGNATION LEVEL(S) | 30 |
| 6.2.2 | CONTRACTOR PERSONNEL SECURITY REQUIREMENTS | 31 |
| 6.3 | METHOD AND DISTRIBUTION OF DELIVERABLES | 33 |
| 6.4 | PERFORMANCE METRICS | 33 |
| 6.5 | FACILITY/RESOURCE PROVISIONS | 34 |
| 6.6 | GOVERNMENT FURNISHED PROPERTY/INFORMATION | 35 |
| ADDENDUM A – ADDITIONAL VA REQUIREMENTS, CONSOLIDATED | 37 | |
| ADDENDUM B – VA INFORMATION AND INFORMATION SYSTEM SECURITY/PRIVACY LANGUAGE | 44 |
BACKGROUND
The Department of Veterans Affairs (VA), Veterans Health Administration (VHA) Center for Compassionate Innovation (CCI) was established to find innovative programs that improve quality, access, customer satisfaction, and value for Veterans in VHA. The mission of the CCI is to explore emerging therapies that are safe and ethical to enhance Veteran physical and mental well-being when other treatments have not been successful. CCI primarily focuses on treatments that address suicide prevention, Traumatic Brain Injury (TBI), Posttraumatic Stress Disorder (PTSD), and chronic pain. Alcohol and opiate addiction are risk factors for Veteran suicide and homelessness — both of which are priorities for the VA and the Nation.
Substance Use Disorders (SUDs) are among the most common and costly conditions for the estimated one million Veterans and active duty military personnel affected. Treatment for this disorder plays an important role in Veteran healthcare. VHA treatment personnel are mission-driven, committed, and operate within an evidence base of clinical practices. However, organizational processes for implementing and allocating care to the specific needs of Veterans with SUDs have not kept pace with addiction treatment demand. As a result, limited capacity can result in long delays between first contact and treatment. Delayed care can contribute to less than desirable readmission rates among addicted Veterans, Veteran dissatisfaction with VA systems, and potential intentional or unintentional death from overdose. VHA is continuously working to find solutions to create new pathways for access. Thus, a SUD proof of concept that can scale up to meet demand for addiction treatment modalities is required.
The SUD proof of concept will provide an opportunity initially to increase access to care for up to 1,000 patients diagnosed with alcohol and opiate addiction for whom access to care in the VHA system is limited. It builds off of the success of an effort to address access to care initiated in Veterans Integrated Service Network (VISN) 2. Created in partnership with the Loyola Recovery Foundation and VISN 2, the current SUD program has treated more than 16,000 patients with positive results, including: decreased hospital readmission rates by 70 percent, increased patient satisfaction, and increased patient engagement. The current program employs a one-stop-shop for counseling, pharmacotherapy, meditation and patient support and monitoring (via a mobile digital application) and is delivered in an outpatient clinical setting. It is regarded as a practice-based standard of care at VHA. However, VHA has not determined how to scale the approach to multiple locations so Veterans in different VISNs can have access to a similar program. Therefore, VHA requires a scaled approach to assess the opportunities and investments necessary to make the current program available to a larger number of patients in need. This proof of concept will enable a practice-based evidence approach and address how VA can effectively and efficiently scale this effort to more sites. The SUD proof of concept will also address the administrative, technical, and clinical impediments to scale the approach; identify and develop requirements from the lessons learned from the project. The benefits of the proof of concept include:
· Access to care for up to 1000 patients already diagnosed with alcohol and/or opiate addiction who otherwise would not receive care in 2017 and 2018.
· Delivery of a data exchange for the SUD proof of concept that also can be used as a model for other programs to scale secure access across the Enterprise.
· An example of increased use of care delivered in the community as directed by the Veterans Choice Act.
· An instance of “innovation at scale” aligned with the President’s Executive Order on Reorganization.
· An instance of "innovation at scale" aligned with the President's Executive Order on Reorganization an urgent response to the President’s declaration of emergency for opioid crisis.
APPLICABLE DOCUMENTS
In the performance of the tasks associated with this Performance Work Statement, the Contractor shall comply with the following:
1. 44 U.S.C. § 3541, “Federal Information Security Management Act (FISMA) of 2002”
2. Federal Information Processing Standards (FIPS) Publication 140-2, “Security Requirements For Cryptographic Modules”
3. FIPS Pub 201-2, “Personal Identity Verification of Federal Employees and Contractors,” August 2013
4. 10 U.S.C. § 2224, "Defense Information Assurance Program"
5. Carnegie Mellon Software Engineering Institute, Capability Maturity Model® Integration for Development (CMMI-DEV), Version 1.3 November 2010; and Carnegie Mellon Software Engineering Institute, Capability Maturity Model® Integration for Acquisition (CMMI-ACQ), Version 1.3 November 2010
6. 5 U.S.C. § 552a, as amended, “The Privacy Act of 1974”
7. 42 U.S.C. § 2000d “Title VI of the Civil Rights Act of 1964”
8. VA Directive 0710, “Personnel Security and Suitability Program,” June 4, 2010, http://www.va.gov/vapubs/
9. VA Handbook 0710, Personnel Security and Suitability Security Program, May 2, 2016, http://www.va.gov/vapubs
10. VA Directive and Handbook 6102, “Internet/Intranet Services,” July 15, 2008
11. 36 C.F.R. Part 1194 “Electronic and Information Technology Accessibility Standards,” July 1, 2003
12. Office of Management and Budget (OMB) Circular A-130, “Managing Federal Information as a Strategic Resource,” July 28, 2016
13. 32 C.F.R. Part 199, “Civilian Health and Medical Program of the Uniformed Services (CHAMPUS)”
14. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, October 2008
15. Sections 504 and 508 of the Rehabilitation Act (29 U.S.C. § 794d), as amended by the Workforce Investment Act of 1998 (P.L. 105-220), August 7, 1998
16. Homeland Security Presidential Directive (12) (HSPD-12), August 27, 2004
17. VA Directive 6500, “Managing Information Security Risk: VA Information Security Program,” September 20, 2012
18. VA Handbook 6500, “Risk Management Framework for VA Information Systems – Tier 3: VA Information Security Program,” March 10, 2015
19. VA Handbook 6500.1, “Electronic Media Sanitization,” November 03, 2008
20. VA Handbook 6500.2, “Management of Breaches Involving Sensitive Personal Information (SPI)”, July 28, 2016
21. VA Handbook 6500.3, “Assessment, Authorization, And Continuous Monitoring Of VA Information Systems,” February 3, 2014
22. VA Handbook 6500.5, “Incorporating Security and Privacy in System Development Lifecycle”, March 22, 2010
23. VA Handbook 6500.6, “Contract Security,” March 12, 2010
24. VA Handbook 6500.8, “Information System Contingency Planning”, April 6, 2011
25. Office of Information and Technology (OI&T) ProPath Process Methodology (Transitioning to Process Asset Library (PAL) (reference process maps at http://www.va.gov/PROPATH/Maps.asp and templates at http://www.va.gov/PROPATH/Templates.asp
26. One-VA Technical Reference Model (TRM) (reference at http://www.va.gov/trm/TRMHomePage.aspx)
27. National Institute Standards and Technology (NIST) Special Publications (SP)
28. VA Directive 6508, “Implementation of Privacy Threshold Analysis and Privacy Impact Assessment,” October 15, 2014
29. VA Handbook 6508.1, “Procedures for Privacy Threshold Analysis and Privacy Impact Assessment,” July 30, 2015
30. VA Directive 6300, Records and Information Management, February 26, 2009
31. VA Handbook, 6300.1, Records Management Procedures, March 24, 2010
32. OMB Memorandum, “Transition to IPv6”, September 28, 2010
33. VA Directive 0735, Homeland Security Presidential Directive 12 (HSPD-12) Program, October 26, 2015
34. VA Handbook 0735, Homeland Security Presidential Directive 12 (HSPD-12) Program, March 24, 2014
35. OMB Memorandum M-06-18, Acquisition of Products and Services for Implementation of HSPD-12, June 30, 2006
36. OMB Memorandum 05-24, Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors, August 5, 2005
37. OMB memorandum M-11-11, “Continued Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors, February 3, 2011
38. OMB Memorandum, Guidance for Homeland Security Presidential Directive (HSPD) 12 Implementation, May 23, 2008
39. Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, December 2, 2011
40. NIST SP 800-116, A Recommendation for the Use of Personal Identity Verification (PIV) Credentials in Physical Access Control Systems, November 20, 2008
41. OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information, May 22, 2007
42. NIST SP 800-63-2, Electronic Authentication Guideline, August 2013
43. NIST SP 800-157, Guidelines for Derived PIV Credentials, December 2014
44. NIST SP 800-164, Guidelines on Hardware-Rooted Security in Mobile Devices (Draft), October 2012
45. Draft National Institute of Standards and Technology Interagency Report (NISTIR) 7981 Mobile, PIV, and Authentication, March 2014
46. VA Memorandum, VAIQ #7100147, Continued Implementation of Homeland Security Presidential Directive 12 (HSPD-12), April 29, 2011 (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)
47. VA Memorandum, VAIQ # 7011145, VA Identity Management Policy, June 28, 2010 (reference Enterprise Architecture Section, PIV/IAM (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)
48. IAM Identity Management Business Requirements Guidance document, May 2013, (reference Enterprise Architecture Section, PIV/IAM (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)
49. Trusted Internet Connections (TIC) Reference Architecture Document, Version 2.0, Federal Interagency Technical Reference Architectures, Department of Homeland Security, October 1, 2013, https://s3.amazonaws.com/sitesusa/wp-content/uploads/sites/482/2015/04/TIC_Ref_Arch_v2-0_2013.pdf
50. OMB Memorandum M-08-05, “Implementation of Trusted Internet Connections (TIC), November 20, 2007
51. OMB Memorandum M-08-23, Securing the Federal Government’s Domain Name System Infrastructure, August 22, 2008
52. VA Memorandum, VAIQ #7497987, Compliance – Electronic Product Environmental Assessment Tool (EPEAT) – IT Electronic Equipment, August 11, 2014 (reference Document Libraries, EPEAT/Green Purchasing Section, https://www.voa.va.gov/documentlistpublic.aspx?NodeID=552)
53. Sections 524 and 525 of the Energy Independence and Security Act of 2007, (Public Law 110–140), December 19, 2007
54. Section 104 of the Energy Policy Act of 2005, (Public Law 109–58), August 8, 2005
55. Executive Order 13693, “Planning for Federal Sustainability in the Next Decade”, dated March 19, 2015
56. Executive Order 13221, “Energy-Efficient Standby Power Devices,” August 2, 2001
57. VA Directive 0058, “VA Green Purchasing Program”, July 19, 2013
58. VA Handbook 0058, “VA Green Purchasing Program”, July 19, 2013
59. Office of Information Security (OIS) VAIQ #7424808 Memorandum, “Remote Access”, January 15, 2014, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28
60. Clinger-Cohen Act of 1996, 40 U.S.C. §11101 and §11103
61. VA Memorandum, “Implementation of Federal Personal Identity Verification (PIV) Credentials for Federal and Contractor Access to VA IT Systems”, (VAIQ# 7614373) July 9, 2015, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28
62. VA Memorandum “Mandatory Use of PIV Multifactor Authentication to VA Information System” (VAIQ# 7613595), June 30, 2015, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28
63. VA Memorandum “Mandatory Use of PIV Multifactor Authentication for Users with Elevated Privileges” (VAIQ# 7613597), June 30, 2015; https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28
64. “Veteran Focused Integration Process (VIP) Guide 1.0”, December, 2015, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4371
65. “VIP Release Process Guide”, Version 1.4, May 2016, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4411
66. “POLARIS User Guide”, Version 1.2, February 2016, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4412
SCOPE OF WORK
The objective of the SUD proof of concept is to improve access to care and provide a template and framework that enables VA to scale this approach across the VHA system. The outcome of the proof of concept will provide a path for VA to implement a system-wide approach to directly improve the lives of Veterans in need of substance use disorder treatment.
The Contractor shall maximize results from the original treatment program, to manage, test, and evaluate the proof of concept’s Enterprise capability, and to refine and scale the approach to SUD treatment, including:
· Review existing management and administrative systems and propose improved mechanisms for scaling to a VA-wide solution;
· Establish a repeatable and scalable program management process;
· Provide the knowledge transfer to VA Medical Center (VAMC) personnel;
· Define the requirements and necessary enhancements needed to achieve scalability;
· Develop an open source digital application that will support the interoperability between all components of the proof of concept and operational capability;
· Provide an enhanced analysis of the results of treatment;
· Identify requirements for functionality and interfaces for follow-on capability.
The following are specific objectives of the contract:
· A framework for improving access to care and increasing engagement for patients suffering from SUDs
· A detailed set of institutional and enterprise requirements for the supervision, management, and clinical services to deliver care
· The technological interfaces, data interoperability and exchange frameworks, and deployment guidelines necessary to support care
· A set of implementation metrics for use in future model replication and scaling
· Develop mobile tools aimed at recovery monitoring, predictive analytics, patient support and relapse prevention
· A Fast Healthcare Interoperability Resources (FHIR)-based exchange for the SUD program that can be used as a model for any program to scale secure access across the enterprise.
PERFORMANCE DETAILS
PERFORMANCE PERIOD
This work shall cover a nine month base period and up to two option years of twelve months. It is anticipated that the base period of performance (POP) shall be comprised of a three and a half-month ramp-up period to start the proof of concept, followed by six months to collect and evaluate data to deliver specific enhancements to the management and administrative systems that ensure proper patient support at the initial and future sites. Proof of concept will be delivered for one site in the base period. Each of the two option periods, if exercised, shall deliver continued proof of concept support over an additional 12 months of patient treatment at the original site in order to achieve a statistically significant number of patients in the proof of concept that then can inform the creation of requirements for a commercial procurement. The option periods will address scalability.
Support related to direct clinical care which takes place at the San Diego VA Medical Center (VAMC) facility may take place on Federal holidays or weekends. Other administrative support at Government facilities will not take place on Federal holidays or weekends unless specifically directed by the Contracting Officer’s Representative (COR).
Under current definitions, four are set by date:
| New Year's Day | January 1 |
| Independence Day | July 4 |
| Veterans Day | November 11 |
| Christmas Day | December 25 |
If any of the above falls on a Saturday, then Friday shall be observed as a holiday. Similarly, if one falls on a Sunday, then Monday shall be observed as a holiday.
The other six are set by a day of the week and month:
| Martin Luther King's Birthday | Third Monday in January |
| Washington's Birthday | Third Monday in February |
| Memorial Day | Last Monday in May |
| Labor Day | First Monday in September |
| Columbus Day | Second Monday in October |
| Thanksgiving | Fourth Thursday in November |
PLACE OF PERFORMANCE
The contractor shall perform tasks under this PWS at contractor facilities and at the San Diego VAMC.
TRAVEL
The Government anticipates travel under this effort to perform the tasks associated with the effort, as well as to attend program-related meetings or conferences throughout the PoP. Include all estimated travel costs in your firm-fixed price line items. These costs will not be directly reimbursed by the Government.
The following is the Government’s estimated long distance travel:
Basic Period Travel Estimate:
| Destination |
| Number of trips |
| Length of each trip (days) |
| Number of Contractor Staff traveling per trip |
| VA Central Office (VACO) |
| 3 |
| 5 |
| 5 |
| Site 1 San Diego |
| 5 |
| 5 |
| 5 |
Option 1 Period Travel Estimate:
| Destination |
| Number of trips |
| Length of each trip (days) |
| Number of Contractor Staff traveling per trip |
| VACO |
| 3 |
| 5 |
| 4 |
| Site 1 San Diego |
| 5 |
| 5 |
| 5 |
The Government encourages the contractor to maximize its use of teleconferencing and video conferencing for meetings.
SPECIFIC TASKS AND DELIVERABLES
The Contractor shall perform the following. All deliverables shall be provided in accordance with Federal Acquisition Regulation (FAR) 52.227-14 Rights in Data – General (Dec 2007) Alt IV and FAR 52.227-16 Additional Data Requirements (Jun 1987), with the exception of any commercial computer software licenses delivered. Commercial computer software licenses delivered shall be in accordance with FAR 52.227-19 Commercial Computer Software Licenses (Dec 2007).
PROJECT MANAGEMENT
CONTRACTOR PROJECT MANAGEMENT PLAN
The Contractor shall deliver a Contractor Project Management Plan (CPMP) that lays out the Contractor’s approach, timeline, and tools to be used in execution of the contract. The CPMP should take the form of both a narrative and graphic format that displays the schedule, milestones, risks, and resource support. The CPMP shall include how the Contractor will coordinate and execute planned, routine, and ad hoc data collection reporting requests as identified within the PWS. The initial baseline CPMP shall be in accordance with Section B of the contract and shall be concurred upon by the VA Project Manager (PM). The Contractor shall update and maintain the VA PM approved CPMP throughout the PoP. In accordance with Section 6, Security and Privacy Requirements, the contractor shall deliver a Staff Roster.
Deliverables:
A. CPMP.
B. Contractor Staff Roster.
1.1.1 KICK-OFF MEETING
Within 15 days of contract award, the Contractor shall lead a kick-off meeting for the effort. The purpose of the kick-off meeting shall be to create an understanding between VA and the Contractor of project approach, major actions, and schedule for key milestones and deliverables. The kick-off meeting shall also serve as the means to provide the Contractor with additional details regarding required tasks. The Contractor shall provide the Government with a draft presentation one business day prior to the meeting. The presentation shall review the task coordination details, e.g., meeting schedules and topics, deliverable review, issue resolution processes, and preferred communication mechanisms. The kick-off meeting shall be held at VA facilities, Contractor facilities, or virtually, at the discretion of the Government. The completion of this meeting shall result in the following outcomes:
· Introduction of Contractor and Government personnel performing work related to this project
· A brief overview of project administration and reporting by the Contractor
· A review of tasks by the Contractor to forge a common understanding of work to be performed, responsibilities, and Government’s priorities for the Contractor.
The Contractor shall provide the Government with a final copy of the presentation.
Deliverable:
Kick-Off Meeting Presentation.
REPORTING REQUIREMENTS
The contractor shall provide the COR with Monthly Progress Reports in electronic form in Microsoft Word and Microsoft Project formats. The report shall include detailed instructions/explanations for each required data element, to ensure that data is accurate and consistent. These reports shall reflect data as of the last day of the preceding month.
The Monthly Progress Reports shall cover all work completed during the reporting period and work planned for the subsequent reporting period. The report shall identify any problems that arose and a description of how the problems were resolved. If problems have not been completely resolved, the contractor shall provide an explanation including their plan and timeframe for resolving the issue. The report shall include an itemized list of all Electronic and Information Technology (EIT) deliverables and their current Section 508 conformance status. The Contractor shall monitor performance against the CPMP and report any deviations. The Contractor shall keep in communication with VA accordingly so that issues that arise are transparent to both parties and to prevent escalation of outstanding issues. Upon final delivery the contractor shall provide Section 508 compliance test results in accordance with Section A3.4 Acceptance and Acceptance Testing.
The Contractor shall use VA’s implementation of IBM Rational Collaborative Application Lifecycle Management (CALM) Toolset (hereafter referred to as Rational) or Atlassian JIRA (hereafter referred to as JIRA), as directed by the Government, to provide a single Agile project/product lifecycle management tool to track execution details. The Rational or JIRA project/product data and artifact repository shall be used to provide a single, authoritative project and product data and artifact repository. All OI&T project data and artifacts shall be required to be managed in this data and artifact repository daily. All checked out artifacts shall be checked back in daily and any data updated daily. Rational or JIRA synchronizes all changed information immediately for all team members to access work proficiently without the concern of working on aged information.
The Contractor shall use Rational or Atlassian tools in accordance with the VA Rational Tools Guide to:
1. Input and manage scheduled project/product sprints and backlog
2. Input and manage project/product agile requirements
3. Input and manage project/product risks and issues
4. Input and manage project/product configurations and changes
5. Input and manage project/product test plans and execution
6. Input and manage project/product planning and engineering documentation
7. Input and manage linkages to correlate requirements to change orders to configurable items to risks, impediments, and issues to test cases and test results to show full traceability.
The Contractor shall show all Agile requirements, changes, tests performed, and test results in Rational or JIRA to show evidence of code coverage and test coverage of all the requirements specified, allowing VA to have high confidence in a fully documented, as evidenced by data in the tools and requirements traceability matrix.
Deliverables:
A. Monthly Progress Report.
B. Final Section 508 Compliance Test Results.
1.1.1.1 WEB & MOBILE POLICY FOR SOFTWARE BUILDS
All source code shall be stored in VA’s Mobile Application Environment (MAE) source code repository. Developers can develop code in an external development repository; however, each version delivered to the MAE for testing, must be reproducible from code stored in the MAE source code repository.
The dependencies for a build shall be stored in the MAE source code repository and may not be pulled from the Internet during build time.
All versions of the app delivered in the MAE Integration environment shall be tagged with the release number in the MAE source code repository. All release numbers must follow the naming convention as described in the official Release Numbering Scheme for the VA Mobile Framework (VAMF). Currently the VAMF and Mobile Applications use the release numbering scheme described below.
All builds shall be constructed (built) with build scripts that can be executed from an automated build tool such as Jenkins (provided in the MAE) or the command line. The MAE source code repository will include the instructions for building the app outside of any automated build tool. For example, the build scripts may use ant or maven and the specific commands and customizations of the build must be documented in a file stored with the source code in the repository.
To deliver an app deployment package into the MAE or to an app store (Apple App Store, Airwatch, Google Play, etc.), the app must be built using a Jenkins build job in the MAE from source code in the source code repository. Delivery of apps shall be automated in Jenkins so the Jenkins build output can be retrieved for delivery into the environment.
1.1.1.2 RELEASE NUMBERING SCHEME
Mobile Applications and the VAMF will use the Release Numbering Scheme described by the Open Source Semantic Versioning project located at: http://semver.org
The Contractor shall use metadata tags to enumerate the environment to which a build is to be deployed (dev, test, demo, int1, int2, int3, preprod, prod) as well as the Jenkins build sequence for any given build job.
Major releases include significant app changes. Major releases shall accompany significant User Interface (UI), app feature set, Application Program Interface (API) or enhancement/remediation project changes. App APIs are considered "Stable" across builds with the same Major release number. APIs may be deprecated in subsequent Major releases and shall not be removed until at least two Major releases have been made. For example, an API introduced in release 1 may be deprecated in release 2 and then subsequently removed in release 3.
Minor releases are defined by incremental feature set enhancements/remediation(s). The Minor Release number indicates the status of the app with regards to "Development/Test" build versus a "Production" build for public use. All enhancement/remediation builds shall be denoted by an ODD Minor Release number. All Public releases shall be denoted by an EVEN Minor Release number.
The Feature release number indicates product enhancements or remediation (bug fixes) for a given release. The feature release number is often incremented throughout the Software Development Life Cycle (SDLC) as needed for coordination with development, testing, or other project teams.
The Build number is a sequential number assigned by the Continuous Integration server to identify specific builds.
Examples:
| 1.1.0.1 | Denotes the first Major enhancement/remediation release build. |
| 1.1.0.32 | Denotes the 32nd build of the first Major enhancement/remediation release. |
| 1.1.1.1 | Denotes the first build of the first Major enhancement/remediation release with additional app enhancement/remediation. |
| 1.2.0.1 | Denotes the first build of the first Major public release of the app. |
RATIONAL TOOLS TRAINING
The Contractor shall complete all of the following VA TMS training courses:
1. TMS ID 3878248 - IBM Rational Team Concert - Agile Sprint, Configuration/Change Management Level 1
2. TMS ID 3878249 - IBM Rational Team Concert - Agile Sprint, Configuration /Change Management Level 2
3. TMS ID 3878250 - IBM Rational DOORS Next Generation - Requirements Management Level 1
4. TMS ID 3897036 - IBM Rational DOORS Next Generation - Requirements Management Level 2
5. TMS ID 3897034 - IBM Rational Quality Manager - Quality Management Level 1
6. TMS ID 3897035 - IBM Rational Quality Manager - Quality Management Level 2
Contractors who have completed these VA training courses within the past 24 months and have furnished certificates will not be required to re-take the training courses.
Deliverable:
Rational Training Certificates.
PRIVACY AND HIPAA TRAINING
The Contractor shall submit TMS training certificates of completion for VA Privacy and Information Security Awareness and Rules of Behavior and Health Insurance Portability and Accountability Act (HIPAA) training, and provide signed copies of the Contractor Rules of Behavior in accordance with Section 9, Training, from Appendix C of the VA Handbook 6500.6, “Contract Security”.
Deliverables:
A. VA Privacy and Information Security Awareness and Rules of Behavior Training Certificate B. Signed Contractor Rules of Behavior C. VA HIPAA certificate of completion.
1.2 MANAGEMENT AND OVERSIGHT STRUCTURE RECOMMENDATIONS
The Contractor shall establish the management and oversight structure necessary to assure the integrated execution of the proof of concept. The Contractor shall coordinate with VHA regarding the setup of the demonstration site at the San Diego VAMC, recommend qualifications for staff members, propose approaches to align and integrate enabling technologies, and recommend administrative and financial components of the system. The Contractor shall, in coordination with VHA, stand up the proof of concept.
The Contractor shall assess the demonstration site. The Contractor shall review the results from the VISN 2 pilot and provide a Report of Lessons Learned from VISN 2 Pilot, which includes recommendations for improving the SUD treatment approach. The Contractor shall use and improve upon the SUD treatment approach in VISN 2 with VA approved improvements and by performing the following tasks:
a. Evaluate Incidence/Prevalence of complex SUD Patients
b. Assess San Diego VAMC Existing Infrastructure and determine need
c. Orient key VAMC personnel to SUD treatment models to include Behavioral Health and Social Work Services leadership and management
d. Develop protocols for VAMC collaboration, using existing SOPs (e.g., local care in the community referrals, treatment of SUD, billing, etc.) as available
e. Coordinate with VHA on VAMC protocol development to address variance for each specific VAMC site
f. Coordinate with Third Party Administrator’s (TPA's) on VAMC protocols
g. Identify local community partners and/or academic medical centers suitable for partnership
h. Assess local community partner infrastructure, including at least 25 bed capability readiness in terms of licensure, facility and staffing, and administrative support
i. Orient local community partner to SUD treatment models
j. Verify support from state and local authorities for the community partnership
k. Coordinate with non-VA social services available within the community to ensure support, including social determinants of health [housing, food insecurity, employment], in collaboration with local VAMC
l. Develop and verify consensus regarding strength of service design, proof of concept timetable and stakeholder interest
m. Assist in preparation and coordination of necessary Memorandum of Understanding (MOUs).
The Contractor shall include these results in a SUD Proof of Concept Management Process and Plan. As part of the SUD Proof of Concept Process and Plan, the Contractor shall detail all the components and services that need to be in place and provide metrics to define when the proof of concept is ready to receive the first patient. The Contractor shall evaluate VHA’s capability to sustain the improvements and scale them over the long term at the designated pilot site.
Deliverables:
A. Report of Lessons Learned from VISN 2 Pilot B. SUD Proof of Concept Management Process and Plan
1.3 MOBILE MEDICAL DIGITAL APPLICATION DEVELOPMENT
The Contractor shall design, develop, test, and evaluate a mobile medical application. The mobile medical application shall be an open source solution (i.e., no license fees, ever) that will enhance the exchange of patient information and improve case management and care coordination for patients. The proof of concept mobile medical application shall use emerging digital services to increase the exchange of patient information while complying with applicable security and privacy controls, consistent with current White House guidance.
VIP DEVELOPMENT LIFECYCLE
AGILE REQUIREMENTS ELABORATION
The Contractor shall complete an initial backlog grooming session, prior to each build, with the VA team to properly understand and elaborate business Agile requirements. The outcome of this session shall be a complete review of, and agreement to, the initial user stories, including user stories added as a result of backlog grooming by decomposing epics into stakeholder needs, business requirements, business rules, requirements visualizations, and user story elaborations.
The Contractor shall:
a. Ensure all epics are included and executed as appropriate within the overall agile backlog grooming effort.
b. Populate the backlog during an initial planning session, identifying all features the team considers relevant to building the product. The backlog serves as the primary source for all program requirements and user stories and the team shall prioritize the contents.
c. Establish initial unit of measurement (e.g. Story Points) as the estimated relative complexity of user stories.
d. Facilitate any stakeholder briefings, meetings, and/or elicitation sessions.
e. Execute requirements reviews with stakeholders and record results of reviews using Rational DOORS Next Generation or JIRA, updating requirements data as a result of the reviews.
f. Identify the development and test environment access that is needed not more than 10 days prior to development start.
g. All Epics, stakeholder needs, visualizations, stories, and other sources of requirements information for functional and non-functional requirements shall be input and maintained in Rational or JIRA. All requirements data is under change control and is fully linked to work items that show traceability to design changes, configurable items, test cases and test results.
BUILD AND DEVELOPMENT
The Contractor shall continuously support the iterative build and development methodology described below in order to complete all epics and user stories identified in the backlog.
All code and associated documentation developed under this effort externally to the MAE shall be uploaded by the Contractor to the MAE no less than weekly.
BUILD PLANNING
The Contractor shall develop a Build Plan prior to the start of the build. The build shall be no longer than three months in duration and shall be made up of individual sprints. Each build shall be fully tested by end users and shall end in a new release candidate. The Contractor shall maintain the program/project backlog, continuously, for each build, in every release and throughout the period of performance within Rational Team Concert or JIRA. All activity scheduled in each build and backlogs shall be captured and have status showing all work items, changes, impediments, and retrospectives. All data and artifacts in Rational Team Concert or JIRA shall be fully linked to requirements data and test data. The Contractor shall develop a System Design Document for the SUD mobile application based on the requirements elaboration and build planning results.
Build planning shall consist of the following:
a. Teams shall review, elaborate, and prioritize the backlog. This backlog grooming shall occur continuously throughout the build to ensure the customer’s highest priorities are being met.
b. Backlog grooming and build planning sessions. Facilitated by the Contractor, sessions shall outline the intent of the build, and are not a formal commitment. The Contractor shall update the resulting Build Plan within Rational Team Concert or JIRA.
c. Identification of the epics and user stories to be completed within the build, the agreement of acceptance criteria of the build, and readiness to begin build.
d. Identification of test environments, acceptance criteria, and Authority to Operate (ATO) requirements.
e. Coordinate and validate MOU’s and Service Level Agreements (SLAs) for partner dependencies that specifically highlight the commitment of partners to associated release.
Deliverables:
A. Build Plan B. Systems Design Document C. Build Test Plan.
SPRINT PLANNING
Once the build plan is completed and accepted, the Contractor shall initiate Sprint Planning for the first Sprint of the build. All activity scheduled in each sprint and backlog shall be captured in Rational Team Concert or JIRA and have status showing all work items, changes, impediments, and retrospectives. All data and artifacts in Rational Team Concert or JIRA shall be fully linked to requirements data and test data.
The Contractor shall:
a. Initiate and participate in a Sprint Planning Meeting, at the beginning of each sprint. The Contractor shall update the Sprint Plan in Rational Team Concert or JIRA at the conclusion of the Sprint Planning.
b. Support, coordinate, and provide input for the Sprint Acceptance Criteria in Rational Team Concert or JIRA. The Sprint Acceptance Criteria shall be coordinated and approved for every sprint.
Deliverable:
Sprint Plan.
SPRINT EXECUTION
All activity executed in each sprint and backlog shall be captured and have status showing all work items, changes, risks, issues, impediments, and retrospectives in Rational Team Concert or JIRA. All data and artifacts in Rational Team Concert or JIRA shall be fully linked to requirements data and test data. Using Rational, all project artifacts and source code will be under change and configuration management as specified by the COR using Rational or JIRA.
The Contractor shall:
a. Provide a certified Scrum Master to provide the following functions: facilitate all ceremonies, ensure Rational Team Concert or JIRA is updated daily, enforce scrum framework, track and assist with removing impediments.
b. Develop the features and capabilities as work items in Rational Team Concert or JIRA that were established in the Sprint Plan.
c. Complete sprint development including disciplined testing (unit, functional, regression) and reviews as a continuous process, to avoid finding issues at the end of sprint development.
d. Initiate and conduct daily scrums (typically 15 minutes) to show the team progress, impediments, and daily plans.
e. Update Rational Team Concert or JIRA daily, to include progress on tasks during sprints, blockers, and dependencies.
f. Coordinate and support demonstration of the sprint activities with the project team and Users at the end of each sprint. This is termed a sprint review and shall result in customer acceptance of the sprint.
g. Develop and deliver automated build and automated publishing capabilities to schedule jobs and support continuous integration for every sprint. Automated build tools shall be in compliance with the approved list from the One-VA TRM and code shall be demonstrable and stable enough to be promoted to another environment without issue by evidence of the status of tests and results in the Rational Tools or JIRA.
h. Initiate and facilitate a sprint retrospective at the end of the sprint to capture team performance lessons learned.
i. Deliver Source Code in Rational or JIRA.
The Contractor shall use the Health Adapter framework for data exchange between the apps and any VA systems containing data such as the Veterans Health Information Systems and Technology Architecture (VistA), Computerized Patient Record System (CPRS), Corporate Data Warehouse (CDW), and the VAMF used or updated by the app. VistA, CPRS, CDW, VAMF and Health Adapter specifications shall be provided after award. The Contractor shall use validated data via Representation State Transfer (RESTful) or Simple Object Access Protocol (SOAP) service where available as opposed to directly accessing VA systems. Some RESTful services have been developed for existing apps, others will need to be developed to support the apps supported under this PWS.
The Contractor shall ensure that content developed for each app is expressed in nationally recognized reference and authoritative terminology standards such as, Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT). In apps where data is required to be entered, the Contractor shall require data entry using standardized terms.
App code developed under this PWS shall be released to the open source community with all VA-sensitive information redacted. Since the VA-sensitive information redaction process is required, the Contractor shall develop code in a compartmentalized manner to facilitate redaction activities and maximize the functionality of the redacted code. Coding which is not correctly designed for VA-sensitive information redaction and submission to the open source community shall be considered to be incomplete and require revision by the Contractor. App code to be submitted to the open source community shall be licensed by the Contractor under the Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html).
Deliverables:
A. Source Code and JIRA/Rational Updates B. Sprint Review Reports
TESTING
The Contractor shall adopt agile best practices for integration testing into each agile development sprint and build. The Contractor shall populate their Test Strategy section of the test plan in VA’s implementation of Rational Quality Manager tool or JIRA within 15 days of the initial sprint for each build. The Contractor shall conduct tests (e.g. unit, functional, accessibility, system, reliability, usability, interoperability, regression, security, performance) throughout the development lifecycle (e.g. user story, sprint, build, release) using industry best practices of continuous integration methods and automated regression testing utilities using One-VA TRM approved tools. The Contractor shall conduct testing related to non-functional requirements, (e.g. load, performance, installation, back-out, and rollback).
The Contractor shall provide Test Plan data in the Rational Quality Manager or JIRA following the templates and data requirements appropriate for each test purpose appropriate to each phase of development. The Contractor shall provide test results in the Rational Quality Manager or JIRA; this is the final piece of data that completes the Requirements Traceability Matrix (RTM). VA acceptance will occur through the Rational Quality Manager or JIRA approval process.
The Contractor shall support the security, accessibility, performance, technical standards, architectural compliance, user acceptance, and initial operational capability tests, audits, and reviews. Security scanning is done by multiple methods and is done multiple times throughout the course of a project with methods such as infiltration testing (WASA), code analysis tools (Fortify), etc. Accessibility reviews are performed through a variety of tool based and manual reviews, able to scan web applications and other technologies used for user interfaces. Performance testing is done through load testing and technical analysis of capacity planning data submitted by the project team. Architectural compliance assessments are done through submission of design materials to confirm compliance with allowed enterprise architecture.
The Contractor shall ensure all test and compliance review planning and execution details and their testing and compliance results are entered and maintained in Rational Quality Manager or JIRA and under version control in Rational Team Concert or JIRA. Specifically test management data and artifacts include such items as scripts, configurations, utilities, tools, plans and results. The Contractor shall ensure that results of all assessments of the project performed by the Contractor or by VA offices are consolidated into Rational or JIRA for planning and status reporting.
When a defect is identified during testing, the Contractor shall log it in Rational or JIRA, selecting the appropriate severity level. The Contractor shall support the VA PM for prioritizing the defect in the sprint backlog. Based on a prioritization, the defect could be entered into the current sprint or entered into the backlog.
The Contractor shall ensure Rational or JIRA data is up-to-date on a daily basis so that VA stakeholders can access accurate and timely status.
Deliverables:
A. Test Strategy Data input into Rational or JIRA B. Test Plan and Test Execution Data input into Rational or JIRA C. Requirements Traceability Matrix (RTM) input into Rational or JIRA D. Defect Log input into Rational or JIRA.
USER ACCEPTANCE TESTING AND BUILD DELIVERY
The Contractor shall conduct User Acceptance Testing (UAT) to test the mobile application and web portal solution requirements with up to 10 VA-designated personnel and document results in a User Acceptance Testing report. The Contractor shall create a Build Acceptance Form, for use by UAT personnel during the testing. The build acceptance test form shall be a pass/fail-type form to be used for final user acceptance of the application functionality.
Deliverables:
A. User Acceptance Testing Report B. Build Acceptance Form (Contractor Format)
RELEASE SUPPORT
The VIP release process is conducted during the build and development cycle by one or more assigned Release Agents, who perform frequent, regular reviews of required and appropriately linked product data in Rational or JIRA. The Release Agents provide timely feedback to the product team concerning the status of the product data and the status of the team’s compliance with the VIP release process. The Contractor shall support OI&T’s single VIP Release process.
The POLARIS calendaring process and tool shall be used to track software installations, hardware replacements, system upgrades, patch release and implementation, special works in progress, and other deployment events in the VA production environment. The Contractor shall provide data for populating and updating the POLARIS calendaring process for each release and deployment.
The Contractor shall develop the Deployment and Installation Guide that includes back-out and rollback procedures.
The Contractor shall develop a User Manual that addresses procedural information for the business users on daily operational use of the software.
Deliverable:
Build Release Package
RELEASE TO OPEN SOURCE
All app functionality delivered to meet the requirements of this PWS shall be made available to VA’s open source community, including all app source code.
As a result, the Contractor shall create an open source submission package per app for COR/VA PM submission to the open source code repository for certification. This package shall include:
a. All app source code to be submitted.
b. Automated tests and test data as required by the code repository.
c. M-Code Primary Developers checklist (for M-code only).
d. Technical articles describing the functional goals of the code, the use of the code, and any additional details that may help a user of the package or subsequent developers who may maintain the package. Technical articles shall follow the style of a technical report, with particular focus on providing guidance for future use and maintenance of the code contributed to the open source community.
Deliverable:
Open Source Submission Package.
SUD MOBILE APPLICATION FUNCTIONAL REQUIREMENTS
The Contractor shall develop one nonproprietary application on one platform with both a Veteran/Caregiver (patient generated data) view and a Clinical (custom data view in patient viewer) view. The Contractor shall follow the Lifecycle described in Section 5.3.1, including all subparagraphs, of this PWS, for each of the specific functional requirements described below.
The SUD mobile application shall record, assess, and track progress for patient-centric digital therapy practices. The application shall provide Veteran patients, caregivers, case workers, and providers, the capability to log and analyze medical encounters, clinical observations, self-reported inventories, and health records. The Contractor shall develop tools and services within the application to enhance traditional SUD clinical treatment programs. The application platform shall include tools to assist in the management of substance use or mental health disorders. The SUD mobile application shall include the following capabilities:
a. Log, track, and review various time-based medical events, user records, and observations.
b. Provide customized, specific data entry options, such as a medication…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it.