I agree with Richard on this. Changing the DD definition of a commonly used field like SSN, would most likely have some unwanted, and unintended side-effects. Code that references SSN, would not always be in the Data Dictionary. It would also be in routines, sometimes obscured by indirection. Therefore difficult to search for.
There are other alternatives though, besides "aliasing" the SSN field to make it something like Medical Record Number. I have always liked the internal entry number of the patient file because it is not user-editable, and it is a good "hook" in the database. Now, some people would argue against using it to identify patients, even in combination with other fields because of several possible scenarios that happen to databases on occasion. - Migrating the database to another database - Merging databases But even in those scenarios you could concatenate the IEN with the original site ID# to make it unique again. Of course the VA is using the Integration Control Number or ICN as the analog to Medical Record Number. It is used extensively in such applications as Remote Data Views. RDV's assembles data from multiple sites using the ICN. Richard J. Sowinski Chief of Application Development Roudebush VAMC 317-554-0000 xt 4226 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nancy Anthracite Sent: Tuesday, April 19, 2005 3:14 PM 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? 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
