Success with VistA from the WorldVistA conference

This is a report on an excellent talk that I am hearing on the factors of success with VistA. The subject is the seven critical success with Medical Software. Essentially these are the lessons that VistA has learned via hard knocks. This list is partly compiled from those who have suceeded but mostly is the result of those who have failed with VistA.

Medical Informatics does not fit the standard software development cycle.

  • Medicine is complex
  • Medicine is variously practiced
  • Medicine changes continuously

As a result

  • Users of medical software must be co-developers, partners in the process
  • The software must be highly adaptable
  • The software must change continuously
  • The process of changing medical software must protect health and privacy

The VAs succcess is based on seven core principles.

  • Software Structure: The software must be compatible with a non-stasis seeking process.
  • It is a combination of paradoxes: It must be integrated and modular, centralized and decentralized, forward and backwards compatability , culture must dictate development standards


  • Software Lifecycle: The software lifecycle must not seek stasis:
  • user driven instead of management driven, developers collaborate on users, Fluxus Quo, Small incremental changes not massive invasive changes, prototype instead of specification, rapid draft iteration, You must stay up to date with improvements and patches (weekly commitment), sites must innovate according the forward compatible rules, sites must force non-forward compatible changes upstream, extreme decentralizations development by users


  • Support Model: The software support model must support the process. It must not seek stasis and it must include everyone:
  • support staff must have layers of expertise user-specific, service-specific, site-specific, VistA-wide, package-specific. Support must be centralized.


  • Community Organization: The development process must be community oriented
  • Five tier model, expert users, service support, site support, common support, software gurus


  • Expertise Lifecycle: The training program is school that is always open and always changing its curriculum.
  • Changes require learning. It is easier to learn to program than it is to learn medicine.


  • Management Model: Decentralized, delegated development authority.
  • Empowered teams repspond to users first, peers second and management third.


  • Economic Model: Service Relationship Model good, penalized for changes bad
  • Users cannot be charged for making changes. If you do, then you incent the users to be silent. Must be a service/relationship model.

Leave a Reply

Your email address will not be published. Required fields are marked *