VISTA PARAMETER
The value of sequence has no bearing on PRECEDENCE as to which ENTITY supersedes which ENTITY.
A PARAMETER DEFINITION is stored in file 8989.51. No values are stored here. Values are stored in the PARAMETER file 8989.5. The option that Calvin cited allows one to edit a specific PARAMETER value. It has nothing to do with PRECEDENCE.
What is a PARAMETER DEFINITION? It defines the characteristics for a PARAMETER to store values. Unfortunately, the word 'value' has multiple, significantly different meanings which has confused many people for many years. A PARAMETER DEFINITION has 6 main components and other fields supporting those main fields or components.
PARAMETER DEFINITION file (8989.51) 1. There must be a unique name, ^DD(8989.51,.01) 2. There must be an INSTANCE data type, ^DD(8989.51, fields .04, 6.1, 6.2, 6.3, 7, 8) 3. There must be a VALUE data type, ^DD(8989.51, .05, 1.1, 1.2, 1.3, 2, 3) 4. Is the PARAMETER MULTIPLE VALUED, ^DD(8989.51, .03) 5. There must be one or more associated ALLOWABLE ENTITIES, ^DD(8989.51,30) which is a Fileman multiple containing two fields, PRECEDENCE and ENTITY
No end user, ADPAC, or CAC has authority to alter a PARAMETER DEFINITION. PARAMETER DEFINITIONS are either imported from a KIDS Install or hand-entered by developer/programmer.
The NAME is just free text.
The two groups of fields for INSTANCE and VALUE define the characteristics to be used by the XPAR routines to set up a ^DIR call. So these two sets of fields allows the developer to define their Fileman data types such as set of codes, date field, free text, numeric, pointer-type, word processing, etc.
MULTIPLED VALUED determines how many 'values' can be stored in the PARAMETER file. The PARAMETER file does not have a Fileman Key defined on it but the XPAR routines ensure a key is enforced. This is where MULTI-VALUED comes into play. In the PARAMETER file the combination of the three fields PARAMETER, ENTITY, INSTANCE must be unique across the entire PARAMETER file. PARAMETER is just a pointer to the PARAMETER DEFINTION file and is thus the name of the parameter. ENTITY is a pointer the ENTITY file (8989.518) screened to allow selection of only those ENTITIES defined in the PARAMETER DEFINITION file for the PARAMETER selected. INSTANCE is just the 'value' entered to a DIR call where the DIR call is defined by the data entered in the various INSTANCE fields in the PARAMETER DEFINTION file for the parameter selected. If MULTI-VALUED is NO then XPAR ensures that the combination of PARAMETER and ENTITY is unique across the entire PARAMETER file. If MULTI-VALUES is YES then XPAR ensures that the combination of PARAMETER, ENTITY, and INSTANCE is unique. Now to the ALLOWABLE ENTITIES multiple The .01 field of the multiple is PRECEDENCE which is a number. The lower the PRECEDENCE value (i.e., number) the higher the precedence of that ENTITY. So 1 supersedes 2 which supersedes 3. The .02 field of the multiple is ENTITY which is just a pointer to the ENTITY file (8989.518) The ENTITY file has two main fields, .001 called FILE NUMBER which has a special screen so that on certain Fileman file numbers can be selected. The second field is the .01 NAME field. So the Entity called Division which has a .001 value of 4 which is the INSTITUTION file.
PARAMETER file (8989.5) The PARAMETER file (8989.5) is completely driven and controlled by the PARAMETER DEFINITION file. The PARAMETER file has exactly 4 components to it.
The .01 field is ENTITY which is a Fileman variable pointer to the FILE OF FILES file The .02 field is PARAMETER which is a pointer field to the PARAMETER DEFINITION file with a screen that only param_defs can be selected which have the ENTITY (.01 field value) in the ALLOWABLE ENTITIES multiple. The .03 field is INSTANCE which is free text but must pass the Fileman field attributes as defined in the various Instance fields in the corresponding PARAMETER (.02 field value), i.e, PARAMETER DEFINITION The PARAMETER 'value' can be stored in one of 3 fields defined in the PARAMETER file (8989.5) depending upon the Fileman field attributes as defined in the various Value fields in the corresponding PARAMETER (.02 field value).
Now back to Calvin's example. He is running an OPTION that calls an XPAR routine that allows for the add, edit, delete of entries in the PARAMETER file (8989.5)
Select PARAMETER DEFINITION NAME: ORWOR WRITE ORDERS LIST Write Orders (Inpatient) [a .01 field value in file 8989.51]
ORWOR WRITE ORDERS LIST may be set for the following: [XPAR routine is now showing the list of ALLOWABLE ENTITIES for the selected PARAMETER NAME]
1 User USR [choose from NEW PERSON]
2 Location LOC [choose from HOSPITAL LOCATION]
2.3 Service SRV [choose from SERVICE/SECTION]
2.7 Division DIV [choose from INSTITUTION]
3 System SYS [BETA.VISTA-OFFICE.ORG]
4 Package PKG [ORDER ENTRY/RESULTS REPORTING]
Since the ALLOWABLE ENTITIES has a .001 field defined, the api shows Precedence, Entity name [^DD(8989.518,.01)], and PREFIX [^DD(8989.518,.02)]
Enter selection: 2.7 Division INSTITUTION Select INSTITUTION NAME: PINEVILLE FHA WV OCS 020A5
Setting ORWOR WRITE ORDERS LIST for Division: PINEVILLE FHA --------
Select Sequence: ? [Sequence is the DIR("A") value taken from the INSTANCE TERM field for the Parameter selected]
Sequence Value
-----
10 OR ADD MENU CLINICIAN PINEVILLE
What is 10? 10 is just a data value in a Fileman file that has no bearing on PRECEDENCE. The PARAMETER DEFINITION field INSTANCE HELP has this value: Enter the relative sequence for this order in the list box.
The description of this PARAMETER DEFINITION states:
- This parameter has been superseded by ORWDX WRITE ORDERS LIST.***
Currently, the GUI references only for backward compatibility reasons. This parameter is used do list the order dialog names that should appear in the Write Orders list box of the CPRS GUI. This is the list of dialogs that should be used in the inpatient setting.
The XPAR utilities really expanded the multi-dimensionality of the Fileman DBMS. Because of M, Fileman naturally allowed for multiple values in a single cell of a traditional relational database. XPAR expands this multi-value in that it allows for each of the multi-values in a single cell to be a different database type.
SO, the PARAMETER file has no influence on PRECEDENCE other that being the repository for values for which PRECEDENCE will be applied according to the rules defined the PARAMETER DEFINTION file.
Side-note. The Value fields in the PARAMETER DEFINTION file do not necessarily mean that this is the "pertinent value" of an entry in the PARAMETER file. Mull this over.
A PARAMETER entry has two fields defining the type of entry where those two fields are PARAMETER NAME and ENTITY, For each combination of PARAM-ENTITY there are two degrees of freedom to associate Fileman data information with that pair, namely INSTANCE and VALUE.
