VistA, Java, Eiffel, GEHR, USAM, C++, C, Python.....
I see CORBAmed/CORBA as the least common denominator in all these.......it
does not preclude any of the above and falls within our definition of "open
source" (or does it? -- Dave F?)
Is it alright for us therefore to focus our sights on CORBAmed since it is
the most neutral of all the "models" set forward.
Alvin
On another note: I have only gone to a few conferences here in the US, but
in all of them, the VA had booths to demo VistA. Is this something the VA
has been doing all these years (if so, why?)? Or is this an effort to
prepare the industry for VistA as a standard EMR?
> To me, the discussion is starting to sound like a good reason for
>including an additional "interface layer" [please translate to techspeak
>as needed] to facilitate use of various legacy databases/data
>structures. MUMPS is only one of several good but non-ideal
>foundations, currently supporting systems with many users, enormous
>amounts of data, and a high degree of current functionality.
>
> In the early years of release, what proportion of system users are
>actually expected to be starting from scratch, with no base of existing
>data?? It lookss like this phase of the project needs to be geared to
>the importation and use of existing data from a huge variety of
>formats/structures; I daresay successful management of _that_ aspect of
>system design will make far more difference than any decisions about
>what end-users will type or see on their screen.
>
> I believe it will also be important to choose a coding platform that
>is accessible and relatively easy for humans to parse. I suspect that
>choosing either Eiffel or MUMPS as a foundation moves the project
>quickly toward obsolescence, as it places considerable reliance (and
>burden) upon those who already know those programming environments.
>
> I understand that some (extensible?) environments, such as Python,
>are designed in such a way that one cannot commit "memory leaks" and
>other common errors, thus making it more difficult to shoot yourself
>(and the project) in the foot. These environments are becoming more
>popular as foundations for shared projects due to relative ease of
>parsing code, and the preference for a degree of inefficiency over the
>risk of difficult-to-find but fatal errors. IMO these considerations
>are important when relying upon volunteers, who may need to take over an
>incomplete or poorly documented module. Also relevant is the fact that
>choosing such a tool lowers the costs of participation for potential
>volunteers. There seems to be interest in having participation by
>persons with clinical experience and clinical jobs; if they can learn by
>looking at the code, with a minimal investment of time (i.e. less than
>one semester of additional study) then you're helping ensure the
>continuation of the project.
>
> I wonder whether the most valuable contributions of those skilled in
>MUMPS and Eiffel (for example) may actually lie in sharing opinions re:
>overall data structure/ design, and in coding the MUMPS- or Eiffel-
>specific linkage modules so they can import existing data. Here's why
>I'm sayin this:
>
> The natural history, or evolution of many human-designed systems,
>graphed as complexity over time, seems to plot a series of S-shaped
>curves (OK, tilt the S to the right--cosine wave?) in which a system
>increases in complexity until it reaches (passes) the point of being
>incomprehensible to ordinary mortals. The scarcity and finite lifespan
>of (currently available) superbeings means that eventually mortals using
>the system declare it too cumbersome to maintain; a replacement,
>incorporating now-known-to-be-important features is then created from
>the ground up.
>
> I think we have a choice of where-on-the-curve to graft this project.
>Judging by the list traffic, there seems to be a desire among many vocal
>participants to engage in a well-planned, long-term endeavor and create
>a system designed to outlive its creators by a significant margin. Some
>others seem to have a vision of rapidly managing to incorporate massive
>amounts of existing data from several platforms _and_ having the system
>ready and reliable for production use by 2002 or so. I think of these
>as being differences in ideas about "where to attach this project, in on
>the complexity curve of currently available medical data /practice
>tracking software". Recent messages promoting use of the existing
>MUMPS-based foundation (given the non-vast pool of fledgling MUMPS
>programmers) strikes me as a choice to graft the project onto the higher
>portions of the complexity curve.
>
> I don't know how to tell when it's a good idea to suggest or discuss
>forking a project into related but separate sections, with different
>goals/timeframes. Maybe someone else does.
>
> For anyone still reading--I'm not a real programmer and don't play
>one on TV: I can't even pretend to comprehend the technical aspects of
>most of what's being said on the list. On the other hand, I have the
>opportunity to observe a lot of goal-directed human behavior in the
>world, and hope that some aspects of the above will resonate with your
>own experience, and hopefully result in some benefit for the project(s).
>
> - Richard Ebling
>
>On Tue, 28 Dec 1999, Jim Self wrote:
> >[...] Personally, I don't think it
> >is all that hard to read for a programmer who has spent enough time to
> >become familiar with MUMPS syntax. ^^^^^^^^^^^^^^^^^^^^^^^^^
> (emphasis added)
> >
> >While interest in MUMPS per se may not be growing, the importance of a Free
> >MUMPS is becoming increasingly clear to those of us who have highly
> >functional and actively growing information systems based on MUMPS.
>
>
> [Thomas Beale had stated):
> >>Alright, I'll be a bit more serious. In my experience, you _can_ write
> >>high-quality C++ code, and with additions such as the above, you might get
> >>pretty close to Eiffel. C++ is powerful, no doubt about it. The issues are:
> >>
> >>- cost of training: it's complexity practically mandates a B. Sc. in
> >>comp sci, then significant inhouse training to establish enterprise
> >>idioms and norms.
> >>- cost of development: requires experienced engineers; expensive.
> >>Hackers will create an obscene mess
> >>- cost of maintenance: it's just heard to read, and often not clear
> >>what the design intention was from the code. If standards have not
> >>been applied to all coding in the product, the myriad of different
> >>styles can make it cheaper to rewrite than to maintain. I have seen
> >>this myself in big sites.
>
>
----------------------------------------------------------------------------
----------
Alvin B. Marcelo, M.D.
National Library of Medicine, B1N30
Office of High Performance Computing and Communications
Bethesda, Maryland 20894
Voice: 301-435-3278
Fax: 301-402-4080
eFax: 603-452-3657
Work: [EMAIL PROTECTED] [EMAIL PROTECTED]
Home: [EMAIL PROTECTED]
PGP keyID: 0x6E9941D1
PGP server: http://www.keyserver.net
