up a level
post article
search
admin
Contact
main
|
| Success with VistA from the WorldVistA conference |
 |
 |
 |
 Posted by Fred Trotter on Friday June 30, 2006 @ 09:23 AM
from the VistA dept.
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. Digg this article
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.
<
|
>
|
|
