The short answer is that FMQueryFind wraps the FileMan call FIND^DIC whereas FMQueryList wraps LIST^DIC. Perhaps a FileMan expert, which I am definitely not, could better explain the nuances of each.
As implemented in OVID, the two are very similar. FMQueryList allows you to specify internal vs external on a field-by-field basis. FMQueryFind sets internal/external on the entire operation. FMQueryList allows you to specify an index and value, as you noted. This results in a much quicker operation when the items you want to find are indexed. Say, for example, you wanted a list of patients with the name of "SMITH,ROBERT" in the PATIENT MOVEMENT file. If you were to use FMQueryFind with a screen, then on the Vista side every record in the PATIENT MOVEMENT file would be retrieved and the screen would be applied to weed out those with a non-matching name. This could run into thousands of iterations. However, using FMQueryList, the index is used retrieve matching records, which would probably be only a few in number.
To check which fields are indexed, you should check with FileMan:
D P^DI
Select OPTION: ??
Choose from:
1 ENTER OR EDIT FILE ENTRIES
2 PRINT FILE ENTRIES
3 SEARCH FILE ENTRIES
4 MODIFY FILE ATTRIBUTES
5 INQUIRE TO FILE ENTRIES
6 UTILITY FUNCTIONS
7 OTHER OPTIONS
8 DATA DICTIONARY UTILITIES
9 TRANSFER ENTRIES
Select OPTION: 8 DATA DICTIONARY UTILITIES
Select DATA DICTIONARY UTILITY OPTION: ??
Choose from:
1 LIST FILE ATTRIBUTES
2 MAP POINTER RELATIONS
3 CHECK/FIX DD STRUCTURE
Select DATA DICTIONARY UTILITY OPTION: 1 LIST FILE ATTRIBUTES
START WITH WHAT FILE: PATIENT MOVEMENT//
GO TO WHAT FILE: PATIENT MOVEMENT//
Select SUB-FILE:
Select LISTING FORMAT: STANDARD//
Start with field: FIRST//
DEVICE: VIRTUAL Right Margin: 80//
STANDARD DATA DICTIONARY #405 -- PATIENT MOVEMENT FILE
FEB 11,2010@09:54:38 PAGE 1
STORED IN ^DGPM( (4 ENTRIES) SITE: DEMO HOSPITAL UCI: EHRD,EHRD (VERSION 5.
3)
DATA NAME GLOBAL DATA
ELEMENT TITLE LOCATION TYPE
-------------------------------------------------------------------------------
This file holds the data for all admissions, transfers, discharges, treating
specialty changes, and lodger movements. These entries must not be edited
through fileman. Instead, the appropriate bed control options should be
executed to insure data consistency.
The following cross-references exist on this file:
^DGPM("ATID"_TT,DFN,Inverse date_AS,DA)=""
^DGPM("ATT"_TT,Date_AS,DA)=""
^DGPM("APID",DFN,Inverse Date_AS,DA)=""
^DGPM("APTT"_TT,DFN,Date_AS,DA)=""
^DGPM("APCA",DFN,Corresponding Admission,Date_AS,DA)=""
("APCA" lists only physical movements related to admission)
^DGPM("APMV",DFN,Corresponding Admission,Inverse Date_AS,DA)=""
^DGPM("APRD",DFN,Date_AS,DA)=""
^DGPM("AMV"_TT,Date_AS,DFN,DA)=""
^DGPM("ATS",DFN,Corresponding Admission,Inverse Date_AS,Treating
Specialty,DA)=""
^DGPM("CN",External Format of Ward,DA)="" **inpatients only**
^DGPM("LD",External Format of Ward,DA)="" **lodgers only**
^DGPM("ARM",IFN of Room-bed,DA)=1 or 0 [1 indicates lodger,
0 indicates non-lodger]
^DGPM("B",Date,DA)=""
^DGPM("C",DFN,DA)=""
^DGPM("CA",Corresponding Admission,DA)=""
And we can see that the "C" index is on the DFN (aka patient) field.
Just to clarify, in the PatientMovementRepository, I do not see a reason to apply the screen on the patientDFN because, by indexing on it, we are already limiting ourselves to index matches anyway.
