"John S. Gage" wrote:
>
> "Woodhouse, Gregory J." wrote:
>
> > constraints are expressed as MUMPS code). Instead, most business rules are
> > built into application code, making it difficult to reuse that code in a new
> > business environment. The representation of business rules in one of the
> > major issues involved in integrating MUMPS based VistA applications with
> > non-MUMPS, non-Fileman applications.
>
> Examples of this phenonmenon would help the rest of us continue our
> evaluation of Vista. So much of VistA takes its "business rules" just
> from the care of patients, and the fact that VistA is so modularized,
> make it hard for me to believe that there is a pervasive problem with
> VistA simply because it is used in the VA environment. In addition, the
> fact that VistA is in use in the German Heart Institute and throughout
> Finland makes me believe it is adaptable.
In Finland, they are based on the VistA Infrastructure (Fileman database, Kernel
menus/devices/background tasking/etc., Mailman, etc.). They grew their own
apps. Marcus Werners at the German Heart Institute has used the VistA apps (you
must run the infrastructure to run the apps), but they no doubt have had to
modify them.
Once you modify VistA apps extensively, you are off the escalator, so to speak.
You can look at later releases of VistA apps and scavenge and adapt features
that are added, but it is not trivial to do so. I have been an adopter of
VistA's infrastructure (not the apps) which I religiously refuse to modify. I
have gotten off the Infrastructure escalator in the past. I won't do it
again...
Because VistA was not originally based on fee for services, billing is not a big
part of it. I believe they do collect fees now in some cases, but they won't
release the billing software under FOIA, if I am right.
If I was to start VistA over again, I'd make sure of the following:
- It would need to be object oriented, at least at a fairly large granularity
with wrappers (CORBA, etc.).
- Systems would be developed out of components (parts) that would be plugged
into a framework. The framework itself would be made out of parts.
- The components would provide parts for business rules, independent of the
persistent storage and UI/programs. You would have rules parts, persistence
parts, UI parts, etc.
- Apps would be expressed through the use of Parts and Declarative Knowledge.
This would hide the underlying language so it could be built with parts
implemented from a variety of languages.
- The framework and parts model would be open source. Although proprietary
systems might be employed to build parts, if necessary, it would keep the heart
and soul of the system out of this realm. Only then could you expect to be able
to practically transition to the new technologies that will surface in the
coming decade or two.
I have been very impressed with the vision of parts and declarative knowledge
expressed by Jack Harich at his web site. Jack is a free thinker who openly
shares his ideas and encourages dialog. Take a peak. Don't be put off by the
modest appearance. You are looking into the future of software design...
http://www.mindspring.com/~happyjac/site/index.html
--
--------------------------------------------------------------
Greg Kreis Pioneer Data Systems, Inc.
[EMAIL PROTECTED] http://www.PioneerDataSys.com
http://www.Hardhats.org/ <-- worldwide VISTA/DHCP users
When people are free to do as they please, they usually imitate each other.
-Eric Hoffer
