Abstracted from the Government s Q&As document released on April 22, 2011 and the follow-on Q&As released on April 29, 2011.

Transcription

1 Abstracted from the Government s Q&As document released on April 22, 2011 and the follow-on Q&As released on April 29, Editor s Note: As a part of the RFP process dealing with establishing a Custodial Agent, the VA provided answers to 217 questions submitted by the interested parties. Here we have reproduced those questions and answers that discuss the operation of the CA, eliminating those that focused on the RFP process. We have also updated some of the answers if newer information was available. Section references refer to the original RFP. The original list of Q&As can be found at FedBizOpps.gov: Question #1: Some of the tasks described in the PWS sound like responsibilities of the FOIA office. Is it VA s intent to replace the FOIA office with the Open Source CA? Answer: The Custodial Agent does not replace the VA FOIA office. VA will continue to service FOIA requests. We believe, however, that the CA will provide a convenient mechanism for accessing the open source EHR software. Question #2: If the intent of the Department is not to replace the FOIA office, what relationship will the FOIA office have with the Open Source CA? Please define. Answer: There is no relationship between the VA FOIA office and the CA. They are separate, independent entities. Question #3: How often will VA provide the CA VistA patches for approval and certification into the base code? How quickly does VA expect the patch to be incorporated into the base code? Answer: Anyone, user or developer, who implements a patch or other modification to code from the CA codebase can (and hopefully will) submit the modification to the CA for certification and inclusion in the codebase. There is no fixed schedule for submission of patches. The turnaround time for certification and inclusion into the codebase shall be managed by the CA. Question #9: Further, if VA intends to include interoperability certification as listed in the draft is the Open Source CA envisioned to provide similar services as CCHIT? Answer: Certification of interoperability in this context is intended to mean the ability for code that is not part of the code base to work together with the codebase. CCHIT certification includes a form of interoperability testing, so in this sense, the CA provides a similar service. However, much of CCHIT s certification involves factors that are not the domain of the CA, such as certification of meaningful use. Interoperability is also listed as criteria for certification of code that is contributed to the code base. In this case, it refers to the ability for the contributed code to work with the rest of the code in the code base. Question #12: VA might initiate a project request to the CA for codebase refactoring... (pg 20-21). Does this statement put the awarded contractor into conflict of interest if it also

2 provides development services for VA under other contracts? Answer: The activities of the Custodial Agent won t preclude the successful Offeror from participating on any new development efforts conducted in VA unless a potential conflict results if the Offeror is involved in the development of requirements, tasks or technical details specifically related to the development effort or proposed acquisition in question. Question #13: RFP states: Five crucial objectives: It will unleash EHR Innovations. ; It will release VA s captive dependency on any particular component or service and give clinicians access to the best available tools and solutions; It will reduce the costs and risks of reliable implementation (and integration) of new functional modules that improve VistA s capabilities; It will measurably improve health outcomes for our nation s Veterans; and It will enable other providers in the public and private health care system to benefit from, contribute to and interoperate with this national asset. Please explain how certification of proprietary software aligns with these goals. Answer: In order to assemble the best EHR solution for its needs, a user (including VA) may choose to implement some functions using proprietary software. By providing the ability for such software to be certified as interoperable with the open source EHR software, the CA assists users in creating and maintaining implementations that best serve their needs. Question #15: Refactoring projects. What are VA s timelines around submitting new refactored code to the CA for certification and approval? How does VA propose to keep the EHR Open Source codebase as current as possible with VA s code base? Answer: Without discussing timelines for work that is not yet undertaken, VA intends to engage the open source community in all of its EHR development. This may take several forms: code developed by VA may be contributed to the codebase, code developed under VA contract may be contributed to the codebase, code developed by others and contributed to the codebase may be used by VA, etc. To the greatest extent possible, these actions will result in a close correlation between the EHR Open Source codebase and VA s EHR implementation. Question #20: RFP states: Licenses will be irrevocable. Please clarify how VA proposes a community member be held accountable to licensing terms if a license cannot be revoked. Answer: This statement is intended to prevent open source licenses from being revoked when no violation of license terms has occurred. Question #22: Within one (1) day following the activation of the CA, the Contractor shall receive code from VA consisting of the initial contribution of VistA code Please define what code exactly will be provided to the CA - as the VHA s internal rules and practices, as well as proprietary code, security related routines, and financial information are not current released outside the VA firewall. So what code (FOIA, Gold, other) will be provided? Answer: VA intends to provide the FOIA code, which includes all code that is not proprietary or restricted for security or privacy reasons. Question #31: Please confirm that VA expects the entire Open Source ecosystem, which includes hardware, testing environment, certification environment, certified code base

3 environment and community website, will not involve government equipment or VA networks. Answer: Confirmed. Question #49: What is the role of the CA after approval and throughout the implementation of a capability? Answer: Members of the community are always free to develop new capabilities. Some may be proposed to the CA as sponsored projects; in this case the implementation of an approved project is the responsibility of the project lead. When the new capability is developed, the code may be contributed to the codebase. The CA provides the certification required to accept the code into the codebase. Depending on the nature of the function, the CA may update architecture documentation and product definition documentation. Other CA functions include governance, establishing licensure, establishing the code repository, performing certification, managing the open source architecture, managing open source change requests, product definition, and launching the community website. Question #53: Will the custodial agent be required to obtain product EHR certification from HHS? This is not addressed in the RFP. Answer: No, this is not a requirement. Question #54: Will the custodial agent be required to participate in IHE connect-a-thons and be IHE compliant? This is not addressed in the RFP. Answer: No, this is not a requirement. Question #56: Is VA's intent to fold the private sector efforts together under the Custodial Authority, or to use the CA as a mechanism for incorporating their improvements in VA's VistA? Answer: VA views the CA as an independent entity that enables the formation and operation of an active EHR open source community. We foresee the community beginning with the current VistA code and evolving and improving it over time. VA intends to be an active community member and a user of the open source codebase maintained by the CA. Question #57: Will the code under the CA's aegis be the canonical version of VA VistA, or will VA's VistA exist as a downstream consumer of the CA's work product? Answer: VA will contribute the current FOIA version of VistA as the initial code contribution in the establishment of the CA. Thereafter, the CA will manage the evolving EHR open source codebase and VA intends to be both a contributor to, and a consumer of the CA s work product. Question #60: Will the CA be responsible for tracking the intellectual rights (patents, copyright, etc.), or will that work be performed by another VA entity?

4 Answer: The CA is not intended to own or track intellectual property. Question #61: Does VA envision the CA as an organization that directs development efforts, a certification authority that creates consensus amongst the various VistA interests, or both? Answer: The CA is intended to be an independent, central body that fosters the creation and evolution of an open source EHR community. In this role, it defines and performs certification and manages the code repository that provides access to the codebase. It provides the forum for maintaining and communicating architecture, product definition, and other aspects of the codebase, as well as other functions that help to build and sustain the community. Helping the community achieve consensus among members should be part of the execution of CA responsibilities. Question #62: In typical open source ecosystems, the task of building a sustainable business is often distinct from the task of building a sustainable community. Has VA considered divesting the CA of its responsibility to sustain itself commercially? Answer: The CA must sustain its operations and the contractor must propose a business plan that demonstrates how this is achieved as part their proposal submission. VA does not have a preference as to whether this includes commercial revenue or other sources of funding. Question #63: What mechanisms are in place to encourage internal adoption of the CA's services within VA? Answer: VA is strongly committed to the open source model and will have appropriate processes in place to work with the CA as both a user and a developer. Question #64: Should the CA be unable to fund itself after one year, what contingency funding plans are in place? Answer: VA expects that the awarded company will develop a business model for the CA that requires less VA financial support after the first year, drawing support (including financial support) from the community in ways that still need to be determined and evaluated. VA will evaluate appropriate contracting vehicles for carrying out the appropriate level of involvement after year 1. As presently contemplated VA expects the CA to be established with a legal structure that can survive beyond the base contract period. Question #67: Free interaction between VA IT staff and VA users is essential for the success of this project. After the initial provision of software to the CA, the only interaction between VA and the CA is meetings to report on progress, someone to contribute to the governance and a mechanism for VA to have VA award contracts that the CA agrees to from within VA. Provisions to allow open communication with the users and developers within VA is not mentioned and it is key to making this CA successful for VA. I understand that VA may be concerned that it will be inundated with communications from outside of VA so I would suggest that the CA moderate communications between the community and VA so that optimal communication can occur, both to value the time constraints on key developers and users (both in as well as out of VA) as well as insure that timely communication is occurring. Answer: In addition to the interactions outlined in the question, VA participates as a

5 community member, both as a developer and a user. We expect and encourage communication among all community members, including VA. Question #69: Having everything pre-written and predetermined will not allow for the free communication with the CA by others who have a significant interest in the project. They need to have an opportunity to help to help shape the governance and architecture of the CA so it can best work with the VistA community. The open source VistA community of users and developers is not likely to be those who have the resources to respond to the RFP and win it, yet they are the ones with the most interest and capability to help the CA succeed. They should be consulted. Also individual developers and users need to be able to have input and doing so before the CA is chosen will be almost impossible. This needs to include input from VA users and developers. Answer: VA anticipates that the open source ecosystem will continually evolve and over time become a community effort, and the projected CA contract constitutes the first steps in that direction. Based on feedback VA has received concerning the timeline for the CA, we will update the timeline in the final RFP. We believe that entities that have experience with open source software should be able to develop the required deliverables on the required timeline. VA intends the CA to enable open communication and collaborative engagement to the greatest extent possible. Question #71: VA needs to make a good faith effort to provide the current documentation for the architecture, interfaces, etc. as the initial description of the architecture that can then be modified as the CA evolves. That documentation has not all been freely available. The process of gathering the documentation, organizing it and making it available on the Internet will be a considerable task on its own. The suggestion that the CA needs to figure out what documentation to ask for and go through usual channels to get it is not in keeping with the spirit of this project nor its time-line. Equally, asking the CA to establish the architecture immediately is not going to be practical. What the CA can do is to evolve in a suitable direction in consultation with the community, not by imposition. Answer: VA will work with the CA contractor on initial documentation, architecture descriptions, etc. It is VA s intent to assist the CA to the greatest extent possible. It is also VA s hope that the community may be engaged as early and as often as possible. Question #72: Governance of non-profits may already be established if they are allowed to bid on a contract. As such, the requirement that VA have one seat of 3 needs to be clarified as to what it is one seat of. The Custodial Agent Governing Board does not make it clear as to the role of the BOD and officers of the existing 501(c)3 regarding the CA contract and if there is a conflict between the OBD of the nonprofit and the CA Governing Board how that can be resolved. Perhaps the only choice would be for an existing 501(c)3 to set up another 501(c)3. Answer: VA s intent is that the CA be governed by a board made up of 3 members, and that the board be responsible for setting the direction for the CA and overseeing its operation. One of the 3 board members is selected by VA to make clear VA s commitment to the success of the CA and the open source community it enables. The draft RFP nor the final RFP as intended does not prohibit a non-profit organization from submitting a proposal, as long as they are a qualified GSA Federal Supply Schedule 70 contract holder.

6 Question #79: Unless there is a provision for charging for the costs of certification of proprietary software or the CA is allowed to choose what software it is going to certify, the costs and demands for certification of software will likely be prohibitive. The demand is likely to be very high as products seek to be considered for adoption by VA. Charging for certification of proprietary products perhaps based on the size of the company requesting it will help provide initial sustainability for the CA independent of VA funding. Answer: The CA contractor will devise a certification capability and a business plan that will sustain itself, with a financial contribution from VA that declines over time. The CA contractor s business model submission may well include charging certification fees as part of that business model. Question #85: There is no provision for effective cooperative work between VA and this open source entity. The largest group of developers for VistA exists within VA and yet there is nothing that addresses the issue of how VA developers and users can interact with this entity except through a contracting approval-disapproval process. This is not an open source ecosystem being developed between VA and the outside community. At the very least, VA developers should be encouraged to participate on the Hardhats mailing list and feel free to provide some of their posts to OpenForum and/or those working with the CA could be invited to be part of Open Forum and provide filtered content to the VistA Community outside of VA. Answer: VA employees will participate in the open source community. There are many ways in which they can contribute to a vibrant ecosystem. Question #87: The ease of testing the software will only be improved through the proper refactoring of the code base which is something that will take time and coordination. VA continuing to provide contracts to re-factor code and then handing it back to the CA without ongoing CA involvement is pointless. It will only perpetuate the problems that now exist that contribute significantly to the failure of software projects. Answer: VA believes that an open source ecosystem enabled by the CA provides an environment in which an open and transparent refactoring process can be carried out. Question #88: The refactoring process needs to be transparent and at least well supervised by package experts with extensive knowledge and experience with the VistA packages and at best done by permanent teams of users and developers who will be continuously improve and re-factor the code in the packages and bring new people into the team to gain the expertise needed. These teams need to be able to work seamlessly across the government-private sector barrier. It does not seem possible in the current environment of government regulation. VA needs to brief those bidding on the contract as to what will and will not be allowed in terms of interaction with government employees and processes so that the CA does not come into existence expecting open cooperation and then finding out there is little to none. Answer: VA believes that an open source ecosystem enabled by the CA provides an environment in which an open and transparent refactoring process can be carried out and in which many members of the community may play a role. VA employees are free to participate in the open source community. There are many ways in which they can contribute

7 to a vibrant ecosystem. Question #91: Users are the driving force behind the development of requirement and improvements to the software. Support from and for users in the form helping to decide what software development has priority, usability testing, use case development, template repository, etc., mailing lists, needs to be included in the proposal. The users from within VA need to be encouraged to become involved with the CA in this process. Answer: Users across the full breadth of the community will be encouraged to participate. Question #92: No training is provided for implementers. Without more implementers there will be fewer users and less support for the software. The open source software users will drive the sustainability of this organization independent of VA because of their demand for software improvements. Otherwise this CA may be nothing more than an outside agency to support the testing of proprietary software for use by VA with little open source. Answer: VA envisions an active EHR open source community as the best way to produce and support more implementers. Question #101: Custodial Authority? Is this the right term and does it even communicate the right impression. If VA intends to provide seed funding to create an Open Source Community to design and develop a world class, state of the art system to support a large network of medical centers, out patient clinics, and veteran patients, another term might be more appropriate. It certainly suggests an inappropriate image of what needs to be done. Answer: As discussed above, VA does not plan on providing seed funding to establish the EHR Open Source ecosystem, and VA believes that the term captures the spirit of an entity that has custody, but not ownership of the VistA software and acts on behalf of the community by providing open source software code. Question #104: Page 20 Code base refactoring. VA might initiate a project request to the CA for codebase refactoring. We think this is a very good idea and should be started at once. Maybe VA should start several such projects to see which one comes up with the best design and process. Rather than VA prescribing this process, it should instead describe the need and ask how it might be handled by the Open Source community and the Custodial Agent. Answer: VA agrees that refactoring is an important undertaking and one that should involve the CA and the open source community. There are many ways to approach the task. Having VA initiate a single project is one idea. The best approach can be better determined when the CA is active and the community is forming. Question #105: Page 29 Section 5.11 Open Source Product Definition. There is a natural conflict between a meritocracy and a benevolent dictator. The CA has to walk a very fine line between these two positions. Ideally the CA will define a process that allows for efficient decision making in a sufficiently timely fashion without actually dictating a solution. This is hard, complex, and unscientific. This paragraph describes how product management (aka product roadmap) needs to be accomplished. It will be a delicate process to design, implement and optimize. Answer: VA envisions the initial product definition task as one that captures and communicates a description of the product consisting of the initial VA code contribution.

8 Subsequently, VA envisions product definition to be the organization of code updates into releases that provide structure for the user community. Question #108: Page 20, Codebase Modernization--What is VA s process going to be to contract a vendor for design of the refactoring task? Answer: VA believes that refactoring is an important undertaking and one that should involve the CA and the open source community as part of the CA Bylaws and Operating Terms required by PWS paragraph 5.2. There are many ways to approach the task. Having VA initiate a single project is one idea. The best approach can be better determined when the CA is active and the community is forming. Question #110: Page 27, Section Is the Custodial Agent authorized to contract external resources to perform certification? Answer: Yes. Question #111: Page 13, Section Accelerated Rate of Innovation - If the goals are to address fundamental structural constraints, how is the CA to account for the structural constraints? Answer: VA believes that the CA will enable an ecosystem to develop around the open source EHR, allowing many community members, including VA, to actively advance the EHR. The CA does not need to address VA structural constraints; enabling a robust community to evolve will accelerate innovation beyond any constraints. Question #112: What impact does VA anticipate the current infrastructure (Data Centers, VITALS, WAN latency, etc.) initiatives will have on CA? Answer: VA does not believe that internal VA infrastructure will impact the CA. Question #113: One of the goals is, it will unleash EHR innovation inside and outside VA, since it s a known issue of the process to evaluate, approve and deploy Class III to Class I products, how is the CA to account for those current processes without VA releasing current specifics on the process? Answer: The CA does not need to account for VA internal processes. The CA should focus on developing the community around the open source EHR, with VA as a community member. VA will adapt its processes to accept innovations delivered via the open source codebase maintained by the CA. Question #131: How does VA envision involvement from VA functional communities (e.g., clinicians) in this initiative? Answer: VA will play a role in the governance of the CA and it is likely that VA employees will be involved in various committees and working groups organized by the CA. VA employees will also participate as contributing members in the community. VA believes this will provide ample opportunity for clinicians and others to be engaged in the ecosystem. Question #137: Will the various internal VA development communities continue their own internal software modernization, integration, and maintenance efforts? Will all internal

9 modernization and integration efforts be required to follow the guidelines and bylaws of the custodial agent? What authority does the CA have in the integration tasks with the VistA at the sites? Answer: VA will maintain internal integration, testing, and maintenance efforts to support our production use of EHR software, as any user must. VA intends, to the greatest extent possible, that our EHR software development and modernization be performed such that the resulting software can be contributed to the CA for inclusion in the codebase in accordance with the guidelines and bylaws of the CA. The CA will have no authority over the internal operations of any of the users in the community. Question #144: Reference Section 1.1 Goals: Has VA developed and documented a migration plan for VistA? What software components (functionality) does VA plan to retain? What is the prioritized sequence for modernizing functionality within VistA? Answer: VA plans to make open source software development its predominant methodology for the advancement and maintenance of its EHR software. For any user in the community, standardization or migration across facilities is an internal function managed by the user and not within the domain of the CA. However, VA will provide the FOIA version of VistA as an initial code contribution towards the establishment of a CA, and will contribute any modernization of functionality as any user or contributor of the CA would, for the purpose of creating and fostering the evolution of an open source EHR community in which making open source software development is its predominant methodology. As the needs and requirements of VA and other EHR users evolve, the CA will be central to organizing the open source community participation in that effort, and will be the preferred method of modernizing functionality within VistA. Question #146: Reference Section 1.1, Goals: How will VA foster adoption, acceptance, and adherence of the open source business model within VA community (internal vs. external)? Answer: VA plans to make open source software development its predominant methodology for the advancement and maintenance of its EHR software. VA hopes that many other community members will adopt a similar approach. The CA is key to enabling the growth of the community and fostering the adoption of open source methodologies. Question #147: Reference Section 1.1, Goals: Understanding that there are several public organizations already supporting and promoting VistA. These communities were established to extend and through collaboration improve the VistA electronic health record and health information for use in its veteran s hospitals, outpatient clinics, and nursing homes. How is the non-governmental custodian the open source business model different than the organizations already in place? Answer: VA believes that an open, collaborative community developed around the CA will provide the means for all users, including VA, to share a common codebase and benefit from the developments and improvements made by any member of the community. VA hopes that existing organizations currently supporting and promoting VistA will become active members of the community and continue to contribute towards its enhancement. Question #149: Reference Section Accelerated Rate of Innovation (page 13 of 60). How

10 will VA ensure the modernization is achieved in a structured, deliberate, and predictable manner? Given the independent modernization and customization of the VistA system at each VA community, how will VA ensure VistA components/enhancements interoperate correctly? Who is responsible for insuring interoperability of the VistA within these environments? Is it the Governments intent to continue software enhancements at the local community level? What role does the CA play in the site-level component integration process? Answer: The CA establishes and fosters the growth of the community and manages the common open source EHR codebase via the functions described in the draft RFP. The CA does not take on the responsibility of any user, including VA, to ensure that its EHR implementation operates correctly within the user s production environment; it is the user s responsibility to make sure that this implementation is production ready in that user s environment. The CA certifies that code contributed to the codebase meets the requirements established by the CA; but a user may implement its EHR using code from the codebase and other software developed internally or obtained externally, including proprietary software. Question #152: Reference Section 1.2 The EHR Open Source Ecosystem. Is VA proposing to standardize the VistA platform at the all VA facilities? What role does the CA plan in managing the continue code proliferation and customization of the VistA environment at the local site level? Answer: As with any user in the community, standardization across facilities is an internal function managed by the user and not the domain of the CA. The establishment of a common open source EHR codebase, and an active community to manage its evolution, provides an evolutionary foundation upon which internal standardization or customization may be implemented, but this is an internal user function and not within the purview of the CA. Question #153: Reference Section 1.2 The EHR Open Source Ecosystem. Does the government have a specific preference for how code conflicts will be resolved within the EHR Open Source Ecosystem? Answer: VA will not specify the manner in which code conflicts will be resolved within the EHR Ecosystem. When necessary, the CA, with community contribution and innovation, will resolve code conflicts within the open source EHR codebase to community standards. Question #157: Reference 1.2 The EHR Open Source Ecosystem (page 20 of 60). States software and technology that is not intended to reside in the codebase but interacts with the Open Source EHR or provides complementary functions may be certified to demonstrate interoperability. Will the CA have discretionary funding certification and interoperability testing of contributions that are not part of the codebase? Answer: The CA is responsible for establishing certification criteria and for performing certification. VA expects that the awardee will develop a business model for the CA that requires less VA financial support after the first year, drawing support (including financial support) from the community in ways that still need to be determined and evaluated. VA will evaluate appropriate contracting vehicles for carrying out the appropriate level of involvement after year 1. As presently contemplated VA expects the CA to be established with a legal structure that can survive beyond the base contract period.

11 Question #158: Reference 1.2 The EHR Open Source Ecosystem, Code Modernization (page 20 of 60). What is the decision authority of the CA? Does the CA have the authority to reject VA- proposed modernization or refactoring projects? Answer: The CA has authority to accept or reject proposals from any member of the community, including those from VA. All community members, including VA, may pursue any derivative project without involvement or approval of the CA and may submit resulting software to the CA for acceptance into the codebase. Question #159: Reference 1.2, The EHR Open Source Ecosystem, Code Modernization (page 20 of 60). How do the CA and the code modernization efforts fit into the overall migration plan for VistA? Is there a prioritized plan of enhancements in support of the migration plan? How will the CA (and VA) make the determination for code modernization vs. maintenance? Answer: The CA manages code contributed by the community and establishes processes that make it easier for community members to use, enhance, and maintain the code. VA will maintain internal integration, testing, and maintenance efforts to support our production use of EHR software, as any user must. VA intends, to the greatest extent possible, that our EHR software development and modernization be performed such that the resulting software can be contributed to the CA for inclusion in the codebase in accordance with the guidelines and bylaws of the CA. The CA will have no authority over the internal operations of any of the users in the community. Question #160: Reference 1.2, The EHR Open Source Ecosystem, Code Modernization (page 20 of 60). What is VA s approach for maintenance for the VistA modernization efforts and open source initiative? Will the CA be responsible for providing maintenance support resources for the EHR Open Source Ecosystem? Answer: While the CA should evolve to provide functions that the community requests, VA does not expect that the CA itself provides maintenance. The CA should facilitate the process of maintaining the open source software in the codebase. For example, while CA resources might not develop code fixes, the CA might collect and communicate bug reports and provide expedited certification of code contributed to fix bugs. Question #166: What role or responsibility will VA have in building a community of developers? For example, will the current VistA developers be available to attend open source events and make speeches where appropriate? Answer: VA will participate as a member of the community in both user and developer roles. VA employees may participate in community events. Question #172: Section 5.8, Establish Certification Function. What is the extent of the certification program? For example, would integration tests with other VA systems need to be performed prior to certification? Answer: Code intended for inclusion in the codebase will be certified to ensure that it provides the intended function and operates properly with all supported components and in all intended environments; the specific elements of this certification will be at the discretion

12 of the CA Contractor, and the CA Contractor may propose additional requirements as part of the certification definition. Code that is not part of the codebase but works with the codebase will be certified that it is interoperable with the codebase. Integration tests with the systems of any user, including VA, are not including in the certification. Question #173: Section 5.9, Manage EHR Open Source Architecture. Does the government expect the CA to coordinate with other VistA stakeholders at VA with when/if proposed changes to the codebase/architecture suggest an impact to interfaces to or processes involves with other systems? Answer: The CA is the vehicle by which all community members interact for discussion, coordination, and communication of proposed changes and improvements. As a community member, VA will participate in those activities in the same manner as any other community member. Question #178: Section 6.3, Performance Metrics: Who is responsible for soliciting code contributions? What role will VA play in engaging industry participation in this effort? Answer: Active participation by community members should result in code contributions. Although VA does not contemplate specific code contribution solicitation, the CA may solicit specific contributions when specific functions, improvements, or fixes are desired by the community. VA intends to be an active participating community member. Question #188: Will non-proprietary codeset data such as the National Drug File and VUID database be included in VA's initial contribution (page 27)? If so, will all such data necessary for VistA to be fully operational be included? Answer: VA intends to provide the FOIA code, which includes all code that is not proprietary or restricted for security or privacy reasons. Further, VA may provide associated supporting files and documentation. Question #189: Will the database of past VistA patches be included in the initial contribution (page 27) so that non-va sites that are behind in patching have a chance to get current? Answer: VA intends that its initial code contribution will be current. Question #190: In addition to the code, does VA intend to supply the current architecture and design documents? Answer: VA intends to provide to the CA the material necessary to facilitate documentation of the initial architecture. Question #191: In addition to the code, does VA intend to supply the tools, methodologies, and documentation it has been using to test VistA software? Answer: Taking VA internal operations as a starting point and seeking to duplicate them is unlikely to be the best way to establish the CA. The needs of a user test organization are substantially different from the needs of an entity certifying open source software for acceptance into the codebase, for example. VA (and hopefully many others in the

13 community) will, however, provide assistance to the CA in developing the certification implementation and we will provide any materials that can be helpful, wherever possible. Question #196: Also on the subject of the re-factored code, does VA mean MUMPS code that is rewritten as new and superior MUMPS code (the actual definition of refactoring, to rewrite in place to improve the software engineering), or is VA using re-factored as a euphemism for replacement? Answer: Re-factored is not a euphemism for replacement. Refactoring and code modernization should be done in ways that best meet the needs of the community. Question #199: To what extent will individual VistA developers within VA be allowed to contribute their knowledge and opinions to the open-source community? Answer: VA will participate in the community as both a user and a developer and its employees will participate in this activity. Question #200: To what extent will individual VistA users within VA be allowed to share their expertise and opinions with the open-source community? Answer: VA will participate in the community as both a user and a developer and its employees will participate in this activity. Question #201: Who will be responsible for the training of new VistA adopters? Does VA anticipate that the community will take on this role, or will individual adopters need to find their own resources? Answer: VA expects that the community will include those who wish to provide training and other services to new adopters. Question #202: Who will be responsible for the training of new VistA developers? Can the CA use any of the financial resources in this RFP to launch training programs? Answer: The CA has responsibility to foster community development and training is part of this effort. The CA may choose to engage directly in training or may seek to find community members who provide training.