| 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 |
| 346 | DBIA346-A | File | TOOLKIT | 1994/02/04 | APPROVED | Active | Private | 8984.1 |
Read only access to ^XT(8984.* globals for $D checks in the Environment Check routine prior to installing the Clinical Lexicon (GMPTIENV). i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not found" K DIFQ Q Read/Write access to ^XT(8984.* global in Post-Init routines to setup the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST). i.e., a. Seeding the Local Look-Up file #8984.4 with the Clinical Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT display routine. b. Seeding the Synonym file #8984.3 with Cancer as a sample synonym for Carcinoma c. Seeding the Short Cut file #8984.2 with DM II as a sample short cut for Diabetes Mellitus, Non-Insulin Dependent |
|||
| 391 | DBIA391 | File | TOOLKIT | 1994/03/16 | APPROVED | Active | Private | 8984.1 | AMIE v2.6 will be using the MTLU functionality from the Kernel tool kit in order to do a look up on the Disability Condition file (#31). As part of the functionality provided to the users, there needs to be a set of distributed Keywords, Synonyms and short cuts. AMIE would like to distribute these lists in,a post init fashion with little to no user intervention. |
|||
| 392 | DBIA392 | File | TOOLKIT | 1994/03/16 | APPROVED | Active | Private | 8984.2 | AMIE v2.6 will be using the MTLU functionality from the Kernel tool kit in order to do a look up on the Disability Condition file (#31). As part of the functionality provided to the users, there needs to be a set of distributed Keywords, Synonyms and short cuts. AMIE would like to distribute these lists in a post init fashion with little to no user intervention. |
|||
| 393 | DBIA393 | File | TOOLKIT | 1994/03/16 | APPROVED | Active | Private | 8984.3 | AMIE v2.6 will be using the MTLU functionality from the Kernel tool kit in order to do a look up on the Disability Condition file (#31). As part of the functionality provided to the users, there needs to be a set of distributed Keywords, Synonyms and short cuts. AMIE would like to distribute these lists in a post init fashion with little to no user intervention. |
|||
| 394 | DBIA394 | File | TOOLKIT | 1994/03/16 | APPROVED | Active | Private | 8984.4 | AMIE v2.6 will be using the MTLU functionality from the Kernel tool kit in order to do a look up on the Disability Condition file (#31). As part of the functionality provided to the users, there needs to be a set of distributed Keywords, Synonyms and short cuts. AMIE would like to distribute these lists in a post init fashion with little to no user intervention. |
|||
| 854 | DBIA346-B | File | TOOLKIT | 1994/02/04 | APPROVED | Active | Private | 8984.2 |
Read only access to ^XT(8984.2,"B" and the associated data node ^XT(8984.2,DA,0) If the user input is found in the "B" cross-reference, and it is a valid "Short Cut" for the Clinical Lexicon - ^XT(8984.2,DA,0)[GMP(757.01 - then the preprocessing of the input string is disabled and the Multi-Term Look-Up Utility (MTLU) is called directly (GMPTA2). Read only access to ^XT(8984.* globals for $D checks in the Environment Check routine prior to installing the Clinical Lexicon (GMPTIENV). i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not found" K DIFQ Q Read/Write access to ^XT(8984.* global in Post-Init routines to setup the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST). i.e., a. Seeding the Local Look-Up file #8984.4 with the Clinical Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT display routine. b. Seeding the Synonym file #8984.3 with Cancer as a sample synonym for Carcinoma c. Seeding the Short Cut file #8984.2 with DM II as a sample short cut for Diabetes Mellitus, Non-Insulin Dependent |
|||
| 855 | DBIA346-C | File | TOOLKIT | 1994/02/04 | APPROVED | Active | Private | 8984.3 |
Read only access to ^XT(8984.* globals for $D checks in the Environment Check routine prior to installing the Clinical Lexicon (GMPTIENV). i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not found" K DIFQ Q Read/Write access to ^XT(8984.* global in Post-Init routines to setup the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST). i.e., a. Seeding the Local Look-Up file #8984.4 with the Clinical Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT display routine. b. Seeding the Synonym file #8984.3 with Cancer as a sample synonym for Carcinoma c. Seeding the Short Cut file #8984.2 with DM II as a sample short cut for Diabetes Mellitus, Non-Insulin Dependent |
|||
| 856 | DBIA346-D | File | TOOLKIT | 1994/02/04 | APPROVED | Active | Private | 8984.4 |
Read only access to ^XT(8984.* globals for $D checks in the Environment Check routine prior to installing the Clinical Lexicon (GMPTIENV). i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not found" K DIFQ Q Read/Write access to ^XT(8984.* global in Post-Init routines to setup the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST). i.e., a. Seeding the Local Look-Up file #8984.4 with the Clinical Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT display routine. b. Seeding the Synonym file #8984.3 with Cancer as a sample synonym for Carcinoma c. Seeding the Short Cut file #8984.2 with DM II as a sample short cut for Diabetes Mellitus, Non-Insulin Dependent |
|||
| 857 | DBIA346-E | Other | TOOLKIT | 1994/02/04 | Retired | Private |
Agreement is to add XTLK name-spaced Option XTLKUSER2 to the GMPT CLINICAL LEXICON MGT MENU so managers can add keywords, short-cuts and synonyms to the ^XT(8984.* files without leaving the Clinical Lexicon Manager menu. |
|||||
| 887 | MTLU setup | File | TOOLKIT | 1994/05/16 | APPROVED | Active | Controlled Subscription | 8984.4 | The Clinical Lexicon Utility needs to write to the Kernel Toolkit Multi-Term Look-up Utility's (MTLU) files/DDs during the Post-Init. |
|||
| 890 | MTLU setup | File | TOOLKIT | 1994/05/16 | APPROVED | Active | Controlled Subscription | 8984.2 | The Clinical Lexicon Utility needs to write to the Kernel Toolkit Multi-Term Look-up Utillity's (MTLU) files/DDs during the Post-Init. |
|||
| 891 | MTLU setup | File | TOOLKIT | 1994/05/16 | APPROVED | Active | Controlled Subscription | 8984.3 | The Clinical Lexicon Utility needs to write to the Kernel Toolkit Multi-Term Look-up Utility's (MTLU) files/DDs during the Post-Init. |
|||
| 2075 | DBIA2075 | Routine | TOOLKIT | 1997/08/20 | APPROVED | Active | Supported | This agreement expands agreement 10095 for XTKERMIT. This agreement allows access to the KERMIT HOLDING file (#8980) and the API that adds entries to it, RFILE^XTKERM4. The "AOK" cross-reference of the KERMIT HOLDING file (#8980) may be checked to see if the user has an entry in the KERMIT HOLDING file (#8980). If not, RFILE^XTKERM4 may be called to add an entry to the file. |
XTKERM4 | |||
| 2078 | DBIA2078 | File | TOOLKIT | 1997/08/20 | APPROVED | Active | Private | 8980 | Integration Agreement to read the "AOK" cross reference and check for the existence of the ^DIZ(8980,"AOK",DUZ) cross-reference. If not, data is added to the KERMIT HOLDING file (#8980) via the RFILE^XTKERM4 entry point. |
|||
| 2213 | XRTL SET TO FORCE RESPONSE TIME MONITORING | Other | TOOLKIT | 1997/10/29 | APPROVED | Active | Private | XRTL=1 is a flag that allows response time monitoring. It is typically set during signon based on a flag in the Kernel Site Parameter file. Because resource utilization must be monitored closely in the new client/server environment, the RPC Broker needs to NEW and SET the XTRL variable in its code. This will allow for the monitoring of all RPCs. (The README file that accompanies version 1.1 of the RPC Broker notifies IRM staff that the monitoring is being turned on.) When sufficient data has been collected the SETting of XTRL will be removed by a patch. |
||||
| 2263 | SUPPORTED PARAMETER TOOL ENTRY POINTS | Routine | TOOLKIT | 1998/01/11 | APPROVED | Active | Supported | Parameter Tools is a generic method of handling parameter definition, assignment, and retrieval. A parameter may be defined for various entities where an entity is the level at which you want to allow the parameter defined (e.g. package level, system level, division level, location level, user level, etc.). A developer may then determine in which order the values assigned to given entities are interpreted. The following are some basic definitions used by Parameter Tools: Entity: ======= An entity is a level at which you can define a parameter. The entities allowed are stored in the Parameter Entity file (#8989.518). The list of allowable entities at the time this utility was released were: Prefix Message Points to File ------- ---------- ------------------------ PKG Package Package (9.4) SYS System Domain (4.2) DIV Division Institution (4) SRV Service Service/Section (49) LOC Location Hospital Location (44) TEA Team Team (404.51) CLS Class Usr Class (8930) USR User New Person (200) BED Room-Bed Room-Bed (405.4) OTL Team (OE/RR) OE/RR List (101.21) (Note: entries will be maintained via ToolKit patches. Entries existing in the file at the time it is referenced are considered supported.) Parameter: ========== A parameter is the actual name which values are stored under. The name of the parameter must be namespaced and it must be unique. Parameters can be defined to store the typical package parameter data (e.g. the default add order screen in OE/RR), but they can also be used to store GUI application screen settings a user has selected (e.g. font or window width). When a parameter is defined, the entities which may set that parameter are also defined. The definition of parameters is stored in the PARAMETER DEFINITION file (#8989.51). Value: ====== A value may be assigned to every parameter for the entities allowed in the parameter definition. Values are stored in the PARAMETERS file (#8989.5). Instance: ========= Most parameters will set instance to 1. Instances are used when more than one value may be assigned to a given entity/parameter combination. An example of this would be lab collection times at a division. A single division may have multiple collection times. Each collection time would be assigned a unique instance. Parameter Template: =================== A parameter template is similar to an input template. It contains a list of parameters that can be entered through an input session (e.g. option). Templates are stored in the Parameter Template file (#8989.52). Entries in this file must also be namespaced. This integration agreement defines the callable entry points in routine XPAR. |
XPAR | 2012/11/09 | ||
| 2335 | OE/RR CALL TO XPAR FOR BACKWARDS COMPATIBILITY | Routine | TOOLKIT | 1998/05/11 | APPROVED | Active | Private | This DBIA is a private agreement between OE/RR and the Parameter Tools portion of Toolkit to allow a call to PUT1^XPAR. This is needed until Radiology converts to using XPAR calls directly. Parameter Tools functionality was originally in the ORXP namespace, but was later moved to the XPAR namespace. |
XPAR | |||
| 2336 | SUPPORTED CALLS TO XPAREDIT | Routine | TOOLKIT | 1998/05/11 | APPROVED | Active | Supported | This DBIA contains a list of calls which are supported for use. The calls are part of the Parameter Tools component of Toolkit. Parameter Tools is a generic method of handling parameter definition, assignment, and retrieval. See DBIA 2263 for the main entry points to this module. This DBIA contains calls to XPAREDIT which contain some additional utilities to for editing parameters. |
XPAREDIT | |||
| 2338 | DBIA2338 | Routine | TOOLKIT | 1998/05/11 | APPROVED | Active | Controlled Subscription | During special processing related to the Patient Merge, the routine IBAXDR needs to call the entry point SAVEMERG^XDRMERGB. This call is used to save the file image of an entry involved in the merge process when only one of the entries (the entry being merged or the entry being merged into) is present in [FILENUM]. Normally, the merge process would handle when it can identify a FROM or a TO entry which is not present based on the DINUMed values. For [FILENUM], however, the internal entry numbers are determined from the "B"-cross- reference, and missing entries need to be handled separately. |
XDRMERGB | |||
| 2365 | Merge File Entries | Routine | TOOLKIT | 1998/04/27 | APPROVED | Active | Supported |
Overview A file in which entries need to be merged may be entered in the DUPLICATE RESOLUTION file (file 15.1). This requires adding the file as one which can be selected as the variable pointer, and search criteria would usually need to be specified to assist in identifying potential duplicate pairs (although an option can be use by which selected pairs can be added directly to the DUPLICATE RECORD file as verified duplicates). Verified duplicate pairs may be approved for merging, and a merge process generated for those approved pairs. A DUPLICATE RECORD file entry will also have handle files which are not associated as normal pointers identified in the PACKAGE file under the 'AFFECTS RECORD MERGE' subfile with special processing routines. ***IF A FILE HAS RELATED FILES WHICH ARE NOT NORMAL POINTERS, THEY SHOULD BE HANDLED ONLY AS ENTRIES IN THE DUPLICATE RECORD FILE AND THE TOOLKIT OPTIONS USED FOR MERGES INVOLVING THE FILE.*** The merge utility of Kernel Toolkit as revised by patch XT*7.3*23 provides an entry point which is available to developers for the merging of one or more pairs of records (a FROM record and a TO record) in a specified file. The merge process me rges the data of the FROM record into that of the TO record and deletes the FROM record, restoring by a hard set only the zero node with the .01 value on it until the merge process is completed (such that any references to that location via pointers will not error out). Any files which contain entries DINUMed with the data pairs are then also merged (and any files which are related to them by DINUM as well). Any pointers which can be identified rapidly by cross-references are modifie d so that references for the FROM entry become references to the TO entry instead. Following this, any files which contain other pointers are searched entry by entry to test for pointers to a FROM entry, and when found are modified to reference the TO entry. This search for pointer values is the most time consuming part of the entire process and may take an extended period depending upon the number of files that must be searched, the number of entries in those files, and how many levels of subfiles pointers may be located at. Since the search through these files will take the same period of time independent of the number of pairs which are being merged, it is suggested that as many pairs as convient be combined in one proc ess. At the end of the conversion of these pointers, the zero node stubs will be removed from the primary file and all related DINUMed files. The merge process is a single job which is tracked with frequent updates on location and status from start to finish. The job can be stopped at any time if necessary using Task Manager utilities (or in the event of a system crash, etc.) and restarted at the point of interruption at a later time. The manner in which data is merged. When a primary file or a DINUMed files entries are merged, any top level (single value) fields which are present in the FROM entry which are not present in the TO entry will be merged into the TO entries data. Any of these fields which contain cross-references will be entered using a VA File Manager utility (FILE^DIE) so that the cross-references will be fired. Other fields (those without cross-references) will be directly set into the data global. If a subfile entry exists in the FROM record which is not present in the TO record (as identified by the .01 value), that entry will be created with a VA File Manager utility (UPDATE^DIE) and the rest of the subfile merged over into the TO record and the cross-references within the subfile and any descendent subfiles run. If a subfile entry exists in the FROM record and an identical .01 value exists in the TO record, the subfile in the FROM record will be searched for any descendent subfiles which are not present in the TO record subfile. If such a subfile is found it will be merged into the subfile in the TO record and any cross-references in the merged subfile run. For fields which are simple pointers to the primary file (or any other file DINUMed to the primary file) the reference to the FROM record will be changed to a reference to the TO record. If the field contains a cross-reference this editing will be performed using a VA File Manager Utility call (FILE^DIE), otherwise it will be set directly into the global node. |
XDRMERG | |||
| 2532 | DBIA2532 | File | TOOLKIT | 1998/09/04 | APPROVED | Active | Private | 15 | In routine RGMTDPCT, CIRN counts duplicate entries for the PATIENT file (#2) in the DUPLICATE RECORD file (#15) by STATUS or MERGE STATUS It then counts the match percentile for the following: For STATUS it matches on (P) potential duplicates, (N) verified, notduplicate, (V) verified duplicate, (X) verified in progress, and (R) required review. For MERGE STATUS the matches are counted on (0) not ready, (1) ready, (2) merged, and (3) in progress. In routine RGMTDPSC, CIRN searches file #15 for duplicate pairs and displays this information by the CIRN Master of Record (CMOR) activity score range. The ranges are in 100'2 with a separate range for pairswhere both members have no score and where both members have zero score or one member has a zero score and the other has no score. The reports will give sites an idea of the active patients (with a CMOR score, incl 0) that are deemed duplicates. File: DUPLICATE RECORD (#15) ^VA(15,D0,0) .01 RECORD1 0;1 Direct Global Read .02 RECORD2 0;2 Direct Global Read .03 STATUS 0;3 Direct Global Read .05 MERGE STATUS 0;5 Direct Global Read |
|||
| 2685 | OE/RR direct reference to XTV(8989.51 | File | TOOLKIT | 1998/12/31 | APPROVED | Active | Private | 8989.51 | Within OE/RR, it's necessary to determine a parameter definitions IEN. To do this, the 'B' index of the PARAMETER DEFINITION file (#8989.51) is utilized. |
|||
| 2686 | OE/RR direct reference to XTV(8989.5 | File | TOOLKIT | 1998/12/31 | APPROVED | Active | Controlled Subscription | 8989.5 | Within OE/RR, it's necessary to determine if a parameter is in use. To do this, the parameter definition IEN is determined based on the 'B' index of the PARAMETER DEFINITION file (#8989.51) (see DBIA 2685). Using that IEN, the 'AC' x-ref in the PARAMETERS file (#8989.5) is utilized to determine if any parameter entity is set to a given value. If so, deletion of the item is prohibited. In addition, a one time patch post-install routine (ORY27) used this x-ref when populating a new parameter value based on an existing value. |
|||
| 2839 | CPRS USE OF XPAR MENU | Other | TOOLKIT | 1999/06/03 | APPROVED | Active | Private | CPRS is requesting the ability to attach the XPAR MENU TOOLS menu to the CPRS Configuration (IRM) menu. This will allow IRM users to get to the tools menu for XPAR when editing using other CPRS-related IRM tools. |
||||
| 2917 | DBIA2917 | Routine | TOOLKIT | 1999/09/23 | Retired | Private |
During special processing related to the Patient Merge, the routine PRCAMRG needs to call the entry point SAVEMERG^XDRMERGB. This call is used to save the file image of an entry involved in the merge process when only one of the entries (the entry being merged or the entry being merged into) is present in file 340. Normally, the merge process would handle when it can identify a FROM or a TO entry which is not present based on the DINUMed values. For file 340, however, the internal entry numbers are determined from the "B"-cross- reference, and missing entries need to be handled separately. Retired and placed under IA 2338. |
XDRMERGB | ||||
| 2992 | PARAMETER DEFINITIONS | File | TOOLKIT | 1999/11/23 | APPROVED | Active | Supported | 8989.51 | Parameter Tools is a generic method of handling parameter definition, assignment, and retrieval. A parameter may be defined for various entities where an entity is the level at which you want to allow the parameter defined (e.g. package level, system level, division level, location level, user level, etc.). A developer may then determine in which order the values assigned to given entities are interpreted. Parameter: ========== A parameter is the actual name which values are stored under. The name of the parameter must be namespaced and it must be unique. Parameters can be defined to store the typical package parameter data (e.g. the default add order screen in OE/RR), but they can also be used to store GUI application screen settings a user has selected (e.g. font or window width). When a parameter is defined, the entities that may set the parameter is also defined. The definition of parameters is stored in the PARAMETER DEFINITION file (#8989.51). KIDS exports them. |
|||
| 3127 | DBIA3127 | File | TOOLKIT | 2000/06/01 | APPROVED | Active | Controlled Subscription | 8989.51 | Requesting read access/fileman to all fields in the PARAMETER DEFINITION FILE (#8989.51) to retrieve the Clinical Procedures Parameter definitions. Clinical Procedures is a strictly GUI application and includes a Manager executable to setup and maintain site files and system parameters. Additionally a lookup on the parameter definition file by name screening by Entity Type allow for retrieval of all parameters for a specific entity (i.e. Division) and display/update of these values. With the information retrived from file 8989.51 this application dynamically configures input screens for the user and sends data back to the server for the XPAR API's to add/edit/delete parameter values in the XPAR utilities. Access is read-only via GETS^DIQ, GET1^DIQ, FIND^DIC, and FIND1^DIC and is programmed to only allow access to parameters in the subscribing package namespace. |
|||
| 3168 | DBIA3168 | Routine | TOOLKIT | 2000/08/16 | APPROVED | Active | Private | CIRN needs to use the Toolkit routine call RMOVPAIR^XDRDVAL1 to remove pairs from the merge process based on CIRN Exceptions. |
XDRDVAL1 | |||
| 3197 | XQALBUTL | Routine | TOOLKIT | 2000/09/19 | APPROVED | Active | Supported | The DELSTAT entry point in XQALBUTL is a SUPPORTED reference for obtaining information on the recipients of the most recent alert with a specified alert id and the status of whether the alert has been deleted or not for those recipients. DELSTAT - For the most recent alert with XQAIDVAL as the PackageID passed in, on return array VALUES contains the DUZ for users in VALUES along with an indicator of whether the alert has been deleted or not, e.g., DUZ^0 if not deleted or DUZ^1 if deleted. Note that contents of VALUES will be killed prior to building the list. Example: D DELSTAT^XQALBUTL("OR;14765;23",.RESULTS) Returned: The value of RESULTS indicates the number of entries in the array. The entries are then ordered in numerical order in the RESULTS array. RESULTS = 3 RESULTS(1) = "146^0" User 146 - not deleted RESULTS(2) = "297^1" User 297 - deleted RESULTS(3) = "673^0" User 673 - not deleted |
XQALBUTL | |||
| 3228 | VIEW MERGE IMAGES FOR FEE BASIS | File | TOOLKIT | 2000/10/18 | APPROVED | Active | Private | 15.4 | This integration agreement permits the patch FB*3.5*19 post install to examine data in the MERGE IMAGES (#15.4) file. This data will be used to identify and correct problems in the Fee Basis software that may have occurred when patients were merged before installation of patch FB*3.5*19. In addition to reading data in the global, the post install will loop (using $Order) through the following parts of the XDRM global to locate the Fee Basis data. XDRM(D0) loop thru all patient pairs in MERGED IMAGES file XDRM(D0,1,"B", loop thru FROM FILE# "B" x-ref to locate Fee files XDRM(D0,1,D1,1,D2) loop thru GLOBAL DATA for a specific FROM FILE XDRM(D0,2,"B", loop thru TO FILE# "B" x-ref to locate Fee files XDRM(D0,2,D1,1,D2) loop thru GLOBAL DATA for a specific TO FILE XDRM(D0,3,"B", loop thru POINTERS CHANGED "B" x-ref to find Fee files Data in the MERGE IMAGES fill will not be modified under this integration agreement. |
|||
| 3407 | DEFINITIONS AND ENTITIES | File | TOOLKIT | 2001/06/05 | Pending | Controlled Subscription | 8989.51 | |||||
| 3408 | PARAMETER ENTITY | File | TOOLKIT | 2001/06/05 | APPROVED | Active | Controlled Subscription | 8989.518 | 2001/06/30 | |||
| 3524 | XDRDFPD | Routine | TOOLKIT | 2002/02/14 | APPROVED | Active | Private | This integration agreement is for access from the top of the routine XDRDFPD. Entry at this location will result in the user being prompted for a specific file to check for duplicate entries, then prompted for a specific entry within that file. To proceed there must be an entry for the selected file in the DUPLICATE RESOLUTION file (#15.1). The routine then checks other entries within the specified file to determine whether they are potential duplicates based upon the information and routines specified in the DUPLICATE TESTS sub-file (field #1100) for the specified file. Entries which are identified as potential duplicates are entered into the DUPLICATE RECORD file (#15). |
XDRDFPD | |||
| 3525 | EN XDRDFPD | Routine | TOOLKIT | 2002/02/14 | APPROVED | Active | Private | This entry point provides the ability to perform a search on a specified file for potential duplicates to a specified file entry, using user specified criteria in the DUPLICATE RESOLUTIION file (#15.1). The routine creates entries in the DUPLICATE RECORD file (#15) of potential duplicates identified for subsequent verification. The users must create an entry in the DUPLICATE RESOLUTION file for the file that will be analyzed. This entry must include data in the CANDIDATE COLLECTION ROUTINE field (#.09) which will specify the routine to be used as the basis for identifying those that might be potential duplicates. These candidates are then compared using the data and routines specified in the DUPLICATE TESTS sub-file (field #1100) for the analyis. The weighted result from these tests is then compared to the POTENTIAL DUPLICATE THRESHOLD% value to determine if an entry should be considered a potential duplicate and entered into the DUPLICATE RECORD file. |
XDRDFPD | |||
| 3526 | SETUP XDRDFPD | Routine | TOOLKIT | 2002/02/14 | APPROVED | Active | Private | Master Patient Index Austin is utilizing the Duplicate Record Merge software from within Kernel Toolkit to search for patients already existing in the index. |
XDRDFPD | |||
| 3527 | CHECK XDRDMAIN | Routine | TOOLKIT | 2002/02/14 | APPROVED | Active | Private | Master Patient Index Austin is utilizing the Duplicate Record Merge software from within Kernel Toolkit to search for patients already existing in the index. |
XDRDMAIN | |||
| 3528 | FILE XDRDQUE | Routine | TOOLKIT | 2002/02/14 | APPROVED | Active | Private | Master Patient Index Austin is utilizing the Duplicate Record Merge software from within Kernel Toolkit to search for patients already existing in the index. |
XDRDQUE | |||
| 3561 | M XML PARSER | Routine | TOOLKIT | 2003/07/03 | APPROVED | Active | Supported | This utility provides a M based XML version 1.0 parser. It supports both the SAX interface and the DOM interface. |
MXMLDOM | |||
| 3985 | Direct access to 8989.5 and 8989.51 | File | TOOLKIT | 2003/02/25 | APPROVED | Active | Private | 8989.5 | As part of the installation of patch OR*3*141 (GUI v20), 4 CPRS parameters became obsolete and were deleted. However, the parameters were deleted directly and their corresponding entities were not removed before the parameters were deleted. Patch OR*3*177 will include a post-init (ORY177) that will go through file 8989.5 and identify any system level entities that are pointing to non-existent entries in 8989.51. The entries from 8989.5 will then be deleted. |
|||
| 3995 | File 8989.5 | File | TOOLKIT | 2003/03/12 | Withdrawn | Private | 8989.5 | |||||
| 4123 | 4123 | File | TOOLKIT | 2004/08/24 | APPROVED | Active | Private | 409.61 | If a List template has been distributed to a site and subsequent changes are made and KIDS is used to send the updated version, IT DOES NOT UPDATE to the new version but the old version is left in place. This gives the subscriber permission to directly KILL an entry and SET the zero node of file 409.61 (LIST TEMPLATE). This includes the use of the "B" cross reference. |
|||
| 4149 | M XML EVENT-DRIVEN API | Routine | TOOLKIT | 2003/07/03 | APPROVED | Active | Supported | An event-driven interface that is modeled after the widely used SAX interface specification. In this implementation, a client application provides a special handler for each parsing event of interest. When the client invokes the parser, it conveys not only the document to be parsed, but also the entry points for each of its event handlers. As the parser progresses through the document, it invokes the client's handlers for each parsing event for which a handler has been registered. |
MXMLPRSE | |||
| 4153 | MXMLUTL | Routine | TOOLKIT | 2003/07/15 | APPROVED | Active | Supported | Utility API's to help when building XML messages. |
MXMLUTL | 2011/05/13 | ||
| 4164 | XPARDD | Routine | TOOLKIT | 2003/07/29 | APPROVED | Active | Private | The HealtheVet Desktop allows the setting and changing of parameter values that control its behavior from within the application itself; since this is a GUI application it must do its own presentation and thus needs access to some lower-level calls to manipulate those values. |
XPARDD | |||
| 4165 | XPARLIST | Routine | TOOLKIT | 2003/07/29 | APPROVED | Active | Private | The HealtheVet Desktop allows the setting and changing of parameter values that control its behavior from within the application itself; since this is a GUI application it must do its own presentation and thus needs access to some lower-level calls to manipulate those values. |
XPARLIST | |||
| 4325 | NATIONAL TIU MONITOR | Routine | TOOLKIT | 2004/01/06 | APPROVED | Active | Private | A software package to monitor CPRS GUI response time for data retrievals of Lab, TIU and Clinical Reminders. |
AWCMCPR1 | |||
| 4631 | VHA UNIQUE ID (VUID) API | Routine | TOOLKIT | 2005/05/06 | APPROVED | Active | Supported | API to handle the storage and retrieval of VUID-assigned data for terms/concepts. Please consult the VistA document library online to browse examples of its use. |
XTID | 2009/06/17 | ||
| 4690 | XDRDVALF variable | Other | TOOLKIT | 2005/06/21 | APPROVED | Active | Controlled Subscription | The XDRDVALF variable is defined during the MERGE process, and can be used to determine whether changes which are being seen are the result of a merge process. |
||||
| 4797 | MTLU Setup for Code Sets | File | TOOLKIT | 2005/09/21 | Pending | Controlled Subscription | 8984.4 | The Lexicon Utility needs to write to the Kernel Toolkit Multi-Term Look-up Utility's (MTLU) files during a KIDS install/post-init. |
||||
| 4809 | DBIA4809 | File | TOOLKIT | 2005/10/12 | APPROVED | Active | Private | 8985.1 | This DBIA is a one time request to permit the HDI application to scan the EFFECTIVE DATE/TIME Multiple (subfile #8985.11) of the XTID VUID FOR SET OF CODES file (#8985.1) for consecutive storage of the same status using a Direct Global Read. The M code is in the routine HDI1002A which is being invoked in the post-installation of patch HDI*1.0*2. If a duplicate status entry is found, the FileMan M routine ^DIK is used to delete the EFFECTIVE DATE/TIME multiple entry. The HDI1002A routine can be deleted after the patch is successfully installed. This is a one time request since future updates to the file will not result in redundant status entries being created. |
|||
| 5078 | API Set for Data Standardization | Routine | TOOLKIT | 2008/01/23 | APPROVED | Active | Supported | High Level Examples Assume the following replacement relationships: A --> B --> C --> D A is replaced by B G is replaced by C ^ ^ ^ ^ B is replaced by C H is replaced by C | \ | \ C is replaced by D I is replaced by F | \ | \ D has no replacement J is replaced by F | \ | \ E is replaced by A K is replaced by H | F | H F is replaced by A L is replaced by H | ^ ^ | ^ ^ | / \ | / \ E I J G K L $$GETRPLC(B) would return C $$RPLCMNT(B) would return D $$RPLCVALS(J) would return the requested field values from entry D $$RPLCTRL(G) in both directions would return D and the output array would be set as follows: OutArr("BY",A) = B OutArr("FOR",A,E) = "" OutArr("BY",B) = C OutArr("FOR",A,F) = "" OutArr("BY",C) = D OutArr("FOR",B,A) = "" OutArr("BY",D) = "" OutArr("FOR",C,B) = "" OutArr("BY",E) = A OutArr("FOR",C,G) = "" OutArr("BY",F) = A OutArr("FOR",C,H) = "" OutArr("BY",G) = C OutArr("FOR",D,C) = "" OutArr("BY",H) = C OutArr("FOR",F,I) = "" OutArr("BY",I) = F OutArr("FOR",F,J) = "" OutArr("BY",J) = F OutArr("FOR",H,K) = "" OutArr("BY",K) = H OutArr("FOR",H,L) = "" OutArr("BY",L) = H $$RPLCTRL(L) in the forward direction would return D and the output array would be set as follows: OutArr("BY",C) = D OutArr("FOR",C,H) = "" OutArr("BY",D) = "" OutArr("FOR",D,C) = "" OutArr("BY",H) = C OutArr("FOR",H,L) = "" OutArr("BY",L) = H $$RPLCTRL(B) in the backward direction would return D and the output array would be set as follows: OutArr("BY",A) = B OutArr("FOR",A,E) = "" OutArr("BY",E) = A OutArr("FOR",A,F) = "" OutArr("BY",F) = A OutArr("FOR",B,A) = "" OutArr("BY",I) = F OutArr("FOR",F,I) = "" OutArr("BY",J) = F OutArr("FOR",F,J) = "" $$RPLCLST(G) in both directions would return D and the output array would be set as follows: OutArr(1) = G ^ 0 OutArr("INDEX",A) = 8 OutArr(2) = C ^ 0 OutArr("INDEX",B) = 7 OutArr(3) = D ^ 1 OutArr("INDEX",C) = 2 OutArr(4) = H ^ 0 OutArr("INDEX",D) = 3 OutArr(5) = K ^ 0 OutArr("INDEX",E) = 9 OutArr(6) = L ^ 0 OutArr("INDEX",F) = 10 OutArr(7) = B ^ 0 OutArr("INDEX",G) = 1 OutArr(8) = A ^ 0 OutArr("INDEX",H) = 4 OutArr(9) = E ^ 0 OutArr("INDEX",I) = 11 OutArr(10) = F ^ 0 OutArr("INDEX",J) = 12 OutArr(11) = I ^ 0 OutArr("INDEX",K) = 5 OutArr(12) = J ^ 0 OutArr("INDEX",L) = 6 $$RPLCLST(L) in the forward direction would return D and the output array would be set as follows if the status history was also included: OutArr(1) = L ^ 0 OutArr("INDEX",C) = 3 OutArr(1,3080101.0954) = 0 OutArr("INDEX",D) = 4 OutArr(2) = H ^ 0 OutArr("INDEX",H) = 2 OutArr(2,3080101.1308) = 1 OutArr("INDEX",L) = 1 OutArr(2,3080105.09) = 0 OutArr(3) = C ^ 0 OutArr(3,3080105.0859) = 1 OutArr(3,3080112.1722) = 0 OutArr(4) = D ^ 1 OutArr(4,3080112.1723) = 1 $$RPLCLST(B) in the backward direction would return D and the output array would be set as follows: OutArr(1) = A ^ 0 OutArr("INDEX",A) = 1 OutArr(2) = E ^ 0 OutArr("INDEX",E) = 2 OutArr(3) = F ^ 0 OutArr("INDEX",F) = 3 OutArr(4) = I ^ 0 OutArr("INDEX",I) = 4 OutArr(5) = J ^ 0 OutArr("INDEX",J) = 5 |
XTIDTRM | 2015/06/08 | ||
| 5237 | Deletion of entries in XTID VUID FOR SET OF CODES file | File | TOOLKIT | 2008/07/03 | APPROVED | Active | Private | 8985.1 | This ICR permits the HDI application to delete entries from the XTID VUID FOR SET OF CODES file (#8985.1). Entries are found using the FileMan call FIND^DIC with a screen set to find those entries that match the file and field numbers being removed. Entries are then deleted using the FileMan call ^DIK. |
2012/09/13 | ||
| 5271 | ADD XDRDADDS | Routine | TOOLKIT | 2008/10/09 | APPROVED | Active | Private | ADD^XDRDADDS adds a patient pair record to the DUPLICATE RECORD file (#15) at a VistA site. It can be called directly, but can also be invoked using the Remote Procedure call XDR ADD POTENTIAL PATIENT DUP. With patch MPI*1.0*62, and accompanying patches MPIF*1.0*52 and XT*7.3*113, most entries will be made to a local VistA DUPLICATE RECORD file because of an action taken by the Person Service Identity Management package (PSIM). Either a pair of patients is determined to be above the Auto Match Threshold by the commercial search engine Initiate, or a pair of patients has been determined to be a potential match and verified by the Identity Management Data Quality group (IMDQ). |
XDRDADDS | 2009/03/12 | ||
| 5456 | Merged Records | File | TOOLKIT | 2009/06/04 | APPROVED | Active | Private | 15.3 |
The Health Data Repository (HDR) relies on the Master Patient Index (MPI), and Person Service Identity Management (PSIM) to provide national and correlated identifiers for patients. The MPI does not currently have data for patient records involved in past merge events. Post-init routine, MPIF51P, will order through the XDR REPOINTED ENTRY (#15.3) file. For the PATIENT (#2) file entries, data will be extracted for the MERGED ENTRY (#.01) and MERGED TO ENTRY (#.02). This data will be sent in A24 HL7 messages to the MPI to update PSIM and the Administrative Data Repository (ADR). MPIF51P will be distributed in VistA patch MPIF*1.0*51. It will be run one time as part of the patch installation, and the routine can then be deleted from the site's VistA system. |
2009/06/17 | ||
| 5515 | HTTP Client | Routine | TOOLKIT | 2009/12/29 | APPROVED | Withdrawn | Supported | This API provides access to a HTTP client to retrieve WEB pages. |
XTHC10 | 2009/12/29 | ||
| 5516 | HTTP client utilities | Routine | TOOLKIT | 2009/12/29 | Withdrawn | Supported | ***** Replaced with DBIA $5555. Utility API to help with HTML. |
XTHCUTL | 2009/12/29 | |||
| 5553 | HTTP Client | Routine | TOOLKIT | 2010/08/24 | APPROVED | Active | Supported | This is a HTTP/1.1 client that can request a web page from another system and pass the returned data to the calling routine. It can make both GET and POST requests. |
XTHC10 | 2015/06/26 | ||
| 5554 | HTTP Client Helper | Routine | TOOLKIT | 2010/08/24 | APPROVED | Active | Supported | These are some helper functions for the HTTP/1.1 Client. |
XTHCURL | 2015/06/26 | ||
| 5555 | HTTP Client Helper | Routine | TOOLKIT | 2010/08/24 | APPROVED | Active | Supported | Helper function for the HTTP/1.1 Client. |
XTHCUTL | 2015/06/26 | ||
| 6554 | VISTA PARAMETER HANDLING | Routine | TOOLKIT | 2016/10/18 | Withdrawn | Private | The Logistics and Prosthetics Suite cloned certain XPAR functionality into its native DSIY namespace. |
XPAR1 | ||||
| 6915 | Parameter Definition File Access | File | TOOLKIT | 2018/05/04 | APPROVED | Active | Private | 8989.51 | Permission requested for initial release of DSSO 2.0 Due to namespace conversion of the Advanced Prosthetics Acquisition Tool (APAT) product from DSIVA to DSSO, it is necessary to convert the existing DSIVA-namespaced parameter definitions to the new DSSO namespace. For this, there will be a one-time installation routine which will utilize the "B" cross-reference of the PARAMETER DEFINITION FILE (#8989.51) to loop through each instance of a DSIVA-namespaced parameter. In this loop, each parameter NAME and DISPLAY NAME will have DSIVA replaced with DSSO using FileMan API FILE^DIE. To prepare for the need to back out, there is also a one-time routine which will utilize the "B" cross-reference of the PARAMETER DEFINITION FILE (#8989.51) to loop through each instance of a DSSO-namespaced parameter. In this loop, each parameter NAME and DISPLAY NAME will have DSSO replaced with DSIVA using FileMan API FILE^DIE. |
2018/06/05 | ||
| 10094 | XTFN | Routine | TOOLKIT | APPROVED | Active | Supported | XTFN | |||||
| 10095 | XTKERMIT | Routine | TOOLKIT | APPROVED | Active | Supported | XTKERMIT | |||||
| 10122 | XTLKKWL | Routine | TOOLKIT | APPROVED | Active | Supported | XTLKKWL | |||||
| 10143 | XLFMSMT | Routine | TOOLKIT | 1994/04/11 | APPROVED | Active | Supported | XLFMSMT | ||||
| 10144 | XLFHYPER | Routine | TOOLKIT | 1994/04/11 | APPROVED | Active | Supported | XLFHYPER | ||||
| 10153 | MTLU LOOKUPS/FILE MANAGEMENT | Routine | TOOLKIT | 1995/01/11 | APPROVED | Active | Supported | Procedure calls for MTLU. |
XTLKMGR |