Jim,
Your additional input is helpful, and right on target in my opinion. Thanks.
Rob
At 03:20 AM 11/21/99 -0800, you wrote:
>"Robert R. Hausam" <[EMAIL PROTECTED]> wrote:
>>Alvin,
>>
>>I would say that you are probably correct, and that we shoud NOT reject
>>VISTA out of hand due to its MUMPS (or now called M) implementation. It is
>>a very complete and powerful system that is implemented and working on a
>>production basis in I believe all of the VA sites (to one degree or
>>another), and a number of other sites throughout the world.
>
>I am aware of VistA users in Finland and Germany, as well as in the US and
>several schools of Veterinary Medicine. I believe it is also the basis for
>large medical systems deployed by the US Department of Defense and the US
>Indian Health Service.
>
>>I worked with
>>the VA development office (IRMFO) as a fellow during the first 6 months
>>that I was in Salt Lake, back in 1995. The Salt Lake office is where the
>>development has been done for the clinical modules, including the Clinical
>>Lexicon (their vocabulary component, which has some features worth looking
>>at).
>>
>>While we are discussing MUMPS-based EMR systems, we should also mention
>>COSTAR, which is another public domain system, developed at MGH originally
>>for the Harvard Community Health Plan. It has also been widely and
>>successfully used at a number of other sites.
>
>I worked with COSTAR (Computer Stored Ambulatory Record) in 1981-1982. It
>needed a rewrite then but it contained many good ideas and medical
>knowledge. It was "frame" based with nearly all data stored in a
>longitudinal patient record. We rejected it for use as a basis for *our HIS*
>because it was too patient oriented, didn't have provision for enough
>species of patients for our needs :-), and contained a deeply embedded
>assumption that patients could be identified by social security numbers. I
>don't know how it has progressed since then, but I believe a number of
>people have developed GUI front-ends for it.
>
>>Now for a few words about MUMPS. It is a very unstructured language (like
>>BASIC, but probably worse?), but also very powerful, with built-in
>>hierarchical database capability. It is particularly suited for string
>>manipulation.
>
>Any resemblance to BASIC is at best superficial. I think that MUMPS
>is actually, best thought of, not as a computer language, but as a computing
>environment conducive to the construction of highly scalable and resource
>efficient multi-user information systems. This is reflected in the marketing
>of InterSystems, the current owner of most of the commercial
>implementations of MUMPS, for its flagship product, Cache. They refer
>to Cache as "Post-Relational" and emphasize its advantages of performance
>and flexibility over the relational databases together with its interfaces
>to Java and SQL and the web. They never mention MUMPS, but that is its core.
>
>The language itself is deceptively simple but rather different in syntax
>from languages derived from C.
>
>MUMPS' greatest strength, and the source of much its simplicity,
>flexibility, scalability, and uniqueness, is the logical form of its shared
>data storage (referred to simply as globals). MUMPS globals are multi-level
>sorted associative arrays which are almost universally implemented on disk
>with B+ trees (multi-way balanced trees).
>
>>Due both to the nature of the language itself and also to
>>how MUMPS programmers tend to use it, I think it would be difficult to port
>>MUMPS routines to most other languages (i.e. the XECUTE command, if any of
>>you are MUMPS programmers and know what I mean!). But MUMPS code and
>>systems can be made to interoperate with other code modules and systems.
>>In recent years a lot of work has gone on in the MUMPS community to improve
>>interoperability and interfaces. I think these are fair statements. Art
>>Smith or Jim Self may want to offer some additional comments or possibly
>>corrections if they think I didn't get this quite right.
>>
>>My gut feeling is that we can learn a lot from the MUMPS-based efforts in
>>VISTA and COSTAR, but we may not want to or be able to use any of their
>>work directly in building the type of system for the future that most of us
>>seem to be interested in.
>
>VistA and COSTAR each embodies a tremendous amount of knowledge and
>practical experience of medical information. They have each been installed
>and proven effective in many hundreds of medical institutions.
>
>To the best of my knowledge, there is nothing comparable outside of MUMPS.
>I would be very surprised if the totality of all other open source medical
>software has more than a small fraction of their functionality.
>
>The main obstacle to the use of MUMPS software in open source projects is
>the lack of an open source implementation of MUMPS itself. This is being
>addressed with the GUM project and FreeM.
>
>>Rob