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 regarding that file. You are trying to bypass those 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 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