Frequently Asked Questions (FAQs) - Revision history

NeilArmstrong: Added a glossary link to Business Rules~

2012-08-04T09:21:31Z

Added a glossary link to Business Rules~

← Older revision		Revision as of 09:21, 4 August 2012
Line 123:		Line 123:
	8925 at fault? In this case, I do not think either one is at fault. I have		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		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		expect to know all the related [[business rules~\|Business Rules]] regarding that file. You are
	trying to bypass those business rules by going to the native data structure to		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		extract data using generic Fileman. Many VistA files are not truly Fileman
	compatible. By this, I define Fileman compatible as entering data via		compatible. By this, I define Fileman compatible as entering data via
	generic Fileman tools into a file being exactly equivalent to entering		generic Fileman tools into a file being exactly equivalent to entering
	that same data through the supported package interface and honoring all		that same data through the supported package interface and honoring all
	business rules for the entering of that data.		[[business rules~\|Business Rules]] for the entering of that data.

	steven mcphelan		steven mcphelan

69.68.182.66 at 11:33, 23 March 2005

2005-03-23T11:33:03Z

@@ 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:
 <pre>
@@ Line 85: / Line 81: @@
-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.
-Lloyd
+One can manipulate a file's data structure so that it will cause the
 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
@@ Line 103: / Line 145: @@
 George Timson

69.68.182.66 at 11:28, 23 March 2005

2005-03-23T11:28:31Z

← Older revision		Revision as of 11:28, 23 March 2005
Line 8:		Line 8:


			<pre>
	OUTPUT FROM WHAT FILE: TIU DOCUMENT//		OUTPUT FROM WHAT FILE: TIU DOCUMENT//

Line 56:		Line 56:

	Press RETURN to continue...		Press RETURN to continue...
			</pre>



Line 63:		Line 62:
	should have found.)		should have found.)

			<pre>
	NUMBER: 4299 DOCUMENT TYPE:		NUMBER: 4299 DOCUMENT TYPE:
	OFFICE VISIT		OFFICE VISIT
Line 82:		Line 81:
	THWING,PHILIP T		THWING,PHILIP T
	REPORT TEXT: xxx		REPORT TEXT: xxx
			</pre>

69.68.182.66 at 11:27, 23 March 2005

2005-03-23T11:27:09Z

New page

=== 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

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

Lloyd

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