| IA # | Name | Type | Custodial Package | Date Created | DBIC Approval Status | Status | Usage | File # | General Description | Remote Procedure | Routine | Date Activated |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IA # | Name | Type | Custodial Package | Date Created | DBIC Approval Status | Status | Usage | File # | General Description | Remote Procedure | Routine | Date Activated |
| 367 | DBIA367 | Routine | LIST MANAGER | 1994/03/09 | APPROVED | Active | Private | Request: Use of the routine calls REFRESH^VALM and RESET^VALM4:VALMCC Input: none Output: none Purpose: These calls are used to refresh the screen and reset the scrolling area while program control remains within an action (as opposed to performing the same action when exiting an action, which is accomplished by setting VALMBCK="R"). Request permission to set the variable VALM("PROTOCOL"). The purpose of setting this variable is to be able to define the specific protocol to be executed for a list template, as opposed to defining three identical list templates, all with different protocol menus. Resetting VALM("PROTOCOL") resets the protocol menu. This allows having the same list manager definitions for a screen that may have different input capabilities, for example one with input and one just view only actions. RESET^VALM4 can ONLY be called if VALMCC is high(1) The context for these calls are as follows: The calls will be made within a List Manager application, specifically within various options of the Encounter Form Utilities. The reason for making the calls is that we want to be able to display an encounter form in the top part of the screen while having a dialogue with the user in the bottom part of the screen. The problem is that it is necessary to call FileMan at certain points within the dialogue. FileMan assumes it has the entire screen at its disposal, so when it communicates with the user the display#is likely to scroll out of the scrolling area on the bottom of the screen, so the user is unable to read what FileMan displays. To avoid that, what we do is: 1) Everywhere FileMan is called in the situation described above we call FULL^VALM1. That sets the scrolling area to the entire screen. 2) When the problem point is passed and we want to continue the dialogue with the encounter form displayed at the top we call REFRESH^VALM to redraw the screen. Then we call RESET^VALM4 to reset the scrolling area so that the dialogue can occur on the bottom of the screen with the form displayed at the top. VALMCC is an input variable to RESET^VALM4. VALMCC must test true or RESET^VALM4 should not be called. There are dozens of variables that are set by the List Manager, but those are part of the internal workings of the List Manager and are not the concern of this application. There are some List Manager variables that the application is responsible for setting, but those are well documented by the List Manager, i.e., they are not specific to calling these entry points. The context is that the List Manager has been called. Then, from within the List Manager, the user has selected an action, which invokes a protocol. The protocol invokes a routine, which is where those calls are made. |
VALM | |||
| 1569 | TEXT INTEGRATION UTILITIES | Routine | LIST MANAGER | 1996/08/01 | APPROVED | Active | Private | TIU is using List Manager. For one of our LM displays, we need to display at the beginning of the screen a 60 character name, then 4 or 5 short fields, then a different 60 character name. Sites don't want either 60 character name truncated. Since the screen is only 80 characters wide, we need to set one scroll lock long enough to display a meaningful part of the name and still show our short fields, and then to set a second, very short scroll lock so we can display the whole second 60 character name with enough scroll locked to identify the entry. I have found that if I set VALM("FIXED") and VALMLFT, I can essentially set two different scroll locks, enabling me to display both 60 character names meaningfully. This also enables me to code a PRINT LIST Action which prints columns beyond page width on a separate page rather than wrapping them. Since we are using many columns beyond 80 characters, this is important to our users. For the sake of clarity, this was NOT a simple matter of setting those two variables: I also had to rewrite for TIU the Scroll Right/Left actions and the Print List Action rather than use the actions LM exports. TIU requests a private Integration Agreement with List Manager to read and set the variables VALMLFT and VALM("FIXED"). We understand that if/when LM adds functionality affecting these variables, we would need to rewrite portions of our code. |
VALM | |||
| 2334 | DBIA2334 | Routine | LIST MANAGER | 1998/03/04 | APPROVED | Active | Controlled Subscription | Inpatient Medications requests permission to call RESET^VALM4 (List Manager). This entry point allows the use of the ListMan standard protocol VALM TURN ON/OFF MENUS ( Auto-Display(On/Off) )to toggle between a normal and expanded screen length. In each Inpatient Medications Protocol HEADER field, a call is made that declares a short and long screen length and makes the call to RESET^VALM4. Each time the user executes the VALM TURN ON/OFF MENUS protocol, the protocol choices at the bottom of the screen are removed or brought back and the screen length is adjusted accordingly. During the Alpha testing of Inpatient Medications 5.0 and CPRS 1.0 at Tuscaloosa AL and West Palm Beach FL, this ability to expand the ListMan screen viewing area brought extreme positive feedback from the users. |
VALM4 | |||
| 2615 | TERM OF VALM0 | Routine | LIST MANAGER | 1998/10/19 | APPROVED | Active | Private |
Inpatient Medications requests an integration agreement with List Manager to call TERM^VALM0. This call is to set the variables that determine terminal characteristics. |
VALM0 | |||
| 2684 | OE/RR needs to save/restore LM video attributes | Other | LIST MANAGER | 1998/12/31 | APPROVED | Active | Private | List Manager maintains video attributes in ^TMP("VALM VIDEO". Within Order Entry/Results Reporting and Consult/Request Tracking, list manager is used extensively. One of the key features used is to have list manager actions which envoke other list manager displays. An example would be entering CPRS on the patient selection screen, selecting a patient and getting the cover sheet, selecting to change ot the orders tab (another screen), and adding orders (yet another screen). In order to maintain the video attributes of a particular display, it's necessary for OE/RR and Consults to save off the values in ^TMP("VALM VIDEO" prior to changing screens and kill existing values and restore them when returning. Saving/restoring of this data is done with the MERGE command. This DBIA requests authorization to access the ^TMP("VALM VIDEO",$J) data, kill it, and reset it based on previous values. |
||||
| 4736 | TERM SETUP | Routine | LIST MANAGER | 2005/07/20 | APPROVED | Active | Private | HIPAA Electronic Claims requests an integration agreement with List Manger to call TERM^VALM0. Call will set up variables needed by the Claims Data Entry Screen. |
VALM0 | |||
| 5435 | VALM1 (PRT,PRTL) | Routine | LIST MANAGER | 2009/05/01 | Withdrawn | Private | Outpatient Pharmacy requests an integration agreement to call line tags PRT and PRTL of VALM1. |
VALM1 | ||||
| 5436 | VALM2 (HELP,MENU) | Routine | LIST MANAGER | 2009/05/01 | Withdrawn | Private | Outpatient Pharmacy requests an integration agreement to call line tags HELP and MENU of VALM2. |
VALM2 | ||||
| 5437 | VALM4 (FIRST,LAST,NEXT,PREV) | Routine | LIST MANAGER | 2009/05/01 | Withdrawn | Private | Outpatient Pharmacy requests an integration agreement to call line tags FIRST, LAST, NEXT and PREV of VALM4. |
VALM4 | ||||
| 5438 | VALM40 (DOWN,FIND,GOTO,LEFT,RIGHT,UP) | Routine | LIST MANAGER | 2009/05/01 | Withdrawn | Private | Outpatient Pharmacy requests an integration agreement to call line tags DOWN, FIND, GOTO, LEFT, RIGHT and UP of VALM40. |
VALM40 | ||||
| 5451 | VALM HIDDEN ACTIONS protocol | Other | LIST MANAGER | 2009/05/13 | APPROVED | Active | Supported | Supported actions entries in the VALM HIDDEN ACTIONS protocol. |
2009/06/11 | |||
| 5513 | HDI PATCH 10 PREINSTALL CLEANUP | File | LIST MANAGER | 2009/12/10 | Pending | Supported | 409.61 | The pre-install routine (HDI1010I) deletes all but the zero node of the List Manager (LM) Templates for the Generic Mapping Tool and Text File Deployment Tool. This is to overcome a problem in KIDS where LM templates are not updated when re-installed. |
||||
| 10118 | VALM | Routine | LIST MANAGER | APPROVED | Active | Supported | VALM | |||||
| 10120 | VALM4 | Routine | LIST MANAGER | APPROVED | Active | Supported | VALM4 |