At 03:12 PM 12/28/99 -0500, you wrote:
>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.
The use of CORBAmed certainly is consistent with open source. The
specifications from the OMG are officially not public domain, but there are
no licensing fees to implement or use the specifications (or even to obtain
them).
I think that there are two areas of use. One is to use (or review for
applicability) the CORBAmed IDL specifications. More generally, added
functionality can be defined by IDL that might be of interest to the
openEMR effort but without it having to be CORBAmed approved
specifications. The group might want to submit its arrived at
specifications to the OMG for adoption (by an RFC or by responding to an
RFP through an organization that is a member of the OMG, such as ourselves).
>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?
The VA has been doing this for a long time, I believe.
Dave
>> 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
