DRAFT Open Source Policy

Size: px
Start display at page:

Download "DRAFT Open Source Policy"

Transcription

1 DRAFT Open Source Policy Comments on Performance Work Statement (PWS) for VA I-0558, Transformation Twenty-One Total Technology (T4) Next Generation (NG) Program dated July 28, 2014 Date: Tuesday 26 August, 2014 To: From: Subject: OSEHRA Community Members OSEHRA Open Source Policy Comments Ad Hoc Work Group Optional Comments for Open Source Policy Response to VA Background Re: SECTION C - DESCRIPTION/SPECIFICATIONS/STATEMENT OF WORK, Page 7, Item QQ. Within the VA s Transformation Twenty-One Total Technology (T4) Next Generation (NG) Request for Information, the referenced item (from document VA I-0558 VA I-0558) cites the Open Source Policy as (TBD). The VA s open source policy is likely to have a significant impact on the activities planned under the subject contract. As such, OSEHRA established an ad hoc Work Group of members to generate a draft open source policy. The OSEHRA Open Source Policy Comments Ad Hoc Work Group approach to developing these comments included the following considerations: Orientation as an acquisition-related policy Make it simple to adopt Avoid being too prescriptive Reference new and emerging policies Action It is expected the VA will provide an opportunity to review its draft policy before it is finalized. OSEHRA members are encouraged to incorporate the OSEHRA Open Source Policy Comments Ad Hoc Work Group language into their submission, using the material provided here. Members are also encouraged to incorporate their own views and perspectives in their submission. This policy represents an important opportunity for members to advocate for open source. Therefore, it is important to have as many responses as possible submitted to the VA.

2 Draft Policy The Work Group recommends an open source policy address the following issues: 1.0 Open Source Software (OSS) Definition 1.1 Open source software (OSS) is computer software for which the source code is accompanied by a license under which the author allows others to view that code, copy it, learn from it, alter it, and share it. Open source software licenses promote collaboration and sharing because they allow entities other than the author to modify the source code, incorporate those changes into their own projects, and share them with the community. 1.2 The Department of Veterans Affairs intends to release software developed under T4NG and other designated contracts to the public in accordance with the Freedom of Information Act (FOIA) so as to permit open source licensing of the software and derivative works. Contractors shall not include any code in their software deliverables, either developed by themselves or by others, that would impede the government s ability to place the source code in the public domain via FOIA. 2.0 Open Source and Commercial Off The Shelf (COTS) VA considers open source software a commercial off-the-shelf (COTS) product as defined by Title 41 Public Contracts, Chapter 7 Office of Federal Procurement Policy, Section 403 Definitions, Item (12); and Section 431: (c) Commercially available off-the-shelf item. 3.0 Open Source Software Quality Certification 3.1 Any code delivered to VA must be certified at Level 3 or higher of the Open Source Electronic Health Record Alliance (OSEHRA) Open Source Software Quality Certification Standard ( OSEHRA Certification ). This certification establishes a baseline of quality, completeness, and usability for code offered to VA. There are four possible levels of OSEHRA Certification based upon measurements in eight independent categories of certification criteria, one of which is Apache 2.0 licensing for the entire code submission. The outcome of certification scoring will be either a certification failure, or OSEHRA Certification at one of the four levels. 3.2 OSEHRA certification is not intended to replace user testing, verification and validation, or other pre-production and production testing processes carried out by VA or any other community member. Rather, OSEHRA certification is focused on evaluating the usability and quality of open source software in order to minimize implementation risks. A complete description of OSEHRA Certification can be found at:

3 4.0 Open Source Collaboration and Agile Development 4.1 Open source development is compatible with Agile development. VA will implement the following language from the Draft TechFAR issued by the White House on August 11, 2014, updated to reflect VA as the Agency : 4.2 The contractor will work in a team-based Agile environment. The Agency will create and maintain system roadmaps, project plans, and product and release backlogs that will be the basis for the contractor s work. The Product Owner will specify high-level requirements to the Agile team. As in typical Scrum-based Agile processes, the Agency Product Owner will work together with the team to develop and estimate user stories and establish acceptance criteria. These acceptance criteria will specify expected functionality for a user story, as well as any nonfunctional requirements that must be met in the development of the story. The Agency Product Owner, supported by SMEs and business analysts, will determine whether or not acceptance criteria have been satisfied. 4.3 Utilize industry best practices for agile development in achieving the objectives of this PWS. Agile best practices shall include, at a minimum, Common Coding Guidelines, Code Refactoring, Code Regression Testing, Continuous Integration, Test Driven Development, and Active Stakeholder participation. The Contractor shall obtain Government approval from the COR prior to using the HMP System, Patient and Team Facing code from OSEHRA as the baseline code for this development effort. 4.4 With the redaction process in mind, which may be necessary to redact Personally Identifiable Information, the Contractor shall ensure that code is developed in a compartmentalized manner to facilitate redaction activities and maximize the functionality of the redacted code. Coding which is not correctly designed for redaction and submission to the open source community shall be considered to be incomplete and require revision by the Contractor under the terms of this contract. All code, software and software artifacts delivered under this Task Order are hereby licensed to the Government under the terms and conditions of an open-source software Apache 2 license. Code to be submitted to the open source community shall be licensed by the Contractor under the Apache License, Version 2.0 ( 4.5 The Contractor shall update the RSD to capture technical requirements so that immunization software solutions address the modernization and enhancement contributions of OSEHRA and Open Source standards that facilitate achievement of IOC. This solution will fully support open-source software requirements as part of Open Source Electronic Health Record Agent (OSEHRA).

4 5.0 Redaction of VistA Code-Base 5.1 To comply with FOIA, VA releases VistA software packages, modules, and patches on a recurring basis after removing proprietary code or any nonproprietary code that impacts security, privacy, or confidentiality. Contractors who are developing new VistA software shall follow VA Standards and Conventions as well as industry best practices to ensure that any sensitive information is adequately parameterized to allow easy removal (and insertion of placeholder information) with minimal impact on the executable code. Where appropriate, contractors should also develop / employ automated redaction tools so that redaction at the time of FOIA release can be done automatically and reliably. 5.2 The policy governing redaction has not been refreshed to the industry approach to either Agile or what is really proprietary. Suggest the following to be consistent with open source policy: Contractors who are developing new VistA software shall follow VA Standards and Conventions as well as industry best practices to ensure that any sensitive information is adequately parameterized to allow easy removal (and insertion of placeholder information) with minimal impact on the executable code. Where appropriate, contractors should also develop / employ automated redaction tools so that redaction at the time of FOIA release can be done automatically and reliably. Government will consider the formation of a workgroup, engaging Industry, including Open Source, to evaluate the existing current redaction policy and to hear the impact that some redaction actions has, including non-usable software. 6.0 Evaluation of Total Cost of Ownership (TCO) of Software When acquiring software, whether the code is open source or proprietary, VA shall conduct an analysis of the total cost of ownership (TCO). The TCO analysis process for proprietary software is well established. The following cost or savings factors will be included in all analyses to ensure accurate overall evaluation among proposed open source and proprietary solutions: Reduction in vendor lock-in Ability to experiment or innovate Access to knowledge and skills Building business agility Support of incremental developments of solutions Ability to develop collaboratively with the open source community

5 Access to wider community-based support services Ability for additional testing by the community Improved adoption by the users Access to the code and documents Ability to modify the code Ability to change support services Cost of upgrades Response submission site and deadline All responses shall be submitted electronically no later than 3:00pm EST on August 28, 2014 via Virtual Office of Acquisition (VOA), The use of hyperlinks or embedded attachments in responses is prohibited. The OSEHRA Open Source Policy Comments Ad Hoc Work Group would appreciate receiving copies of member submissions. Additional comments and/or communication should be directed to Kris Prendergast at