Andrew Ho wrote: >On Sun, 21 Dec 2003, Jim Self wrote: > >> Thanks for taking the time to look. I will be glad to help. I think that >> MUMPS is vastly underappreciated by those who are not familiar with it > >Jim, > I have heard this statement enough times that I am convinced that it >must have some merit. However, unless 1) its advantages are overwhelmingly >obvious or 2) it is trivially easy to learn, getting more people to learn >it will be quite impossible.
MUMPS has always been conspicuous by an absence of features. Some of MUMPS advantages are obvious only in the long term. It supports continual development of live systems. It has a uniquely simple yet scalable concept of data. MUMPS as a language is one of the easiest to learn there is. It is important that people interested in healthcare computing give MUMPS serious consideration because it has a long history of success in supporting highly usable robust and scalable systems. > >> and that it still has a great deal to offer for building robust and >> scalable information systems and particularly for deployment of such >> systems on the web. > >.Net, Java, even Zope :-) camps claim the same. It is much easier to make a claim in the short term than to prove it in the long term. > >> > 1) How easy would it be to modify VMACS to support human hospitals and >> >clinics? >> >> Why would you want to when you have a Free alternative with as well >> proven a record of large scale deployment as VistA? > >I was hoping that VMACS is smaller and will be easier to install and >configure. It may be a good learning system or the kernel for the next >generation VistA. VMACS is definitely smaller and may be easier to install and configure but those aspects of VMACS have not been exercised much yet so that is unknown. On the other hand, VistA has been installed in many different hospitals, some of which are very large. The task of fitting any system to a functioning hospital is a serious undertaking which profoundly dwarfs any perceived difficulty in getting started with VistA. >> To modify VMACS to support some human hospitals and clinics might >> actually be doable but it would not be easy. > >Well, what good is it if it cannot be easily changed? :-) Not at all the same thing. VMACS has always been easily changed - that is why it is still a viable system after twenty plus years. The problem is that hospitals are complex institutions performing a vital function with limited resources. Reliable detailed knowledge of the operations of such institutions are in general not readily obtainable until after a hospital information system is in place. > >> It might be a better starting point than many alternatives, but to >> modify anything to provide comprehensive integrated support > >No, the goal would be to modify it enough so that it will become easily >changeable. A boot-strapping strategy, if you will. Think EsiObjects >(http://www.esitechnology.com/library/downloads/esiobjects/EOdescription.html) >but with medical systems-specific (OIO-like) object layer. > >... >> hospitals are complex insitutions that are generally not well understood >> in depth by any of the people working in them. > >1) Build complexity slowly. 2) Copy from VistA (reverse-engineer). I completely agree with both suggestions. My approach at this point is to take basic web oriented tools from VMACS and combine them with Vista installation on GT.M and Linux with Apache. Then I can expose VistA data and design to the web making it easier for me and others to understand, to potentially reverse engineer, and, of course, that also opens possibilities for re-engineering VistA applications for the web. >> > 2) Can a bare VMACS instance be replicated and installed to >> >bare-harddrive in a few hours? >... >> After we have gone through the process a couple more times I expect that >> installing a new bare instance could easily fit under half an hour. > >Wonderful! > >> This seems a strange question to ask about a hospital information system >> in that the effort or time involved in installing a bare system to >> harddrive is as nothing > >I agree. But it is the first hurdle in disseminating the product. > >> compared to other aspects of fitting or growing a system to fit its host >> institution. > >That's why we need to focus our energy on the "Change-enabling" tools. Some dimensions of change are more vital to enable than others in a given context. In a mature system, procedures, services, and clinicians change rarely. Tools for managing that data does not need to have as much polish as tools for managing clinic appointments or lab tests and results. >> Furthermore, a bare system is not very useful. A great amount of data >> about hospital procedures, services, staff, clinicians, patients, >> schedules, lab tests, etc. must be entered before it would be very >> useful. > >How hard is it to "enter" these "data about hospital procedures, services, >etc"? The major thrust of the OIO project (in case you don't already >know), happens to be building tools that makes it easy, fast, and reliable >to do exactly this. Individually it is very easy but there are many thousands of them. I do want to learn more about OIO. > >> > 3) How do you handle schema and workflow changes in VMACS? >> >> This question is too lacking in context for me to begin to answer. >> Are you thinking of anything specific? > >For example, adding the vaccination schedule, related "forms", etc for a >new kind of animal called "human". > >Best regards, > >Andrew >--- >Andrew P. Ho, M.D. >OIO: Open Infrastructure for Outcomes >www.TxOutcome.Org > > --------------------------------------- Jim Self Chief Systems Developer and Manager VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself)
