If you have only a single ID per person based on the "eligibility" that
works just fine.  It was developed so that IDs for military personnel and
their family members (using SSN with what is called the "family member
prefix") could be used in DHCP before the days of CHCS.  However, the Indian
Health Service needed multiple chart number IDs per person, as different
clinics running on the same system each had their own chart IDs for a given
patient.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
McCormack
Sent: Tuesday, April 19, 2005 7:37 PM
To: [email protected]
Subject: Re: [Hardhats-members] Configurability of fields in FileMan

FWIW - I'm not sure if the following is functional but at one time the 
underlying software functionality anticipated various patient types and 
identifiers.

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: <[email protected]>
> 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: [email protected]
>>> > Date: Tue, 19 Apr 2005 10:55:04 -0400
>>> > To: [email protected]
>>> > 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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to