| # | Name | Location | Type | Details | Index | Description |
|---|---|---|---|---|---|---|
| .001 | number | 11 | This is the internal number of this file. | |||
| .01 | name(+) | 0;1 | FREE TEXT | B | This is an arbitrary name for the single entry in this file. | |
| 1 | current order # | 0;2 | NUMERIC | This is the current order # on the system. | ||
| 2 | system parameters | 1;0 | MULTIPLE | 100.992 | This is the name of the system as found in the global node ^%ZOSF("VOL"). An entry should be made here for each CPU system that generates orders. | |
| 3 | treating specialty | 0;3 | SET OF CODES | 0:NOT ASK 1:ASK | This is a site parameter which controls the prompt for TREATING SPECIALTY when defining patient demographics. If set to NOT ASK, the prompt will not be displayed; and TREATING SPECIALTY will only be defined for the order if it can be found. | |
| 3.01 | or3 conversion complete?(+) | CONV;1 | BOOLEAN | 0:NO 1:YES | This field is maintained by the Order Entry/Results Reporting version 3.0 conversion of orders. It will be initialized to 0 at the start of the conversion and updated to 1 when the conversion is complete. It is important that this field not be edited. | |
| 3.02 | or3 inpatient conversion start(+) | CONV;2 | DATE-TIME | This field will be maintained by the OE/RR version 3 conversion. It will be set to the time the conversion of orders for inpatients started. | ||
| 3.03 | or3 inpatient conversion stop(+) | CONV;3 | DATE-TIME | This field will be maintained by the OE/RR version 3 order conversion. It will contain the time the conversion of orders for inpatients completed. | ||
| 3.04 | or3 inpatient location up to | CONV;4 | FREE TEXT | This field will contain the name of the location the conversion is currently up to if still converting orders for current inpatients. If that step is complete, this field will be blank. | ||
| 3.05 | or3 inpatient dfn up to | CONV;5 | POINTER | 2 | If the OE/RR version 3.0 order conversion is converting orders for inpatients, this field will contain the patient the conversion is currently up to. If the inpatient order conversion is complete, this field will be null. | |
| 3.06 | or3 background job start(+) | CONV;6 | DATE-TIME | This field is maintained by the OE/RR version 3 orders conversion. If the conversion is up to phase 2 (which converts orders for recently seen patients and those scheduled to be seen in the near future), this field will contain the date phase 2 of the conversion started. | ||
| 3.07 | or3 background job stop(+) | CONV;7 | DATE-TIME | This field is maintained by the OE/RR version 3 orders conversion. If the conversion has completed phase 2 (which converts orders for recently seen patients and those scheduled to be seen in the near future), this field will contain the date phase 2 of the conversion completed. | ||
| 3.08 | or3 background job stage | CONV;8 | NUMERIC | This field is maintained by the OE/RR version 3 conversion. If the conversion is in the background job, this will keep track of the stage of the background process it is on. Once the background job is complete, this field will be deleted. The stages are: 0. Populate multiple of patient orders to convert 1. Current inpatients. 2. Patients with future scheduled admissions 3. patients on waiting list 4. patients with discharges in the last 4 weeks 5. patients with appointments in last 4 weeks and next 4 weeks 6. all remaining patients in DPT 7. orders not associated with DPT | ||
| 3.09 | or3 background job up to | CONV;9 | FREE TEXT | This field is maintained by the OE/RR orders conversion. If the background job process is running, this will keep track of the last value processed for the current stage. If the background job stops and needs to be restarted, this field will allow restart from where the process left off. | ||
| 3.1 | or3 background job task | CONV;10 | NUMERIC | This field is maintained by the OE/RR orders conversion. If the conversion is in the background job portion, this field will contain the task number (ZTSK) of the background process job. This will assist in providing the status of the job and allowing restart should the job stop. | ||
| 3.11 | or3 background job stop? | CONV;11 | BOOLEAN | 1:YES 0:NO | Should you wish to stop the background job process for any reason during the OE/RR version 3.0 orders conversion, you can call STOP^OR3CONV and this field will be set to yes. The conversion will check for this field and when it finds it set, it will allow the conversion to make a clean stop. RESTART^OR3CONV may be used to restart the task. | |
| 3.12 | or3 patients converted | CONV;12 | NUMERIC | This field will be maintained by the Order Entry/Results Reporting version 3.0 orders conversion. It will keep a counter of the number of patients that have been converted. | ||
| 4 | add menu default | 0;9 | VARIABLE-POINTER | 101, 19 | This field is the default menu used to add orders. If this field has no entry, then the ORADD menu will be used as the default. This field is for sites that wish to customize the ORADD menu by creating another menu in a local namespace (ORZADD) so that local changes won't be overwritten when new versions of OE/RR are installed. When a customized menu structure has been created for local use of OE/RR, it should be put in this field. Starting with Version II of OE/RR, menus can be set up in file 101 for specific users or groups of users and assigned on an individual basis via the Clinical Coordinators menu. | |
| 5 | package parameters | 5;0 | MULTIPLE | 100.995 | This field allows each package to define its own set of parameters. The entries in this multiple field are exported much the same as entries in the PACKAGE File are exported when a package is initialized. | |
| 6 | show status description | 0;10 | BOOLEAN | 0:NO 1:YES | This field allows the description associated with a status to be displayed with the current status of an order when a detailed display is requested. | |
| 7 | show patient name | 0;11 | BOOLEAN | 0:NO 1:YES | This field allows the patient name to be displayed each time an order action is executed after the subheader during ADD NEW ORDERS option. | |
| 8 | active orders context hours | 0;12 | NUMERIC | This field defines the number of hours that orders remain in the "Current Orders" context after they have been completed. | ||
| 9 | review on patient mvmt | 0;13 | BOOLEAN | 0:NO 1:YES | This field allows orders to be reviewed when a patient is transferred or discharged, and when a clinic appointment is made or cancelled. | |
| 10 | single user/suspend filer | 0;4 | BOOLEAN | 1:YES 0:NO | This is a parameter that can be set for single user systems (PC's) that do not allow multiple jobs to run simultaneously. This is needed since OE/RR uses a background filer. If this field is set to YES then tasks that normally are run in the background will run in real time. For demo/training purposes, not to be used in a production environment. This field is also used to shut down or suspend the background filer. The filer needs to be suspended when the ^ORYX global is being moved or a new version of OE/RR is being installed. | |
| 11 | initials on summary | 0;14 | BOOLEAN | 1:YES 0:NO | This field allows the initials of the person who entered the order to be displayed on the OE/RR summary reports. The initials take up an additional line on the display and are shown just below the Ord'd date time. | |
| 12 | default provider | 0;15 | BOOLEAN | 0:NO 1:YES | This field allows the attending physician to be prompted as a default when adding new orders. | |
| 13 | last purge date | 0;5 | DATE-TIME | This field contains the date that the OE/RR purge utility was last started. | ||
| 14 | last order purged | 0;6 | POINTER | 100 | This field contains the last order number purged by the OE/RR purge utility. | |
| 15 | error days | 0;7 | NUMERIC | This field tells OE/RR how long to keep the record of failed tasks in the OE/RR ERROR file. If no entry is put in this field then errors are kept for 2 days. | ||
| 16 | debug | 0;8 | SET OF CODES | 0:OFF 1:ON | This field is used by package developers to help debug transaction failures with their package and OE/RR. If this field is turned ON, then transactions are not processed thru the background filer and a message is displayed when a transaction fails. This field should be turned OFF at all other times. | |
| 17 | installation flag | 0;16 | DATE-TIME | This field is used during installation to disable OE/RR protocols. There should only be an entry here during OE/RR installation. The entry is provided by the OE/RR installation process. | ||
| 18 | confirm provider | 0;17 | SET OF CODES | 0:NO 1:YES (Default NO) 2:YES (Exclude ORES) 3:YES (Default YES) | This field will allow an additional prompt to confirm the provider
selection when adding new orders.
Entering 2 in this field will exclude holders of the ORES key
(providers) from this check.
Notice that these parameters also control the default presented to the user:
'Are you sure? | |
| 19 | show lab # | 0;18 | BOOLEAN | 0:NO 1:YES | This field controls the listing of lab orders for holders of the ORES key, after the electronic signature has been entered when entering new orders. If Physicians want to see the lab order # with the order after entering and signing the orders, this parameter must be set to YES. The Lab Order # is not displayed on the new orders screen. Only after the order is released to Lab service is the number assigned. All other users get the listing regardless of what this parameter is set to. | |
| 20 | package site parameters | 20;0 | MULTIPLE | 100.9901 | Here are the package specific parameters that can be modified by the installation site. | |
| 21 | electronic signature | 2;1 | BOOLEAN | 0:NO 1:YES | This field allows electronic signature functionality to be used. Use of this functionality requires some initial setup before it can be turned on. Users have to be assigned keys that allow them to perform verification steps in the order entry process. They also have to be given an electronic signature code. This also has an effect on who can be selected as the person requesting the order. | |
| 22 | electronic record | 2;2 | SET OF CODES | 0:NO 1:YES 2:YES (ALLOW S.O.C.) 3:YES (ALLOW S.O.C & WRITTEN) 4:YES (Exempt Service Entered) | A site can use this field to select 1 of 4 modes for Electronic Signature: 0>No change from current Electronic Signature functionality. 1>Yes All orders must be signed online. Signature on chart is not allowed All orders are filed initially with a signature status of Unsigned and a notification for electronic signature is sent to the ordering provider. 2>Yes (Allow S.O.C) All orders are signed online, but for those cases where an order is written and signed on the paper chart, you can so specify. Backdoor orders send a notification for electronic signature and require a signature, unless the order has a Nature of Order set to null. 3>Yes (Allow S.O.C. & Written) Is the same as option 2 except that it will allow orders sent from the ancillary packages with a nature of order of Written to be entered without requiring an electronic signature. 4>Yes (Exempt Service Entered) Is the same as option 2 except that it will allow orders sent from the ancillary packages that have not defined a nature of order to be entered without requiring an electronic signature. This is the way 'backdoor' orders were handled before the changes introduced with this new field (added with patch OR*2.5*46) were added. As of the release of patch OR*2.5*46 only Pharmacy and Lab have a way of dealing with the nature of order from the backdoor. So until the rest of the backdoor interfaces can deal with this, option 4 is the least disruptive method of evolution, and still get the enhancements for notification and signing of verbal orders. For options 1,2,3 & 4, the default for the prompt "Do you want to mark these orders as 'Signed on Chart'" is changed to NO. | |
| 23 | unsigned orders screen | 2;3 | SET OF CODES | 0:All 1:Select | This field controls the type of review screen that is used for new/unsigned orders. Without this parameter, the user has to sign all orders when entering new orders or presented with new /unsigned orders when leaving the review screen. Setting this parameter to 1 (Select) will force the use of the standard review screen of unsigned orders. This 'new' screen allow the user to select the order sign by number, range of numbers or all orders by entering the keyword "all" If a site sets the UNSIGNED ORDERS SCREEN parameter to Select, the default prompt for all users will be 'Accept Orders'. This default can be overridden for physicians (holders of the ORES key), by appropriately setting a new parameter, NEW ORDERS DEFAULT - PROVIDER to 1 - SIGN & RELEASE. | |
| 24 | new orders default - provider | 2;4 | SET OF CODES | 0:ACCEPT ORDERS 1:SIGN & RELEASE | This parameter determines the default prompt for providers when the UNSIGNED ORDERS SCREEN parameter is set to SELECT. The default is ACCEPT ORDERS. | |
| 25 | hospital site | 25;0 | MULTIPLE | 100.9925 | This field allows parameters to be set up for each location in the hospital that uses OE/RR. | |
| 26 | chart copy format | 2;6 | POINTER | 100.23 | This is the format used when printing chart copies of the orders for the hospital. | |
| 27 | chart copy header | 2;7 | POINTER | 100.23 | This is the format used to print the header of the chart copies of orders for the hospital. | |
| 28 | chart copy footer | 2;8 | POINTER | 100.23 | This is the format used to print the footer of the chart copies of orders for the hospital. | |
| 29 | expand continuous orders | 2;5 | SET OF CODES | 1:EXPAND ON CHART 0:DON'T EXPAND ON CHART | This is a site parameter to enable continuous orders (i.e., orders with a continuous schedule, e.g., QD or Q4H) to be expanded or not on the chart copy. If set to 1 (EXPAND ON CHART) an order for GLUCOSE BLOOD SERUM with the schedule QD would appear on the chart as: 05/17 11:04 GLUCOSE BLOOD SERUM Marcus Welby, MD LB #805 WC ROUTINE 05/18 11:04 GLUCOSE BLOOD SERUM Marcus Welby, MD LB #806 WC ROUTINE 05/19 11:04 GLUCOSE BLOOD SERUM Marcus Welby, MD LB #807 WC ROUTINE If instead, the field is set to 0 (DON'T EXPAND ON CHART) the same order would appear as: 05/17 11:04 GLUCOSE BLOOD SERUM QD Marcus Welby, MD 05/19 11:04 LB #805 WC ROUTINE | |
| 30 | stop dates for generic orders | 2;9 | BOOLEAN | 1:YES 0:NO | This field will be checked to decide whether stop dates should be prompted for when generic text orders are entered through OE/RR. An entry of YES will cause users to be prompted. | |
| 31 | default generic stop date | 2;10 | NUMERIC | This field will accept the number of days in the future that will determine the default stop date presented to users when placing generic orders. Example: An entry of 5 will cause the stop date presented to users to be 5 days from today. | ||
| 32 | notification to physician | 2;11 | SET OF CODES | 0:ALL 1:INPAT ATTENDING | This field controls the sending of notifications to attending and primary physicians. Set this field to 0 to have both the attending an primary physicians receive alerts for both inpatients and outpatients. Set this field to 1 to have only the attending physician receive alerts for only inpatients. The default is to have both attending and primary physician receive all alerts (0). In any case the ordering provider will always get the alert. | |
| 33 | last lab clean-up # | 2;12 | NUMERIC | This is the last order number that was processed as part of the Lab order cleanup option. | ||
| 34 | allow dc reason | 2;13 | BOOLEAN | 0:NO 1:YES | This field allows the user to enter a reason for entering a DC order. If the reason is DUPLICATE ORDER, then the order is simply DC'ed and no chart copies are printed or notifications sent. If the reason is CHANGE IN THERAPY, then chart copies and notifications are sent. DC's resulting from a CHANGE IN THERAPY are so noted in the text of the DC order. The order DC'ed will show the name & title of the user that DC'ed the order. There are 2 cases where the DC Reason prompt does not apply. DC'ing any Generic (text) order will not get the DC Reason prompt. Holders of the ORES key will not get the DC Reason prompt. | |
| 35 | allow dc reason backdoor | 2;14 | BOOLEAN | 0:NO 1:YES | This field allows the same functionality as the parameter: ALLOW DC REASON for orders DC'ed from the ancillary packages (backdoor). | |
| 36 | dc of generic orders | 2;15 | SET OF CODES | 0:WARD TRANSFER 1:SPECIALTY TRANSFER | This field controls the DC'ing of Generic orders. If this field is set to 1, then Generic orders are DC'ed only when a patient's Treating Specialty changes. If set to 0, then the Generic orders are DC'ed when the patient's Ward Location changes. The automatic DC'ing of orders only happens when one of the protocols OR GUA DC GEN ORD ON TRANS* are placed on the DGPM MOVEMENT EVENTS protocol. | |
| 37 | lapse days | 2;16 | NUMERIC | The Lab Order clean-up utility on the ORE MGR menu looks at this field to decide when to put pending lab orders with old start dates in a lapsed state. Orders with a Lapsed status (l) are no longer shown in the current orders context. This is used as a default for order clean-up. A new menu of clean-up utilities (ORE MGR) is being exported with items ORE XREF and ORE LAB ORDER CLEANUP. The ORE XREF (Clean-up OE/RR Cross References) option will check cross references in file 100 for accuracy. The ORE LAB ORDER CLEANUP (Clean-up Lab Orders in OE/RR and Lab files) option will check for inconsistencies between OR/RR and Lab files and attempts to correct them. The Lab Order clean-up utility on the ORE MGR menu looks at LAPSE DAYS to decide when to put pending lab orders with old start dates in a lapsed state. Orders with a Lapsed status (l) are no longer shown in the current orders context. Another parameters is being exported called LAST LAB CLEAN-UP. This holds the last ORIFN that was processed during the last clean-up, and is used as a default number to start with the next time the option is run. | ||
| 38 | restrict requestor | 2;17 | SET OF CODES | 0:NO 1:YES (ORELSE) 2:YES (ORELSE & OREMAS) | This field allows a site to restrict the selection of providers when adding new orders at the 'Requesting CLINICIAN: ' prompt for holders of the ORELSE and OREMAS key. The restriction being that they cannot select themselves as the requestor even though they may also hold the PROVIDER key. 1 YES (ORELSE) -restricts only holders of the ORELSE key. 2 YES (ORELSE & OREMAS) -restricts holders of either key. | |
| 39 | auto unflag | 2;18 | BOOLEAN | 0:NO 1:YES | This parameter, when set to YES, will automatically cancel the Flag Orders Notification and unflag all orders for a patient when a user process a Flagged Orders Notification. | |
| 101 | converted protocols | 101;0 | MULTIPLE | 100.99101 | This is a list of the protocols for which corresponding entries have been created in the Order Dialog file. | |
| 101.41 | unsuccessful dialogs | 101.41;0 | MULTIPLE | 100.99141 | This is a list of the protocols for which corresponding entries were not successfully created in the Order Dialog file. | |
| 200 | last user preference converted | 200;1 | NUMERIC | This field contains the last entry processed in the New Person file #200 when converting Add Orders menus in the post-init of CPRS. | ||
| 201 | conversion completed | 200;2 | BOOLEAN | 1:YES | This field is a flag to determine if the conversion of the Add Orders menus from the Protocol file to the Order Dialog file is completed. | |
| 300 | or3 patients to convert | PTCONV;0 | MULTIPLE | 100.9903 | This multiple will store patients that have not yet been converted by the OE/RR version 3.0 (CPRS) orders conversion. It is maintained by the conversion and should not be edited or updated. |
Not Referenced