Check out the following files/fields in VistA to see if the functionality to support alternate patient identifiers is supported. Also by creating different patient types it may be possible to have the software bypass some of it's VA specific checks and associate alternate patient identifier formats with that patient type.
The TYPE OF PATIENT file may allow creating customized patient types. While the IDENTIFICATION FORMAT file may allow defining custom patient identifiers.
STANDARD DATA DICTIONARY #391 -- TYPE OF PATIENT FILE APR 19,[EMAIL PROTECTED]:15:44 PAGE 1
STORED IN ^DG(391, (9 ENTRIES) SITE: TECHNICAL INTEGRATION SERVICE UCI: PLATINUM,VISTA (VERSION 5.3)
DATA NAME GLOBAL DATA
ELEMENT TITLE LOCATION TYPE
-------------------------------------------------------------------------------
This file contains the various types of patient which might be seen at a VA
facility. The file is pointed to by the TYPE field of the PATIENT file and
every patient added to the system must have a TYPE specified. Using the
'Patient Type Update' option of ADT the user should specify the parameters
concerning which screens should be displayed during the registration process
for these patient types and what data elements on those screens are editable.
DD ACCESS: @ RD ACCESS: d WR ACCESS: @ DEL ACCESS: @ LAYGO ACCESS: @
POINTED TO BY: TYPE field (#391) of the PATIENT File (#2)
STANDARD DATA DICTIONARY #8.2 -- IDENTIFICATION FORMAT FILE APR 19,[EMAIL PROTECTED]:17:24 PAGE 1
STORED IN ^DIC(8.2, (1 ENTRY) SITE: TECHNICAL INTEGRATION SERVICE UCI: PLATINUM,VISTA (VERSION 5.3)
DATA NAME GLOBAL DATA
ELEMENT TITLE LOCATION TYPE
-------------------------------------------------------------------------------
This file contains the specifications for each patient id format. Each entry
in the ELIGIBILITY CODE file points to an entry in this file. This
relationship is used whenever a primary or other eligibility is assigned to a
patient. The ID FORMAT associated with the assigned eligibility will be used
to set the patient's long and short id.
The default ID FORMAT is 'VA STANDARD'. This format is the same as the SSN.
Currently, spring of 1991, the only sites using formats other then VA STANDARD
are those sites running VA/DOD software developed by the Dallas ISC.
Those hospitals having VA/DOD sharing agreements may eventually add other
format types to help identify DOD patients. However, the site should contact
its support ISC before adding any new formats.
DD ACCESS: @
RD ACCESS: d
WR ACCESS: @
DEL ACCESS: @
LAYGO ACCESS: @POINTED TO BY: ID FORMAT field (#9) of the ELIGIBILITY CODE File (#8)
ID FORMAT field (#8.2) of the TYPE OF PATIENT File (#391)
CROSS REFERENCED BY: NAME(B)
NAME: VA STANDARD PROMPT USER FOR ID?: NO
DESCRIPTION: This format represents the normal VA identification format.
The format uses the Social Security field to produce the following id format:
o LONG ID: 123-45-6789P
o SHORT ID: 6789P
DEFAULT LONG ID VALUE LOGIC: S X="" I $D(DA(1)),$D(^DPT(DA(1),0)) S X=$P(^(0),U,9),X=$E(X,1,3)_"-"_$E(X,4,5)_"-"_$E(X,6,10)
SHORT ID TRANSFORM: S X=$S($D(X):$P(X,"-",3),1:"")
INPUT TRANSFORM: Q
James Gray wrote:
I would say it is not good idea to try to change the name of field .09 in file 2 (the SSN field) so it can be used as medical record number. Using HRN in file 9000001 is much easier. It is already there.
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
------------------------------------------------------- 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
