Difference between revisions of "Frequently Asked Questions (FAQs)"

From VistApedia
Jump to: navigation, search
Line 3: Line 3:
  
 
"Problem": When performing a search on a field that is a pointer to another file, the search seems to fail.  For example:
 
"Problem": When performing a search on a field that is a pointer to another file, the search seems to fail.  For example:
 
 
 
 
  
 
<pre>
 
<pre>
Line 85: Line 81:
  
  
 +
Answers from the Hardhast message board:
 +
 +
<pre>
 +
This has something to do with initials being an output transform.  If
 +
you use INTERNAL(ENTERED BY), EQUALS, 73 it should work.  --Lloyd
 +
</pre>
  
 +
<pre>
 +
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.
  
This has something to do with initials being an output transform.  If
+
It then compares this value (73) to the external
you use INTERNAL(ENTERED BY), EQUALS, 73 it should work.
+
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
 +
</pre>
 +
 
 +
<pre>
 +
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.
  
Lloyd
+
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
 +
</pre>
  
  
 +
<pre>
 
The problem arises when there is a pointer field that has an Output transform on  
 
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  
 
it.  Try this to fix the problem of searching on such a field:  In the  
Line 103: Line 145:
  
 
George Timson
 
George Timson
 +
</pre>

Revision as of 11:33, 23 March 2005

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