Greg:
The issue of "implementation language" is part of the "Enterprise View,
Life Cycle Principles" perspective on the whole VistA architecture. The
Open Source character of the effort and the model base for the
architecture being tied to the VA makes constraints. Since the open value
utilizes, for the present, the VA's design it must accept the present VA
model until a Common Data Model for the Conceptual Content has been
arrived at and then discussions about a different design for
implementation of the common model can be entertained. There is latitude
in different configurations for the same architecture (different
terminologies value set, and referential data for different enterprises)
for differing business purposes. All of this is in the realm of
"implementation" but does involve some common agreements on components of
the physical architecture that keep the technical configurations
relatively limited. THat can all be managed by Life Cycle Principles and
Processes (consider the Capability Maturity Model Discipline from the
CMU-SEI VA study). An information architecture as complex as VistA needs a
discipline. Principles and Procedures can be applied to a M environment as
well as other environments and is relevant to all aspects.
On Tue, 13 Sep 2005, Gregory Woodhouse wrote:
A related question is whether an *implementation* language is needed to
facilitate discussion of health information systems. If we are really
discussing specifications or design, rather than implementations, then
doesn't the use of an implementation language in this context blur this
fundamental distinction (and, I would add, tend to contribute to poor
design)?
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Before one gets the right answer, one must ask the right question." -- S.
Barry Cooper
On Sep 13, 2005, at 9:43 AM, A. Forrey wrote:
Greg:
you have to understand that standards are common conventions for
communicatiing about a spubject. The common misundertsatnding is that they
are "specifications". If you cant communicate clearly then you are just not
in the ballgame; the MDC just keeps us in the ballgame rather than
wandering blind and ignorant in the desert. It takes all players
communicating to get the bennies and there are many wys to do that but this
notice from ONCHIT is "Communicate or you're not in the game!". The VistA
Community has to figure out how they will be in the WHOLE game; MUMPS
deals with the technology platform for VistA - that all; but without it you
have to go out and re-engineer the whole architecture at great cost (maybe
the VA uppercrust has that in mind, it remains to be seen). The log cabin
era is over, so that technology platform role of MUMPS is one building
bl;oick, so lets do it right. Sorry to be so blunt but that reality.
Arden
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
