4 ms·
For fuck's sake, the code is out there: http://sourceforge.net/projects/openvista/ http://sourceforge.net/projects/openvista/ EDIT: apparently the main project
by sachinag 17y ago
For fuck's sake, the code is out there: http://sourceforge.net/projects/openvista/ http://sourceforge.net/projects/openvista/ EDIT: apparently the main project is at WorldVista now: http://sourceforge.net/projects/worldvista/ http://sourceforge.net/projects/worldvista/
There are for-profit companies selling install/support services around it: http://www.medsphere.com/ http://www.medsphere.com/ (And here's their .org for their OpenVista repository: http://medsphere.org/index.jspa http://medsphere.org/index.jspa)
Yeah, VistA is a PITA. What we need are data standards for non-imaging data (where DICOM has been a raging success). I've long suggested that all records have to be readable in VistA - it doesn't force people to use Medsphere, but it means that there's a lowest common denominator FREE software package that works.
- siculars 17y agoagreed. i'll just paste my comment from an article on the oreilly radar blog, http://radar.oreilly.com/2009/05/who-will-cut-the-gordian-knot.html http://radar.oreilly.com/2009/05/who-will-cut-the-gordian-kn... . In my opinion, one thing that government can do to accelerate electronic record keeping in the healthcare arena is mandating that solution providers must make means available to both import and export data to/from their systems. Mandating a specific format is less of an issue and should not be the main goal. If vendors were obligated to open their systems and encouraged to do so via some [fiscal/tax] incentive then the problem would solve itself. IT professionals either on their own or contracted would create solutions that connected the hodgepodge of systems out there. These systems are infinitely difficult to implement on any scale (by scale I mean number of people using the system - not technical challenges). At the moment I am tangentially involved in a major enterprise installation at a very well known institution. From my vantage point one of the major stumbling blocks is the difficulty in which the many, many systems already in place will interact with the new system (and with each other). The inability of these systems to interact with each other directly affects the cost of doing business in the modern day hospital. Many of the people in positions to make purchasing decisions are not fully cognizant of the concept of "vendor lock in" and "data portability". These poor decisions are paid back many fold not only in cold hard cash but also in opportunity cost over the lifetime of the system purchased, which may very well be decades. Government can make this all go away by simply requesting that all players in this space provide mechanisms for programmatic, unfettered data access. Providing fiscal incentive will all but ensure that those providers in compliance will be preferred. Mandating a specific system, or data exchange format is not the solution or, frankly, the "American way". Evening the playing field by ensuring openness through financial incentive is much more palatable to a broader spectrum of participants. The market place will ultimately decide and coalesce around its own standards and formats.
- sachinag 17y agoSee, I fundamentally disagree that mandating data formats in un-American or a violation of market principles. We had an Interstate Commerce Commission (the first independent commission) because interstate markets fail sometimes. And it's not healthcare specific for me: if the federal government picked one between MPEG and Ogg for the <video> tag in HTML5, I'd be perfectly happy.
- olefoo 17y agoDamn, I was just looking at all of those last week. Just one step ahead of the herd, apparently. I have to say that MUMPS compares favorably w/ sendmail.cf as a programming syntax.