Frequently Asked Questions (FAQs)

Search Issues

"Problem": When performing a search on a field that is a pointer to another file, the search seems to fail. For example:

OUTPUT FROM WHAT FILE: TIU DOCUMENT//

  -A- SEARCH FOR TIU DOCUMENT FIELD: author OF NOTE AUTHOR/DICTATOR
  -A- CONDITION: =  EQUALS
  -A- EQUALS NEW PERSON: ptt  THWING,PHILIP T     ptt         PHYSICIAN

  -B- SEARCH FOR TIU DOCUMENT FIELD: enterED BY
  -B- CONDITION: =  EQUALS
  -B- EQUALS NEW PERSON: kst  TOPPENBERG,KEVIN S    kst          PHYSICIAN

  -C- SEARCH FOR TIU DOCUMENT FIELD:

IF: A&B    AUTHOR/DICTATOR EQUALS 74 (THWING,PHILIP T)
                 and ENTERED BY EQUALS 73
(TOPPENBERG,KEVIN S)
OR:

STORE RESULTS OF SEARCH IN TEMPLATE: [TMG SET
                              (Mar 20, 2005@00:07)
User #73 File #8925   SEARCH


DATA ALREADY STORED THERE....OK TO PURGE? NO// y  YES
DESCRIPTION:
This can be used to store sets of records, for working
with multiple
records etc.

  Edit? NO//

SORT BY: NUMBER//
START WITH NUMBER: FIRST//
FIRST PRINT FIELD: .01  DOCUMENT TYPE
THEN PRINT FIELD:
Heading (S/C): TIU DOCUMENT SEARCH//
DEVICE:   TELNET
TIU DOCUMENT SEARCH                            MAR
20,2005  00:09    PAGE 1
DOCUMENT TYPE
--------------------------------------------------------------------------------




                         0 MATCHES FOUND.

Press RETURN to continue...

And here is one (of about 1000+ documents that it should have found.)

NUMBER: 4299                            DOCUMENT TYPE:
OFFICE VISIT
  PATIENT: xxxxxxxxxx,xxxxx x           STATUS:
COMPLETED
  EPISODE BEGIN DATE/TIME: NOV 05, 2004
  EPISODE END DATE/TIME: NOV 05, 2004   LINE COUNT: 18
  ENTRY DATE/TIME: FEB 07, 2005@21:03:39
  AUTHOR/DICTATOR: THWING,PHILIP T      EXPECTED
SIGNER: THWING,PHILIP T
  HOSPITAL LOCATION: Main_Office        ATTENDING
PHYSICIAN: THWING,PHILIP T
  VISIT LOCATION: Main_Office           REFERENCE
DATE: NOV 05, 2004
  ENTERED BY: kst                       CAPTURE
METHOD: upload
  SERVICE: FAMILY PRACTICE              SIGNED BY:
THWING,PHILIP T
 REPORT TEXT:  xxx

Answers from the Hardhast message board:

This has something to do with initials being an output transform.  If 
you use INTERNAL(ENTERED BY), EQUALS, 73 it should work.  --Lloyd

It appears that patients external input (i.e. 'kst')
is converted into internal format (i.e. 73). And is
echo'd back to the user in external format.  OK so
far.

It then compares this value (73) to the external
format of that field, after the output transform.
(i.e. TOPPENBERG, KEVIN).  Obviously, these are not
equal values.

So that is where I think it is a bug.

The INTERNAL(X) specification gets around this, but I
think that the default should be to compre internal
format to internal format.

Kevin

I would not call this a bug.  I suspect that Fileman is doing 
everything properly.  However, because of the Output Transform on field 1302, this
causes Fileman to fail to find the matches.  By putting an output 
transform on a pointer field you are asking FM to lookup a .01 field value in the
pointed to file.   Yet FM will compare that value with the value from 
field 1302 which has the output transform on it to display the INITIAL field 
from the NEW PERSON file.  Obviously, the person's name does not equal the
person's initials and thus no matches are found.

One can manipulate a file's data structure so that it will cause the 
generic Fileman tools to apparently misbehave.  So who is at fault, if even 
there is anyone at fault?  Is generic Fileman at fault or is the owner of file 
8925 at fault?  In this case, I do not think either one is at fault.  I have
always said, one cannot look at the Data Dictionary of a file and 
expect to know all the related [[business rules~|Business Rules]] regarding that file.  You are 
trying to bypass those [[business rules~|Business Rules]] by going to the native data structure to 
extract data using generic Fileman.  Many VistA files are not truly Fileman
compatible.  By this, I define Fileman compatible as entering data via
generic Fileman tools into a file being exactly equivalent to entering 
that same data through the supported package interface and honoring all 
[[business rules~|Business Rules]] for the entering of that data.

steven mcphelan

The problem arises when there is a pointer field that has an Output transform on 
it.  Try this to fix the problem of searching on such a field:  In the 
DIS1 
routine, add eight characters:
 OUTX .I $D(^(2)),$P(^(0),U,2)'["D",DV'["="  ......

Yours,

George Timson