> From: Nancy Anthracite <[EMAIL PROTECTED]>
> Reply-To: hardhats-members@lists.sourceforge.net
> Date: Tue, 19 Apr 2005 16:14:13 -0400
> To: hardhats-members@lists.sourceforge.net
> Subject: Re: [Hardhats-members] Configurability of fields in FileMan
> 
> So I guess that means that one cannot entirely rely upon the cross reference
> information in the data dictionary to track down the potential interactions
> with other packages, hence the desire of many to carefully reengineer VistA
> before considering an attempt to replace it?

Most definitely, you SHOULD NOT rely of cross reference info alone.  To have
a high degree of confidence in these matters, one should perform a VERY HIGH
LEVEL, SEMANTIC analysis of the system programs.  Ideally, that means a
large--tens to hundreds--team of VistA specialists reading and interpreting
the Vista Programs.  That is a huge undertaking, and not within any
reasonable budget that I can imagine.

IF a LIMITED-scope, semantic analysis were developed for a specific set of
problems, then an automated system can be developed to make the analysis
economically feasible.  I know that is possible since I have done such a
project on a  major M(UMPS) implemented system that was comparable to VistA
in terms of gross size parameters--routines, files, function points, etc.
However, this approach appeals only to the technical folks, the so-called
'HardHats'.

Most others prefer to work out the problem in more fluid, less well defined
terms of sales meetings, project management conferences, and the like.
There one can generate lots of smoke and ensure that all responsibility is
so dispersed that no one can be held accountable.   (which is why these
debates continue to return like spring flowers.)

Regards,

Richard.


> 
> On Tuesday 19 April 2005 03:46 pm, Richard G. DAVIS wrote:
>>> From: Nancy Anthracite <[EMAIL PROTECTED]>
>>> Reply-To: hardhats-members@lists.sourceforge.net
>>> Date: Tue, 19 Apr 2005 10:55:04 -0400
>>> To: hardhats-members@lists.sourceforge.net
>>> Subject: Re: [Hardhats-members] Configurability of fields in FileMan
>>> 
>>> Could you please address the poison in a little more detail, starting
>>> with the part of not using field.  Could you reassign the name of the
>>> field and change the length, for instance, for the SS number to create
>>> the patient record number that would continue to function properly?
>> 
>> At the database level, working with VA File Manager (FM) as the tool, then
>> YES--the name of the field used to store SSN can be changed and the length
>> of the data value to be expected by FM can also be increased.  This can be
>> done easily in a matter of a minute or two.
>> 
>> However!!!  Let the modifier beware!!  The ramifications of that change at
>> the application level can't be understood unless one has a detailed
>> internal knowledge and experience with all of the applications that may
>> populate that field, or that rely on that field.
>> 
>> VistA applications can NOT be relied upon to respect the sanctions against
>> direct reference to the underlying M(UMPS) global storage system.
>> 
>> Where the VistA field for SSN is concerned, as an example, if that field is
>> not completely satisfactory for a use of VistA outside  of the DVA, the
>> best course of action is one that can only be determined by careful study
>> by a collaboration of the new user group and competent specialists in the
>> VistA technology.
>> 
>> For me to even speculate with an example for the sake of discussion in this
>> forum would really be irresponsible of me.
>> 
>>> On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
>>>> The design of the VistA system anticipated the requirement to create new
>>>> data elements (fields) indefinitely into the future.  VistA provide for
>>>> a formal method of allowing for the addition of data elements without
>>>> adverse impact.  It is, however, a matter for competent (master
>>>> craftsman) personnel.
>> 
>> ...
>> ....
>> ....
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free runtime
>> info, new features, or free trial, at:
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Hardhats-members mailing list
>> Hardhats-members@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/hardhats-members
> 
> -- 
> Nancy Anthracite
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime info,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> Hardhats-members mailing list
> Hardhats-members@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to