Difference between revisions of "Frequently Asked Questions (FAQs)"
From VistApedia
(Added a glossary link to Business Rules~) |
|||
(One intermediate revision by one other user not shown) | |||
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. | ||
− | + | 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 | ||
+ | </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. | ||
− | + | 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 | ||
+ | </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> |
Latest revision as of 09:21, 4 August 2012
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