VistA Open Community Proposal v.2

[fred trotter]

Here is the next version. The biggest changes are to move from having a VistA-community person to a VistA-community process....

Thoughts?

add them here please.

http://libertyhsf.org/index.php/ovcp

 This is the version .2 of the VistA Open Community Proposal that the LibertyHSF will present on behalf of the VistA community to the VA regarding a new era of openness and collaboration around the VA VistA-based software.

• Create a process for creating with the VistA community outside the VA. This process should recognize the following operating principles
  
  • Formally acknowledge that the VistA community outside the VA can benefit Veterans by contributing improvements to VistA back to the VA.
  • Formally acknowledge that the VistA community outside the VA can provide better care to Veterans in private hospitals and clinics that are VistA enabled. Many Veterans do not qualify for treatment at VA hospitals but can still benefit from VistA.
  • The VA should prefer Open Source Software in its software acquisition process. This enables VistA users outside the VA to follow the VA in software decisions and allows the community to further enhance VA software by making their improvements available to the VA.
  • Create a default open stance to FOIA requests. Create a process that not only completes FOIA requests for software source code resources, but provides a feedback mechanism to ensure that the FOIA releases are complete.
  • Some FOIA requests for VistA are very complex because they include requests for complex sourcecode or data files that have mixed copyright permission (CPT codes) find ways to ensure that complicated requests can be met.
  • By default, when FOIA available source code and applications is made evailable insider the government, make it available to the public too. (i.e. ensure that the contents of the VA Intranet software server, as much as possible, is also published externally)
  • Create a bridge-team: Ensure that the bridge process has enough people invested that no single person can become a single point of failure with VA communication with the outside VistA community.
• Overturn the moratorium of local VA hospital VistA development.
• Reinvest in local VA hospital VistA instances. Centrally managed instances of VistA, with locally deployment. Flawed VistA modules from one hospital should not take down the VistA instance of another hospital.
• Empower the bridge process with a VistA Community Portal. That portal should provide the following services:
  • Allow for the submission of improved VistA components back into the VA, to be evaluated as Class III code for possible adoption by local VA hospitals.
  • Those submissions should always be public unless they are security issues, and then they should be made public immediately after being confirmed-patched/denied-ignored
  • Publish a list of approved licenses for contributing VistA components back (probably from proprietary friendly licenses like Apache, Mozilla, BSD, MIT, X11, EPL etc etc, or just chose one if that is easier).
  • Organizations that submit patches, or improvements should expect that someone from the bridge team will publicly comment on reasons for rejection for a particular patch or software, if the VA will not adopt the software.
  • Have a feature request system, that is accessible only to groups who are or represent live VistA instances outside the VA. This should include local VA hospital programmers and CACS, people from IHS, representatives from foreign organizations like Mexico and Jordan, and private hospitals running VistA. This should provide a means for the community to give feedback to the VA about the consequences of central VA development decisions. However, this would not put the VA in the position of accepting feature requests from people who merely 'might' use and improve VistA.
• The features and contributions should be analysed against the current VA 'modernization' plan to create a new modernization plan that considers the needs and contributions of outside-VA VistA users.

Original text by Fred Trotter http://www.fredtrotter.com

Changes:

v.1 to .2

spelling corrections

Changed to focus on a bridge process rather than a bridge person

Propose that the VA instead create a process which acknoledges the basic value of outside commitments etc etc

Meta level policies that are intended to address Nancies outstanding issues.

Changed the name from Open VistA Community Proposal to VistA Open Community Proposal b/c "OpenVistA" is trademarked, and not what I am referencing.

Addressed comments from Hardhats and co-ment instance

--
Fred Trotter
http://www.fredtrotter.com

[fred trotter]

Any user of VistA or VistA derivatives. I want the process by which the VA might open up to private institutions to be of benifit to other goverment agencies like IHS and even other governments. In fact if someone could put me in touch with the powers that be at IHS, that would be very helpful.

-FT.

On Sat, Jul 18, 2009 at 11:07 AM, Mike Ginsburg <MGin...@dssinc.com> wrote:

Who comprises the "VistA community" for whom you are speaking?

-----Original Message-----
From: Hard...@googlegroups.com on behalf of fred trotter
Sent: Fri 7/17/2009 8:08 PM
To: Hardhats; openh...@yahoogroups.com; open-ehealth-...@googlegroups.com
Subject: [Hardhats] VistA Open Community Proposal v.2

Here is the next version. The biggest changes are to move from having a
VistA-community person to a VistA-community process....


Thoughts?

add them here please.

http://libertyhsf.org/index.php/ovcp


 This is the version .2 of the VistA Open Community Proposal that the
LibertyHSF will present on behalf of the VistA community to the VA regarding
a new era of openness and collaboration around the VA VistA-based software.

  - Create a process for creating with the VistA community outside the VA.

  This process should recognize the following operating principles

  - Formally acknowledge that the VistA community outside the VA can

     benefit Veterans by contributing improvements to VistA back to the VA.

     - Formally acknowledge that the VistA community outside the VA can

     provide better care to Veterans in private hospitals and clinics that
     are VistA enabled. Many Veterans do not qualify for treatment at VA
     hospitals but can still benefit from VistA.

     - The VA should prefer Open Source Software in its software

     acquisition process. This enables VistA users outside the VA to follow
     the VA in software decisions and allows the community to further
     enhance VA software by making their improvements available to the VA.

     - Create a default open stance to FOIA requests. Create a process that

     not only completes FOIA requests for software source code resources,
     but provides a feedback mechanism to ensure that the FOIA releases are
     complete.

     - Some FOIA requests for VistA are very complex because they include

     requests for complex sourcecode or data files that have mixed
     copyright permission (CPT codes) find ways to ensure that complicated
     requests can be met.

     - By default, when FOIA available source code and applications is made

     evailable insider the government, make it available to the public too.
     (i.e. ensure that the contents of the VA Intranet software server, as
     much as possible, is also published externally)

     - Create a bridge-team: Ensure that the bridge process has enough

     people invested that no single person can become a single point of
     failure with VA communication with the outside VistA community.

  - Overturn the moratorium of local VA hospital VistA development.
  - Reinvest in local VA hospital VistA instances. Centrally managed

  instances of VistA, with locally deployment. Flawed VistA modules from
  one hospital should not take down the VistA instance of another hospital.

  - Empower the bridge process with a VistA Community Portal. That portal

  should provide the following services:

     - Allow for the submission of improved VistA components back into the

     VA, to be evaluated as Class III code for possible adoption by local
     VA hospitals.

     - Those submissions should always be public unless they are security

     issues, and then they should be made public immediately after being
     confirmed-patched/denied-ignored

     - Publish a list of approved licenses for contributing VistA

     components back (probably from proprietary friendly licenses like
     Apache, Mozilla, BSD, MIT, X11, EPL etc etc, or just chose one if that
     is easier).

     - Organizations that submit patches, or improvements should expect

     that someone from the bridge team will publicly comment on reasons for
     rejection for a particular patch or software, if the VA will not adopt
     the software.

     - Have a feature request system, that is accessible only to groups who

     are or represent live VistA instances outside the VA. This should
     include local VA hospital programmers and CACS, people from IHS,
     representatives from foreign organizations like Mexico and Jordan, and
     private hospitals running VistA. This should provide a means for the
     community to give feedback to the VA about the consequences of central
     VA development decisions. However, this would not put the VA in the
     position of accepting feature requests from people who merely 'might'
     use and improve VistA.

  - The features and contributions should be analysed against the current

  VA 'modernization' plan to create a new modernization plan that considers
  the needs and contributions of outside-VA VistA users.

Original text by Fred Trotter http://www.fredtrotter.com

Changes:

v.1 to .2

spelling corrections

Changed to focus on a bridge process rather than a bridge person

Propose that the VA instead create a process which acknoledges the basic
value of outside commitments etc etc

Meta level policies that are intended to address Nancies outstanding issues.

Changed the name from Open VistA Community Proposal to VistA Open Community
Proposal b/c "OpenVistA" is trademarked, and not what I am referencing.
Addressed comments from Hardhats and co-ment instance

--
Fred Trotter
http://www.fredtrotter.com