It’s worthwhile, as far as I can tell, to get the little guy into a position of being able to better care for there patients, by using and getting used to the “process” that is also VistA. That’s the portion that so many people seem to overlook. It’s not only software, it’s a different way of doing things, that works remarkably well.

Yes, a lot of people complain, and gripe about not having gui frontends. Understandable. The people who know the systems inside and out, also know that a gui isn’t all that it’s cracked up to be.

Fine for some things, horrible for others.

I’ve seen first hand, some of the things that have been done, by the EWD guys, and what has been done with OVID. OVID is the new Java interface provided by Medsphere, and it also holds a great deal of promise.

The biggest problem with VistA, is that it was never designed with Java, and web interfaces, or even modularity in mind. (I’m referring specifcally to VistA not M). It was also never designed to be put into a small medical practice. However, the EWD, OVID, and the cadre of people who are making it all work anyway, prove that anything is possible.

I know of a small group that is considering re-writing the VistA core, to make it more friendly to the small practice, and to make it more modular. This project isn’t meant to take the place of World VistA or any of the other VistA’s, but meant to fill in one of the largest gaps in health care today.

DHCP, VistA, and the process that has evolved from these software packages, are the most significant changes in the health care industry, since family practice came into being. It got people talking, and taking notice of what was happening.

Let’s hope that whether VistA lives on, or dies off, that the trend of communication continues.

I am a programmer with 10+ years of developing enterprise web technologies (.Net, Java, XML, Relational SQL Databases, etc). I started looking into VistA for a Doctor friend of mine for use in his office. I has never heard of MUMPS before last week, but I can say, after looking at Cache, VistA, etc for one week, that it will not be an issue developing any external apps against the VistA platform that leverage web 2.0 technologies. Many already exist. In fact, the WorldVistA project has code that allows you to reference VistA data with XPath, which is the standard method of accessing data in XML format using //node syntax. I will say that understanding VistA is not for the faint of heart,nor is it for neophyte programmers/system admins/IT guys. It is a complex system, but the complexity is out of necessity because it is a complex problem.

Let me close by telling you an old programmer’s adage: There is a function for everything.

For even more pizazz, throw in something like Emprise Javascript Charts (see http://gradvs1.mgateway.com/download/ejsc4.0.682.pdf – again just look at the pictures) and now you’re visualising Mumps data (results, diagnostic tests etc) as graphs and charts, all done in Javascript (ie no plugins), and capable of being implemented literally in minutes.

Sorry Gregory, IMHO the time for purist navel-gazing is over. As Steve is demonstrating all this kind of stuff really *can* be done today using the existing VistA code base, and rapid, fast and loose development techniques and third-party Ajax tools are there to make it all quick and easy. Now JFDI guys!

I am a HUGE fan of RIA and to be honest, given the strength of the VistA backend, I was hoping that someone would arrive at this same conclusion at the front end. JSON and Ext JS are compellling tool sets to bring the data alive. My favorite RIA development shope is Cynergy Systems based in SD. I was blown away by some of the concepts they developed.

I would love to see what you are thinking in terms of some front end extensions. Please advise.

A web desktop that will make wonder, “is it my desktop, or my browser?” Ext JS provides the flash and web presentation while EWD gives you the tools to integrate the browser, Ext JS, and VistA data. We can leverage the existing RPC broker framework and DBS call functionality. EWD custom tags give us the ability create re-usable, configurable, VistA data aware components that can be passed off to the web designer.

And if you want to get revved-up about Ext JS design, take a look at the very soon to be released Ext 3.0 Designer:

http://extjs.com/forum/showthread.php?t=52258

The platform is fine, you just gota jump in and get wet

It is perhaps worthwhile to compare MUMPS to another “legacy” language that has remained very popular, Scheme. Scheme was first introduced in 1975, but is part of the Lisp family of languages which goes back further, at least to 1960. The language has been very popular due, in large measure, to extensions that have been introduced by vendors and open source projects. My preferred implementation, PLT Scheme, has a robust module system and good support for objects. Interestingly, in the most recent “official” version of Scheme, R6RS, has finally introduced modules under the name library.

We’re not there yet with MUMPS, but without suitable language level support, there will always be significant obstacles to working extending and adapting existing systems. This translates to higher costs and lost opportunities.

Thanks for your comments regarding MUMPS. My point about modularity is not about modularity within the platform, but modularity with third party applications that can tie in from outside the platform. Adding on additional modules that are already built out in MUMPS specifically for the VistA platform is easy – dietetics, radiology, and the other 120+ modules. However, my point was to highlight that when a comprehensive system like VistA gets plopped into a complex hospital environment, there are typically between 15-25 other systems that must be tied into the centralized VistA health information system because that functionality does not exist native within VistA (ICU monitoring, financial functionality, monitoring devices, etc). This is challenging work given the current construct of VistA.

In terms of objections to MUMPS, I agree that they are “wrong, all misleading” and soon are going to be quite outdated. I also agree that its unique properties make it an exceptional tool from which to build a health information system. Given what I am learning about some the evolution of MUMPS and its ability to interact with newer UI technology I am more convinced than ever that MUMPS based EHR’s have a very bright future.