To me there seems to be some important issues raised in the first post on this subject that have been addressed well.
1. Can you delete existing fields in file 2? This is not a good idea.
2. Can you change the characteristics of and exiting field? It depends. Some simple things like making the field not required will rarely cause problemsm, but even that depends on the field. Changing what can be stored in a field is probably not a good idea.
3. Can you add new fields. Yes that is easy in Fileman.
4. I think a more important issue is the logic in the registration module where the data is collected to store in the fields in file 2. That can be changed but it can involve a lot of Mumps programming. It is possible to write the code to stuff in values that are not needed outside of the VA. It should be noted that IHS has a totally different registration module from that used in VistA, but it uses many of the same Fileman fields.
Jim Gray
----- Original Message ----- From: "Nancy Anthracite" <[EMAIL PROTECTED]>
To: <hardhats-members@lists.sourceforge.net>
Sent: Tuesday, April 19, 2005 2:14 PM
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?
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
