{"aaData": [[".11", "INDEX", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "
\nThis file stores information about new-style cross-references defined on a\nfile. Whereas traditional cross-references are stored under the 1 nodes of\nthe ^DD for a particular field, new-style cross-references are stored in\nthis file and can consist of one field (simple cross-references), as well\nas more than one field (compound cross-references).\n\n
\nThis file stores information about keys on a file or subfile. A key is a\nkey. This index is called the uniqueness index.\n \nAll key fields must have values. They cannot be null.\nset of one or more fields that uniquely identifies a record in a file. If\nmore than one set of fields can uniquely identify a record, one of those\nsets should be designated the primary key; all others should be designated\nsecondary keys. The primary key is the principal means of identifying\nrecords in the file.\n \nTo allow FileMan to enforce key uniqueness, the database designer must\ndefine a regular index that consists of all the fields that make up the\n\n
\nThis file stores the PRINT FIELDS data and other information about print\ntemplates. These templates are used in the Print, Filegram, Extract, and\nExport options.\n\n
\nThis file stores either SORT or SEARCH criteria. For SORT criteria, the\nSORT DATA multiple contains the sort parameters. For SEARCH criteria, the\ntemplate also contains a list of record numbers selected as the result of\nrunning the search.\n\n
\nThis file stores the EDIT FIELDS data from an input template.\n\n
\nThis file stores ScreenMan forms, which are composed of blocks. The\nform's attributes that describe how information is presented on the screen\nare contained in this file.\n\n
\nThis file stores ScreenMan blocks, which are used to build forms in the\nForm file.\n\n
\nThis file stores the characteristics of various file export formats,\nwhich are used by the Export tool in building Export Templates to send\ndata to non-M systems.\n\n
\nThis file stores information about FUNCTIONS used by FileMan. The first\n100 records in this file are reserved for functions brought in during the\nFileMan INIT process. The rest of the file is available for other\ndevelopers to enter their own functions.\n\n
\nThis file stores an audit trail of changes made to data dictionaries.\n\n
\nThis file stores operating system-specific code. Since the code to invoke\nsome operating system utilities that FileMan uses varies among operating\nsystems, code to perform these utilities is stored in and executed from\nthis file. During the FileMan INIT process an operating system is\nselected so that FileMan knows which entry to use from this file.\n\n
\nThis file stores all of the data types that VA FileMan allows in the\nMODIFY FILE ATTRIBUTES option.\n\n
\nThis file stores information used for creating compiled SORT routines.\nDuring the FileMan SORT/PRINT option, if the user has specified that a\nsort template is compiled, a routine name is generated by concatenating\n"DIZS" with the next available number from this list. A flag indicates\nwhether or not a number is currently in use.\n\n
\nThis file stores the dialog used to 'talk' to a user (error messages,\nhelp text, and other prompts.) Entry points in the ^DIALOG routine\nretrieve text from this file. Variable parameters can be passed to these\ncalls. The parameters are inserted into windows within the text as it is\nbuilt. The text is returned in an array. This file and associated calls\ncan be used by any package to pass information in arrays rather than\nwriting to the current device. Record numbers 1 through 10000 are\nreserved for VA FileMan.\n\n
\nThe LANGUAGE file is used both to officially identify a language, and to\n \nA note to VISTA developers: Although users can select entries by name, \nsoftware should use the official two or three letter codes to eliminate \nmistakes resulting from languages that have similar spelling.\nstore MUMPS code needed to do language-specific conversions of data such\nas dates and numbers.\n \nThe KIDS build for FileMan 22.2 contains all languages in ISO 639-2:1998(as revised 11/21/2012).\nWhen installed without the KIDS build, FileMan 22.2 installs 11 languages.\n \nA pointer to this file from the TRANSLATION multiple on the DIALOG file\nalso allows non-English text to be returned via FileMan calls.\n\n
\nThis file stores the names of different kinds of STRINGS that describe data.\n\n
\nThis file stores the names of different kinds of lines of MUMPS code that are used in the definitions of DATA TYPES\n\n
\nThe Meta Data Dictionary file contains detailed information about the Fields \nin FileMan Files. The information is retrieved \nfrom the installed data dictionaries by running the 'Update the META Data Dictionary'\nOption on the Data Dictionary Utilities menu. That option runs the DDD routine.\n\n
\nThis file stores the descriptive information for all files in the FileMan\nmanaged database.\n\n
\nThis file stores an audit trail of changes made to data fields.\n\n
\nThis file stores information and status of data archiving activities.\n\n
\nThis file stores information and status of filegram activities.\n\n
\nThis file stores information about Filegram errors and the text\nof the affected Filegrams.\n\n
\nThis file stores information about the editors that can be used to edit VA\nFileMan WP fields. The LINE EDITOR and SCREEN EDITOR are exported with VA\nFileMan, but instructions are given to allow site managers to enter local\neditors of their choice. There is a pointer in the NEW PERSON File to\nthis file. The pointed-to editor for that person is then used whenever\nthe person edits a WP field.\n\n
\nThe ENTITY (#1.5) file maps VistA data to entities or resources, which can\nbe exposed RESTfully to standard web methods and formats. It can support\nvarious data models such as Fast Healthcare Interoperability Resources\n(FHIR) or Intersystems' Summary Document Architecture (SDA).\n\n
\nA set of tables and domains. A subset of catalog and environment\n\n
\nSQL identifiers that may not be used for column and table names.\n SQL, ODBC and vendors all have lists of restricted words, which\nshould be put in this table before SQLI table generation.\n\n
\nA set of values from which all domains of that type may be drawn.\nMEMO - the set of all character strings of length > 255\nPRIMARY_KEY - the set of all primary keys (in SQLI_TABLE_ELEMENT, type P)\nCHARACTER - the set of all character strings of length less than 256\nINTEGER - the set of all cardinal numbers\nNUMERIC - the set of all real numbers\nDATE - the set of all date valued tokens\nTIME - the set of all time valued tokens\nMOMENT - the set of all tokens which have both a date and a time value\nBOOLEAN - the set of all tokens which evaluate to true or false only\n\n
\nThe set from which all objects of that domain must be drawn.\nThe PRIMARY_KEY data type and domain is unique to SQLI. It is used to\nrelate primary keys to foreign keys unambiguously (see SQLI_TABLE_ELEMENT)\nIn SQLI, all table elements (SQLI_TABLE_ELEMENT) have a domain which\nrestricts them to their domain set. For each data type there is a domain\nof the same name, representing the same set. Other domains have different\nset membership restrictions. \n \nEach domain has a data type, which determines the rules for comparing\nvalues from different domains, and the operators which may be used on them.\n \n\n
\nStrategies for converting base values into key values.\nSoundex and upper case conversion are common examples. This implies that\ncomparisons of key values with base values must be preceded by conversion\nof the base value to key value. Key formats are frequently lossy; they\ncan't be converted uniquely back to base format.\n\n
\nStrategies for converting base values to external values.\nIn FileMan they are used to convert references to pointers to\ntheir text values. They are also used for the SET OF CODES type.\n \nSQLI projects pointer and set of codes as calls to $$GET1^DIQ, \nvariable pointer into calls to $$EXTERNAL^DILFD.\n \nVendors and other users of SQLI may choose to implement their own \nconversions to improve performance.\n\n
\nDescriptor of a set of table elements: Includes name and file no.\n(See SQLI_TABLE_ELEMENTS). Each ^DD(DA) represents a table in a relational\nmodel of FileMan. Further, each index represents a table. \n \nEach schema contains multiple tables. Each table contains just one primary\nkey, but multiple columns, foreign keys and indicies.\n\n
\nNames and domains of primary keys, columns and foreign keys.\nEach represents the relational concept of an attribute, whose essential\ncharactaristics are a name (unique by relation) and a domain.\n \nSee SQLI_PRIMARY_KEY, SQLI_COLUMN and SQLI_FOREIGN key for more.\n\n
\nA set of formatting and physical structure specifications.\nEach column specification has a column type table element\n(SQLI_TABLE_ELEMENT) which contains the relational specifications, name\nand domain. The column specification contains those attributes required\nto locate the value in the global structure, and to project the value to\nthe user.\n\n
\nA chosen set of columns which uniquely identify a table.\nIn the relational model (as in set theory) the columns of a primary key\nare not ordered. In SQLI they must be, in order to map to the quasi-\nhierarchical model of M globals.\n \nFileMan subfiles (multiples) have a primary key element for each parent\nplus one for the subfile. Each contains a pointer to its primary key table\nelement (SQLI_TABLE-ELEMENT), a sequence and a column in the local base\n table (SQL_COLUMN).\n\n
\nA set of columns in a table that match the primary key of another table.\n They represent an explicit join of the two tables. Each foreign key\n element points to it's table element (SQLI_TABLE_ELEMENT),\na column in the local table (SQLI_COLUMN) and a primary key element of a\n foreign table (SQLI_PRIMARY_KEY). The primary key table element of the\nforeign table has the domain of that table, which makes the connection.\n\n
\nA numbered list of error messages, auto-generated by ERR^DMSQU.\n\n
\nLog of all errors encountered while compiling SQLI.\nIt generates the error text table (SQLI_ERROR_TEXT) on a laygo basis;\nerrors are added only when they occur. If DBS errors triggered the\nerror, the DIALOG file reference is also saved.\n\n
\nThis file holds sets of rules that define a user's authorization to access\nrule whose 'target' attributes match the record will be applied; those\nthat do not match are simply skipped. Matching rules may have additional\nconditions that are evaluated, to determine a result of Permit or Deny.\nEach policy can have a result function that determines when evaluation is\nsatisfied (for example, as soon as a rule returns Permit).\ndata stored in VistA. It supports an attribute-based utility that VistA\napplications can use to permit or deny access to an individual record in a\nfile. Rules can be combined as needed to create simple or very complex\npolicies; policies can themselves be organized into policy sets.\n \nA policy or set can be tied to an action on a particular VistA file in the\nApplication Action file #1.61; member policies are then evaluated in\nsequence, drilling down the Member hierarchy to each rule. Every policy or\n\n
\nThis file contains the actions that users may take on a record in a \nspecific VistA file or sub-file; these should be the actions provided by \nand supported in the application that owns the designated file.\n \nWhen the policy evaluation API is invoked, the File# and API Name passed\nin will be used to find a match in this file; its associated Policy will\nthen be evaluated to return an access result of Permit or Deny.\n\n
\nThis file contains the functions needed to support evaluation of data access\nfor example, and should return a boolean result in Y.\n \nResult functions may look at the DIRESULT variable, if it is set to P or D,\nand should return a boolean value in Y indicating if processing is done.\n \nObligation functions may perform any tasks needed by the application, such\nas logging access granted to a file, and do not need to return a value.\nPolicies in file #1.6. See the VA FileMan Programmer Manual for full details\nof local variables available to use, and output requirements of each type.\n \nAttribute functions may use variables such as the current file (DIFN) and\nrecord number (DIENS) to set DIVAL("attribute")="value" with the attributes\nthat will be needed to evaluate the policy.\n \nCondition functions often look beyond the record, at a user's keys or role\n\n\nThis file denotes time zone designations used throughout the world.\n\n
\nThis file is used to track which countries have periods during the year\nin which they follow DAYLIGHT SAVING TIME, STANDARD TIME, or SUMMER TIME.\n\n
\nThe Race Master file contains standard Health Level Seven (HL7) race\nof locally defined fields that were created prior to the VHA Directive's\n2005-044 effective date shall not be supported.\ncodes.\n \nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\n\n
\nThis is the file of orders/requisitions made for any package through the\nOrder Entry Option (OR).\n\n
\nThis file contains the possible statuses that may be associated with\nof locally defined fields that were created prior to VHA Directive \n2005-044 shall not be supported.\nan order in OE/RR.\n \nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \n\n
\nThis file should not be added to or deleted from. It determines the\nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to VHA Directive \n2005-044 shall not be supported.\n \nThe Orders Domain has approved editing of the following fields in this\nfile:\n - PRINT CHART COPY (#.12)\n - PRINT DAILY SUMMARY (#.13)\n - PRINT WORK COPY (#.15)\n - INCLUDE IN ACTIVE ORDERS (#.16)\nactions that are to be taken based on the nature of an order or change to\nThis may be accomplished via the option "Print Parameters for Nature of \nOrder" [ORCL NATURE], on the "Print/Report Parameters" [OR PARAM PRINTS] \nmenu.\nan order.\n \nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \n\n
\nThis file is used to define the possible reasons for DC'ing/cancelling\nThis file points the the Nature of Order file. This relationship\nis what identifies the appropriate actions to take for any DC Reason.\nan order. The entries are identified by package so that each package\ncan have their own set of reasons. Sites may wish to modify the\nentries in this file to fit their needs. It is important to maintain\nthe correct links to the Radiology Reason file if modifications are\nmade. These links are maintained in the CODE field. For Radiology\nreasons, the code field is the internal # of the radiology reason file\nfollowed by the characters RA.\n \n\n
\nThe file contains pre-defined override reasons that can be used\nwhen order checks are overridden.\n\n
\nThe purpose of this file is to create a repository for instances of order \nchecks that are presented to the users of VISTA across all applications. \n\n
\nThis file is used by CPRS to track what happened to a patient's orders as\na result of an event, such as an MAS movement or returning from the OR.\n\n
\nThis file contains data related to lists. Generally these lists take the\nform of provider(s)/patients.\n\n
\nEntries in this file with an internal number >1000 have been exported\nwith the OE/RR package. Everytime a new version of OE/RR is installed\nthe entries above 1000 are removed and overwritten.\n \nIf you want to use one of these exported entries, transfer the entry\nto a number less than 1000 and give it a new name so that it can be\ndifferentiated from exported entry.\n\n
\nEntries in this file with an internal number >1000 have been exported\nwith the OE/RR package. Everytime a new version of OE/RR is installed\nthe entries above 1000 are removed and overwritten.\n \nIf you want to use one of these exported entries, transfer the entry to\na number less than 1000 and give it a new name so that it can be\ndifferentiated from the exported entry.\n\n
\nThis file is used to store "Combination" pointers for Patient Selection\nLists in OE/RR. Users can select individual default settings for Wards,\nProviders, etc. - but the "Combination" option allows them to set a\nmultiple, or combination, of such choices. When the user enters CPRS, the\ndefault patient list will be built from the combined list of sources in\nthis file (as compared to a single source). \n\n
\nThis file stores order check data from cancelled orders via CPRS and the \nOrder Checking System. This data will be used to report on orders that \nare never entered into the order file and the corresponding order checks \nthat were presented at the time of the order. Orders that have been \naccepted once and subsequently cancelled will have an entry and point to \ntheir full ORDER data in File #100.\n\n
\nThis file contains a record of events that failed or errored out\nduring the use of OE/RR. This file is not to be edited. It is\nfor debugging purposes.\nEntries in this file are automatically purged. The life of an\nentry depends on the parameter ERROR DAYS in the ORDER PARAMETERS\nfile (100.99).\n\n
\nThis file contains the locally-defined events that can release delayed\norders within each division.\n \nIt is strongly recommended that this file not be edited with\nFile Manager. Please use the edit options provided within CPRS.\n\n
\nThis file contains the locally-defined rules that control if and when\nactive orders are automatically discontinued within each division.\n \nIt is strongly recommended that this file not be edited using\nFile Manager. Please use the edit options provided in CPRS.\n\n
\nThis file stores the electronic Prescribing of Controlled Substances \n(ePCS) parameters used by CPRS.\n\n
\nThis file contains the order checks which are used within OE/RR-CPRS to\nperform real-time order checking within the OE/RR-CPRS ordering dialogs.\n\n
\nThis file contains data used to generate notifications. Packages\ndetermine if a notification should be sent then send the patient ID and\nnotification ID (IEN in this file) to order entry routines. Based on the\nnotification IEN, data from this file is used to generate the notification\nand help determine its recipients.\n\n
\nThis file is used to capture the pharmacy Antimicrobial usage orders.\n\n
\nThe purpose of the Quick Order Division Groups file is to\nprovide a place to organize those divisions and groups whose results are \nprinted on the Antimicrobial Monthly tracking reports. A site with \nmultiple divisions can separate monthly results of Antimicrobial ordering\ninto those divisions belonging to a specific group.\n\n
\nThis file allows orders to be clustered in groups other than by package.\nIt is similar in structure to the OPTION File (19). This allows display\ngroups to be arranged in a hierarchy. The main entry in this file\nshould be 'ALL SERVICES'. Other entries should be logically subordinate\nto the 'ALL SERVICES' entry.\n\n
\nThis file contains site specific parameters for OE/RR. It has only\none entry.\n\n
\nThis file contains the orderables and methods for accomplishing orders\n(protocols) within OE/RR.\n\n
\nThis is a scratch file used for entering word processing fields used\nduring dialogs. It allows text to be captured and edited before it is\nactually passed to the database. Entries in this file are very transient.\nThey are created, accepted, transferred to a destination file, then\ndeleted.\n\n
\nThis file stores CPRS GUI Cover Sheet tab acronyms.\n\n
\nThis is the Opioid Treatment Program Medication Dispense record. This \nfile contains the patient name, dispense date and time, and other \ninformation surrounding the dispense of medication. This data comes from \nthird-party vendors like MyAvatar and Methasoft, and is filed here.\n\n
\nThis file contains definitions and parameters used in various reports\nwithin CPRS.\n \nEntry numbers >1000 are reserved for national use. Any local entries\nshould be added to a number <1000. If this convention is not followed,\nyou run the risk of having your local entries overwritten by a patch\nor future release of CPRS.\n\n
\nThis file contains the information needed to define how to prompt for each\norder, what values are acceptable, etc.\n\n
\nThis file contains the urgencies available to assign to an order.\n\n
\nThis file contains the orderable items for use within OE/RR.\n\n
\nThe newer CPRS ordering dialogs use a Windows Listview control for\ndisplaying lists of orderable items and quick orders. Using this control\nwill help us rely less on custom built controls to handle long lists of\nitems. While the Listview control is able to operate on long lists of\nitems, it must know at the outset how many items are potentially going to\ndisplay and must be able to map from any sequence number produced by the\nListview control to a specific item in the list. The ORDER QUICK VIEW\nfile (101.44) provides this mapping. It maps a subset of orderable items\nor quick orders in alphabetical order to specific sequence numbers.\n\n
\nThis file contains the information for the configuration of the AP Dialog\nfor CPRS for AP ordering. There is one AP Dialog form which can be reused\nfor any orderable item for AP. This configuration will allow for control\nover default values, the ability to find controls/prompts, and to build\nprompt assistance elements (builder blocks) that aid the user in\npopulating the specimen description or word processing fields such as\nclinical history.\n\n
\nThis file is used to audit certain actions made to Controlled Substance\nePCS (Electronic Prescriptions for Controlled Substances) Orders.\n \nThe following actions will be audited:\n1. A provider's intention to sign an ePCS order.\n2. Changes to unsigned ePCS orders. \n\n
\nThe purpose of this file is to satisfy the Drug Enforcement Agency (DEA) requirement\n \nIn order to satisfy the requirement that both the prescribing (CPRS) and \nfilling systems (Outpatient Pharmacy) create an archive, but to reduce the \nneed for additional storage space, both CPRS and Pharmacy will use the same \nfile. CPRS will create the entries when an order is signed or when a backdoor \norder message is received from Pharmacy. Once Pharmacy verifies the data in \nthe Pharmacy system is an exact match for what CPRS stored, they will \nsubscribe to the entry in the archive file and will update the PRESCRIPTION \nNUMBER (#1) field.\n \nfor an electronic prescribing system to maintain an archive of all controlled \nThe file was defined in a different global name in order to handle the \nvolume set from the rest of the CPRS system (i.e., the ORDER file).\nIt is important to note that to fully meet the DEA requirements, the fields \nrequired by the DEA cannot be pointers. We must store the data completely. \nThe fields that are pointers are for our internal use, rather than for \nthe DEA purposes.\nsubstance prescriptions that were electronically entered.\n \nThe file will store all the information that is considered a part of the \nprescription.\n \nThe file should always be audited. In addition, the file should NEVER be\nedited using FileMan. These are both DEA requirements.\n\n
\nThis file is used to log Prescription Drug Monitoring Program (PDMP) \nqueries initiated from within CPRS/VistA.\n\n
\nThe CPRS query tool provides a mechanism by which clinical users may \n \nThis file also contains definitions of report criteria. These criteria \nare selected and modified by the user when building custom reports. A\nreport criterion contains a list of constraints that apply to the\nparticular criterion. A critieron behaves much like a "mini-report".\n \nThe other part of a query definition stored in this file is the list of\nfields to be displayed after the query is run. The query produces a \ncolumnar report with the selected display field in each column.\nsearch for items typically managed by CPRS. These are very limited types\nof queries. A wizard helps the user construct the criteria used in the\nquery.\n \nThis file contains definitions of queries used to build reports of CPRS\nitems (orders, consults, documents). Each query definition contains a\nlist of constraints. These constraints are used by the query routines to\nreturn a subset of CPRS items.\n\n
\nThis file contains the list of constraints that are available when\ndefining a query of CPRS items. Each constraint is associated with a \nparticular editor. This is a graphical interface based editor. The \nconstraint name is also used to build the name=value pairs that make up \nthe query.\n\n
\nThis file contains a list of graphical editors that are available within \nthe CPRS query tool for editing constraints.\n\n
\nThis file contains display fields that may be selected. Each display \nfield may be a column in the results of a query. For each display field, \nthe file contains information about how the column should be sorted when \nclicked and some sample data to assist the user when setting up the \ncolumns.\n\n
\nThis file contains patient tasks for the Care Management dashboards;\nall supporting attributes are stored here, as well as tracking of each\none's cancellation or fulfillment.\n\n
\nThis file contains all acknowledgments for order results captured via\nthe Care Management dashboards. A stub is created here for the ordering\nprovider when new results become available for an order that s/he placed;\nthe entry is then updated when the order is actually acknowledged via\nthe CM application. An order's results may also be acknowledged by\nother users as well, such as the nursing staff caring for the patient.\n\n
\nThis file captures flowsheet data in support of the the Anticoagulation \nManagement Program (AMP), which is a Joint Commission National Patient\nSafety Goal initiative to use a standardized process for the management of\ntheir patients on extended anticoagulation therapy.\n \nAMP runs as a Windows Application from the CPRS Tools menu, and assists \nClinicians with the expeditious documentation of visits to Anticoagulation\nClinics.\n\n
\nThis file holds the set of parameters which modify the operation of the \nMRSA Program Tools to suit the needs of your site. For multi-divisional \nfacilities, each division should have a separate entry in this file.\n\n
\nThis file contains search criteria used by the MRSA Program Tools \nsoftware. This file should only be edited using the MRSA Tools Lab \nParameter Setup option provided with this software.\n\n
\nThis file contains the different multi-drug resistant organisms (MDROs)\nthat are needed for the MRSA Program Tools software. Entries in this file\nshould not be edited. This file will be maintained by the support team.\n\n
\nThis file contains the Ward Mappings for the MDRO Program Tools software. \nHere you will create 'Geographical Units' which consist of one or more \nWard Locations (from file 42). For purposes of the MDRO Program Tools \nsoftware all Ward Locations belonging to the same Geographical unit are \none - and any interward transfers between wards belonging to the same \ngeographical unit will be ignored.\n\n
\nThe MASTER MARITAL STATUS file (#11.99) contains the standard set of \npermitted. Use of locally defined fields that were created prior to the\nVHA Directive's 2005-044 effective date shall not be supported.\nmarital statuses from the HL7 Standards Development Organization (SDO).\n \nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall\nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS).\nCreating and/or editing locally defined fields in the file are not \n\n
\nThis file contains a list of all of the diet modifications allowed\nby the using facility. Associated with each diet are characteristics\nsuch as alternate names, an abbreviated name, whether a clinician\nis to be bulletined when ordered, and a diet precedence which\nis used to prevent diet conflicts and as a printing sequence order.\n\n
\nThis file contains diet patterns. The entries for a specific pattern\nrepresent changes from the production diet for this particular pattern.\n\n
\nThis file contains both standard USDA nutrient data based upon\nHandbook 456 and Revised Handbook 8 as well as user entered data.\nThe standard data includes 32 common nutrients.\n\n
\nThis file contains the values of the Dietary Reference Intakes (DRI). In\n1997, the Food and Nutrition Board began releasing updated recommendations\nfor nutrient intake levels that apply to healthy individuals under a new\nframework called Dietary Reference Intakes. For nutrients that have not\nyet been revised as DRI (protein for example) the 1989 RDA values are the\nmost current recommendations and are used here.\n\n
\nThis file contains menus of food items, classified by day and meal,\nwhich are saved for nutrient analysis.\n\n
\nThis file is the master list of ingredients used in preparing\nrecipes. It contains purchasing information, such as stock number\nand vendor, issuance data such as the issuing unit, and various\nconversion factors. Nutritive data such as food group, poundage\nfactors, and a pointer to the analogous food nutrient item in\nFile 112 are also included.\n\n
\nThis is the file of storage locations where ingredients are\nstored by the dietetic service. It is primarily used to sort\nvarious ingredient pull lists.\n\n
\nThis file contains basic data on the various vendors supplying\ningredients to the Dietetic Service. It contains address, telephone\nnumbers and name of contacts.\n\n
\nThis file contains all recipes necessary to build meals. Each\nrecipe consists of basic data concerning the recipe, various\ningredients, and may also contain 'embedded' recipes.\n\n
\nThis file contains a basic list of categorizations which may\nbe applied to recipes. It is primarily used to sort and/or\ndetermine the order in which lists of recipes will print.\n\n
\nThis file contains a list of areas in which food is prepared.\nRecipes may be classified by preparation area and this file\nis used to sort recipes into the various preparation areas\nas well as determine the order in which various lists will\nprint.\n\n
\nThis file contains a list of basic serving utensils. Recipes\nuse this file to indicate the most appropriate serving utensil.\nThe utensil name is printed on various reports for use by\nserving personnel.\n\n
\nThis file contains a list of basic equipment used in the preparation\nof recipes. A recipe may point to this list to indicate the\nprimary type of equipment used in the recipe preparation.\n\n
\nThis file contains all dietetic orders for each admission of a\npatient. It includes diet orders, consult requests, supplemental\nfeedings, early/late tray requests, and tubefeedings. It also\ncontains any food allergies entered for the patient.\n\nThis file will also be used to store outpatient data for individuals\nserved in the outpatient meals functionality.\n\n
\nThis file contains the items which can be selected as patient\npreference items. It contains both items which can be selected,\nsuch as coffee or tea, as well as food preferences (such as \nno liver) which will result in certain recipes being excluded\nfor the patient.\n\n
\nThis file contains site-specific nutrition classifications used in\nnutrition assessment and screening.\n\n
\nThis file contains the four nutrition statuses of the established\nguidelines that are used in nutrition assessment and screening.\n\n
\nThis file contains a list of nutrition plan actions which are\nlisted on the Nutrition Screening form.\n\n
\nThis file contains a list of types of dietetic encounters,\nor events, which are used to account for many of the professional\nactivities of dietetic personnel.\n\n
\nThis file contains the various dietetic encounters entered\nby dietetics personnel. It includes patient-related events,\nsuch as diet instructions, as well as non-patient-related\nevents such as talks to the community.\n\n
\nA menu cycle consists of some specified number of days each day\nof which is associated with a breakfast, noon, and evening meal.\nAn effective date determines the start of the cycle and it will\nrepeat until the effective date of another menu cycle begins.\n\n
\nThis file contains the various meals served by the institution. A\nmeal consists of all recipes prepared for a breakfast, noon, or\nevening meal as well as the production diets associated with\neach recipe. In turn, the production diet entry may indicate the\npercentage of that recipe that is to be served in a cafeteria\nor by tray.\n\n
\nThis file contains a list of the production diets which are the\nbasic diets actually prepared and from which the wide variety\nof clinical diet modifications are derived.\n\n
\nThis file consists of a list of holiday dates for which special\nmeals are prepared. It consists of the holiday date, name, and\nallows for entry of a breakfast, noon, and/or evening meal\nwhich, if present, will override the normal menu cycle meals\non that date.\n\n
\nThis file contains the statistical data necessary to prepare the\nServed Meals Report and the Staffing Data Report. Data\nis saved for each date.\n\n
\nQueued FH Print OPTIONS and the time that the option will be run \nincluding parameters.\n\n
\nFile of the days that may be chosen when building the Queued Reports File \n#117.024.\n\n
\nThis file contains the statistical data necessary to prepare the\nStaffing Data report. Data is saved for each date.\n\n
\nThis file is used to store the monthly costs of the various\nfood groups. Data is used to calculate the cost of meals\nserved as well as ensure an adequate distribution of\nfood across the food groups.\n\n
\nThe Annual Dietetic Report is designed to facilitate data gathering\nand to eliminate information that has been discontinued or deemed\nirrelevant. The report will be compiled manually and submitted to\nCentral office Dietetics through regular mail.\n\n
\nThis file contains the categories, Specialized Medical Programs,\nPrimary Delivery System, Primary Production System, and the\nDietetic Service Equipment.\n\n
\nThis file contains all items served as supplemental feedings.\nWhen appropriate, it may include combinations such as ice cream\nwith spoon. Items designed for bulk delivery to the wards are\nalso contained in this file.\n\n
\nThis file contains a pattern of supplemental feedings (up to four\nitems for each of three time periods) which are often requested\nin common situations (e.g., a diabetic patient) and avoids the\nnecessity of individually selecting the various items when\nordering supplemental feedings.\n\n
\nThis file contains the products commonly used for tube-feedings\nas well as their characteristics such as Kcals/ml, cost, and\nsynonyms.\n\n
\nThis is a list of the common standing orders (often called add-ons\nor specials) which may be ordered for a patient. It may include\nsuch things as 'double portions' or preferences such as 'no fish.'\n\n
\nThis file contains entries relating to required reviews for\neach dietitian response for a ward or group of wards. It can\nalso be used to record personal or non-patient related\nentries.\n\n
\nThis file consists of a list of units used by the ingredient file\nto indicate the dietetic issue unit.\n\n
\nThis file contains the list of isolation/precaution types, as\ncommonly identified by medical personnel, and indicates the\ncharacteristics of those types important to the Dietetic\nService such as type of china and appropriate tray delivery\nperson.\n\n
\nThis file contains the list of types of dietetic consultations\nperformed as well as 'time-units' necessary to complete such\nconsultations for workload purposes.\n\n
\nThis file is a list of wards in the hospital and associated room-beds\nand contains various dietetic specific information such\nas the assigned clinician, bulk nourishments for the ward, and\nwhich Service Point, Communication Office, and Supplemental Feeding\nSite is assigned responsibility for the ward.\n\nThis file will also be used to store outpatient locations necessary\nfor the outpatient meals enhancement.\n\n
\nThis file is a list of Production Facilities and associated\nparameters. A Production Facility is generally a main kitchen where\nbulk food is prepared for use by Service Points.\n\n
\nThis file is a list of Service Points and associated parameters.\nA Service Point is a tray assembly line or cafeteria where bulk\nfood from a Production Facility is served.\n\n
\nThis file is a list of Communication Offices and associated parameters.\nA Communication Office has responsibility for processing diet orders\nfor a group of wards.\n\n
\nThis file contains a list of Supplemental Feeding Sites and associated\nparameters. A Supplemental Feeding Site prepares orders for a \ngroup of wards for which it is responsible.\n\n
\nThis file contains entries for all patient movements, diet changes,\ntubefeeding orders, additional orders, food preferences, standing\norders, and patient isolation orders requiring action by the\nDietetic Service.\n\n
\nThis file contains an extensive set of site parameters designed to\nindicate characteristics of the Nutrition and Food Service and/or\ndifferent methods by which the Service wishes the program to perform.\n\n
\nThis file contains all acceptable relationships for persons named as \nPrimary Next of Kin, Secondary Next of Kin, Primary Emergency Contact, \nSecondary Emergency Contact, and Designee. These relationships are \nconsistent with the values used by Defense Manpower Data Center (DMDC) \nand Cerner for these relationships. Additions or modifications to entries \nin this file should only be done through a national patch release. \nRecords in this file should not be added, edited, or deleted locally. \nDoing so would likely cause database corruption.\n\n
\nThis file contains the list of telephone country codes using the \nwould likely cause database corruption.\nInternational Telecommunications Union (ITU) Standard. This list is \nnecessary to accurately store, transmit, and receive patient phone \nnumbers that are outside the United States.\n \nNOTE: This file is controlled by the MAS Health Eligibility Center, \nMember Services. Records in this file should not be added, edited, or \ndeleted. Any changes to this file's structure or its records should only \nbe done through a national patch release. Performing local modifications \n\n
\nThis file contains vital sign information and other measurement data for a \npatient.\n\n
\nPer VHA Directive {pending directive #}, this file has been "locked down" \nThis file contains a list of vital sign types, and various parameters\nwhich mold the data entry.\nby Data Standardization (DS). The file definition (i.e. data dictionary) \nshall not be modified. All additions, changes and deletions to entries in\nthe file shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to VHA Directive\n{pending directive #} shall not be supported.\n \n\n\nPer VHA Directive {pending directive #}, this file has been "locked down" \nThis file contains a list of qualifiers for vitals/measurements.\nby Data Standardization (DS). The file definition (i.e. data dictionary) \nshall not be modified. All additions, changes and deletions to entries in\nthe file shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to VHA Directive\n{pending directive #} shall not be supported.\n \n\n\nPer VHA Directive {pending directive #}, this file has been "locked down" \nThis file contains a list of qualities or characteristics that can be \naffixed to a vital measurement.\nby Data Standardization (DS). The file definition (i.e. data dictionary) \nshall not be modified. All additions, changes and deletions to entries in\nthe file shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to VHA Directive\n{pending directive #} shall not be supported.\n \n\n\nThis file contains information specific to the General Medical Record -\nVitals/Measurements orders.\n\n
\nThis file contains the various site configurable parameters for the\nVitals/Measurements application.\n\n
\nContains patient allergy/adverse reaction information.\n\n
\nContains a listing of allergies from which user can select.\nshall not be supported.\n \nPer VHA directive XXX, this file has been "locked down" by Data\nStandardization (DS). The file definition (i.e. data dictionary) shall\nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to VHA Directive XXX\n\n
\nA listing of possible allergic reactions.\nshall not be supported.\n \nPer VHA directive XXX, this file has been "locked down" by Data\nStandardization (DS). The file definition (i.e. data dictionary) shall\nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to VHA Directive XXX\n\n
\nSite configurable features for the Adverse Reaction Tracking package.\n\n
\nThis file contains all the data for an Observed Drug reaction.\n\n
\nThis file is a listing of all the patients who have been asked about\nallergies/adverse reactions. It contains a pointer to File 2 (PATIENT), a\nflag to indicate if the patient has or does not have an Allergy/Adverse\nReaction, the person making the assessment and the date/time of the\nassessment.\n\n
\nThis file contains the name and text of documents that can be displayed\nto the user (e.g., ART Reference Card text).\n\n
\nThis file contains locally entered comments relating to allergies\nentered for a patient at a separate (remote) facility\n\n
\nThis file contains consult and request orders originating primarily via\nthe OE/RR ordering process. Once the order exists in this file,\nreceiving service users perform update tracking activities. An audit\ntrail of the update tracking activities is maintained in this file.\n \nThe only associating of results to a consult or request, for this \nversion, is based on Medicine Package procedure results.\n\n
\nThis file is used by the Consult Closure Tool to associate consults,\nclinics, and note titles.\n\n
\nThis file identifies the action types which may be used by a service to \ntrack activity related to a consult or request.\n \nCertain action types may have a "GMRCACT " protocol entry in the Protocol\nFile (101) which corresponds to the action type. Two actions should not \npoint to the same protocol.\n\n
\nThis file is used for the maintenance of procedures used in the\nCONSULT/REQUEST TRACKING package. The procedures contained in this file\nare orderable in CPRS if not inactive.\n\n
\nThis file allows services and specialties to be grouped in a hierarchy \nservices when the Clinician ordering a consult is prompted for\n"Select TO Service/Specialty:" to send the consult to.\nrepresenting the sites services available. This grouping capability\nmay be used with Review screens to filter out consults to a \nservice, sub-service, specialty, or sub-specialty of consults/requests.\n \nThe main entry in this file is the "ALL SERVICES" entry. Other entries\nshould be subordinate in its hierarchy.\n \nThe "ALL SERVICES" entry is used to display the hierarchy of the hospital\n\n
\nThis file is used to maintain a log of transmissions of inter-facility \nconsult activities to a remote VistA system. The file will record the \nrecord and activity that triggered the transmission as well as the \nfacility to which the transmission was directed. Any transmission that \nreceives a negative acknowledgement from the remote system will have an \nerror code recorded. \n \nUpon successful completion of a transmission with successful \nacknowledgement, entries will be deleted after approximately one week.\n\n
\nThis file is used by the IFC order processing code to change the sequence \nin which the REASON FOR REQUEST (#20) word processing field in the \nREQUEST/CONSULTATION file (#123) is populated. Each entry in the IFC \nREASON FOR REQUEST MAPPING file (#123.7) corresponds to an orderable item \nin Cerner (see OBR-19). The DATA FIELD multiple (#1) identifies each\nheader value (see OBX-5) and the sequence with which it is to be stored \nin the REASON FOR REQUEST field.\n\n
\nVarious site configurable parameters for the Text Generator package.\n\n
\nFile that contains the aggregate terms which makes up the prime document\ncontent.\n\n
\nFile that contains the term classifications which allow a package to\ncharacterize aggregate terms.\n\n
\nFile that stores the selected patient data for a prime document.\n\n
\nThis file contains information defining lists of problems commonly seen\nby a particular clinic or user. These lists will be presented as menus\nto select from, to facilitate adding new problems.\n\n
\nThis file contains the categories that make up the Problem Selection\nLists defined in file #125. Each entry links a problem category to\na list, optionally with a subheader and a sequence order.\n\n
\nThis file contains problems categorized into groups for inclusion in\na Selection List. Items within a category will be ordered according to\nthe Sequence number; up to two decimal digits may be used.\n\n
\nThis file contains the problems that make up the categories defined in\nfile #125.11; these are groups of commonly selected, similar problems.\nEach entry in this file links one problem to a single category, and\nmay have a sequence number and ICD code assigned to it. Problems may\nappear in more than one category.\n\n
\nThis file holds an audit trail of all changes made to the Problem\nList entries including the old and new values, who made the change,\nand why. Each entry here represents a single change to one problem.\n\n
\nThis file controls the behavior of the Problem List application for each\nsite where it is installed.\n \nThere should be only one entry in this file!!\n\n
\nThis file contains a patient's intake and output measurements.\n\n
\nThis file contains a list of major input/intake types such as PO, TUBE \nFEEDING, etc. The ADP coordinator is allowed to configure the file entries.\n\n
\nThis file contains the major output types such as URINE, STOOL, DRAINS, etc.\nThe ADP coordinator is allowed to configure the file entries.\n\n
\nThis file contains subtypes associated with the output types. For example,\nvoid, foley and suprapubic are subtypes of the output type urine. The ADP\ncoordinator is allowed to configure the file.\n\n
\nThis file contains a list of IV infusion sites. The ADP coordinator is \nallowed to configure the file.\n\n
\nThis file contains descriptions of IV infusion site conditions. The ADP\ncoordinator is allowed to enter/edit the file entries.\n\n
\nThis file contains the names of IV catheters in different types and sizes.\nThe ADP coordinator is allowed to enter/edit the file entries.\n\n
\nThis file contains reasons why the IV infusion site was discontinued. The \nADP coordinator is allowed to enter/edit the file.\n\n
\nThis file contains NON-IV intake items such as tea, coffee, etc. The ADP\ncoordinator is allowed to configure the file.\n\n
\nThis file contains names of IV solutions used for the Intake and Output\napplication. An entry is used when no Pharmacy order is available. The\nADP coordinator is allowed to enter/edit the file entries.\n\n
\nThis file contains the various site configurable parameters for the\nIntake and Output application.\n\n
\nPer VHA Directive, this file has been 'locked down' by Data \nThe LOINC file contains an extraction of the LOINC database. The LOINC\ndatabase provides sets of universal names and ID codes for identifying\nlaboratory and clinical test results.\n \nThis file is a standard file distributed by Dallas CIOFO and should not be\nedited locally.\n \nThis file structure and data were initially copied from the LAB LOINC \n(#95.3) file with some obsolete fields removed. The other difference \nbetween the two files is that a new ACTIVATION STATUS multiple was also\nStandardization (DS). The file definition (i.e. data dictionary) shall not\nadded. Since Regenstrief had no historical information, this multiple was\npopulated in the following way:\n > If the CHANGE TYPE field is not equal to "DEL", then there is one \n entry with date of 6/29/2015 and Status of Active.\n > If the CHANGE TYPE field is equal to "DEL", then there are two \n entries. The first has a date that is one day before the LAST CHANGE\n DATE with a status of Active. The second entry has a date equal to\n the LAST CHANGE DATE with a status of Inactive.\n \nLOINC Copyright acknowledgement \nbe modified. All additions, changes and deprecation to entries in this\n \n1995-2015, Regenstrief Institute, Inc. and the Logical Observation \nIdentifiers Names and Codes (LOINC) Committee. All rights reserved. LOINC\nis a trademark of the Regenstrief Institute.\n \nLOINC c/o Regenstrief Institute 1001 West 10th. Street, RHC-5 \nIndianapolis, Indiana 46202 USA\n \nThe Department of Veterans Affairs abides by all copyright restrictions, \ncondition and LOINC code use. \nfile shall be done by Enterprise Reference Terminology (ERT) using the\n \nPermission was granted, without written agreement and without license or \nroyalty fees, to use, copy, or distribute the LOINC codes, LOINC User's \nGuide, and the contents of the LOINC database for any purpose, so long as\nthis copyright notice appears on any copies of the LOINC database and\nUsers' Guide, and that the following conditions are met.\n \nThe Department of Veterans Affairs agrees to the following conditions: \n \n1. Will not change the meanings of any of the LOINC codes. \nMaster File Server (MFS), provided by the Common Services (CS). Creating\n \n2. Will not change any content in the defined LOINC fields. \n \n3. Will include this notice of copyright and terms in any copies of the \n LOINC database distributed. \n \n4. If new records are added to the LOINC database as distributed to deal \n with local requirements, these records will be assigned a LOINC code \n containing a leading alphabetic "X" so that the new term cannot be \n confused with new LOINC codes as they are assigned by the LOINC \nand/or editing locally defined fields in the file are not permitted. Use\n committee. \n \n5. Incorporation of any part of the LOINC database into another laboratory\n test definition database for distribution outside of their corporation \n must include the LOINC code (field #1), all six names fields (#2-7),\n and include this copyright notice on the electronic document that\n incorporates the LOINC database.\n \nRegenstrief Institute and members of the LOINC Consortium do not accept \nliability for any omissions or errors in the LOINC database, and all \nof locally defined fields that were created prior to the VHA's effective\nEXPRESS AND IMPLIED WARRANTIES, INCLUDING THOSE RELATED TO MERCHANTABILITY\nOR FITNESS FOR A PARTICULAR PURPOSE, ARE DISCLAIMED.\nDirective shall not be supported. \n \n\n
\nThis file contains the name of the component or analyte measured for the \nLOINC file (#129.1).\n \nThis file is a standard file that is centrally maintained and should not\nbe edited locally.\n\n
\nThe LOINC Axis Codes file contains a collection of LOINC codes used by \nthe Axis fields in the LOINC file.\n \nThis field is centrally maintained and should not be edited locally.\n\n
\nThis file contains a listing of method code, which is one of the axis\nfields in a a LOINC code and are defined by Regenstrief.\n \nThis field is centrally maintained and should not be edited locally.\n\n
\nThis file contains LOINC terms which are meant to be excluded from \nindexing. NOTE: Data entries in this file should not be altered by the\nsite.\n\n
\nRxNorm is a standardized nomenclature for clinical drugs. RxNorm is\nMedical Language System (UMLS). Some of the Metathesaurus fields are not\nprovided by RxNorm and are marked as "(no value provided)". There is\nexactly one row in this file for each atom (each occurrence of each unique\nstring or concept name within each source vocabulary) in RxNorm, i.e.,\nthere is exactly one row for each unique RXAUI in RxNorm. Every string or\nconcept name in RxNorm appears in this file, connected to its language,\nsource vocabularies, and its concept identifier (RXCUI).\nproduced by the National Library of Medicine (NLM). In this context, a\nclinical drug is a pharmaceutical product given to (or taken by) a\npatient with a therapeutic or diagnostic intend. The name of the drug in\nRxNorm combines its ingredients, dosage strength and form.\n \nThe RxNorm Concept Names and Sources file contains a subset of the data\ndistributed by NLM in the RXNCONSO.RRF file. This file follows the general\nformat of the MRCONSO.RRF file of the Metathesaurus in NLM's Unified\n\n
\nRxNorm is a standardized nomenclature for clinical drugs. RxNorm is\nUnified Medical Language System (UMLS). Some of the Metathesaurus fields\nare not provided by RxNorm and are marked as "(no value provided)". There\nis exactly one row in this table for each concept, atom, or relationship\nattribute that does not have a sub-element structure. Not all RxNorm\nconcepts or RxNorm relationships have entries in this file. This file\nincludes all source vocabulary attributes that do not fit into other\ncategories.\nproduced by the National Library of Medicine (NLM). In this context, a\nclinical drug is a pharmaceutical product given to (or taken by) a patient\nwith a therapeutic or diagnostic intend. The name of the drug in RxNorm\ncombines its ingredients, dosage strength, and form.\n \nThe RxNorm Simple Concept and Atom Attributes file contains a subset\nof the data distributed by NLM in the RXNSAT.RRF file. This file follows\nthe general format of the MRSAT.RRF file of the Metathesaurus in NLM's\n\n
\nRxNorm is a standardized nomenclature for clinical drugs. RxNorm is\nSystem (UMLS). Some of the Metathesaurus fields are not provided by RxNorm\nand are marked as "(no value provided)". There is one row in this table\nfor each relationship between concepts or atoms known to RxNorm. In\naddition, explicit SY RELs are provided which give the UMLS Metathesaurus\nCUI and AUI as the RXCUI2 and RXAUI2 fields.\n \nNote that for asymmetrical relationships there is one row for each \ndirection of the relationship. Note also the direction of REL - the \nrelationship which the SECOND concept or atom (with Concept Unique \nIdentifier RXCUI2 and Atom Unique Identifier (RXAUI2) HAS TO the FIRST \nproduced by the National Library of Medicine (NLM). In this context,\nconcept or atom (with Concept Unique RXCUI1 and Atom Unique Identifier \nRXAUI1).\na clinical drug is a pharmaceutical product given to (or taken by) a\npatient with a therapeutic or diagnostic intend. The name of the drug in\nRxNorm combines its ingredients, dosage strength, and form.\n \nThe RxNorm Related Concepts file contains a subset of the data distributed\nby NLM in the RXNREL.RRF file. This file follows the general format of the\nMRREL.RRF file of the Metathesaurus in NLM's Unified Medical Language\n\n
\nRxNorm is a standardized nomenclature for clinical drugs. RxNorm is\nSystem (UMLS). There is exactly one row in this file for each Semantic\nType assigned to each concept. All RxNorm concepts have at least one\nentry in this file. Many have more than one entry. The STY is a direct\nlink to the UMLS Semantic Network.\nproduced by the National Library of Medicine (NLM). In this context, a\nclinical drug is a pharmaceutical product given to (or taken by) a patient\nwith a therapeutic or diagnostic intend. The name of the drug in RxNorm\ncombines its ingredients, dosage strength, and form.\n \nThe RxNorm Semantic Types file contains a subset of the data distributed\nby NLM in the RXNSTY.RRF file. This file follows the general format of the\nMRSTY.RRF file of the Metathesaurus in NLM's Unified Medical Language\n\n
\nRxNorm is a standardized nomenclature for clinical drugs. RxNorm is\nlevels.\n \nThere is one row in this file for every source in RxNorm that is\nrepresented in this RxNorm release.\nproduced by the National Library of Medicine (NLM). In this context,\na clinical drug is a pharmaceutical product given to (or taken by) a\npatient with a therapeutic or diagnostic intend. The name of the drug in\nRxNorm combines its ingredients, dosage strength, and form.\n \nThe RxNorm Source Information file contains a subset of the data\ndistributed by NLM in the RXNSAB.RRF file. This file contains the sources\nfor each of the RxNorm Files loaded into VistA and their restriction\n\n
\nThis MASTER RELIGION file contains the Health Level Seven (HL7) standard \npermitted. Use of locally defined fields that were created prior to the\nVHA Directive's 2005-044 effective date shall not be supported.\nset of religions.\n \nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall\nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS).\nCreating and/or editing locally defined fields in the file are not \n\n
\nEach entry in the SURGERY file contains information regarding a surgery\ncase made up of an operative procedure, or multiple operative procedures\nfor a patient. The file includes the information necessary for creating\nthe Nurses' Intraoperative Report, Operation Report, and Anesthesia Report\n\n
\nThis file is used to restrict entries into 'person' type fields in\nother files. Each entry will contain a field name, file number,\nfield number, and (site determined) keys to restrict entries. Fields\nin other files that will be restricted will call the routine SROXPR\nas part of the input transform. This will determine whether there\nare any restrictions and if so, whether the person selected has the\nproper keys to be entered into this field.\n\n
\nThis file contains devices used to transport the patient to and from the\noperating room. The file will be distributed with data which should\nnot be altered, however sites may wish to add entries to this file.\n\n
\nThis file contains entries describing the special instruments planned for \nuse during the procedure.\n\n
\nThis file contains entries describing the special supplies planned for use\nduring the procedure. \n\n
\nThis is information about medication.\n\n
\nThis file stores the length of time it takes to do an operative\nprocedure based on CPT code and surgical specialty.\n \n\n
\nThis file contains entries describing the special equipment planned for\nuse during the procedure.\n\n
\nThis file contains the VASQIP list of Spinal Level CPT codes. \n\n
\nThis file contains entries describing the Planned Implant(s) to be used \nduring the procedure.\n\n
\nThis file contains entries describing the destination of the patient\nupon completion of the procedure: requested disposition, postoperative\ndisposition or post-anesthesia care disposition.\n\n
\nThis file contains information regarding the operating rooms. It\nincludes a number of fields that cannot be edited using fileman.\nThose fields include the PATTERN, BLOCK SCHEDULE DATE and SERVICE\nBLOCKOUT.\n\n
\nThis file contains information related to operating room and surgical\nspecialty utilization. Start and end times for each room will be stored\nfor each specific date.\n \n\n
\nThis file contains prosthetic devices used by the Surgery package. This\nfile is distributed with no pre-supplied entries. Sites must add entries\nas needed.\n\n
\nThis file contains the various positions that a patient may be in\nduring an operation. It is pointed to by the SURGERY POSITION field \nin the Surgery file. The file is distributed with pre-supplied entries,\nhowever sites may wish to make additions to it.\n\n
\nThis file contains all restraints and positioning aids to be used in\nthe operating room. The file is pointed to by the field RESTR &\nPOSITION AIDS in the Surgery file. The file is pre-supplied with entries,\nhowever each site may want to make additions to it.\n\n
\nThis file will contain causes for delays of surgical procedures. Sites\nmay make additional entries to this file, but should not alter the entries\nprovided. It is pointed to by the field DELAY CAUSE in the Surgery file.\n\n
\nThis file contains the American Society of Anesthesiologists physical\nstatus classification system, based on the presence and severity of\ndisease in the patient. \n\n
\nThis file is pointed to by the ATTENDING CODE field in the SURGERY\nfile (#130). It contains the codes representing the highest level of\nresident supervision provided by the attending staff surgeon. \n \nSites should NOT make additional entries to this file and should NOT\nmodify existing entries in this file.\n\n
\nThis file is pointed to by the ANES SUPERVISE CODE in the Surgery\nfile. It contains the codes representing the highest level of \nsupervision for the anesthesiology supervisor. Sites should NOT make\nadditional entries to this file.\n\n
\nThe Surgery Site Parameter file contains elements to the Surgery package\nthat may be specific to each individual site.\n\n
\nThe Surgery package uses this file for its HL7 interface with VistA and\nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\nNon-VistA packages or systems. The file acts as a mapping and processing\ntool for receiving information from other applications and transmitting\ninformation from the Surgery package.\n \nData in this file SHOULD NOT be altered through the use of VA\nFileMan;input to this field should only take place through the Surgery\nInterface Management Menu options.\n \n\n
\nThis file contains invasive and non-invasive monitors used in the\nSurgery package. It is pointed to by the MONITORS sub-field in the\nSurgery file. The Monitors file is distributed with pre-supplied\nentries, however each site may want to make additions to it.\n\n
\nThis file contains irrigation solutions used during the operative\nprocedure. It is pointed to by the IRRIGATION sub-file in the\nSurgery file. The Irrigation file is distributed with pre-supplied\nentries, however additions may be made at each site.\n\n
\nThis file contains replacement fluids used during the operative procedure.\nIt is pointed to by the REPLACEMENT FLUIDS sub-file in the Surgery file.\nThe Surgery Replacement Fluids file is distributed with pre-supplied\nentries, however additions may be made to it.\n\n
\nThis file contains information regarding the surgery waiting list for\neach surgical specialty. Patients entered into this file will later\nbe moved into the Surgery file at the point that a request for surgery\nis made.\n\n
\nThis file contains information regarding the types of operating rooms.\nIt is pointed to by the TYPE field in the Operating Room file. The\nOperating Room Type file is distributed with pre-supplied entries. \nSites should NOT make additions to it.\n\n
\nThis file contains reasons for cancelling a scheduled operative\nprocedure. It is pointed to by the CANCEL REASON field in the\nSurgery file. The Surgery Cancellation Reason file is distributed\nwith pre-supplied entries, however sites may wish to add to it.\n\n
\nThis file contains solutions used as skin prep agents for a surgical\nprocedure. It is pointed to by the field SKIN PREP AGENT in the \nSurgery file. The file is distributed with pre-supplied entries,\nhowever sites may wish to make additions to it.\n\n
\nThis file contains entries describing the skin integrity of a patient\nbefore and after the operative procedure. It is distributed with pre-\nsupplied entries, however sites may wish to make additions to it.\n\n
\nThis file contains entries regarding the assessment of the patient's\nmood before and after the operative procedure. It is distributed\nwith pre-supplied entries, however sites may wish to make additions\nto it.\n\n
\nThis file contains entries regarding the assessment of the patient's\nconsciousness before and after the operative procedure. The file\nis distributed with pre-supplied entries. The sites may wish to\nmake additions to it.\n\n
\nThis file contains the final procedure (CPT) codes and diagnosis (ICD9)\ncodes for each completed case in the SURGERY file (#130).\n\n
\nThis file contains perioperative occurrence categories used within the\nDHCP Surgery package. All perioperative occurrences entered must be\ngrouped into one of the categories contained in this file. The fields in\nthis file are restricted so that entries cannot be altered.\n \n\n
\nThis file contains the VASQIP list of excluded CPT codes. Surgical cases\ncoded only with CPT codes from this list will not be assessed.\n\n
\nThis file contains the Surgical Specialties used locally. This file\ncontains all the entries in the national SURGICAL SPECIALTY file (45.3)\nas well as locally created entries. All entries should point to a\nstandard entry in the national SURGICAL SPECIALTY file.\n\n
\nThis file contains the various body sites to which the electroground\nmay be applied.\n\n
\nThis file contains the set of laboratory tests tracked by the Surgery Risk \nAssessment Module along with the corresponding local data names in file 63 \npointed to by these tests and the appropriate specimens for these tests.\n\n
\nThis file contains the organ transplant procedures performed within VHA\nfacilities, as well as outside the VHA.\n\n
\nThis file describes the TASKMAN's main file of jobs to start.\nBecause TM works on this file from many UCI's it doesn't use FM to\nmanipulate it. At this point there are no X-refs on this file\nand there are no fields that can be edited, Use TM options for that.\nThe file can be searched, sorted and printed.\nThe third piece of the zero node is only updated when the XUTM QCLEAN\noption runs. There are some applications that still do there own\nsetting into this global and wipeout the zero node.\nThe storage of the symbol table is not in a FM compatable format.\n\n
\nThis file describes the volume sets available in the current multiprocessor\nnetwork. The information pertaining to each volume set is primarily\nused by the Kernel, especially TaskMan. The ucis that make up each\nvolume set can be determined by using the cross-references in the UCI\nAssociation Table file.\n\n
\nMost TaskMan tasks run in the same uci and volume set in which they were\nhas this structure: ^%ZIS("AT",.01,1.5,2.5,3)="", and is used to find\nequivalent ucis on different volume sets. The "AV" index has this\nstructure: ^%ZIS("AV",1.5,.01)="", and is used to determine whether a\ncertain uci is part of a certain volume set.\n \nWhenever the VOLUME SET field of the VOLUME SET file is changed, a\nMUMPS cross-reference searches through this file and re-cross-references\nall pointers to that entry, thereby keeping the two files in synch.\ncreated. However, tasks that need a device that is only available from\na different volume set can not. Such tasks must run on the volume set\nfrom which the device is available, in a uci equivalent to their\ncurrent one. Equivalent ucis on different volume sets can have different\nnames, so this file indicates which ucis on different volume sets are\nequivalent.\n \nTaskMan only directly uses the "AT" and "AV" indices. The "AT" index\n\n\nThis file should be used by the system manager to tune TaskMan to the\nsite's specific needs. Entries are identified by the cpu and volume set,\nso that parameters can be set differently for different nodes that share\na single volume set, etc. Changes to any of the fields will automatically\ncause all accessible Task Managers on the system to update their local\ncopies of the parameters.\n\n
\nThis Taskman file hold counts that taskman has collected during the day.\nEach of the fields 3 to 26 holds the count for 1 hour starting from\nmidnight.\n\n
\nThis file holds Taskman SnapShot data.\nThis is a snapshot of the counts in the taskman ^%ZTSCH global.\nThere should be no user entry of this data.\nIt is just for reporting.\n\n
\nThis file holds the task syncronation flags that control if a task\ncan run or must wait.\n\n
\nThis file contains the structure of a Health Summary. Components from the\nwith the Health Summary Package. These types of Health Summaries should \nnot be deleted.\n \nFields 2,3,4,5 and 6 are used ONLY by Indian Health Service.\nSpecifically, fields 4 (MEASUREMENT PANEL) and 6 (SURVEILLANCE PANEL)\npoint to files 9001017 and 9001018 respectively, which WILL NOT be\npresent at non-PCC sites.\nHealth Summary Components file (142.1) may be selected and restricted by\nnumber of occurrences or time limits. The original creator of a type of \nHealth Summary is the owner of that type. Health Summaries that are\n"owned" may not be modified or deleted by anyone else, except the Clinical\nCoordinator. "Owned" Health Summaries may be used by other users to\nprint patient information. \n \nThe GMTSMGR security key is included on generic Health Summaries sent out \n\n
\nThis file contains all components which may be used to create a Health\nSummary. These entries are typically defined by a programmer. Components\nwhich represent packages which are not in use may be disabled, so they\nwill not be selected by users to build new types of Health Summary\nreports.\n\n
\nThis file contains Health Summary Types that are to be embedded into another \ndocument as an object. The bulk of this file is made up of display flags \nwhich control how the object is to be embedded into the other document.\n\n
\nThis file contains any site parameters which may apply to the Health\nSummary package.\n\n
\nThis file contains information about duplicate records in any file defined\nthe two entries were truely duplicates and change the status field\nare conditional upon external SET values. Modify this dictionary with\nextreme caution.\n \nSeveral TRIGGERs have been modified using ^%GEDIT to add MUMPS code to\nthe conditional logic to prevent firing during a RE-INDEX. This was done\nonly for TRIGGERs that already had human readable conditional logic.\n \n***** W A R N I N G *****\nWhen you add a file to a variable pointer field FileMan deletes the\ninput transform so save it off before the change and restore it after\nappropriately.\nthe change.\n \nIf the user changed the status to 'verified duplicate' he/she would then\nbe asked whether to merge RECORD1 to RECORD2 or RECORD2 to RECORD1. The\nrecords would then be merged accordingly.\n \nThis user interaction is controlled by the merge software and the dictionary\nsupports a merge methodology that will notify the appropriate packages\naffected by the merging of the two entries and wait for their concurrence\nin the two variable pointer fields; RECORD1 and RECORD2 (.01 and .02). The\nprior to actually merging the two entries. If this approach is not desired\nthe software can set the appropriate fields and immediatley do the merge.\nThis methodology requires the two fields defined below.\n \nThe MERGE STATUS field is a SET where 0=not ready, 1=ready, and 2=merged.\nThis field would be set to 0=not ready and a bulletin would be sent to\nthe appropriate package users.\n \nThe MERGE PACKAGES field is a multiple which contains a list of packages\nthat are affected by the merging of entries in the subject file. The\nstatus of an entry in this file may be 'potential duplicate, unverified',\nSTATUS field of this multiple will be set to 0=not ready if the package\nhas the 'from' entry and does an interactive merge. It will be set to\n1=ready if the package has the 'from' entry but does an automatic merge.\nIt will be set to 2=no from entry if the package does not have the 'from'\nentry, regardless of whether they do an interactive or automatic merge.\nIf the package has a merge routine in the package file the merge is\nautomatic. If not, the merge is interactive. The ERROR MESSAGE field of\nthis multiple will contain any errors encountered during the execution of\nthat packages merge routine.\n \n'verified, not a duplicate', or 'verified duplicate'.\nOnce all entries in the MERGE PACKAGES multiple have a STATUS'=0 the MERGE\nSTATUS field is set to 1=ready via a TRIGGER.\n \nOnce the MERGE STATUS is set to 1=ready the actual merge will occur. When\nit is complete the MERGE STATUS will be set to 2=merged. Once set to 2\nmost fields cannot be modified.\n \nThe following fields are set by TRIGGERs and are never seen by the user:\nDATE FOUND, DATE VERIFIED, DATE RESOLVED, WHO CREATED, WHO VERIFIED,\nand WHO CHANGED. Also, the MERGE DIRECTION and MERGE STATUS fields will be\n \ndeleted by a TRIGGER if the STATUS field is modified from 'verified\nduplicate' to any other status.\n \nThe fields LOOKUP1 and LOOKUP2 provide navigational capability from this\nfile to either the RECORD1 or RECORD2 entries in the file specified in\nthe variable pointer fields. The field LOOKUP3 provides navigational\ncapability to any file that points to this file and has a DINUM\nrelationship.\n \nA lookup on the "B" xref will get any file entry that is part of a duplicate\nThe envisioned sequence of events is software would identify potential\nrecord pair because the "B" xref is set by a REGULAR xref on the .01 field\nand by a MNEMONIC xref on the .02 field.\n \nThe "AFR" xref is used by the INPUT TRANSFORMS on the .01 and .02 field to\nprevent entering a file entry that has already been merged away.\n \nAll xrefs that have subscripts consisting of 'RECORD^RECORD' pairs will be\n'low DFN^high DFN'.\n \nThe "ALK" xref is short lived and contains entries that are unresolved\nduplicates from a file and add an entry in this file containing the two\npotential duplicates or verified duplicates that have not yet been merged.\nIts form, using file 2 as an example, is ^VA(15,"ALK","DPT(",fe#1,1,fe#2,DA)\nor ^VA(15,"ALK","DPT(",fe#1,2,fe#2,DA) where the 5th subscript has the\nfollowing meaning: 1=potential duplicate, 2=verified duplicate. When the\n5th subscript is a 1 there will be two "ALK" entries with the two fe#s\nreversed. When the 5th subscript is a 2 there will be only 1 "ALK" entry\nand fe#s will be in the order 'from' 'to'. Once merged the "ALK" xref\nfor that entry will be killed.\n \nThe "AMRG" xref is also short lived and contains one "AMRG" entry for\npotential duplicate records and set the status field to 'potential\neach entry in this file that has a MERGE STATUS of 0=not ready or\n1=ready. Once merged the "AMRG" xref for that entry will be killed.\nThe form of the "AMRG xref, using file 2 as an example, is\n^VA(15,"AMRG","DPT(",0,DA) or ^VA(15,"AMRG","DPT(",1,DA) where the value\nof the 4th subscript has the following meaning; 0=not ready, 1=ready.\n \nThe "AVCHG" xref is set by the WHO CHANGED field which is itself only set\nwhen the STATUS field is changed from "V" to any other value. If this xref\nexists action needs to be taken because other packages have been notified\nto merge the two entries.\nduplicate, unverified'. A user would then make the determination of whether\n \nAll TRIGGERs fire forward except the TRIGGER on the STATUS field of the\nMERGE PACKAGES multiple which fires backward to set the MERGE STATUS field.\nHowever, that TRIGGER has no effect on the kill side. TRIGGER direction can\nbe relevent when deleting entries using ^DIK.\n \nThe .01 and .02 fields are 'uneditable' so entries can only be deleted from\nthis file using ^DIK.\n \nMost TRIGGERs will not fire during a RE-INDEX of this file. Also, many\n\n\nThis file is used to handle duplicate checking and merging of files that\nhave entries in the Duplicate Record File. It is meant to provide the\noverall control information that would be used to first identify\nduplicates within a file, e.g. Patient File, and then to merge the\nentries.\n\n
\nWhen a merge process is set up, all its information is stored in this\nfile. Once a merge process has completed, that entry may be purged using\nthe Purge Merge Process File option in the managers menu.\n\n
\nThis file is used to record the entry number of the FROM record that is\nmerged into the TO record. This can be used for FileMan to determine\nwhich entries were merged, so the IEN of the FROM record will not be\nreused.\n\n
\nFile 15.4 stores an image of the pairs of entries in files that were\nmerged immediately prior to the actual merge. In addition, there is also\na record of the locations of pointer values that were changed during the\nmerge process.\n\n
\nThis is a list of AMIS Reporting Codes for the DSS IDs (STOP CODE file\n#40.7) that are used by the ancillary packages that will be treated as\noccasion of service and not as primary encounters.\n\n
\nThis file list VHA facilities and their site code.\n\n
\nDemographic and followup data concerning Oncology patients is stored\nin this file. (Tumor-related data is stored in the Primary File).\nData is NOT exported with this file, but it is populated on site.\n\n
\nThis file contains fields unique to the Facility, and that are necessary\nfor the followup system to work, and that will enable ACOS reporting.\nData is input from the facility by the user and should be the first file\nthat is populated before any other data is collected.\n\n
\nThe type of recurrence. The term "recurrence" defines the return or\nreappearance of the cancer after a disease-free intermission or\nremission.\n \nIf the patient has been disease-free since treatment, code 00.\n\n
\nIdentifies the surgical procedure(s) performed\nin an effort to diagnose ane/or stage disease.\n\n
\nThe state or Canadian province of the patient's usual residence when the\ntumor was diagnosed and treated.\n\n
\nThis file contains the ONCOLOGY Data Extract Formats.\n\n
\nThis file contains the ONCOLOGY PCE Extract Formats.\n\n
\nThe American College of Surgeons identification number.\nThis file contains 5000+ medical locations nationwide.\n\n
\nFile contains Forms used by the Tumor Registry as well as on line\ninstructions for procedures that must be followed such as making a\ndisk for ACOS. It comes with at least one form, but can be added to by\nthe IRM as needed, and used in later versions of the package.\n\n
\nThe patient's primary payor/insurance carrier at the time of initial diagnosis\nand/or treatment.\n\n
\nRECONSTRUCTIVE SURGERY reconstructs, restores, or improves the shape and\nappearance or function of body structures that are missing, defective,\ndamaged or misshapen by cancer or cancer-directed therapies.\nReconstruction may be a part of the first course of therapy or may be\ndone after the first course is completed.\n\n
\nSURGICAL APPROACH describes the method used to approach the surgical field.\ntraditional and laparoscopic approaches.\nUse codes 1-9 only if the patient had cancer-directed surgery of the\nprimary site. Use code 0 if the patient did not have cancer-directed\nsurgery of the primary site.\n \nUse code 9 for TURP, TURB, and colonoscope with polypectomy, etc.\n \nThis item records information on the increasing use of less invasive\nprocedures. The data will make possible a comparative analysis of\n\n
\nHL7 Message Repository for IFCs and PRFs exchanged between non-converted \nVistA sites and Cerner Millennium. Messages are used for production \nissue research and resolution.\n\n
\nThis file determines the number of days to retain entries in the EHRM HL7 \nMessage file (#1609). Retention is based on the source or type of HL7 \nmessage, either IFC or PRF. \n \nOption EHMHL7 PURGE uses this file when scanning file #1609 and selecting \nentries to be deleted.\n\n
\nCONTAINS ALL AUTHORIZATIONS FOR FEE BASIS SERVICES.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains all Vendors established for payment of Fee Basis services.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains CNH vendor contract information.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the negotiated rates for CNH vendors.\nThe file was created to handle multiple rates for a single\nnursing home.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nIn order to keep track of rate changes for an authorization in\nthe CNH program, this file was developed. It stores the rate\nthat is paid for an authorization time frame. When new contracts\nare negotiated for a CNH new entries must be created in this file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains those vendors whose master record information has changed and which\nmust be sent to the Austin Centralized Fee system for updating the master\nrecord data.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains the entry of veterans whose master record information has \nchanged. The updated information must be sent to the Centralized Fee \nsystem in Austin for the updating of their master veteran records.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains all the valid Suspense codes available to the Fee basis system.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is presently used for storing facility designed suspension\nand/or unauthorized claims letter(s). Future versions may utilize this \nfile for other types of correspondence.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is part of Project Access to care Received Closer to Home \n(ARCH). The file is used to identify a list of reasons that a\npatient may be determined eligible for Project ARCH at the local level.\n\n
\nContains the site specific data for Fee basis functionality. One and only\none entry can exist in this file per installation.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a list of contracts for the local site. New outpatient\nand civil hospital authorizations and payments can be linked to an active\ncontract. The contract number will be included with associated payments\nthat are transmitted to Central Fee. Note that contracts for community\nnursing home rates are stored in the FEE BASIS CNH CONTRACT file instead\nof this file.\n\n
\nThis file holds the original internal entry numbers (IENs) and the new\nIENs for payments that have been moved. This is expected to occur when the\npatient merge process causes data in the FEE BASIS PAYMENT file to move.\nThe Fee Basis special patient merge routines (FBPMRG*) automatically\npopulate this file during patient merges.\n \nThe server routines that process data from the Austin Automation Center\nuse the information in this file to link data received from Austin with\npayments that are moved after being reported to Austin.\n\n
\nStores report of contact information for contract (civil) hospital\nprogram.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains all valid Specialty codes which can be assigned to a vendor.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContain all batches established by Fee Basis users. Payments are assigned\nto a batch and payment data is transmitted for payment in batches.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains all valid Fee Basis functional programs (ie Outpatient Medical,\nContract Hospital, Community Nursing Home).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains all the valid Participation Code types that can be assigned to\na vendor.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains all valid Purpose of Visit codes which can be assigned to a \nveteran in the Authorization option.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains a history of all 'old' ID card numbers and relevant data \nrelating to prior non-current ID cards issued.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains temporary information for the automation\nof Fee Basis Vendor and 5010 Providers to the IB NON/OTHER\nVA BILLING PROVIDER (#355.93) file. The automation assists IB clerks in the\ncreation of bills to third party insurance companies for paid fee claims.\n\n
\nThis file contains a list of claim adjustment reason codes. These codes\nThis file is exported with data and the contents should not be locally\nmodified.\nare used to indicate why the amount paid is different from the amount\nbilled on a health care claim. The source of the codes is the National\nHealth Care Claim Payment/Committee Bulletins. It is available from\nWashington Publishing Company. The associated suspend code, suspension\ndescription, and applicability for use by VA on fee claims is provided by\nthe Fee Replacement Project Management Office in Denver which represents\nthe VA Chief Business Office.\n \n\n
\nThis file contains a list of claim adjustment group codes. The codes in \nThis file is exported with data and the contents should not be locally \nmodified.\nthis file are used to identify the general category of payment adjustment.\nThe source of the codes is the National Electronic Data Interchange \nTransaction Set Implementation Guide for the Health Care Claim Payment \nAdvice (ASC X12N 835). It is available from Washington Publishing \nCompany. The applicability for use by VA on fee claims is provided by the\nFee Replacement Project Management Office in Denver which represents the\nVA Chief Business Office.\n \n\n
\nThis file contains a list of remittance remark codes. The codes in this\nmodified.\nfile represent non-financial information critical to understanding the\nadjudication of a health insurance claim. The source of the codes is the\nNational Standard Format Electronic Remittance Advice. It is available\nfrom Washington Publishing Company. The applicability for use by VA on\nfee claims is provided by the Fee Replacement Project Management Office in\nDenver which represents the VA Chief Business Office.\n \nThis file is exported with data and the contents should not be locally \n\n
\nThe file contains the present on admission (POA) indicator codes. These\ncodes are defined by the Center for Medicare & Medicaid Services (CMS) and\nshould not be locally modified. The codes are used to indicate if a \ndiagnosis was present on admission \n\n
\nThis file contains Intra-governmental Payment and Collection System (IPAC)\n \nPer VHA Directive 2004-038, this file definition should not be modified.\nvendor agreement data that is applicable to Fee Basis invoices. Each\nrecord in this file is for a specific vendor and fiscal year. More than\none record can be entered for the same vendor.\n \nWhen Fee invoices are entered, if the vendor being paid has an active IPAC\nvendor agreement on file the system will require the payment to be made\nvia the IPAC system. This Department of Treasury system is used to\ntransfer funds between government agencies.\n\n
\nThis file contains Master Record Adjustment entries for the \nIntra-Governmental Payment and Collection (IPAC) Vendor Agreements.\n \nWhen IPAC Vendor Agreement information is added, edited, or deleted, this \nupdated information is sent to the Central Fee system in Austin so the \nCentral Fee master record data can have the same updates applied.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file holds reject codes that are applicable to payment line items. \n (#162) file.\n 3. PRESCRIPTION NUMBER (#162.11) multiple within the FEE BASIS PHARMACY\n INVOICE (#162.1) file.\n 4. FEE BASIS INVOICE (#162.5) file.\n \nEach of these four logical files has a free-text REJECT CODE field within\na REJECT CODE multiple. The value stored in the REJECT CODE field is \nnormally expected to have a matching record in the FEE BASIS PAYMENT\nREJECT CODE file so a description of the reject code can be displayed on\nappropriate outputs. In the event the FEE BASIS PAYMENT REJECT CODE file\nThis file will be exported with data. The data must not be locally\ndata is out-of-date and does not contain a code that is stored with a\npayment, a description similar to "Reject reason code not currently\ndefined in list" will be used as the code description until the code \nis added to file #161.99 by a patch.\nmodified.\n \nVistA Fee Basis has four logical files/sub-files that contain payment line\nitems:\n 1. SERVICE PROVIDED (#162.03) multiple within the FEE BASIS PAYMENT\n (#162) file.\n 2. TRAVEL PAYMENT DATE (#162.04) multiple within the FEE BASIS PAYMENT\n\n
\nContains all Fee Outpatient medical payment data. Include's payment\nancillary data for Contract Hospital as of version 2. Does NOT include \nPharmacy payment data.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains Pharmacy invoices and payment data associated with hometown\npharmacy payments.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the information gathered when a site is notified\nthat a veteran has been admitted to a civil hospital.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all bed movement activity associated with the\ncommunity nursing home program.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the information associated with a 7078\nauthorization.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the payment data associated with the inpatient\nhospital programs of FEE Basis.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the disposition choices when moving a patient\nin the inpatient programs.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains unauthorized claim information for active fee programs.\nSites have the ability to either track only complete claims or incomplete\nclaims, depending upon the value in the site parameter field.\nA claim is considered complete once all information is received in order \nto make a determination (dispostion).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the information requested on an incomplete claim. The\nUnauthorized Claim can only move to the next status once all pending \ninformation for a claim is received. Each item which is pending is entered\nas a separate record into this file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a listing of dispositions used in the Unauthorized\nClaims sub-module. The description of the disposition is used as text\nin the unauthorized claim disposition letter.\n *** ENTRIES SHOULD NOT BE ADDED TO THIS FILE ***\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nEach unauthorized claim is assigned a status. This file contains the\npossible status' which an unauthorized claim may be assigned. Associated\nwith a status is the status order. This is the order in which a \nclaim may progress. Also associated with each status is the number of days\nbefore the claim expires, if applicable.\n *** ENTRIES SHOULD NOT BE ADDED TO THIS FILE ***\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nData contained in this file pertains to information needed in order \nto process an unauthorized claim. Sites have the ability to add local entries.\nThe description of the requested information is printed as part of the text\nin the letter which is mailed to the submitter requesting the information.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains various reasons why the claim was disapproved. \nThe description of the disapproval reason is entered as part of the text\nin the disposition letter which is mailed to the submitter of the claim.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file stores the check cancellation reasons and codes used by the\nFinancial Management System (FMS). These reasons will be returned to\nthe site from FMS when a check is cancelled. This file will be pointed\nto by all payment files.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains by calendar year all relative value units\nassociated with a geographic area. Geographic area is defined\nwith Zip Codes. This is a table file that should not be altered\nat the station unless instructed to do so. The relative values\nare set by the Health Care Finance Administration.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains by calendar year all relative value units associated\nwith a service rendered. The Service rendered is defined with CPT Codes.\nThis is a table file that should not be altered at the station unless\ninstructed to do so. The relative values are set by the Health Care\nFinance Administration. \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThese entries contain percentage value to pay for a service.\nAfter calculating the Medicare rate and the modifier is not\na separate entry in the fee schedule, this table stores by\ncalendar year a percentage multiplier which will adjust\nthe payment amount accordingly.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains, by calendar year, Major CPT Categories and the\nconversion factor (multiplier) assigned to each by the Health Care\nFinance Administration (HCFA).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the list of VistA Fee Basis invoices that are pending \nInvoices are automatically added to this file when various trigger events \noccur such as receipt of a payment confirmation message. The interface \nsoftware uses this file to identify invoices that should be transmitted \nto FPPS and to maintain a record of transmissions and acknowledgements.\ntransmission or have already been transmitted to the Fee Payment\nProcessing System (FPPS) hosted at the Health Administration Center (HAC).\n \nVistA invoice data must be transmitted to FPPS for invoices that are \nassociated with an electronically submitted health care claim. FPPS can\nthen generate the electronic remittance advice to the vendor as required\nby HIPAA.\n \n\n
\nThis file contains an audit log of changes made to a VistA Fee Basis\ninvoice after the invoice has been initially transmitted to the Fee\nPayment Processing System (FPPS) located at the Health Administration\nCenter (HAC). Such changes are made using special edit options that\nautomatically populate this audit log file.\n\n
\nThis file is controlled by the program office and will be used for\nhelping sites do cost analysis.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used as the table of current Payment Methodologies received \nfrom FBCS as part of the claim data.\n\n
\nThis file stores the default amount paid for outpatient medical\npayments. It is populated using the fee schedule option found on\nthe supervisor menu.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nComplete ICDO-2 Topography from the 1990 International Classification of\nDiseases for Oncology (2nd edition), World Health Organization. Contains\nsite specific coding for Extent of Disease and AJCC Staging.\n \nThis file comes with data, which overwrite the site's data. It is not\nrecommended that sites modify this file.\n\n
\nThe parent ICDO-2 Groups for the ICDO-2 Topography codes. Pointed to by\nfile 164; simple list of code groups and meaning.\n\n
\nICDO-2 Morphology File (World Health Organization's International\nClassification of Diseases - Oncology), containing all codes including /2's.\n \nThis file comes with data, which overwrite the site's data. It is not\nrecommended that sites modify this file.\n\n
\nThis file, pointed to by the ICDO-SITES File (#164.08), facilitates the\nproduction of the Annual Registry Summary Report.\n \nThis file comes with data, which overwrite the site's data. It is not\nrecommended that sites modify this file.\n\n
\n"Tumor Markers" record prognostic indicators for specific sites or\nhistologies.\n\n
\nThis file lists the physical conditions of patients prior to the beginning\nof initial treatment using Karnofsky's Rating. \n\n
\nChemotherapeutic drugs as listed in SEER SELF-INSTRUCTIONAL MANUAL FOR\nTUMOR REGISTRARS Book 8 - ANTINEOPLASTIC DRUGS Third Edition\n\n
\nContains major site-groups for the Oncology package. It contains ALL the\nof the TOPOGRAPHY Multiple (#10) of the ICDO-1 SITE FOR ONCOLOGY\nFile (#169.2).\nACOS Site-Specific Surgery Codes. In addition, it also contains the SEER\nExtension and Lymph node coding - sharing that function with file 164.\n \nThe "F" cross-reference of the TOPOGRAPHY Field (#.01) of the TOPOGRAPHY \nMultiple (#10) sets an index under ^ONCO(164.2,"F"). An index under\n^ONCO(164.2,"G") is set by both the "G" cross-reference of the\nICDO-1 TOPOGRAPHY Field (#.02) of the TOPOGRAPHY Multiple (#10),\nand by the "AC" cross-reference of the TOPOGRAPHY Field (#.01)\n\n
\nData file containing other methods of staging for particular sites.\nData will overwrite data in field.\n\n
\nFile contains the AJCC Staging Groups and the TNM coding schema.\nThis is a very important data file and should not be modified.\n\n
\nCommon cancers file containing list of common cancers (data file).\n\n
\nThis file contains a superset of the DAM Cancer Status Codes for use\nin identifying tumor status at follow-up on the ONCOLOGY PRIMARY File \n(#165.5). The extended codes (4-7) help the registrar to record more \ncompletely the overall cancer status of an expired patient.\n \nThis file comes with data, which overwrite the site's data. It is not\nrecommended that sites modify this file.\n \nThis file is referenced directly by routine ONCOCOFA.\n\n
\nThis file contains codes used to record the grade of tumor in the GRADE\nField (#24) of the ONCOLOGY PRIMARY File (#165.5).\n \nThis file comes with data, which overwrite the site's data. It is not\nrecommended that sites modify this file.\n\n
\nThis file contains the Grade codes for the GRADE CLINICAL (#24.3),\nGRADE PATHOLOGICAL (#24.4) and GRADE POST THERAPY (#24.5) fields of the\nONCOLOGY PRIMARY (#165.5) file.\n\n
\nThis file contains transforms for converting AJCC stage data from internal\nto external format and vice versa.\n \nThis file comes with data, which overwrite the site's data. It is not\nrecommended that sites modify this file.\n \nThis file is referenced directly by routine ONCOTNS.\n\n
\nThis file contains codes used to record the patient's race in the RACE\nField (#8) of the ONCOLOGY PATIENT File (#160). The codes are derived\nfrom the ACOS Data Acquisition Manual.\n \nThis file comes with data, which overwrite the site's data. It is not\nrecommended that sites modify this file.\n\n
\nThis file contains the Schema Discriminator codes used by NAACCR. These\ncodes are used to record the SCHEMA DISCRIMINATOR 1 (#3926),\nSCHEMA DISCRIMINATOR 2 (#3927) and SCHEMA DISCRIMINATOR 3 (#3928) fields\nof the Oncology Primary (#165.5) file.\n\n
\nThis file contains extension, lymph node, and surgery codes from the SEER \nExtent of Disease Codes and Coding Instructions. Each set of codes can be \nlinked to code sets from future editions.\n \nThis file is referenced directly by routines ONCODEL (for extension and \nlymph node codes) and ONCODSR (for surgery codes).\n \nThis file comes with data, which overwrite the site's data. It is not\nadvised that sites modify this file.\n\n
\nIdentifies additional information needed to generate stage, or\nprognostic factors that have an effect on stage or survival.\n\n
\nThe Commission requires staging of pediatric patients using AJCC or the\nstaging criteria of the pediatric intergroup studies and the pediatric\ncooperative groups.\n\n
\nThis item may be used as a quality assurance monitor to evaluate the\noverall pattern of care within a facility. It is potentially useful\nas a monitor of appropriateness and efficacy of treatment and in\nselecting patients for outcome reporting.\n\nIn many cases, RADIATION TREATMENT VOLUME will be most appropriately\ncoded by the radiation oncologist.\n\n
\nRADIATION COMPLETION STATUS is useful in evaluating treatment outcomes\nand the appropriateness of the initial decision to treat.\n\nThis file indicates whether the patient's radiation therapy was\ncompleted as outlined in the initial treatment plan. This information\nis generally available only in the radiation treatment chart.\n\n
\nThis file contains the codes and descriptions used by the Radiation fields\n2018+ cases: PHASE I RAD EXT BEAM PLANNING (#5502), PHASE II RAD EXT BEAM\nPLANNING (#5512) and PHASE III RAD EXT BEAM PLANNING (#5522) of the\nOncology Primary (#165.5) file.\n\n
\nThis file contains the codes and descriptions used by the Radiation fields\nfor 2018+ cases: PHASE I RAD TREATMENT VOLUME (#5504), PHASE II RAD\nTREATMENT VOLUME (#5514) and PHASE III RAD TREATMENT VOLUME (#5524) of\nthe Oncology Primary (#165.5) file.\n\n
\nThis file contains the codes and descriptions used by the Radiation fields\nfor 2018+ cases: PHASE I RAD TO DRAINING LN (#5505), PHASE II RAD TO\nDRAINING LN (#5515) and PHASE III RAD TO DRAINING LN (#5525) of the\nOncology Primary (#165.5) file.\n\n
\nThis file contains the codes and descriptions used by the Radiation\nfields for 2018+ cases: PHASE I RAD TREATMENT MODALITY (#5506), PHASE II\nRAD TREATMENT MODALITY (#5516) and PHASE III RAD TREATMENT\nMODALITY (#5526) of the Oncology Primary (#165.5) file.\n\n
\nThis file contains the WHO histological classification of tumor codes for\ntumors of the brain and central nervous system.\n\n
\nFile for Oncology contacts. Populated by the user, partly automatically by\nFollow-up options, and by the user. Used only for patient follow-up.\n\n
\nForm letters for Oncology/Tumor Registry follow-up. These are linked\nby type to the Contact file. Upon installation the option is\ngiven to preserve or delete the letters already in the system.\n\n
\nSEER Geocodes. These codes include states of the United States as well as\nforeign countries.\n\n
\nFor a hospital registry, Class of Case divides cases into two groups. \nto meet central registry requirements or because of a request by the\nfacility's cancer program.\n \nAnalytic cases (codes 00-22) are those that are required by CoC \n(Commission on Cancer) to be abstracted because of the program's primary\nresponsibility in managing the cancer. Analytic cases are grouped\naccording to the location of diagnosis and treatment. Treatment and\noutcome reports may be limited to analytic cases.\n \nNonanalytic cases (codes 30-49 and 99) may be abstracted by the facility\n\n
\nTumor-related data for Oncology patients is stored in this file.\n(Demographic and follow-up data is in the Oncology Patient File).\nFile is populated in the field by using the abstracting options.\n\n
\nThis file contains whole file conversion flags.\nCurrently the only flag available is for the ROADS to FORDS conversion.\n\n
\nTied to Primary file (Dinumed to .01 field), containing computed fields only.\nThis can be used by IRM to add computed fields to the file for use in the\nstatistical options for cross-tabulation routines.\n\n
\nFor a hospital registry, Primary Abstract cases need to record the\nperson or group who assigned the clinical and pathologic staging\nitems.\n \nThis file contains the applicable numeric codes to use for recording\nthe value for each case and the label (description) for each code.\n\n
\nThis file contains the T, N and M codes as well as the T Suffixes and\nN Suffixes and AJCC Chapter and Name for the AJCC Cancer Staging Manual\n8th Edition.\n\n
\nThis file contains the site-specific codes and descriptions for the\nSEER EOD (Extent of Disease) data items.\n\n
\nThis file is intended to assist the registrar in coding the source\nthat first identified the tumor.\n\n
\nThis file contains a list of managing physician specialties.\nThe file is used for the Patient Care Evaluation Study of\nCancers of the Urinary Bladder form.\n\n
\nREGIONAL TREATMENT MODALITY is intended to identify the dominant modality\nThis field can be useful in assessing resource utilization, planning for\nexpansion, or monitoring quality. It should be used at the discretion of\nthe Radiation Oncologist.\n\nof therapy delivered to the primary volume of interest. In some cases,\nit may be appropriate to choose a code for its academic or economic\ninterest, even though it may not reflect the majority of the patient's\ntherapy. For example, a patient with carcinoma of the nasopharynx may\nreceive original treatment using a linear accelerator and then have a\nboost with High-Dose-Rate (HDR) brachytherapy. In a department with a\nspecial interest in brachytherapy, the code 15 would be chosen.\n\n\n
\nThis file supports the 1996 Patient Care Evaluation of Soft Tissue Sarcoma.\n\n
\nIdentifies systemic therapeutic procedures administered as part\nof the first course of treatment at this and all other facilities.\nIf none of these procedures were administered, then this item\nrecords the reason they were not performed. These include bone\nmarrow transplants, stem cell harvests, surgical and/or radiation\nendocrine therapy.\n\nFor further information see FORDS pages 182-183.\n\n
\nThis file contains the codes for the BRAIN MOLECULAR MARKERS (#3816) of\nthe Oncology Primary (#165.5) file. This corresponds to NAACCR item #3816\nBrain Molecular Markers.\n\n
\nThis file contains the codes and description for the Gleason Patterns\nused by the GLEASON PATTERNS CLINICAL (#3838) and GLEASON PATTERNS\nPATHOLOGICAL (#3839) in the Oncology Primary (#165.5) file.\n\n
\nThis file contains the codes for the LN STATUS FEM-ING,PAR-AOR,PLV \nfield (#3884) of the Oncology Primary (#165.5) file.\n\n
\nThis file contains the codes used for the PERIPHERAL BLOOD INVOLV 2018\nfield (#3910) of the Oncology Primary (#165.5) file.\n\n
\nThis file contains the codes and descriptions used for the\nRESIDUAL TUM VOL PST CYTO field (#3921) of the Oncology Primary (#165.5)\nfile.\n\n
\nThis file contains the codes and descriptions used for the NEOADJUVANT\nTHERAPY-TX EFFECT (#245.3) field of the Oncology Primary (#165.5)\nfile. This is needed for NAACCR Item #1634.\n\n
\nThis file contains the HPV Status codes and descriptions\nfor use with the SEER Site Specific Fact 1 NAACCR Data element.\n\n
\nThis file is intended to assist the registrar in coding the source of \ndocuments used to abstract the cancer being reported.\n\n
\nThis file is used to identify the type of multiple tumors that are \nabstracted as a single primary.\n\n
\nThis file contains the International Classification of Diseases for Oncology,\nThird Edition (ICD-O-3) morphology codes and code descriptions.\n\n
\nThe simple file allows for the storage of the status of the package\nunder control of the programmer: version installed, beginning and\nending of the installation, with the generation of a mail-message\nto the installer, and supporting ISC the installation information.\n\n
\nThis is a parameter file for CPRS response time monitoring. It keeps all \nnecessary information to make web pages with the response times graphed \non them.\n\n
\nThis is the CPRS Monitor data file which stores information necessary to \nmake graphical data for the monitor web pages of the facilities. It is \nalso used to send data to the National Response Time Monitor web site.\n\n
\nThis file holds the site parameters for this installation of Foundations\nManagement and VistALink.\n \nIt will have only one entry (DINUM=1) and the .01 field points to a\nDOMAIN that represents the name of the installation site.\n\n
\nThe entries in this file contain the connection related and proxy class\ninformation of remote web services.\n \nThis information is required in order for the HealtheVet Web Services\nClient (HWSC) application to call remote web services.\n\n
\nThis file holds VistALink Listener configurations. A configuration may \ncontain multiple Listener ports, and each Listener port may be configured \nto start upon system startup. Note: This only applies to Cache NT \nsystems. VMS/DSM systems need to use the TCP/IP (UCX) utility to have\nListeners automatically started on reboot.\n \nThis file is pointed to by the Foundations Site Parameters file (#18.01)\nand is used when obtaining the default Listener configuration for a \nspecified BOX-VOLUME pair.\n\n
\nThis file contains informational status pertaining to the current state of\nConfiguration option [XOBV LISTENER STARTUP] is invoked, or by using the\naction protocols found under the Foundations Management Menu option\n[XOBU SITE SETUP MENU] to either start the BOX-VOLUME default\nconfiguration or start a single VistALink Listener.\n \nWhen a Listener is stopped, the log file is edited with an updated\nstatus. Non-active Listeners are deleted from the log file when the Clean\nUp Log action protocol is invoked. As mentioned, this action protocol as\nwell as the action protocols previously described above can be found under\nthe Foundations Management Menu option [XOBU SITE SETUP MENU].\nVistALink Listeners for each BOX-VOLUME pair. \n \nNote: This file only applies to Cache NT systems and is not utilized for\nVAX/DSM systems. Those systems must use the TCP/IP (UCX) utility to start\nand stop VistALink listeners.\n \nThis log file is initially populated when one or more VistALink Listeners\nare started. This will occur when either the Start VistaLink Listener\n\n
\nThis file contains the message type definitions used by the VistALink \nmanager to dynamically determine which request handler to load and\nexecute.\nrequest manager. Each message type is associated with a request handler.\n \nThe request manager uses TCP/IP input stream information to lookup entries\nby 'message type' or 'proprietary format indicator'. Once an entry has\nbeen found, the request manager can execute the correct request handler\nmethods for the incoming request stream.\n \nInformation contained in the entries of this file allow the request\n\n
\nThis file contains the web server(s) and associated information\nrequired for HealtheVet Web Service Client (HWSC) to communicate with the\nserver using SOAP and REST web services over HTTP.\n\n
\nThis file contains lookup key names that are mapped to WEB SERVER file\nentries.\n \nThese key-to-server mappings allow application developers to code\nusing key names and call the appropriate HWSC API at run-time to\nresolve the server using the key name as input to the API.\n \nThere is also a deployment time API that can be use to registered the key\nname during the installation of application.\n\n
\nThe Kernel Site Parameters File establishes when and how a log of option\nusage will be recorded in this file. For the indicated time period, all\nspecified options, namespaces, and users will be audited. Each time an\naudit is put into effect, it is recommended that the number of audited\nentities be at a minimum so that disk space is not inadvertently wasted.\nThis file is cross-referenced by option.\n\n
\nThis is the file that contains notes that are saved by the nurses. Do \nnot edit this file via Fileman. To purge this file, be sure option NUPA\nPURGE SAVED NOTES (Purge Saved Notes Over 5 Days Old) is queued to run\nnightly.\n\n
\nThese are the problems that the nurses can note. Do not edit this file\nvia Fileman.\n\n
\nThese are the tabs that the problems are displayed on. Do not edit this \nfile via Fileman.\n\n
\nThese are the interventions that the nurse can select for various \nproblems. Do not edit this file via Fileman.\n\n
\nThis is the PCE that nurses at your site can resolve. Do not edit this \nfile via Fileman. Use option NUPA PCE EDIT.\n\n
\nThese are the interdisciplinary care plans that are done by nurses or \nother medical personnel. Information is uploaded from the \nassessment_careplan GUI. Do not edit this file via Fileman.\n\n
\nThis file holds information on all IVs that a pateitn has during a \nparticular admission.\n\n
\nHolds information on any Gastrointestinal or Genitourinary devices that a \npatient may have.\n\n
\nThese are items for various components in the GUI. They were placed here\nin order to facilitate future updates by not requiring a new GUI to be \nsent. Do not edit this file via Fileman.\n\n
\nThis is the log of changes made to a patient's care plan. It logs the \nfield changed, the old & new values of that field, who changed it, and \nthe date changed. Do not edit this file via Fileman.\n\n
\nThe PATIENT file contains all the patients followed by the medical center/\nThe ADMISSION sub-field is scheduled to be moved into the new PATIENT\nMOVEMENT file by the end of calendar year 1989. Care should be used\nwhen removing a patient from the PATIENT file since virtually all\nother DHCP modules do utilize data from this file. Of the many fields\nin the file you will note that many are preceeded by an asterisk.\nThose fields are scheduled to be removed from the file due to either\nlack of use or replacement by another field/file in the next release.\nOutpatient clinic. At a minimum each patient entry must have a NAME, DATE\nOF BIRTH and SOCIAL SECURITY NUMBER. In order to add a new patient to the\nPATIENT file the user must also indicate whether or not the patient is\nrequesting to receive care as a VETERAN of the U.S. Armed Forces and\nspecify the TYPE of patient being added to the system. For the most\npart the information contained in this file is demographic in nature,\ni.e., address, employment, service history, etc., however data\nconcerning admissions, appointments,etc., is also stored in this file.\n\n
\nThis file, introduced with Name Standardization (Patch XU*8.0*134), holds\n \nThe "source name" that has these components is identified by the following\nthree fields:\n \n File (field #.01)\n Field (field #.02)\n IENS (field #.03)\n \nThe "ANAME" cross-reference on the Family (Last) Name, Given (First) Name,\nMiddle Name, and Suffix fields keeps each component in synchronization\nthe component parts of a person's name as follows:\nwith the corresponding source name. In the case of Patch XU*8.0*134, the\nsource name is the .01 field (the Name field) of the NEW PERSON file\n(#200).\n \nThe Degree and Prefix fields are not considered part of a standard name,\nbut can be used to build formatted names for display.\n \n Family (Last) Name (field #1)\n Given (First) Name (field #2)\n Middle Name (field #3) \n Prefix (field #4)\n Suffix (field #5)\n Degree (field #6)\n\n
\nThis file contains data on employees, users, practitioners, etc.\n Nodes and X-ref 'RA*'.\nField numbers 720-725 reserved for DSSM\n Nodes and X-ref 'EC*' and 'AEC*'.\nField numbers 740-749.9 reserved for QA\n Nodes and X-ref 'QA*'.\nField numbers 654-654.9 reserved for Social work\n Node 654 and X-ref 'SW*'.\nField numbers 500-500.9 reserved for mailman\n Node 500 and X-ref 'XM*' and 'AXM*'.\nField numbers 740-749.9 reserved for QA\nwho were previously in Files 3,6,16 and others.\n Nodes and X-ref 'QA*'.\nField numbers 910-910.9 reserved for Police Package\n Node and X-ref 'ESP'\n \nDHCP packages must check with the KERNEL developers to see that\na given number/namespace is clear for them to use.\n \nField numbers 53-59.9 reserved for Pharm.\n Nodes and X-ref 'PS*'.\nField numbers 70-79.9 reserved for Radiology\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file will contain an entry for every image, image group, waveform,\naudio file, or waveform generated at your site. It is distributed without\n | |\ndata. Objects handled by the VistA Imaging System currently include single\nimages (various resolutions), series of images, scanned documents, motion\nvideo, waveforms, and audio files. There is a record in file 2005 for\neach object, containing the attributes of the object. All fields are\nautomatically stuffed by the Imaging software - there is no user input.\nObjects handled by the VISTA Imaging System currently include: \n * Single images (various resolutions)\n * Series of images\n * Scanned documents\n * Waveforms \n | Property of the US Government. |\n * Motion video\n * Audio files\n \n \nEach object has a natural language Name (.01); this usually\nconsists of the patient's name, ssn, and object description. \nDepending on the object type, the object will either have:\n \n * A filename and logical location on the network (e.g., single image, graphics).\n * A multiple field called Object Group, containing entries, which\n | No permission to copy or redistribute this software is given. |\npoint back to the Image file (e.g., image series or tiled\nabstract display).\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file is where Study level data associated with stored\nimages can be managed, e.g., Key Images.\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains an entry for each annotated image. The information\nincludes the detail about each annotation, e.g.: annotator, date/time\n | |\nsaved, tool version, source and XML data...etc. \n\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains an entry for each annotated study. The information\nincludes the detail about each annotation, e.g.: annotator, date/time\n | |\nsaved, tool version, source and XML data...etc. \n\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n \n | |\n | The Food and Drug Administration classifies this software as |\n | a Class II medical device. As such, it may not be changed |\n | in any way. Modifications to this software may result in an |\n | adulterated medical device under 21CFR820, the use of which |\n | is considered to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains an entry for every type of object handled by the VistA\n +---------------------------------------------------------------+\nImaging System. It is exported with data. All sites must have entries\nfor the data types distributed in order to display objects sent via\nmultimedia mail.\n The Object Type file handles objects of various types. These include: \n * still images \n * image groups\n * graphics or waveforms\n * scanned documents\n * audio files \n \n | |\n Other types are expected in the future (i.e., image overlays,\nmotion video chips, and office automation files). An object,\nsuch as an image series, may actually consist of multiple\nobjects. In this case, the object type is Group. The Object\nGroup multiple field is used to point to a set of objects in the\nImage file. Each object type has associated methods (software\nroutines) for performing certain actions. For example, there are\nmethods for displaying images and image abstracts. The group\ntype is used to combine multiple objects of the same or different\ntypes to create complex objects.\n | Property of the US Government. |\n \n There are different image types, for example: \n * black and white high-resolution x-rays\n * black and white ultrasound images (lower resolution)\n * pseudo-color nuclear medicine scans\n * medium resolution true color bronchoscopy images\n * pathology images\n \n Each type of object has a number of specific characteristics,\nincluding the methods required to display them. For example,\n | No permission to copy or redistribute this software is given. |\neach object type has a type name and an associated display method\nor window.\n \n All accesses to objects use the file finder routine ^MAGFILE or\n^MAGFILEA to find the network location needed. Different entry\npoints of this routine will find locations of full files,\nabstract files, and jukebox copies of files. In addition, the\nnetwork write location will be returned for image captures.\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains all the image filename extensions supported by \nImaging and specific characteristics for the filename extensions. \n | |\nThis is a static file only updated by newer versions of the Imaging \napplication. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe Imaging File (2005) has many "imaging multiples" pointing to it from\nother packages such as Radiology, Medicine, Surgery, Mailman and the\n | |\nvarious sub-files of Laboratory such as Surgical Pathology etc. In order\nto have a method of tracing back from the Image file to the parent file\nmultiple, a file was developed to aid in this process, along with some\nadditional fields in the Image file. Using these fields along with the\nPARENT DATA FILE, backward navigation is possible whether it be to a\nmultiple of a file, or a multiple of a sub-file of a file. Each image that\nis captured is associated with a procedure or test report. Depending on\nthe service collecting the image, different types of reports will be\nassociated. For example:\n \n | Property of the US Government. |\n * Medical Procedures: Endoscopy, Dermatology, Hematology, Rheumatology, etc.\n * Anatomic Pathology: Surgical Pathology, Cytology, Autopsy, Electron Microscopy\n * Radiology: Xray, CT, MRI, Ultrasound\n * Surgery Operation reports\n * Text Integration Utility Progress notes\n \n In order to be able to display information from the associated\nreport, references to that report are stored in the Image file. \nOne of these references is a pointer to the Parent Report file\n(2005.03), which contains an entry for each package's report file\n | No permission to copy or redistribute this software is given. |\nthat is currently supported.\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds data from modified image records of the Image file (2005)\nand serves as an audit trail for modified images. When image deletion takes\n | |\nplace, the image is deleted on the server if it is there, the Parent Report\nfile's pointer to the image file is deleted, the data from the Image file\nis copied over to this file using the same IEN, and the node in the image\nfile is set to null as it can never be used again. The image residing on\nthe WORM drive cannot be deleted, so it can always be retrieved.\n This file stores the modified image record from the Image file\n(2005) and serves as an audit trail for modified images. When\nimage deletion takes place:\n \n * The image is deleted on the imaging server (if it is there).\n | Property of the US Government. |\n * The parent report file's pointer to the image file is deleted. \n * The data from the image file is copied over to this file using the same IEN. \n * The node is deleted from the image file. \n The image residing on the WORM drive cannot be deleted, so it\ncan always be retrieved. The field names and definitions are the\nsame as the Image file (#2005).\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n This file will contain an entry for every network storage location, as\nwell as MUSE (EKG) network location(s). This file maps logical device\n | |\nnames to physical device names, allowing continued operation even when\nnetwork storage devices are done. The Imaging site parameters has a number\nof fields pointing to this file to locate where on the network different\nfiles are written. Because the Imaging System operates in a distributed\nenvironment, an object may be stored on one or more of the network storage\ndevices. These include multiple magnetic file servers, one or more\noptical jukeboxes, and possibly additional network devices accessed\nthrough a gateway.\n \n Each logical location in the Network Location file is mapped to a\n | Property of the US Government. |\nphysical device. Every physical device on the network that will be used\nfor objects must have at least one entry in the Network Location file.\n \n The Operational Status field allows rapid software reconfiguration in the\nevent of failure of one of the object storage devices.\n \n Each network storage device has a type, such as magnetic or optical.\nThis allows "automatic file migration," where an object resides on a fast\nmagnetic disk until 30 days since its last access, then it is moved to\nslower, less expensive optical media.\n | No permission to copy or redistribute this software is given. |\n \n Three fields in the Image file (2005) are used to indicate the storage\ndevice(s) on which the object resides. For example, an object may\noriginally be captured to MAG1, the first magnetic server. Within\nseconds, an abstract is created and stored on this same device; the Disk &\nVol, Abstract field will be set to MAG1 also. Next, the Image file will\nbe copied to the optical jukebox (if present on the network), creating an\nimmediate backup copy. The Disk & Vol, Optical field will now be set to\npoint to the optical device used for the optical copy.\n \n | Use of unreleased versions of this software requires the user |\n The Network Location file was designed to allow access across a gateway.\nThis type of access has not been required at the test sites.\n \n We recommend using names for magnetic devices that begin with the three\nletters, MAG, followed by sequential numbers. We recommend that images be\nstored in directories named IMAGE at the first level. Do not store any\nfiles in this directory that are not objects handled by File 2005.\n \n Logical names for Write Once Read Many (WORM) optical devices should\nstart with the four letters, WORM.\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nAnatomic pathology specimens are generally stained. This file contains a\nlist of all the various stains used in making the slides. There is a field\n | |\npointing to this file in the Image/object file (2005) indicating which\nstain was used on the slide from which the image was captured.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n The Microscopic Objective file contains a list of choices of microscope\npower available for selection during an Anatomic Pathology image capture.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file stores information\nfor the Telepathology Worklist that cannot be stored in the\nLAB DATA file.\n\n
\nThis file stores information related to the Consultation/Interpretation\nfunctionality for Telepathology.\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about each patient with whom Imaging \nprocedures and studies are associated within VistA.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about each procedure corresponding to a \npatient in the IMAGING PATIENT REFERENCE File (#2005.6).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about each study corresponding to an entry \non the IMAGING PROCEDURE REFERENCE file (#2005.61).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about each series corresponding to an \nentry on the IMAGE STUDY file (#2005.62).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains CT DOSE information corresponding to an entry in \nthe IMAGE SERIES file (#2005.63).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains PROJECTION X-RAY DOSE information corresponding to\nan entry in the IMAGE SERIES file (#2005.63).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains anatomic target region codes and descriptions.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains phantom type codes and descriptions.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file stores coding schemes associated with irradiation instance \ncodes.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about each SOP instance corresponding to an\nentry on the IMAGE SERIES file (#2005.63).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about each physical file instance\ncorresponding to an entry on the IMAGE SOP INSTANCE file (#2005.64).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about duplicate UIDs.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file contains duplicate and corrupt entries from Imaging files.\n\n
\nThis file contains information for imaging DICOM fields that will be \ndisplayed when capture of an image is done within VI Capture Client.\n \nAdded by Patch MAG*3.0*106\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains entries indicating the Imaging institution associated\nwith an action performed on an Imaging file entry.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed |\n | in any way. Modifications to this software may result in an |\n | adulterated medical device under 21CFR820, the use of which |\n | is considered to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n The purpose of this file is to present a standard list of Image \nCategories to the user.\n | |\n The user of the VistA Imaging Capture application is able to \nselect from this list during the capturing of images that are not\nassociated with a specific VistA Package.\nThis file is pointed to by the Image file (2005) and the Image\nAudit file (2005.1).\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file has all the class types of images and is used in the indexing \nof images, which allow clinicians to apply sort filters when viewing or\n | |\nresearching images.\n \nThis file is updated by Imaging and should not be edited on-site. \nRequest for additions or modifications should be submitted to the Imaging \nDevelopers group.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file has all the types of images and is used in the indexing images \nto allow clinicians to apply sort filters when viewing or researching \n | |\nimages.\n \nThis file is updated by Imaging and should not be edited on-site.\nRequest for additions or modifications should be submitted to the Imaging\nDevelopers group. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file has all the specialties and sub-specialties that an image can be\ncaptured to. These specialties will be used to allow clinicians the\n | |\nflexibility to filter images according to only the images they are \ninterested in researching or viewing.\n \nThis file is updated by Imaging and should not be edited on-site.\nRequest for additions or modifications should be submitted to the Imaging\nDevelopers group.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file has all the possible procedures or procedural events that an \nimage can be associated with and will be used for indexing images. The \n | |\nPROCEDURE/EVENT associated with an image can be used in filters defined by \na clinician. \n \nThis file is updated by Imaging and should not be edited on-site.\nRequest for additions or modifications should be submitted to the Imaging\nDevelopers group.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is populated with post processing actions for each image type. \nThe file has a multiple 'TYPE' field that points to the file IMAGE INDEX \n | |\nFOR TYPES which allows the possibility of multiplempost processing for\neach entry in this file.\n \nWhen an Image is successfully captured an evaluation is done on the \nimage's TYPE property. If the TYPE matches an entry's TYPE field value in\nthis file and the entry is ACTIVE, then execution is passed to the routine\nidentified in the fields: TAG and ROUTINE.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file holds Image Filters created by each user, and Created by an \nImaging system manager as public filters, to be available for all users.\n\n
\nThis file is used to map DICOM modalities and specialties to procedure \nfor XMOD, if one is defined; else it returns a null value.\n \nThis file is not to be modified by sites.\npointers that can be populated into the PROC/EVENT Field (#43) of the \nIMAGE File (#2005).\n \nFunction $$FIELD43^MAGXMA(XMOD,XSPEC,XPROC) returns in XPROC\nthe procedure\npointer defined\nunder modality XMOD for specialty XSPEC, if XSPEC is sent and is defined \nin this file. Otherwise, the function returns the default procedure \n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file stores valid reasons (justifications) for actions performed on\nimages: copying, printing, etc.\n | |\n \nOnce a reason is referenced by a record of other file (e.g. IMAGE file \n(#2005)), it cannot be deleted. Use the DATE OF INACTIVATION field (.03) \nto exclude the reason from the list presented to the users.\n \nThis file is defined by the patch MAG*3*93.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file contains the body part index term for the images captured by \nVI. It also contain the corresponding values in ICD, LOINC, SNOMED CT, \nand DICOM standard.\nThe information is stored in DICOM header during the conversion of image \nfiles in JPEG or TIFF formats to image files in DICOM format.\n \nThe Body Part Term could be used to sort and retrieve group of images for \neducational and research uses when the corresponding information is \nstored in VistA Imaging data files.\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n The Image Background Queue file is a holding file for all the entries to\nbe processed by the Background Processor. Entries are made by Clinical\n | |\nCapture workstation, VistARad Diagnostic workstation, DICOM Image\ngateways or the Background Gui application for functions such as copying\nfile to and from the jukebox and/or magnetic drives. The Background GUI\napplication will update entries as well as remove entries from this file.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains the pointers for the Imaging Background Queue file. It\ntracks the status of queue processing.\n | |\n \n The Background Processor uses three files:\n 1. Queue (2006.03)\n 2. Queue Pointer (2006.031)\n 3. Jukebox (2006.032)\n \nThere are five different tasks that can be performed by the background\nprocessor:\n \n1. ABSTRACT -- create a small version of an image\n | Property of the US Government. |\n \n2. EXPORT ---- copy an image to an export directory so that it can be used\noutside the imaging system\n \n3. IMPORT ----copy an image from an import directory into the imaging system\n \n4. JUKEBOX ---copy an image from hard disk to the jukebox\n \n5. JBTOHD ----copy an image from the jukebox to the hard disk\n \n | No permission to copy or redistribute this software is given. |\nThere is a single Input Queue file for all the requests, with a\ncross-reference to request type. The background processor processes the\nentries in a prioritized first-in first-out fashion, and uses the Queue\nPointer file to record its progress. The background processor uses the\nJukebox file for device-specific information. The jukebox platters are\nlogically placed into the Network Location file, and are pointed to by the\nJukebox file and the Image file. Jukeboxes, which can be configured as a\nsingle volume, only have a single entry in the network location file.\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nTracks images that are on jukebox platters that have been removed\nfrom the jukebox\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is necessary to manage the rich data set that is passed during \nthe Import queue event. It is kept in sync with the Image Background\n | |\nQueue file (#2006.03) through the 2006.03's field #10 QUEUE DATA ITEM.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this file each represent a file to be transmitted\nto a remote location.\n | |\nEntries are placed (automatically) into this file when images\nare acquired, based on rules that are set up in a separate table.\nEntries in this file are processed by a "background routing processor"\nthat takes care of the actual transmission of files to remote locations,\nand also takes care of purging obsolete routed files from those locations.\nProcessed entries can be purged from this file using a menu option\non the menu of the "Routing Processor".\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this file tally the activity of any automated routing\nthat takes place on the site where this file resides. Any images\n | |\nthat are transmitted from this file will be tallied in this file.\nSee also the "DICOM STATION" file, which contains similar information,\nbut compiled for multiple sites.\n\nThe counts that are reported in this table reflect the numbers of groups\nof images that were transmitted to the various locations\nThe 'Description' field further describes the counts in an entry\nto reflect either 'Duration' or 'Lag' time.\n'Duration' refers to the total time needed to transmit the whole\ngroup of images\n | Property of the US Government. |\n'Lag' time refers to the time-span between the acquisition of the last\nfile of a group of images, and the transmission of the\nfirst file for that group of images to the destination\nin question.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is used to manage and track the various devices used to \n"Import" images into the Vista Imaging network.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\nThis file is used to archive and document each of the subprocesses\ninvolved in managing Import queues. It is a potential source of \ninformation regarding the isolation of inefficient Import processes.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe Imaging Site Parameter file contains those variables which are site\nspecific, and which are necessary for the Imaging Software to perform\n | |\nproperly. Most of the fields have MUMPs cross-references with which they\nare associated that are used by the software for quick access to the\nspecific data. Some of the fields defined may not be in use presently, but\nare reserved for future development. Review the Imaging Installation\nManual for instructions on making entries into this file.\n \nNon-integrated sites and Integrated sites that have one shared image \nstorage location have one record. Integrated sites where each site has\ntheir own image storage have one record for each of the associated sites.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nTelepathology Configurations\nStores site templates and other site-related parameters\nfor the Telepathology GUI.\n\n
\n +---------------------------------------------------------------+\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n +---------------------------------------------------------------+\n \nThe purpose of this table is to specify the first groups\nof digits for the unique object identifiers that will be\ngenerated by the software.\nNote that this "root" for the UIDs is organization-specific,\n | Property of the US Government. |\nand that the FOIA release of this software will only\ninclude data for this table for VA sites.\n \nSee the DICOM Standard (www.nema.org/dicom) PS 3.8 Annex A\nfor instructions on how to obtain a valid UID root.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n | The Food and Drug Administration classifies this software as |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is used to store MUSE version numbers. It is pointed to by\nthe Imaging Site Parameters file (2006.1). It is needed in order\n | |\nfor the Imaging Display software to perform certain actions based\non the MUSE version installed at the site. This file will be updated \nas new MUSE versions are released. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file holds the list of MUSE Test Types that are used\nby the MUSE FORMAT TABLE File to map a Test Type to a \nMUSE Format ID number.\nSites can add new Test Types to this file if needed.\nIMPORTANT:\nThe TEXT of the Test Type that is entered into this file\nmust EXACTLY Match the TEXT of the Test Type on the MUSE System.\n\n
\nThis File is a mapping of MUSE Test Types to the MUSE Format ID number\nIf Site Specific Format ID's have been entered into the \nMUSE FORMAT TABLE, those Format ID's will override the defaults.\n---------- Default mapping ----------------------\nTest Type Grid Format ID\nRestingECG Y 6\nStress Y 7\nHolter Y 8\nHiRes Y 9\nRestingECG N 12\nHiRes N 13\nfor a specified MUSE System.\nStress N 14\nHolter N 15\nThe default Format IDs listed below are used by the MUSE System\nto compile the MUSE Test data, for the specified Test Type, into\na PDF File for viewing.\nThe deafult Format IDs cannot be modified.\nSites can add entries to this file if any of the Default mappings\nof MUSE Test Types to MUSE Format IDs is not correct for a certain\nMUSE System.\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file keeps user preferences for placements of the Imaging System\nwindows components. \n | |\n \nFor example:\n . window placement: top, left, height, width, \n if it is standalone or MDIChild;\n . font for reports;\n . acquire images from archive (jukebox)\n . number of abstract to display in abstract window\n . display Radiology exam listing\n . patient listings\n . and more to be added for future development.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n This file contains the names of domains using the imaging system and the\nbeginning characters used for image file names created at each site.\n | |\n \n Note: The information in this file should not be edited. This file is\nused during initial setup of the Imaging Site Parameter file.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is used by the VistA Imaging DICOM Text gateway for reading\nmessages regarding Admission, Transfer, Discharge, Patient demographic\n | |\nchanges, and Radiology order processing. The DICOM gateway will route the\nmessages to commercial PACS vendors or modality worklist interfaces.\n \nFileman should not be used to enter information into this file. Entries\nare made into this file from the MAGD SEND ORM, MAGD SEND ORU, and MAGD\nDHCP-PACS ADT EVENTS protocols.\n \nMaintenance on this file is performed from the DICOM gateway. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis table contains the DICOM Element Dictionary.\nEvery element that is part of the 1999 DICOM Standard is stored\n | |\nin this table.\nElements that may only have a restricted number of values are marked,\nand the list of allowed values is itemized in this table.\nElements that are marked as "Obsolete" in the DICOM standard are\npresent in this table, and also marked as "Obsolete".\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table indicate classes of additional data fields\nthat will be displayed with images from certain origins.\n | |\nThe top-level of this table indicates the class of possible origins,\nthe next-deeper level is the list of fields for that class.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table define the message structure for the\nvarious messages that are exchanged in the context of communication\n | |\naccording to the DICOM standard.\nEach entry defines the structure of one message-type.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table link the names of the various Unique IDentifiers\nthat are defined in the DICOM standard to their numeric representations.\n | |\nCross-references are present to allow for an easy method of finding the\nname, given the numeric UID, or the other way about.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table define any extended SOP Negotiation information\nthat is being used in the context of establishing a DICOM communication\n | |\nstream.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file will contain a list of unique identifiers for\nDICOM SOP Classes.\n | |\n \nEach of these UIDs (Unique IDentifiers) corresponds to a\nDICOM Service Class that is used for the acquisition of\nimages.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\nThis file documents specific actions to be taken to process various kinds \nof DICOM-defined entities or attributes, such as SOP Classes, application \ncontexts, etc.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table link the names of the various Protocol Data Units\nthat are defined in the DICOM standard to their hexadecimal representaitons.\n | |\nA cross-reference is present to quickly find the PDU from its hexadeximal\ncode number.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds the Query/Retrieve requests that are generated by VistA\nto be performed by the DICOM Gateway.\n | |\n \nThe DICOM Gateway uses the MAG DICOM Q/R CLIENT to read this file and\nto pass information back to the VistA Q/R client.\n \nThis file should be truncated periodically, as there is no need for\nthe information in this file after the Q/R request has been processed.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe DICOM RETRIEVE REQUEST QUEUE is located on the DICOM Gateway.\n \n | |\nThis file holds retrieve requests that are generated by VistA and DICOM Gateway to be\nhandled by a Retrieve Client Process on the DICOM Gateway.\n \nThe DICOM Gateway Retrieve Client Process uses the MAG DICOM Q/R CLIENT to pass\nretrieve status information back to the VistA Q/R client.\n \nThis file should be truncated periodically, as there is no need for the\ninformation in this file after the retrieve request has been processed.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis table contains information about batch query/retrieve runs\nthat either compare images between VistA and PACS or retrieve\n | |\nmissing images for PACS. The Q/R runs can be for either radiology\nor consult/procedure requests.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table contain the demographic information for the various\npatients, for whom tasks are recorded on the worklist for a DICOM "modality".\n | |\nThe top-level information in this table separates the patients from the\nvarious clinics at a consolidated site; the next level contains the patient\ninformation.\n \nThis file contains temporary copies of information from the VistA\nsystem that live on our satellite systems for the duration of the\nstudy that produces the images, and the only reason for\nreplicating the information onto these "DICOM Gateway Stations"\nis that we want to be able to allow the acquisition of images and\nthe presentation of "worklist information" to continue, even\n | Property of the US Government. |\nwhile the VistA system is down, or when the RPC connection\nbetween our Gateways and the VistA system is not operating. \n \nInformation is copied from VistA to DICOM Gateway when an HL7\nmessage is processed that announces the "exam", and removed when\nan HL7 message is processed that announces that the exam is\ncarried out. \n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table contain the information about the various\nstudies that are recorded as tasks on the worklist for a DICOM "modality".\n | |\nThe top-level information in this table separates the activities from the\nvarious clinics at a consolidated site; the next level contains the study\ninformation.\n \nThis file contains temporary copies of information from the VistA\nsystem that live on our satellite systems for the duration of the\nstudy that produces the images, and the only reason for\nreplicating the information onto these "DICOM Gateway Stations"\nis that we want to be able to allow the acquisition of images and\nthe presentation of "worklist information" to continue, even\n | Property of the US Government. |\nwhile the VistA system is down, or when the DDP connection\nbetween our Gateways and the VistA system is not operating. \n \nInformation is copied from VistA to DICOM Gateway when an HL7\nmessage is processed that announces the "exam", and removed when\nan HL7 message is processed that announces that the exam is\ncarried out. \n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis table contains only one entry.\nThe information in this entry defines the customization for the DICOM\n | |\nGateway Processor on which this table is stored.\nNote that some site-specific parameters apply to the whole site, those\nparameters are stored in the table "IMAGING SITE PARAMETERS", and other\nparameters apply to the individual PCs. The latter parameters are stored\nin this table.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table define the various FIFO queues that are\npart of the DICOM Gateway operation. For each queue, the entry defines\n | |\nhow that queue is being used (incoming or outgoing messages, requests\nor responses, and relative priority).\nCurrently, 16 queues are defined.\n \nFor requests initiated by the remote DICOM application entity:\n \n +-----+-----+-----------+----------+-----------+\n | Ltr | Chn | Direction | Type | Priority |\n +-----+-----+-----------+----------+-----------+\n | A | * | INCOMING | REQUEST | HIGH |\n | Property of the US Government. |\n | B | * | OUTGOING | RESPONSE | HIGH |\n | C | * | INCOMING | REQUEST | MEDIUM |\n | D | * | OUTGOING | RESPONSE | MEDIUM |\n | E | * | INCOMING | REQUEST | LOW |\n | F | * | OUTGOING | RESPONSE | LOW |\n | G | * | INCOMING | REQUEST | IMMEDIATE |\n | H | * | OUTGOING | RESPONSE | IMMEDIATE |\n +-----+-----+-----------+----------+-----------+\n \nFor requests initiated by local DICOM application entity:\n | No permission to copy or redistribute this software is given. |\n \n +-----+-----+-----------+----------+-----------+\n | Ltr | Chn | Direction | Type | Priority |\n +-----+-----+-----------+----------+-----------+\n | S | * | OUTGOING | REQUEST | IMMEDIATE |\n | T | * | INCOMING | RESPONSE | IMMEDIATE |\n | U | 1 | OUTGOING | REQUEST | HIGH |\n | V | * | INCOMING | RESPONSE | HIGH |\n | W | 1 | OUTGOING | REQUEST | MEDIUM |\n | X | * | INCOMING | RESPONSE | MEDIUM |\n | Use of unreleased versions of this software requires the user |\n | Y | 1 | OUTGOING | REQUEST | LOW |\n | Z | * | INCOMING | RESPONSE | LOW |\n +-----+-----+-----------+----------+-----------+\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis table is used to keep track of the various Machine IDs on\nthe DICOM Gateways. Since each ID has to be a unique one, the\n | |\nsoftware that maintains this table uses the data in this table\nto ensure that the same ID is not issued multiple times.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis table contains information about batch runs that export DICOM data.\nEach record in this table keeps track of the actual parameters of\n | |\none single batch run.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various HL7 segments that are\nbeing processed in the context of the DICOM-related activities.\n | |\nCurrently, only HL7 messages that are germane to the building and purging\nof DICOM Modality Worklists, are being processed.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe a number of parameters about image\nfiles that have been received by a DICOM Image Gateway.\n | |\nEntries are placed into this table (automatically) when a C-Store processor\ndelivers a file to the Image Gateway.\nEntries are removed from this table (automatically) when the "Process Images"\ntask on the Image Gateway processes the image in question.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe activities that are requested\nby DICOM Gateways, to be performed by procedures that are\n | |\nexecuted remotely on a VistA Server.\n\nThe name of the Remote Procedure that processed these requests\nis MAG DICOM IMAGE PROCESSING; the code for this procedure\nstarts at ENTRY^MAGDIR8.\n\nThe data in the various request-records contains a code that\nspeficies the type of operation, and any subsequent data\nin the request are parameters for that operation.\n\n | Property of the US Government. |\nCurrently, the following requests are recognized:\n(upper case values are constants, lower case values\nindicate variable values):\n\nPROCESSED|0|location|instrument|image|1\nCORRECT|PROCESSED|image|study|deletion|instrument|filename|study_uid|gateway_id\n\nThe data in this file is extremely volatile.\nRecords will be entered, processed and deleted in rapid progression.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe images that initially could\nnot be processed because erroneous information was encountered\n | |\nin their file-headers.\n\nThe entries in this table describe those images for which the\nerroneous information has been corrected, and that are now\nready to be (re)processed.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe images that could not be processed\nbecause the DICOM Gateway had no information about the "modality"\n | |\nthat generated the image.\n\n"Modalities" are defined in table 2006.582 (MODALITY TYPE DICTIONARY),\nwhich is populated from the text-file xx:\\DICOM\\DICT\\MODALITY.DIC.\n\nThe "C" cross-reference on this table organizes the problem-images\nby the identifying properties of the "modality": manufacturer,\nmodel, and modality-type.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe images that could not be processed \nbecause they were incompletely captured.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis table contains the DICOM Element Dictionary.\nEvery element that is part of the 1999 DICOM Standard is stored\n | |\nin this table.\nElements that may only have a restricted number of values are marked,\nand the list of allowed values is itemized in this table.\nElements that are marked as "Obsolete" in the DICOM standard are\npresent in this table, and also marked as "Obsolete".\nan image with a UID that is already in the database (but only if the\nUID of the new image is equal to the UID of the image that was being\nprocessed when the DICOM Image Gateway was interrupted.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file will record all the incomplete image files received on the DICOM\nImage gateways as well as any entries in the DICOM FAILED IMAGES that were\n | |\nmarked for deletion. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about studies\nfor which all images have been transmitted\n | |\nto a VistA DICOM Gateway.\n \nWhen all images for a study have been transmitted,\nthe study (or examination, or briefly, 'exam')\nis called 'complete'.\n \nThe information that is collected for each study\nconsists of a flag that indicated whether or\nnot the exam is complete,\nan accession number,\n | Property of the US Government. |\na patient ID as well as the patient's name,\nand an unique identifier for the study (UID).\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various requests to obtain\ninformation from a PACS from General Electric.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table are the result-sets that are created\nin response to DICOM Query/Retrieve requests that may be processed\n | |\nthrough Remote Procedure Calls.\n \nEach entry in this table is one such result-set.\n \nResult-sets are kept in this table, so that client-stations can\ncall Remote Procedures to obtain the content of a result-set in\nportions of a limited size.\n \nAlso, since the creation of a result-set may need more time than\nis reasonable wait for in a single Remote Procedure Call, the\n | Property of the US Government. |\nexistence of this table makes it possible to call a first\nRemote Procedure to create the result-set through a TaskMan process\nand then call subsequent Remote Procedures to inquire whether\nthe result-set is complete, and subsequently to obtain the results.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table are statistics about the usage\nof the DICOM Query/Retrieve facility.\n | |\nEach entry in this table tallies how often a specific query occurred.\nSome entries in this table have sub-records that tally how often\nspecific results occurred.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe requests to transmit image files\nto an alternate storage provider.\n | |\nThe top-level of this table identifies the storage provider, the next\nlevel identifies the images for which files are to be transmitted.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe image files that were received by the\nDICOM Image Gateway, and could not be matched with a patient and an\n | |\nordered study.\n \nThe MAGD FIX DICOM FILE and MAGD FIX MEDICINE DICOM FILE menu options are\nused to update the entries in this file. The DICOM Image Gateway will\npoll this file for corrected entries. The cross reference used to poll\nthis information is ^MAGD(2006.575,"AFX".\n \nThe routine L^MAGDLB1 is used by the above menu options and will loop thru\nthe following cross reference ^MAGD(2006.575,"F". This cross reference is\nset by the DICOM Study Instance UID; this is a unique number assigned by\n | Property of the US Government. |\nmodalities (imaging equipment) and is unique by case study. So it is\npossible to have over 20 entries in the file and only one unique "F" cross\nreference. \n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThe DICOM OBJECTS TO BE IMPORTED file (#2006.5751) resides on the DICOM\nGateway and tracks DICOM objects that have been received and may be imported.\n \nEntries are made to this file by reading the DICOM Object files and recording the \nraw data elements from the file. The information is displayed in listing\nwhich are selectable for importing into the VistA database.\n\n
\nThe IMPORTABLE DICOM OBJECTS file (#2006.5752) is on the VistA HIS and tracks the importable DICOM objects that are on each of the different the DICOM Gateways.\n \nThis allows the site to see all importable DICOM objects from each of the\nsite's DICOM Gateways. \n \nThe information is obtained from DICOM Gateway's file DICOM OBJECTS TO BE\nIMPORTED (#2006.5751). Information is periodically updated by a remote\nprocedure call on the DICOM Gateways connecting to VistA. \n\n
\nThe DICOM RADIOLOGY PROCEDURE MODIFIERS file (#2006.5757) resides on the\nDICOM Gateway. It contains the list of Radiology procedure modifiers \nthat may be used when placing orders for VistA on the DICOM Gateway. \n \nThis file is periodically updated on the Gateway by a remote procedure\ncall to VistA to read file Radiology's PROCEDURE MODIFIERS (#71.2).\nThis allows the Gateway to continue processing if a VistA connections \nis lost.\n\n
\nThe DICOM RADIOLOGY PROCEDURES file (#2006.5758) contains the list of orderable radiology procedures, along with related data that is needed for the Importer to place orders on VistA.\n \nThis file resides on the DICOM Gateway and several of the fields will be\nredundantly storing the same information for pointer fields. This is \nrequired to continue image processing when a VistA connection is lost.\n \nInformation in this file is a combination of data from files RAD/NUC MED\nPROCEDUES (#71) and OUTSIDE IMAGE LOCATION (#2006.5759). The data in this\nfile will be periodically updated via a remote procedure file to VistA.\n\n
\nEntries in this file are locations identified in Radiology's IMAGING LOCATION file (#79.1) for \nentities that are non-credit locations. These entries will be used by the DICOM Gateways during the \nordering process to assign a location to an 'unordered' Radiology study. The DICOM Gateways \nperiodically download this file.\n \nUse menu option 'Build Outside Imaging Location File' [MAG BUILD OUT LOC] to populate this file.\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nAs messages are being processed by VistA DICOM Text Gateways,\nstatistics are being logged about the number and nature of these\n | |\nmessages.\n \nThe entries in this file keep track of how many occurrences\nof the various message types occur per day.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n \nAs images are being processed by VistA DICOM Image ext Gateways,\n | |\nstatistics are being logged about the number and nature of these\nimages.\n \nThe entries in this file keep track of how many images were\nacquired per day from the various instruments that produce images,\nand how many of these images were processed.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nAs messages are being processed by VistA DICOM Text Gateways,\nstatistics are being logged about the number and nature of the\n | |\nevents that cause these messages.\n \nThe entries in this file keep track of how many transactions\noccurred for each accession number being processed, and how\nmany events were processed for each accession number.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n \nAs images are being processed by VistA DICOM Image ext Gateways,\n | |\nstatistics are being logged about the number and nature of these\nimages.\n \nThe entries in this file keep track for every instrument that\nproduces images of whether or not the instrument is currently\nconnected, whether or not an association is currently established.\nThis file also tallies on a day-by-day basis how many associations\nhave been established, and how many image files have been transmitted.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe VistA DICOM Text Gateway organizes some of its activities\nby entering various chunks of work into FIFO queues.\n | |\nThe entries in this file keep track of the processing of the\nentries in these FIFO queues.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nData recorded in this file will be set and removed by the VISTA DICOM\ngateway. Please do not edit entries in this file.\n | |\n \nA message display and logging facility is provided in the VISTA DICOM\ngateway by the ^MAGDMLOG routine. Status, informational, progress, and\nwarning messages generated by the various processes are passed to the\nroutine via the MESSAGE entry point. The messages for the process are\nstored in the ^MAGDMLOG global, where they can be retrieved (from\n^MAGDMENU or programmer mode) by invoking the DUMP entry point. Each\nmessage is also displayed in real-time on the MSM Console window, if the\nwindow is free (i.e., not owned by another job).\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various image acquisition\ndevices that may transmit image files to an Image Gateway.\n | |\nNote: a "modality" is a class of devices, an "instrument" is a\nspecific device, or an instance of such a class.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n \n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | ||\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various types of image\n | |\nacquisition devices that are present at a site.\nNote: a "modality" is a class of devices, an "instrument" is a\nspecific device, or an instance of such a class.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table document about the history of\nof the conversion parameters that were used to create Targa files from DICOM streams.\n | |\nThe history in this table is used to reconstruct DICOM files when needed\nfor export to external devices.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various image acquisition\ndevices for which the site maintains a DICOM Modality Worklist.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis contains the parameters that are used to interface CPRS\nConsult Request Tracking to DICOM Modality Worklist and HL7.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nAnatomic Pathology images are associated with TIU documents that\ncontain the diagnostic report. Until the TIU document is created,\n | |\nthis Imaging file temporarily records the association for the\nAnatomic Pathology image entries. The Lab package notifies Imaging\nwhen an Anatomic Pathology case is electronically signed and a TIU\nnote is created for the report. Imaging then changes the association\nparent data file to the TIU document(actually the TIU EXTERNAL DATA\nLINK file (#8925.91)). The entry in this file is then deleted.\n \nIf the TUI document exists at the time that the image is acquired,\nthe association is made to it and this file is not used.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis is an Imaging file that temporarily stores image entries that have\nbeen acquired on the DICOM gateways and do not have an associated\n | |\napplication parent report entry. Imaging is a subscriber to the protocol\nentry GMRC EVSEND OR (Consults event sent to OE/RR) and evaluates all HL7\nmessage segments received from this protocol. When an ORC message segment\nis received for a signed result (signed TIU note) then a module is called\nto lookup the entry in this file for possible matches and once found will\nupdate the image entry in the Image file with it's associated parent\nreport and file the image pointer in the associated parent report. The\nmatched entry is then deleted from this file. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various providers of DICOM\nservices that are accessible from the DICOM Gateway computers.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis dictionary contains the information that defines the TeleReader worklist. This\ndictionary is located at the Acquisition Site.\n\n
\nThis dictionary indicates the status of the Acquisition Site from the\nperspective of the reading site. It is used to indicate service\noutages. For example, if the network is down between the two sites, \nthe status would be set to 'Inactive'.\n\n
\nThis dictionary maintains the Specialty and Acquisition Site\nfor each reader. It is maintained at the reading site.\n\n
\nThis is the Unread/Read list and is stored on the Acquisition Site's Vista system. \nThe file is indexed by pointers to file IMAGE INDEX FOR SPECIALTY/SUBSPECIALTY file (#2005.84)\n and IMAGE INDEX FOR PROCEDURE/EVENT file (#2005.85).\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various services that are\nbeing used by the DICOM Gateway as a DICOM Service User.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table describe the various services that are\nbeing offered by the DICOM Gateway as a DICOM Service Provider.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe routing software is able to transmit image files from the\nVistA system where the images are stored permanently to various\n | |\ndestinations that may receive temporary copies of images.\nFiles can be transmitted to these destinations using several\nprotocols. Valid destinations for files that are transmitted\nusing the MS-DOS copy protocol are stored in the Network Location\ntable (FileMan file #2005.2).\nValid destinations for files that are transmitted using the\nDICOM C-Store protocol are stored in this file.\n \nFor each destination, this table contains the identifying information\nfor the destinations, as well as the identifying information for\n | Property of the US Government. |\nthe DICOM Gateways that are allowed to transmit images to these\ndestinations. If multiple DICOM Gateways are allowed to transmit\nimages to a specific destination, this table will contain multiple\nentries for that destination, one for each source and destination pair.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThe APPLICATION ENTITY TITLE file (2006.588) is used to map Application Entity Titles to aliases and descriptive names. It is built from the entries in AETITLE.DIC.\ndescriptive name, which help to identify it better. In this case, if the SCU's Called Application Entity \nTitle is one that is defined in the SCP_LIST.DIC, the entry in the APPLICATION ENTITY TITLE file is optional.\n \nThe APPLICATION ENTITY TITLE file is used for two purposes. When a DICOM Service Class \nUser (SCU) negotiates an association with VistA, it may present a Called Application Entity Title that is \ndifferent than one defined in the SCP_LIST.DIC. The APPLICATION ENTITY TITLE file may \ncontain an entry for the SCU's Called Application Entity Title that maps it to one that is defined in \nSCP_LIST.DIC. This is required in order for the association to be accepted.\n \nThe second purpose is to provide a mapping from the SCU's Calling Application Entity Title to a more \n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThe entries in this table define the various rules for automatically\nrouting image files to remote locations.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n\nThis file will be used by the software that processes routing rules\nand that governs the load-balancing of images to be viewed over\n | |\na number of candidate recipients.\n\nThe data in this file will be extremely volatile, and any data\nolder than a day will be removed automatically.\n \nThe load-balancer uses the data in this file in two ways:\n - when the first image of a new study is being processed,\n the load-balancer will calculate the designated recipient\n for that study, based on the routing rule in question\n - when subsequent images of that study are being processed\n | Property of the US Government. |\n the load-balancer will ensure that they are transmitted\n to the same destination.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n\nThis file is used to keep track of the various queues and\nqueue-threads that are used to conduct automated routing.\n | |\n\nThe information in this file will be used by end-users\nto view which queue-threads are active, and to indicate that\nqueue-threads are to be stopped or resumed.\n\nThe various queue-processors will query this file to see\nwhether a request has been posted to stop (suspend)\nthe queue-thread that they are processing.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nAs a DICOM Gateway performs its various tasks, there are occasions\nwhere error messages need to be transmitted to remote recipients\n | |\n(FileMan users and/or mailgroups as well as SMTP mail recipients).\n \nWhen such a message needs to be transmitted, a new entry is made\ninto this table, which will contain the message text and some\ninformation about the message. Then an attempt is made to transmit\nthe message.\nWhen the transmission is successful, the entry is removed from\nthis table.\n \nWhen the transmission is not successful (which is likely since\n | Property of the US Government. |\nmany errors that need to be transmitted have to report some\ntype of "network failure") the text remains in this table while\nthe software on the DICOM Gateway can enter its further error\nprocessing.\n \nA supervisory task on the DICOM Gateway scans the content of\nthis table on a regular basis and will transmit any "left over"\nmessages.\nAs soon as a message has been transmitted successfully, its\nentry in this table will be removed.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file will record all the incomplete image files received on the DICOM\nImage gateways as well as any entries in the DICOM FAILED IMAGES that were\n | |\nmarked for deletion. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nA problem was caused by patch MAG*3.0*226 (October 2019) which changed\n \nAn index to the JPEG.DCM problem images is maintained in this file. \nThis file is only accessed by MAG*3.0*350.\nthe way that Clinical Capture stored DICOM images.\n \nInstead of saving them as DICOM objects, they were stored as raw JPEG\nimages with a *.DCM extension (that is, JPEG.DCM).\n \nThese images need to be converted to DICOM and reprocessed. The previously\nstored JPEG.DCM IMAGE file entry needs to be copied to the IMAGE AUDIT\nfile (#2005.1) and deleted from the IMAGE file (#2005).\n\n
\n +---------------------------------------------------------------+\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n +---------------------------------------------------------------+\n \nThis file contains historical entries from MODALITY.DIC for\nCT modalities. The data in the file can be used to determine\nwhat the Dicom-to-TGA processing parameters were used for a\ngiven device as of specified dates. This is needed when\n | Property of the US Government. |\na TGA-to_Dicom conversion must be performed, or when performing\nHounsfield calculations for these older files. The processing\nparameters are needed for CTs processed prior to Patch 50;\nafter then, the parameters are stored in the individual image\ntext files.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n | The Food and Drug Administration classifies this software as |\n\n
\n +---------------------------------------------------------------+\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n +---------------------------------------------------------------+\n \nThis file is used to indicate that a correction for a historical\nproblem with certain Fuji CR images should be applied when\nperforming measurements on those images. Entries should be added\nto this file to define precisely which CR Models/Software versions\n | Property of the US Government. |\nneed to have this correction applied. The problem was that the\nFuji CR image header stored incorrect values in the newer Imager\nPixel Spacing field (0018,1164), whereas the older field (Pixel\nSpacing--0028,0030) still carried the correct value.\nNote that the problem could appear in Fuji CR images, or images\nthat may be identified as coming from DeJarnette ImageShare CR\ndevices.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n | The Food and Drug Administration classifies this software as |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains a list of data elements made available for VistARad \nExam Lists.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nAll exam lists are defined in this file; defines the content and format\nof VistARad Exam Lists.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is used by the Imaging VistaRad system to define search logic\nin the MAG RAD LISTS DEFINITION file. No entries exist in this file, as\n | |\nthe file definition itself is what is used in the data-entry for defining\nthe search logic.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is used by the Radiology Imaging Workstation system to define\nlogic for determining a patient's prior exams that may be of interest when\n | |\nviewing a given exam. Each entry in the file defines a one-to-many\nrelationship for a current exam to prior exams of interest; the mappings\nare defined in terms of CPT codes.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file allows us to map a given Radiology procedure to other\nprocedures of interest based on grouping of CPT codes, or\nattributes associated with the CPT code (Modality, Body Part).\nThis supports logic in the hanging protocols for automatically \nretrieving and displaying prior exams of interest when interpreting\na new exam for a patient.\n\n
\nThis file contains legal values for associating body part information\nwith CPT codes in file #2006.67 MAG RAD CPT MATCHING.\n\n
\nThis file is used for assigning body region designations to the\nMAG RAD CPT MATCHING file entries.\nThe values in this file are derived from the AMA CPT book's RADIOLOGY\nchapter, and correspond to the subsection "body part" headings.\n\n
\nThis file stores various Vistarad user settings, preferences, etc.,\nthat are created on the Vistarad workstation.\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains various site-specific parameters that control the\nbehavior of VistaRad.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains all the Background Processor workstations\nused in the Imaging System.\n | |\nIt points to the Hospital Location file and has other identifying fields.\n The Imaging Workstations file is designed to track imaging workstation:\n * locations\n * volume set names\n * component serial numbers\n * display modes \n It points to the Hospital Location file and has other identifying fields.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n The Imaging Windows Workstations file is used by the Imaging System Manager.\nThis file will contain an entry for any workstation that has connected to this\n | |\nsite during an Imaging Session. The Workstation information is stored in \nthis file.\nidentified to automatically update its Imaging software. The Imaging\nSystem manager at the Medical Centers should periodically review this file\nto ensure that all the workstations have the latest code.\n \n Note: The information in this file should not be edited.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n The Imaging Windows Sessions File (2006.82) and the Imaging Windows \nWorkstations File (2006.81) have fields to store information about each\n | |\nimaging session that connects to this site.\n The information is intended to be used to produce statistical reports,\ntrack workstation usage, Imaging version information for each workstation \nand more.\n This file also tracks errors that occur during an Imaging Session, \nand certain actions that occur on the workstation. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about the instruments that communicate \nwith the DICOM Gateway. Each DICOM Gateway uniquely serves\n | |\none or more instruments.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains the various types of image\nacquisition device modalities. For each DICOM Gateway that is present at a site.\n | |\nNote: a "modality" is a class of devices, an "instrument" is a\nspecific device, or an instance of such a class.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nAn ordered list of strings that have meaning for the client software. \nAllows the client to retrieve artifacts in potentially nested groups \n | |\ndefined by the client. Key List is only connected to the Artifact file (#2006.916) in \na 0..1-to-many fashion. This approach allows the user of the Storage \nService to store relational context of data hierarchies in the subsystem \nto enable intelligent searches by the user for groups of artifacts \nwithout hard coding the relationships between the affected artifacts in \nthe Storage Service.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds the various retention policies available \nto the storage subsystem. They come in two varieties: user-definable, and \n | |\nbusiness.\n \nUser-definable retention policies can be created and mapped to artifact \ndescriptors, to serve as intrinsic retention policies. They can be \ninactivated, or "logically deleted", but only if no artifact descriptors \nare pointing to them. They can never be physically deleted, since there \nare artifacts that still point to the old retention policies, and we need \nto keep the historical record of retention policies that have been \napplied to this artifact over time.\n \n | Property of the US Government. |\nBusiness retention policies are designed to be called by business code \nfor certain patients (e.g., Agent Orange retention policy, Employee \nretention policy, etc.). These retention policies will be installed with \nthe patch and can be "replaced" with updated versions, but not deleted, \nsince business logic will presumably expect to find them.\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file acts as the entry point into storage. It holds information \nabout a particular type of artifact (i.e. medical image in DICOM format), \n | |\nand maps this type of document to its intrinsic retention policy. It also \nstores the file extension to be used for files of the given type.\n \nArtifact descriptor records will be inserted during patch installation \ntime, and are not available for creation or deletion by users. In the \nfirst release, we plan to make them not modifiable as well. In future \nreleases, we will probably add the ability to change the intrinsic \nretention policy for the given artifact descriptor.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds records containing the invariable information \nabout the artifact, regardless of the physical storage location: CRC, \n | |\nFileSize, who the artifact was created by, a link back to the artifact \ndescriptor, etc.\n \nIt acts as the parent for one or more ArtifactInstance records, and holds \nthe token that external clients will use to get a stream representing the \nartifact.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds one record for each "device" in use. For \nexample, if there is a consolidated site with a RAID in place A, a RAID \n | |\nin place B, and an archive in place B, there would be 3 entries in the \ntable.\n \nEach storage provider has a type, as well as fields such as Archive, Primary \n(i.e. "RAID"), etc. These will be used to determine whether a particular \nconfiguration is valid at configuration and runtime.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds the details of a particular instance of the binary data \nfor an artifact. Each record is owned by a specific storage provider, and has a \n | |\nreference to its parent Artifact record, as well as a URL understandable \nby the given provider that can be used to return a stream for the \nartifact.\n \nIt also holds properties related to when the file was created, when it \nwas last accessed, etc.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds information on various parameters of each DICOM Gateway, e.g., mail group, post office, post port.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file stores the application entity names and parameters.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains VistA Imaging applications or services, e.g VI DICOM \nStorage SCP, Asynchronous Icon Service.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file maps an artifact to the set of retention policies currently and also \nhistorically in effect for that artifact. \n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file maps a running history of how particular retention policies \ncaused artifacts to be written to specific storage providers.\n | |\n \nIt is also used by asynchronous archiving to determine which retention \npolicies have not yet been satisfied, and which providers still need to \nbe written to. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file maps retention policies, via an acquisition location, to the \nstorage providers that should be used to satisfy that retention policy.\n | |\n \nIn a valid configuration, the attributes on the retention policy (i.e \nMinimum Archive Copies, etc) can be matched to the corresponding attributes \nof the mapped storage provider (i.e. Archive), to see whether the configuration \nis valid.\n \nThis file also holds a flag indicating whether a particular provider \nshould be called synchronously or asynchronously.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file holds information related to availability of the link between \nan acquisition place and a particular storage provider. If a record is present \n | |\nfor a particular storage provider/acquisition location combination, the link is \nonly available between the start and end times provided. If no record \nexists, the link is available at any time. \n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file gathers statistics about network transfers, for use in reports \nas well as real time estimates of how long a requested transfer may take. \n | |\nIt stores details of a transfer between a provider and a client endpoint, \nincluding the time of day the transfer occurred, the duration of the \ntransfer, and the size of the artifact.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file tracks the history of actions attempted for a particular \nartifact. For example:\n | |\n Successful storage to a particular provider\n Failed storage attempts to a provider\n Successful retrieval from a particular provider\n Failed retrieval attempts from a provider.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file is a list of Queues. It will contain queues for async storage\nrequests and failed async storage requests.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file stores individual queue messages for a queue. It contains the \nmessage, earliest delivery date/time and expiration date/time of a \n | |\nmessage. This will be used to queue asynchronous storage requests.\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains information about audit events.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains VistA Imaging auditable events.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains a queue of work items for worklists in the WORKLIST file (#2006.9412).\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains entries for worklists and their current activity status.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains work item statuses.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains work item subtypes.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file contains a log of studies imported with the Importer II application. (MAG*3.0*118)\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \n \nThis file contains a log of media bundles from which study data were \n | |\nimported by the Importer II application. A media bundle is a group of \nstudies under a single Importer II work item. A media bundle may or may \nnot represent a single piece of media or a single network transaction. \nThis file includes information about media validity, the user who \nreconciled the associated studies, etc.\n(MAG*3.0*118)\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n +---------------------------------------------------------------+\n \nThis file contains MAG work item service type, mapped with Modality and Procedure.\n | |\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\n +---------------------------------------------------------------+\n | The Food and Drug Administration classifies this software as |\n | a medical device. As such, it may not be changed in any way. |\n | Modifications to this software may result in an adulterated |\n | medical device under 21CFR820, the use of which is considered |\n | to be a violation of US Federal Statutes. |\n | |\n +---------------------------------------------------------------+\n \nThis file logs all users and the image activity that took place during\ntheir session (i.e., image accesses, reports displayed, exports, and\n | |\nimage deletions).\n | Property of the US Government. |\n | No permission to copy or redistribute this software is given. |\n | Use of unreleased versions of this software requires the user |\n | to execute a written test agreement with the VistA Imaging |\n | Development Office of the Department of Veterans Affairs, |\n | telephone (301) 734-0100. |\n | |\n\n
\nThis file records the internal entry numbers of IMAGE File (#2005) \nentries whose index values in Fields 40-45 have been automatically \ngenerated using the functionality exported in Patches 17 and 25.\n \nThis file is to be set ONLY by image index conversion routines. It may \nNOT be edited by sites.\n\n
\nThis file contains a log of multiple images that have been queued for \nprinting.\n\n
\nUSER CLASS is to be used for identifying the kinds of all other entries \nin the NEW PERSON file #200 that are not providers identified with PERSON \nCLASS.\n\n
\nThis file contains information on the VIST veterans of interest to\nthe VIST Coordinator.\n\n
\nThis file is designed to use only one entry for the site identifier.\n\n
\nThis file contains eye diagnoses which relate to the VIST veterans.\n\n
\nThis file contains data to be used to answer questions on the\nVIST Benefits Checklist.\n\n
\nThis file contains the information which allows the VIST Coordinator\nto review and track the usage of benefits for legally blind veterans.\n\n
\nThis file contains the names of the Blind Rehabilitation referral\nfacilities.\n\n
\nThis file contains the referral information for the VIST veterans.\n\n
\nThis file contains the boilerplate letters that may be personalized\nfor the VIST facility's use.\n\n
\nThis file contains the information that will allow the VIST Coordinator\nto track claims made to the regional office for the VIST veterans.\n\n
\nThis file contains local benefits and services available to the\nVIST veteran.\n\n
\nThis file contains the main record for VIST Patient Reviews. The subfile \nfor this file is 2048.1 VIST PATIENT REVIEWS SECTIONS.\n\n
\nContains the Patient Review sections linked to each Patient Review record.\n\n
\nThe Nursing Staff file contains information on nursing employees.\nData includes staff demographics, title/position(s) held, FTEE, assignment\nlocations, primary tour of duty, nursing grade/step code, salary, license\ninformation, emergency contact, dates employed, promotion date, Nursing\nProfessional Standards Board/proficiency due dates, professional education,\nhighest nursing and/or academic degree, faculty appointments, certification\ninformation, military experience, MI review group information, and medical\ncenter privileges.\n\n
\nThis file is used to store the fields and data which make up the\nactual code sheet.\n\n
\nThis file stores the FMS documents for the batch type FINANCIAL\nshould not be edit through VA FileMan.\nMANAGEMENT.\n \nThis file is used to manage the transmission of the FMS code sheets\nbetween DHCP and FMS. When FMS code sheets are created manually or\nautomatically, the code sheets are queued for transmission or\ntransmitted immediately from this file.\n \nThis file is used internally by the Generic Code Sheet System and\n\n
\nThis file stores the different batch types of code sheets.\n\n
\nThis file stores the different types of code sheets for each type\nof batch (in file 2101.1).\n\n
\nThis file stores data that manages the creation/transmission of\nbatch numbers (batches of code sheets).\n\n
\nThis file stores a map of the input template which is used for\nassembling the code sheet.\n \nThis file is no longer used in version 2.0.\n\n
\nThis file stores the counter number used for assigning numbers to\neach code sheet and each batch.\n\n
\nThis file is used to store the user, process and date@time a Generic\nbatching and transmitting duplicate code sheets. When one user\nis batching or transmitting and a second user tries to run the\nsame process, a message is displayed from this file to the second user.\nCode Sheet process was locked. A process can be defined as batching \nor transmitting code sheets.\n \nThe data stored in this file is for informational purposes only.\nIt is not used to control the locking of processes in Generic Code\nSheets.\n \nGeneric Code Sheets uses incremental locks to prevent users from\n\n
\nThis file stores the name of the site using the generic code\nsheet system.\n\n
\nThis file contains a list of nursing grade/step codes and their\nassociated GS or Title 38 grade/step levels. \n\n
\nThis file lists names of specific GS and Title 38 grade/step levels and\ntheir related salary. \n\n
\nThis file contains information on nursing 'service positions' and their\nrelated data (i.e., priority sequence numbers, AMIS position, service\ncategory).\n\n
\nThis file contains nursing information on all patient care areas and\noffice locations specific to Nursing Service. \n\n
\nThis file lists areas of professional experience applicable to nursing\nemployees. \n\n
\nThis file contains a list of official tours of duty specific to Nursing\nService. \n\n
\nThis file contains Nursing positions and associated field numbers as\ndisplayed on VA Form 10-1106b(AMIS). \n\n
\nThis file tracks budgeted position within a service.\n\n
\nThis file indicates reasons for position vacancies/transfers.\n\n
\nThis file contains information which is used in determining the\nhighest academic and/or nursing degree of nursing employees.\n\n
\nThis file contains a list of nursing certifications and the related\ncertifying organization/agency. \n\n
\nThis file contains a list of college majors. \n\n
\nContains the titles of inservices which are considered mandatory by nursing.\nThe file is pointed to by the NURS STAFF FILE (#210). \n\n
\nThese are groupings of nursing mandatory inservices.\n\n
\nThis file contains clinical privileges that may be assigned to nursing\nemployees.\n\n
\nThis file contains a list of services/programs/product lines that are being\ntracked by the Nursing Administrative module.\n\n
\nThe VANOD UNIT TYPES file contains Unit Types that are used to \ncategorize nursing locations.\n \nThis file is exported with data and the contents of the file should not be\nlocally modified.\n\n
\nThis file contains comparison FTEE data for Nursing (i.e., total budgeted/\nceiling FTEE vs. actual FTEE). \n\n
\nThis file contains names of official nursing bed sections. \n\n
\nThis file contains the AMIS 1106 manhours, and acuity category totals by\nbedsection for the Nursing Service units on a specific date and shift.\n\n
\nThis file holds the exception data for unclassified patients for the\nNursing Acuity/Separation-Activation Run. Data will be stored for thirty\ndays before it is purged.\n\n
\nThis file contains the current nursing location, and nursing bed section, and\nselected admission information for a patient.\n\n
\nThis file contains classification information in a flat file format.\n\n
\nThis file contains an audit of classification reviews in a flat file format.\n\n
\nData pertaining to the Nursing Care Plan or Patient Plan of Care for a\nparticular patient.\n\n
\nThe QI Summary file contains data relating to surveys, such as survey name,\nrelated indicators (questions) from the survey, key functions, data\ncollection information, and possible actions to be taken. These records\nare used for tracking and reporting any indicators, including chart\naudits and discharge audits.\n\n
\nThis file contains a list of the facility's standards of care/practice.\nthe QI Summary reports.\n\n
\nThis file contains all of the rationale data used in the QI Summary\nreports.\n\n
\nThis file contains frequency data used in editing the QI Summary records.\nreports.\n\n
\nThis file contains a mapping of option, routine, help frame and bulletin\nnames from the Nursing package prior to version 2.5.\nversion 2.5.\n\n
\nThis file contains patient information pertinent to the Dental Service.\nIt points to the Patient file (2).\n\n
\nThis file contains information about dental providers. It contains the\nname of the provider, a unique provider number and the status of the\nprovider (active or inactive). A new, 8 character, dental provider \nnumber has been implemented which will replace the old 4 character number \nused in Dental Record Manager.\n\n
\nThis file contains a list of Provider Types used to categorize the \ndifferent types of Dental Providers within Dental Record Manager. The \nCODE field will be zero-filled and will become the first two characters \nof the new 8 character Dental Provider Id# used in DRM reports.\n\n
\nThis file contains a list of Provider Specialties used to categorize the\ndifferent types of Dental Providers within Dental Record Manager. The\nCODE field will be zero-filled and will become the second two characters\nof the new 8 character Dental Provider Id# used in DRM reports.\n\n
\nThis file contains the screen formats used throughout the package to\nedit/display information from the Dental package files.\n\n
\nThe Treatment file contains all dental treatments for each patient entered\nby the date of treatment and the provider ID #. This is the core of the\ndental package where all dental activities are recorded. Entries are usually \nrecorded in this file on a daily basis.\n\n
\nThis file contains applications and Dental fee data and selected general\nmanagement and planning data on dental outpatients, class I-VI. A monthly\nservice report is prepared by each facility having dental outpatient\nactivities. Facilities having a Dental fee jurisdiction will complete\nall necessary information.\n\n
\nThis information is used to report the number of staff class I-VI treatment\ncases authorized, the number of staff class I-VI cases pending initiation of\ntreatment and the number of staff class I-VI treatment cases pending \ncompletion. This information is entered by the Dental Service monthly.\n\n
\nThis file contains personnel information pertinent to Dental Service\nemployees. This information is used to report the days worked during the\nreport period for all dental personnel, plus the number of patient visits to \nconsultants and attendings. This information is entered by the Dental\nService monthly.\n\n
\nThis file contains three site parameters that each facility must complete.\nThey are the station.division number of the facility, the port number that\ntheir card reader is connected to, and whether or not the site is sending\ndata to Austin over VADATS.\n\n
\nThis file contains the non-clinical time spent by each dental provider\nin each of four categories: Administrative; Research; Fee Basis and\nEducation and Training. This information is totaled for the month, then\ncombined with the data in the Dental Personnel file to produce a monthly\npersonnel report.\n\n
\nThis file contains all information associated with an accident that\nresults in injury and/or illness.\n\n
\nThis file contains a list of terms used to describe or categorize the type\nof injury sustained by the employee. Each term is associated with a code.\nFile data is exported with the package and should not be edited by medical\ncenter staff.\n\n
\nThis file contains a list of terms and codes used to describe\nthe body part affected by the injury. This file contains codes\ndefined by the DOL (Department of Labor) and MUST NOT be changed\nor deleted. Modifications to this file may cause the rejection\nof CA1/CA2 claims submitted to DOL.\n\n
\nThis file contains a list of terms used to categorize the type of injury\nsustained by the employee. Each term is associated with a code. File\ndata is exported with the package and should not be edited by the site.\n\n
\nThis file contains the weather conditions that contributed to the\nIncident.\n\n
\nThis file contains the list of valid sources causing the incident.\n\n
\nThis file contains the list of prevention methods that could be used\nto avoid another incident.\n\n
\nThis file contains items worn for protection against body fluid exposure.\nFile data is exported with the package and should not be edited by the\nsite.\n\n
\nThis file contains a list of patient care areas and other locations where\naccidents occur. Each location is associated with a code. File data is\nexported with the package and should not be edited by the site.\n\n
\nThis file contains a list of phrases describing the purpose for originally\nusing the sharps item. Each entry is associated with a code. File data is\nexported with the package and should not be edited by the site.\n\n
\nThis file contains a list of phrases describing how or when the injury\noccurred. Each entry is associated with a code. File data is exported with\nthe package and should not be edited by the site.\n\n
\nThis file contains a list of terms used in describing the device or item\nthat caused the injury. File data is exported with the package and should\nnot be edited by the site.\n\n
\nThis file contains a list of phrases describing the type event (e.g.,\nspills, contaminated sheets, person contact) that resulted in a body fluid\nexposure. File data is exported with the package and should not be edited\nby the site.\n\n
\nThis file contains valid responses for describing the safety characteristics\nof the device that was being used when the incident occurred.\n\n
\nThis file contains valid device sizes for the needle or syringe, if the object\ncausing injury were either one. Needle size would be the gauge and syringe\nsize would be cc. \n\n
\nThis file contains the brand names of devices that are used in incidents\ninvolving needlesticks and sharps.\n\n
\nThis file contains the nine valid reasons the agency can controvert a CA-1\nworkers' compensation claim.\n\n
\nThis file contains a listing of valid Additional Pay Type codes. It is used on\nthe workers' compensation section of the Claim for Compensation form (CA-7).\n\n
\nThis file contains the basic reason a CA-1 case is disputed by the agency.\nOnce a dispute code is selected the user add additional text in the \nReason for Dispute comment field to further explain the reason for \ndisputing the claim.\n\n
\nThis file contains the valid Type of Injury Codes and descriptions for\nsubmission of CA1/CA2 claims to DOL (Department of Labor). This file\nMUST NOT be altered as doing so may cause DOL to reject the submission.\n\n
\nThis file contains the valid codes and descriptions for the Source of\nInjury codes used for submitting claims to the DOL (Department of Labor).\nThis file MUST NOT be altered as doing so may cause DOL to reject the \nsubmission.\n\n
\nThis file contains the valid codes and description for the Cause of Injury\nCodes for submission of a CA1/CA2 claim to DOL (Department of Labor). This\nfile MUST NOT be altered as doing so may cause DOL to reject the submission.\n\n
\nThis file contains the valid codes and descriptions for the Nature of\nInjury Codes for submission of a CA1/CA2 claim to the DOL (Department\nof Labor). This file MUST NOT be altered as doing so may cause DOL to \nreject the submission.\n\n
\nThis file contains the valid titles that can be used for Providers for\nsubmission of CA1/CA2 claims to the DOL (Department of Labor). This file\nMUST NOT be altered as doing so may cause DOL to reject the submission.\n\n
\nThis file contains Union and Union Representative information for Unions at \nthe facility. The information will be used to sent a MailMan bulletin to\nthe appropriate Union representative if the employee authorizes sending\ninformation concerning their incident to the Union.\n\n
\nThis file will contain claim information filed by an employee for compensation\nrelating to a specific accident incident or illness previously filed in \nASISTS. A pointer to the CA-1 or CA-2 that the CA-7 claim refers to will be\nstored in this file. Multiple claims can be filed for each CA-1 or CA-2. \n\n
\nThis file contains canned comments that are entered by DRM Plus \nadministrators and users. These canned comments will be used within the \nDRM Plus application when completing a note within the new exam elements. \nA user is only allowed to have 12 total comments, a restriction set by \nthe GUI, for each category. There are two types of canned comments: \nsystem and user. A system canned comment has priority over any user \ncomments.\n\n
\nThis file contains the data request types support by My HealtheVet.\nA request is typically a query for a data domain, but can be just about \nany operation that can be requested via HL7 and requires some code to be \nexecuted within the MHV package. The file defines much of the behavior \nfor these requests.\n\n
\nThis file is used to map response protocols and message builders from the \nincoming message type and event type.\n\n
\nThis file serves as the log of emergency department visits. It works \ndisplay board. The display board is refreshed every 30 seconds. Many of\nthe indexes in this file assist in making the refresh code as efficient as\npossible.\ntogether with the ED LOG HISTORY file to track when activities of a\ntypical emergency department visit are done. It records where the patient\nwent, who was responsible, and when key things happened (such as triage\nand disposition).\n \nThis file serves as the key source of information for data that is\ndisplayed on the emergency department display board (an electronic "white\nboard"). Patient visits that are currently active are shown on the\n\n
\nThis file contains a history of changes to key fields in the ED LOG \n \nThe fields in this file correspond to the identically named fields in the \nED LOG file (230). For more detail in the field description, please \nrefer to the matching field in the ED LOG file.\nfile. When a record is first created in the ED LOG file, and each time \nthat record is updated, a record is also created in this file that\ncontains the values of the fields that actually changed. This gives a\nthorough history of what was changed when and by whom. A major purpose to\nthe Emergency Department Tracking System is to measure how long it takes\nto do things. By keeping this history file, with all the time stamps, it\nis possible to generate a variety of reports. These include information\nsuch as wait times, lengths of visit, number of delayed visits, etc.\n\n
\nThis file contains the settings for the local tracking boards.\n\n
\nThis file contains staff assigned to a particular area (e.g., the \nemergency department). It allows for concise selection lists when \nupdating the tracking log. It also allows for particular colors to be \nassociated with staff. When that person is shown on the display board, \nthe colors may be used to more easily tell who is assigned to which \npatient.\n\n
\nAs the patient moves thru a visit, such as a visit to the emergency \ndepartment, there are a number of areas the patient may stop at. This \nfile allows the department to set up places a patient may be, physical or \nconceptual, so that the patient may be tracked throughout their visit. \nThese places may include specific beds, waiting areas, other areas of the \nhospital such as radiology, exam rooms, etc.\n\n
\nThis file contains the parameters that control the behavior of the \ntracking software. It also contains XML descriptions that are used by \nthe client display board software to control column appearance, row \ncontent, and cell color.\n\n
\nThis file holds adhoc report templates.\n\n
\nThis file holds the report elements for use in the report templates.\n\n
\nThis file contains the user role settings.\n\n
\nThis file contains the specifications for worksheets. Worksheets are \ncomprised of sections. Each of the sections may contain many 'worksheet \ncomponents'.\n\n
\nThis file contains the settings for worksheet sections. Each section can \ncontain multiple components from the EDP WORKSHEET COMPONENT file.\n\n
\nThis file contains the specifications for worksheet components.\n\n
\nThis file contains entries that are used in selection lists within the \ntracking software. The entries for these selection lists may eventually \nbe rolled up for reporting to the Emergency Department director.\n\n
\nThis file contains collections of codes that represent a specific \nselection list (acuities, patient statuses, dispositions, delay reasons, \netc.) used within the patient tracking software.\n\n
\nThis file stores the NHAMCS reason's for visits.\n\n
\nThis file contains display names for the NHAMCS Reason for Visit codes.\n\n
\nThis file contains the list of ED complaints.\n\n
\nThis file holds clinically relevant events in a patient's treatment. Many\nwill be mapped to a lab result or vital measurement, and will trigger a\nchange in treatment which can be documented here.\n\n
\nThis file collects statistical data for the ISI Rad Dynamic Query\nfeature, for each time a query is run.\n\n
\nThis file holds a list of radiology exams selected by the ISI Rad user for ready recall.\n\n
\nThis file stores notes related to an exam that are entered by the ISI Rad user.\n\n
\nAn indication that changes occurred in a Record of Pros Appliance/Repair\n(file 660) transaction is stored in this file. When a Record of Pros\nAppliance/Repair transaction is edited or deleted, an entry is created.\nThe display of duplicate transactions for a patient will incorporate\nupdate/delete activity for a specified Record of Pros Appliance/Repair\ntransaction in order to provide the most current information when\nidentifying duplicate appliance transactions. Entries are purged manually\nby the site.\n\n
\nThe APAT PROSTHETICS PCO COMMENTS file contains comments regarding\na Prosthetics (simplified) purchase card order throughout the\npurchasing/reconciliation process.\n\n
\nThe DSSO APPL TRANS EXT ACTIVITY file contains FileMan errors, System \nerrors, and progress messages that occurred during the processing of\noption DSSO APPL TRANS EXT - ALL. Entries are added to the file by this\noption; however, the STATUS field is edited in the DSSAPAT GUI when an\nerror is resolved. After a FileMan error is resolved, the associated\nRECORD OF PROS APPLIANCE/REPAIR (#660) is reprocessed by option DSSO APPL\nTRANS EXT - ALL. \n\n
\nThis file contains the Health Benefit Plan names and their short and long \ndescriptions.\n\n
\nThis file contains Category II (Local) Patient Record Flags that can be \nassigned to a patient. Use the Record Flag Management [DGPF RECORD FLAG\nMANAGEMENT] option to create/edit entries in this file.\n \nRecords in this file should not be added, edited, or deleted except \nthrough the use of the Patient Record Flag software that is part of \nRegistration. Doing so would likely cause the Patient Record Flag \ndatabase to become corrupted.\n\n
\nThis file contains the audit information associated with a record in the \ndatabase to become corrupted.\nPRF LOCAL FLAG (#26.11) file. Entries in this file are created \nautomatically by the Record Flag Management [DGPF RECORD FLAG MANAGEMENT]\noption for each creation/edit of a PRF LOCAL FLAG (#26.11) \nfile entry.\n \nRecords in this file should not be added, edited, or deleted except \nthrough the use of the Patient Record Flag software that is part of \nRegistration. Doing so would likely cause the Patient Record Flag \n\n
\nThis file contains a list of Patient Record Flag assignments. Use the \nRecord Flag Assignment [DGPF RECORD FLAG ASSIGNMENT] option to \ncreate/edit entries in this file.\n \nRecords in this file should not be added or edited except through the use\nof the Patient Record Flag software that is part of Registration. Doing\nso would likely cause Patient Record Flag database corruption.\n\n
\nThis file contains the audit information associated with a record in the \ndatabase to become corrupted.\nPRF ASSIGNMENT (#26.13) file. Entries in this file are created \nautomatically by the Record Flag Assignment [DGPF RECORD FLAG ASSIGNMENT]\noption for each creation/edit of a PRF ASSIGNMENT (#26.13) \nfile entry.\n \nRecords in this file should not be added, edited, or deleted except \nthrough the use of the Patient Record Flag software that is part of \nRegistration. Doing so would likely cause the Patient Record Flag \n\n
\nThis file contains a list of the Category I (National) Patient Record\nFlags that can be assigned to a patient.\n \nCategory I flags are established at a National level and any changes to\nthis file or it's entries should only be done through a national patch\nrelease.\n\n
\nThis file contains a list of usage classifications that can be applied to\na Patient Record Flag.\n \nAdditions or modifications to entries in this file should only be done\nthrough a national patch release. Records in this file should not be\nadded, edited or deleted locally. Doing so would likely cause the Patient\nRecord Flag database to become corrupted.\n\n
\nThis file contains a list of all Unsolicited Observation Update (ORU~R01)\nHL7 transmissions that have been generated at the site by the Patient \nRecord Flags software module. Entries in this file are created/edited \nautomatically by the Patient Record Flags HL7 interface. \n \nRecords in this file should not be added or edited except through the use\nof the Patient Record Flag software that is part of Registration. Doing so\nwould likely cause Patient Record Flag database to become corrupted.\n\n
\nThis file contains the configuration parameters for the Patient Record \nFlag module of the Registration package. The file should contain only \none record numbered "1". Modifications to the file should only be done \nthrough the Patient Record Flag Configuration [DGPF RECORD FLAG \nCONFIGURATION] option.\n\n
\nThis file contains a list of all Query (QRY~R02) HL7 transmissions that\nhave been generated at the site by the Patient Record Flags software\nmodule. Entries in this file are created/edited automatically by the\nPatient Record Flags HL7 interface.\n \nRecords in this file should not be added or edited except through the use\nof the Patient Record Flag software that is part of Registration. Doing so\nwould likely cause Patient Record Flag database corruption.\n\n
\nThis file tracks patients that need to have one or more of their treating\nfacilities checked for existing Patient Record Flag assignments.\n\n
\nThis file contains log of PRF flag transfer requests.\n\n
\nThis file contains patient enrollment records. Enrollment records should\nnot be added, edited, or deleted except through the use of the enrollment\nsoftware that is part of Registration. Doing so would likely cause the\nenrollment database to become corrupted.\n\n
\nThis file is used to log queries for enrollment/eligibility that have been sent\nto HEC.\n\n
\nThis file is used to audit the changes made (other than to enrollment) by \nthe upload of the Enrollment/Eligibilty transmission from HEC.\n\n
\nThis file will contain the statuses associated with an enrollment application.\n\n
\nThis file contains the Enrollment Group Threshold (EGT) for patient enrollment. Enrollment Group Threshold records should not be added, edited, or deleted except through the use of the enrollment software module which is part of Registration. \n\n
\nTHIS FILE SHOULD NOT BE MODIFIED BY USERS!\nPer the Enrollment Phase II SRS (section 6.8.1.2), this file has been\nadded to store the acceptable reasons why a veteran may be classified\nas catastrophically disabled.\n\n
\nThis file contains reasons for the awarding of and changes to pension benefits. The VBA manages benefits awards and changes to benefits. Receiving VA Pension is a monetary benefit granted to a \nVeteran. Recently, additional information has been shared with the HEC so that periods of award could be more accurately \nshown for billing purposes. Simply having a Pension Indicator = yes or no is not enough for that purpose. \n \nThis file comes pre-populated and the sites are not allowed to edit it. Any changes to file will come in a patch.\n\n
\nThis file contains patient Nose and Throat Radium Treatment records.\nRecords in this file should not be added, edited, or deleted except\nthrough the use of the Nose and Throat Raduium software that is part of\nRegistration. Doing so would likely cause the Nose and Throat Radium\ndatabase to become corrupted.\n\n
\nThis file tracks the Military Sexual Trauma status for veterans as part\nof the data collection requirement for VHA Directive 98-058, \n"Sexual Trauma Counseling Care and Services". Data in this file SHOULD\nNOT BE MODIFIED directly. This is a history file which tracks the \nhistorical MST status for a veteran. All entries should be done through\nthe associated List Manager application.\n\n
\nOnce the maximum sign-on attempts limit has been exceeded, an entry will\nbe made in this file to record all available information about the failed\nsign-on attempt. Information includes the date/time, CPU, UCI, device,\nand, if known, user. The text entered for each attempt is recorded when\nit does not match existing codes such that security is not violated.\nThis file is not cross-referenced.\n\n
\nEntrance into programmer mode via the menu system is automatically logged\nin this file. It points to the New Person File to identify the user. It\nis not cross-referenced.\n\n
\n \nThis file is used to maintain a log of the errors occurring during use of\nthe system. Errors are entered into this log by the error trap\nestablished for the user (by ZU or application programs) calling %ZTER\nwhen an error occurs. The entries are all entered by the routine %ZTER.\nThere is no need for a user to make a manual entry into this file.\n\n
\n \nThis file contains a number of the abbreviations used to indicate the type\nof error encountered. The most important ones are those which are\nindicated as fatal errors warranting termination of the job after logging\nof the error.\n\n
\nThis is a tool for capturing the VistA errors at each site. These\nfindings can be used locally and pushed to a central repository to\nhelp to prioritize the efforts to seal up the hot spots in the \napplications.\n\n
\nThis file records sign-on/sign-off times by user, device, job, UCI,\nand CPU. It is cross-referenced by user, device, and sign-off time.\n\n
\nThis file holds the IP address or domain name of a system that has failed \nto successfully signon with in the limits imposed.\n \nOnce the lock out time has passed the record is removed, so it would be \nnormal for this file to have no records most of the time.\n\n
\nThis file holds the count of signon attempts from a IP address or domain.\nThis is to prevent a user from disconnecting after each try.\n \nOnce a signon is successful the record is removed, so it would be normal\nfor this file to have no records most of the time.\n\n
\nThis file is pointed to by the Subtype field of the Device File. This\nThe Kernel Virgin Install distribution will seed a more complete\nset of terminal types including those for printers as well as CRTs.\nHowever, the Kernel Virgin Install should only be performed once\nand only on a system where there is no pre-existing Kernel.\nThe data in this file is cross-referenced by name and synonym.\nfile may hold vendor-specific code to characterize a terminal type. For\nexample, escape sequences may be entered in the Open and Close Execute\nfields to set pitch or font. This file is also pointed to by the New\nPerson File to record sign-on subtype characteristics by user.\nData is distributed with this file to support screens handling capabilities.\nThis data will overwrite existing data for those terminal types of the\nsame name. However, terminal types for printers will not be affected\nsince the data that is distributed is for a subset of known CRTs.\n\n
\nThis file holds the translation between the ANSI DA return code and\nthe name in the terminal type file that should be used.\n\n
\nThis file defines all input/output devices that can be accessed from\nmnemonic, subtype, and form currently mounted.\nthis CPU (definitions are not account-specific). Each device is\nidentified with a unique name. Each is associated with a $I value\nwhich may correspond with a hardware port or, on layered systems,\na host file or directory. If there are several devices for the same\nvolume set and $I, one may be given sign-on system status. Devices\nmay also be assigned to hunt groups to share work. This file is\ncross-referenced by name, $I, volume set(CPU), and sign-on/system\ndevice. It is also cross-referenced by hunt group, local synonym,\n\n
\nThis file holds the name of spool documents created by the Kernel\nspooler (%ZIS4) for all operating systems. It does not hold the text\nof the documents themselves. That text is first spooled to spool\nspace, then moved into the ^XMB global as a mail message. This file\ndoes, however, provide the mechanism for securing spool space for and\nduring spooling. It is cross-referenced by name, spool number, user,\nand mail message.\n\n
\nThis is the holding file for spool documents until moved to a mail message\nor deleted.\n\n
\nThis file is used to record print jobs passed to a print server. Under\nold files can be purged regularly, or to aid in troubleshooting of problems\ninvolving print queues. \n\nLinux a CUPS is used to provide print services and to manage print queues.\n\nPrint jobs are passed to the print server via a host file. Each time a host\nfile is created a new entry will be created in this file. The file will be\npurged of old entries on a regular basis.\n\nThe principle use of this file is to insure that the name of the host file is\nunique. A secondary use is to track the host files, for example, so that\n\n
\nThis file is for internal use by TaskMan and the Device Handler in\nthe sequential processing of tasks. Jobs that have been sent to a\nresource-type device will be monitored according to fields in this\nfile. To accomodate the Device Handler's need to write to but rarely\nread from this file, the translated ^%ZISL global is used. This file\nis cross-referenced by name and job number.\n\n
\nBulletins are 'Super' messages. Each Bulletin has a text and a subject\non programmer entry points. FileMan sets up code that will issue\na bulletin automatically when the special cross reference type is\ncreated. In either case the parameters that go into the text and/or\nthe subject make each bulletin unique.\njust like a normal message. But embedded within either the subject or\nthe text can be variable fields that can be filled in with parameters.\nThere is also a standard set of recipients in the form of a Mail Group\nthat is associated with the bulletin.\n \nBulletins are processed by MailMan either because of a special cross\nreference type of FileMan or because of a direct call in a routine.\nThe interface for the direct call is described in the documentation\n\n
\nThis file holds pointers to the message file, according to users.\nEach mailbox entry corresponds to a user. POSTMASTER is a special\nuser who controls the network communications queues. Each user\nis automatically given two baskets: IN and WASTE. All incoming messages\ngo into the users IN basket. When the user deletes them, they are\ntemporarily stored in the WASTE basket. Users may create new baskets\nas they wish.\n\n
\nThis file holds entries that are processed by a special MailMan job that\nmakes messages new for people at scheduled dates and times.\n\n
\nThis file holds the names of all groups known to MailMan, and their\nmembers.\n\n
\nThe Distribution List file has entries that consist of names. Each name is\n G.SUPPORT@DOMAIN.EXT\n G.SUPPORT@ALTOONA.DOMAIN.EXT\n & G.SUPPORT@ISC-SF.DOMAIN.EXT\nassociated with one or more domain. When a Distribution List is entered\ninto a Mail Group, MailMan will deliver the message to all the entities\nit has linked to it. A Distribution List is interpreted as a name at which\nthe message will be delivered to at each of the associated domains in the\nlist. Therefore a Distribution List whose NAME is G.SUPPORT and whose\nassociated domains are DOMAIN.EXT, ALTOONA,DOMAIN,EXT and ISC-SF.DOMAIN.EXT will\nbe sent (in addition to all other entities attached to the Mail Group) to:\n \n\n
\nThese messages are the heart of the MailMan system.\n\n
\n \nThis file contains a list of patients (by income year) who are undergoing\n(or have undergone) income verification with the IVM Center.\n \nData in this file is maintained by the IVM software module. It should not\nbe modified in any way at the site level.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\n \nThis file contains a log of all IVM transmissions that have occurred at\nthe medical center. The data in this file is maintained by the IVM\nsoftware module and should not be altered.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to track DHCP billing activity which has been\ntransmitted to the IVM Center. The data in this file is maintained\nby the IVM software module and should not be altered.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a log of all financial queries that have been sent to HEC\nfrom the medical center. The data in this file is maintained by the IVM\nsoftware module and should not be altered.\n\n
\nThis file is used to record the processing statistics for the\ninitial enrollment extract.\n\n
\nThe IVM ADDRESS CHANGE LOG file contains the patient's prior address\nstored along with the Date/Time the address was changed, the Source of the\nchange, and User ID of the person who made the change. In the case of an\nupdate via an ORU~Z05, the User ID will be POSTMASTER.\ninformation when the address has been updated.\n \nA record will be created when the address is updated from either the\nupload of an ORU~Z05 Demographic (Address) HL7 Transmission or from manual\ndata entry using any of the following options: DG ADDRESS UPDATE,\nDG REGISTER PATIENT, DGPRE PRE-REGISTER OPTION, and DG LOAD PATIENT DATA.\n \nThe previous address information found in the PATIENT File #2 will be\n\n
\nThis site parameter file contains a QUERY INCOME YEAR multiple which\nsubmitted. The query information is stored so that the request\nmay be processed outside of peak hours when the nightly background\njob is run.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\ncontains information for Queries received from the IVM center.\nThe IVM PARAMETER file will be used in IVM v2 to hold several parameters\nwhich shall be used to control the uploading of verified demographic\nand Means Test data from the IVM Center. This file is being introduced\nwith patch IVM*1*2, with the single parameter entry only containing\nthe Station number. The parameter file is needed for this patch\nto capture the query information sent to the site by the IVM Center\nwhen a request for a full data transmission for all patients is\n\n
\n \nThis file contains reasons why the facility did not upload insurance data\nsent from the IVM Center.\n \nNew entries should not be added to this file. The addition of new\nentries must be coordinated with the IVM Center.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\n \nThis file contains information pertaining to the demographic fields sent\nin HL7 segments from the IVM Center to the VAMCs.\n \nThis table contains parameters which are used during the receipt\nand upload of demographics data from the IVM Center. This file\nshould not be altered in any way.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to store a list of reasons for closing out case\nrecords in the IVM PATIENT (#301.5) file. This file should not be altered\nin any way.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a list of reasons for closing a record in the\nIVM FINANCIAL QUERY LOG file. This file should not be altered\nin any way.\n\n
\nThis file contains data required for tracking the status of the \neligibility for emergency Mental Health care for patients with Other Than \nHonorable Discharge type.\n\n
\nThis file contains the history of changes made to the PRESUMPTIVE \nPSYCHOSIS CATEGORY field (#.5601) in the PATIENT file (#2).\n\n
\nThis file stores requests and responses made before and after the\nDGREGEEWS routine calls for COMPACT Act Administrative Eligibility Status\nto monitor this activity for troubleshooting purposes. DGREGEEWS calls\nwebservice DG EE SUMMARY SERVICE through the webservice client XOBWLIB.\nThe file stores calling routine, request datetime, response datetime and\ncode by Integration Control Number (ICN). This file will be used primarily\nby the Office of Health Informatics in conjunction with the COMPACT ACT\nEPISODE OF CARE file (#818) support and maintenance.\n\n
\nThis file should **NOT** be edited directly by FileMan. By editing this\nfile directly data corruption can occur.\n \nThis file holds information pertaining to debtor accounts. A debtor\ncan be an insurance company, patient, person, institution, or vendor.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the data needed to create and administer Repayment \nPlans for Debtors.\n\n
\nThis file contains all predefined audit log comments for repayment plan \naudit log in file 340.5.\n\n
\nThis file will store metrics data for all options within the Accounts \nReceivable package. The metrics data could be option specific (such as # \nof Repayment Plans Administratively Closed) or technical (how long \ndid it take the Repayment Plan Nightly Process to run) in nature.\n\n
\nThis file contains events that occurred to a debtor's account. This\nfile should NEVER be edited directly. Eventually all types of events\nwill be stored in this file as the Accounts Receivable package moves\nto a transaction-based system.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is a table that allows the AR package to manage events throughout\nthe AR package. This file MUST NEVER be edited by sites or any users.\nBy editing this file, data corruption can occur and functionality in the\nAR package may be compromised.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds parameters that allows the site to customize certain\nfunctionality of the AR package.\n\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file allows sites to define a 'group', such as: Billing Agencies,\nAgent Cashier, Return Payment, etc. These groups represent a person,\ninstitution, or entity. Within each group, information can be defined\nthat is used in the AR package. The main purpose for this file is\nfor tracking address information.\n\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThe type of group defines what 'category' a group belongs to and the\nparameters that are associated with the specific type of group.\nA type of group, for example, is 'Billing Agency' or 'District Counsel'.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file stores the most recently selected parameters and the printer to \nbe called by a user when customizing the screen and the printer options.\n\n
\nThis file holds all the follow-up letters that the AR package supports.\nThese letters can either be manually generated by the user or automatically\ngenerated by the AR package.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds batch payments information. Payments no longer are posted\nPer VHA Directive 10-93-142, this file definition should not be modified.\ndirectly to patient bills, but rather, entered into this file. Once\nthe entries in this file are reconciled with cash on-hand and verified\nto be correct, they are then 'posted' to the patient bills.\n \nNOTICE: This file SHOULD NOT be edited directly via FileMan.\nInformation in this file should only be modified via the AR\npackage options.\n \n\n
\nThis file stores information associated with SF-215 or Deposit Tickets.\nMultiple Receipts can be open by different cashiers, but they are all\ntied to a deposit ticket that tracks the date the money \nis deposited to bank, who deposited the money, total deposit, etc.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to store payments received for automatic processing.\n\n
\nThis file is used to store EFT payment data received to allow the site to\nrecord the amount of the daily EDI Lockbox deposit to treasury that belongs\nto their site.\n\n
\nThis file is used to store each individual payment from a single payer\nmade to the site using Electronic Funds Transfer and the EDI 3rd Party\nLockbox system in VistA.\n\n
\nThis file holds the ERA (Electronic Remittance Advice) information that\nis received electronically. It holds the summary for each individual EOB\n(Explanation of Benefits) that comprise the ERA. Individual EOB detail\ndata is found in file 361.1 in Integrated Billing.\n\n
\nThis file contains the data that will be used to auto-create a receipt\nfrom data received via the EDI Lockbox system for ERAs.\n\n
\nThis file receives the raw data from electronic ERAs and EOBs. Once filed\nhere, the records are verified and sent to the permanent file where the\nsummaries are kept (#344.4) and the detail is stored in Integrated\nBilling's file #361.1. Once permanently filed, the raw data is deleted\nfrom this file.\n\n
\nThis file is populated based on the data in the ELECTRONIC REMITTANCE \nADVICE file (#344.4). Initially, a post-installation process created a\nrecord for each unique PAYER NAME/PAYER ID combination. Afterwards, this\nfile is populated by the EDI Lockbox (ePayments) nightly batch job. \nWhenever the nightly batch job encounters a new PAYER NAME/PAYER ID\ncombination, a new record will be added to this file. The file will be\nmaintained via the EDI Lockbox Parameters [RCDPE EDI LOCKBOX PARAMETERS]\noption. \n\n
\nThis file holds the parameters specific to the EDI Lockbox processes \n(ePayments).\n\n
\nThis file will store all of the CARCs or RARCs that can be used during \nauto-decrease of a patient's bill.\n\n
\nThis file is for auditing changes to the RCDPE PARAMETER file (#344.61).\n\n
\nThis file will store all of the audit entries when an ERA line item is \nplaced in suspense. Once in suspense, the suspensed item will update the \naudit log whenever the suspended item is refunded or paid.\n\n
\n \nThis file will store the processing history of an ERA if the ERA can be \nauto-posted. Once the PRCA NIGHTLY PROCESS determines that an ERA can be \nauto-posted, an entry will be filed for every Auto-Post Status change \n(file 344, field 4.02).\n\n
\nThis file holds the history of receipt line comments.\n\n
\nThis file stores the parameters necessary for generating and \nif necessary, transmitting the AR Diagnostic Measures reports.\n\n
\nThis file will store a copy of the AR Diagnostic Measures Reports \ngenerated as part of the Nightly Process.\n\n
\nFile implemented for patch PRCA*4.5*303\n \nThis file stores the codes and descriptions of the Claim Adjustment \nRemittance Codes (CARC) file published by the Washington Publishing \nCompany. The CARC data is updated by the FSC, which has a subscription \nfrom WPC to obtain updated codes and descriptions.\n\n
\nThis file was implemented in patch PRCA*4.5*303\n \nThis files stores the codes and descriptions of the Provider Level \nBalance Codes (PLB Codes). The PLB Codes are published by CMS and \noriginate from their Healthcare Integrated General Ledger Accounting \nSystem (HIGLAS).\n\n
\nThis file was implemented in patch PRCA*4.5*303\n \nThis file stores the codes and descriptions of the Remittance Advice \nRemark Codes (RARC) file published by the Washington Publishing Company.\nThe RARC data is updated by the FSC that has a subscription to WPC for\nthese codes.\n\n
\nInformation transmitted from the DHCP Accounts Receivable system\nto the FMS system are sent via records called 'documents'. Once\nthese documents are transmitted, pertinent information is stored\nin this field, such as: Status of the document, Bill Number, Fund, etc.\nIt is necessary to store this information in the event a document\nneeds to be recreated or traced in the event of a system problem.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nInformation that is transmitted to the FMS System are sent via\nrecords called 'documents'. Each FMS document has a field called\n'type' that describe the information or transaction being transmitted.\nWhen the Accounts Receivable system transmits documents, certain parameters\nare stored in this field that help define the layout of the\ndocument.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the revenue source codes required for detail FMS\ndocuments. The revenue source code is used for the Reimbursable earnings\nreport generated by FMS.\n\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the Transaction codes sent to FMS and the trans code\nfor related document. IE. BD 01 is sent to FMS, any other document that\nreferences the BD 01 must contain a related tran code.\n\nBD 01 requires CR 05 and WR 01.\n\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds the data points for the Accounts Receivable Data\ncollectors that transmit data to the National Data Base in San\nFrancisco.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to store figures used in the bad debt allowance\ncalculation.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to store the Refund and Refund Reversal codes to be\nplaced on the corresponding TOP documents. The codes are stored by\ncalendar year. This file is updated through a menu option, whenever\nTreasury advises the VA of the codes for the next year.\n\n
\nThis file contains bill entries which based upon certain criteria\nhave been triggered into this file. These bill entries are used\nto export data information for CBO to the Boston Allocation\nResource Center (ARC).\n\n
\nThis file holds the Cross-Servicing error codes for the\nIntegrated Agency Interface (IAI) file transmission of\ndebt/debtor records into FedDebt.\n \nPer VA Directive 6402, this file should not be modified.\n\n
\nThis file holds the Cross-Servicing action codes for the\nIntegrated Agency Interface (IAI) file transmission of\ndebt/debtor records into FedDebt.\n \nPer VA Directive 6402, this file should not be modified.\n\n
\nThis file holds the Cross-Servicing record types for the\nIntegrated Agency Interface (IAI) file transmission of\ndebt/debtor records into FedDebt.\n \nPer VA Directive 6402, this file should not be modified.\n\n
\nThis file is used to store transmission records that are sent\nby the Accounts Receivable software.\n\n
\nThis file stores the transmission types used in file 349\nAR TRANSMISSION RECORDS.\n\n
\nThis file stores the patient statement information that is\nsent from AR to CCPC.\n\n
\nThis file keeps a record of the electronic AR Transmissions sent \nvia the Regional Counsel Interface. Entries in this file will be \npurged routinely. This file may grow to be very large. \n\n
\nThis file contains the transaction codes sent from the Regional\nCounsel Office for Third Party bills that are referred. Transmissions\ncontaining these codes will be applied to the bill as the AR\naction that is associated with the code. These associations were\npredetermined by the General Counsel Office and VACO MCCR. Modification\nof these codes is prohibited. \n\n
\nThis file is the list the of errors that may be returned from CCPC as\nreasons for a patient statement not printing.\n\n
\nThis file has all the error code types for CCPC.\n\n
\nThis file holds the information for AR transmission routers based on\ntype.\n\n
\nThis file contains the local Sharing Agreement sub-categories.\n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with\n \nEntries in this file will not be deleted or edited (except for the\nstatus field, cancellation reasons filed, last updated field, and\nuser last updating field). Rather than deleting an entry, an entry\nis "reversed" by creating an additional entry with the IB ACTION TYPE\nentry that cancels the original entry. An entry is edited by creating\nthe cancellation entry and then adding an updated new entry. All entries\nrelated to the original entry will be related by the PARENT LINK field.\n \nThere is also an IB ACTION type that is an event, which may include\nVA File Manager.\nHospital admissions, NHCU admissions, and outpatient visits. All of\nthe charges associated with an event will be related to that event by\nthe EVENT LINK field.\n \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n \nEntries in this file are created by other applications calling approved\napplication specific routines. This file is the link between Accounts\nReceivable and an application. Integrated billing will attempt to\naggregate charges where possible to reduce the number of account \nentries necessary. Resolution of charges from Accounts Receivable would\nthen be accomplished through Integrated Billing.\n\n
\nThis file contains the types of actions that a service can use with IB.\nData in this file provides links from the application to IB to AR that\nare associated with the type rather than each entry.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the unit charges for an IB ACTION TYPE by the\neffective date of the charge. The "AIVDT" cross-reference can be\nused to quickly ascertain the most recent charge for an action type.\n \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis new file for Integrated Billing version 2.0 has been implemented\na pointer field (pointing to this file). Thus, the internal entry\nnumbers for the statuses in this file MUST MATCH the codes established\nfor the statuses in the old set-of-codes definition. The entries in this\nfile will be precisely set in the IB version 2.0 post initialization.\n \nENTRIES IN THIS FILE SHOULD NOT BE EDITED OR DELETED. IF YOU LOSE\nENTRIES IN THIS FILE DUE TO SYSTEM FAILURE, THEY MUST BE RE-SET USING\nTHE CORRECT INTERNAL ENTRY NUMBERS. If you have any questions about\nre-setting entries in this file, please contact your supporting ISC.\n \nto replace the set of codes for the STATUS (#.05) field of the\nPer VHA Directive 10-93-142, this file definition should not be modified.\nINTEGRATED BILLING ACTION (#350) file. The file holds new statuses\nwhich are introduced in v2.0, display and abbreviated names for the\nstatus, and classification-type fields for each status which is\nused for processing in the Integrated Billing module.\n \nTo convert to the use of this new file, it was necessary to change\nthe field type of the STATUS field from a "set-of-codes" field to\n\n
\nThis file contains the reasons that an IB ACTION entry was cancelled.\n \nThis file comes pre-loaded with data and should not be edited or added\nto by sites.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains the HCFA rate groups for ambulatory surgeries that may\nPer VHA Directive 10-93-142, this file definition should not be modified.\n \n \nAs of 10/1/96 this functionality has not been authorized. The data in this\nfile is deleted by patch IB*2*52 and the file definition will be deleted\nin a future release.\nbe billed. This file is time sensitive, a procedure may have multiple entries\nindicating updates effective on different dates. These updates include a\nprocedure changing rate groups or changing status.\n \nThe data in this file is either transfered from 350.41 or \nentered interactively and is used to calculate the charge for a procedure\non any given date.\n \n\n
\nContains updates to the ambulatory surgery procedures that can be billed.\n \nAs of 10/1/96 this functionality has not been authorized. The data in this\nfile is deleted by patch IB*2*52 and the file definition will be deleted\nin a future release.\nThe data comes from HCFA in a WP file that is uploaded and entered into\nthis file, generally once a year.\nThe new billing procedures or billing group updates are activated only after\nthe data in this file is transferred to 350.4. This file should be empty\nexcept during the loading and transferring of the HCFA updates.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n \n\n
\nThis file is used in the calculation of the charge for an ambulatory\nsurgery performed on any given date. This file contains time sensitive data\nwith each entry defining a locality modifier and wage percentage for a\ndivision. There may be multiple entries for each division indicating changes\neffective on a particular date.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file will be used to track the archiving and purging operations\nwill be permitted, and subsequently purging will be allowed when the\narchive end date is logged. The log entry is thus used to assure that\nall the necessary steps for archiving and purging are performed in\ntheir entirety in the correct order.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nof the following three data files used in billing:\n \n #350 INTEGRATED BILLING ACTION\n #351 CATEGORY C BILLING CLOCK\n #399 BILL/CLAIMS\n \nA log entry will be filed when an archival "search" is initiated for\none of these files. Once the search end date is logged, archiving\n\n
\nThis file contains the details of the line format\nfor the Ambulatory Surgries Check-off Sheets.\nEach sheet in this file can be associated with multiple clinics.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nContains the Sub-headers and Procedures associated with each ambulatory\nsurgery check-off sheet. Defines the relationship between check-off sheets,\nSub-headers, and Procedures. Also defines the print order of each entry on \nthe check-off sheet.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains errors for billing functions. It may be used by\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\napplications, IB or AR. The normal format for a routine to return\nan error is to return the variable:\n Y=1^... a successful event occured\n Y=-1^error code[;error code;error code...]^additional text\nThe error messages can be displayed by calling routine ^IBAERR. If\nthe error occurs in a tasked job ($D(ZTQUEUED)'=0) the routine will\nput the error message in a bulletin and post it to the group defined\nin the IB SITE PARAMETER FILE.\n\n
\nThis file contains the data necessary to run the IB package, and to\nThis file should always be edited by use of the provided options.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nmanage the IB background filer. The menu IB SITE MANAGER MENU provides\noptions that allow display and editing of\ndata in this file, in addition to options to manage the\nIB background filer, for the site manager. \n \nThe Billing Site Parameters are also found in this file. \nThe option to edit these parameters is on the Billing Supervisor menu.\n \n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file\nconversion that took place when v1.5 was installed. Entries are\nsubsequently updated and created by Integrated Billing.\n \nEntries in this file should not be deleted. Billing clocks which\nare not correct will be cancelled, and new clocks may be added.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nwith VA File Manager.\n \nThis file was introduced with v1.5 of Integrated Billing in\nconjunction with the automation of bills for Means Test\ncharges. The file is used to create and maintain billing clocks in\nwhich Means Test patients may be charged co-payment and per diem\ncharges for Hospital or Nursing Home Care, as well as outpatient\nvisits. This file was initially populated by the Means Test data\n\n
\nThis file was created as part of v1.5 of Integrated Billing, in\nconjunction with the automation of Means Test/Category C billing.\nThis file contains a list of all continuous Hospital or Nursing\nHome Care patients since 7/1/86 who may be subject to Category C\nbilling. These patients are exempt from the co-payment charges,\nbut not the per diem charges. Patients who change their level of care must\nbe manually unflagged.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to track inpatient episodes for Category C veterans\n \nA case record will automatically be filed at admission for this special\ngroup of patients, and updated when the patient is discharged. The\nsite then has 45 days to disposition the case, i.e. determine if the\ncare was related to the claimed exposure. If the care was unrelated,\nand copayment and per diem charges are created in the Cancel/Edit/Add\nPatient Charges option, the case record will be automatically\ndispositioned. If the patient is not going to be billed, the reason\nfor not billing must be entered into this file.\n \nwho have claimed exposure to Agent Orange, Ionizing Radiation, and\nPer VHA Directive 10-93-142, this file definition should not be modified.\nEnvironmental Contaminants.\n \nThese episodes, which are normally billed automatically by the system,\nrequire individual review to determine if the care provided was related\nto the claimed exposure. If the care was determined to be related to\nexposure, the patient should not be billed, but the case disposition \nmust be documented.\n\n
\nThe MEANS TEST BILLING CLOCK VERIFY file contains the individual \nquery responses from an enterprise MEANS TEST BILLING CLOCK (#351) query.\nThis file is for historical and reconciliation purposes.\n\n
\nThis file is used to store data related to each Pharmacy billing\ntransaction with the Tricare fiscal intermediary. Each transaction\nis submitted to the the RNA/Triad Pharmacy ClaimGuard System, which\nis a commercial point of sale pharmacy billing software package,\nwhere it is forwarded to the intermediary through an electronic\nswitch company. All of the information which is returned from the\nintermediary is stored in this file.\n\n
\nThis table file is used to store the various errors which may\noccur when TRICARE prescriptions are billed using the commercial\npoint-of-sale pharmacy billing software package.\n\n
\nThis file is used to store all of the reasons that were used by the\nTricare fiscal intermediary to reject a pharmacy billing transaction.\nEntries in this file are automatically deleted if a prescription is\nre-submitted an subsequently accepted. The option Delete Reject\nEntry [IB TRICARE DEL REJECT] may be used to delete entries from this\nfile.\n\n
\nPer VHA Directive 10-93-142, this file definition should not be modified.\n \nThis file is used to store Transfer Pricing patient specific information.\n\n
\nPer VHA Directive 10-93-142, this file definition should not be modified.\n \nThis file holds all transfer pricing transactions\n\n
\nThis file comes populated with national entries. These entries should\nnever be deleted or edited. It is not recommended that facilities add\nentries to this file. The entries are used to extract and format data for\nall the transfer pricing reports.\n \nDO NOT delete entries in this file. DO NOT edit data in this file with VA\nFile Manager.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file stores the prosthetic devices that should be automatically\nbilled for inpatient devices issued. Unless a device is in this file, it\nwill only be billed for outpatient services (automatically).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the necessary DM reports which will have their summary\ndata collected via the Diagnostic Measures Extraction process.\n \nPer VHA directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains various report data elements/line items. One or more of\nthese file entries is related to a corresponding entry in the IB DM EXTRACT\nREPORTS file (#351.7).\n \nPer VHA directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains data collected via the Diagnostic Measures Extraction\nprocess. Within each entry is a series of DM reports from which summary\ndata has been collected on a monthly basis.\n \nPer VHA directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains Input parameters used to produce AR Workload To-Do\nLists. It also contains the flag that determines if a clerk is to ONLY be\nincluded on productivity reports. The Workload To-Do lists are mailman\nmessages sent to the supervisors and clerks. The Productivity reports are\nsent to a printer.\n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with VA\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nFile Manager.\n \nEntries in this file will be added and updated my menu options, event \ntriggers, and a nightly background job. Entries in this file will not be \ndeleted.\n \nThis file stores Long Term Care billing information that is used to make a\nbilling determination for LTC rates.\n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with \n \nPer VHA Directive 6402, this file definition should not be modified. \nVA File Manager.\n \nEntries in this file will be added and updated by menu options and a\nnightly background job. Entries in this file will not be deleted.\n \nThis file stores Community Care Urgent Care Visit information that is\nused to determine what copay, if any, a veteran has to pay for an \nUrgent Care visit within the community.\n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with \n \nPer VHA Directive 6402, this file definition should not be modified. \nVA File Manager.\n \nEntries in this file will be added and updated by menu options and a \nnightly background job. Entries in this file will not be deleted.\n \nThis file stores Mental Health Visit information that is used to determine\nwhat copay, if any, a veteran has to pay for a Mental Health visit as \nrequired by the Cleland-Dole Act of 2022.\n\n
\nThis file contains information on bills that have been sent to the Ingenix\nClaimsManager.\n \nThe entries in this file have matching entries in the BILL/CLAIMS file\n(399). The internal number in file 399 is the same as the internal number\nin the CLAIMSMANAGER BILLS file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the status entries that are utilized by the\nClaimsManager interface.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nRecords for each appointment type with indicators for IGNORE \nMEANS TEST, PRINT ON INSURANCE REPORT, and DISPLAY ON INPUT\nSCREEN. Also contains effective date of determination.\nAccessed by extrinsic function ^IBEFUNC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file shall be used to flag dispositions in the DISPOSITION (#37)\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nfile as either billable or non-billable for Means Test Billing. The\nflagging of dispositions is date-sensitive, so the ability to not\nbill can be turned on or off. The default billing action is TO BILL\nALL dispositions; thus, it is only necessary to add entries to this\nfile if billing of a particular disposition is not desired.\n \nThe routine IBEFUNC contains the function call to determine if a\ndisposition should not be billed on a specific date.\n\n
\nThis file shall be used to flag clinic stop codes in the CLINIC\n \nThe routine IBEFUNC contains the function call to determine if a\nclinic stop code should not be billed on a specific date.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nSTOP (#40.7) file as either billable or non-billable for Means\nTest Billing and Third Party Billing. It may also be used to flag\nbillable stops so the Third Party auto biller will not create bills\nfor them. The flagging of the stop codes is date-sensitive,\nso the ability to not bill can be turned on or off. The default\nbilling action is TO BILL ALL stop codes; thus, it is only\nnecessary to add entries to this file if billing of a particular\nclinic stop code is not desired.\n\n
\nThis file shall be used to flag clinics in the HOSPITAL LOCATION (#44)\nThe routine IBEFUNC contains the function call to determine if a\nclinic should be not billed on a specific date.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nfile as either billable or non-billable for Means Test Billing and Third\nParty Billing. It may also be used to flag billable clinics so the\nThird Party auto biller will not create bills for them. The\nflagging of clinics is date-sensitive, so the ability to not bill\nmay be turned on or off. Please note that the default billing action\nIS TO BILL all clinics; thus, it is only necessary to add entries in\nthis file for clinics where billing is NOT desired.\n \n\n
\nThis file is used to store the outpatient clinic stop code and\nbillable type based on an effective date. An internal lookup\non the AEFFDT cross reference for a clinic stop code and visit\ndate will provide the billable type. The billable type determines\nthe billable rate for each outpatient visit.\n\n
\nThis is a reference file containing the types of health insurance\nbill to the Follow-up Printer for that form using the specified routine\nfor that form.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nclaim forms used in billing.\n \nSites may add local forms to this file however, the number of entries\nfor locally added forms should be in the stations number range of\nStation number time 1000. \n \nIf other than UB-04 forms are pointed to by the BILL/CLAIMS file, then\nthe follow-up letter job will create a separate tasked job for each\n\n
\nThis is a reference file containing the Place of Service codes that may be\nassociated with a procedure. This is a set of codes specifically defined to\nbe used on the CMS-1500.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis is a reference file containing the Types of Services that may be\nassociated with a procedure. This set is specifically defined for the\nCMS-1500.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThe IB Attachment Type file contains entries that describe the type of\nsupplemental information available to support a claim for\nreimbursement for health care services.\n\n
\nThis file contains Ambulance Transport Reason Codes and Ambulance \nTransport Reasons used to identify why ambulance transportation was \nrequired. This file comes pre-populated and should not be edited.\n\n
\nThis file contains patient conditions in relation (pickup, during, and \ndrop-off) to ambulance transportation. This file comes pre-populated and \nshould not be edited.\n\n
\nDO NOT EDIT THIS FILE.\nis created for a patient. Exemptions are automatically created when\nchanges in patient information change the exemption status or when\nan expired (older than 1 year) exemption is encountered when determining\nthe exemption status for pharmacy.\n \nThis file will contain specific information related to billing about\nindividual patients. Current Status of the Medication Copayment Exemption\nwill be kept in this file. Conceptually this is different than the\nBILLING EXEMPTIONS File which maintains the audit log and historical data\nrelated to billing exemptions.\n \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nUnder normal operation it is not necessary to edit the fields in this\nfile directly. The option Manually Change Copay Exemption (Hardships) can\nbe used to update and correct this entry by creating a new exemption.\nIf many patient records have problems the option Print/Verify Patient\nExemption Status can be used to correct the entries.\n \nThe data in this file is updated each time a new (current) exemption\n\n
\nDO NOT EDIT THIS FILE.\nif a patient can be exluded from any type of billing for a period of\ntime. The initial use of this file is for storing the time sensitive\ndata related to whether or not a patient is exempt from pharmacy copay\nrequirement due to income below the pension level.\n \nThe file then maintains the audit trail of changes to exemptions and\nhistorical data about exemptions. The data in this file should be\nretained for approximately the current calendar year and the past\ncalendar year. The ability to purge data in this file will be added\nat a future time.\n \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nUnder normal operation it is not necessary to edit the fields in this\nfile directly. The option Manually Change Copay Exemption (Hardships) can\nbe used to update and correct entries by creating a new exemption.\nIf many patient records have problems the option Print/Verify Patient\nExemption Status can be used to correct the entries.\n \nThis file will hold the time sensitive data that is used to determine\n\n
\nWarning: DO NOT EDIT ENTRIES IN THIS FILE without instructions from\nshould not be edited except on instruction from your ISC. Generally\ninstructions to modify this file will be released through the National\nPatch Module on FORUM.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nyour ISC.\n \nThis file contains the reasons for exemptions to a particular billing\nprocess. Initially it will contain reasons only for the Pharmacy Copay\nIncome exemption process. This may be expanded in a later release \nto allow other exemptions to other processes. The current software \nexpects certain entries in this file to exist. Changing the data in\nthis file can have major impact on the Pharmacy Copay process. It\n\n
\nThis file contains the threshold amounts for the Medication Copayment\nbased on veterans making less than the VBA rate for pension plus Aid\nand Attendence.\n \nWith the filing of the 1996 thresholds, the directive was changed to\nreflect that the Medication Copayment Income Exemption was to be based on\nveterans making less than the VBA rate for Basic Pension. This is the\ndirective that is still in effect for current rates.\n \n \n \nIncome Exemption.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nThe Medication Copayment Income Exemption legislation\nwas effective on 30-Oct-92. The thresholds are normally effective\non December 1. To simplify implementation VACO has determined that\nthe threshold effective 1-Dec-92 would be used for the period from 30-Oct-92\nto 1-Dec-92.\n \nThe Medication Copayment Income Exemption from 1992 thru 11/30/96 was\n\n
\nThis file will only be populated if a site chooses to use the\ndeleted after 60 days.\n \nThe data in the file is automatically entered by the system when\neither a detectable error occurs or when an action occurs that\nrequires automatic notification for fiscal integrity (such as\ngiving a hardship notification).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nAlert functionality available in Kernel v7 instead of receiving \nmail messages This is determined by the field USE ALERTS in the\nIB SITE PARAMETERS file.\n \nThe entries will contain the name of the alert and after it has been\nresolved, who resolved the alert. The entries in this file will\nautomatically be deleted by the nightly background job, IB MT NIGHT COMP.\nResolved alerts will be deleted after 30 days, unresolved alerts will be\n\n
\nThis file contains data used to generate alerts. This information \nis used to determine recipients and the contents of the alerts.\nSites should not normally need to delete or edit these entries.\nSpecific users and mailgroups can be assigned to receive each alert message.\n \nDo not add, edit, or delete entries in this file without instructions\nfrom your ISC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the Header and Main body of letters that are\ngenerated by the IB package. Sites should edit the header of the\nletter to their own address. Sites may edit the main body of the\nletter to change the signer of the letter or add in contact persons \nand phone numbers. The text of the letters have been approved\nby MCCR VACO.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with VA\nFile Manager.\n \nThis file stores summary information about a patient's copay account. The\ninformation will be used to determine if a patient has reached his copay\ncap for the month or year.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with VA\nPer VHA Directive 10-93-142, this file definition should not be modified.\nFile Manager.\n \nThis file stores individual transactions for outpatient medication\ncopayments. The transactions in this file will be used to store detailed\ninformation about a patient's rx copayments, including amounts billed and\nnot billed. There should be transactions stored in this file for both\nthis facility and other treating facilities through out the VA system.\n \n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with VA\nFile Manager.\n \nThis file comes populated with data. The data in this file should not be\nedited, added, or deleted locally. The information stored here is the cap\namounts for outpatient medication copayment. Once a patient has reached\nhis cap, billing will stop for the remainder of the period indicated.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the standard types of plans that an insurance\ncompany may provide. The type of plan may be dependent on the type\nof coverage provided by the insurance company and may affect the type\nof benefits that are available for the plan.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a list of valid Source of Information codes. These\ncodes can be used to track where the insurance information originated \nfrom.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the list of valid Standard Insurance Filing Time Frames. \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nThe time frame is the maximum amount of time from the date of service that \nthe Insurance Company or Plan allows for submitting claims. \n \nThe time frames in this file are those that may be automatically applied \nand therefore have a corresponding function to calculate the time frame \nrelative to a date of service.\n \nDo NOT add, edit, or delete entries in this file.\n\n
\nThis file contains the types of coverages that an insurance company is\ngenerally associated with. If an insurer is identified with more than \none type of coverage then it should be identified as HEALTH INSURANCE as\nthis encompases all.\n \nSites should not add, edit or delete entries from this file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the relevent data for Group insurance plans.\nThe data in this file is specific to the plan itself.\n \nThis is in contrast to the patient file which contains data about\npatient's policies, where the policy may be for a group or Health \nInsurance Plan.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis table file contains elements that can be checked for an\ninsurance company policy to determine if third party billing is valid.\nFor example, the general categories of coverage the policy may exclude.\n\n
\nThis file contains the detail by plan and effective date of the categories\nthat may be restricted for insurance coverage.\n\n
\nThis file contains insurance information accumulated by various sources.\nThe data is held in this file until an authorized person processes the\ninformation by either rejecting it or moving it to the Insurance files.\n \nOnce an entry is processed most of the data is deleted leaving a stub entry\nin this file which can be used for reporting and tracking purposes.\n\n
\nThis is a log file for the insurance queries that were done during a \ngiven month/year. There will be one entry for each month/year with \nsummary results only stored in the file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file keeps track of when an eII file is extracted (Creation time), \nDate/time that the extracted file message was sent, with message ID and Austin ID \nand AITC Confirmation Number.\nIn addition, the Activity Log sub-file keeps track of the history of these \nfile transfers.\n\n
\nThis file keeps track of date/time that HMS result file messages are\nreceived from HMS. In addition the Activity Log sub-file keeps track of the\nhistory of the message transfers. \n\n
\nThis file will track transaction from creation until final processing. \nThis file tracks insurance records that are processed through the \nINSURANCE VERIFICATION PROCESSOR (355.33), in addition to records that \nare processed via auto update.\n\n
\nThis file contains the fields to maintain the annual benefits by year \nfor an insurance policy.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file will contain the claim to date information about a patient's\nhealth insurance claims to a specific carrier for a specific year. This\nwill allow estimate of receivables based on whether claims exceed deductibles\nor other maximum benefits.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a listing of Insurance Riders that can be purchased\nas add on coverage to a group plan. The software does nothing special\nwith these riders. The listing may be added to locally and be assigned\nto patients as Policy riders. This information is strictly for display\nand tracking purposes only.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the insurance riders that have been purchased as\nadd on coverage to a group plan. This information is used internally\nfor display purposes only. \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThe SPONSOR file contains a list of people who are the sponsors\nof more than one patient. The SPONSOR RELATIONSHIP (#355.81)\nfile relates a sponsor to a specific patient.\nfor patients who have Tricare insurance coverage. These\npeople, who are typically active duty personnel or military\nretirees, are stored as either patients (in file #2) or\nnon-patients in the SPONSOR PERSON (#355.82) file. A variable\npointer is used to point to the person in either of those\ntwo files.\n \nThis file is used as a list of sponsors who may be the sponsor\n\n
\nThe Sponsor Relationship file is used to associate a sponsor\nin file #355.8 with a patient. The attributes associated\nwith that sponsor/patient relationship are stored in this\nfile.\n\n
\nThis file is pointed to by the SPONSOR (#355.8) and contains\nall sponsors who are not patients. This file contains the\nnon-patient sponsor's name, date of birth, and social security\nnumber, all of which are retrieved from the PATIENT (#2) file\nfor sponsors who are patients. Other pertinent sponsor\ninformation is stored in the SPONSOR (#355.8) file.\n\n
\nThis file contains one record for each unique billing provider id number\n o Assigned by an insurance co to an individual practitioner\n o Assigned by an insurance co to an individual practitioner,\n but a new number assigned for each care unit entry\nthat an individual provider (practitioner) is assigned by an insurance\ncompany or by a licensing or government entity. Entries without an\ninsurance company indicate the number is assigned to the practitioner by a\nlicensing or government entity and will apply to all insurance companies.\n \n This file contains the id numbers for the following ids:\n o Assigned by gov't or licensing agency to a practitioner\n for all ins co\n\n
\nThis file contains one record for each provider id that an insurance\n unit\ncompany assigns to a facility for ALL billing providers at the facility.\nEach record can be for an insurance company and any combination of the\npatient status, form type and care unit. There must be only one\nrecord for each combination.\n \n This file contains the id numbers for the following levels:\n o Assigned by insurance company to all providers\n o Assigned by insurance company, to all providers, one id for each care\n\n
\nThis file contains one record for each facility id that an insurance\ncompany assigns to a facility. Each record can be for an insurance\ncompany and any combination of the patient status and form type.\nThere must be only one record for each combination.\n\n
\nThis file contains data for non-VA facilities that provide services for VA\npatients who have reimbursable insurance for these services. VA pays for\nthese services and in turn submits the charges to the insurance co for\nreimbursement.\n\n
\nThis file contains the data values (referred to as care units) to be used\nto match a provider on a claim to the correct provider id #. The entries\nin this file are specific to an insurance company.\n\n
\nThis file defines the 'list' of care units that an insurance company\nuses to assign provider id's. Each record must have an insurance company,\na provider type and a care unit entry. The sum total of all the\nrecords in this file for a given insurance company comprises the complete\nlist of care units the insurance company requires the V.A. to use when\ndetermining provider id's for any claims sent to them.\n\n
\nThere can be many different kinds of provider id numbers that may need\nto be reported when billing for hospital and professional services. This\nfile contains entries that will be used to classify or identify the valid\nkinds of provider ids that the V.A. will use. This is needed specifically\nfor the transmission of bills so the proper interpretation of the ID's can\nbe made electronically.\n\n
\nThis file contains the Alternate Primary Payer ID Types which are used to\nidentify an Alternate Primary Payer ID for a payer to be sent on the\noutgoing electronic claim (837).\n\n
\nMaster Type of Plan contains standard sources of payment from the the\nof locally defined fields that were created prior to the VHA Directive's\n2005-044 effective date shall not be supported.\nPublic Health Data Standards Consortium (PHDSC).\n \nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\n\n
\nThis file may contain entries of all type of billable events that need\nto be tracked by MCCR. The information in this file is used for MCCR and\nor UR purposes. It is information about the event itself not otherwise\nstored or pertinent for MCCR purposes.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for request \ncategories.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for certification \ntype codes.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for current health \ncondition.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for prognosis.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for delay reasons.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for diagnosis types.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for delivery time \npattern.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for condition.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for admission source.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for patient status.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for nursing home \nresidential status.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for subluxation level.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for oxygen equipment \ntypes.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for oxygen test \nconditions.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for oxygen test \nfindings.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for oxygen delivery \nsystems.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for patient locations.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for report types.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for nursing home \nlevel of care.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all of the corresponding X.12 codes for the \nCertification Action Codes.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all of the corresponding X.12 codes for the Health \nCare Services Decision Reason Codes according to the ASC X12 External \nCode Source 886.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all of the corresponding x12 codes for\ndental work on a tooth. Per VHA Directive 10-93-142, this file\nshould not be modified.\n\n
\nReason for removal of an entry from the HCSR 278 Request/Inquiry for\nAuthorization for service.\n\n
\nThis file contains Utilization Review information about appropriateness\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nof admission and continued stay in an acute medical setting. It uses\nthe Interqual criteria for appropriateness. An entry for each day of\ncare for cases being tracked is required by the QM office in VACO. The\ninformation in this file will be rolled up into a national data base.\nOnly reviews that have a status of COMPLETE should be rolled up.\n \nThe information in this file is clinical in nature and should be treated\nwith the same confidentiality as required of all clinical data.\n\n
\nThis is the type of Review that is being performed by MCCR or UR. This \nfile may contain the logic to determine which quesions and/or screens\ncan be presented to the user in the future.\n \nDo NOT add, edit, or delete entries in this file without instructions\nfrom your ISC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the data used in the compilation of the average\n \n Fields 2.01 - 2.11 contain the unbilled inpatient and outpatient\n totals for the month used in creating the unbilled amounts bulletin\n and report.\n \n NOTE: Fields .02 - .16, 19, and 20 will no longer be used for\n storing and configuring average/unbilled totals and will\n be phased out at a later date.\n \nThis data is generally maintained by two options queued to run once\ninpatient bill totals and the monthly unbilled amounts bulletin and\neach month. The first option will update the monthly and yearly totals\nfields. The second option will search the CLAIMS TRACKING file for\nunbilled episodes of care and should be run on the 1st or second day\nof the month.\n \nThere are two user options which are available to regenerate the\nreports. The automatically queued options will not write over\npreviously compiled data. The user queued options will write over\npreviously compliled data. Sites who modify the data in this file\nshould be aware that the user queued options will overwrite manual\nreport.\nchanges.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n \nThe data is in two parts:\n \n Fields 1.01 - 1.14 contain the inpatient claim and episode totals\n for the month and prior 12 months used in configuring the average\n inpatient bill totals.\n\n
\nThis file contains information about the MCCR/UR portion of Utilization\nPer VHA Directive 10-93-142, this file definition should not be modified.\nReview and the associated contacts with Insurance Carriers. Appropriateness\nof care is inferred from the approval and denial of billing days by\nthe insurance carriers UR section. \n \nWhile this information appears to be primarily administrative in nature\nit may contain sensitive clinical information and should be treated with\nthe same confidentiality as required of all clinical data.\n \n\n
\nThis file is a list of the standard reasons for denial of a claim. Do\nnot add to or delete from this file. Editing this file may have significant\nimpact on the results of the MCCR NDB roll-up of claims tracking \ninformation.\n \nDo NOT add, edit, or delete entries in this file without instructions\nfrom your ISC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains information related to Healthcare Services Review \nworklist and corresponding HL7 messages (message type 278).\n\n
\nPer VHA Directive 2004-038, this file should not be modified or edited\nwith VA Fileman.\n \nThis file stores Release of Information (ROI) data collected that relates\nto a specific patient/drug/insurance combination for the effective dates.\nA claim that includes a sensitive drug is checked against this file for\na billing determination. Claims that do not pass the check are determined\nto be not ECME billable. Bills that do not pass the check cannot be \nauthorized.\n\n
\nThis file contains the Release of Information (ROI) Special Consents \nobtained from patients for sensitive conditions.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file contains the major categories of areas that are used to address\n \nThe contents of this file are the general categories for Intesity of \nService and Severity of Illness from Interqual.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nthe severity of illness and intensity of service. Specific criteria for\neach category must be met to address appropriateness of admission to\ncontinued stay in and discharge from specialized units and general\nunits.\n \nDo Not add to or delete from this file without instructions from your\nISC. Editing this file may have significant impact on the QM national \nroll-up of Utilization Review information.\n\n
\nThis file serves as a bridge between Claims Tracking and the Bill Claims \nfile. An entry is created automatically by the billing module to link\nthe events being billed to the claims tracking entry. It serves as a\ncross-reference in a many to many relationship for the entries in these\ntwo files. Entries should not normally be added or edited manualy in \nthis file. It should be maintained by the Billing Module.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the list of approved non-acute classifications provided\nby the UM office in VACO. The codes are used in roll up of national data\n \nDo NOT add, edit, or delete entries in this file without instructions\nfrom your ISC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the DRG's and average length of stays (ALOS) that\nis the most common alos approved by insurance companies. this generally\nis much shorted than the ALOS for the VA\n \nThe data in this file is initially seeded with the HCFA 1992 table of\naverage length of stays.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the types of events that can be stored in Claims\nTracking. It also contains data on how the automated biller is to\nhandle each type of event. \n \nDo NOT add, edit, or delete entries in this file without instructions\nfrom your ISC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a list of the types of actions that may be taken\non a review or a contact by an insurance company\n \nDo NOT add, edit, or delete entries in this file without instructions\nfrom your ISC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis is a file of reasons that may be entered into the claims tracking \nmodule to specify why a potential claim isn't billable.\n \nDo NOT add, edit, or delete entries in this file without instructions\nfrom your ISC.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file stores the Billable Findings codes for the Claims Tracking\nmodule of IB. Entries in this file are nationally distributed and should\nnot be changed locally.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is designed to hold all inpatient diagnoses.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds inpatient procedures.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds interim DRGs computed by the Claims Tracking Module for\ndisplay in Claims Tracking and on Reports. The computed ALOS is based\nupon 1992 HCFA average lengths of stay and not VA averages. The purpose is\nto help utilization review personnel determine if the the ALOS approved\nby an insurance company is within industry standards.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is to allow the claims tracking module store the admitting\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nphysician. In addition, the attending and resident providers can be\nidentified in this file. If attending and resident providers are\nentered then they are assume to be entered completely for an episode\nof care being tracked. If no provider other than admitting physician\nis entered then the providers and attending from MAS will be considered\nto the the correct providers. Because QM data may be extracting this\ndata on the national roll-up, it is necessary to correctly identify the\nattending physician.\n\n
\nWarning: Do Not Re-Index this file. If this file should accidentally\n be re-indexed, use the option to Recompile All Forms. This will\n correct any printing problems that might occur.\n \nThis file contains the descriptive information about an encounter form. An\nencounter form is composed of many encounter form blocks. Encounter form\nblocks contain all the data and lists that appear on the form. The data\nfrom this file along with the other encounter form files is used to design\nand print encounter forms.\n\n
\nThis file will contain one entry for each time the AICS purge options\nare run. Both the automatic and manual options cause entries. The\npurpose of this file is to provide a historical log of the number of\nentries that are purged at each site. \n\n
\nThis file contains the AICS parameters that control the operation of\nthe package. Included are parameters to manage the automatic purge\nand those necessary to create print manager jobs that automatically \nqueue encounter forms to print.\n\n
\nWarning: Do Not Re-Index this file. If this file should accidentally\n be re-indexed, use the option to Recompile All Forms. This will\n correct any printing problems that might occur.\n \nThis file contains the description of encounter form blocks. A block is a\nrectangular areas on an encounter form. Blocks are the basic building unit\nof encounter forms. All data on a form is contained within a block and the\nblock is sized and positioned to create a usable form.\n\n
\n \nto be checked to indicate that a choice is being made from the list.\n \n \n \n \nThis file contains descriptions of 'selection lists'. A selection list is\na rectangular area in a block that contains a list. The list has 'columns'\nof 'selections'. The columns have 'subcolumns', which can either contain\ntext or a 'marking area'. A marking area is an area on the form designed\n\n
\n \nContains the items appearing on the SELECTION LISTS. A selection can be\ncomposed of several fields, hence can occupy several subcolumns. Only the\ntext is stored here, not the MARKING SYMBOLS.\n\n
\n \nA Selection Group is a set of items on a list and the header that those\nitems should appear under.\n\n
\n \nA data field can be composed of a label, determined at the time the form\ndescription is created, and data, coming from the DHCP database and\ndetermined at the time the form prints. The label and data are printed to\nthe encounter form. A data field can be composed of subfields, each\nsubfield containing possibly its own label and data.\n\n
\nThis file contains a description of all of the interfaces with other packages.\nNote that multiple entries in this file can have the same entry points\ninto routines. This is for efficiency purposes. For example, patient name,\nDOB and sex are all located on the same node of the Patient file. Each of\nthese items of data can have its own entry in the Package Interface file,\nbut by using the same entry point there is a savings because all of the\ndata on that node can be obtained at once. The routine that invokes the\nentry points keeps track of those already invoked so that they are not\nrepeated.\nThe form will invoke the proper interface routines by doing a lookup on\nthis file and then calling the routine by indirection. The\nData will be exchanged between the encounter form utilities and other\npackages by putting the data in at @IBARY. Interfaces that pass a single\nvalue or record will will reference data as in: S DATA=@IBARY. Interfaces\nthat pass lists of records or values will reference the data as in:\nS DATA=@IBARY@(<number of item on the list>).\n \n\n
\nThis file contains the Evaluation and Management codes. They consist\nof a subset of CPT codes used to describe the level of care for an\noutpatient visit.\n\n
\nEither a horizontal or vertical line appearing on the form.\n\n
\n \nA TEXT AREA rectangular area on the form that displays a word processing\nfield. The text is automatically formatted to fit within the area.\n\n
\n \nThis file contains the different types of marking areas that can be\nprinted to a form for the user to write in. Examples are ( ),__, etc.\nThese are for the person completing the form to mark to indicate a choice.\n\n
\nThis file must not be edited!\n \nA table containing a list of conditions recognized by the print manager.\nThey are used to specify the conditions under which reports should be\nprinted. The print manager is a program that scans the appointments for\nselected clinics for a selected date, and prints specified reports under\nspecified conditions.\n\n
\nThis file allows multiple choice fields to be defined for forms.\n\n
\nThis file contains a list of terminal types that can support either\nduplex printing or the printer control language PCL5. Entering the\ncorrect information in this file will allow encounter forms printed\nto these terminal types to utilize these features.\n\n
\nContains information about the form needed to process the input.\n\n
\nThis file is used to track the data capture efforts associated with \neach appointment.\n\n
\nThis file contains the counters needed by the encounter form utilities.\n\n
\nA table of qualifiers used by the PCE Generic Device Interface.\n\n
\nThis file is used to create groups of clinics for use by the\nPrint Manager.\n\n
\nUsed by the import/export utility as a workspace.\nThis file is nearly identical to file #357. It is used by the Import/Export\nUtility as a temporary staging area for data from that file that is being\nimported or exported.\n\n
\n \nThis file is nearly identical to file #357.1. It is used by the\nImport/Export Utility as a temporary staging area for data from that file\nthat is being imported or exported.\n\n
\nUsed by the import/export utility as a workspace.\nthat is being imported or exported.\nprovisions have been made to specify up to 4 columns per list.\n \n \n \n \n \n \nThis file is nearly identical to file #357.2 . It is used by the\nImport/Export Utility as a temporary staging area for data from that file\n\n
\n \nThis file is nearly identical to file #357.3. It is used by the\nImport/Export Utility as a temporary staging area for data from that file\nthat is being imported or exported.\n\n
\n \nThis file is nearly identical to file #357.4. It is used by the\nImport/Export Utility as a temporary staging area for data from that file\nthat is being imported or exported.\n\n
\nUsed by the import/export utility as a workspace.\n \n \nThis file is nearly identical to file #357.5. It is used by the\nImport/Export Utility as a temporary staging area for data from that file\nthat is being imported or exported.\n\n
\nThis file is used as a workspace by the import/export utility.\nutilities and other packages by putting the data in a predefined location.\nThe first part of the subscript is always be ^TMP("IB",$J,"INTERFACES".\nFor output routines, but not selection routines, the fourth subscript is\nbe the patient DFN. The next subscript is the name of the Package\nInterface. For single valued data and record valued data there is no\nadditional subscript. For interfaces returning a list there is one\nadditional subscript level, the number of the item on the list. For\nword processing type data the data will be in FM word-processing format,\ni.e., the final subscripts will be ...1,0),...2,0),...3,0), etc.\nthese items of data can have its own entry in the Package Interface file,\nImport/Export Utility as a temporary staging area for data from that file\nbut by using the same entry point there is a savings because all of the\ndata on that node can be obtained at once. The routines that invoke the\nentry point keep track of the entry points already invoked so they are\nnot repeated.\nthat is being imported or exported.\n \nThis file contains a description of all of the interfaces with other packages.\nThe form will invoke the proper interface routines by doing a lookup on\nthis file and then invoking the routine by indirection. The INPUT VARIABLE\nfields are for documentation purposes and to verify that the proper\nvariables are defined. Data will be exchanged between the encounter form\n\n\nThis file is nearly identical to file #357.7. It is used by the\nImport/Export Utility as a temporary staging area for data from that file\nthat is being imported or exported.\n\n
\nThis file is nearly identical to file #357.8. It is used by the\nImport/Export Utility as a temporary staging area for data from that file\nthat is being imported or exported.\n\n
\n \nThis file is nearly identical to file #357.91. It is used by the\nImport/Export Utility as a temporary staging area for data from that file\nthat is being imported or exported.\n\n
\nThis file is used as a work space for the import/export utility of the\nencounter form utilities.\n\n
\nUsed by the Import/Export utility as a workspace.\n\n
\nUsed by the import/export utility of the encounter forms as a workspace.\n\n
\nUsed as a workspace for the import/export utility.\n\n
\nThis file contains a list of forms created with the IB 2.0 version of the\nencounter form utilities that have been converted under AICS for scanning.\n\n
\nUsed to describe a simple data element, one that would appear as a single\nfield on a form. The description includes instructions on how to print\nthe field and how the scanning software should recognize it.\n\n
\nThis file contains the description of the form used by the scanning\nsoftware. The description, for example, must contain the locations of all\nthe fields to be read.\n\n
\nThis file is used to log errors that occur in the DHCP Server side of AICS.\n \nEntries in this file may be deleted after any corrective action that\nneeds to be taken is complete.\n\nCurrently this occurs while rolling up the data from the scanner in a format\nthat is then passed to the PCE Device Interface. Under normal circumstances\nvery few errors should occur, however, if they do occur, the workstation \nsoftware (client side) will be notified and the error can be found in\nthis file and if possible resolved. Normally each error represents one\npiece of data that was ignored by the server software and can easily\nbe entered into PCE using one of the data entry methodologies.\n\n
\nThis file allows fields to be defined to print on forms for hand print.\n\n
\nThis file is used to link FB authorizations to FB payment file invoices\nand, ultimately, IB bills. \n\n
\nThis file contains the data from the return status messages for IB bills\nreturned via EDI from Austin FSC and AAC.\n\n
\nThis file contains the explanation of benefits results (EOB) for bills\nas well as MEDICARE remittance advice data. The data in this file may be\nappended to any subsequent claims in the COB process.\n\n
\nThis file contains a record for each electronic report that can be\nreturned to the site by the V.A's clearinghouse. The puropse of the file\nis to allow the sites to determine which of these reports should be\nforwarded to the appropriate mail group and which ones should be ignored.\n\n
\nThis file contains a list of words or phrases that, if found in the text\nof an electronic returned message for billing, will cause the message to\nbe handled in one of two ways, based on a flag on each entry:\n \nIf the text is present, always file the message without requiring a review\nor\nIf the text is found in the message, regardless of any text found in the\nrest of the message, always force it to be reviewed.\n\n
\nThis file contains the transmission history and return messages that were\nreceived via the test queue for claims that were sent initially as EDI\nclaims and have been retransmitted as test claims.\n\n
\nThis file contains entries created by the Third Party automated biller.\nAuto Bill date did not match the time frame set by the parameters, no\nentry is made in this file but the events Earliest Auto Bill Date is \nreset.\nAn entry will be created for every event that a bill was created for, in\nsome cases these entries will have comments about the event that may be of\ninterest to billing the event.\n \nEntries are deleted from this file in two ways. Entries for events that\nwere billed are only deleted by the system, when the bill is either \ncancelled or authorized. Entries without corresponding bills must be \nAs the auto biller attempts to create bills based on events in Claims\nmanually deleted by a user, with the option provided.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nTracking it sets entries in this file indicating the action taken by the\nauto biller for the event. The only way entries are added to this\nfile is by the auto biller, there is no user entry.\n \nAn entry may be created for the event if a bill could not be created, this\nentry will contain a comment on why the bill could not be created.\nIf the Claims Tracking event could not be billed because the Earliest\n\n
\nThis file contains all diagnoses for bills in the Bill/Claims file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all prescription refills for bills in the Bill/Claims file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all prosthetic items for bills in the Bill/Claims file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nA Rate Schedule defines a specific type of service that may be billed to \na specific payer. This links all elements necessary to define exactly\nwhat events are billed (Charge Set) to which payers (Rate Type).\n \nThere should be a unique Rate Schedule for each type of service billable\nto a payer.\n\n
\nThis file contains the definitions of all Charge Sets. A Charge Set\ndefines a charge rate for a single type of billable event.\n \nDO NOT edit data in this file with VA FileManager.\n\n
\nIndividual billable items and their charges. Each item that may be billed\nshould have an entry. For the item to be automatically charged it must\nbe an item defined on a bill.\n \nThe items are grouped into Charge Sets which correspond to rates.\n\n
\nThis file is part of the Rates process and contains billable items that\nmay be found on a bill but do not have a source file of their own.\n \nEntries should only be added or deleted through the option provided.\n\n
\nThis file defines the types of rates available to bill third parties for\nreimbursment.\n \nNationally distributed Billing Rates should not be modified.\nDO NOT edit data in this file with VA FileManager.\n\n
\nA Billing Region is an area defined by a Billing Rate as having a unique\nset of charges. This may correspond to one or more divisions.\n \nEach Billing Rate may have multiple regions and each region may cover\none or more divisions.\n\n
\nThis file contains the names of special cases that should be applied to\ncertain bill types. This includes the Revenue Code Link group names and the\nProvider Discount group names.\n\n
\nCertain types of bills require specific revenue codes to be used to bill\ncertain types of care. This file allows linking of revenue codes and the\ncare they should be used for.\n\n
\nThis file contains a discount associated with a provider person class.\nThis discount is generally used to adjust physician based provider charges \nfor a non-physician provider. The discount will be applied to \ncare billed to a Billing Rate for providers of the listed person class's.\n\n
\nThis file contains a record for each bill for each time it is included in\na batch for EDI transmissions. This file allows a bill to be tracked\nthroughout its transmission life and gives the bill's current EDI status.\n\n
\nThis file contains a record for each 'batch' created for EDI transmission.\nIt is used to track batch activity and to record statistics on number of\nbills in a batch that were rejected and accepted and to record the message\nnumber in Mailman that the batch is stored in for inquiry access.\n\n
\nThis file contains the messages that are sent electronically back to the\nsite relating to EDI processing. These include, but are not limited to,\nstatus messages, error and warning messages found in the EDI transmission\ncycle, insurance company updates, batch summaries and statistics.\nThese messages are stored by message type and options exist that scan this\nfile and display the messages to the appropriate users and allow each one\nto be dealt with and resolved if necessary.\n\n
\nThis file contains a listing of the transactions that can be handled\nby the IB message server. This file also contains the mailgroup\nthat will receive any transaction processing error message and the\nentry point (TAG^ROUTINE) for each different transaction processing.\n\n
\nThis file contains the rules to be applied to a bill to determine if\nit is eligible for transmission via national EDI.\n\n
\nDO NOT delete entries or edit data in this file with VA File Manager.\n \nThis file contains the definition of all data elements that are needed for\nvarious forms throughout the MCCR DHCP system. It contains the 'blueprint'\nfor how to extract the data for each data element entry.\n \nEntries in this file that are designated as having a SECURITY LEVEL of\nNATIONAL should not be deleted or edited.\n\n
\nDO NOT delete entries or edit data in this file with VA File Manager.\nNATIONAL should not be deleted or edited.\n \nThis file contains records that define the skeleton makeup of forms for\nthe IB system. This definition includes the absolute position of every\nfield that can be output on the form, the length each field must be limited\nto, and some descriptive information. This includes printed forms,\ntransmittable output files, and special local billing screens.\n \nEntries in this file that are designated as having a SECURITY LEVEL of\n\n
\nDO NOT delete entries or edit data in this file with VA File Manager.\n \nThis is the file that contains the specific fields to be used to produce\nthe associated form or screen. If there is no insurance company or bill\ntype specified for an entry, this is assumed to be the default definition\nof the field.\n \nEntries in this file that are designated as having a SECURITY LEVEL of\nNATIONAL should not be deleted or edited.\n\n
\nThis file is the VistA version of FSC's tbl.Payers table, used to perform \nCOB Payer ID switching for Medicare Supplemental claims.\n\n
\nThis file holds all responses to HL7 messages generated from\nthe IIV Transmission Queue File for Insurance Identification\nand Verification.\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 EB01 codes \n(Eligibility/Benefits).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 EB02 codes (Coverage \nLevel).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 EB03 codes (Service \nType).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 EB04 codes (Insurance \nType).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 EB06 codes (Time \nPeriod Qualifier).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 EB09 codes (Quantity \nQualifier).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 AAA03 codes (Error \nConditions).\nThese values are returned because of an error in processing.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 271 AAA04 codes (Error \nActions).\nCertain retry actions are programmed based upon the current values\nin this table.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes which\nidentify a method for contact.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes which identify an \neligibility/benefit entity.\n \n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all the corresponding X.12 codes for identification \nqualifiers.\n \n \nPer VHA Directive 10-93-142, this file definition should not be \nmodified. \n\n
\nThis file contains all the corresponding X.12 codes which identify a \nprovider.\n \n \nPer VHA Directive 10-93-142, this file definition should not be \nmodified.\n\n
\nThis file contains all the corresponding X.12 codes for delivery \nfrequency.\n \n \n \nPer VHA Directive 10-93-142, this file definition should not be \nmodified. \n\n
\nThis file contains all the corresponding X.12 codes for date/time \nqualifiers.\n \n \nPer VHA Directive 10-93-142, this file definition should not be \nmodified. \n\n
\nThis file contains all the corresponding X.12 codes for loop IDs.\nIt is a dictionary to map X12 codes to their corresponding values. \nThe codes are used to parse inbound type 271 messages, among others.\nHIPAA loop IDs come from FSC as part of 271 response message.\n \n \nPer VHA Directive 10-93-142, this file definition should not be \nmodified.\n\n
\nThis file contains all the corresponding X.12 codes for reference \nidentification codes.\n \n \n \nPer VHA Directive 10-93-142, this file definition should not be \nmodified.\n\n
\nThis file contains all the corresponding X.12 271 Units of measurement.\n\n
\nThis file contains all the corresponding X.12 271 Entity Relationship \ncodes.\n\n
\nThis file contains all the corresponding X.12 271 date format qualifiers.\n\n
\nThis file contains the corresponding X.12 271 YES/NO CONDITION OR \nRESPONSE CODES.\n\n
\nThis file contains all the corresponding X.12 271 Location Qualifiers. \n\n
\nThis file contains all the corresponding X.12 271 procedure coding \nmethods.\n\n
\nThis file contains all the corresponding X12 271 Delivery Pattern codes.\n\n
\nThis file contains all the corresponding X.12 271 patient relationship\ncodes.\n\n
\nThis file contains all the corresponding X.12 271 NATURE OF INJURY \nCATEGORY codes.\n\n
\nThis file contains all the corresponding X.12 271 military personnel \ninformation status codes.\n \nPer VHA Directive 10-93-142, this file definition should not be \nmodified.\n\n
\nThis file contains all the corresponding X.12 271 Military Personnel \nInformation government service affiliation codes.\n\n
\nThis file contains all the corresponding X.12 271 Military Personnel \nInformation rank codes.\n\n
\nThis file contains all the corresponding X.12 271 Entity Type Qualifiers.\n\n
\nThis file contains all the corresponding X.12 271 code list qualifiers.\n\n
\nThis file contains all the corresponding X.12 271 NATURE OF INJURY CODES.\n\n
\nThis file contains all the corresponding X.12 271 MPI employment status \ncodes.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains records which have been selected based on\nspecific criteria to generate an HL7 message. These messages\nwill be sent to the Eligibility Communicator for processing.\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThe Auto Match file is a VistA facility to help IIV match user-entered \ninsurance company names to the correct insurance company names in the \ninsurance company file. This file links together an Auto Match Value \nwith a valid insurance company name. The Auto Match Value may contain \ncommon spelling mistakes and wildcard characters to aid in the selection \nof a valid insurance company name.\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis is a standard file exported by the IB package. It contains insurance \nPer VA Directive 6402, this file definition should not be modified. \npayers for the VA. The payers included are used for electronically \nverifying insurance, authorization and referral request, and/or the IIU \npayer application. Do not add, edit or delete these entries except \nthrough the provided edit options. \n \nAt this time, payers added to this file are received from FSC via HL7 \nmessages.\n \n\n
\nThis file contains all the different applications that a payer\ncould be contacted electronically for.\n \nInitially there will only be electronic insurance identification\nand verification as an application.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all of the statuses that an electronic\ninsurance identification or verification transmission or \nreceiving record can have.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the various IIV statuses for entries in the Insurance \nBuffer. Also included are the symbols that should appear in the IIV \nstatus column in the Insurance Buffer list, and a more detailed\ndescription of the status that is used in the Expand Entry option in the \nInsurance Buffer.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file allows VistA to track data associated with the Electronic\nInsurance Coverage Discovery (EICD) extract process. Both Identification\nand Verification EICD transactions (inquires and responses) are detailed\nand tracked in this file. Per VHA Directive 6402, this file definition\nshould not be modified.\n\n
\nThis file contains a list of recently verified 'active' policies that \nwere either sent/shared to another VAMC or was received from another VAMC.\nThis file is the main file for the Interfacility Insurance Update (IIU) \nprocess. Per VA Directive 6402, this file definition should not be\nmodified.\n\n
\nThis file holds the reviews of the IIV Response messages. Per VHA \nDirective 10-93-142, this file definition should not be modified.\n\n
\nThis Integrated Billing (IB) file was created for the e-Pharmacy Project.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nIt is maintained centrally, via real time HL7 Table Update Messages, using\nthe WebMD database.\nNever maintain locally, except via a designated and secured option that \nedits selected APPLICATION Subfile fields, such as LOCAL ACTIVE?.\n \nA NCPDP Processor receives NCPDP transmissions and adjudicates NCPDP \nclaims.\nA NCPDP Processor is uniquely identified by its' name.\n\n
\nThis Integrated Billing (IB) file was created for the e-Pharmacy Project.\ninsurance company payer.\nA PBM is uniquely identified by its' name.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nIt is maintained centrally, via real time HL7 Table Update Messages, using\nthe WebMD database.\nNever maintain locally, except via a designated and secured option that \nedits selected APPLICATION Subfile fields, such as LOCAL ACTIVE?.\n \nA Pharmacy Benefits Manager (PBM) administers a plan on behalf of the\ninsurance company payer.\nA PBM is typically a separate, contracted entity, but it may be the \n\n
\nThis Integrated Billing (IB) file was created for the e-Pharmacy Project.\nA Plan is uniquely identified by its' identifier (VA National Plan ID).\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\nIt is maintained centrally, via real time HL7 Table Update Messages, using\nthe WebMD database.\nNever maintain locally, except via a designated and secured option that \nedits selected APPLICATION Subfile fields, such as LOCAL ACTIVE?.\n \nA Plan is a Payer's medical health care insurance product that defines \nbenefits and their delivery to organizations and individuals that enroll \nin the Plan.\n\n
\nThis Integrated Billing (IB) file was created for the e-Pharmacy Project.\nIt is maintained centrally.\nNever maintain locally.\n \nA NCPDP Processor Application identifies an electronic interface\napplication associated with the NCPDP PROCESSOR File (366.01).\nA NCPDP Processor Application is uniquely identified by its' name.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis Integrated Billing (IB) file was created for the e-Pharmacy Project.\nPer VHA Directive 10-93-142, this file definition should not be modified.\nIt is maintained centrally.\nNever maintain locally.\n \nA Pharmacy Benefits Manager (PBM) Application identifies an electronic\ninterface application associated with the PHARMACY BENEFITS MANAGER \n(PBM) File (366.02).\nA PBM Application is uniquely identified by its' name.\n \n\n
\nThis Integrated Billing (IB) file was created for the e-Pharmacy Project.\nIt is maintained centrally.\nNever maintain locally.\n \nA Plan Application identifies an electronic interface application\nassociated with the PLAN File (366.03).\nA Plan Application is uniquely identified by its' name.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains data which are passed into IB NCPDP APIs by outside \nmodified. \napplications - E CLAIMS MGMT ENGINE and OUTPATIENT PHARMACY (see IA # \n4299). Data stored in this file are used for IB ECME EVENT report to\nprovide details about E-Pharmacy claims processing and about communication\ndetails between IB and the applications listed above. The data in this\nfile is populated internally by the IB application (data not directly\nentered by the user).\n \nPer VHA Directive 10-93-142, this file definition should not be \n\n
\nDO NOT delete entries in this file. DO NOT edit data in this file with VA\nto allow easy lookup if the copayment charge needs to be cancelled.\n \n \nPer VHA Directive 2004-038, this file definition should not be\nmodified. \nFile Manager.\n \nThis file is used to support NCPDP billing for multiple Rate Types. \nEntries are created in this file based on the prescription and \nfill/refill number. The Rate Type determined at time of Billing \nDetermination is stored in this file so it can be utilized when bill \ncreation occurs. This file is also used to store the associated \ncopayment reference number if a non-veteran copayment charge is created \n\n
\nThis file contains the non-billable status reasons used by the IB NCPDP\nBilling Event Log and which are returned by the IB Billable Status Check\nfor ePharmacy claims.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains responses associated with inquiries from the \nHPID/OEID TRANSMISSION QUEUE file (file #367.1).\n \nPer VHA Directive 10-93-142, this file definition should not be modified. \n\n
\nThis file contains records which have been selected based on \nspecific criteria to generate an HL7 message. These messages will be sent to \nthe National Insurance File (NIF) for processing.\n \nPer VHA Directive 10-93-142, this file definition should not be modified. \n\n
\nThis file contains the possible ID types that could be received from\nthe National Insurance file (NIF) for an Insurance Company entry.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all records received from the FSC ASC X12N health Care \nClaim Request For Additional Information (277) HL7 message.\n\n
\nHealth Care Claim Status Codes - limited to the R codes of X12 code \nsource 507.\n\n
\nCode identifying the type/source of the descriptive number used in\nProduct/Service ID.\n\n
\nThe PFSS SITE PARAMETERS file holds data required for proper function\nof the IBB software, which provides common utilities and procedures\nfor PFSS.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to store charge data from various VistA applications\nso that a background process can create an HL7 P03 message from each record.\nThe messages are batched and sent to the external medical billing system.\n \nUnder no circumstances may records be created or modified directly via\nFileMan or other methods. Record creation and data update is allowed\nonly through CHARGE^IBBAPI.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file is used to store visit/encounter data from various VistA \napplications, so that a background process can create HL7 ADT messages \nthat are sent to the external medical billing system.\n \nUnder no circumstances may records be created or modified directly via\nFileMan or other methods. Record creation and data update is allowed\nonly through GETACCT^IBBAPI.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all sensitive patients. Patients are either\nsensitive or non-sensitive. This file is also used as an audit\ntrail for when a sensitive patient is accessed, who accessed it,\nthe option used to access it and whether or not the patient was\nan inpatient at the time the record was accessed.\n\n
\nThe INCONSISTENT DATA file contains those patient's who were found\nto have missing and/or inconsistent data elements in the PATIENT\nfile by the MAS consistency checker. For each patient the date\nthe inconsistencies were first identified, last identified, by whom,\netc., is stored as well as the individual inconsistencies. The\ninconsistent data elements are stored in the INCONSISTENT DATA ELEMENTS\nfile where individual checks can be turned on or off by the facility.\nOnce the data is corrected through the appropriate registration menu\noptions, the entry will be removed from this file.\n\n
\nThe INCONSISTENT DATA ELEMENTS file contains those entries which are\nchecked by the MAS module consistency checker. Other than turning\nindividual checks on or off the user should not alter or add to this\nfile in any way. Making any modification to this file will definitely\ncause the consistency checker to function improperly.\n\n
\nThe purpose of this file is to allow DHCP software flexibility and\nreliability when the station number of a medical center changes or when\none or more stations have merged into one station.\n \nAdding or modifing entries in this file may affect many DHCP applications.\nControl of entry into this file should be carefully controlled by the\nIRM Service Chief.\n\n
\nThis file will be used to keep track of HL7 transmissions sent to external\nPer VHA Directive 10-93-142, this file definition should not be modified.\nsystems. An entry in this file will be created for each transmission\nsent, when an acknowledgement is returned the entry will be deleted. This\nfile will contain transmitted records and records not accepted by other\nsystems.\n \nThe file is currently maintained by the VIC software modules and should\nnot be altered.\n \n\n
\nThis file tracks new/modified Rated Disability changes received from the \nHealth Eligibility Center via ORU/ORF Z11 messages. The purpose of this \nfile is for History only and can not be considered current. Data will be \npurged from this file after it is over 365 days old.\n\n
\nThe MHV Socialization file contains informational My HealtheVet Engagement\ntext to be read to the patient describing the benefits of My HealtheVet\nregistration, and a follow-up dialog to capture actions taken by the clerk\nto assist the patient with My HealtheVet registration.\n\n
\nThe MHV Socialization Actions file contains pre-defined actions which can\ntaken by the Pre-Registration clerk to assist the patient to register in\nMy HealtheVet.\n\n
\nThe MHV Declined Reasons file contains pre-defined text reasons explaining\nwhy the patient has declined My HealtheVet registration.\n\n
\nThe MHV Action Selection file contains the pre-defined My HealtheVet \nEngagement/Registration modules that prompt for MHV SOCIALIZATION ACTIONS.\nThis works in conjunction with the SELECTABLE LOCATIONS (#1) field in the\nMHV SOCIALIZATION ACTIONS (#390.02) file to screen actions and make\navailable only actions that are appropriate for the module, or section of\nMHV functionality.\n\n
\nThis file contains the various types of patient which might be seen\nat a VA facility. The file is pointed to by the TYPE field of the\nPATIENT file and every patient added to the system must have a TYPE\nspecified. Using the 'Patient Type Update' option of ADT the user\nshould specify the parameters concerning which screens should be\ndisplayed during the registration process for these patient types\nand what data elements on those screens are editable.\n\n
\nThis file contains the various AMIS segments. The .001 (Number) field\nshould be defined as the segment number.\n\n
\nThis file is used to define the fields that are collected at a Last Site\nTreated and loaded into a Querying Site via Register Once Messaging.\n \nNOTICE: This file is part of an implementation of a Nationally \n Controlled Procedure. Local modifications to this file \n are prohibited per VHA Directive 10-93-142. \n\n
\nThis file serves as a funnel for all of the ADT events that need to be \nbroadcast to any system. The VISIT file may replace this file in the \nfuture. The entries in this file will contain information on how to \nget back to its parent event in PIMS. There are no parent child \nrelationships stored here.\n\n
\nThis file contains the event reason codes for admission, discharge and\ntransfer (ADT) Health Level Seven (HL7) events.\n\n
\nThis file holds the Treating Facility List, a list of \ninstitutions where the patient has had treatment.\n\n
\nThis file contains a list of all of the facilities that have migrated \nto/implemented the CERNER application in support of the Electronic Health \nRecord Modernization (EHRM).\n \nNOTE: Entries will be added/updated to this file remotely and distributed \n out to all sites through a Remote Procedure Call (RPC) executed on \n the Master Patient Index.\n\n
\nThis file holds the Correlation List, the list of institutions where the\nNEW PERSON is known. As the TREATING FACILITY LIST FILE (#391.91) relates\nto the PATIENT, correspondingly this file (NEW PERSON TREATING FACILITY \nLIST FILE (#391.92)) relates to the NEW PERSON.\n\n
\nThis file is currently used to log exceptions encountered and \ntheir status. This file should not be limited to demographic \nexceptions as it is a place holder. It is tied to a patient.\n\n
\nThis file contains the status name and code (abbreviation)\nassociated with the exceptions processed by the\nPatient Data Review [VAFC EXCEPTION HANDLER] option.\n\n
\nThis file is used to store each individual data element and its location\nfor the exception that is logged.\n\n
\nThis file contains the completed travel claim entries for patients showing\ndeparture/destination data, as well as specific claim data.\n\n
\n \nThis file contains the mileage data between departure cities and\nmedical center divisions. Each departure city can have multiple\ndivisions entered, each with it's own associated mileage, most\neconomical cost, and remarks field.\n\n
\n \nThis file contains the income certification data for patients\nfor Beneficiary Travel claims, including amount certified,\neligibility for for Bene. Travel, and means test status.\n\n
\nAlthough this file has be decentralized, changes and additions should be \nmade with extreme care. \n\n
\nThis file contains vendors of the Core Financial Logistics System\n(coreFLS) used by your local system. Entries should only be added and\nupdated through the applications interfaced with coreFLS. Entries SHOULD\nNOT be added, edited, or deleted through Filemanager.\n\n
\n \nThis file contains the data on the different modes of transportation\navailable in Bene Travel claims.\n\n
\nThis file contains internal codes and descriptions of patients' reasons \nfor BT eligibility.\n\n
\nThe file contains a list of acceptable types of transporation for special \nmode patients.\n\n
\nThis file contains the denial letters the site uses.\n\n
\nThis file contains the list of patients that have an active manual \nwaiver at the time the Travel Claim.\n\n
\nThis file contains the Beneficiary Travel denial reasons.\n\n
\nThis file contains alternate income data for patients.\n\n
\nThis file is the main file for the Incomplete Records Tracking package IRT\nThis is where all of the data is stored that will be displayed for each\ndeficiency on the enter/edit screens and on all of the reports.\n\n
\nThis file stores all the possible services for both wards and clinics.\n\n
\nThis is the file that contains the names of the\nstatuses that an IRT record must go thru to\nits completion.\n\n
\nThis file contains the names of the types of deficiencies\nthat are tracked in the IRT package.\n\n
\nThis is the file that stores the name of the category and all\ndata elements related to the category, that a deficiency falls\nunder. There are thirteen categories.\n\n
\nThis file has been replaced with the VAQ - TRANSACTION file (#394.61).\n \nVersion 1.0 of PDX used this file to store administrative information\nconcerning all PDX transmissions. Version 1.5 of PDX has marked it for\ndeletion and version 2.0 will delete it.\n\n
\nThis file has been replaced with the VAQ - DATA file (#394.62).\n \nVersion 1.0 of PDX used this file to store patient information that was\ntransmitted using PDX. Version 1.5 of PDX has marked it for deletion and\nversion 2.0 will delete it.\n\n
\nThis file has been replaced with the VAQ - PARAMETER file (#394.81).\n \nVersion 1.0 of PDX used this file to store site specific information\nconcerning the use of PDX. Version 1.5 of PDX has marked it for deletion\nand version 2.0 will delete it.\n\n
\nThis file has been replaced with the VAQ - STATUS file (#394.85).\n \nVersion 1.0 of PDX used this file to store all possible phases of a PDX\ntransmission. Version 1.5 of PDX has marked it for deletion and version\n2.0 will delete it.\n\n
\nThis file has been replaced with the VAQ - WORKLOAD file (#394.87).\n \nVersion 1.0 of PDX used this file to store workload statistics concerning\nuse of PDX. Version 1.5 of PDX has marked it for deletion and version 2.0\nwill delete it.\n\n
\nThis file holds information describing each PDX transaction. A PDX\ntransaction is created when one of the following events occur.\n \n (1) A PDX Request is defined and sent\n (2) A PDX Request is received from a remote facility\n (3) An Unsolicited PDX is defined and sent\n (4) An Unsolicited PDX is received from a remote facility\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds any patient information that was transmitted using PDX.\nthe Extraction Array).\n \nSegments stored as display ready will only have one entry.\n \n \nIf field # .05 is set to 'YES', fields # .03, .04, 10, 20, and 30 will not\ncontain data (field # 50 will contain the display ready format of the\nsegment).\n \nIf field # .05 is set to 'NO', field # 50 will not contain data (fields #\n.03, .04, 10, 20, and 30 will contain the information required to rebuild\n\n
\nThis file defines each data segment currently supported by PDX.\nDisplay methods must take the output of their associated extraction method\nas input.\n \nGlobal format of Display Array:\n Root@("DISPLAY",line number,0)=information displayed on specified\n line number of screen\n \nMethods must use the following parameters (where needed):\n ROOT - Where to store the information (full global reference)\n DFN - Internal file number for requested patient (pointer to PATIENT\n \n File)\n SEGPTR - Internal file number of segment (pointer to VAQ - DATA\n SEGMENT File)\n XTRCT - Where the extracted information resides (full global\n reference)\n OFFSET - Where line numbering should begin from\n TIMLIM - Time limit to apply to extraction\n OCCLIM - Occurrence limit to apply to extraction\n \nMethods must return the following:\n \n 0 - Extraction was successful (if an Extraction Array was returned)\n n - Number of lines in display (if a Display Array was returned)\n -1^ErrorText - Method was not successful\n \nSample methods:\n $$EXTRACT^VAQZZZ(DFN,SEGPTR,TIMLIM,OCCLIM,ROOT,OFFSET) - Display\n Array is\n returned\n $$EXTRACT^VAQZZZ(DFN,SEGPTR,TIMLIM,OCCLIM,ROOT) - Extraction Array\n is returned\nGlobal format of Extraction Array:\n $$DISPLAY^VAQZZZ(XTRCT,SEGPTR,ROOT,OFFSET) - Display Array, built from\n input extraction array,\n is returned\n \nSample use:\n S ROOT="^TMP(""VAQ"","_$J_")"\n S SEGPTR=internal file number for segment\n S DFN=internal file number of patient\n S TIMLIM=time limit to use when extracting segment (if applicable)\n S OCCLIM=occurrence limit to use when extracting segment (if\n Root@("VALUE",file,field,sequence number)=value\n applicable)\n X ("S X="_^VAT(394.71,SEGPTR,"XRTN"))\n The variable X is now set to the proper exit code (X<0 on error)\n Root@("ID",file,field,sequence number)=identifier\n \nExtraction methods must account for data encryption.\n \n\n\nThis file defines each encryption method currently supported by PDX.\n string - Encrypted or decrypted form of STRING\n NULL - Error\n \nSample methods:\n $$ECR^VAQZZZ(STRING,KEY1,KEY2) - Encrypts STRING using the\n encryption keys KEY1 & KEY2\n $$DCR^VAQZZZ(STRING,KEY1,KEY2) - Decrypts STRING using the\n decryption keys KEY1 & KEY2\n \nSample use:\n \n S IFN=internal file number for encryption method\n S STRING="TEST"\n S KEY1="ABCD1234"\n S KEY2="ZYXW0987"\n X ("S X="_^VAT(394.72,IFN,"ECR"))\n The variable X is now set to the encrypted format of STRING\n \nMethods must use the following parameters:\n STRING - String to encrypt/decrypt\n KEY1 - Name of primary encryption/decryption key\n KEY2 - Name of secondary encryption/decryption key (if required)\n \nMethods must return the following:\n\n\nThis file contains all fields that should be encrypted in PDX Requests and\nUnsolicited PDXs transmitted by the facility. This file is only relevant\nwhen encryption has been turned on.\n\n
\nThis file contains site specific information concerning the use of PDX.\nOnly one entry may be made in this file.\n\n
\nThis file contains the facilities that have been granted 'Automatic\nProcessing'. In order for a request to be automatically processed, the\nrequesting facility must have an entry in this file.\n\n
\nThis file contains groups of facilities commonly accessed using PDX.\n\n
\nThis file contains groups of data segments commonly referenced by the\nfacility. Groups marked as 'Public' may be referenced by all users of\nPDX. Groups marked as 'Private' may only be referenced by the individual\nthat created the group.\n\n
\nThis file defines all possible statuses of a PDX transaction.\n \n \nCodes must be in the form XXXX-YYYYY where XXXX is the namespace of the\npackage (1-4 upper case characters) and YYYYY is 1-5 characters (upper or\nlower case) of the package's choosing. [Must pattern match 1.4U1"-"1.5A]\n\n
\nThis file is used to implement auto-numbering in the PDX files. Fields\nwith auto-numbering capability will have an entry in this file.\n\n
\nThis file contains statistics concerning the workload done using PDX.\nPDX workload is considered to be requesting patient information from\nanother facility, manually processing requests from another facility, and\nuploading PDX data to the Patient File. Work done by the PDX Server is\nalso stored in this file.\n\n
\nThis file contains the type of work being tracked by the VAQ - WORKLOAD\nfile (#394.87).\n\n
\nHolds all requests for 7131 information. This is the information which\nfields on nodes 6 and 7 indicates the node the field exists on.\nThe piece position for each field on nodes 6 and 7 corresponds to the\npiece position of its respective report status field on that report's node.\n \nNOTE: The 'AE' and 'AF' cross-references are specialized MUMPS cross-\nreferences used to implement the Divisional Transfer of reports on a\n7131 request. Please follow the technical descriptions of the above\ncross-references when reindexing.\nwas requested on the old paper 7131 forms.\n \nNode 6 was added with Version 2.7 of AMIE. This node contains the\ndivisions a selected report on a 7131 has been transferred to.\nNode 7 was added with Version 2.7 of AMIE. This node contains the\ndates a report on a 7131 was transferred to another division.\nThese nodes are used only by Multidivisional facilities that transfer\nreports on a 7131. The decimal portion of the field numbers for the\n\n
\nHolds the package specific parameters for the AMIE site.\n\n
\nThis file is used by the CAPRI GUI to maintain a list of AMIE C&P \nexaminations that are assigned to a specific medical center division. It \nis also possible to set a flag in this file to disable the division from \nappearing in the listing of selectable divisions in the GUI.\n\n
\nThis file holds the definitions generated by users of the CAPRI C&P \nWorksheet Module (CPWM) that are used to re-generate GUI screens. CPWM \nallows point-n-click entry of C&P examinations and will store ASCII \nreports in AMIE and TIU when the user has finished the documentation \nprocess. This file serves to track documents in progress as well as \ndocuments that have been already completed and sent to TIU and AMIE.\n\n
\nThis file maintains a list of definitions used to generate \nexamination templates in the CAPRI GUI interface. These definitions will\nbe used by providers to document C&P examinations in point-n-click\nformat. The definitions will not be used in the roll-n-scroll AMIE-II \napplication and are specific to the GUI environment. Old definitions, as\nthey are retired, will be retained in the file for historical\npurposes. This file should remain standardized between all sites and \nentries not be modified, removed, or added except through patch \ninstallation.\n\n
\nThis global will contain the selectable reroute site for CAPRI.\n\n
\nFile to hold various parameters for specialized reporting in the A.M.I.E.\npackage. Information is deleted as soon as possible.\n \n(This file is used specifically when generating and printing Notices of\nDischarge.)\n\n
\nThis file will store transmission data from a CAPRI GUI User transmitting \nClinical Documents.\n\n
\nThis file contains a list of valid Special Considerations.\n\n
\nThis file contains a list of valid Claim Types.\n\n
\nHolds all 2507 requests generated from Regional Office users.\n\n
\nThis file contains the status for the 2507 Request.\n\n
\nThis file contains all the exams that are associated with the various 2507\nrequests. \n \n NOTICE: This file is part of an implementation of a Nationally\n Controlled Procedure. Local modifications to this file\n are prohibited per VHA Directive 10-93-142.\n \n\n
\nThis file contains contacts for external Contractors (or Companies) who \nare authorized to perform 2507 exams for VA patients at their respective \nclinic/hospital.\n \nNote: SFTP information will be maintained and referenced from the central \nCLAIMS VistA system, denoted by the REMOTE CONTRACTOR Field #3. SFTP \ninformation added locally will be ignored by the demTRAN application.\n\n
\nThis file has all current reasons that a 2507 exam may be cancelled.\n \n NOTICE: This file is part of an implementation of a Nationally\n Controlled Procedure. Local modifications to this file\n are prohibited per VHA Directive 10-93-142.\n\n
\nCodes for rerouting the 2507 Request\n\n
\nCurrent listing of all valid 2507 exams that may be requested. The exams\nmay be inactivated by the setting of the active/inactive flag. Only the \nRegional Office may determine if an exam is active or inactive.\n \n \nNOTICE: This file is part of an implementation of a Nationally \n Controlled Procedure. Local modifications to this file\n are prohibited per VHA Directive 10-93-142. \n\n
\nContains all body system names to which the 2507 exams are related.\n\n
\nThe FORM 28-8861 file contains data from veteran's Chapter 31 Request for Medical Services requests. The 8861 requests are tied to consults created through CPRS.\n\n
\nThis file has been added for use by the 2507 EXAM File (396.4). It\ncontains the reason an exam is returned by the Regional Office to the\nMedical Center as 'Insufficient'.\n \nThe reasons contained in this file were developed and agreed upon by the\nAMIE Sub-group of the PII-EP. This information should not be modified by\nthe site.\n\n
\nThis file has been added for use by the 2507 REQUEST File (396.3). It\n are prohibited per VHA Directive 10-93-142\ncontains information about C&P appointments linked to 2507 Requests.\n \nThis file should not be edited via FileMan. The information in this file\nis crucial to proper calculation of the Average Processing Time on the\nAMIE AMIS 290.\n \nNOTICE: This file is part of an implementation of a Nationally\n Controlled Procedure. Local modifications to this file\n\n
\nThis file contains all of the information necessary to complete a \nThird Party billing form.\n \nThe entries in this file have matching entries in the Accounts Receivable\nfile (430). The internal number in the AR file is the same as the internal\nnumber in the BILL/CLAIMS file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all of the Occurrence Codes, Discharge Bedsections,\nDischarge Statuses and Value Codes which may be used on the Third Party\nclaim forms.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all of the Revenue Codes which may be used on the\nThird Party claim forms.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all of the Rate Types which may be used in MCCR Billing.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains a list of all possible reasons why a bill may be\ndisapproved during the review phase of the billing process. Each\nelement in this file corresponds directly to a form locator on the\nUB-04 form.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains the historical billing rates, associated with revenue\nThis file has been replaced by functionality in the Charge Master and\nwill no longer be used after patch IB*2*52 is released.\ncodes and bedsections that the DVA has legislative authority to bill third\nparties for reimbursement.\n \nIt is used to automatically associate revenue codes, bedsections and\namounts with a bill.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n \n\n
\nThe Inter-UCI Transfer file is used by MailMan to do non-interactive\ntransmissions and receptions of messages to and from UCIs that share\nthe %ZISL file either because they are on the same machine or because\nthey are on the same local area network and use DDP translation techniques\nfor the %ZISL global.\n\n
\nWhen multimedia messages are transmitted, procedure files are created to\nsend the 'non-textual message body parts' using the File Transfer Protocol\n(FTP). Entries are made into this file for each such instance and then\nthe TCP/IP Poller will execute the procedure file and delete the entry for\nit.\n\n
\nPeople who have mailboxes on remote systems may be entered into this\nfile so that local users can look up their names and have their mail\nautomatically addressed.\n\n
\nThis file is used to store statistics about local message deliveries,\nresponse time and numbers of active user processes.\n\n
\nThis file is used to collect non-static information about network mail transmissions\n\n
\nThis file holds the site parameters for MailMan.\nIt may have only one entry - the domain name of the installation site.\nSome parameters are defined by the systems manager during installation.\nOthers may be edited subsequent to installation. The parent domain,\nset to FORUM during initialization, may be changed. Audit parameters may\nbe established.\n\n
\nMailMan Time Zones are used to calculate the time in the time zone a\nreceiving domain is in for a message coming in from a different time zone.\nTherefore times can be expressed in EST (Eastern Standard Time) even\nif they were originally formed in PST (Pacific Standard Time).\n\n
\nThis file is not currently in use by MailMan.\nIt is still distributed because there may be\nlocal sites that have software that uses it.\n\n
\nThe system manager can input partial or full matches to network addresses\ninto this file. When Network mail receives a message from a sender that\ncontains the string input, that message will be rejected. This file can\nbe used to prevent spam or nuisance messages from being received from a\nremote site.\n\n
\nTransmission scripts are lists of script commands that are executed by\nthe script processor for Network Mail transmissions in order when they\nare invoked. The command in a Script that invokes a transmission\nscript is the CALL. Therefore 'C KERNEL' invokes a script that\ninterfaces with the SMTP (Simple Mail Transfer Protocol) process using\nthe SCP (Simple Communications Protocol). Transmission scripts are\nused most often to invoke a portion of a longer script that is used in many \ndifferent domains. It can then be used in many different domains.\n\n
\nThis file contains the Outpatient Visit records (Routing Sheet\nrecords) which are transmitted to Austin DPC.\n\n
\nThis file contains the field name(s) and number(s) which is/are\nrequired and was/were found to be invalid. Once the invalid\ndata is entered the entry will be automatically purged from the\nfile. Accurate reporting on the Amis 223 is dependent on the\nmaintenance of this file utilizing the "OPC MENU" option\nin the SD module.\n\n
\nThis file is used to record institutional holidays. It is referenced\nby the XUWORKDY routine. It is not distributed with data. It is\ncross-referenced by date.\n\n
\nThis file stores the list of current tele health stop codes. The Tele \nHealth Management Platform (TMP) uses this file to identify tele health \nclinics as part of the TMP real time updates. TMP is monitoring the \nHospital Location File (#44) for edits to tele health clinics. These \nedits are sent to TMP in real time in order to keep TMP in sync with each \nVistA system. \n\n
\nThis file contains the Medical Center Divisions which are defined\nusing the 'MAS Parameter Entry/Edit' option. The primary facility\nas well as any NHCU, Domiciliary or other division should be\ndefined within this file.\n\n
\nThis contains the user's preferences to be used as defaults.\n\n
\nThis table file contains the scheduling events.\n \nIf an entry needs to be added, modified or deleted a patch will be issued\ninstructing the site how to make the change. Otherwise, this table should not\nbe edited in anyway by the site.\n\n
\nThis table file contains the scheduling reasons.\n \nIf an entry needs to be added, modified or deleted a patch will be issued\ninstructing the site how to make the change. Otherwise, this table should not\nbe edited in anyway by the site.\n \nScheduling Reason event code 'HL-S15' entries in this file correspond to the\nentries in the Cancellation Reasons file (#409.2).\n\n
\nThis table contains the standard team positions used by PCMM.\n \nSites are NOT allowed to edit this file's fields via FileMan, without \nthe direction of DHCP Customer Support. Deleting, changing, or adding \nentries to this file may result in faulty performance of the Primary \nCare Management Software or other DHCP software that uses this file.\n \nEach Team Position entry must map to one of these standard roles.\n \nSites are NOT allowed to edit the structure of this file. Making any \nkind of revision to this file may result in a faulty performance of the\nPrimary Care Management Software or other DHCP software that uses this \nfile. Updates to this file should only be done as a result of an \nofficial patch to the Scheduling Module.\n\n
\nThis standard table contains the list of roles/purposes of a team.\n - Super-Team (group)\n \nExamples:\n - Primary Care\n - Inpatient Ward\n - Mental Health Treatment\n - Rapid Response\n - Community Care\n - Special Treatment Program\n\n
\nThis file contains records for all active Recall Reminders. Once a \npatient has called to make an appointment, the entry is then moved\nfrom this file to RECALL REMINDERS REMOVED file. Patients should not be\nentered into this file when their future appoitment is less than 30 days.\nThe records are maintained by Recall Date and patient name.\n\n
\nThis file contains the Recall Types that a Recall Coordinator has created \nfor their hospital. The recall type is asked during creation of a Recall \nentry for a patient. \n\n
\nThis file will contain all the clinics which will be using Recall Reminder\nand have decided to use Recall Letters. There is a wordprocessing field \nwithin this file that can be designed for each clinic.\n\n
\nThis file contains what type of Recall notification should be used. It \nholds various settings for each entry.\n\n
\nThis file will contain all Providers who have been entered into the \nRecall Reminder application. Entries in this file must be in the New \nPerson file first.\n\n
\nThis file contains Recall Reminder Teams, which can be entered for \nspecialty areas or physical location. Entries in the file will be used \nwhen setting up a Recall Provider.\n\n
\nThis file holds records deleted from the RECALL REMINDERS [#403.5]\nfile, whether deleted by the user or because they were given appointments.\n\n
\nThis table contains outpatient related information for a patient.\nFor example, it contains computed fields that indicate the current\nprimary care team, positions and practitioner assigned to the patient.\n\n
\nThis table contains a history of the teams that\nthe direction of DHCP Customer Support. Deleting, changing, or adding \nentries to this file may result in faulty performance of the Primary \nCare Management Software or other DHCP software that uses this file.\nhave been assigned to the patient over time.\nSites are NOT allowed to edit the structure of this file. Making any \nkind of revision to this file may result in a faulty performance of the\nPrimary Care Management Software or other DHCP software that uses this \nfile. Updates to this file should only be done as a result of an \nofficial patch to the Scheduling Module.\n \nSites are NOT allowed to edit this file's fields via FileMan, without \n\n
\nThis file contains a history of positions that have been assigned\nthe direction of DHCP Customer Support. Deleting, changing, or adding \nentries to this file may result in faulty performance of the Primary \nCare Management Software or other DHCP software that uses this file.\nto the patient.\nSites are NOT allowed to edit the structure of this file. Making any \nkind of revision to this file may result in a faulty performance of the\nPrimary Care Management Software or other DHCP software that uses this \nfile. Updates to this file should only be done as a result of an \nofficial patch to the Scheduling Module.\n \nSites are NOT allowed to edit this file's fields via FileMan, without \n\n
\nThis is the parameter file for PCMM. There should be only one entry in this\nfile. The IEN of this entry must be 1. If other entries are added and the\ncode not adjusted PCMM will not function properly. This file should only be\nupdated or modified with the help of NVS or a PCMM developer.\n\n
\nThis file contains the PCMM server patches that have been issued since\nSD*5.3*177. Data in this file will be adjusted by new patches and KIDS builds.\nThis file should not be edited by the site unless specifically instructed by\nthe CIOFO.\n\n
\nThis file contains a list of the PCMM client versions that have come out since\nSD*5.3*177. Data in this file will be adjusted by new patches and KIDS builds.\nThis file should not be edited by the site unless specifically instructed by\nthe CIOFO.\n\n
\nThis file contains a log of all PCMM HL7 Transmissions that have\noccurred at the medical center. It is also used to track PCMM\nHL7 Transmission errors that have been transmitted back to the\nmedical center from the Austin Automation Center (AAC).\n \nThe data in this file is maintained by the PCMM software module\nand should not be altered.\n\n
\nThis table file contains a list of all error codes that the Austin\nAutomation Center (AAC) will report when processing PCMM HL7\nTransmissions.\n \nThis table should not be edited in anyway by the site. If an entry in this\nfile needs to be to be added, modified or deleted; a patch will be issued\ninstructing the site how to make the change.\n\n
\nTrack patients that need their primary care data transmitted to Austin.\n\n
\nThis is a local table file containing the site's names for teams.\nteam. Teams can be setup as primary care teams or service specific teams.\n \nSuper-teams can be setup as a group of teams.\n\n
\nThis table holds the history of which users were assigned to each\nthe direction of DHCP Customer Support. Deleting, changing, or adding \nentries to this file may result in faulty performance of the Primary \nCare Management Software or other DHCP software that uses this file.\nTeam Position and when.\nSites are NOT allowed to edit the structure of this file. Making any \nkind of revision to this file may result in a faulty performance of the\nPrimary Care Management Software or other DHCP software that uses this \nfile. Updates to this file should only be done as a result of an \nofficial patch to the Scheduling Module.\n \nSites are NOT allowed to edit this file's fields via FileMan, without \n\n
\nThis table holds the history of which preceptor positions were assigned to\nto this file may result in faulty performance of the Primary Care\nManagement Software or other DHCP software that uses this file.\neach Team Position and when. Sites are NOT allowed to edit the structure\nof this file. Making any kind of revision to this file may result in a\nfaulty performance of the Primary Care Management Software or other DHCP\nsoftware that uses this file. Updates to this file should only be done as\na result of an official patch to the Scheduling Module.\n \nSites are NOT allowed to edit this file's fields via FileMan, without the\ndirection of DHCP Customer Support. Deleting, changing, or adding entries\n\n
\nThis file tracks patient events of interest to PCMM.\n \nFor patient death events, the file is updated by the DG FIELD MONITOR\nevent driver executing the SCMC PCMM INACTIVATE ON DATE OF DEATH event\nprotocol.\n\n
\nThis table contains the practitioner and administrative positions associated with a Team.\n\n
\nThis file is a logical multiple of the TEAM File (#404.51). It contains\nthe direction of DHCP Customer Support. Deleting, changing, or adding \nentries to this file may result in faulty performance of the Primary \nCare Management Software or other DHCP software that uses this file.\nthe history of activations and inactivations for the team.\nSites are NOT allowed to edit the structure of this file. Making any \nkind of revision to this file may result in a faulty performance of the\nPrimary Care Management Software or other DHCP software that uses this \nfile. Updates to this file should only be done as a result of an \nofficial patch to the Scheduling Module.\n \nSites are NOT allowed to edit this file's fields via FileMan, without \n\n
\nThis is the log file of the statuses of the team positions. Primarily,\nSites are NOT allowed to edit this file's fields via FileMan, without \nthe direction of DHCP Customer Support. Deleting, changing, or adding \nentries to this file may result in faulty performance of the Primary \nCare Management Software or other DHCP software that uses this file.\nthis is used to determine if a position is active for a certain time\nperiod.\nSites are NOT allowed to edit the structure of this file. Making any \nkind of revision to this file may result in a faulty performance of the\nPrimary Care Management Software or other DHCP software that uses this \nfile. Updates to this file should only be done as a result of an \nofficial patch to the Scheduling Module.\n \n\n
\nThis file contains Stop Codes used by Mental Health to produce reports \nwithin PCMM. The following report uses this file to produce output:\n \n MH Encounter Report [SCMC MH PCMM ENCOUNTER RPT]\n \nFuture updates to this file will be handled through the National Patch \nRelease Module.\n\n
\nThis file contains the scheduling parameters.\n\n
\nThis file contains the definitions for hard coded scheduling reports\n\nAlso, where possible, a default value is specified that is used\nwhen first displaying the prompt.\n\nthat are available to the user on a client workstation.\n\nThese definitions are pre-determined and must not be modified unless\nexplicitly instructed as part of a patch or module upgrade.\n\nThe parameters specified in each report definition are used by the\nclient application. The parameters indicate what prompts are presented\nto the user, which prompts are required as part report criteria.\n\n
\nThis file contains the field definitions used by the SCHEDULING REPORT\nDEFINITION (#404.92) file. Including a field in the report definition\nmeans that the field is presented to the user as part of the report \ncritieria. This file defines the relationship between the field and\na GUI component.\n\nThese field definitions are pre-determined and must not be modified unless\nexplicitly instructed as part of a patch or module upgrade.\n\n\n
\nThis file defines specific scheduling report groups. Each report\n\ndefinition in the SCHEDULING REPORT DEFINITION (#404.92) is assoicated\nwith a report group.\n\nThe report group allows the easy display of related report definitions\nto the user for selection.\n\nThese groups are pre-determined and must not be modified unless\nexplicitly instructed as part of a patch or module upgrade.\n\n
\nThis file stores report criteria specifications used to print\nwho created it. Public templates can be used by anyone but can\nonly be edited by the template creator. However, another user can copy\nand edit a public template specification by using the 'Save As...' command.\n\nTemplates are only available on client workstation.\nreports defined in the SCHEDULING REPORT DEFINITION (#404.92) file. \n\nThese user-defined templates can then be access by the user, eliminating\nthe need to specify the criteria each time a report needs to be executed.\n\nThe user can created/edit/copy/delete his or her own templates. The user\ncan also specify whether the template is a 'personal' or\n'public' template. Personal templates can only be used by the user\n\n
\nThis file contains Conversion Specification Templates (CST) that\n 4) Error logs\n 5) Conversion event start/stop parameters\n 6) Estimate statistics\n 7) Record creation statistics\n\nThe database conversion logic utilizes and updates the information stored in\neach CST. \nare used by the ACRP Database Conversion (SD*5.3*137). These templates\nallow management of the conversion process to meet the needs of the\nindividual site.\n \nEach template contains the following:\n 1) Start and End dates for encounters to be converted\n 2) Event logs (estimate, convert, re-convert)\n 3) Action logs (schedule, stop, re-start) \n\n
\nThis file holds the data for all admissions, transfers, discharges,\n ^DGPM("APTT"_TT,DFN,Date_AS,DA)=""\n ^DGPM("APCA",DFN,Corresponding Admission,Date_AS,DA)=""\n ^DGPM("APMV",DFN,Corresponding Admission,Inverse Date_AS,DA)=""\n ^DGPM("APRD",DFN,Date_AS,DA)=""\n ^DGPM("AMV"_TT,Date_AS,DFN,DA)=""\n ^DGPM("ATS",DFN,Corresponding Admission,Inverse Date_AS,Treating Specialty,DA)=""\n ^DGPM("CN",External Format of Ward,DA)="" **inpatients only**\n ^DGPM("LD",External Format of Ward,DA)="" **lodgers only**\n ^DGPM("ARM",IFN of Room-bed,DA)=1 or 0 [1 indicates lodger, 0 indicates non-lodger]\n ^DGPM("B",Date,DA)=""\ntreating specialty changes, and lodger movements. These entries must not\n ^DGPM("C",DFN,DA)=""\n ^DGPM("CA",Corresponding Admission,DA)=""\n \nwhere: TT=Transaction type where choices are as follows:\n 1=admission 4=check-in lodger\n 2=transfer 5=check-out lodger\n 3=discharge 6=specialty change\n \n AS=ASIH Sequencewhere choices are as follows:\n 1=transfer to hospital ASIH\nbe edited through fileman. Instead, the appropriate bed control options\n 2=Admission to hospital (automatically generated by module)\n or 1=discharge from hospitalwithin 30 days of ASIH stay\n 2=transfer to or discharge from NHCU/DOM (automatically generated by module)\n [NOTE: This value is 0 for non-ASIH movements or ASIH movements where there are not 2 movements at the same date/time]\n \nshould be executed to insure data consistency.\n \nThe following cross-references exist on this file:\n ^DGPM("ATID"_TT,DFN,Inverse date_AS,DA)=""\n ^DGPM("ATT"_TT,Date_AS,DA)=""\n ^DGPM("APID",DFN,Inverse Date_AS,DA)=""\n\n\nThis file contains all allowable admission, discharge, transfer,\nspecialty change, check-in lodger, and check-out lodger movements.\nThese are site determined and site maintained. However, we STRONGLY\nrecommend that when updating movement types, you utilize the 'Edit\nBed Control Movement Types' option to ensure all data is properly\nupdated.\n\n
\nThis file holds all MAS accepted/approved movement types. All entries in\nyou FACILITY MOVEMENT TYPE FILE (file 405.1) must point to an entry in this\nfile. This file is distributed by MAS and should NOT be altered by any\nfacility. Altering this file can severely corrupt the integrity of your\nbed control movement options. The internal entry numbers of this file are\nused by various packages to determine the processing necessary. These\nnumbers and entries must remain as distributed by the MAS package.\n\n
\nThis file holds all type of movement transactions. The data in this file is\ndestributed with the MAS package and must NOT be altered in any way. There\nare currently 6 entries in this file:\n 1 ADMISSION\n 2 TRANSFER\n 3 DISCHARGE\n 4 CHECK-IN LODGER\n 5 CHECK-OUT LODGER\n 6 SPECIALTY TRANSFER.\n\n
\nThis file contains all room-beds found at your site as well as data\nabout our-of-service periods for those beds. This file is maintained\nby the site.\n\n
\nThis file contains the VACO-approved reasons a room-bed or ward may be\nplaced out-of-service. These entries must not be altered in any way.\nThe internal entry numbers and the entries themselves have been added\nunder the direction of MAS VACO and are the only approved reasons for\nplacing wards and beds out-of-service. Altering of this data in any\nway can have severe and negative impacts on the operations of many DHCP\npackages.\n\n
\nThis file contains all site-determined descriptions for a room-bed.\nExamples are 'PRIVATE ROOM', 'NON-SMOKING', etc. This file is\nmaintained by the site.\n\n
\nThis file holds all site determined reasons why a patient may be lodged\nat a facility.\n\n
\nThis file contains all letters that may be sent out by a site. These\ninclude letters notifying patients of future appointments, cancelled\nappointments, and scheduled admissions. The site can edit the text that\nthey would like to appear in these letters.\n\n
\nThis file holds the types of letter, e.g. Pre-Appointment, No-Show, etc.\nThe Letter file points to this file.\n\n
\nThis file contains the names of the transmission routers or destination\npoints that data will be electronically transmitted to. It holds the\nspecific information connected with each router, eg. lines per message.\n\n
\nThis file holds the discretionary workload reports.\n\n
\nThis file contains all acceptable relationships for persons contained in the\nPATIENT RELATION file. These relationships are provided by MAS VACO for use\nin the income screening and means test portions of the MAS software. They\nmust NOT be altered in any way at the site level. No entries may be added,\nedited, or removed from this file.\n\n
\nThis file contains all relations of a veteran, including the veteran\n \nThis file relates all relations for a veteran to the veteran. These\nrelations are date sensitive and can be activated and inactivated.\n \nData in this file is utilized by the income screening and means test\nportions of MAS. It should be edited through those applications and\nnot through direct access through VA FileMan.\nhimself/herself. Demographic data (name, SSN, date of birth, and sex)\ncan be found in either the PATIENT file (if the relation is a veteran)\nor in the INCOME PERSON file (if the relation is not a veteran). A\nsingle individual may be entered in this file more than once of that\nindividual is related to more than one veteran. An example would be\na spouse that was a veteran. One entry would exist for the veteran\nhimself and one as the husband of his veteran wife. This would also\nhold true for children of two veteran parents.\n\n
\nThis file contains demographic information (name, social security number,\ndate of birth, and sex) for non-veteran relations of patients seen at this\nfacility. This information is collected for use in the means test and\nincome screening modules of MAS. This data will also be used for\nIVM (Income Verification Matching) with the IRS (Internal Revenue Service).\n\n
\nThis file contains the individual annual income for a veteran\nand any applicable relations. This income information is\nused in registration and means test.\n\n
\nThis file contains the income relation type data for a veteran\nand any applicable relations. This relation type information is\nused in registration and means test.\n\n
\nThis file contains the annual financial tests for a veteran.\n\n
\nThis file contains the statuses associated with the means test.\n\n
\nThis file contains the types of test assoicated with financial data\ncollected.\n\n
\nThis file contains a list of the various sources from which an income test\nmay originate. This would include the VAMC if the means test was\nadministered by a user or IVM if the income was verified by the Income\nVerification Match Center.\n \nThis file, and the data contained within the file, is strictly maintained\nand should not be altered at the site level. Editing of this file or the\ndata contained within may result in data corruption or may cause software\nto malfunction.\n\n
\nThe MEANS TEST CHANGES file is a file which tracks certain types of actions\nto a means test. Such actions which lead to an entry in this file are\nadding a means test, edits to a means test, changing a means test category,\nadjudicating a means test.\n Entries are automatically added to this file as an event to an action\non a means test.\n A deletion of a means test will result in the deletion of any changes\npreviously recorded in this file for the patient and date of means\ntest being deleted.\n\n
\nThe MEANS TEST CHANGES TYPE file contains the types of changes which\ncan be made to a means test. This is a table file. The types of changes\nwithin this file are selectable only if active.\n The MEANS TEST CHANGES file points to this file.\n\n
\nThis file contains a list of reasons that can be selected when a user is \ncreating a patient that either does not want to be enrolled for VA care \n(Registration only) or is a Collateral patient.\n\n
\nThese are the valid appointment types to be used in Scheduling as determined by the MAS SIUG. This file should not be altered in ANY fashion unless so directed by the ISC.\n\n
\nThis file contains the cancellation reasons to be used in the Scheduling\nPackage. The MAS SIUG determined the allowable reasons. This file should\nnot be added to or have entries deleted from it.\n\n
\nThis file contains the Wait List entries for the Wait List (Sch/PCMM) \npackage. Each entry represents a unique wait list entry.\n\n
\nThis file contains the list of DSS Identifiers that can be used by an \ninstitution in the Wait List (Sch/PCMM) package as a Service/Specialty. \nEach DSS ID is assigned an institution, date activated and date \ninactivated. The Service/Specialty represents a collection of clinics \nthat have this DSS ID as the primary stop code that a patient is waiting \nfor an appointment.\n\n
\nThis file contains the list of Clinics that can be used by an\ninstitution in the Wait List (Sch/PCMM) package. The clinic must be an \nactive clinic in the Hospital Location file. Each entry in this file will \ncontain a wait list activation date and inactivate date. \n\n
\nThis table file contains types of outpatient classifications. \nThese include Service Connected, Agent Orange Exposure, Ionizing\nRadiation Exposure and Environmental Contaminants.\n \nIf an entry needs to be added, modified or deleted a patch will be\nissued instructing the site how to make the change. Otherwise,\nthis table should not be edited in anyway by the site.\n\n
\nThis file contains outpatient classifications associated with outpatient\nencounters.\n\n
\nThis file contains outpatient diagnoses associated with outpatient\nencounters.\n\n
\nThis file contains outpatient providers associated with outpatient\nencounters.\n\n
\nThis table file contains stop codes exempted from the outpatient\naccomplished only by maintenance patches. Creating new Stop Codes or \nlocal codes, and/or editing fields in the file are not permitted.\nclassification questions.\n \nThis file has been "Locked Down" so that FileMan and other user updates \nare not allowed. Changes may be made only through HPS Administrative \nSustainment Support (formerly VistA Maintenance) patches coordinated with \nthe Office of Community Care - Policy and Planning. The file definition \n(data dictionary) shall not be modified. All additional, changes, \ninactivations, and reactivations to entries in the file shall be \n\n
\nThis file contains a list of encounters which were selected for review \nbased on a comparison of the ICD diagnosis codes from the encounter and\nthe VBA rated disabilities (VA) codes from the patient. Entries will be\nedited as necessary per the review criteria established for determining\nif an encounter is service-connected (SC) or non-service connected (NSC).\n\n
\nUnscheduled clinic stop codes and Ambulatory Procedures stored here.\n\n
\nThis file provides a linkage between the scheduled appointment\nidentifiers: DFN-Appointment Date/Time-Clinic IEN and the PFSS ACCOUNT\nFile (#375). Indexes allow the lookup of the PFSS Account Reference by\nusing the appointment identifiers.\n\n
\nThe Patient Appointment Information Transmission (PAIT) log is maintained \nin this file. Log entries are added when appointment information is \ntransmitted to the Austin Automation Center via HL7 messages. File \nentries are deleted automatically when HL7 acknowledgments are received.\n\n
\nThis file contains entries defining list attributes that are\nused by the Scheduling List Manager utility. The application developer\nadds entries in this file for each list of items to be\ndisplayed using the List Manager.\n\n
\nThis table file contains entries that describe appointment\na current status associated with that group are then displayed.\n \nIf a group needs to be added/modified/deleted, a patch will be\nissued instructing the site how to make the change. Otherwise,\nthis table file should not be edited in any way by the site.\ncategories/groups. An APPOINTMENT STATUS(#409.63) file entry can be\nassociated with one or more of these groups This relationship is defined\nby the ASSOOICATED GROUPS(#100) multiple of that APPOINTMENT\nSTATUS file.\n \nThe SDAM APPT MGT (Appointment Management) option of the Scheduling\npackage uses this association. In that option, the user is allowed to\nselect which 'group' of appointments to view. Appointments with\n\n
\nThis table file contains the list of valid statuses for an\nappointment. \n \nIf an entry needs to be added/modified/deleted, a\npatch will be issued instructing the site how to make\nthe change. Otherwise, this table file should not be edited\nin any way by the site.\n\n
\n This table contains the query object definition for a specific database\n file supported by a custodial package. This definition specifies any specific\n mehtods and properties that are needed beyond the generic methods and\n properties available.\n \n Using this query object interface, custodial packages can allow access\n to internal data entries to other packages without direct global access\n and integration agreements.\n \n\n
\nThis log file contains entries that track the execution of the\n o USER\n \nThe date and time the update process completed is logged at the finish\nof the update process in the DATE LAST UPDATE COMPLETED field. If\nthis field is missing at the time of OPC generation, the user will be\nwarned that the update process has not completed. OPC generation can\ncontinue, however.\n \nAt the end of the OPC generation process, the OPC GENERATED DATE field\nwill be logged only if the DATE LAST UPDATE COMPLETED is present.\nappointment status update process. An entry is added/modified\nIf the OPC GENERATED DATE field is not present then OPC\ntransmission will not be allowed for the appointment date.\nfor each date that has been processed. The SDAM BACKGROUND JOB and\nthe SDAM APPT UPDATE options create the entries.\n \nThe following fields are entered at the beginning of the update process:\n o APPOINTMENT DATE\n o UPDATE METHOD (background or manual)\n o DATE LAST UPDATE STARTED\n\n
\nThis table file contains the list of transaction types that\ncan occur against an appointment. For example, when an \nappointment is cancelled, the CANCEL transaction type occurs.\n \nIf a transaction type needs to be added/modified/deleted, a patch\nwill be issued instructing the site how to make the change. Otherwise,\nthis table file should not be edited in any way by the site.\n \n\n
\nPointer file for grouping HOSPITAL LOCATION records for various purposes.\n\n
\n This file contains all outpatient encounters since 10/1/93 that have been\n \n If the encounter has been no-showed or cancelled then it will NOT be\n in this file.\n \n Inpatient encounters will always have a status of 'INPATIENT APPOINTMENT'.\n \n Appointments made for non-count clinics will always have a status of\n 'NON-COUNT'.\n \n All other encounters will have a status of 'CHECKED OUT'.\n successfully checked out or need to be checked out. The types of\n \n\n encounters that caused entries to be added to this file are appointments,\n add/edit stop codes and dispositions.\n \n If the encounter needs to be checked out then it will have a status\n of 'PENDING ACTION'. The site will not receive workload credit if\n the status remains 'PENDING ACTION'. 'PENDING ACTION' includes both \n 'ACTION REQUIRED' and 'NO ACTION TAKEN' statuses.\n\n
\nThis file will contain the current transmission status of all Outpatient\n \nThis file does not contain the transmission history for an encounter.\nEncounters and Deleted Outpatient Encounters that have been transmitted or\nrequire transmission to the National Patient Care Database.\n \nEntries in this file are only created when an existing entry for the\nspecified encounter does not exist. When an Outpatient Encounter is\ndeleted, the entry in this file that pointed to that Outpatient Encounter\nis modified so that it points to the Deleted Outpatient Encounter that was\ncreated.\n\n
\nThis file will contain all encounters that have been deleted.\n\n
\nThis file contains all errors that the National Patient Care Database\nreported when processing an encounter.\n \nWhen an encounter is transmitted to the National Patient Care Database,\nall errors that my have occurred previous to that transmission are\ndeleted.\n\n
\nThis table file contains a list of all error codes that the National\nPatient Care Database will report when processing an encounter.\n \nIf an entry needs to be added, modified or deleted a patch will be issued\ninstructing the site how to make the change. Otherwise, this table should\nnot be edited in anyway by the site. \n\n
\nThis file will contain the transmission history of all Outpatient\nEncounters and Deleted Outpatient Encounters that have been transmitted to\nthe National Patient Care Database.\n\n
\nThis is where Versions and Builds are recorded for Clinic Scheduling.\n\n
\nThis is where Access Groups are defined.\nThese Groups are sometimes termed as 'department'.\nThese are used to 'group' access types to tie together a group of \nResources that may be selected from.\n\n
\nThis is where Access Types are defined.\nThe Resource object points to this file.\nThis is where the Group (or department) \nis linked to a resource and where the colors are\ndefined for the calendar.\n\n
\nThis is where Access Groups and Access Types are paired together.\nThis is used to group Resources.\n\n
\nThis is where a Resource object is defined for Clinical Scheduling.\nA Resource Object can be a NEW PERSON, HOSPITAL LOCATION, or an SDEC \nADDITIONAL RESOURCE.\nA Resource is linked to a HOSPITAL LOCATION (or Clinic).\n\n
\nThis is where Resources are 'grouped' with other Resources.\n\n
\nThis is where a NEW PERSON user is linked to a Resource (SDEC RESOURCE).\nThe user's ability to Overbook, Modify Schedules, and \nmodify appointments are defined here.\n\n
\nThis file is as used a source file for items that are to be defined as a \nresource, but do not fit into a typical Resource source file.\nSDEC RESOURCE points to this file.\n\n
\nThis is where appointment definitions are linked to a resource.\n\n
\nThis file is comprised of the various different appointment CHECK-IN\nSTEP STATUSes that are referenced by the applications that utilize it.\n\n
\nThis is where Patient Preferences are defined for Patients.\n\n
\nThis file contains the SDEC Appt Request entries for the Appointment \nScheduling application.\nEach entry represents a unique appointment request.\n\n
\nThis file contains the disposition reasons to be used in the Scheduling\nPackage and the VS GUI. The MAS SIUG determined the allowable reasons.\n \nThis file should NOT be edited in anyway by the site. \n\n
\nThis file is used by the VSE VS GUI. The file contains patient contact\ninformation regarding appointment follow up each time a patient is\ncontacted. This file should not be edited using Fileman, the file is\nupdated using the VSE VS GUI.\n\n
\nThis file stores standard appointment cancellation comments used by VS \nGUI. Comments consist of hash tags (abbreviations) and their associated \ntextual equivalent.\n\n
\nThe SDEC Stop Code file (#409.89) contains Stop Codes and their associated\nName, Type (P-Primary, M-Mental Health, S-Special Care) and Active flag. \nIt is used to calculate Mission Act Eligibility.\n\n
\nThis file contains user defined parameter specification templates for\nthe 'ACRP Ad Hoc Report' [SCRPW AD HOC REPORT]. Because template\nintegrity may be adversely affected, records in this file should not be\ncreated or edited directly through Fileman.\n\n
\nThis file contains the parameters necessary to manipulate the various data\nelements used by the 'ACRP Ad Hoc Report' [SCRPW AD HOC REPORT].\n \n *** THE CONTENTS OF THIS FILE SHOULD NOT BE EDITED ***\n\n
\nThis file is used to hold the error codes returned to the user interface \nor web application.\n\n
\nThe SDEC SUBSPECIALTY file (released in SD*5.3*896) will contain both \nsecondary and tertiary subspecialties that can be associated with clinics \nin the new multiples, SECONDARY SUBSPECIALTY (#301) and TERTIARY \nSUBSPECIALTY (#302), in the HOSPITAL LOCATION (#44) file. Those multiple \nfields will point directly to this SDEC SUBSPECIALTY file.\n\n
\nThis file defines which encounter forms to use for a particular clinic.\nalong with the encounter forms. The idea is that for each appointment a\npacket of forms can be printed, saving the effort of collating the forms\nmanually.\n \nAlso, this file can be used to define other forms or reports to print,\nalong with the encounter forms. The idea is that for each appointment a\npacket of forms can be printed, saving the effort of collating the forms\nmanually.\nfirst time patients, and one for all patients.\n \nAlso, this file can be used to define other forms or reports to print,\n\n
\n \n \nThis file allows the user to specify reports or forms that should print in\naddition to the encounter forms for the entire division . Only reports\ncontained in the Package Interface file can be specified. The user can\nalso specify the conditions under which the report should print. The\nintent is to print packets of forms that do not require manual collation.\n\n
\nThe SD Audit Statistics file contains counts of activities performed by a \nscheduler on a date. The statistics are compiled early each morning by \nthe audit statistics compiler routine (SDECAUD) from data in files 403.5, \n409.3, 409.84 and 409.85."\n\n
\nThere are two records in the SDEC Settings file. One stores national \nsettings for VS GUI. The other stores local settings for VS GUI. \nNational settings will be updated via VistA patch. Local settings will \nbe updated at each VAMC using FileMan.\n \nThe two records in this file should never be deleted.\n\n
\nThis file contains data concerning patients scheduled for a\nfuture admission to the medical facility.\n\n
\nThis file contains the history of changes to patient information \nthrough the pre-registration process. Currently only the date and\ntime of the change, and the user making the change are maintained.\n \nThis file maintains a record of changes to patient demographic information\nthrough the pre-registration process and should not be purged.\n\n
\nThis file contains a list of patients to be called as part of the \nPre-Registration process.\n \n*** NOTE ***\nThis file SHOULD NOT be edited directly. Field values need to be\nentered by the background job, or the Add to Call List Option.\nEditing this file directly can result in erroneous data being displayed\nin the Call List.\n\n
\nThis file stores a log of call attempts to patients being called for \npreregistration.\n\n
\nThis file contains the statistical data necessary for each ward to\ncreate the daily G&L and bed status reports. The data contained\nin this file is also utilized to compile a wide assortment of MAS\nAMIS segments.\n\n
\nThis is the main file in the Control Point Activity package. It contains\ninformation concerning each and every control point transaction. There\nare four basic transaction types: Ceiling, Obligation, Adjustment and\nCancelled. Each transaction type has a set of fields in this file that\nrelate to it. Some fields relate to all four transaction types. This\nfile should only be edited through the Control Point Activity package.\n *********DO NOT RE-INDEX THIS FILE**********\n\n
\nThis file keeps track of the last sequential number used for each \ntransaction number series. A transaction number series consists of the\nfollowing elements separated by hyphens: Station Number - Fiscal Year -\nControl Point Number.\n\n
\nThis file is a list of request types. Control Point Activity users have\nlaygo access to this file and will populate it as they use the Control\nPoint Activity package.\n\n
\nThis file is used to build a list of repetitive (purchase request card type)\nitems. The Control Point Clerk can then generate requests automatically\nfrom the entries in this file. At the time requests are generated, the items\nare pre-sorted by vendor before being entered in the Control Point Activity\nfile as requests.\n\n
\nThis file contains the names of sub-control points used by Control Point\nClerks and Control Point Officials to sub-divide the funds allocated to\nthem by Fiscal Service. Entries in this file are established by entering\na new sub-control point name in the Sub-Control Point field of the\nControl Point Activity file (#410).\n\n
\nThis file contains the type of Control Point Activity form types.\nFor each type of form, certain transaction data is required when\ncreating and editing a request.\n\n
\nThis file contains all of the delivery schedules for items\nPoints is totaled and the Sub-Control Point Multiple of the request\nis updated with the Sub-Control Point and its associated dollar amount.\nIf the distributed quantities and the request's transaction dollar\namount matches, then entry into the Sub-Control Point Multiple\nis not required. When the Control Point Official signs the\nrequest, this delivery schedule's Sub-Control Point dollar amount\ndistribution updates the Sub-Control Point Balance.\nthat the Control Point wishes to distribute on a request.\nFor each item of a request, they can distribute by date, \nquantity, Sub-Control Point and/or Delivery Point. This file\ncontains all delivery schedules for each item of a request for\na repetitive, non-repetitive or a non-repetitive/repetitive\nform type. If the Sub-Control Point is entered, the dollar\namount of the item's cost is calculated for that Sub-Control \nPoint and all delivery schedules' cost distribution to Sub-Control \n\n
\nThis file contains the Control Point's Sort Group. This is\nused as a sorting mechanism of requests to categorize their\nparticular or specific cost distribution. Each Control Point\nspecifies a particular Sort Group and only sees their Sort\nGroup. \nThis is one of the files that is pointed-to from the Sort Group\nfield of the Control Point Activity File (#410). The other file\nthat the Sort Group field points to is the Engineering Work Order File.\n\n
\nThis file contains the multiple delivery schedule\nDelivery Points under the request's item multiple.\nThis is any reference that the Control Point wishes\nto enter.\nThis entry can be a room, building, location, or\npoint that particular items will be delivered or\ndistributed by the Control Point.\n\n
\nThis file contains a list of officially approved authorities for 1358 \ncreation. Entries in this file are populated via national patches only, \nno data should be entered, edited or deleted within this file.\n \nPer VHA Directive 2004-038, this file should not be modified.\n\n
\nThis file contains parameters that allow each Site to tailor the IFCAP\nsystem to meet their needs. Use of this file also allows the users to\nrun multiple, independent stations on a single computer.\n\n
\nThis temporary file will be replaced by new fields on the Institution\nFile. It is used only for printing the facility type on IFCAP generated\nforms and reports (such as Purchase Orders and Receiving Reports).\n\n
\nThis file contains information pertaining to incorrectly converted\nFMS VENDOR UPDATE. This file is populated during the IFCAP \nvendor conversion process when a record can not be properly converted.\nproperly converted.\n\n
\nTHIS FILE CONTAINS A LIST OF ERROR MESSAGES. RATHER THAN BURYING THE\nERROR MESSAGES IN SOME ROUTINE, THE MESSAGES ARE AVAILABLE HERE TO\nREVIEW OR CHANGE.\n\n
\nThis file will contain entries that are not site specific for IFCAP.\nEntries are specific to the computer that is running IFCAP.\n\n
\nThis file will contain the non-expendable equipment requests\nfor all stages of the request process.\n\n
\nThis file contains all turn-in requests, both those requests\nthat are created because non-expendable equipment is being replaced\nor non-expendable equipment is no longer to be used.\n\n
\nThis file is for designating the members of the Equipment Committee\nwho meet and decide on non-expendable equipment requests.\n\n
\nThis file contains a list of users that are frequently used as\nconcurring officials for equipment requests.\n\n
\nThis file contains codes that indicate that certain items may need\nto have special handling.\n\n
\nThis file contains all of the different statuses that a equipment\nrequest or turn-in request may have.\n\n
\nThis file is used to create temporary transaction numbers for each\nrequest. The structure is SITE #-CMR #-FYR-SEQUENTIAL NUMBER.\n\n
\nThis file retains data that is normally deleted from IFCAP files. The\ndata held in this file will be retained for a brief period of time (TBD)\nand purged after this retention period.\n \nIt holds data that is specifically related to interface of IFCAP package\nto DynaMed (an outside entity).\n\n
\nIn the event that an external system needs to be notified when an event \nof some type occurs, a publish/subscribe interface allows messages to be \nsent to that system when the event occurs. This file contains a list of \nactive subscriptions, and records are added or deleted in response to \n"subscribe" or "cancel" messages received from the external system. More \nthan one type of subscription is supported.\n\n
\nThis file is use to store checksums associated with objects such as file \nrecords. The reason for this level of generality is that it is at times \nconvenient to associated a checksum with a subset of fields in a file (or \npossibly other objects). This means it may be necessary to support more \nthan one checksum on the same file or other type of object class.\n\n
\nThis file is designed to hold the various types of transactions that support\ncommunication for the IFCAP and the Electronic Contract Management\nSystem (eCMS) interface.\nReports from this file will be used by the IFCAP users to follow the\ninterface activity to assure that communication with the eCMS vendor portal\nis timely and effective, and to provide contact information if needed.\n\n
\nThis file contains the list of event types that describe the various\ntransactions between IFCAP and the Electronic Contract Management System\n(eCMS). The event types describe the messages from the IFCAP perspective.\n\n
\nThis file holds FMS reconcilliation data\nfor a Fiscal Service. Each entry contains the\nsite, control point fiscal year, quarter,\ntransaction amount, and any FMS generated\ndata.\n\n
\nThis file is used to hold 820 transmissions returned\nfrom FMS for which no control point could be determined.\nBudget elements returned on the transmission did not match\nbudget elements stored on the site's control point files.\nThis file is used to generate the FMS Exceptions Report.\n\n
\nThis file contains the patients who are placed by the VA Facility\non a Waiting list and related data.\n\n
\nThis file contains results of Amis 334-341 reports by month for each\ndivision.\n\n
\nThis file contains results of Amis 345&346 reports by month for each \ndivision\n\n
\n This file contains parameters that allow the IFCAP user to define and\n maintain separate balances for funding at their station.\n\n
\n This file contains codes used by Fiscal service to subdivide funding\n and spending information by area of usage.\n\n
\nthis file contains programs used by fund control points.\n\n
\nThis file contains FCP/PRJ used by the fund control points.\n\n
\nThis file contains OBJECT CLASS used by the fund control points.\n\n
\nThis file contains JOBS used by the fund control points.\n\n
\nThis file contains REPORTING CATEGORY codes and descriptions.\n\n
\nThis file contains REVENUE SOURCE codes and descriptions.\n\n
\nThis file contains SUB-REV SOURCE codes and descriptions.\n\n
\nThis file contains SUB-OBJECT codes and descriptions.\n\n
\nThis file contains FMS SECURITY codes and descriptions.\n\n
\nThis file contains FUNDS used by the fund control points.\n\n
\nThis file contains SUB-ALLOWANCE ACCOUNT data used to map fund control points.\n\n
\nThis file contains administrative office codes used by the fund control points.\n\n
\nThis file contains document types used by the required fields table.\n\n
\nThis file contains document data elements used by the required field table.\n\n
\nThis file contains the required fields used by the fund control points.\n\n
\nThis file contains the all standard dictionaries used in IFCAP.\n\n
\nThis is used to indicate the status of an entry in file.\n\n
\n This file contains codes used by Fiscal service to subdivide procurement\n amount information by type of item used.\n\n
\nThis file contains all ALD codes specified in MP4 Part V. In addition \nit contains the appropriation symbol associated with the ALD code and\na pattern necessary to create the YALD code for the 921 transaction.\n\n
\nThis file contains the names and templates for all of the\nCALM and LOG I Transaction Codes.\n\n
\n This file contains a set of codes designating standard packaging units\n used in both procurement and distribution of goods.\n\n
\nThis file contains codes known as 'Reason Not Competed' which are used \nduring the creation of a purchase order in IFCAP. These codes are used in \nthe new FPDS report.\n\n
\nThis file contains codes known as 'Solicitation Procedures' which are \nused during the creation of a purchase order in IFCAP. These codes are\nused in the new FPDS report.\n\n
\nThis file contains codes known as 'Extent Competed' which are used during\nthe creation of a purchase order in IFCAP. These codes are used in the new\nFPDS report.\n\n
\nThis file is used by the new FPDS report and contains codes to indicate \nan 'Evaluated Preference' selected during the creation of a purchase\norder in IFCAP.\n\n
\nThis file contains codes called 'EPA Designated Products' used during the \ncreation of a purchase order in IFCAP. These codes are part of the new\nFPDS report.\n\n
\nThis file contains FPDS codes for fiscal years 88 & 89.\nThese FPDS codes are used to track the types of businesses from which\ngoods are being procured, in order to do reporting to Central Office.\nAll codes with internal entry #'s below 100 are for fiscal year 88.\nAll codes with internal entry #'s above 100 are for fiscal year 89.\n\n
\nThis file contains a listing of the distribution codes used\nwhen entering funding transactions in the Funds Distribution\nportion of IFCAP. This information may be edited.\n\n
\nThe codes used in this file designate a broad category defining the\nprocurement source for goods. The codes are used to update centralized\nreporting for procurement and define either specific government sources\nsuch as DEPOT and GSA, or ways of procuring goods from outside sources,\nsuch as whether or not they are purchased using a government contract.\n\n
\nThis file is used for identifying a particular type of item \nfor cost accounting purposes.\n\n
\nThis file contains the FMS/IFCAP conversion files.\n\n
\nThis file contains information necessary to print the 850 report after\nthe OOP message is processed from Austin.\n\n
\nThis file contains codes and descriptions data used by the IFCAP.\n\n
\nThis file contains the transaction used to distribute\nfunds to control points.\n\n
\nThis file is used by the Funds Distribution module to\nmultiply distribute funds to control points.\n\n
\nThis file contains a history of the CALM/LOG Transactions\nthat have been transmitted to Austin. This information\nis stored by Batch Number and Transaction Number.\n\n
\nThis file contains a listing of all the CALM Error Messages\nspecified in MP4 Part V. This file is used by Accounting\nto look up these messages.\n\n
\nThis file is used to "mark" a record while it is being\nedited. It serves to ensure that simultaneous editing\nof financial/procurement records does not occur.\n\n
\nThis file is used to record payment invoices which require\nControl Point sign-off.\n\n
\nThis file is used by the Funds Distribution module to distribute\nfunds to Control Point.\n\n
\nThis file is used to generate sequential tracking numbers\nfor Invoice Tracking.\n\n
\n This file will hold the printouts that are automatically generated\nwithin IFCAP. The user may then select to print from this file at a later\ndate/time.\n\n
\nThis is a file of partial number counters in which each obligation has\nhas its own counter. It is used to get the next available partial number\nfor a payment voucher associated with a given obligation.\n\n
\nThis file is used to construct code sheets for CALM and LOG I.\n\n
\nThis file is just a collection of counters.\n\n
\nThis file contains the completed CALM/LOG Code Sheets.\n\n
\nThis file contains the Reason Code used in HLS and OLS\ntransactions.\n\n
\nThis file contains a listing of the transactions that can be handled\nby the PRCOISM IFCAP server. This file also contains the mailgroup\nthat will receive any transaction processing error message and the\nentry point (TAG^ROUTINE) for each different transaction processing.\n\n
\nThis file contains the transactions that have been received from\nAustin through MailMan. For an entry to be made in this file, the\ntransaction type must be found in File 423.5. For each\ncomplete transaction, based on the entry point (TAG^ROUTINE) from\nFile 423.5, a TaskMan job is set up to process that transaction.\n\n
\nThis file contains a list of the various CALM and LOG I Batch\nTypes managed by the facility. In addition, it also contains\nthe appropriate physical address used by Network Mail for each\nbatch type to enable the Code Sheet Batches to be transmitted\nto Austin DPC via VADATS.\n\n
\nThis file contains a summary record of each authorization, obligation,\nand liquidation against a 1358 established in file 442.\n\n
\nThis file contains detail history of each bill submitted for payment for\neach authorization on a 1358.\n\n
\nThis file contains the site specific parameters which are used by\nthe Admission, Discharge and Transfer (ADT) modules. The parameters\nare set by using the 'DGPAR' routine or the 'ADT Parameters' menu\noption. The parameters are used to identify such things as your\nfacility hemodialysis unit, your admission/discharge/transfer types,\nyour divisions (if multi-division facility) and the devices to which\nyou desire your 10-10's, routing slips, etc., printed to. The ADT\nparameters must be set prior to running ADT.\n\n
\nThis file contains specific outpatient and inpatient event rates \nwhich are set to specific dollar amounts which are used by the \nBeneficiary Travel Module.\n\n
\nThis file contains entries which are set each year to a specific amount\nby MAS regulations. The TYPEs of awards are determined by MAS VACO.\nThis file should not be altered or added to unless so directed by the\nISC.\n\n
\nThis file contains data concerning changes, additions or deletions\nwhich were made to patient movement and captured by the system.\nThe data prints on the daily G&L.\n\n
\nThis file consists of a table of G&L type of changes. Previously, \n 5 TRANSFER DELETED\n 6 TRANSFER DATE EDITED\n 7 DISCHARGE ENTERED\n 8 DISCHARGE DELETED\n 9 DISCHARGE DATE EDITED\n 10 ADMISSION WARD EDITED\n 11 MOVEMENT TYPE EDITED\n 12 TRANSFER WARD EDITED\n 13 FACILITY TS ENTERED\n 14 FACILITY TS DELETED\nthis was a set of codes in the G&L Corrections File (#43.5). \n 15 FACILITY TS DATE EDITED\nThe data in this file is distributed with the MAS package and must \nNOT be altered in any way. There are currently 15 entries in this file:\n \n 1 ADMISSION ENTERED\n 2 ADMISSION DELETED\n 3 ADMISSION DATE EDITED\n 4 TRANSFER ENTERED\n\n
\nThis file contains those options for which a facility may specify\na local template to utilize for output purposes rather than the\none distributed by the MAS developers. The file is uneditable\nusing VA filemanager and may not be added to under any circumstances\nby the facility. To specify a local template utilize the appropriate\noption of the MAS module.\n\n
\nThis is the main file of the Accounts Receivable system.\nIt holds a permanent record, by bill number, of the receivable.\nDO NOT USE FILEMAN TO EDIT THIS FILE DIRECTLY! Using FileMan\nwill compromise system integrity. Use the AR menu options.\n\nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file stores the categories used for billing purposes along with\nthe associated AMIS segment, General Ledger, ALD code and Type.\nDO NOT EDIT THIS FILE !\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file stores the type categories used to identify transactions in the\nTransaction File (No. 433) along with flags that are set to control their\nuse. DO NOT EDIT THIS FILE !\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds the Cross-Servicing return reason codes\nfor the Integrated Agency Interface (IAI) file transmission\nof debt/debtor reconciliation file records from FedDebt.\n \nPer VA Directive 6402, this file should not be modified.\n\n
\nThis file holds short text entries that are used in the debt collection\nletters to identify the source of the bill. DO NOT USE FILEMAN TO\nEDIT THIS FILE DIRECTLY! Using FileMan will compromise system integrity.\nUse the AR menu options.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nPer VA Directive 6402, this file should not be modified.\n \nThis file will store the detailed data of which a summary is sent monthly \nto the AITC. This will allow sites to reconcile the data that was sent. \nIt will only store up to 3 months back and will be purged of any prior \nmonth's data when the AR Data Collector runs.\n\n
\nThis file serves as a temporary storage file for archived AR Records.\nEntries in this file are populated by the AR Archive Module. FileMan\nshould not be used directly to add/edit to this file.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds the Accounts Receivable transactions and all related\ninformation. DO NOT USE FILEMAN TO EDIT THIS FILE DIRECTLY!\nUsing Fileman will compromise system integrity. Use the AR menu options.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file contains all predefined suspension types for AR transactions.\n\n
\nThis file is used to store Medicare Part A Deductible Alerts (MDA) that\nare received by the Financial Services Center (FSC) in Austin and sent to\nthe individual sites. This data will be used by the new MDA worklist so\nthat Accounts Receivable personnel can take any necessary action.\n\n
\nContains locations found in the hospital (ie. Wards, Clinics)\n *********DO NOT RE-INDEX THIS FILE**********\n\n
\nThis file contains executable 'M' code for Scheduling Data field extracts.\n\n
\nThis file contains the listing of Vendors used by the facility. The data\nincludes the name, address, contact person, contract number and FPDS data\nused when entering a request and purchase order.\n\n
\nThis file contains the name and address of those patients who\nreceived deliveries of goods directly from a vendor. This address\ncould be a Nursing Home Care address or another vendor address.\n\n
\nThis file contains the listing of Vendors used by the facility. The data\nincludes the name, address, contact person, contract number and FPDS data\nused when entering a request and purchase order.\n\n
\nThis file contains a list of manufactures of items stored in the Item\nMaster file (#441).\n\n
\nThis file contains a list of possible sources for manufacturer's part\nnumbers and vendor stock numbers.\n\n
\nThis is a charge card master file.\n\n
\nThis file is used to store ORACLE records for reconciliation.\n\n
\nDuring the compile performed in option Accrual (Monthly) [PRCB MONTHLY\nACCRUAL], entries are added to this file listing total unpaid and\nunreconciled credit card order amounts by budget string "Fund/Beginning\nBudget Fiscal Year/ Administration or Staff Office/Accounting\nClassification Code/Cost Center/BOC" within month and station. This\nfile then serves as the source for generating the appropriate SV\ndocuments to be sent to FMS.\n\n
\nThis file contains a record of each transmission batch from the Credit\nCard System of Purchase Card Charges and Purchase Card Demographic Changes\nto be posted to IFCAP files (#440.6 and #440.5, respectively). This file\nis the source for the report Daily Charge Transmission Log [PRCH DAILY\nCHARGE TRANS LOG].\n\n
\nThis file contains descriptive information for any supply item that can be\nordered. Contains information needed for purchasing or ordering the item.\nAny item that is purchased repetitively should be entered to this file.\n\n
\n This file contains codes used to classify types of items into categories\nto be used for centralized reporting of procurement. Examples of categories\nare 'DRUGS & BIOLOGICALS', 'SURG. DRESS. MATERIALS', etc.\n This file also contains new entries known as product service codes\nwhich are applicable to services only. These codes are not allowed to be \nused with items.\n\n
\nThis file contains codes used to classify types of items into categories\nto be used for centralized reporting of procurement. The categories are\nbroader than those on the "FEDERAL SUPPLY CLASSIFICATION" file. Examples\nare "CHEMICALS" and "SUBSISTENCE".\n \nAlso this file has been updated with product service codes (PSC) to\nsupport a new report requirement for the Austin Automation Center (AAC).\n\n
\nA general purpose file containing assorted DLA and LOG codes used when\nconstructing electronic transmissions to either the Austin LOG system,\nor the DLA system. The 'SCREENING CODE' field is used to limit the\nchoice of codes available to the user to an appropriate set.\n\n
\n This file contains a list of the allowable types of amendments that\ncan be made to a Requisition after it has been Obligated. The file is used\nduring the Amendment process, both to allow the user to select the type of\namendment, and to direct the programs to the proper entry point for\nprocessing the type of amendment selected.\n\n
\nThis file contains the delivery locations and dates for display\non purchase orders.\n\n
\nThis is the main file for IFCAP Supply. It contains all of the Purchase\nOrder and Requisition data both while the record is being processed,\nand as an online history record after the record has been completed.\nIt also contains information pertaining to Accounts Receivable transactions.\n *********DO NOT RE-INDEX THIS FILE**********\n\n
\n This file contains a list of the allowable types of amendments that\ncan be made to a Purchase Order after it has been Obligated. The file is\nused during the Amendment process, both to allow the user to select the\ntype of amendment, and to direct the programs to the proper entry point for\nprocessing the type of amendment selected.\n\n
\nThis file contains a listing of all of the possible status codes that can\nbe assigned to a 2237 request or a purchase order. This file cannot\nbe edited. The file is used both to inform the user as to what processing\nhas been done to a request or Purchase Order, and also by the programs to \nscreen and direct each request/Purchase Order into the correct processing \npath.\n\n
\nThis file contains a listing of the Purchase Authorities as specified in the\nFPMR.\n\n
\nThis file contains a listing of all the appropriate Methods of Processing\nwhich apply to a purchase order. This file cannot be edited. The Method of\nProcessing directs each type of Purchase Order or Requisition into the\ncorrect processing path through IFCAP.\n\n
\nThis file contains prefix information for a PAT number. It allows the\nuser to reserve blocks of P.O.numbers for specific groups of users,\nso that the computer can automatically assign the next sequential number\navailable within the block when a new PAT is added to file 442.\n\n
\nThis file contains a listing of pre-set clauses used on purchase order.\nThe file is initially sent with data, but each station can then edit\nor add their own clauses. Once a clause is entered to this file, the\nPurchasing or PPM agent can then copy the clause into any Purchase\nOrder or Requisition, which will cause it to be printed in the P.O.\nComments block on the P.O. or Requisition form.\n\n
\nThis file contains the delivery locations and dates for display\non purchase orders.\n\n
\nThis file contains data about the Electronic Receiving Reports\nthat are transmitted to Austin.\n\n
\nThis file contains a listing of the requests that have been transmitted to\nA&MM but not yet transferred onto a Purchase Order or Requisition.\n\n
\nThis file contains the entries to be processed by PurgeMaster.\n\n
\nThis file contains the parameters for the PurgeMaster Utility\n\n
\nThis file is a temporary repository for transaction being processed by\nPurgeMaster. In the event of a system failure, these entries are \nrestored into the PurgeMaster Worklist file.\n\n
\n This file contains the list of special handling instructions.\n\n
\nThe operator is allowed to reprint a batch of requests in Supply, or\nreprint a batch of Purchase Orders in either Fiscal or Supply, or reprint\na batch of Receiving Reports in Fiscal that were previously printed within\na date/time range. This option could be used if the printer was not working\nduring those times. This file is used to keep lists of Requests or Purchase\nOrders printed, to allow the operator to review the list before reprinting.\n\n
\nThis is a temporary holding file used to store a purchase order while an\nAmendment is being created. Changes to a P.O. are actually made to this\nfile, and not to the original P.O. If the user completes and approves\nthe Amendment, the changes are copied to the P.O. Whether approved\nor not, the "copy" is deleted from this file when the user is finished.\nThe file is also used for amendments to Requisitions.\n *********DO NOT RE-INDEX THIS FILE**********\n\n
\nThis file has the information sent from Austin in the ACT or PRJ\ntransactions. These transactions inform IFCAP if the EDI package\naccepted or rejected the PHA transaction sent to Austin.\n \nIn addition this file also has the POA status sent back from the\nvendor about the PHA order. The POA status is placed into the \nEDI STATUS CODE 1 or 2 and EDI STATUS QUANTITY 1 or 2\nfields in the ITEM multiple of file 442 for the PHA order.\n\n
\nThis file holds list of REJECT REASON CODEs that are sent from Austin \nwhen a PHA or an RFQ is rejected.\n \nThis file is pointed by a field (#9) in EDI STATUS FILE (#443.75).\n \n\n
\nThis file is a listing of the reasons for procuring items locally.\n\n
\nThis file is a local Archive/Purge file that documents what records are\npending archive. Prior to initiating an archive, this file should be\nempty. This file is populated by the menu option Find Archivable IFCAP\nRecords [PRCG ARCHIVE FIND].\n\n
\nThis file serves as a worksheet for the Request for Quotation process.\nThe Purchasing agent can edit data imported from one or more 2237s.\nThis data is then the basis for the electronically submitted RFQ.\nCorrespondence via 864 Transactions (Text Messages) are stored in a\nmultiple of this file. The quotes submitted by vendors are also stored\nin a multiple of this file.\n\n
\nThis file contains vendors used in the RFQ process who are not found in\nthe site's main VENDOR file (#440). Once a vendor is selected as the\nsource during RFQ award, an entry for him should be made in file #440\nso that he will be vendorized by the Austin Automation Center and be\nready for payment transactions. In lookups for vendors in the RFQ\nmodule, file #440 is first searched for the vendor. If the vendor is\nnot found, the search continues in file #444.1. If not present in this\nfile, the user has the option to add a vendor to this file.\n\n
\nThis file contains the Standard Industrial Classification Codes, which\nare used to classify organizations by economic activity.\n\n
\nThis file contains categories for lumping SIC Codes and will be used to\nfacilitate lookups.\n\n
\nThis file contains counters for getting the next available sequence\nnumber. There is a separate counter for each combination of Station # and\nFiscal Year. This sequence number is padded on the left with zeros to\nform the sequence number portion (4th piece) of the RFQ number. (i.e.\n688-96-RFQ-00014).\n\n
\nThis file stores the user's editing mode preference, FileMan Input Template\nor ScreenMan Form.\n\n
\nThis file contains descriptive and inventory information for any entity\n\nthat wants to maintain a perpetual inventory, automate their item \ndistribution function, and automatically generate stock replenishment \norders based on inventory needs.\n \nThere are three types of inventory points that can be on this file:\nWarehouses, Primary Distribution Points (locations that are allowed to\norder directly from supply), or Secondary Distribution Points (locations\nthat must order through a Primary Distribution Point).\n\n
\nThis file stores the beginning monthly balances for the items stored\nin the inventory points.\n\n
\nUSED BY GENERIC INVENTORY SYSTEM.\n This file is used to keep a log of ANY transaction that affects the\ninventory level. The file will be updated ONLY if the flag on the\ninventory point "KEEP DETAILED TRX.HISTORY" is set to "Y" (YES).\nRecords are then automatically added to the file during the processing\nof any transaction that affects the inventory level (receiving,\ndistribution, usage, manual adjustments, etc.) NOTE: THIS FILE SHOULD\nBE PURGED FREQUENTLY!!!\n\n
\nUSED BY GENERIC INVENTORY SYSTEM.\nThis file is used to store distribution orders from a Primary Inventory/\nDistribution point to a Secondary. An order can be entered either at\nthe Primary, for the Secondary, or at the Secondary, if they are\nautomated. When an order is posted, the inventory level at the\naffected inventory points are updated, history is updated, and the\nrecord is deleted from the file, unless items are backordered. Items\non backorder are left on the record until the back-order function has\nbeen completed.\n\n
\nThis file is used to describe storage locations within any Generic Inventory\nPoint (i.e. the Bins, Shelves, Rooms, etc. in which supplies are stored).\nThe format for creating codes related to a storage location can be\ndefined by each inventory point to meet their own needs.\n\n
\nThis file contains information that assists GIP in communicating correctly\nwith a supply station.\n\n
\nUSED BY GENERIC INVENTORY SYSTEM.\n This file stores codes and related descriptions used for grouping\ninventory items. Items might be grouped for printing catalogs,\ndoing physical counts, or other reports. Each item on the\ninventory (file 445) should have a group category.\n\n
\nThis file is used to define items which make up a case cart.\n\n
\nThis file is used to define items which make up an instrument kit.\n\n
\nUSED BY GENERIC INVENTORY SYSTEM.\nNOTE: For usage within an inventory/point (i.e. goods were distributed\nto the end user at this point and not distributed to another inventory/\ndistribution point), the DISTRIBUTED TO and DISTRIBUTED FROM fields will\nbe the same.\n This file is used to store data needed for cost accounting. The data\nis updated automatically by the Generic Inventory system, when a\ndistribution order (from a Primary to a Secondary) is posted, when\nan adjustment is made to distribution, or when usage within an inventory\npoint is recorded. The file keeps a record of total dollars distributed\n/used by month, and by the cost center that distributed or used the supplies.\nReports can then be generated from this file by cost center, or broken\ndown further by MIS Bed Sections (defined for each inventory point).\n\n
\nThis file is used to track inventory items which are distributed from\nthe secondary to the patient.\n\n
\nThis file contains barcode programs and data uploaded from the barcode\nreader to be used as part of the Barcode Inventory process.\n\n
\nThis file contains the custom labels to be used as part of the Barcode\nInventory process.\n\n
\nThis file contains the Specialty Commands for the barcode reader and \nprinter to be used as part of the Barcode Inventory process.\n\n
\nThis file contains report data needed by the Clinical Logistics Report \nServer (CLRS). The PRCPLO CLO GIP OPTION runs the report that clears and\nthen populates this file. The Prosthetics and Clinical Logistics Office\n(P&CLO) requires this option to be run on the first day of each month.\n\n
\nThis file is used to manage the locking of files by user in the inventory\npackage. When a user locks a file or inventory item, an entry is made\nin this file. Other users which try to access the locked file or item\nwill be displayed a message showing the user and option which is locking\nthe file or item.\n\n
\nThis file is populated with information originating from the automated\nsupply station HL7 transactions. Once the data stored here has been\nprocessed by GIP and the GIP files have been updated appropriately, the\nrecord will be deleted. This file allows information from the supply\nstations to flow to GIP even if the file 445 entry for a particular\nsecondary inventory point is in use.\n\n
\nThis file contains all PTF information generated from admissions, treating\nspecialty transfers, and PTF screen edits.\n\n
\nFacilities used in PTF transfers.\n\n
\nThis file contains the list dialysis codes that can be use when\ncoding a PTF record for a dialysis treatment episode.\n\n
\nMessage generated by changes in bedsection and diagnosis to be reviewed by\nPTF coders\n\n
\nThis file contains a history of all Archive/Purge functions\nperformed on the PTF file(#45). The fields in this file should not be\nupdated through Fileman; they are updated by the PTF Archive/Purge\noptions throughout the Archive/Purge process.\n\n
\nThis file defines error codes, their meaning and position location in the \ndata segments that are transmitted to the Austin INformation Technology\nCenter (AITC).\n\n
\nThis file is used to record PTF records as they are released by MIS and their subsequent transmission to Austin.\n We don't recommend re-indexing of this file.\n\n
\nThis file is used to record the PTF records that are closed out for release\nto Austin\n\n
\nThis file is a work file of patients who were inpatients as\nof 11:59pm on acensus date. File entries are created by the \nRegenerate Census Workfile option of the Census module.\n \nThe file is used to produce the Census Status Report. Without this\nworkfile, it would be necessary to search all admissions in order\nto compile this report. This file eliminates that processing.\n\n
\nThis file contains a list of PTF census dates. Usually these\ndates are on 9/30.\n \nAlso, this file contains census date specific parameters, such\nas CLOSEOUT DATE for the census.\n\n
\nThis file is a log of special PTF transactions submitted to Austin.\nThe following PTF transactions are logged in this file:\n o N099 for PTF record deletion\n o N150 for RPO of a specific admission\n o N151 for RPO of all admissions at a VAMC\n\n
\nThis file contains data that is tranmitted to the Austin DPC as part of the\nTerm Care Patient Assessment Instrument).\nRUG-II program. Data contained in this file relates to patients that were\n(or are) housed on an intermediate care or nursing home care ward. It\npertains to the patient's level of care and needs from the nursing\nprofessionals. This data is in turn used for reimbursement. Data should\nbe edited through menu options on the RUG-II menu, not through VA FileMan\noptions.\n \nQuestions asked on this form mimic those on VA form 10-0064a (the Long\n\n
\nThis file contains the RUG-II groupings used for reimbursment for patients\nare stored in this file along with the yearly WWUs (weighted work units)\nfor each. These weighted work units are supplied by MAS VACO and the\nBoston DPC (which supports the RUG-II program) and are used for\nreimbursement at the medical center level.\nthat reside on long term care units (those with services of either\nintermediate or nursing home care). Each time a patient is transferred\nor admitted to a ward of one of these types, a patient assessment\ninstrument must be completed (these are stored in the PAF file - #45.9).\nAdditionally, twice a year, a census of nursing home and intermediate\nmedicine wards is taken and assessments are done at that time. Once an\nassessment is completed, a patient is placed into one of the 17 RUG-II\ngroups based on the level of care s/he is receiving. The 17 RUG groups\n\n
\nThis file contains employee master record data that is sent to the\nstation from the Austin Data Processing Center.\n \n\n
\nThis file stores PAID download processing error messages until the\nmessages can be placed into a MailMan message to alert the user. After\nthe MailMan message has been created, the error messages are deleted\nfrom this file.\n\n
\nThis file stores information about the PAID download MailMan messages\nuntil the last message for the download arrives and the processing begins.\nAfter the last message of the download has been processed, the entries to\nthis file are deleted.\n\n
\nThe file stores all nurse Point of Care (POC) data for direct patient\ncare and non-direct nurses. The POC data includes the daily time card \nrecords and its approval, release and correction information.\n\n
\nNurse Roles correspond to codes from VA Human Resources and Finance \ndatabases, which were used in making the nursing roles determination. \nCost center, budget object code, occupation series code, and assignment \ncodes are all utilized to determine a nursing role.\n \nThis file is exported with data and the contents of the file should not be\nlocally modified.\n\n
\nThe file stores all POC Types of Time with their associated ETA Types of Time.\n\n
\nThis file contains codes for types of work a nurse may perform in a \nmedical setting. Examples include Direct Care, Light Duty, On Site \nEducation.\n \nThis file is exported with data and the contents of the file should not\nbe locally modified.\n\n
\nThis file contains codes for reasons why a nurse may work overtime.\nExamples include Extreme Weather, Sitter Needed, and Unpredicted\nPatient Care.\n \nThis file is exported with data and the contents of the file should not be\nlocally modified.\n\n
\nThe file stores the released POC Daily Time Records from the\nPOC DAILY TIME RECORDS (#451) FILE for extracting by other applications.\nEntries are set up without user interactions.\n\n
\nThis file contains information on employee and non-employee attendance at\ncontinuing education and inservice programs.\n\n
\nThis file contains the names of the continuing education and inservice programs used in the Education Tracking software.\n\n
\nThis file contains the names of the companies or organizations who supply the programs or classes.\n\n
\nThis file contains groups of mandatory or required classes. For Nursing\nservice this was known as Mandatory Inservice (MI). These groups can be\nfor individual students or for entire services.\n\n
\nThis file contains information used to group or categorize related\nprograms/classes.\nEntries in this file are not to be edited.\n\n
\nThis file contains methods of presenting a program/class.\n\n
\nThis file contains entries used to document the attendee's reason or \npurpose for attending a class.\nEntries in this file are not to be edited.\n\n
\nThis file contains the service's reasons for individuals attending a \nprogram/class.\n\n
\nThis file contains specific parameters used in the Education Tracking \nApplication.\n\n
\nThis file contains information on employee/student registration.\n\n
\nThis file contains information on organizations which accredit the\ncontinuing education programs.\n\n
\nTHIS FILE IS CURRENTLY BEING USED BY THE CREDENTIALS TRACKING PACKAGE\nTO CONTAIN APPLICANTS GOING THROUGH THE CREDENTIALING PROCESS.\n\n
\nThis file is a series of subfiles containing the PAID codes and code \ndescriptions.\n\n
\nThis file contains a list of organizational units to be associated with a\nparticular cost center/organization combination.\n\n
\nThis file contains error messages corresponding to various edit\nerrors that may be detected during the processing and checking\nof an 8B record entry.\n\n
\nThis file contains the list of T&L units established by a station\nas well as the associated timekeepers.\n\n
\nThe PAID PARAMETERS file contains data that is specific to the \nadministration of Nurse Alternate Work Schedules, such as whether\nto send notification bulletins and how many should be sent. It also\ndefines the manner in which nurses shall be accessed for Nurse POC\nrecords.\n\n
\nThis file contains a list of all Tours of Duty utilized by the\nstation. Each tour can contain up to seven time segments which\nmay optionally have a Special Tour Indicator to indicate\nspecial processing. Further, a tour may be available to all\nT&L Units or may be associated with a list of T&L Units which\nmay utilize the tour.\n\n
\nThis file contains a list of special processing conditions\nwhich may relate to a particular Tour of Duty time segment.\n \nThis file should not be altered except as instructed.\n\n
\nThis file contains a list of Types of Time which may be used\nin posting. Most of the entries are either types of leave or\nOvertime/Comp time.\n \nThis file should not be altered except as instructed.\n\n
\nThis file contains fixed entries to indicate special conditions\nrelated to a posted time segment.\n \nThis file should not be altered except as instructed.\n\n
\nThis file contains a string of codes which indicate entitlement\nto specific type of time for different pay plan categories.\nThe first character of the name is the Pay Plan, the second is\nDuty Basis, and the third is the FLSA indicator.\n \nThis file should not be altered except as instructed.\n\n
\nThis file contains a list of valid Environmental Differentials which\nmay be requested. This file should not be altered except as\ninstructed.\n\n
\nThis file contains all the data that appears on an employee's time card.\n\n
\nThis file contains all Leave (Absence) Requests entered by\nemployees.\n \nIt contains much the same information as a SF-71 form.\n\n
\nThis file contains all requests for OT/CT other than those\nscheduled as part of a tour.\n \nIt contains the information pertaining to the request formerly\nfound on a VA Form 4-1098.\n\n
\nThis file contains all Environmental Differential requests.\n \nIt contains the information previously entered on VA Form 4-1098a.\n\n
\nThis file contains extended absence records for part-time physicians that \nabsence. Therefore the physician will not need to manually update their\nESR during the absence.\nwork adjustable hours and have a memorandum of service level expectations.\nSuch employees must maintain an electronic subsidiary record (ESR) that\nrecords their actual work.\n \nThe part-time physician can enter an extended absence record to indicate a\nfuture period when they will not be performing work for the VA. The\nsoftware will automatically change the status of ESR days with a scheduled\ntour of duty to signed if those days are covered by the period of extended\n\n
\nContains data identifying prior pay period exceptions for employee time\ncards.\n\n
\nThis file contains entries that are generated during a supervisors \ncertification. When an employee's 8B string contains more overtime than \napproved overtime in the requests file, a warning message is displayed \nto the supervisor before certifying the timecard. If the supervisor \ncertifies the timecard without resolving the warning then the warning is \nfiled in this file. The entries are for either week 1 or week 2 of a \npay period.\n\n
\nThis file contains all of the information related to the part-time physician's\nMemoranda of Service Level Expectation. Memorandum will only be applicable for\npart-time physicians who work adjustable hours. A memorandum will cover 26 pay\nperiods.\n\nThe file will contain all of the information related to the part-time\nphysician's memoranda including a per pay period breakdown of hours worked\nand various comments fields that will assist Human Resources as the reconcile\nthe memoranda after its completion or termination.\n\n
\nThe Recess Tracking file contains records of recess periods for each \nfiscal year for nurses on the 9-month AWS schedule. Nurses on the 9-month\nAWS shall be required to schedule 75 percent of the fiscal year as work\nand 25% of the fiscal year as recess, prior to beginning the AWS. The\nperiods of work and recess are prorated from the first pay period in which\nthe AWS begins and the last pay period of the fiscal year. An ETA fiscal \nyear runs from the first full pay period after September 30 through the \nfollowing year and the entire pay period that contains September 30.\n\n
\nThis file contains PAID accounting data and some master record data for\ncurrent employees by pay period.\n\n
\nThis file is used to capture inpatient professional services for billing.\nEntries from this file are used on the CMS 1500. This file can be used\nto capture billing information for observation visits The date and time\nof the professional service is used as a unique identifier for the\nprofessional service.\n\n
\nIn the initial design of the RAI/MDS interface, the need to create a\ncreated. In addition, a routine which will periodically run checking the\nentries for patients who have exceeded the 30 day stay. Whenever a stay\nis found to exceed the 30 days, an HL7 Discharge (A03) will be created and\nsent to the COTS system and the entry in the RAI MDS ASIH PATIENT file\nwill be inactivated. This file and associated routine and option are part\nof patch DG*5.3*328.\ndischarge when a patient exceeds 30 days in ASIH was overlooked. Because\nthe RAI/MDS interface is triggered by PIMS ADT events, there is no PIMS\nevent for this discharge. In fact, the PIMS software creates a pseudo\ndischarge at the time the patient goes on ASIH with a date/time of NOW\nplus 30 days. Therefore, if the 30 days is exceeded, the discharge goes\ninto affect. If the patient returns or dies while ASIH, the discharge is\neither deleted or modified.\nIn order to maintain control of the patients on ASIH, a new file was\n\n
\nThis file holds the inquire and update audit transactions queued to be \nsent to the Vista Audit Solutions (VAS) external archive.\n\n
\nThis file contains the most recent record from the AUDIT file (#1.1) that \nwas queued to be sent to the VistA Audit Solution (VAS) external archive.\n\n
\nThis file contains settings for the VistA Audit Solution (VAS) process \nthat sends audit transactions to the VAS external archive.\n\n
\nThis file contains all of the allowable Supporting Documentation Types \nthat identify the available documents detailing how a patient's death was \nrecorded.\n\n
\nThis file contains all of the allowable Source of Notifications that are \navailable for identifying who first notified the VA of a patient's death.\n \nNOTE: The first nine (9) entries exported in this file will correlate to \nthe SET OF CODES that this file is replacing.\n\n
\nThis file contains all of the allowable SUPPORTING DOCUMENTATION TYPES \n(#47.75) and SOURCE OF NOTIFICATIONS (#47.76) combinations that can exist \nbetween these two files. By placing these valid combinations into a file, \nexisting hard-coded sections of code can be removed allowing for a more \ndynamic implementation of this business rule.\n \nNOTE: Future combination additions/changes (including inactivation) will \n be performed through an RPC on the Master Patient Index and \n distributed out to all sites as needed.\n\n
\nThis file contains all the allowable Sexual Orientation Types that can be \nassociated to a patient's identity in relation to the gender to which \nthey identify with.\n\n
\nThis file contains all the allowable Pronoun Types that a patient can be \naddressed as.\n\n
\nPrimary file used for the storage of patient specific information from the\nPatient Funds package.\n\n
\nThis file is the file which contains ALL transactactions entered for\nALL patients. The Transaction field of each patient account points\nto this file.\n\n
\nThis file contains the list of forms utilized by the Patient funds system.\n\n
\nThis file contains information pertaining to incorrectly converted\nSIGNATURE CODES. This file is populated during the\nPRPF*3.0*6 conversion process when a signature cannot\nbe properly converted.\n\n
\nThis file is a READER file to temporarily store data for later filing in\nthe Master Transaction File and Patient Funds File\n\n
\nThis file contains the list of symbols and expanded descriptions\nto be used to identify remarks on a card.\n\n
\nThis file contains the release notes for the MAS module starting\nwith version 3.5. Also included are the facility initialization\ntimes, comments conerning the release, etc.\n\n
\nThis file contains a list of the modules distributed by PIMS. The\nentries in the file are used by various PIMS release management\nutilities and options.\n\n
\n*** NOTICE: DO NOT POINT DIRECTLY TO THIS FILE UNTILL YOU GET AN IA ***\n \nThis file will store all known Postal Codes as well as other associated \ninformation related to the Postal Code. Although the original data in\nthis file will only contain US Postal Code, the file has been designed to \nallow non-US Postal Codes to be added in the future if desired.\n\n
\n*** NOTICE: DO NOT POINT DIRECTLY TO THIS FILE UNTILL YOU GET AN IA ***\n*** The ONLY file that is allowed to point directly to this file is the:\n POSTAL CODE(#5.12) file ***\n \nThis file contains all known US County FIPS codes according to the USGS, \nHUD, and USPS.\n\n
\nThis file holds the information related to each drug that can be used\nto fill a prescription. It is pointed to from several other files and\nshould be handled carefully, usually only by special individuals in the\npharmacy service. Entries are not typically deleted, but rather made\ninactive by entering an inactive date.\n \nThis file must be built by Pharmacy Service BEFORE going on-line. It is\ncommon to use another centers file and edit it to match your center's\nunique formulary.\n\n
\nThis file contains the questions and parameters to be associated\nwith a DUE study. \n\n
\nThis file contains the responses to a DUE QUESTIONNAIRE.\n\n
\nThis file contains the individual questions to be used in a DUE\nQuestionnaire.\n\n
\nThis file is used to group DUE Answer sheets into meaningful groups, e.g. Providers, Clinics, Services, etc.\n\n
\n This file allows drugs to be grouped into categories. Once a category \nhas been created, custom-tailored reports such as provider cost reports,\nward/drug usage reports, and drug cost reports, may be run for groups of\ndrugs defined in a category.\n\n
\n This file contains drug names used to order medications for patients. \nThese names are used mainly for selection and printing for non-pharmacy \npersonnel, as the names HAVE NO DOSAGE ASSOCIATED WITH THEM.\n\n
\n This file contains applications and their one character codes. These\ncodes are used by the APPLICATION field of the PRIMARY DRUG file.\n \n THESE CODES (OTHER THAN 'Z' OR 'z') MUST BE ASSIGNED BY THE BIRMINGHAM ISC!!\n\n
\n This file contains the names and concentrations of electrolytes found in\ncertain IV drugs. Entries in this file are pointed to by the IV Additives\nfile (52.6), and the IV Solutions file (52.7).\n\n
\nPer VHA Directive 2005-044, this file has been "locked down"\nThis file contains individual generic drugs which are components of\nvarious drug products.\nby Data Standardization (DS). The file definition (i.e. data dictionary)\nshall not be modified. All additions, changes and deletions to entries in\nthe file shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating and/or\nediting locally defined fields in the file are not permitted. Use of\nlocally defined fields that were created prior to VHA Directive\n2005-044 shall not be supported.\n \n\n
\nPer VHA Directive 2005-044, this file has been "locked down"\nby Data Standardization (DS). The file definition (i.e. data dictionary)\nshall not be modified. All additions, changes and deletions to entries in\nthe file shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating and/or\nediting locally defined fields in the file are not permitted. Use of\nlocally defined fields that were created prior to VHA Directive\n2005-044 shall not be supported.\n\n
\nPer VHA Directive 2005-044, this file has been "locked down"\nThis file contains the VA Drug Classifications. Each five-character\nalpha-numeric code specifies a broad classification and a specific\ntype of product. The first two characters are letters and form the\nmnemonic for the major classification (e.g., AM for antimicrobials).\nCharacters 3 through 5 are numbers and form the basis for subclassification.\nThe VA Drug Classification system classifies drug products, not\ngeneric ingredients. Drug products with local effects are classified\nby route of administration (e.g., dermatological, ophthalmic). If a\nproduct is not classified by route of administration, it is classified\nin most instances under a specific chemical or pharmacological\nby Data Standardization (DS). The file definition (i.e. data dictionary)\nclassification (e.g., beta-blockers, cephalosporins). If a product\nis not classified by route of administration, or chemical or\npharmacological subclassification, it may be classified under a\ntherapeutic category (e.g., antilipemic agents, antiparkinson agents).\nshall not be modified. All additions, changes and deletions to entries in\nthe file shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS). Creating and/or\nediting locally defined fields in the file are not permitted. Use of\nlocally defined fields that were created prior to VHA Directive\n2005-044 shall not be supported.\n \n\n
\nThis file contains dosage forms.\n\n
\nThe MASTER DOSAGE FORM file contains the standardized RxNorm Concept \nUnique Identifier (RXCUI) codes representing dose forms. \n\n
\nThis file contains drug units.\n\n
\nThis file contains package types.\n\n
\nThis file contains package sizes.\n\n
\nThis file contains information on drugs that have been matched, or for\nwhich a match was attempted to the National Drug File.\n\n
\nThis file contains Patient Medication Information (PMI) in English and\nis supplied and maintained by the vendor.\n\n
\nThis file contains Patient Medication Information (PMI) in Spanish and\nis supplied and maintained by the vendor.\n\n
\nThis file contains mapping information in English in order to link\nGCNSEQNO to a PMI.\n\n
\nThis file contains mapping information in Spanish in order to link\nGCNSEQNO to a PMI.\n\n
\nThis file contains Warning Label information in English and is supplied\nand maintained by the vendor.\n\n
\nThis file contains Warning Label information in Spanish and is supplied\nand maintained by the vendor.\n\n
\nThis files contains mapping information in order to link GCNSEQNO to\nWarning Labels.\n\n
\nThis file contains available dispense units used for CMOP purposes.\n\n
\nThis file contains a list of National Drug Codes (NDCs) and Universal\nProduct Numbers (UPNs).\n\n
\nPer VHA Directive {pending directive #}, this file has been "locked down" by\nThis file contains a list of available drug products.\nData Standardization (DS). The file definition (i.e. data dictionary) shall not\nbe modified. All additions, changes and deletions to entries in the file shall\nbe done by Enterprise Reference Terminology (ERT) using the Master File Server\n(MFS), provided by Common Services (CS). Creating and/or editing locally\ndefined fields in the file are not permitted. Use of locally defined fields\nthat were created prior to VHA Directive {pending directive #} shall not be\nsupported. \n \n\n\nOrder Entry name for items that can be ordered in the Pharmacy package.\n\n
\n This file contains information concerning the IV workload of the pharmacy.\nThe file is updated each time the Compile IV Stats option is run and the \ndata stored is used as the basis for the IV AMIS report.\n\n
\nThis file holds information extracted nightly by a special pharmacy program\nto allow easier and quicker reporting of pharmacy activity the next day.\nWhen the daily information accumulates in excess of one month's information,\nit is condensed into a monthly total and the daily information is purged.\n \nThis file serves as the principal database for the cost analysis programs.\n\n
\nThe CDR ACCOUNT file (#509850) contains all of the cost accounts used to \nQUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\ncalculate and print the Cost Distribution Report (RCS 10-0141) for \nAudiology and Speech Pathology (Cost Center 228).\n \nEach patient visit contains a pointer to one of these accounts for \ndistribution of workload to appropriate cost accounts.\n \nThis file arrives at the VAMC with data. This file SHOULD NOT be altered \nthrough the use of VA FileMan; input should take place ONLY through the \n\n
\nThe A&SP DIAGNOSTIC CONDITION file (#509850.1) contains pointers to a \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\nsmall subset of ICD CM codes which pertain to Audiology and Speech \nPathology. Entries in this file are pointed to by the DIAGNOSTIC CODE \nfield in the A&SP CLINIC VISIT file (#509850.6).\n \nThis file arrives at the VAMC with data. This file SHOULD NOT be altered \nthrough the use of VA FileMan; input should take place ONLY through the \nQUASAR menu options.\n \n\n
\nThe A&SP PATIENT file (#509850.2) contains identifying, demographic, and \ninput should take place ONLY through the QUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\nother clinical information for all patients seen in the Audiology and \nSpeech Pathology clinics.\n \nThe entries in this file are pointers to the PATIENT file (#2) used by \nMAS. For this reason, a patient must already be present in DHCP File #2 \nbefore he can be added as an Audiology/Speech Pathology patient.\n \nData in this file SHOULD NOT be altered through the use of VA FileMan; \n\n
\nThe A&SP STAFF file (#509850.3) contains the names of all A&SP clinicians \n \nData in this file SHOULD NOT be altered through the use of VA FileMan; \ninput should take place ONLY through the QUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\nand students. Information in this file includes the staff person's name, \nactivation and inactivation dates, status (i.e., clinician, fee basis, \nother provider, or student), and an ID number for sites that may wish to \nenter provider by code number.\n \nEntries in this file are pointed to by fields in the A&SP CLINIC VISIT \nfile (#509850.6) in order to identify staff members who took part in a \ngiven visit. Therefore, staff names should NEVER be deleted.\n\n
\nThe A&SP PROCEDURE CODE file (#509850.4) contains pointers to a small \nThis file arrives at the VAMC with data. This file SHOULD NOT be altered \nthrough the use of VA FileMan; input should take place ONLY through the \nQUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\nsubset of CPT-4 codes which pertain to Audiology and Speech Pathology.\nEntries in this file are pointed to by the PROCEDURE CODE field in the \nA&SP CLINIC VISIT file (#509805.6).\n \nBefore using the QUASAR package, the supervisor must enter cost data for \neach procedure code in the A&SP PROCEDURE CODE file. This can be done \nusing the Enter Cost Information for Procedures option.\n \n\n
\nThe A&SP Procedure Modifier file contains a list of the CPT and HCPCS\nData in this file SHOULD NOT be altered through the use of VA FileMan;\ninput should take place ONLY through the QUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\nModifiers that are appropriate to Audiology and Speech Pathology. This\nfile restricts the selection of Modifiers when entering CPT Procedures\nwithin the New Visit option and Edit Existing visit option.\nThe file will be referenced when the user is either selecting a Modifier\nor requesting a Help list for Modifiers whilst within the New Visit or\nEdit an Existing Visit options.\nThis file was introduced within Version 3.0 of QUASAR. \n \n\n
\nThe A&SP CLINIC VISIT file (#509850.6) contains all data specific \nto each patient encounter. This includes the patient, the clinicians \nand students involved, the diagnostic and procedure codes, the date \nof the visit, procedure time, and the CDR cost account.\n \nData in this file SHOULD NOT be altered through the use of VA FileMan;\ninput should take place ONLY through the QUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\n\n
\nThe A&SP CLINIC WORKLOAD file (#509850.7) contains each month's\ncapitation statistics. Data in this file are used to compile \nstatistics which includes a display of total and unique visits by\nzip code, procedure, and disease code for any specified month.\n \nData in this file SHOULD NOT be altered through the use of VA FileMan;\ninput should take place ONLY through the QUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\n\n
\nThe A&SP SITE PARAMETERS file (#509850.8) contains site specific\nthen the overnight job to send data to PCE will be active. It will\nsend visit data for any Division that has the SEND TO PCE field\nset to YES.\n \nEach Division has a USE ASP CLINIC FILE NUMBER field which allows you \nto associate existing clinic file numbers with patients. You can also\nactivate the AMIE C&P Interface for specific Divisions and specify\nthat when entering data for a Division the user is not required to \nenter Audiometric data for Hearing Loss cases by setting the BYPASS \nAUDIOMETRICS parameter to YES.\ndata used by the QUASAR package. There should be only ONE site\n \n \nData in this file SHOULD NOT be altered through the use of VA FileMan; \ninput should take place ONLY through the QUASAR menu options.\n \nPer VHA Directive 10-93-142, this file definition SHOULD NOT be modified.\nentry in this file.\n \nBefore running the package, at least one Division must be added to \nthe file and at least one Clinic entered for the Division.\n \nThe INTERFACE TO PCE and SEND TO PCE parameters control whether \nvisit data is sent to PCE. If the INTERFACE TO PCE is set to YES\n\n
\nThis file is used to maintain a record of audiological exams.\n \nData for this file is only entered through the Audiometric\nExam Module GUI application: ACKQROES3E. Entering data in\nany other way, may have unpredictable results, as help for\nindividual fields and most data validation takes place in\nthat application.\n \nAn accompanying GUI application: ACKQROES3 uses the data in\nthis file to create a graphical audiogram.\nIt contains all of the air conduction, bone conduction and word\nrecognition test results.\n \nWhen signed (DATE SIGNED field), the results are transmitted\nto the Denver Distribution Center to be stored in a national\ndatabase. The information from the last exam received for\na patient is also added to hearing aid orders for the patient\nplaced through the Remote Order Entry System(ROES3.0) at the DDC.\n\n
\n This file holds the abbreviations which are often used when entering the\nin the classical VA FileMan sense, but that logically it is nearly the\nsame thing.\nRx sig. Each record holds an expansion of the abbreviation which is used\nto complete the sig as it is printed on the Rx label. Care should be taken\nto not delete entries in this file after going into production use of the\npharmacy package. If an entry were deleted then any sigs that contain\nthe abbreviation would not find it when printed later and thus could confuse\nthe patient.\n \nThe above description indicates that this file is not strictly 'pointed to'\n\n
\n Sets of standard times over which medications are to be administered.\n\n
\n This file contains shifts - ranges of times over which an action\nis to take place, such taking a patient's temperature.\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nThis file contains the list of standard Medication Routes for Vista. \nUpdates will only occur to this file at the national level. Updates \ncannot be made at a local facility. This file will be used to link local \nMedication Routes from the Medication Routes (#51.2) file to the national \nstandard.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nThis file contains a list of Standard Dose Units, associated synonyms, and\na corresponding FIRST DATABANK Dose Unit for every Standard Dose Unit. \nThe associated FIRST DATABANK Dose Unit will be used for the Dosage \nChecks provided by FIRST DATABANK. Updates cannot be made at a local\nfacility.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n \n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nDOSE UNIT 2. The top level or parent will be DOSE UNIT 1(#.01). \nAssociated with each DOSE UNIT 1 will be multiple child DOSE UNIT \n2(51.251,#.01) and CONVERSION FACTOR(51.251,#1) pairs. All fields are \nrequired for a given entry or sub-entry. \n \nThe DOSE UNIT CONVERSION file will be used to convert one dose unit to \nanother using a conversion factor so that a comparison can be made \nbetween two dose units when they are not equivalent. The dose unit used \nfor the Dosing Order Check may not be the same dose unit First Data Bank \n(FDB) returns with the Dosing Order Check results.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by Common Services (CS) or via released\nPharmacy Data Management (PDM) patches. Creating and/or editing locally\ndefined fields in the file are not permitted. \n \nThis file will be used to store CONVERSION FACTORS for DOSE UNIT 1 to\n\n
\nThis file stores rapidly changing drug restrictions, guidelines, and\nprotocols to help assure medications are being used according to formulary\nspecifications.\n\n
\nContains all outpatient RX data used by the outpatient pharmacy package.\nAs the above indicates, this is the hub of the outpatient system. It will\neasily be the largest pharmacy file in time and is pointed to very heavily.\nDeletion of an entry in this file must be handled VERY carefully and is not\nallowed if refills have been issued.\n \nOf particular interest is that essentially all the history pertaining to a\nparticular Rx is contained in each Rx entry.\n\n
\nThis file logs all activity related to remote refills and partial fills. \nThis file will hold actions taken locally on a remote prescription, as \nwell as actions taken by an external facility on any local prescriptions.\n\n
\nThis file holds information to be used for the Prescription Ready\ndisplay and also data to be used to collect work load and waiting\ntime information. Ideally, as the pharmacy receives the Rx\nfrom the patient, the information will be entered into this file.\nwithin the outpatient pharmacy package.\n\n
\nThis file contains user specific preferences for the eRx Holding Queue option.\nIf a specific user does not have an entry in this file, default values apply.\nDefault values are explained in the description of each sub-file in this file.\n\n
\nThis file is used for:\ncan review.\n 1. If the outpatient pharmacy is using the verification feature all \nmedication entered by a non-pharmacist will be identified in this file. The \nlabel is not printed for dispensing until a pharmacist can review the \nmedication and verify that everything is correct.\n 2. The next use of this file is for medications that create drug/drug\ninteractions. While entering new medications, if two or more medications \ncause interactions, and the input is done by a non-pharmacist, the \ninformation about the interaction is stored in the file until a pharmacist \n\n
\nThis file holds pending orders transmitted from the OE/RR package.\nAll orders in this file must be processed by pharmacy service, they\nshould be finished or rejected.\n \n \n \n\n
\nThe purpose of this file is to hold the refill requests that are \ngenerated from the web interface in the My HealtheVet package. Requests \nare filed here, to be processed by pharmacy.\n\n
\nThe purpose of this file is to have a VA FileMan compatible telephone\nrefill processing file. The information is imported from a class III \nnon-VA FileMan compatible vendor file, ^VEXHRX(19080) at the time of\nprocessing. Normally the vendor file will only contain the outpatient\nsite, patient ien and prescription ien.\n\n
\nThis file holds various codes needed by eRx package.\n\n
\nThis file holds the eRx external patient information as received from\nChange Healthcare.\n\n
\nThis file holds the eRx pharmacy information.\n\n
\nThis file holds the eRx external prescriber and supervisor information.\n\n
\nThis file holds the eRx prescriptions received from Change Healthcare.\n\n
\nThis file simply keeps an ordered list of all the prescriptions that have\nbeen put on suspense for a certain date. It is typically used to print\nall prescriptions on suspense for a given date range, usually in order\nof entry. After an entry has been printed, a printed flag is set to\nkeep it from being inadvertantly reprinted.\n \nThe outpatient pharmacy package supplies an option to clean out printed\nprescriptions that have accumulated over time. This is up to the center\nto determine when it will routinely perform this task.\n\n
\nThis file holds all prescriptions that are sent to an External Interface\nat the time of label printing.\n\n
\nThis file contains information regarding who, when and why the\n \nUNDER NO CIRCUMSTANCES SHOULD THE DATA DICTIONARY FOR THIS FILE\n BE MODIFIED\n \nprohibition on a prescription for clozapine was overridden by a\nmember of the team. Because of the nature of this drug and the\nrestrictions placed upon dispensing it, all fields in this file\nare not to be edited through the VAFileManager, but are to be set\nONLY through the order entry options of the outpatient pharmacy\npackage. Reports generated from this file should be generated only\nfrom the option provided by the package. For these reasons, READ,\nWRITE, DELETE and LAYGO access to this file are severely restricted.\n\n
\nThis file stores the automated dispensing devices used by the Outpatient\nPharmacy application.\n\n
\nThis file contains the possible reasons for overriding a Clozapine \nprescription or order lockout.\n\n
\n The IV ADDITIVES file contains drugs which will be used as additives\nin the IV room. Any drug entered in this file must already exist in\nthe DRUG file (50). All drug information relating to its use in the\nIV package is stored in the IV ADDITIVES file. If a drug is no longer\nto be used as an IV additive, DO NOT delete it from the IV ADDITIVE\nfile, but simply inactivate it by entering the date it is to be dis-\ncontinued in the INACTIVATION field.\n\n
\n The IV SOLUTIONS file contains drugs which will be used as the primary\nsolutions in the IV room. Any drug entered in this file must already \nexist in the DRUG file (50). All drug information relating to its use\nin the IV package is stored in the IV SOLUTIONS file. If a drug is no\nlonger to be used as an IV solution, DO NOT delete it from the IV SOLUTIONS\nfile, but simply inactivate it by entering the date it is to be discontinued\nin the INACTIVATION DATE field.\n\n
\nThis file stores copies of information from IV orders that have either\npharmacists so they can pull IVs that are discontinued and prevent them \nfrom being sent to the patient ward and potentially be given in error. \nIt also allows the pharmacist to perform a drug-drug interaction check, \nsince recently discontinued medications can still cause a drug \ninteraction.\n \nTaking action on these records does not impact the actual orders.\nbeen discontinued or edited within the CPRS package. The records in \nthis file are considered temporary and can be deleted through the \nfollowing option:\n \n Non-Verified/Pending Orders [PSJU VBW].\n \nThese records are only intended to help identify discontinued IV orders \nfor a particular ward or a ward group. The records act as alerts for\n\n
\nThis file is used to identify prescriptions that have been archived away.\nThe archived prescriptions may have been also deleted from the Prescription\nfile (#52).\n\n
\nThis file contains Pharmacy Division specific preferences for the ePharmacy\n GROUP BY STATUS: OFF \n DISPLAY ORDER COUNT: ON \nMedication Profile. For divisions without specific preferences in this file,\nthe Outpatient Pharmacy application uses the 'Factory Default', which has the\nfollowing default values: \n \n EXP/CANCEL CUTOFF: 120 DAYS \n SORT BY: DRUG NAME \n SORT ORDER: ASCENDING \n DISPLAY SIG: OFF \n\n
\nThis file (#52.87) is used to capture TRICARE/CHAMPVA bypass\nand override audit information for Outpatient Pharmacy related \nprescriptions. The bypass function circumvents ePharmacy processing for\nTRICARE/CHAMPVA eligible inpatients. The override function allows \ncontinued processing of prescriptions for non-billable products for \nTRICARE/CHAMPVA eligible outpatients as well as prescriptions that reject.\n\n
\nThis file is used to store labels and profiles while printing. This \ninformation is used to reprint a batch of labels and/or profiles if the \nprinter should jam. The option that reprints this information is called \n'Label/Profile Monitor Reprint'.\n\n
\nTransitional Pharmacy Benefit Project (TPB), Phase I (patch PSO*7*145) \nintroduces a new file called TPB ELIGIBILITY file (#52.91), to store \npatient data for those who are enrolled in VHA's health care system and \neligible for the pharmacy benefit as required by the Directive, Code of \nFederal Regulations (CFR) 38 CFR Part 17 RIN 2900-AL68, "Medication \nPrescribed by Non-VA Physicians".\n\n
\nThis file holds the local facility information elements that are to be \nused in printing TPB letters to patients.\n\n
\nThis file holds a list of valid statuses that can be assigned to each Rx\nthat represents the authorization for the Rx. This is independent of the\neligibility code assigned to the patient by MAS. This file also holds the\nparameters that determine if an Rx for a certain status can be refilled, \netc. Data is sent for this file, but can be altered by the center, with\ncare.\n\n
\n Unit Dose Pharmacy orders are initially entered into this file.\n\n
\n Allows the grouping of Unit Dose orders, to facilitate the entry of\nmultiple orders at one time.\n\n
\n A table of explanations for activities on Unit Dose orders.\n\n
\n This is the number of units for an order that the pharmacist needs to\ndispense to the ward for administration to the patient until the next\ncart exchange. The data is deleted when printed.\n\n
\n This file contains labels to be printed for Unit Dose and IV Medication \norders. The labels are deleted when printed.\n\n
\n This is used to log data about the inpatient background job that\nshould being running every night. (The option is 'PSJU BRJ'.)\n\n
\n This file is used to hold data for various reports. This file is used\nmainly to facilitate 'double queueing', which does not tie up a printer\nwhile the report gathers data.\n\n
\n This contains actions the provider has entered for inpatient orders for a \npatient during the order entry process. Once the provider changes patients\nor exits the process, this file is used to print a 10-1158 for the provider.\n \n\n
\n This file is used to tailor the Inpatient Medications package with regards\nto specific users. Some of these parameters (fields) can be set by the\nusers, and others can only be set by an Inpatient supervisor. (A supervisor\nis a user who has been assigned the 'PSJU MGR' security key.)\n This file also contains fields that are used as temporary storage of data\nduring order entry/edit.\n\n
\nThis file is used to allow sites to define the behavior of inpatient orders \nfor outpatients on a clinic-by-clinic basis.\n\n
\n This file holds the abbreviations used when entering the Infusion Rate \n(#.08) field in the IV (#100) multiple of the PHARMACY PATIENT (#55) \nfile, and the INFUSION RATE (#59) field in the NON-VERIFIED ORDERS \n(#53.1) file. \n \nEach record holds an expansion of the abbreviation which replaces the\nabbrevation in the Infusion Rate at the time the IV order is created.\n\n
\n This file is used by the Pharmacy to dispense medications to the various\ninpatient areas of the medical center. The pick list shows the Pharmacy\nwhich orders go to which areas (ward groups), and automatically calculates\nthe amounts to dispense.\n\n
\n Whenever a pick list is sent to the ATC dispensing machine, the data is\nfirst formatted and entered into this file. From this file, the data is\nthen sent to the ATC.\n\n
\nThis file contains the IV parameters set by individual ward.\n\n
\nContains the missing dose requests from the ward that are sent to\npharmacy. This file may be purged as needed by VA Fileman.\n\n
\nContains all report requests generated by users of the BCMA system.\nThis file may be purged as needed by VA Fileman.\n\n
\nThis is the main BCMA Backup system data file. ALL FIELDS ARE POPULATED \nAS A RESULT OF HL7 MESSAGE PROCESSING. NONE OF THE FIELDS SHOULD BE\nEDITED VIA FILE MANAGER. Please refer to individual field descriptions\nfor further information about the contents of the fields.\n\n
\nThis file contains implementation-specific information about the \nFOR MAR (field #1), DEFAULT MAR PRINTER (field #2), PURGE ORDER DAYS \n(field 5), PURGE PATIENT (field 6) and MED-LOG NUMBER (field 7). The\noption BCMA Backup System Parameters Edit (ALPB PARAMS EDIT) is provided\nfor editing of these fields.\ninstallation and use of the BCMA Backup system on the client workstation.\n \nThis file is distributed with a pre-defined entry labelled "ONE". \nFurther, the .01 field for this entry is marked uneditable. This\npre-defined entry should not be deleted. No additional PARAMETERS entries\nshould be made as they will be ignored by the BCMA Backup System.\n \nThere are five fields that can be edited in this file: DEFAULT DAYS \n\n
\nThe Bar Code Medication Administration (BCMA) Unable to Scan Log file is \nto contain information pertaining to BCMA Scanning and BCMA scanning \n"failures". This file has been created in effort to support refinement \nof the BCMA scanning process and BCMA scanning equipment.\n\n
\nContains all variances occurring during the medication passes.\n \nThis file may *NOT* be purged.\n\n
\nContains all medication passes.\n \nThis file may *NOT* be purged.\n \nDue to the size of this file Re-Indexing is also not recommended unless\ndirected by customer support.\n\n
\nThis file contains information regarding who, when and why the\n \nUNDER NO CIRCUMSTANCES SHOULD THE DATA DICTIONARY FOR THIS FILE\n BE MODIFIED\nprohibition on a order for clozapine was overridden \nmember of the team. Because of the nature of this drug and the\nrestrictions placed upon dispensing it, all fields in this file\nare not to be edited through the VA FileManager, but are to be set\nONLY through the order entry options of the inpatient pharmacy\npackage. Reports generated from this file should be generated only\nfrom the option provided by the package. For these reasons, READ,\nWRITE, DELETE and LAYGO access to this file are severely restricted.\n\n
\nThe Network Health Exchange is a program whereby selected hospitals can\nrequest complete or pharmacy Health Summaries from each other.\n\n
\nPATIENT FILE OF ALL PATIENTS WHO HAVE BEEN REGISTERED AT PARTICIPATING\nNETWORK HOSPITALS.\n\n
\nSites authorized to be part of the transfer of patient data.\n\n
\nThis file is maintained at both the National Database and at the local\nsites. It contains all information needed for transmission of the\nNational Rollup data to the National Database. Information is gathered\ninto this file through IBQ Utilization Management menus extracting data\nfrom the IB Claims Tracking package. This file is maintained by menus in\nthe IBQ Utilization Management Rollup package.\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\n\n
\nThis file holds the expansion of the number codes that represent the\n \nData storage moved to PS(54 from DIC(54 with version 7 of Outpatient\nPharmacy.\nadditional warnings/consultations that may be needed for a particular\ndrug. The DRUG file informally points to this file, in much the same\nway that it points to the Medication Instruction file. The field that\npoints to this file is WARNING LABELS and it essentially requires that\nthe numbers entered here be valid entries in this file.\n \nThese numbers are printed on the labels with the idea that the pharmacy\nwould attach the appropriate warning stickers to the bottle.\n\n
\nThis file holds, for each patient, information that is typically of\ninterest only to the pharmacy. This should be noted when merging patient\nrecords and deleting the 'old' record from the patient file. That process\ndoes not delete the corresponding pharmacy patient file entry.\n \nThis file is also shared with inpatient pharmacy and promises to become a\nvery central file to the pharmacy.\n\n
\nThis file contains drug manufacturers.\n\n
\nThe system parameters in this file manage operations of the Consolidated \nMail Outpatient Pharmacy for the medical center. This information controls\nthe transmission of data to the Consolidated Mail Outpatient Pharmacy\nhost facility selected by the medical center. Information in this file \nmust be entered or edited ONLY through the Consolidated Mail Outpatient \nPharmacy package options.\n\n
\nThis file is used by the Consolidated Mail Outpatient Pharmacy system\nat the medical center to manage prescription data for transmission to the\nhost facility. Data in this file is entered, edited, maintained, and purged \nby background jobs triggered by the Consolidated Mail Outpatient Pharmacy \nsoftware and must NOT be edited using VA FileMan. \n\n
\nThis file is used by the Consolidated Mail Outpatient Pharmacy system\nat the medical center to maintain summary information on all pharmacy\nprescription data transmissions created and transmitted to the Consolidated \nMail Outpatient Pharmacy host facility. Data in this file is maintained by \nthe Consolidated Mail Outpatient Pharmacy software and must not be edited \nusing VA FileMan.\n\n
\nThis file is used by the Consolidated Mail Outpatient Pharmacy host \nfacility to maintain information on all participating medical centers which \ntransmit outpatient prescription data for dispensing by the automated \nsystem. Only data received from medical centers designated as active in \nthis file will be accepted by the host facility for processing. Data \nin this file is maintained by the Consolidated Mail Outpatient Pharmacy\nsoftware and must not be edited using VA FileMan.\n\n
\nThis file is maintained at the Consolidated Mail Outpatient Pharmacy host\nfacility and contains summary information for all data transmissions \nreceived from the medical centers. This information is used to manage the\ndownload of transmission data to the automated dispensing system and to \ncontrol the purge of the CMOP DATABASE file (#552.2). Data in this file\nis maintained by the Consolidated Mail Outpatient Pharmacy software and \nmust not be edited using VA FileMan.\n\n
\nThis file is maintained at the Consolidated Mail Outpatient Pharmacy host\nfacility and contains patient prescription orders received in data\ntransmissions from the participating medical centers. Data from this file\nis downloaded to the automated system for dispensing. Once all data for\na transmission is completed by the automated system, the file is purged.\nData in this file is maintained and purged by the Consolidated Mail \nOutpatient Pharmacy software and must not be edited using VA FileMan.\n\n
\nThis file is maintained at the Consolidated Mail Outpatient Pharmacy host\n \n \nfacility and contains release information returned from the automated\ndispensing system. This file manages the background filer operations and \nreturns data received from the automated system at the host facility to\nthe originating medical center for filing. Data is purged from this file\ndaily. Data in this file is maintained by the Consolidated Mail Outpatient\nPharmacy software and must not be edited using VA FileMan.\n \n \n\n
\nThis file is maintained by the Consolidated Mail Outpatient Pharmacy\nsoftware and contains sensitive outpatient prescription dispensing \ninformation for health care facilities which transmit data to the CMOP.\nEditing or deletion of entries in this file is strictly prohibited.\n \nThis file is used by the Consolidated Mail Outpatient Pharmacy system to\nmaintain essential elements for all data transactions. Data in this file is\nmaintained by the Consolidated Mail Outpatient Pharmacy software and must\nnot be edited using VA FileMan.\n\n
\nThis file is used by the Consolidated Mail Outpatient Pharmacy system to\n \nperform drug cost analysis for the host facility. Cost data is maintained \nby medical center/pharmacy division/drug and totals are stored daily and \nmonthly. Data in this file is maintained by the Consolidated Mail\nOutpatient Pharmacy software and must not be edited using VA FileMan.\n \n \n \n \n\n
\nThis file is used by the Consolidated Mail Outpatient Pharmacy system and\n \ncontains information necessary for the operations and management of the\nConsolidated Mail Outpatient Pharmacy interface to the non-DHCP automated\ndispensing system. Data in this file is maintained by the Consolidated Mail \nOutpatient Pharmacy software and must not be edited using VA FileMan.\n \n \n \n \n\n
\nThis file is used by the Consolidated Mail Outpatient Pharmacy system to\ntrack query data exchanges between the automated system and the DHCP CMOP \nhost facility. Data in this file is maintained by the Consolidated Mail\nOutpatient Pharmacy software and must not be edited using VA FileMan.\n\n
\nThis file will contain information regarding the operations of the CMOP\nsoftware. The information will include data on the background jobs which\nrelease prescriptions,file data,print transmission labels, compile cost\ninformation and purge files. Data in this file is maintained by the \nConsolidated Mail Outpatient Pharmacy software and must not be edited \nusing VA FileMan.\n\n
\nThis file is used at CMOP host facilities to track the archiving\nactivities for the CMOP Reference file (552.1) and the CMOP Master\nDatabase file (552.4). Data in this file is maintained by the Consolidated\nMail Outpatient Pharmacy software and must not be edited using VA FileMan.\n\n
\nThis file is used to store DRUG-DRUG interactions. This file will be sent\nout with data. Data can only be added.\n \nLOCAL additions and deletions are allowed.\n\n
\nThe VPR SUBSCRIPTION (#560) file contains parameters needed for tracking\npatient data changes on this VistA system, for updating the Regional\nHealth Connect servers. A dynamic index informs the RHC of records that\nhave been updated for a patient. Monitoring can also be turned off here\nif necessary.\n\n
\nThe VPR CONTAINER (#560.1) file contains information about each container\nclass in the Summary Document Architecture (SDA) data model that has been \nimplemented. The Source File sub-file defines each VistA source for that\ncontainer, and the Entities used to build SDA messages for each source.\n\n
\n This file is used to store order information needed to create IV Fluid\nand Inpatient Medication quick orders.\n\n
\nThis file contains configuration and installation information for the \nPharmacy Product System - National (PPS-N) file retrieval and \ninstallation process.\n\n
\n Allows the user to group the wards from the WARD LOCATION file (42) to\nfacilitate the printing of reports and for other Unit Dose processes.\nWard groups are required for the running of pick lists.\n\n
\n Contains medication amounts and costs for the Unit Dose package. Data\nis entered into this file when pick lists are filed away, and when pre-\nexchange units, extra units dispensed, and returns are entered through the\npackage. Most of the cost reports gather their data from this file.\n\n
\n Allows the user to group beds from various wards together for the\ndispensing of meds, printing of reports, and other Unit Dose processes.\n\n
\n Allows the user to group clinics from the HOSPITAL LOCATION file (44) to\nfacilitate the printing of reports and for other processes.\n\n
\nThis file describes VDEF events. Mostly, these events match the \nlist of events in the HL7 2.4 standard, but there are some cases where\nthere may be multiple entries in this file for a single HL7 standard \nevent.\n \nENTRIES IN THIS FILE SHOULD NOT BE EDITED IN PRODUCTION ACCOUNTS.\n\n
\nThis is a list of the valid subtype codes that are used along with the \n \nExamples: ORU-R01-VTLS (vitals), ORU-R01-CHEM (lab chemistry)\n \nDevelopers must consult with representatives of DaIS before adding entries\nto this file.\n \nTHIS FILE SHOULD NOT BE EDITED IN PRODUCTION ACCOUNTS.\n \nTHIS FILE SHOULD NOT BE EDITED IN PRODUCTION ACCOUNTS.\nHL7 message type and event type to uniquely identify a message to the \nreceiving system. It corresponds to the applications' domain or \nsubdomain when a domain has more than one type of message that it will \nsend to VDEF.\n \nFor example Vitals, Allergies and Lab all send ORU-R01 messages but the \ncontents are vastly different. Each will use a different subtype to make \nthe messages unique.\n\n
\nIdentifies the logical source for a class of requests for HL7 messages. \n \nENTRIES IN THIS FILE SHOULD NOT BE EDITED IN PRODUCTION ACCOUNTS.\n\n
\nContains VDEF Destination information distinguishing between VISTA \nHL7 and FTP Destinations.\n \nENTRIES IN THIS FILE SHOULD NOT BE EDITED IN PRODUCTION ACCOUNTS.\n\n
\nThis file stores all information specific to each individual Request\nQueue. It defines how the entries in each queue will be processed, how\noften the processed entries in the queue will be purged, etc.\n \nThis file also stores all Requests and Request-specific data for this \nqueue, i.e. the parameters passed in by the calling program as well as \nthe information generated while the VDEF Request Processor program is\nhandling this request.\n\n
\nThis file contains information used to control the processing of VDEF \nmessage requests from the VDEF Request Queue.\n\n
\nThe file contains list of packages that are setup to use the VDEF \nsoftware to create HL7 messages. It also stores their activation status.\n \nENTRIES IN THIS FILE SHOULD NOT BE EDITED IN PRODUCTION ACCOUNTS.\n\n
\nThis file defines the items, their location, and quantity for each area\nof use (AOU) in the hospital. Additionally, information for each\ninventory, by item, is stored for an audit trail of usage.\n\n
\nDefines the inventory types which are used to group related items in\nor across areas of use. This file is defined by the user to allow\nmaximum flexibility in adapting to the system of inventory in each\nhospital.\n\n
\nExpansions of the codes used to indicate storage location of item\nin the area of use.\n\n
\nThis file contains information that pertains to each individual inventory \nsuch as date/time of inventory, responsible employee, ID number, and\ninventory group.\n \n*** NOTE *** There is a cross-reference called "AINV" that is not\nVA FileMan compatible and has SACC exemption which allows its use.\nIf you create any local cross-references for this file DO NOT use the\nname "AINV" as this will overwrite the existing cross-reference.\n\n
\nEntries in this file define standard inventories by defining the areas\nuse intended for CS are defined in field #3 - NARCOTIC AREA OF USE (NAOU).\nof use and type of inventory items inventoried. This saves the user\nfrom having to re-define the inventory boundaries every time a particular\ninventory is scheduled. Instead, the user can name inventory groups and\nthe computer then knows what will be inventoried by accessing this file.\n \nThis file is designed to be used by both the Automatic Replenishment/\nWard Stock module and the Controlled Substance module. Areas of use\nintended for AR/WS are defined in field #1 - AREA OF USE (AOU). Areas of\n\n
\nThis file contains information that pertains to backorders, such as the\ndate/time of backorder, the AOU for which the item was backordered, \nand the quantity backordered.\n\n
\nContains a record for all the drugs that are returned to a contractor\nand/or manufacturer for a credit or to be destroyed. It includes drug\nitems that have been credited, denied or are still pending.\n\n
\nContains contractors and/or manufacturers to whom drugs are returned for \ncredit or destruction.\n\n
\nThis file is used as a map to all the data elements defined in the American\nSociety for Automation in Pharmacy (ASAP) data format version 4.0 and above.\n \nThe ASAP data format is used when reporting controlled substance prescriptions\nto the State Prescription Monitoring Program (SPMP).\n\n
\nThis file holds the set of parameters used in the transmission of controlled\nsubstance prescriptions to each State Prescription Monitoring Program (SPMP).\n \nWhile some of the parameters are updated by the user via a menu option, others\nare used internally for automated scheduled transmissions.\n\n
\nThis file is used to maintain information on all controlled substance prescriptions\ntransmitted to the State Prescription Monitoring Program (SPMP). The file is also\nused for manually re-transmitting the data to the SPMP. \n \nThe data in this file is automatically populated and is not editable by the end-user.\n\n
\nThis file contains the data necessary to generate the AMIS statistics\nfor AR/WS. This data is accumulated automatically by a queued nightly\njob.\n \n*** NOTE *** There are two cross-references that exist under this file\nthat are created in the Pharmacy AOU Stock file (#58.1). The xref\nnames are "AMIS" and "AMISERR", if you create any local xrefs for this\nfile (#58.5) DO NOT use these names as it will overwrite the existing\nxrefs.\n\n
\nThe PADE INBOUND TRANSACTIONS (#58.6) file contains Pharmacy Automation \nand Count. Supported transaction associated with a patient include\nDispense, Return, and Waste.\nDispensing Equipment transactions received from PADE dispensing devices.\nThe PADE HL7 transaction is first received by the VistA HL7 Messaging\napplication, where the PADE inbound filer is invoked to create an entry in\nthe PADE INBOUND TRANSACTIONS (#58.6).\n \nThis file creates several cross references designed to facilitate querying\nand reporting of PADE data using various search criteria. Supported\ntransactions that are not associated with a patient include Load, Unload,\n\n
\nThe PADE INVENTORY (#58.601) file contains Pharmacy Automation Dispensing \ndrug item from a dispensing device deletes the drug from the device.\nEquipment (PADE) inventory information. The inventory is kept for a \nspecific PADE dispensing device, however, there may be more than one \nvendor system operating at a site simultaneously, and as a result, \nuniqueness of PADE device name (DISPENSING DEVICE multiple) is only \nguaranteed within the specific vendor entry (PADE INBOUND SYSTEM).\n \nThe total balance for each drug within a PADE device is stored by \ndispensing device, by drawer, and by pocket. Unloading, or de-stocking, a \n\n
\nPharmacy Automated Dispensing Equipment (PADE) devices contain drug items \nThe PADE DISPENSING DEVICE entry must be unique for the PADE INVENTORY \nSYSTEM (#58.601) file entry to which is linked; this file may contain \nmultiple PADE dispensing devices with the same NAME (.01) field value,\nprovided each duplicate name is associated with a different PADE INVENTORY\nSYSTEM file entry. New entries may be added to this file automatically via\nthe PADE HL7 interface.\nthat may be removed to satisfy a pharmacy medication order. An inbound\n(to VistA) HL7 PADE interface receives transactions indicating drug items\nwere added or removed from a specific PADE device. Each dispensing device \nin this file must be associated with a VistA Division and one or more \nhospital locations (Wards, Ward Groups, Clinics, Clinic Groups) in order \nfor inbound PADE transactions to properly update PADE inventory balances \nin the PADE INVENTORY SYSTEM (#58.601) file.\n \n\n
\nThis file is used to link Pharmacy Automated Dispensing Equipment (PADE) \nincoming HL7 message.\n \nLinking PADE users to VistA users is not required for the PADE interface \nor reports to function, it is intended to improve readability of PADE\nreports and obviate the need for cross checking user ID's with the \nexternal PADE database.\nusers with VistA users. When a PADE Inbound HL7 message is received, this \nfile is checked for the user ID and PADE Inbound System combination from\nthe incoming HL7 message. If the user ID and PADE Inbound System \ncombination is not on file, it is filed. If the user ID and PADE Inbound \nSystem combination does exist in this file, the VISTA USER (#2) field is \nchecked to determine if the PADE user has been linked to a VistA user, \nand if it has, the VistA user information is filed in the PADE INBOUND \nTRANSACTION (#58.6) file, along with the PADE user information in the \n\n
\nThis file defines the Pharmacy Automated Dispensing Equipment (PADE)\nsystem like Pyxis, Omnicell, AccuDose, etc., that will be used by the VA\nMedical Centers to stock and to dispense drug/non-drug items in Inpatient\nWards or Outpatient Clinics. Defining the wards/clinics associated with a\ndivision, and mapping to a PADE cabinet (location/area), will allow VistA \nto communicate precisely the outbound messages related to ADT, clinic \nvisits, order details, drug formulary etc.\n\n
\nThis free text area is mapped to a physical cabinet on the PADE vendor\nsystem.\n \nThese are the pre-defined designations on the PADE vendor system where the\nmessages will be sent to.\n\n
\nThis file holds a log of all outbound HL7 Pharmacy Automated Dispensing \nEquipment (PADE) messages. Records in this file older than 30 days will\nbe purged as part of the nightly Inpatient background job (PSGBRJ).\n\n
\nThis file contains data associated with the Pharmacy Drug Accountability\nNAOU Stock Drug [PSD INACTIVATE NAOU STOCK DRUG] is used to inactivate\ndrugs no longer stocked within that NAOU.\nStats location. Entries in this file may be edited but not deleted.\nEntries in this file should NOT be edited directly using VA FileMan.\n \nThis file is designed to be shared between the Drug Accountability module\nand the Controlled Substances module of the Pharmacy software.\nThe Controlled Substances module will recognize a location as a Narcotic\nArea of Use (NAOU). The menu option Inactivate NAOU [PSD INACTIVATE NAOU]\nis used to inactivate NAOUs no longer in use. The menu option Inactivate\n\n
\nThis file contains the data associated with drug accountability\ntransactions. This file is designed to be shared between the\nDrug Accountability module and the Controlled Substances module.\n \nEntries in this file should NOT be edited directly for Controlled\nSubstances use. The CS module contains all appropriate checks for this\nfile's use.\n \nControlled Substances entries will be flagged.\n\n
\nThe DRUG ACCOUNTABILITY ORDER file contains prime vendor pharmacy \norders with all adjustments. The prime vendor invoice data is \nuploaded from the prime vendor. All data is processed and verified\nbefore it increments the drug balances in Drug Accountability \npharmacy locations and master vaults.\n\n
\nThis file contains Supply Items and Order Units used in matching uploaded\n \nThe Prime Vendor ships drugs in a variety of order unit sizes. In some\ninstances, the order unit on a invoiced item does not match the order \nunit in the facility's files. When this occurs the user has to perform a \nmanual match on the item.\n \nBy entering the order unit sent by the Prime Vendor to the order unit in\nVISTA, the matching can be performed automatically during the upload \nprocess.\nPrime Vendor invoice data.\n \nThe user inputs the name of a supply item and the item's corresponding\nVendor Stock Number (VSN). When an item is uploaded from the vendor, the\nDrug Accountability software attempts to identify the item by the NDC.\nIf a match cannot be found, the entries in this file will be checked.\nBy storing the supply items, the user does not have to identify the item\non the invoice as a supply item each time it is uploaded. \n\n
\nThis file contains the order status of the Controlled Substances requests.\n \nThis is a standard file exported with the Controlled Substances module\nand additional entries should not be added. Existing data will be merged.\n\n
\nThis file contains the completion status of the Controlled Substances\norders.\n \nThis is a standard file exported with the Controlled Substances module\nand additional entries should not be added. Existing data will be merged.\n\n
\nThis file contains the standard types of transactions utilized in\npharmacy drug accountability.\n \nThis file is shared between the Drug Accountability module and the\nControlled Substances module.\n \nThis is a standard file exported by both the Controlled Substances and\nDrug Accountability modules and additional entries should not be added.\nExisting data will be merged.\n\n
\nThis file contains the data associated with the Controlled Substances\norder requests. Pharmacy dispenses these orders based on data\ncontained on the worksheet printed from this file. This file is\npurged when orders are delivered to an NAOU or when cancelled.\n \nEntries in this file should NOT be edited directly using VA FileMan.\nThe Controlled Substances module contains the appropriate data\nchecks.\n\n
\nThis file contains the data for all Controlled Substances drugs destroyed.\nThe entries are listed pending destruction until pharmacy destroys\nthe drug and updates this file.\n \nEntries in this file should NOT be edited directly using VA FileMan.\nThe Controlled Substances module contains all necessary data checks.\n\n
\nThis file contains data associated with corrective actions on the\nControlled Substances orders.\n \nEntries in this file should NOT be edited directly using VA FileMan.\n\n
\nThis file contains the Interactive Reader Language (IRL) Program utilized\nby the barcode TRAKKER when performing Controlled Substances perpetual\ninventories.\n \nEntries in this file should NOT be edited directly using VA FileMan.\n \nThis is a standard file exported with the Controlled Substances\nmodule and additional entries should not be added.\n\n
\nThis file contains the errors generated using the barcode TRAKKER\noptions in Controlled Substances.\n \nEntries in this file should NOT be edited directly using VA FileMan.\n \nThis file may expand to include other types of errors tracked within the\nControlled Substances module with future releases.\n\n
\nThis file holds the set of parameters which modify the operation of the\noutpatient pharmacy package to suit the needs of your site. The address\ninformation appears on the labels. Most of the other fields hold\nparameters which enable or disable a particular feature of the package.\n \nThese parameters are loaded into a local variable when entering the\npackage. Any changes made to these parameters will not be effective\nuntil the users exit from the package and re-enters it.\n\n
\nThis file is used to store outpatient pharmacy AMIS data\n\n
\nThis file contains the data for the Outpatient Pharmacy Management Reports.\nIt contains data compiled from the PRESCRIPTION File ^PS(52, FEE BASIS \nPHARMACY INVOICE File ^FBAA(162.1, and Inpatient IV STATS ^PS(50.8 files.\n\n
\nThis file holds waiting time data. For each date, for each division\n \n \n \nidentified in file 59, the total number of requests (visits) and the\ntotal waiting time for each hourly period from 8AM to 5PM (8-9, 9-10\netc.) are stored. Also stored are the total number of requests which\nwere filled but not picked up by the end of the day. Data is put into\nthis file from the prescription ready file (52.11). It is not intended that \ndata in this file be entered or manipulated directly through the VA \nFileManager. The option to use this file is under the Bingo Manager menu \nand is called Bingo Statistical Report.\n\n
\nThis file is used to display the waiting group for the Bingo Board system.\nThis file also determines how and what information is displayed on the\nwaiting room monitor.\n\n
\n Contains the site parameters for the various inpatient packages, giving\nthe various VAMCs the ability to tailor the packages to their needs.\nCurrently shared by the Ward Stock and Unit Dose packages.\n\n
\nThis file is the location of the IV ROOM site parameters.\n \n\n
\n This file is used to tailor various aspects of the Inpatient Medications\npackage with regards to specific wards.\n\n
\n This file contains data that pertains to the entire Pharmacy system of\n 60 - 69.99 Unit Dose\n 70 - 79.99 Drug Accountability\n 80 - 89.99 Pharmacy Data Management\n 90 - 99.99 Pharmacy Benefits Management\n \n THERE SHOULD ONLY BE ONE ENTRY IN THIS FILE.\n Because of the nature of this file and the fact that ALL the Pharmacy\npackages use this file, it is VERY IMPORTANT to stress that sites DO NOT\nedit fields or make local field additions to the Pharmacy System file.\na medical center, and not to any one site or division. The number ranges\nfor the nodes and field numbers are as follows:\n 0 - 9.99 RESERVED\n 10 - 19.99 National Drug File\n 20 - 29.99 Inpatient\n 30 - 39.99 IV's\n 40 - 49.99 Outpatient\n 50 - 59.99 Ward Stock/AR\n\n
\nThis file contains the date and time of when a particular user \ndisabled or enabled the Vendor interface. This will allow site \npersonnel to keep track of when and who disabled or enabled the \nVendor interface in order to facilitate a Vendor update. The \nstatus of the Vendor interface should only be modified \nthrough the Disable Order Checks option when performing a Vendor\ndatabase update.\n\n
\nThis file keeps track of when and for how long the Vendor \ninterface is unavailable. A background process monitors the status of the \ninterface and records in this file when the interface is down,when it\nbecomes available again and the total time it was unavailable.\n\n
\nThis file will be used to store the clinic sort groups. The sort groups\nwill be used to sort action/information profiles. The current sort for\nprofiles is by patient or clinics (a clinic or all clinics). This third\nsort will allow sites to sort by specific clinic group.\n\n
\nThe KERNEL PKI LOGS file is meant to be used by the Kernel team to log \nare extracted from the given SAML TOKEN; therefore it is possible that\nthis data is forged, inaccurate or simply not provided. The main takeaway\nis that we understand who the user said they were using SECID so that we\ncan later compare that to IAM.\n \nThe ERROR MESSAGE FROM API and ERROR MESSAGE FROM RSA fields are meant to \nstore messages reported by the InterSystems APIs. The OTHER MESSAGE field \nis meant to store other messages that maybe relevant to help triage why \nthe SAML TOKEN failed PKI digital signature validation.\nwhich SAML TOKENS would fail PKI digital signature validation. This file \nhas been released in patch XU*8*810. \n \nAt minimum a log entry MUST contain a DATE/TIME CREATED and a SAML TOKEN. \nPlease note that to preserve the byte by byte integrity of the SAML TOKEN \nthe SAML TOKEN has been saved in base64 format.\n \nThe USER'S SECID, FIRST NAME and LAST NAME fields\n\n
\nThis is the file that holds the names and ordering, display of tests.\n\n
\nStores data concerning access of crisis notes.\n\n
\nThis file tracks site specific Blood Bank information for the purpose of\nvalidating and converting data from the following files: Patient (#2) \nand Lab Data (#63). This file also records the number of data elements \nconverted per record and the total number of characters for textual data \nelements per record.\n\n
\nThis file tracks Blood Bank data integrity issues for the following \nfiles: Patient (#2) and Lab Data (#63).\n \nThese issues are checked during the pre-implementation phase of the Blood \nBank data conversion. A record is kept so the Blood Bank ADPACs can\nresolve those issues logged, so clean data can be moved into SQL tables.\n\n
\nThis file will support the quarterly integrity checks required by the \nFDA. It will hold the routine names and the checksums for the routines to \nbe monitored by the Blood Bank team.\n\n
\nThis file exports the names of VistA Blood Bank (LRBL name spaced) options\nthat will be set 'Out of Order' once the data conversion has successfully\ncompleted.\n\n
\nThe purpose of this file is to store different VistA data elements for \nthe purpose of linking them to standard VBEC data elements. \n\n
\nThis file holds VBECS data that will be mapped against the Function Field\n(#61.3) file for antigens/antibodies and the Blood Bank Utility (#65.4) \nfile for transfusion reactions. VistA Antibody/antigen and transfusion\nreaction data for the purposes of mapping is being stored in the VBECS \nMATCHING TABLE (#6005) file.\n\n
\nThis file exports the file and field numbers of VistA Blood Bank (LRBL\nname spaced) data dictionaries that will 'write protect' these files \nand fields once the data conversion has successfully completed.\n\n
\nFile contains psychological tests and interviews supported by\nthe national Mental Health System.\n \nThis file, as officially released, will NOT contain copyrighted tests\nunless a license has been procured through authorized channels.\n \nExported with data.\n\n
\nThis is a dynamic file which stores the results of psychological\ntests and interviews.\n\n
\nFile contains information concerning the licensing of a copyrighted\ntest.\n \nExported with data.\n\n
\nFile contains tests/interviews that were not completed during\na session by an individual patient.\n\n
\nFile allows the user to score multiple instruments\n\n
\nThis file defines the interviews, surveys and tests available in the \nMental Health Assistant. Attributes of the instruments include authoring \ncredits, target populations, normative samples and copyright information. \nActions available including privileging, reporting of full item content \nand transmission to the Mental Health National Database are also specified. \n \nDirect entry via FileMan is prohibited.\n\n
\nThis file contains specification documents that describe each \ninstrument. The specifications are in JSON format. The ENTRY\nSPECIFICATION describes how an instrument should be presented to the\nuser. Future additions will manage the specifications for scoring and\nreporting.\n\n
\nThis file contains a listing of all questions for all Psychological Interviews,\nSurveys and Tests. This allows usage of questions by multiple instruments. \nEach question can also be linked to an entry in the MH INTRODUCTIONS file \n(#601.73), the MH CHOICES file (#601.75), the MH CHOICETYPES file \n(#601.751) and the Hint field (#8) in the MH QUESTIONS file (#601.72). \n\n
\nThis file contains the introductory information given at the beginning of \neach instrument or at the beginning of a new section of an instrument. The \nintroduction text motivates, gives instructions and sets the frame for the \ntask the patient must complete. The same introduction text can be used by \nmultiple instruments.\n\n
\nThis file contains what type of response from the user is required for a \nquestion. Response types contained in the file include MCHOICE (multiple \nchoice), Integers, Strings, Dates, Memos and Currency. These entries are \npointed to the MH QUESTIONS file (#601.72).\n\n
\nThis file contains the individual selections possible in a multiple choice \n(#601.85) as a pointer to the full response.\nquestion. Examples are Yes or No, True or False, 1. Abraham Lincoln, \n2. George Washington, 3. George W. Bush or 4. Richard Nixon. For instruments \nfirst defined in the legacy system MH INSTRUMENT file (#601), a single \ncharacter is specified for a multiple choice answer. If George Washington \nwas the choice selected the legacy value would be 2. \n\nChoices are pointed to by the MH CHOICETYPES file (#601.751) which is a \ncollection of choices. Choices are referenced in the MH ANSWERS file \n\n
\nThis file contains a collection of choices from MH CHOICES file (#601.75) \nand their display sequence. This allows sets of choices to be specified by \nthe MH QUESTIONS file (#601.72). \n\nAn example of an entry would be: 1. True 2. False 3. Undecided \nEach multiple choice question must specify a ChoiceType. In this way a\nChoiceType can be used by multiple instruments and multiple questions.\n\n
\nThis file specifies which entries from the MH QUESTIONS file (#601.72) are \nparts of which instrument in the MH TESTS AND SURVEYS file (#601.71). It is \nthe "table of contents" for an interview, survey or test. Also specified are \nthe sequence of questions and display attributes for the introductions, \nquestions and choices. Display attributes can be bold, underlined and \nfont size for the introductions, questions and choices.\n\n
\nThis file contains a list of interview, survey and test order sets. \n\n
\nTies the entries in the MH BATTERY CONTENTS file (#601.78) to the instruments\nin the MH TESTS AND SURVEYS file (#601.71).\n\n
\nThis file contains a list of all interviews, surveys and tests associated \nwith a entry in the MH BATTERIES file (#601.77). The order of presentation of \nthe interviews, surveys and tests within a battery and which battery belongs \nto which user in the NEW PERSON file (#200) is also specified. \n\n
\nThis file specifies the questions to be skipped (by question IEN) if a rule is \nmet for a given question in a given instrument.\n\n
\nThis file specifies sections within an interview, survey and test. The \nfirst MH QUESTIONS file (#601.72) is specified along with captions (tab and\noverall). Display characteristics can also be set.\n\n
\nThis file contains the rules used in administering an interview, survey or \ntest. A rule is an action that is performed when a specified question is \nanswered in a specified manner. An example of a rule would be to enter \n'Not applicable' to the Question, "Are you pregnant?" if the patient has \nhad a hysterectomy. Rules are complex logic based entries that enables \nthe user to create complex scripts.\n\n
\nThis file ties together an instrument in the MH TESTS AND SURVEYS file \n(#601.71), a question in the MH QUESTIONS file (#601.72) and a rule in the \nMH RULES file (#601.82). This allows a rule to be used in multiple instruments \nand for different questions.\n\n
\nThe MH ADMINISTRATIONS file (#601.84) contains the data collected during the \ninstrument, how many questions were answered and if the test has been \nelectronically signed.\nadministration of a specified instrument from the MH TESTS AND SURVEYS file \n(#601.71) given to a patient at a specific date and time. For each \nadministration of a specified instrument from the MH TESTS AND SURVEYS file \n(#601.71) there will be an entry in this file. \n\nAn entry in this file does not store the results of the instrument's \nadministration but is an index to the instrument's administration. The entry \nindicates whether the instrument has been completed, who ordered the \n\n
\nThis file contains a list of mechanisms by which administrations have \nbeen entered. The list will grow as more devices are used to enter \nmental health tests.\n\n
\nWhen a patient answers a question, the results are stored in this file. An\nentry for each question answered, in each administration is stored. Each \nentry has an MH ADMINISTRATON ID field(#.01) of the MH ADMINISTRATION file\n(#601.84), a Question NUMBER field (#.01) of the MH QUESTIONS file (#601.72)\nand the response.\n\n
\nScaleGroups are collections of MH SCALES file (#601.87) that are logically\ndisplayed together. Information needed to graph the scales are stored\nhere. This includes the ordinate title, minimum and maximum values, graph\nincrements and grid lines.\n \nAll scales need to be associated with a MH SCALEGROUP to be displayed. MH\nSCALEGROUPS file (#601.86) and MH SCALES file (#601.87) allow multiple\nscoring possibilities within a single instrument.\n\n
\nA MH SCALE is one dimension of measurement in an instrument. An example may \nsimply be a TOTAL as in a spelling test or multiple scales in a personality \ndisorder instrument (depression, anxiety, thought disorder etc.). Each scale \nhas at least one associated entry in the MH SCALEGROUP file (#601.86) and\nan entry in the MH SCORING KEYS file (#601.91).\n\n
\nThis file contains the entries to set the Windows display attributes for the \nMH QUESTIONS file (#601.72), MH INTRODUCTIONS file (#601.73) and the MH \nRESPONSE TYPES file (#601.74). Windows display attributes include fonts, \nbolding, underline, colors and columns. \n\n
\nThis file specifies the displayed numeric options that go along with a \nmultiple choice item. Choice type identifiers can be numbered starting from \none, from zero or remain unnumbered.\n\n
\nThis file contains the scoring keys. The scoring keys are the "answer sheet" \nfor the specified scale entry in the MH SCALES file (#601.87). When an\nanswer matches the Target value (ie, is correct) a specified value is\nadded to the score. An example would be: if the question is "How much is\n5 plus 3", the target value would be 8 and 10 points would be added to the\ntotal score (grade) in a ten question test to make a possible score of\n100.\n\n
\nThis file contains results of the scored output of completed instruments.\n\n
\nThis file contains the reporting format for a specified instrument.\n \nInput into this file must be entered only through the Mental Health Editor \nsoftware.\n\n
\nThis file is used as temporary storage space for the interface between the\nMHA3 DLL and Clinical Reminders.\n \nThe data in this file cannot be entered manually and is managed by the \nMHA3 DLL. Data in this file is routinely purged. The data \nin this file is transferred to files MH Administrations 601.84 and MH \nAnswers 601.85 and then deleted when the Clinical Reminder is completed.\n\n
\nAn Instrument Exchange entry contains the specification for one or more \nMental Health instruments, formatted as JSON. An entry can be created in \na source account, then transmitted to destination accounts. In the \ndestination account, the JSON data may be used to update Mental Health\ninstrument files. This allows the specification for Mental Health\ninstruments to be transmitted via a KIDS build or a host file. It \nalso allows instrument specifications to be backed up.\n\n
\nThis file contains infrequently changing documents that represent objects \nhealth instruments.\nin the Mental Health package. These documents are constructed in a \n"web-ready" format, such as JSON. Other formats, such as XML, are also \npossible. Staging pre-compiled documents into this file allows web \napplications to quickly retrieve mental health structures in a consistent \nformat.\n \nExamples of the kinds of documents contained in this file include JSON\nspecifications for mental health instruments and lists of active mental\n\n
\nThis file contains the categories used by the MHA Web application to \norganize the instruments into sub-groups for easier selection.\n\n
\nThis is a list of patients authorized to receive Clozapine. This list is\nmaintained by the National Clozapine Coordinating Center (NCCC) in Dallas.\n\n
\nThis file links the tests used to report the White Blood Count and\nNeutorphil percentage to the Clozapine Roll-Up database in Hines. There\nwill never be more than one entry in this file. This entry will consist of\nthe two test names for the White Blood Count and Neutorphil percentage.\n\n
\nThis file contains various parameters for the Clozapine rollup. No option\nfields TRANSMISSION START, TRANSMISSION END and LAST DEMOGRAPHICS\nTRANSMISSION report back to the NCCC through the server.\nis assigned for the sites to manipulate the data. This file is used and\nmaintained by the National Clozapine Coordinating Center (NCCC) through\nthe YSCLSERVER option. The TRANSMISSION DAY field forces all of the sites\nto transmit on the same day, in the past we had to allow scattered\nreporting due to network limits. We no longer have this problem. All\ntransmissions will occur on Tuesday unless the NCCC in Dallas wishes to\nchange the day. The DEBUG MODE field allows data to be transmitted to a\ntest location without contaminating the database in Hines. The three date\n\n
\nThis file must be populated with the tests used for the WBC and Neutrpohil\ncounts associated with Clozapine.\n\n
\nThis file is used to track HL7 messages that were sent by\nHL7 Optimized (HLO) for tracking Clozapine patients.\nNo clinical data are stored in this file. This file should only\nbe modified by the Clozapine tracking software.\nThis file can be read by any user who has FileMan access and a\n"Y" in their FileMan access code, which is stored in DUZ(0).\n\n
\n ADDICTION SEVERITY INDEX\n FIFTH EDITION\n Locally Developed by D. LaLIBERTE White City VA Domiciliary\nNational Mental Health Software Development: Allan Finkelstein, Ph.D.\n \nThis is the main ASI file and contains all data for each administration.\nIt is a flat file with one record per administration.\nQuestions and format are determined by the publishers of the ASI and may\nnot be locally modified.\n\n
\nThese are the substance abuse program types as defined in the \nsubstance aduse annual report from VA Headquarters.\nThis is a static file and local modifications are not permitted.\n\n
\nThese are the ASI legal codes.\nThis is a static file and local modifications are not permitted.\n\n
\nThese are the ASI codes for liiving arrangement.\nThis is a static file and local modifications are not permitted.\n\n
\nThis is the allowable optins for patient rating in the ASI.\nThis is a static file and local modifications are not permitted.\n\n
\nThese are the routes of drug administration ie nasal.\nThis is a static file and local modifications are not permitted.\n\n
\nAllowable codes for the ASI family history section.\nThis is a static file and local modifications are not permitted.\n\n
\nFollow-up schedule for administering the ASI.\nThis is a static file and local modifications are not permitted.\n\n
\nData and executable code for administering the Addiction Severity Index. Branching,\ndefaults, screen reminders and question wording are here.\nThis is a static file and local modifications are not permitted.\n\n
\nThis is the logic and executable code to produce a report for the\nAddiction Severity Index that reads like a clinician's written report.\nThis is a static file and local modifications are not permitted.\n\n
\nNational ASI code for different abused drugs.\nThis is a static file and local modifications are not permitted.\n\n
\nFile sets site configuration.\nOne and only one record is expected.\n\n
\nThe MH DASHBOARD WIDGET file contains widget information used to display\nspecific Vista fields in the MH Dashboard GUI.\n\n
\nThis is the TOPOGRAPHY file of SNOMED\n\n
\nThis is the MORPHOLOGY file of SNOMED\n\n
\nThis is the ETIOLOGY file of SNOMED\n\n
\nThis is the FUNCTION field of SNOMED\n\n
\nThis is the DISEASE file of SNOMED.\n\n
\nThis is the PROCEDURE file of SNOMED\n\n
\nThis is the OCCUPATION field of SNOMED\n\n
\nFile stores data produced from the Problem List Option of the\nMental Health System.\n \nExported with data.\n\n
\nContain information required for the processing\nof management reports for Seclusion/Restraint.\n\n
\nFile contains brief synopsis of possible causes for seclusion\nand/or restraint of patient.\n \nExported with data.\n \nFILE IS SITE-SPECIFIC.\n\n
\nFile contains description of type of seclusion/restraint administered\nto patient.\n \nExported with data.\n \nFILE IS SITE-SPECIFIC.\n\n
\nFile contains descriptions of behaviors that would permit a patient's\nrelease from seclusion/restraint.\n \nExported with data.\n \nFILE IS SITE-SPECIFIC.\n\n
\nFile contains a list of possible alternative action attempted\nprior to placing patient in seclusion/restraint.\n \nExported with data.\n \nFILE IS SITE-SPECIFIC.\n\n
\nFile contains a list of possible behaviors or situations that may\nbe encountered during a single seclusion/restraint episode.\n \nExported with data.\n \nFILE IS SITE-SPECIFIC.\n\n
\nFile stores information concerning the creation and utilization\nof scheduling for mental health clinics.\n\n
\nThis file contains CURRENT data used by the In-Patient\nFeatures Option of the Mental Health System.\n\n
\nFile stores information concerning indivdual treatment teams assigned\nto wards.\n\n
\nThis is the main data file for Mental Health Inpatient features. It\n AIN ; xref for all admissions by admit date.\n AOUT ; xref for all admissions by discharge/transfer date.\n AST ; xref for current admissions only by ward and team.\n AWC ; xref for current admissions only by ward and team.\n C ; xref for all patients by DFN.\n CP ; xref for current admissions only by DFN.\n\ncontains current and past treatment episodes. Team information, clinician\nresponsibility and treatment data are stored. This is a flat file that\nmay be easily archived and restored.\n\nCross-references:\n AC ; xref for current admissions only by primary therapist.\n ACP ; xref for current admissions only by physician.\n ACR ; xref for current admissions only by resident.\n\n
\nCollection samples for laboratory specimens.\n\n
\nAn urgency status is defined as the priority given to each laboratory\nThese urgencies are not selectable by the user. Also WKL- prevents non-\nlab users from seeing these tests. These urgencies are used to calculate\nLMIP data only.\n These urgencies begin with internal entry numbers of >49 and are\nassigned by the verification process for LMIP data calculation.\ntest, or how quickly that test must be performed by laboratory personnel,\nbased on site-specific criteria. This file contains eight pre-supplied\nurgencies: STAT,ASAP,PRE-OP,CALL RESULT,ADMIT,OUTPATIENT,PURPLE TRIANGLE\n(or service-connected disability) and ROUTINE, each assigned a numerical\npriority, with '1' for 'STAT' being highest priority, and '9' for \n'ROUTINE' being the lowest priority.\n \nNOTE: Workload logic uses a new class of urgencies which are prefixed with 'WKL-'.\n\n
\n \nuses to display the result and the abbreviation. (The abbreviation is\nalso used to report these antibiotics on the specialized 'Infection\nControl' and 'Antibiotic Trends' microbiology reports.\n \n^LAB(62.06,"AJ",'DRUG NODE','INTERPRETATION')=""\n \n^LAB(62.06,"AI",'DRUG NODE') = INTERNAL # ANTIBIOTIC ^ ABBREVIATION\n \n^LAB(62.06,"AI",'DRUG NODE','RESULT') = INTERPRETATION\n \nThis file is used by each laboratory to define specific information\n^LAB(62.06,"AI",'DRUG NODE','RESULT','ORGANISM (INTRP)','SPECIMEN (INTRP)')\n = ALTERNATE INTERPRETATION\n \n^LAB(62.06,"AS",'DRUG NODE') = DEFAULT SCREEN\n \n^LAB(62.06,"AS",'DRUG NODE','ORGANISM (SCREEN)','SPECIMEN (SCREEN)')\n = ALTERNATE SCREEN\n \n^LAB(62.06,"AO",'PRINT ORDER','NUMBER')=""\nabout the types of antibacterial antibiotics your laboratory uses.\n(NOTE: TB drugs do not have entries in this file.) It contains\napproximately 40 pre-supplied entries. Each of the entries may be\ndefined according to the needs of your hospital. Information which\nis site-configurable for each antibiotic includes the sensitivity result\n(S,I or R), the interpretation for each type of result, the type of\nspecimen the antibiotic is used on, the type of template the system\n\n
\nThe execute code file is used to store a variety of program instuctions\n \nCross-reference description:\n \n ^LAB("X",'SUBSCRIPT NAME')=EXECUTE CODE\n \n Note: With the exception of the Error Trap execute code this x-ref has \n been replaced with the program LRX.\n Example: X ^LAB("X","PT") is now D PT^LRX\nthat are used in various programs in the lab package. The best way to\nsee what they areand what they do is to sort them out by type. This\nmay only be of academic interest, since these codes are rarely changed.\n \nThe 'execute code' type entries have been moved from this file to the\nroutine LRX. All of the 'execute code' type entries will be deleted\n(with the exception of the ERROR TRAP entry) when version 5 of lab is\nreleased.\n\n\nThe DELTA CHECKS file contains entries whose use is optional. They are\ncan be used for other reasons such as skipping over entries that do not\nneed to be prompted or for doing calulations on data and storing the\ncalculated results.\nentered in the LABORATORY TEST file (#60) under the site/specimen for the\nfield 'Type of delta check'. The field 'Delta value' may be used or need \nto have an entry depending on the type of delta check. If test results\nare being entered or reviewed for verification on a test that has an entry\nin the 'Type of delta check' field for that site/specimen then the code in\nthe DELTA CHECK file is executed. Usually the delta check is used to prompt\nback to the technologist a warning that there is some inconsistency in the\ndata, so that the data can be rechecked before it is verified. Delta checks\n\n
\nThis file defines the functional laboratory areas. Each area may have\nmultiple accession areas. Entries may be added, but supplied entries\nshould not be modified or deleted. It is pointed to by the COLLECTION\nSAMPLE and ACCESSION TEST GROUP files.\n\n
\nThis file contains the definition of each of the laboratory controls\nof specimen the control 'mimics', tests performed on the control, mean\nand standard deviation values, etc.\nused as part of the laboratory's quality control program. Every lab\ncontrol for which data will be gathered, entered, calculated, recorded\nand/or stored by the system must have an entry in this file. Also to\nbe included as entries in this file are any 'control-like' samples\nwhich might appear on any of your load or work lists (see file #68.2 -\nLOAD/WORK LIST), including references, blanks, water samples or similar\npriming materials. Each lab control name entry is defined by the\nfile, listing information such as expiration date, lot number, type\n\n
\nMaster file controlling how the Lab system interprets the running of\nthe instruments interfaced to the CORE system.\n\n
\nUsed to map standard code system concepts to the related area of the Laboratory\n'normal flora' or SNOMED CT code 30334005 AEROMONAS SALMONICIDA (ORGANISM)\nwhich represents the name of the organism identified.\n \nThis file should not export its data via the standard KIDS data export \nmechanism. Because local codes can have the same identifier as national \ncodes, the KIDS install may inadvertently overwrite local codes. Data \nexports should use a different mechanism, such as using KIDS Transport \nglobal to load the data onto the target system.\npackage database. It supports mapping codes used in the role identifying the\nresult or expressing the answer.\n \nExamples of result codes are LOINC and VA NLT Test Result codes such as\nLOINC code 11475-1 MICROORGANISM IDENTIFIED: PRID:PT:XXX:NOM:CULTURE which\nrepresents the concept of organism identified.\n \nExamples of answer codes are SNOMED CT code 23506009 which is the term\n\n
\nThis file is used to store parameters associated with a Lab Messaging\nsystem configuration.\n\n
\nThis file stores canned text for logging errors or exceptional \nconditions during message processing.\n \nThis file should not be edited locally by the site, but if a local\nmessaging system is developed, and entries must be added, the site\nshould add new entries at entry numbers higher than 999. It is preferred\nthat the local codes be preceded with the three digit primary site number\nwhich would result in a seven digit number, site #_xxxx.\n\n
\nThe entries in this file will determine which entries in the Hospital\nLocation file (#44) will report results through the CareVue interface.\n\n
\nThis file is used to store the messages that are sent or received by the\nLab Messaging system.\nThis file is populated by application routines and should not be edited\nby users.\n\n
\nThis file is basically a dictionary of abbreviated codes or notations\nwhich are used in the laboratory repeatedly. Each one of the 'canned'\ncodes will expand to a full-length message whenever the code is typed\nin at a 'Select COMMENT:' prompt. Using these codes proves to be a \ngreat time-saver for lab users, and is especially helpful to the\nmicrobiology package (notorious for long,long names of bacteria and\nnumerous comments on culture results). The Blood Bank and Anatomic\nPathology modules use this file extensively as well.\n\n
\nList of all Strengths of Reactions.\n\n
\nThis file is used to setup Accession Test Groups (menus for accessioning tests).\n\n
\nThis file holds the information that describes and controls the specimens\nthat make up the shipment of specimens to another facility.\n\n\n
\nThis file records changes made to a shipping manifest. It is used to track\nthe "who, what, when..." of events that occur to a shipping manifest and the\ntest specimens that are on the manifest. It will record when a shipping manifest\nis created, built, closed and shipped. It will also record when test specimens\nare added, removed, shipped, received and completed. The user and the date/time\nof the event and entry are also recorded.\n\n
\nThis file is used to define and described a relationship between two\nfacilities, a collecting facility and a host facility, for the collecting,\nprocessing, receipting and reporting of laboratory testing of clinical\nspecimens. It is used to control the building of shipping manifests which\nare used as shipping documents for the transport of clinical specimens between\nthe facilities which make up the configuration. It controls how the specimens\nare processed at both facilities and the means and methods used to\ncommunicate test orders and results for these two entities.\n\n
\nThis file is used to define the shipping containers used by the Lab Shipping\nManifest. Shipping containers can be of three types:\n Primary: specimen shipped in original collecting container.\n Aliquot: specimen transferred to this type of ontainer prior to shipping.\n Packaging: container used to hold and contain other specimen containers\n during shipping.\n\n
\nThis file is used by Lab Shipping to define the means of transporting a\nshipment to a host facility. Examples could be: courier, commercial shipper.\n\n
\nThis file is used to define the environmental conditions under which\nlaboratory clinical specimens are shipped to another testing facility.\nExamples would be Refrigerated, Ambient Temperature, or Frozen.\n\n
\nThe DSM (#627.7) file holds the DSM-III codes originally stored in the\nDSM3 (#627) file, DSM-III-R codes originally stored in the DSM-III-R\n(#627.5) file, and DSM-IV diagnostic codes. In addition, it will hold\nall codes created be DSM versions following IV. Each entry is unique\nto a DSM version (even if entries are identical) and is identified\nby the DSM VERSION field.\n\n
\nFile contains the results of the Diagnosis Option in the\n"AF" Xref - DFN, Inverse Date, DX, IFN.\n Used for historical listing.\n \n"AG" Xref - Type (DSM or ICD DIAGNOSIS), DFN, Dx, IFN.\n Used for listing duplicate diagnoses.\n \nMental Health System. \n \n"AC" Xref - DFN, Inverse Date, Dx, Status, IFN.\n Used to list dx as Active, Inactive, etc.\n \n"AE" Xref - Type (DSM or ICD DIAGNOSIS), DFN, System Dte, Dx, DFN.\n Used for reference.\n \n\n
\nPatient's laboratory data\n ^LR("AAU",'AUTOPSY DATE/TIME',LRDFN)=""\n \n ^LR("AD",DT,'ORGANISM','ACCESSION'_" ")=LRDFN\n Set when an organism to be reported to the health department is entered.\n \n ^LR(LRDFN,"CH",LRIDT,1,"AC",DUZ,$H)=DATE REPORT COMPLETED^VERIFY PERSON^\n COMMENT (DELETED)\n Set when a comment is deleted from a verified test, used by the routine\n LRDCOM.\n \nCROSS REFERENCE DESCRIPTION:\n ^LR("AEMA",'YEAR SPECIMEN TAKEN','ACCESSION #',LRDFN,'DATE/TIME SPECIMEN TAKEN')=""\n ^LR("AEM",'DATE/TIME SPECIMEN RECEIVED',LRDFN,'DATE/TIME SPECIMEN TAKEN')=""\n Similar x-refs exists for SURGICAL PATHOLOGY: "ASPA" and "ASP"\n CYTOLOGY: "ACYA" and "ACY"\n AUTOPSY: "AAUA" and "AAU"\n \n\n\nThis file is where patient lab data are stored during the archive process.\nIt has the same data definitions as the subfile 63.04 in File #63.\nThis file requires NO editing by the user.\n\n
\nThis file is the HBHC Patient file and contains demographic, admission,\ndischarge, and record transmission data.\n\n
\nThis file contains HBHC Reject/Withdraw Reason data, is exported with\ndata, and is referenced by HBHC Patient (631) file. This file should\nnot be edited or have entries added.\n\n
\nThis file contains HBHC Expressive Communication data, is exported with\ndata, and is referenced by HBHC Patient (631) file. This file should\nnot be edited or have entries added.\n\n
\nThis file contains HBHC Receptive Communication data, is exported with\ndata, and is referenced by HBHC Patient (631) file. This file should\nnot be edited or have entries added.\n\n
\nThis file contains HBHC Provider data. The Provider name field is a\npointer to VA(200).\n\n
\nThis file contains HBHC Type of Visit data, is exported with data, and is\nreferenced by HBHC Visit (632) file. This file should not be edited or\nhave entries added.\n\n
\nThis file contains HBHC Clinic data. The Clinic Name field is a pointer\nto Hospital Location (44) file.\n\n
\nThis file contains HBHC Period of Service data, is exported with data,\nand is referenced by HBHC Patient (631) file. This file should not be\nedited or have entries added.\n\n
\nThis file is the HBHC Valid State Code file and contains state codes\nwhich are site specific. All state codes must exist in State file (#5).\n\n
\nThis file contains HBHC System Parameters data and is exported with one\nDate represents the earliest allowable date for visit data being transmitted\nto Austin, and must be between 6/1/1992 and 12/31/1999. The Number of Visit\nDays to Scan field can be edited by the application coordinator.\nrecord.\n \n *** Note: This file should only contain ONE record. ***\n \nThe Package Name (.01) field contains 'Hospital Based Home Care' and is\nuneditable. The Last Mail Message Date field is maintained by the package\nand is uneditable. The Package Startup Date field is entered by IRM on the\nvirgin installation of the package and is uneditable. The Package Startup\n\n
\nThis file is the HBHC Visit file and includes visit and record transmission\ndata.\n\n
\nThis file contains HBHC Team data and is referenced by HBHC Provider (631.4)\nfile.\n\n
\nThis file contains HBHC Error Messages for Visits data, is exported with data,\nand is referenced by HBHC Visit Error(s) (634.2) file. This file should not be\nedited or have entries added. \n\n
\nThis file represents the HBHC Medical Foster Home (MFH) file and contains \nMFH data pertaining to the home itself.\n\n
\nThis file contains HBHC admission, visit, discharge, and correction records\nfor transmission to Austin. Medical Foster Home (MFH) records will be \nincluded if the site has been sanctioned as a MFH site by VACO.\n\n
\nThis file contains HBHC Evaluation/Admission Errors found during\nverification of records for transmission to Austin. Fields missing\ndata and/or records with data inconsistencies are considered errors. \n\n
\nThis file contains HBHC Visit Errors found during verification of records\nfor transmission to Austin. Fields missing data are considered errors.\n\n
\nThis file contains HBHC Discharge Errors found during verification of\nrecords for transmission to Austin. Fields missing data and/or records\nwith data inconsistencies are considered errors.\n\n
\nThis file contains HBHC Form 6 Correction records awaiting transmission\nto Austin.\n\n
\nThis file is the HBHC Transmit History file and contains data from the last\n12 transmit batches. Data is all maintained by the package, no user input\nis allowed.\n\n
\nThis file contains HBHC Medical Foster Home Errors found during \nverification of records for transmission to Austin. Fields missing data \nand/or records with data inconsistencies are considered errors.\n\n
\nThis file contains the list of WKLD Codes, which are used to compile \n |TAB|THIS FILE SHOULD NOT BE EDITED DIRECTLY. IT IS A STANDARDIZED NATIONAL\nFILE WITH SPECIFIC INFORMATION AT SPECIFIC INTERNAL FILE NUMBERS. NO\nENTRIES SHOULD EVER BE DELETED. ADDITIONAL ENTRIES WILL BE DISTRIBUTED\nVIA GLOBAL TAPE WHEN NECESSARY.\nLaboratory workload statistics.\nThe WKLD codes which refer to specific methods (ie. suffixed codes) are\ncreated at the local site level. They are created either by manual entry\nvia a special option or automatically during verification.\nTHIS FILE SHOULD NOT BE EDITED DIRECTLY. IT IS A STANDARDIZED NATIONAL\nFILE WITH SPECIFIC INFORMATION AT SPECIFIC INTERNAL FILE NUMBERS. NONE\nTHE ENTRIES SHOULD NEVER BE DELETED. ADDITIONAL ENTRIES WILL BE DISTRIBUTED\nVIA GLOBAL TAPE WHEN NECESSARY.\n\n
\nThis file is populated by laboratory software based on DSS's criteria\nThis file has been converted to be used exclusively by DSS software\nto collect laboratory workload for DSS defined products. DSS software\nis responsible for removing the entries from this file based on their\ntime table and file size.\nof laboratory products. The filter logic is coded in the routine\nLRCAPV3. This routine controls/filter which workload codes should be\nplaced into this file.\n \nLaboratory Site file has a field which stop or starts the collection\nof workload data for DSS purposes. Field COLLECT WKLD LOG FILE DATA\n(#616) of the LABORTORY SITE FILE (#69.9) should be edited as required.\n \n\n
\nThis file is used to store extracted DSS clinical data. The calling\n \nThis file is solely for DSS utilization.\n \nCriteria for data extraction of clinical values is specified the DSS LAB\nTESTS (#727.2) file. The file is populated by the DSS Coordinator with the\nadvise of the Laboratory Information Manager (LIM). Populating DSS LAB\nTESTS file without the approval of the LIM will lead to unexpected or\nunreliable data extraction performance.\n \nNormally there is no residual data stored in this file and journaling is\napplication is responsible for purging the data before and after a call is\nnot required.\nmade to the laboratory API routine LRCAPDAR.\n \nThe structure and contents of this file is to support DSS extraction of\nspecific clinical values to monitor patient treatment effectiveness.\n \nThis file is not for local use and should only be used by the DSS calling\napplication.\n\n
\n Non workloaded activities Procedure List\n Not to be added to weighted work load.\nThe file is not implemented with version 5.2. A later version will\nmake use of this file.\n\n
\nLab Electronic Codes file contains a collection of codes used in\nelectronic messaging. Some of these codes originated in established\nrecognized sources (i.e. HL7 tables). Other codes are unique to the\nlaboratory package needs or requirements.\n \nThis file is a standard file for many types of terms used in electronic\nmessaging.\n\n
\nThis file contain LAB ELECTRONIC CODE (#64.061) screen values. These\nentries provide methods to retrieve appropriate codes from 64.061 base on\nintended use.\n\n
\n This file contains the Laboratory Workload data.\n\n
\nThis file contains Laboratory Archive Workload data.\n\n
\n This file contains a listing of National approved Workload Suffix codes.\nThese codes are published by the Director of Pathology and Laboratory\nService VACO.\n THIS FILE SHOULD NOT BE EDITED LOCALLY.\n As new procedure and instrumentation becomes available, additional entries\nwill be distributed to all VAMC sites.\n Forward all request for additional codes not found in this file, contact\nPathology Central Office, Attention Asst. Director for DHCP affairs. \n\n
\n This file contains the lab section to be used.\nThis field is not the lab section which is used at\nthe local site. This entry merely allows the entry of official\nWKLD code data from the CAP manual.\n\n
\n This file contains all of the approved item description used for counting\nWorkload data. \n THIS FILE SHOULD NOT BE EDITED LOCALLY.\n Suitable selection of item for workload count (.ie Tube,Specimen,Block)\n\n
\n This file contains an approved list of Venders/Manufacturer of Laboratory\nequipment or test reagents. This file is used for Workload collection.\n THIS FILE SHOULD NOT BE EDITED LOCALLY\n\n
\nThis file contains the design for the output format for the cummulative\nreport and the supervisor's reports. The formats may be done with tests\ntop to bottom, or left to right; and dates in forward or reverse chronology.\n \n\n
\nThis file is used to define whether or not your site will be generating\nANY location receive automatically generated interims, you must fill in\nthe field 'Queue verified test(s) notice' in the LABORATORY SITE file\n(#69.9) with 'YES'.\ninterim reports of patient lab values and to what locations these reports\nwill be sent or routed. Interim reports are defined as hard copy print-\nouts of a patient's test results which are generated between the times\nthat the permanent chart copy (cumulative) is printed and made available.\nThe entries in the fields of this file also let you determine whether or\nnot to generate these interim reports automatically upon verification\nof the results in the lab, and specify the device (printer) for any of\nthe reports to print on at a given location. NOTE: In order to have\n\n
\n \n \n ^LAC("LRKILL",LRDFN,MAJOR HDR #,MINOR HDR #,CDT,0) = minor hdr #^CDT^IDT\n ^LAC("LRKILL",LRDFN,MAJOR HDR #,MINOR HDR #,CDT,IFN) = test location\n ^LAC("LRKILL",LRDFN,"MISC",1,CDT,0) = IDT^CDT^verify date/time^accession^topography\n ^LAC("LRKILL",LRDFN,"MISC",1,CDT,IFN)= test location\n \nThis file stores temporary pages of the cumulative report.\n \nThe data in this file is maintained by the cumulative routines. \nBecause patient care can be effected if the cumulative report has \nincomplete lab results, you should not edit this file or data contained\nwithin it. Contact your ISC for technical support if problems arise.\n \nCross-reference descriptions:\n\n\nThis file is used primarily as a National Laboratory Test (NLT) database\n \nThe end user never uses this file for day to day laboratory activities. \nupgrade source file. When new/additional NLT codes are released to the\nfield, they are exported in this file. The installation software takes the\nentries from the LAB NLT/CPT CODES (#64.81) and adds them to the WKLD CODE\n(#64) file, then deletes that installed code from this file. If the\ninstallation is successful, this file will be empty. \n \nNORMALLY, THIS FILE HAS NO DATA EXCEPT DURING INITIAL STAGES OF DATABASE\nUPGRADE.\n\n
\nThis file contains the fields that are audited in LAB.\n \nFields listed in this file will show up on various audit reports and \nextracts within the LAB software.\n\n
\nUnits of various blood components\n\n
\nThis file contains donor affiliation groups, collection sites, items related to donor history, and transfusion reaction types.\n\n
\nList of blood donors with demographic, collection, and test data and components prepared from each collection.\n\n
\nFile stores lab consultations and blood donor letters.\n\n
\nBlood products and reagents for blood banks and transfusion services.\n\n
\nProvides mechanism for documenting the mandated validation of the Blood\noutcome of the review, the date/signature of approval and the date\nof implementation. \n \nThis file offers longitudinal tracking of validation of the software\nto include the release of new versions, the installation of patches and\nthe installation of any local modifications.\n \nThe content and the formatting of the file is consistent with the\nworksheets provided in the Blood Bank User Manual and the Technical\nManual and complies with the requirements of the the American\nBank software options. Data entry in the file is NOT intended to \nAssociation of Blood Bank and the Food and Drug Administration.\nreplace the mandated documentation of the validation testing, including:\n(1) observations from testing, e.g. screen prints, logging files, \nprinted reports, written transcriptions, data tapes, data disks, etc.,\n(2) a record/log of unusual occurrences, bugs, deviations from the\nBB User Manual & resoltuion, or (3) final approval by other responsible\nindividuals, including the BB Medical Director and the LIM. It MAY\nbe used to replace the documentation of the review, the acceptability/\n\n
\nThis is the Master Laboratory Test file.\nMaster File Server (MFS), provided by Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive's\n2005-044 effective date shall not be supported.\nIt contains the standardized Lab Test Name and its associated LOINC code.\nThe Lab will associate their local test to this file \n(^LAB(60,test#,1,specimen#)).\n \nPer VHA Directive 2005-044, this file has been "locked down" by Data\nStandardization (DS). The file definition (i.e. data dictionary) shall\nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\n\n
\nThis file is maintaining items needed for lab test interaction with NTRT for Master Lab Test File (MLTF) items.\n\n
\nContains operations/procedures with identified maximum surgical \nblood order schedules (MSBOS).\n\n
\n This file is used as a pick list of blood componets available to be ordered\nby users wishing to make a selection from another DHCP package.\n This file is locally edited by the LIM.\n\n
\nThis is the main file for prosthetic purchasing transactions. AMIS is\ncalculated from this file based on item issued and disability served.\nThis file is also the permanent record for the patient VAF 10-2319 of\nitems issued to the veteran.\n\n
\nThis file contains items that have been flagged as returned or condemned.\nAlso used to store Returned item information.\n\n
\nThis file contains items that have been returned, donated, condemned, or \non loan\n\n
\nThis is the ITEM MASTER file for Prosthetics that points to File 441,\nIFCAP ITEM MASTER file. The main purpose of this file is to store\nAMIS codes for prosthetic items.\n\n
\nThis is a standardized Prosthetic HCPCS file that contains HCPCS code\nused in Prosthetics. Sites are not allowed to update, add, edit or delete\nentries from this file. Only the SYNONYM and ITEM fields are editable,\nand can be edited in the sites, all other fields will only be updated by\nthe Prosthetics Data Validation Group and update nationally will\ntake place through a patch.\n\n
\nThis file contains all unique (Prosthetics Sensory and Aids Service) PSAS\nHCPCS Items for all stations or divisions under one computer system.\n\n
\nThis is a Prosthetics Stock Item Record file that holds all issue and\nstock control records. This is the main file for Prosthetics inventory\nas in form 10-1210. All transactions that pertains to an item being\ntrack is keep in this file.\n\n
\nThis is a Prosthetics Location file that contains all locations and items\nbeing tracked for inventory. Never delete a location or item from this\nfile. Use option Remove Item from Inventory to deactivate an Item.\n\n
\nThis file holds the re-order quantity for a given HCPCS item at a given \nLOCATION and STATION.\n\n
\nThis file holds the PSAS HCPCS order and reorder entries. An entry is\ncreated when an order is entered or created by the user.\n\n
\nThis file holds the name, address and station number of each stock\nlocation. There will be an index by Station Number and Location Name.\n\n
\nThis file records each transaction as it pertains to inventory.\n\n
\nThis file is used to hold pointers to the patient 2319 file (660).\n HCPC item, vendor, location and unit of measure.\n \n661.63 - record pointers to the 660 and 661.6 file records just created.\n \n661.7 - reduce stock quantity and value by issued quantity and value.\n If the new stock quantity for the stock date and location is\n 0 then delete the record.\nEach time a stock item is issued to a veteran the following files will be\nupdated...\n \n660 - Create record of Prosthetic Appliance/Repair (patient's 2319)\n \n661.6 - Create Prosthetic Inventory Transaction record\n \n661.4 - reduce stock on-hand quantity and value by issued amounts for\n\n
\nThis file implements the concept of 'First In First Out' (FIFO) stock\nThis file can then be used to look up locations containing the oldest\nstock for any given HCPC item.\n \nWhen items are removed from stock the associated vendor and location will\nbe identified by scanning a bar code (or manual entry in case of equipment\nproblems). The system will then assume that the oldest item for the vendor\nand location has been issued and will reduce the stock quantity. If the\nquantity becomes 0 or -ve the record will be deleted.\naccounting.\n \nWhenever stock items are brought into stock on a given date an entry will\nbe created for that date for the relevant HCPC item, location, vendor and\nunit of measure. The date will include time to cater for the rare instance\nwhere the same stock item with the same vendor, location and unit of\nmeasure is brought into stock on the same day but with a different cost.\n \n\n
\nThis file is not being used at present. It will be used for barcode\nimplementation.\n\n
\nThis file holds the running balance of an inventory for every HCPCS and\nHCPCS ITEM for a particular station. All transactions created using\nthe Stock Issue options and Prosthetics Inventory Program (PIP) will have\nan entry in this file in chronological order indexed by Station, HCPCS and\ndate.\n\n
\nContains disability codes related to patient prosthetic disabilities.\nThese disability codes are viewed on the patient VAF 10-2319 record to\ndetermine eligibility.\n\n
\nContains prosthetic AMIS codes assigned to each item purchased for a\nveteran. File 661, PROS ITEM MASTER, points to this file. Do not edit\nthese codes.\n\n
\nThis file holds the current AMIS totals for prosthetics. Only one\nAMIS report (the most current) is stored in this file.\n\n
\nThis file contains the category names that the prosthetic disability codes\nwill fall under. When AMIS is generated, the calculations for the quarter\nwill be stored as temporary information in this file.\n\n
\nContains Scheduled Clinic Visit information to be printed on VAF 10-2527\nand AMIS calculations.\n\n
\nThis is a bridge file used to temporarily store purchasing information\nthat links with the 1358 DAILY RECORD (#424) file prior to close out.\nPurging for this file occurs annually AFTER the Integrated Funds Control, \nAccounting, and Procurement (IFCAP) purge process occurs, using the same\nfiscal year. The Purge Aged Purchasing Transactions [RMPR PURGE AGED]\noption is used for the annual purge.\n\n
\n \nconsolidated record of prosthetic items and services furnished to eligible\nveterans.\nThis file will contain all information related to providing a patient with\nitems/services via the automated VAF 10-2529-3. The items/services will be\nprovided locally by the Orthotic Laboratory, Restoration Laboratory, or \nWheelchair Repair Shops or remote services such as the Denver Distribution \nCenter, National Foot Center, or a remote Orthotic Laboratory.\n \nThis file is the main file for the Prosthetic Lab module. Request and\nReceipt for Prosthetic Appliances or Services, which is used to maintain a\n\n
\nThis file contains VAF 10-2529-3 Work Order information that will be\nstored for AMIS calculations. This file will only be updated if the\nfacility has an active Prosthetic Lab.\n\n
\nThis file will contain dates, rates, and hours of Lab Technicians that have\nfabricated, fitted or repaired a prosthetic item/service.\n\n
\nThis file will hold an entry for each time the Lab AMIS is generated.\n\n
\nThis file holds vital 10-2319 patient information. Included is PSC,\nAuto Adaptive Equipment, Clothing Allowance, Hearing Aid,\nReturned Status and other critical patient data.\n\n
\nThis file contains information regarding prosthetic home/liaison visits\nthat are to be counted on AMIS.\n\n
\nContains skeleton letters for Prosthetics.\n\n
\nThis file stores all patient letters generated by prosthetic\npurchasing agents.\n\n
\nThis file contains monthly billing transactions for home oxygen patients \nfiled by site, by month, by patient, by vendor, and by item.\n\n
\nThis file contains information on vehicles and vehicle auto-adaptive\nequipment related to Prosthetics.\n\n
\nThis file contains auto-adaptive equipment and van modification\nequipment.\n\n
\nThis file contains automotive manufacturers.\n\n
\nThis file contains all items that are added as new, repair, or van\nmodifications to be counted on AMIS.\n\n
\nProsthetic Suspense file used to contain information regarding pending Prosthetic requests and orders. This file contains both Manual and CPRS Orders.\nThere are two main types of suspense items, MANUAL and CPRS via Consult\nTracking.\n \nWhen a suspense is added to Prosthetics the status is OPEN. Once an \ninitial action is taken on the suspense record, the status changes from \nOPEN to PENDING. The status remains PENDING when additional action is \ntaken on a suspense record. The status is changed to CLOSED when the \nprocess is complete and either service was performed or an item was given \nto the patient.\n \n\n
\nThis file will contain the current work order number for the VAF 10-2529-3\nthat has been initiated and send to the local Prosthetic Lab. VAF\n10-2529-3s that are sent to a remote procurment source will not have work\norder numbers.\n\n
\nThis file holds the list of parameters which can change the operation\nNever edit or delete the AMIS GROUPER field.\nNever delete an entry in this file, only edit it.\nof the prosthetics package at a site. \nIt should be noted that these parameters are generally copied into a\nlocal variable when entering the prosthetics program. This means that,\nin general, a change to this file will not take effect until the users\ncurrently using the package leave the prosthetics system and come back\ninto it again.\nThis file may have one or more entries. During the installation process,\nsome of the parameters for the first site may be set for you.\n\n
\nReferral patients who do not have an SSN or Pseudo-SSN may be added to this\nfile. If the patient HAS an SSN or Pseudo-SSN, they should be in the\nPatient file!\n ONLY BILLABLE PATIENTS SHOULD BE ENTERED INTO THIS FILE !\n\n
\nThis file contains the names of research entities (i.e. patients,\nanimals, tissues, etc.).\n\n
\nThis file is for names of sterilizers in the hospital.\n\n
\nThis file is used by laboratory to enter names for environmental\ncultures or cultures of other inanimate entities.\n\n
\n This file will be developed in later version to support non workloaded\nfunctions. ie TQI,QC\n\n
\n This file is used to collect workload data in preparation for\ntransmission to the National Data Base. Each months LMIP reportable\nstatistics is compiled into this file. The file is reviewed by the\nLaboratory Approving Official, the a mail message is prepared and\nforwarded to the user. The user in turn forwards the mail message to\nthe appropriate Domain.\n This file should be archived before purging the data.\n \n THIS FILE SHOULD NOT BE LOCALLY EDITED.\n\n
\n This file contains archived LAB MONTHLY WORKLOADS file data. It\nis an exact copy of ^LRO(67.9 but is designed to be deleted from the\nsystem to free disk space. I can also be restored with out overlaying\ncurrent data.\n Not all sites will make use of this file. If this file is used then\nhistorical reports are possible. This file should be populated before\nthe LAB MONTHLY WORKLOADS [^LRO(67.9)] global is purged from the system.\n\n
\n \nperformed in the area will be displayed and other specific information.\n \nDefinitions of variables used:\n LRDFN = Internal entry in LR( that is being worked on.\n LRIDT = Inverse date/time that data is stored at. ^LR(LRDFN,"CH",\n LRAA = internal value of accession area ^LRO(68,\n LRAD = date working on in accession area ^LRO(68,LRAA,1,\n LRAN = accession number working on ^LRO(68,LRAA,1,LRAD,1,\n LRODT = order date ^LRO(69,\n LRSN = order entry within date ^LRO(69,LRORD,1,\nThis file contains entries which represent the functional subdivisions\nCROSS REFERENCE DESCRIPTION:\n ^LRO(68,"B",'ACCESSION AREA',LRAA)\n ^LRO(68,"AC",LRDFN,'DATE RESULTS AVAILABLE','DATA NODE') =\n used by the cumulative\n ^LRO(68,"AD",'LAB SECTION',LRAC)\n ^LRO(68,"AVS",LRAA,LRAD,LRAN)=LRDFN^LRIDT\n used by micro verify by supervisor\n ^LRO(68,"MI",LRDFN,LRIDT)\n used by micro for cumulative report\n ^LRO(68,LRAA,1,LRAD,1,LRAN,"AE")\nor departments of the laboratory, referred to by the Laboratory package\n used for WKLD count\n \n ^LRO(68,LRAA,1,LRAD,1,"B",'ENTRY FILE 69',LRAN)\n ^LRO(68,LRAA,1,LRAD,1,"C",'IDENTITY',LRAN)\n ^LRO(68,LRAA,1,LRAD,1,"E",'LAB ARRIVAL TIME',LRAN)\n ^LRO(68,LRAA,1,LRAD,1,"D",'ORDER #',LRAN)\n ^LRO(68,LRAA,1,LRAD,1,"AC",'DATE/TIME COMPLETE',LRAN)\n ^LRO(68,LRAA,1,LRAD,1,"AD",'DATE COMPLETE',LRAN)\n ^LRO(68,LRAA,1,LRAD,4,"B",'LAB TEST',LRAN)\nsoftware as accession areas. The file is used to define the site-specific\ninformation needed by your laboratory for each accession area. This \nincludes the type of accession transform (or how often the accession \nnumbers assigned to test performed in that area will be reset to 1), the\nabbreviation of the area (which becomes part of the accession identifying\nthe specimen and test results), the order in which the data for tests\n\n
\nDEFINES THE LOAD/WORK LIST TO BE MADE FROM THE ACCESSION LIST\nThe ^LRO(68.2,LRINST,10,LRPROF,1,"AO",TEST) = ORDER X-ref is setup by\n BUILD^LRLLP4 and holds the order to print the tests on the load/work list.\n\n
\nThis file controls the orderly sequence of lab test ordering. All ordering\n ^LRO(69,"C",'ORDER #',LRODT,LRSN)\n ^LRO(69,LRODT,1,"AA",LRDFN,LRSN) = Used by LROS (order status)\n ^LRO(69,"AT",LRDFN,LRTEST,LRSREC,LRODT) = "" This is used for maximum test order frequency.\n >>> THIS GROUP IS SET AT THE TIME OF VERIFICATION IF NOT A CONTROL. <<<\n ^LRO(69,DT,1,"AC",'REPORT ROUTING LOCATION',LRSN) = "" or 1\n Used by some of the reporting routines and collection list\n (set to 1 when on collection list)\n ^LRO(69,'DATE RESULTS AVAILABLE',1,"AR",'LOCATION','PT. NAME',LRDFN)\n This is used by the daily cummulative\n ^LRO(69,DT,1,"AR",'LOCATION','PT. NAME',LRDFN) = ""\ninformation is stored in the ^LRO global. This file is pointed to by many\n ^LRO(69,DT,1,"AN",'LOCATION',LRDFN,LRIDT) = ""\n ^LRO(69,'DRAW DATE',1,"AL",'LOCATION',PNM,LRDFN) = ""\n ^LRO(69,'DRAW DATE',1,"AP",'DOC NAME',PNM,LRDFN) = ""\n ^LRO(69,"AN",'LOCATION',LRDFN,LRIDT) = ""\n Used by LRWD to give a list of patients with new lab data since\n the start of the day.\n ^LRO(69,DT,1,"AD",'REPORT ROUTING LOCATION',LRDFN,LRSN)= "" Used by the cumm\nother files, and supplies information for order entry and order status \noutput. No editing of the entries should take place, as it may cause\ncorruption or loss of ordering information. The file contains print and \nsort templates that are used by a variety of lab routines and options to\nformat reports.\n \nCROSS REFERENCE DESCRIPTION:\n\n
\nThis contains the lab collection list entries.\n \n ^LRO(69.1,"LRPH",division,location rm/bed, LRDFN,spec)=col samp^LC^build date/time^acc date/time^DA\n ^LRO(69.1,"LRPH",division,location,rm/bed,LRDFN,spec,acc area,acc #,test)=test\n\n
\nThis file used to hold print headers for anatomic path reports and as a temporary holding file for path cumulative, incomplete and complete reports.\n It may also be used for any accession area file since the NAME (.01) field is a pointer to the accession area file (68).\n\n
\nThis file contains additional search and extract parameters to be used \nby the Laboratory Search/Extract software. These parameters are not \nspecific to entries in LAB SEARCH/EXTRACT file (#69.5), but are \nspecific to the Protocol (refer to Protocol file #101) being used.\n\n
\nThis file contains search criteria used by the Laboratory \nSearch/Extract software. This file should only be edited using \nthe Search/Extract Parameter Setup option [LREPI PARAMETER SETUP] provided with this software.\n\n\n
\nThis file holds a pointer to the REMINDER DEFINITION (#811.9) file for\nuse by the Emerging Pathogens Initiative (EPI). The entries in this file\nare used to determine which Clinical Reminders will be used to generate\ndata for the Hepatitis C registry.\n\n
\nLab Orders Pending file serves as a temporary storage locations for\n \nWhen the results have been stored in the collecting site's patient\nclinical record, entries will be purged from this file.\n \nNOTE: The user should not directly edit this file via FileMan. Appropriate\noptions are provided to manage the data in this file.\nelectronic laboratory test orders. LEDI software populates and manages the\ncontents of this file.\n \nElectronic test orders from VA collecting sites are stored in this file\nuntil ordered test results have been returned. Electronic orders are\nmatched with physically shipped specimen during accessioning process.\nSpecimen processing status update information is also stored in this file\nto assist in the management of workload.\n\n
\nThis file is used to capture and retain the specimen demographics.\n\n
\nThis file holds specific information which defines certain site parameters\nrelating to the actual functioning of your laboratory. The parameters\ninclude the official laboratory site name, whether the physician's name must\nbe entered when ordering and/or accessioning tests, what type of accession\nlabel format (if any) the lab will be using, and scheduled hours of routine\nphlebotomy collection times, as well as others.\n\n
\n This file contains routine size (^%ZOSF("SIZE")) AND ROUTINE BIT\nSIZE (^LRNITEG) FOR EXPORTED LAB PACKAGES BY VERSION NUMBER.\n CAN BE USED TO IDENTIFY DIFFERENCE BETWEEN VERSION'S ROUTINE AND\nTO DOUBLE CHECK PATCH APPLICATIONS.\n\n\nThis file stores medicine patients' DINUM to the PATIENT file and also\nkeeps a cross-reference of procedures done on a patient.\n\n
\nThis file contains information on the existence of related DHCP packages\n(OE/RR, PCC, Imaging) at this site.\n\n
\nThis file allows Order Entry and Health Summary to pick-up the fields\nwithin the Medicine Data base.\n\n
\nThis file contains ASTM codes for the HL7 messaging builder for Medicine.\n\n
\nThis file is used by the Medicine device clinical interface to\ndetermine which clinical instrument routine is to process the data passed\nfrom HL7. In the event of an error this file will contain the\ncorresponding Mail Group that will be notified.\n\n
\nThis file supports the loading of Patient Care Component (PCC) visit\nrelated procedure information for sites running QueryMan.\n\n
\nThis file contains the list of entries that were converted.\n\n
\nThis file stores data on Echo procedures done on a patient.\n\n
\nTHIS FILE STORES THE DATA ON 'CATHERIZATIONS' DONE ON PATIENTS\n\n
\nThis file stores data on EKGs done on a patient.\n\n
\nThis file stores data for Holter tests done on a patient.\n\n
\nThis file stores data on Exercise Tolerance Tests done on a patient.\n\n
\nStores (along with ATRIAL STUDY and VENTRICULAR STUDY files) data on\nElectrophysiologies done on a patient.\n\n
\nStores data for Atrial studies done for a particular EP procedure. Data\nis entered into this file through EP options.\n\n
\nUsed by developers to contain information that governs the performance\nof selected options. When choices have to be made and there is no clear\nconsensus among stations as to which choice is most advantageous, an\nattempt is usually made to make the subject parameter site selectable\nby including it in this file.\n\n
\nContains applicable divisions for a multi-divisional facility.\n\n
\nFile of screens used by Engineering Screen Handler.\n\n
\nThis file contains default PM (preventive maintenance) parameters for\ndevice types. The intent is to give facilities a means of scheduling\nPM inspections for a given device type (defibrillator, transformer,\nelectrical generator, etc) without having to explicitly edit the\nrecord of each individual piece of equipment. If the PM parameters in the\nEQUIPMENT file (File 6914) do not agree with the corresponding PM parameters\nin this file, the information in the EQUIPMENT file will take precedence.\n\n
\nList of manufacturers. Centrally maintained, courtesy of Engineering\nService Center, St. Louis. Local entries may be added using a MFGID of\n50000 or greater.\n\n
\nRepository of all capital assets. Typically used by Engineering and\nAcquisition and Materiel Management Services. Capitalized nonexpendable\nequipment records in this file are electronically ported to the\ncentralized VA data base (Fixed Assets Package) in Austin.\n\n
\nConsolidated Memoranda of Receipt in use at your facility. Basic\ninstrument for establishing accountability for non-expendable\nequipment.\n\n
\nFile of formal procedures used at the host site in the performance of\nscheduled maintenance (PMI). If a facility wants their source documents\nin electronic format and is willing to accept the limitations of the\nFileMan word-processing editor, then the actual step by step text of a\nPM Procedure may be stored in this file.\n\n
\nFile of Standard General Ledgers (SGL) appropriate for capitalized\nnon-expendable (NX) equipment. This file should not be locally modified.\n\n
\nFile of Budget Object Codes (BOC) appropriate for capitalized\nnon-expendable (NX) equipment. This file should not be locally modified.\n\n
\nFile of Funds appropriate for capitalized non-expendable (NX) equipment.\nThis file should not be locally modified.\n\n
\nFile of Administration/Offices (A/O) appropriate for capitalized\nnon-expendable (NX) equipment. This file should not be locally modified.\n\n
\nFile of Disposition Methods appropriate for capitalized\nnon-expendable (NX) equipment. This file should not be locally modified.\n\n
\nThis file contains the standard department codes for Equipment Inventory\nListings (EIL) as determined by OA&MM in VACO. It is used to derive the\ncost center of equipment and to validate the CMR field for FA and FR\nDocuments.\n\n
\nList of reasons for creation of an adjustment voucher to a Fixed Asset\n(FAP) Document.\n\n
\nFile of FA documents sent to Fixed Assets. This file should not be locally\nmodified.\n\n
\nFile of FB documents sent to Fixed Assets. This file should not be locally\nmodified.\n\n
\nFile of FC documents sent to Fixed Assets. This file should not be locally\nmodified.\n\n
\nFile of FD documents sent to Fixed Assets. This file should not be locally\nmodified.\n\n
\nFile of FR documents sent to Fixed Assets. This file should not be locally\nmodified.\n\n
\nThis file contains monthly closing dollar balances by station, fund, and\nneccessary. See the Recalculate FAP Balances option for more information.\n \nThis file must not be directly edited or locally modified.\nstandard general ledger for capitalized non-expendable equipment. The\nvalues for the current month are automatically updated when Fixed Assets\n(FAP) Documents are transmitted. If there has not been any activity in a\ngiven month the dollar balance for that month can be obtained by looking\nat the preceeding month which has a value.\n \nThe dollar balances are solely based on FAP Document code sheets. The\nvalues in this file can be recalculated from the FAP Documents if\n\n
\nUsed for submission of an annual report on Biomedical Engineering\nResources. This report is prepared by each site and submitted to\nthe National Engineering Service Center in St. Louis.\n\n
\nThis file contains versions of the hand receipt text displayed to\nusers when they accept responsibility for IT equipment. The text\nversions are distributed via nationally issued patches to the\nEngineering package. For each version a checksum is calculated to\ndetect unauthorized modifications.\n\n
\nThis file contains assignments of responsibility for IT equipment. The \ndata is only intended to be updated via package options. Key data values \nare protected by encryption once the owner has accepted responsibility \nvia electronic signature.\n\n
\nClassification scheme for non-expendable equipment.\n\n
\nRecord of all transactions made via the NX Y2K Equipment Management Module\n(patch EN*7*51).\n \nFile to be deleted some time after the year 20000.\n\n
\nA VA standard list of major utility systems that are of interest from a\nFacility Management point of view.\n\n
\nPermanent record of every archival episode performed within the\nEngineering Package.\n\n
\nStores data for Ventricular studies associated with a particular EP.\nData to this file is entered through the EP options.\n\n
\nRepository of all work requests directed to Engineering Service.\nMain file used by the Work Order Module.\n\n
\nStandardized file of Engineering work actions. Introduced with\nEngineering Version 7. A single work order may have more than\none work action associated with it.\n\n
\nInformation taken from accident reports.\n\n
\nStandardized functional activities.\n\n
\nPhysiological manifestation of accident.\n\n
\nFile of functional divisions within a Medical Center for purposes\nof cataloging Accident Reports.\n\n
\nFile of delegated projects. Fund amounts should be recorded in whole\ndollars only.\n\n
\nFile of Construction Project Statuses.\n\n
\nThis file contains a list of EPA Reporting categories which are used to\ngenerate the A-106 report required by the Environmental Protection Agency\nfor NRM environmental projects.\n\n
\nThis file contains the names of employees who have been issued keys\nand the keys they have been issued.\n\n
\nInformation concerning locks used in the Medical Center; such as control\nkeys, master keys, pathways, etc.\n\n
\nMain file used by the space module. It contains detailed information\non each room within the Medical Center.\n\n
\nFunctional areas commonly found in VA facilities.\n\n
\nCommon hospital utilities.\n\n
\nA simple file of physical buildings. A 'division designation' may\nbe included if needed to distinguish between two buildings having\nthe same number. Suppose, for example, there were two buildings\nnumbered 100 at VAMC St. Louis, one at the John Cochran Division\nand one at Jefferson Barracks. These two buildings could be entered\nseparately as 100-JC and 100-JB; where 'JB' and 'JC' are division\ndesignators. The same strategy may be useful at facilities that\nsupport outpatient clinics, Regional Offices, national cemeteries,\netc.\n\n
\nShould contain all Engineering employees who may be associated with\na Work Order, whether or not they actually have access to this\ncomputer.\n\n
\nListing of allowable Echo conclusions for use in Echo option and\nlisting of Hematology Bone Marrow descriptions.\n\n
\nThis file holds interpretations for Cardiac Catheterization and PFT\nstudies.\n\n
\nThis file holds the interpretations for ECG procedures.\n\n
\nThis file holds the placement sites for use in cardiac catheterization.\n\n
\nThis file holds the allowable interventions for EP procedures.\n\n
\nThis file is used by the Engineering package to store minimal information \nis on online.\n \nThe information stored in this file will be used by a web service running \nin VistA that is capable of triggering a remote procedure call (RPC) back\nto VistA to extract additional information about the record that was\nchanged. There is no direct user interaction with any of the fields in\nthis file. The content is handled via triggers in the Engineering files\nbeing tracked. Initially files #6914 and #6928 are being tracked but other\nfiles could be added in the future if needed.\nof file entries that have been modified and that need to be forwarded to\nIntelligent Insites (RTLS). Records added to this file will have a very \nshort life while they wait for a queue process to send them to RTLS.\n \nThe option 'VIAA MAKE WEB CALL TO MULE' has to be used to schedule a queue\nprocess that can run periodically via Task Manager at a time interval \nsuitable to the site. Once a file entry is sent to RTLS, it is cleaned up\nimmediately, so this file will stay empty most of the time as long as RTLS\n\n
\nStores results of Bone Marrow Aspirates and Bone Marrow Biopsies.\n\n
\nThis file holds the indication for procedures for the various medical\nprocedures.\n\n
\nThis file holds data for use on Surgical Risk Assessment form.\n\n
\nThis file provides linkage between Medicine procedures and various\nstandard coding schemes. It also allows procedures to be called by the\nterm of the users choice.\n\n
\nThis file stores the medications used in the various Medicine procedures.\n\n
\nThis file stores the regional wall motions associated with ECHO\nprocedures.\n\n
\nThis file stores the various procedure types of cardiac catheterization.\n\n
\nFile holds the various types of risk factors that can affect a procedure.\n\n
\nThis file stores the various symptoms associated with the various medical\nprocedures.\n\n
\nThis file stores the various types of catheters used in catheterization.\n\n
\nThis file stores the various reasons for stopping of Exercise Tolerance\nTests, the reason for Generator/Lead changes for Pacemaker, and the\nreason for transmitting a Pacemaker report to the National Center.\n\n
\nThis file stores the normality of the cardiac vessels for use by the\nCATHETERIZATION file.\n\n
\nThis file stores the coronary artery segments for use by the\nCATHETERIZATION file.\n\n
\nThis file stores the lesion percentage for various segments of the Cardiac\nCatheterization procedures.\n\n
\nThis file holds the various morphologies pointed to by the MORPHOLOGY\nsubfields of the CARDIAC CATHETERIZATION file.\n\n
\nThis file stores the allowable morphologies for distal vessels. It is\npointed to by the CARDIAC CATHETERIZATION file.\n\n
\nThis file contains the various locations for the bypass graft segment. It\nis pointed to by the CARDIAC CATHETERIZATION file.\n\n
\nThis file stores the left ventricular segments for use by the Cardiac\nCatheterization procedure.\n\n
\nThis file holds the types of mitral regurgitation used by the Cardiac\nCatheterization procedure.\n\n
\nThis file holds the complications associated with medical procedures.\n\n
\nTHIS FILE HOLDS ANATOMICAL ENTRIES USED IN THE MEDICINE PACKAGE\n\n
\nThis file holds the various referring physicians and agencies that have\nmade referrals for cardiac catheterizations.\n\n
\nThis file stores various File Manager and Screen Handler parameters\nassociated with medical procedures, including global locations, names\nof File Manager full and brief input templates, and names of Screen\nHandler enter/edit screens.\n\n
\nThis file contains the screen characteristics of the medicine screen to\nbe displayed.\n\n
\nTHIS FILE CONTAINS VARIOUS MEDICAL DIAGNOSES WITH A SCREEN TO DIFFERENTIATE\nTHE AREA OF MEDICINE ASSOCIATED WITH IT. IT ALSO STORES THE VARIOUS ICD\nCODES ASSOCIATED WITH EACH DIAGNOSIS\n\n
\nThis file is used to hold the Generator Implant/Explant data for the\nPacemaker portion of the Medicine package.\n\n
\nThis holds the V Lead Implant/Explant information for Pacemaker.\n\n
\nThis holds the A Lead Implant/Explant information for Pacemaker.\n\n
\nThis file holds the telephone/clinic follow-up data for Pacemaker.\n\n
\nThis file holds the various Generators, Leads, PSA Analyzers and telephone\ntransmitters used in the Pacemaker module\n\n
\nThis file holds the manufacturer's name for the various equipment\n(Generators, A Leads, V Leads, PSAs, and telephone transmitters) used by\nPacemaker.\n\n
\nThis file holds the rhythms for use by the Basic Rhythm field of the\nPACEMAKER SURVEILLANCE file.\n\n
\nThis file holds all Endoscopic procedures as well as GI Non-endoscopic\nprocedures.\n\n
\nThis file holds the various instruments used in medical procedures with\na screen to differentiate the area of medicine.\n\n
\nThis file stores basic information on procedures in subspecialties\nfor which separate files do not currently exist in the Medicine package.\n\n
\nThis file holds grosses used for Endoscopic procedures with a screen\nto differentiate the type of sub-procedure(s) the gross is related to.\n\n
\nThis file holds modifiers used for Endoscopic Procedures with a screen\nto differentiate the type of sub-procedure(s) the modifier is related to.\n\n
\nThis file stores the techniques used in medical procedures with a screen to\ndifferentiate the type of sub-procedure(s) the technique is related to.\n\n
\nThis file holds the various stents, sphincterotomes, tubes, etc. used\nin Endoscopic procedures.\n\n
\nThis file holds results for Endoscopic procedures.\n\n
\nThis file holds the consultation types for use in the Consult enter/edits.\n\n
\nThis file stores the location of pain for GI Endoscopies and location\nof pneumonia for Pulmonary Endoscopy with a screen to differentiate\nthem.\n\n
\nThis file holds disease evaluations for use with GI/Pulmonary.\n\n
\nThis file holds the various types of follow-up devices and therapies\nfor use with GI/Pulmonary modules.\n\n
\nStores the type of surveillance for use by GI/Pulmonary modules.\n\n
\nStores the types of Non-endoscopic Procedures for use with GI module.\n\n
\nThis file contains imaging information for patients. This file is the\n are recorded into the system\n \n RA OUTSIDE LIST RA OUTSIDE LIST\n \nAlso, the modification of the other sort templates is not recommended.\n \n Data Storage\n ------------\nThe data for the 'RAD/NUC MED PATIENT' file is stored under the ^RADPT\nglobal. This file is very volatile and should be journaled and translated if\nthe operating system supports these two functions.\n \n Input Templates\n ---------------\nfocal point of the entire radiology/nuclear medicine module.\nThe following is a list of input templates used by the package\nand the entry in the OPTIONS file (#19) that uses the template:\n \n Compiled\n Name Routine Description; Option(s)\n ---- -------- ----------------------\n RA DIAGNOSTIC BY CASE Used to input interpreting physicians\n and diagnostic code;\n RA DIAGCN\n \n \n RA OUTSIDE ADD Add outside films into system;\n RA ADDEXAM\n \n RA OUTSIDE EDIT Edit outside film registry;\n RA OUTEDIT\n \n RA OUTSIDE SUPEROK Indicate outside film to require\n supervisor 'ok' before returning;\n RA OUTFLAG\n \nThe file has four basic sections. They are the following:\n \n RA CANCEL Cancel a registered exam;\n RA CANCEL\n \n RA EXAM EDIT Edit a registered exam;\n RA EDITCN, RA EDITPT\n \n RA LAST PAST VISIT Allows entry of the last visit by a\n patient to the department\n before this module was installed;\n \n RA PAST\n \n RA NO PURGE SPEC IFICATION Indicates no purging of an exam report.\n RA NOPURGE\n \n RA OVERRIDE Exam status is made complete without\n doing a requirements check;\n RA OVERRIDE\n \n RA REGISTER ^RACTRG* Initial registered exam entry;\n I. General Patient demographics\n RA REG\n \n RA STATUS CHANGE Status Tracking input;\n RA STATRACK\n \nIf any modifications to these input templates are needed for local\npurposes, then great care should be taken not to degrade any\nbranching logic in the template. Making modifications is not recommended.\n \nThe following templates contain a large amount of branching and\n II. Patient demographics that are imaging related\nMUMPS code and as a result they are uneditable:\n \n - RA REGISTER\n - RA STATUS CHANGE\n - RA EXAM EDIT\n \n \n Print Templates\n ---------------\n The following is a list of print templates used by the package:\n III. Registered exam information\n \n Name Description; Option(s)\n ---- ----------------------\n \n RA DAILY LOG Prints an informational report for all\n exams for a specified date.\n RA LOG\n \n RA OUTSIDE LIST Prints list of outside films needing to be\n returned by a specified date;\n IV. Outside films registry; where films received from other hospitals\n RA OUTSIDERPT\n \n Sort Templates\n --------------\n The following is a list of sort templates associated with this file:\n \n Name Related Print Template\n ---- ----------------------\n \n RA DAILY LOG RA DAILY LOG\n\n
\nThis file contains information specific to nuclear medicine studies\nin which radiopharmaceuticals are used.\n\n
\nThis file is used to measure the amount of radiation absorbed by a person,\nknown as the "absorbed dose," which reflects the amount of energy that\nradioactive sources deposit in patients, on a study by study basis,\nthrough which they pass.\n\n
\nThis file stores the data on Pulmonary Function Tests performed on the\npatient.\n\n
\nThis file holds the set of Predicted Value and Correction formulas for\nuse by the PFT report. The formulas are selected from the PFT FORMULA\nfile (700.2). There are 2 sets present (Male and Female). The\nMale and Female sets can be changed through the Pulmonary Managers' menu.\n\n
\nThis file contains the master list of predicted value and correction\nformulas for use in Pulmonary Function Tests.\n\n
\nContains one entry for each record transmitted from an auto instrument to\nDHCP. This file is used to print the Auto-Instrument Summary report.\n\n
\nThis file stores data on Rheumatology visits.\n\n
\nThis file contains the transactions between the instruments and user\ngenerated data as it is matched to a consult order and a TIU document is\ncreated for the results. It also manages the interface between the images\nand the Imaging server.\n\n
\nThis CP Transaction TIU History file stores all TIU notes\nthat is associated with the CP Transaction study. This will\nkeep track of multiple notes associated with one CP study.\n\n
\nThis file defines all the procedures used by the Clinical Procedures\npackage. All elements that define a procedure are in this file. This\nfile is exported with data, but entries may be added by the site.\n\n
\nThis file contains the list of instruments used by the Clinical Procedures\npackage. This file is exported with data.\n\n
\nThis file contains the information for the results uploaded from the\nmedical instruments used by Clinical Procedures. It is distributed\nwithout any data. All fields are automatically stuffed by Clinical\nProcedures. There is no user input.\n\n
\nThis is the CP Conversion File file (#703.9). This file is used for storing\nthe site parameters needed and used to convert Medicine reports to CP\nText reports. This file also stores the status of the conversion process\nfor each converted Medicine report.\n\n
\nThis file maintains the Access Control List (ACL) for items in the \nconsole by that item's ID.\n\n
\nThis file maintains a log of HL7 Messages processed by Clinical \nFlowsheets.\n\n
\nThis file monitors Clinical Flowsheets HL7 message processing anomalies.\nThese Clinical Flowsheets HL7 messages are referenced via the CP_HL7_LOG\nFile (#704.002).\n\n
\nThis file will hold a subset of patient movement data. This must be done \nMOVEMENT AUDIT file entry will then need to be purged.\nrather than using a direct reference to the PATIENT MOVEMENT file \n(#405) because, in the instance of cancellations, the internal entry \nnumber (ien) of a patient movement disappears before there is the \nchance to work with it. This file will coalesce all of a movement's\ndata to send to 3rd party users. That data is sent to 3rd party users\nvia Health Level Seven (HL7) messaging. To ensure that message is \navailable to 3rd party users, the ACCEPTED BY QUEUE field (#.09) is set \nto '1' to confirm the message is in the HL7 outbound queue; that CP \n\n
\nThis file will be used by the Clinical Flowsheets application to determine\nthe target for an outbound admission, discharge, and transfer (ADT) \nmessage. Messages are sent to a target via Health Level 7 messaging \n(HL7).\n \nNOTE:\nA target is defined here as a receiving CIS or other COTS product that\nhas expressed a desire to be notified when a patient admission, transfer \nor discharge has occurred for a specific hospital location.\n\n
\nThis file is used to store the site configurable shift definitions.\n\n
\nThis file is used to store the site configurable schedules for the Kardex.\n\n
\nNOTICE: This file is maintained exclusively by the CP Terminology group \nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \nThis file stores all terminology elements for the Clinical Flowsheets\napplication. The entries in this file are called "terms". These terms \nalong with CP files #704.102 - #704.109 constitute the Clinical Data \nModel.\n\n
\nNOTICE: This file is maintained exclusively by the CP Terminology group \ninternal entry number (ien).\n \nThe ordinal set is as follows:\n \n TTermType = (ttUnknown, ttObservation, ttUnit, ttMethod, ttPosition, \n ttLocation, ttQuality, ttProduct, ttNullFlavor, ttTask,\n ttSchedule, ttValue, ttConcept);\nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \n \nGUI PROGRAMMING NOTES:\n \nThis file translates 1-1 to the TTermType ordinal set by the file's \n\n
\nNOTICE: This file is maintained exclusively by the CP Terminology group \nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \nThis file is a join table for the Clinical Data Model that matches \nobservations to their allowable qualifiers. A sample could be the \nobservation equating to "weight" and the paired qualifier equating to \n"lift scale".\n\n
\nNOTICE: This file is maintained exclusively by the CP Terminology group \nUnits are presented as entries in the TERM File (#704.101). For example \nthe unit "CENTIMETER" could be identified by the TERM\nFile (#704.101), TERM ID (field #.01) \n"{EF700458-8C2D-16E8-02DC-9E1711584C53}".\nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \nThis file links like units of measure together with required \nconversion logic to change the value from one unit to another.\n \nNOTE:\n\n\nNOTICE: This file is maintained exclusively by the CP Terminology group \nObservations are presented as entries in the TERM File (#704.101). For \nexample the observation "TRACTION WEIGHT" could be identified by the TERM \nFile (#704.101), TERM ID (field #.01) \n"{0C913807-C678-4E94-BD20-B8B2EBE697BE}".\nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \nThis file matches observation(s) with available units for the observation,\nand the range settings for each pair.\n \nNOTE: \n\n\nNOTICE: This file is maintained exclusively by the CP Terminology group \nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \nThis file holds the structure for complex observations by pairing the \nparent observation to the child observation with an ordinal position as \nwell. Observations are entries in the TERM File (#704.101)\n\n
\nThis file maintains value ranges for related observations/terms.\n \nAn example could be a TERM RANGE CHECK entry that would result in an \nobserved TEMPERATURE of 80 DEGREES FAHRENHEIT for a MALE between 55-150 \nyears of AGE, triggering a "CRITICAL LOW" response by the Clinical \nFlowsheets application.\n\n
\nNOTICE: This file is maintained exclusively by the CP Terminology group \nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \nThis file is the anchor for the mapping table structure for the CP \nGateway. Each mapping table is called up by elements in the HL7 message. \nThe entries are used to translate the HL7 data into appropriate \nCP terminology.\n\n
\nNOTICE: This file is maintained exclusively by the CP Terminology group \nA sample entry could be interpreted as follows:\n Mapping-TableXX is used for processing when VendorX has sent an \n XType message.\nand must not be modified or edited in any way. Subsequent releases of CP \nTerminology may create lasting errors in the CliO data store if this file \nis changed.\n \n \nThis file correlates a vendor (VENDOR KEY field #.1) with a mapping-table \n(MAPPING TABLE ID field #.01) and an HL7 message segment\n(TERM TYPE field #.03).\n\n
\nThis file maintains the views displayed within a flowsheet via the \nClinical Flowsheets application. A view is a group of terms displayed \ntogether.\nA sample view could display "ICU VITALS,INPUTS,OUTPUTS, and ICU \nHEMODYNAMICS" information together in a section of a flowsheet \ndisplayed via the Clinical Flowsheets application.\n\n
\nThis file maintains the relationships between views of OBS_VIEW File \n(#704.111) and terms of TERM File (#704.001).\n \nNote: Some field descriptions are directed to a programming and \ndevelopment audience.\n\n
\nThis file maintains relationships between view entries in the OBS VIEW \nFile (#704.1111) and qualifiers/filters.\n\n
\nThis file maintains the flowsheets used by the Clinical Flowsheets \napplication.\n\n
\nThis file maintains the relationships between OBS_FLOWSHEET File \n(#704.112) entries and pages/view (OBS_VIEW File #704.111) entries.\n\n
\nThis file maintains supplemental pages/views. The supplemental page is a \nvariation of a page as supported via the OBS_FLOWSHEET_PAGE File \n(#704.1121).\n\n
\nThis file maintains flowsheets (file #704.112) and observation \ntotals (file #704.113) relationships.\n\n
\nThis file maintains observation totals.\n\n
\nThis maintains relationships between OBS TOTAL File (#704.113) entries\n and TERM File (#704.101) entries.\n\n
\nThis file supports the Clinical Flowsheets application "alarm" \nfunctionality. And the file maintains the relationships between alarms \nand patients.\n\n
\nThis file maintains sets of observations used by the Clinical Flowsheets \napplication.\n\n
\nThis file maintains the relationships between observations and \nobservation sets.\n\n
\nThis file maintains observations for use with the Clinical Flowsheets \napplication.\n\n
\nThis file maintains relationships between observations and qualifiers.\n\n
\nThis file maintains the chains of observation audits for Clinical \nFlowsheets observations. An audit is defined here as a change in an\nobservation's status, state, or condition.\n\n
\nThis file supports Clinical Flowsheets scheduled tasks and actions \nfunctionality.\n\n
\nThis file supports Clinical Flowsheets scheduled events/actions \nfunctionality.\n\n
\nThis file maintains audits of scheduled event/tasks via the Clinical \nFlowsheets application.\n\n
\nThis file contains data describing a patients access point history for \ndialysis treatments. All data is stored as XML documents in UUEncoded \nformat for VA Fileman compatibility.\n\n
\nThis file contains data describing each patient procedure for\ndialysis treatments. All data is stored as XML documents in UUEncoded\nformat for VA Fileman compatibility.\n\n
\nThis file contains system and user level settings for the client \napplication. All data is stored as XML documents in UUEncoded\nformat for VA Fileman compatibility.\n\n
\nThis file is a temporary repository for the Event Driven reporting\nevents that will be sent to the central system. The events are\ncaptured as they occur and stored in this file for later transmission.\nOnce transmitted, the events are deleted from this file.\n\n
\nThis file contains all the procedures that may be associated with an\n \nOnce this software is in production, you should never delete any entries.\nEntries can be deactivated by entering an 'inactivation' date for the\nentry. Adding new entries is always allowed.\n \n \n Data Storage\n ------------\nThe data for the 'RAD/NUC MED PROCEDURES' file is stored in the ^RAMIS(71,\nglobal. At the present time this file is very static after day-one\nimaging exam. The entries in this file are the allowable choices the user\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\n The following is a list of input templates used by the package\n and the entry in the OPTIONS file (#19) that uses the template:\n \n Name Routine Description; Option(s)\n Compiled\nwill be able to pick from at the procedure prompt. This prompt appears as\n ____ ________ ____________\n RA PROCEDURE EDIT Use to enter/edit procedure to the file;\n \nIf any modifications to this input template are needed for local\npurposes, then great care should be taken not to degrade any branching logic\nin the template.\n \n Print Templates\n ---------------\n The following is a list of print templates used by the package:\npart of the 'Register', 'Case No. Edit' and the 'Exam Status Tracking'\n \n Name Description; Option(s)\n ____ ______________________\n RA ALPHA LIST OF ACTIVES Prints a listing of procedures and used with\n the ALPHA LIST OF ACTIVES sort template to\n list only 'active' procedures;\n RA ALPHALIST\n \n RA PROCEDURE LIST Prints a 'long' listing of procedures;\n RA PROCLONG, RA INACPRCLONG, RA PROCSERIES\nfunctions of the module.\n \n RA PROCEDURE SHORT LIST Prints a 'short' listing of procedures;\n RA PROCSHORT, RA INACPRCSHORT\n \n Sort Templates\n --------------\n The following is a list of sort templates used by the package:\n \n Name Related Print Template\n ---- ----------------------\n \n RA ALPHA LIST OF ACTIVES ALPHA LIST OF ACTIVES\n \n RA PROCEDURES BY PROCEDURE LIST\n AMIS CODES\n \n RA SERIES ONLY PROCEDURE LIST\n \n The modification of any sort templates is not recommended.\nIf the procedure has an inactivation date less than the current date\nthen the procedure is not a valid choice and will not appear on the\nlist of valid/active procedures when displayed to the user.\n\n
\nThis file contains the valid AMIS codes, descriptions, and weighted work\n Data Storage\n ------------\n The data for the 'MAJOR RAD/NUC MED AMIS CODES' file is stored in the\n^RAMIS(71.1, global. At the present time this file is static. There \nare no special requirements to backup or archive data in this file.\n \n \n Input Templates\n ---------------\n The package does not use any input templates associated with this\nunits as assigned by Radiology Service in VACO. The data in this file is\nfile.\n \n \n Print Templates\n ---------------\n The package does not use any print templates associated with this\nfile.\n \n \n Sort Templates\nused in the compilation of various workload reports including the AMIS\nReport.\n \nNew entries and modifications to existing entries are no longer \nprohibited by the National Radiology Program Office (NRPO).\n \n \n\n
\nThis file temporarily hold a new radiology procedure while it is being \ndeveloped and associated to the MASTER RADIOLOGY PROCEDURE file (#71.11).\nAfter the procedure is created and matched it will be moved to the\nRAD/NUC MED PROCEDURE file (#71) and then deleted from 71.11.\n\n
\nThis file is added with radiology patch RA*5.0*223 and contains radiology\n------------\nThe data for the 'RADIOLOGY PROCEDURE MAP TO CC CONSULT' file is stored in\nthe ^RA(71.1235, global. At the present time this file is static and will\nonly be updated by national patch releases.\n \nInput Templates \n---------------\nThere are no input templates associated with this file. \n \nPrint Templates \nprocedures that are associated with a consult service for the purpose of\n---------------\nThere are no print templates associated with this file. \n \nSort Templates \n--------------\nThere are no sort templates associated with this file. \ncommunity care referrals of radiology orders. The entries in this file are\nused by the radiology option 'Refer Selected Requests to COMMUNITY CARE\nProvider' [RA ORDERREF] to determine if a special consult title should be\nused for the community care consult order. The entries in this file are\nmaintained nationally and should not be modified.\n \nData Storage \n\n
\nThis file contains the modifiers that can be associated with an imaging\nof the module:\n \n o PORTABLE\n o OPERATING ROOM\n o BILATERAL\n o LEFT\n o RIGHT\n \nPortable, Operating Room and Bilateral are very important for the\ncompilation of the AMIS report. For this reason, the name of the\nexam. These modifiers are used to further describe the procedure\nmodifier is uneditable. Any modifier who meaning is portable, operating\nroom, or bilateral should be further defined by entering one of these\nchoices in the AMIS Credit Indicator field. Series type procedures cannot\nbe assigned modifiers that affect AMIS credit.\n \nEntries in this file should not be deleted. Adding new entries is always\nallowed.\n \nEach modifier must be assigned one or more Imaging Type(s) in order to\nappear as a selection during modifier edits of procedures and exams. To\nassociated with the exam. For example, if an exam of the 'hand' was\ndeactivate a modifier, use the option for editing procedure modifiers to\ndelete all the imaging types that appear under the modifier.\n \nTo add site specific modifiers and to obtain more information regarding\nthis file, see the ADPAC Guide.\n \n Data Storage\n ------------\n The data for the 'PROCEDURE MODIFIERS' file is stored in the ^RAMIS(71.2,\nglobal. At the present time this file is very static after\nperformed then the modifier 'left' can be chosen to indicate which hand.\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\n The package does not use any input templates associated with this\nfile.\n \n Print Templates\n ---------------\n \n The package does not use any print templates associated with this\nfile.\n \n Sort Templates\n --------------\n The package does not use any sort templates associated with this\nfile.\nIf an exam has a modifier associated with it, then it will automatically\nappear on the report.\n \nWhen the system is installed, the following modifiers are loaded as part\n\n
\nThis file contains the procedures used in the display of common procedures\nwhen requesting a procedure. Up to 40 active common procedures are\nallowed per imaging type. Active common procedures have a sequence number\nthat determines their display order on the common procedure selection\nscreen.\n\n
\nThis file contains messages concerning special requirements when ordering\n \n Templates\n ---------\n The package does not use any input, print or sort templates\nassociated with this file.\na procedure. One or more of these messages can be tied to a procedure\nin the Rad/Nuc Med Procedures file (#71) so that they are displayed to a\nrequestor at the time an order is placed.\n \n Data Storage\n ------------\n The data for the 'RAD/NUC MED PROCEDURE MESSAGE' file is stored in the\n^RAMIS(71.4, global.\n\n
\nThis file contains valid imaging stop codes. It is not pointed to by\nany other file. The Rad/Nuc Med ADPAC should make sure this file is\nupdated. Obsolete or unused entries should be deleted. This file \nshould contain all stop codes that can be assigned to imaging locations\nat the facility.\n\n
\nThis file contains all possible routes of pharmaceutical and\nradiopharmaceutical administration used in imaging exams.\n\n
\nThis file contains frequently-used sites of drug administration for\nimaging exams.\n\n
\nThis file contains the names of vendors, pharmacies, and other sources of\nradiopharmaceuticals.\n\n
\nThis file is used to record names of radiopharmaceutical lots, batches,\nvials, syringes, or kits at the discretion of the facility.\n\n
\nThis file is designed to handle functions in the MASTER RADIOLOGY PROCEDURE\nfile (MRPF) operations that require timeframes, progress recording and\nfunction status and names of mail groups and ADPACS.\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n
\nThis is the primary data file for the NOIS (National Online Information\nSharing) problem reporting system. It holds data for problem calls.\n\n
\nThis file stores the last number used in creating a NOIS Call ID.\nThe number is unique to the year and month of when the NOIS call is reported.\n\n
\nThis file stores notifications that are scheduled on NOIS calls.\n\n
\nThis file stores NOIS calls that will alert a user.\n\n
\nThis file has calls where alerts have been sent (manually).\n\n
\nThis file is used to edit word-processing fields on a NOIS call.\nWhen the data is accepted the text in this file is copied to the\nNOIS file and the entry in this file is deleted.\n\n
\nThis file holds NOIS calls for active-update type lists.\n\n
\nThis file contains information on the locations (sites or services)\nthat report NOIS calls.\n\n
\nThis file contains information on NOIS users. Specialists can\nedit NOIS calls, define lists, and use fields in this file as personal\nparameters and defaults.\n\n
\nThis file contains information on IRM Offices used with NOIS.\n\n
\nThis file contains information on specific versions of modules used\nwith NOIS.\n\n
\nThis file contains the packages used with NOIS.\n\n
\nThis file contains subcomponents of packages used with NOIS.\n\n
\nThis file is used to specify the type of NOIS location.\nFor NOIS locations that are sites, these entries might be a category\nlike computer system (Alpha, 486, etc.). For locations that are in a\nhospital, these entries might be services (medicine, outpatient clinics,\netc.).\n\n
\nThis file contains entries for the status of NOIS calls (both DEV and\nSUPPORT).\n\n
\nThis file contains the priorities that can be assigned to a NOIS call.\n\n
\nThis file contains the tasks that can be assigned to a NOIS call.\n\n
\nThis file contains the functional areas that can be assigned to a NOIS call.\n\n
\nThis file defines the lists of NOIS calls.\n\n
\nThis file defines the fields in a NOIS call, so that they can be selected\nand used in displays, editing, and searching.\n\n
\nThis file contains the conditions used when doing searches on NOIS fields.\n\n
\nThis file defines a NOIS report by combining a group of calls (list) with\na format (display format). A sort order (sort format) can also be \nincluded.\n\n
\nThis file contains formats for display and sorting. Entries are a collection\nof fields with attributes on how they are organized and displayed.\n\n
\nThis file defines types of formats for display and sorting.\n\n
\nThis file contains site parameters and defaults used by the NOIS software.\n\n
\nThe 1010EZ MAPPING File holds the mapping between each data element\nto malfunction and may jeopardize database integrity.\nin the On-Line 10-10EZ Application and the VistA Patient database.\nEach record in this file is uniquely identified by a Data Key which\ncorrelates exactly with a specific 10-10EZ form question within a\nspecific 10-10EZ section. Each record also contains the exact VistA\ndatabase location (i.e., file/sub-file/field) where the data will be\nstored.\n \nLocal modifications to this file will cause the the 1010EZ module\n\n
\nThis file contains the Domains, which are a subset of medicine, a natural \ngrouping of clinical acts (e.g., demographics, vital signs, laboratory,\npharmacy) and the VistA File/Fields associated with the Domain.\n \nThis file is used on the Central Server and Facility for VUID Implementation.\n\n
\nThis file contains the schema for XML documents. It maintains every\nXML element, it's sequence and whether the element has sub-elements\nand whether the element is a multiple.\n\n
\nThis file contains the different status codes used by Data Standardization\nprocesses.\n \nThis file is used on the Central Server and Facility for VUID Implementation.\n\n
\nThis file contains the File/Fields in VistA.\n \nThis file is used on the Central Server and Facility for VUID Implementation\n\n
\nThis file contains the association of a Term/Concept\nand its VUID and Activation Status as defined by\nEnterprise Reference Terminology (ERT).\n \nThis file is used on the Central Server for VUID Implementation.\n\n
\nThis file contains the system related information for a facility.\n \nThis file is used on the Central Server for VUID Implementation.\n\n
\nThis file contains the Term/Concept assigned to a VistA File/Field Internal\nEntry Number (IEN) at a Facility (VAMC) by the Data Standardization VUID\nImplementation Process.\n \nThis file is used on the Central Server for VUID Implementation.\n\n
\nThis file contains the Status of the VUID Implementation Process for a VistA\nFile/Field at a Facility (VAMC).\n \nThis file is used on the Central Server and Facility for VUID Implementation.\n\n
\nThis file contains system specific data. On the central server(s) this \nfile contains data specific to the systems communicating to it/them and \nvariable information required when processing facility data. On VistA\nsystems this file contains data specific to the facility, such as the\nlocation(s) of the central server(s). The local system is typically the\nfirst entry in the file but there is no requirement for this to be true.\n\n
\nEach record in this file holds the contents of an On-Line 10-10EZ\nApplication as received via e-mail at this site. As the 10-10EZ \nApplication is processed by the user, processing audit information\nis also stored here.\n \nThis file may not be directly edited through FileMan.\n\n
\nThis file stores the Metropolitan Statistical Area (MSA) code for\neach Zip Code. The MSA code is used to identify the correct\nrecord in the GMT Thresholds file (#712.5) for counties that have\nmultiple threshold records.\n\n
\nThis file contains the site specific parameters which are used by the\nEnrollment Application System. The parameters are set by using the 'EAS\nMT Parameters' menu option. The parameters are used in the\nauto-generation of the 60, 30 and zero day means test letters.\n\n
\nThis file contains the patient list for which the automated means test\nletters have been generated. This file will also allow specific patients\nto be flagged from having means test reminder letters generated. Based on\nlocal class III file #6185243\n\n
\nThis file contains the patients Means Test anniversary date and letter\nthreshold dates. Entries are generated when the auto-generated Means Test\nLetter functionality runs for reminder letters. 60, 30 and zero day\nthresholds are set, with respective Flag to Print? and Printed status\nfields.\n\n
\nThis file contains the EAS Means Test letters that may be sent out by a\nsite. The initial section of the letter should not be modified locally.\nFacilities should enter facility specific information in the FINAL SECTION\nfield.\n\n
\nThis file contains the reasons why a veteran would qualify for an\nexemption from Long Term Care co-payments. This file is pointed to by the\nReason for Exemption field (#2.07) in the Annual Means Test file\n(#408.31).\n\n
\nThis file stores the data relating to maximum Long Term Care (LTC) \ncopayment calculations. When an HL7 message is received and an EAS \nprotocol event is invoked the Enrollment Application System will \ncalculate the LTC copayment amounts and store the data received and \ncalculated in this file. The data is later on extracted and sent back to \nthe requesting application via HL7 messaging.\n\n
\nThis file contains the statuses an imaging exam may be in, as it\n should be asked of the user when trying to move an exam\n into the status.\n \n o fields that indicate to the various workload report\n routines whether an exam in a particular exam status\n should be used in the compilation of the report\n \nWhen the system is initialized, the following statuses and\ntheir 'order' in the exam process are loaded into this file:\n \nis processed.\n Order Status\n ----- ------\n 1 WAITING FOR EXAM\n 2 CALLED FOR EXAM\n 3 EXAMINED\n 4 TRANSCRIBED\n 9 COMPLETE\n 0 CANCELLED\n \nThe site does not have to use this configuration. The only requirements\n \nof the system are the following:\n \n o there must be a status with an order of '1'; this is the\n status that the module will place an exam in upon registration.\n \n o there must be a status with an order of '9'; when an exam\n reaches this status then the module considers the exam\n complete and the exam can no longer be called up by case\n number; also the case number can then be reused.\n \nThe fields in this file generally fall into three basic categories:\n o there must be a status with an order of '0' and it must\n be called 'CANCELLED'.\n \n Data Storage\n ------------\nThe data for the EXAMINATION STATUS' file is stored in the ^RA(72,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n \n Input Templates\n ---------------\nThe following is a list of input templates used by the package\nand the entry in the OPTIONS file (#19) that uses the template:\n \n Compiled\n Name Routine Description; Option(s)\n------ ------- ----------------------\n RA STATUS ENTRY Used to enter/edit entries in this file;\n RA EXAMSTATUS\n o fields that indicate what data has to be entered for an\n \n This input template should not be modified.\n \n Print Templates\n ---------------\nThe package does not use any print templates associated with this\nfile.\n \n Sort Templates\n --------------\n exam in order for the exam to be placed in the status.\nThe package does not use any sort templates associated with this\nfile.\n \n o when using the 'Exam Status Tracking' system, which prompts\n\n
\nThis file is used to update when the Event Capture software is\nThis file should NOT be modified directly using VA FileMan. This \ninformation is set during the package installation process.\ninstalled. It is used during the post installation process to track\nprevious package installation information. In Version 2.0, the\npost installation routine sets entry number one (1) and the date\nand time the post installation routine ran to completion. This\ninformation is used for future reference. Version 2.0 requires\nextensive data conversion if a previous pilot version of this\nsoftware is resident at site. \n \n\n
\nThis file contains information that is used to screen procedures\nusing the Inactivate Event Code Screens option within the\nEvent Capture software.\n \nThis file should NOT be modified directly using VA FileMan.\nThis information is created and edited using the Event Capture\nManagement Menu options.\nbased on a unique location, DSS unit, category, and procedure.\nInformation in this file should only be entered or edited\nthrough the Event Code Screen (Create) option. Access\nto this option is restricted to the Event Capture Management\nMenu.\n \nOne important note, information related to the event code\nscreen cannot be deleted; however, it may be inactivated\n\n
\nThis file will be used to add procedure reasons to event code screens for\nuse in Event Capture data entry.\n\n
\nThis file contains pointers to the EC Event Code Screens (#720.3) file and\nthe EC Procedure Reason (#720.4) file and is used as a "link" file between\nthe two.\n\n
\nThis file contains procedures entered through the Event\nCapture software. All entries can be created, edited, or\ndeleted using the options provided within the Event\nCapture Data Entry menu.\n \nThis file should NOT be modified directly using VA FileMan.\n\n
\nThis locally populated file contains the names of users that can provide \nservices to patients within the Event Capture package.\n \nThese users may only be selected for workload associated with a DSS unit\nthat is set to not send records to PCE. Traditionally, only licensed \nproviders are selected for workload within Event Capture. This file \nidentifies those people who can provide a service, even though they \naren't licensed providers.\n\n
\nThis file contains the medical specialties associated with DSS\nunits and ordering sections associated with patient procedures.\nEntries in this file will be determined by the Decision Support\nSystem (DSS) Program Office or designee.\n \nThis file should NOT be modified directly using VA FileMan.\nAny additions, deletions, or modifications will be distributed\nnationally through the release of the Event Capture software.\n\n
\nThis file contains all DSS units defined for use in the Event\nThe Event Capture Management Menu provides the options\nnecessary to create, edit, and inactivate all DSS units.\nCapture software. Entries cannot be deleted but may be\ninactivated using the Event Capture software. The fields\nrepresenting service, medical specialty and cost center\nare required for each DSS unit. These fields can be edited\nusing options on the Event Capture Management Menu\nbut cannot be deleted.\n \nThis file should NOT be modified directly using VA FileMan.\n\n
\nThis file contains a set of nationally defined procedures for\nlocally recognized procedures to this file. These local\nentries will be added, by the using the Event Capture\nsoftware, at internal entry number above 90,000.\n \nThis file should NOT be modified directly using VA FileMan.\nuse in the Event Capture software. These procedures are\nnecessary for data collection in DSS that are not represented\nin the CPT file (#81). These procedures were defined by the\nDecision Support System (DSS) Program Office or its designee.\n \nEntries in this file are standard procedures that should not be\nedited or deleted. Options exist within the Event Capture\nManagement Menu that provide users the tools to add\n\n
\nThis is a locally populated file which contains the categories that\ngroup procedures within the Event Capture software. Each site\nwill determine their local categories and the extent of their usage. \n\n
\nThis file contains data about the extracts from DHCP packages. Each\nintegrity of all DSS applications.\nentry includes the date of the extract, the package for which the\nextract was run, the date range covered by the extract, and the\nnumber of records sent. Data is entered into this file by the\nextract routines at the time extracts are transmitted to the\ncommercial software. Data in this file may be viewed by appropriate\noptions within the DSS package. It is not intended that this file\nbe read directly via VA FileMan and DATA IN THIS FILE MUST NEVER\nBE EDITED. Editing data in this file will severely compromise the\n\n
\nThis file provides a mechanism for sites to tailor the running of\npackage extracts by defining the frequency (daily, weekly, or monthly)\nwith which the extracts will run and the number of days in the past\nfor which data will be extracted. The EXTRACT NAME field (#.01) and\nthe FILE NUMBER field (#1) are national standard entries, exported with\nthe file, and should not be edited locally.\n\n
\nThis file contains the set of laboratory tests tracked by the Decision\nnot be changed or deleted. New entries in this file should not be made. \nSupport System along with the corresponding local data names in the\nLABORATORY TEST file (#60) pointed to by these tests. This file also\ncontains the local names for BLOOD and URINE specimens. Each DSS Lab Test\nis assigned a predefined indicator (SOURCE field) of the type of specimen\n(blood or urine) that will be used as search criteria in conjunction with \nthe local names for blood and urine specimens.\n \nEntries in this file are determined by the DSS Program Office and should\n\n
\nThis file contains the set of laboratory LOINC codes tracked by the \nDecision Support System. It contains corresponding DSS test numbers, DSS\ntest names, reporting units, and LOINC name.\n \nEntries in this file are determined by the DSS Program Office and should \nnot be changed or deleted. New entries in this file should not be made.\n\n
\nThis file is used to associate a local DSS Identifier with each medical\ncenter division. Do not use FileMan to enter/edit data in this file. The \nDSS Site Manager is provided with a specific menu option with which to\nperform file updates.\n\n
\nThis file is used to associate a DSS Department code with each active\nward in the medical center. Do not use FileMan to enter/edit data in this\nfile. The DSS Site Manager is provided with a specific menu option with\nwhich to perform file updates.\n\n
\nThis file contains the names of those Mental Health Instruments\nwhich are being tracked by the Decision Support System. Each record\nin this file refers to a record in the MH INSTRUMENT file (#601).\n \nEntries in this file are determined by the DSS Program Office and should\nnot be changed or deleted. New entries in this file should not be made. \n\n
\nThis file is a translation table for converting free text lab test results\nlab test results that were compiled by the DSS Program Office. Sites may \nadd new entries to this file as needed with other free text values and\ntheir corresponding translation codes. \ninto numeric codes for use by Decision Support System (DSS). The \ntranslation table is used to translate the RESULTS field (#10) of\nthe LAB RESULTS EXTRACT file (#727.824) to a standard numeric code to\nindicate the test result when text has been entered instead of a numeric\nvalue. The translated value is used to populate the LAB RESULTS\nTRANSLATION field (#27) of the LAB RESULTS EXTRACT file (#727.824).\n \nThis file has been populated initially with common free text values for \n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the MAS Admission extract from existing \nDHCP files. Entries into this file are made by extracting data from \nseveral files. Once approved by the DSS site manager, entries in this\nfile are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the MAS Clinic No Show extract from \nexisting DHCP files. Entries into this file are made by extracting data \nfrom several files. Once approved by the DSS site manager, entries in \nthis file are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Nursing extract from existing \nDHCP files. Entries into this file are made by extracting data from \nseveral files. Once approved by the DSS site manager, entries in this\nfile are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Dental extract from existing \nDHCP files. Entries into this file are made by extracting data from \nseveral files. Once approved by the DSS site manager, entries in this\nfile are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support \nSince validation techniques will be determined by the local site, it is\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the MAS Physical Movement (Transfer and \nDischarge) extract from existing DHCP files. Entries into this file are \nmade by extracting data from several files. Once approved by the DSS \nsite manager, entries in this file are loaded into an electronic mail \nmessage and sent to the commercial vendor. This file is intended to be \nused for validation purposes only. Entries should be made only by the \nextract load routine.\n \n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Pharmacy Unit Dose extract from \nexisting DHCP files. Entries into this file are made by extracting data \nfrom several files. Once approved by the DSS site manager, entries in \nthis file are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support \nSince validation techniques will be determined by the local site, it is\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Pharmacy Outpatient (Prescription) \nextract from existing DHCP files. Entries into this file are made by \nextracting data from several files. Once approved by the DSS site \nmanager, entries in this file are loaded into an electronic mail message \nand sent to the commercial vendor. This file is intended to be used for \nvalidation purposes only. Entries should be made only by the extract \nload routine.\n \n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Surgery extract from existing \nDHCP files. Entries into this file are made by extracting data from \nseveral files. Once approved by the DSS site manager, entries in this\nfile are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support \nan electronic mail message and sent to the commercial vendor. This file \nis intended to be used for validation purposes only. Entries should be \nmade only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nSystem (DSS) Program Office for the Laboratory extract from existing \nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nDHCP files. Entries into this file are made by extracting data by two \ndifferent methods depending upon whether or not LMIP codes are used. \nUsing LMIP codes, the data are extracted, in large part, from the WKLD \nLOG file (#64.03) which is populated by a routine provided by the \nLaboratory development team. Not using LMIP codes, the data are derived \nfrom several Lab files as well as from several other DHCP files. Once \napproved by the DSS site manager, entries in this file are loaded into \n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Radiology extract from existing \nDHCP files. Entries into this file are made by extracting data from \nseveral files. Once approved by the DSS site manager, entries in this\nfile are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision\n \nSince validation techniques will be determined by the local site, it is\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSupport System (DSS) Program Office for the Event Capture\nextract from the existing Event Capture DHCP files. Entries\ninto this file are made by extracting data from several files.\nOnce approved by the DSS site manager, entries in this file\nare loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for\nvalidation purposes only. Entries should be made only by the\nextract load routine.\n\n
\nThis file contains data elements as specified by the Decision Support \nSince validation techniques will be determined by the local site, it is\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the MAS Treating Specialty Change \nextract from existing DHCP files. Entries into this file are made by \nextracting data from several files. Once approved by the DSS site \nmanager, entries in this file are loaded into an electronic mail message \nand sent to the commercial vendor. This file is intended to be used for \nvalidation purposes only. Entries should be made only by the extract \nload routine.\n \n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Pharmacy IV extract from existing \nDHCP files. Entries into this file are made by extracting data from \nseveral files. Once approved by the DSS site manager, entries in this\nfile are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file is used to hold information to create data for the inpatient\nData elements in this file should never be entered, edited, or deleted\nthrough the VA FileMan.\n \npopulation on the date that a site chooses to begin using DSS. Data\nis entered into this file by a background job which identifies all\npatients who were in the facility on the selected date. Then these\nentries are moved, by another background job, to the ADMISSION EXTRACT\nfile (#727.802) to be transferred to the DSS package. Once the transfer\nto the ADMISSION EXTRACT file (#727.802) is complete, data is purged\nfrom this file, and it becomes inactive.\n \n\n
\nThis file is used to hold information to create data for the physical\n \nData elements in this file should never be entered, edited, or deleted\nthrough the VA FileMan.\nmovements (transfers and discharges) for inpatients on the date that a\nsite chooses to begin using DSS. Data is entered into this file by a\nbackground job which identifies all patients who were in the facility\non the selected date. Then these entries are moved, by another\nbackground job, to the PHYSICAL MOVEMENT EXTRACT file (#727.808)\nto be transferred to the DSS package. Once the transfer to the PHYSICAL\nMOVEMENT EXTRACT file (#727.808) is complete, data is purged from\nthis file, and it becomes inactive.\n\n
\nThis file is used to hold information to create data for the treating\n \nData elements in this file should never be entered, edited, or deleted\nthrough the VA FileMan.\nspecialty changes for inpatients on the date that a site\nchooses to begin using DSS. Data is entered into this file by a\nbackground job which identifies all patients who were in the facility\non the selected date. Then these entries are moved, by another\nbackground job, to the TREATING SPECIALTY CHANGE EXTRACT file (#727.817)\nto be transferred to the DSS package. Once the transfer to the\nTREATING SPECIALTY CHANGE EXTRACT file (#727.817) is complete, data\nis purged from this file, and it becomes inactive.\n\n
\nThis file contains data elements as specified by the Decision Support \nSince validation techniques will be determined by the local site, it is\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Patient Assessment Instrument (PAI) \nextract from existing DHCP files. Entries into this file are made by \nextracting data from the PAF file (#45.9). Once approved by the DSS site \nmanager, entries in this file are loaded into an electronic mail message \nand sent to the commercial vendor. This file is intended to be used for \nvalidation purposes only. Entries should be made only by the extract \nload routine.\n \n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Laboratory Results extract from \nexisting DHCP files. Entries into this file are made by extracting data \nfrom several files. Once approved by the DSS site manager, entries in \nthis file are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the QUASAR extract from existing QUASAR\nDHCP files. Entries into this file are made by extracting data\nfrom several files. Once approved by the DSS site manager, entries in\nthis file are loaded into an electronic mail message and sent to the\ncommercial vendor. This file is intended to be used for validation\npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains the data elements as specified by the Decision Support\npurposes only. Entries in this file should be made only by the extract\nload routine.\n \nSince validation techniques will be determined by the local site, it is\nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\nSystem (DSS) Program Office for the Prosthetics extract from existing\n \nThis file should NOT be modified directly using VA FileMan. \nVISTA files. Entries into this file are made by extracting data that\noriginates in the Prosthetics RECORD OF PROS APPLIANCE/REPAIR file (#660).\nInformation respective to the patient for which Prosthetic information\nis extracted is pulled from the PIMS Patient file (#2). Once the extracts\n(making up the records in this file) are approved by the extract manager,\nentries in this file are loaded into mail messages and transmitted to\nthe commercial vendor. This file is intended to be used for validation\n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary.\nHowever, this file contains one nationally determined cross reference,\nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified.\n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the Clinic extract from existing \nDHCP files. Entries into this file are made by extracting data from \nseveral files. Once approved by the DSS site manager, entries in this\nfile are loaded into an electronic mail message and sent to the \ncommercial vendor. This file is intended to be used for validation \npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is\n\n
\nThis file contains data elements as specified by the Decision Support \nSince validation techniques will be determined by the local site, it is \nintended that the site add whatever cross references deemed necessary. \nHowever, this file contains one nationally determined cross reference, \nthe "AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified. \n \nThis file should NOT be modified directly using VA FileMan.\nSystem (DSS) Program Office for the Blood Bank extract from existing VistA\nfiles. Contains data extracted from the sub file #63.017, TRANSFUSION \nRECORD file of the LAB DATA file (#63) and from the PATIENT file (#2).\nOnce approved by the DSS site manager, entries in this file are loaded\ninto an electronic mail message and sent to the commercial vendor. This\nfile is intended to be used for validation purposes only. Entries should\nbe made only by the extract load routine.\n \n\n
\nThis file will translate the patient's treating specialty to a\nDOM/PRRTP/SARRTP code (if applicable), an observation patient indicator,\nan inpatient/outpatient status indicator, and an observation stop code for\nuse in all DSS extracts.\n \nThis file was originally called DOM PRRTP SAARTP ETC and has been modified\nas part of the DSS FY2002 software release.\n\n
\nThis file contains data elements as specified by the Decision Support \nintended that the site add whatever cross references deemed necessary. \nHowever, this file contains one nationally determined cross reference, the\n"AC" cross reference on the EXTRACT NUMBER field (#2). This cross\nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified. This file should NOT be modified directly using VA FileMan.\nSystem (DSS) Program Office for the Nutrition and Food Service extract\nfrom existing VistA files. Entries into this file are made by extracting\ndata from several files. Once approved by the DSS site manager, entries in\nthis file are loaded into an electronic mail message and sent to the\ncommercial vendor. This file is intended to be used for validation\npurposes only. Entries should be made only by the extract load routine.\n \nSince validation techniques will be determined by the local site, it is \n\n
\nThis file contains data elements as specified by the Decision Support\n \nSince validation techniques will be determined by the local site, it is \nintended that the site add whatever cross references deemed necessary. \nHowever, this file contains one nationally determined cross reference, the\n"AC" cross reference on the EXTRACT NUMBER (#2) field. This cross \nreference is used by the DSS Extracts software package as an essential\nfeature for managing and purging data in this file and should not be\nmodified. \n \nThis file should NOT be modified directly using VA FileMan. \nSystem (DSS) Program Office for the BCMA (Bar Code Medication \nAdministration) extract from existing DHCP files. Entries into this file \nare made by extracting data from several files. The BCM MEDICATION\nLOG (#53.79) file is a major source of fields within this file. Once\napproved by the DSS site manager, entries in this file are loaded into an\nelectronic mail message and sent to the commercial vendor. This file is\nintended to be used for validation purposes only. Entries should be made\nonly by the extract load routine.\n\n
\nThis file contains various data extract information utilized by the DSS\nWhen adding a new extract, make sure that the "LAST DATE XXX" is on\nsame piece of the 7 node as the "XXX" field is on the 7.1 node.\nExtracts software. This data includes the last date an extract was\nrun, the Austin queue receiving the extract data, and extract setup\ninformation.\n \nData in this file should be entered and edited only by using the DSS\nsoftware and not by direct access via VA FileMan.\n \n**TECH NOTE**\n\n
\nThis file holds data from the IV module of the Inpatient\nMedications package to be extracted by the DSS software. Data is entered\ninto this file by routine ECXPIV1 which is called by statistics options\nin the IV module. Data is deleted from this file after it is\nextracted in a form to be shipped to the commercial software.\n \nData in this file should not be entered, edited, or deleted through\ndirect access via VA FileMan.\n \n\n
\nThis file holds the DSS translation tables for entries in the HOSPITAL\nDSS manager on a regular basis and corrected as needed. Since several\nfields in this file are linked to fields in the HOSPITAL LOCATION\nfile (#44), data in this file should be entered and edited only by using\nthe DSS software and not by direct access via VA FileMan.\nLOCATION file (#44). For each clinic, this file holds its name, stop code,\ncredit stop code, and DSS alternatives for both stop code and credit stop\ncode. Also included is a field indicating which code should be sent to the\nDSS commercial software, that is, stop code, credit stop code, or both. If\nthere is no data in this file for a given clinic, the stop code in the\nHOSPITAL LOCATION file (#44) will be used. If DSS alternate stop\ncodes are entered, they will be used in place of those entered in the\nHOSPITAL LOCATION file (#44). This file should be reviewed by the\n\n
\nThis file contains the national standard clinic codes to be sent to the\ncommercial software as part of the DHCP DSS Extracts software. Entries\nin this file are compiled by the DSS Program Office.\n \nThis is a standard file exported with the DSS Extracts software. No\nadditions, deletions, or modifications to entries in this file are\npermitted. As updates become necessary, a new version of this file\nwill be released nationally.\n\n
\nThis file will hold the Managerial Cost Accounting (MCA) labor codes that\nare used to define the labor type associated with a specific clinic.\n\n
\nThis file contains various data extract information utilized by the DSS \nExtracts software. Data in this file should be entered and edited only by\nusing the DSS software and not by direct access via VA FileMan.\n\n
\nThis file contains various data extract information utilized by the DSS \nExtracts software. Data in this file should be entered and edited only by \nusing the DSS software and not by direct access via VA FileMan.\n\n
\nThis file holds information needed to determine the DSS drug product\nforce.\n \nFor these reasons, it is imperative that neither the data nor the\ndata dictionary for this file be modified at the local VAMC. As\nmodifications are required, they will be sent from the developers as\ndirected by the involved task force members.\ncode for any entry in the local DRUG file (#50) which has been matched\nto an entry in the NATIONAL DRUG file (#50.6). The determining factors\nare VA classification, route of administration, and, in some cases,\nspecific VA product name. These factors have been determined by the\nDSS pharmaceutical task force based, in part, on information provided\nby the National Drug File (NDF) task force. Use of this file depends\non fields in the local DRUG file (#50) which were set by the matching\nprocess in the National Drug File package as specified by the NDF task\n\n
\nThis file holds data from the Unit Dose module of the Inpatient\nMedications package to be extracted by the DSS software. Data is entered\ninto this file by routine ECXUD1 which is called by pick list options\nin the Unit Dose module. Data is deleted from this file after it is\nextracted in a form to be shipped to the commercial software.\n \nData in this file should not be entered, edited, or deleted through\ndirect access via VA FileMan.\n \n\n
\nThis file provides codes associated with DSS production units. These\ncodes are used when the DSS Site Manager develops DSS Department codes\nto be associated with various medical center entities such as wards.\n \nThis file is intended for read only purposes. It must not be modified\nin any way by the local site. Modifications to this file will be\ndistributed nationally in accordance with guidance provided by the\nDSS Bedford Technical Services Office.\n\n
\nThe Rad Modality Defined Terms file is required by the VistA Imaging\npossible for a single procedure to be performed on multiple modalities.\nFor example, a GASTROGRAPHIN UGI procedure can be done on a Radio\nFluoroscopy and a Computed Radiography modality.\n \nVistA Imaging software will build a modality worklist using this file and\nthe RAD/NUC MED PROCEDURE file entries. The worklist identifies the\nscheduled radiology cases to be performed on the individual modality\n(equipment).\napplication; entries in this file are as defined in the DICOM Standards PS\n3.3 - 2022a under section General Series Attribute Descriptions\n(C.7.3.1.1). The Radiology developers update entries in the file in\naccordance to changes in the DICOM Standards. THIS FILE CAN NOT BE\nEDITED.\n \nThis file is pointed to by the RAD/NUC MED PROCEDURE (#71), and for each\nactive procedure a modality or modalities must be identified. It is\n\n
\nWARNING: ENTRIES SHOULD NOT BE ADDED/DELETED/CHANGED FROM THIS FILE.\nPROCEDURE TYPE. The PROCEDURE TYPE is similar to the Type of Imaging in \nthe IMAGING TYPE file (#79.2), and is needed from this file to compare\nPROCEDURE TYPES nationally for performance monitors and performance\nmeasures, because not all sites are assigning the same Type of Imaging to\nthe same CPT Code via the RAD/NUC MED PROCEDURES file (#71).\n \nThis file contains only data supplied by the Office of Patient Care \nServices. The data are sent to the Radiology development and maintenance \nteams as an Excel spreadsheet. Updates to the data are sent as a \ncomprehensive spreadsheet, so all entries in this file must be deleted \nbefore loading the new comprehensive spreadsheet into this file.\n \nThis file provides data for certain CPT Codes. One of the data items is \n\n
\nThis file contains the approved list of national services. Entries in\nthis file are standard and should not be edited or deleted. A LOCAL\nSERVICE? field allows you to designate each national service as a\n'local' service. A T&L UNIT field is provided for associating \nT&L units with each 'local' service.\n\n
\nFile contains VAMC management information for each fiscal year.\nData includes assigned FTEE by service by FY, workload data, and\ncontract information. **WARNING** All data should be input\ninto this file through the IMS enter/edit menu options.\n\n
\nThis file serves as a planning tool for management. All local\nVAMC planned equipment may be tracked - including IRM/ADP\nand regional high technology equipment list items.\n\n
\nFile contains staffing data by service for each pay period.\n\n
\nFile of Regulatory Agencies for documenting citations.\n\n
\nThis file is used for Minor Design and Minor Miscellaneous Prioritization\nMethodology. Here points are given according to the type of space\nundergoing 100% renovation or new construction.\n\n
\nThis contains the H-08-9 Chapters for Space Planning. It is used to\nidentify areas where space is added or renovated in construction projects.\n\n
\nFile of Construction Project functional categories.\n\n
\nFile of Construction Progect budget categories.\n\n
\nThis file contains the reports for registered exams. These reports are\n I. Demographic information about the file\n - patient, date reported, date entered etc.\n II. Text Data\n - clinical history, report and impression\n III. Computed Fields that obtain data from patient's exam record\n - technician, procedure etc.\n \nThe computed fields can be a very efficent way to do File Man prints and\nsearches of exam record data, as opposed to doing prints and searches\nthrough the 'RAD/NUC MED PATIENT' file.\nusually first dictated by the interpreting physician before being entered\n \n Data Storage\n ------------\nThe data for the 'RAD/NUC MED REPORTS file is stored in the ^RARPT(\nglobal. This global is very volatile and should be journaled.\nIt should also be translated if the operating system supports this function.\n \nBecause of the large amount of disk space the report text will demand of\nthe system, the module has a 'Purge Data' function that will\nallow the site manager to delete the 'REPORT TEXT' and 'CLINCIAL HISTORY'\nby the transcriptionist.\nfields on a periodic basis. It is up to the computer site manager and\nthe imaging coordinator to determine how long this data will remain\non-line. The 'IMPRESSION' text will not be purged.\n \nIn the future, the module will also have an archive function.\n \n Input Templates\n ---------------\nThe following is a list of input templates used by the package\nand the entry in the OPTIONS file (#19) that uses the template:\n \n \n Compiled\n Name Routine Description; Option(s)\n ---- -------- ----------------------\n RA REPORT EDIT ^RACTWR* Used to enter/edit reports and associated\n information into this file;\n RA RPTENTRY\n \n RA VERIFY ^RACTVR* Used to indicate a report has been verified;\n REPORT ONLY RA BATCHVERIFY, RA RPTVERIFY\nThe Radiology/Nuclear Medicine software includes an HL7 interface to\n \n RA PRE-VERIFY REPORT EDIT Used to edit reports and associated \n information in this file. Does not allow\n report verification; RA RESIDENT PRE-VERIFY\n \n RA PRE-VERIFY REPORT ONLY Used to pre-verify reports;\n RA RESIDENT PRE-VERIFY\n \nIf any modifications to these input templates are needed for local\npurposes, then great care should be taken not to degrade any branching logic\nsupport report entry using voice recognition systems.\nin the template.\n \n Print Templates\n ---------------\n Compiled\n Name Routine Description; Option(s)\n ----- -------- ----------------------\n \n RA REPORT ^RACTRT Prints the status of verified reports only.\n PRINT STATUS Includes date verified, routing queue, date\n \n printed, printed by ward/clinic.\n RA RPTDISTPRINTSTATUS\n \n Sort Templates\n --------------\nThe package does not use any sort templates associated with this\nfile.\nThe data in this file has three basic sections:\n \n\n
\nThis file contains the standard report text that the interpreting\n Data Storage\n ------------\nThe data for the 'STANDARD REPORTS' file is stored in the ^RA(74.1,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\nThe following is a list of input templates used by the package\nphysician can choose from when dictating a report. The transcriptionist\nand the entry in the OPTIONS file (#19) that uses the template:\n \n Compiled\n Name Routine Description; Option(s)\n ---- ------- ----------------------\n RA STANDARD\n REPORT ENTRY Used to enter/edit entries in this file;\n RA STANDRPTS\n \n This template should not be modified.\nis usually the person who copies the standard report into the appropriate\n \n Print Templates\n ---------------\n The following is a list of print templates used by the package:\n \n Name Description; Option(s)\n ---- ------------------------\n RA STANDARD REPORTS LIST Print the impression and report for the\n entries in this file;\n RA STANDPRINT\nexam's report record while using the 'Report Enter/Edit' function.\n \n Sort Templates\n --------------\nThe package does not use any sort templates associated with this\nfile.\n \nThe transcriptionist will only be given the 'Select STANDARD REPORTS'\nprompt during the 'Report Enter/Edit' function if the 'division'\nparameter controlling standard reports use is set to 'yes'.\n \n\n
\nThis file provides the mechanism to group draft reports into logical\n o re-printing the reports if the printer malfunctions.\n o verifying the report can be done by batch with the\n user only answering the 'report status' prompt for\n each report. The system automatically proceeds through\n the reports in the batch.\n o if more than one transcriptionist has to print his/her reports\n on the same printer then batch printing prevents\n interweaving of each transcriptionist's reports.\n \nNaming of batches is controlled by the user and most often the name is the\ncategories to help in the efficent processing of these reports.\nname of the interpreting physician whose dictation the user is\ntranscribing. A user can only enter reports into a batch that he/she\ncreated.\n \n \n Data Storage\n ------------\nThe data for the 'REPORT BATCHES' file is stored in the ^RABTCH(74.2,\nglobal. This file is volatile and should be journaled. It should also\nbe translated if the operating system supports this function.\n \n \n Input Templates\n ---------------\nThe package does not use any input templates associated with this\nfile.\n \n Print Templates\n ---------------\nThe package does not use any print templates associated with this\nfile.\nUsually, an interpreting physician dictates a series of reports onto one\n \n Sort Templates\n --------------\nThe package does not use any sort templates associated with this\nfile.\ntape. The transcriptionist receives the tape and the patient folders\nassociated with the reports dictated on the tape. By placing the reports\nfor that tape in a single batch, usually by interpreting physician name,\nthe following processes will be improved:\n \n\n
\nThis file contains the names of the distribution queues and the\n \n \nInput Templates\n---------------\n \nThe following is a list of input templates used by the package and\nthe entry in the OPTIONS file (#19) that uses the template.\n \nName Description; Option(s)\n---- ---------------------\ncategory of reports for each queue.\nRA DISTRIBUTION EDIT Used to edit the report\n distribution queue.\n \nRA DISTRIBUTION LOG Edits the activity log of the\n distribution queue whenever\n reports are printed. This is\n done automatically by the system\n whenever reports are printed or\n re-printed from a queue.\n \n \n \nPrint Templates\n---------------\nThe following is a list of print templates used by the package:\n \nName Description; Option(s)\n---- ----------------------\nRA DISTRIBUTION Prints a list of names of\n the distribution queues and\n category of reports associated\n \n with each queue.\n \n \n \nSort Templates\n---------------\nThe package does not use any sort templates associated with\nthis file.\nData Storage\n------------\n \nThe data for 'REPORT DISTRIBUTION QUEUE' is stored under the ^RABTCH\n(74.3 global.\n\n
\nThis file points to the Rad/Nuc Med Reports file (#74). It contains only\n---------------\nThe following is a list of print templates used by the package:\n \nName Description; Option(s)\n---- ----------------------\nRA ALL UNPRINTED REPORTS Prints all unprinted reports for a distribution\n queue.\n \nRA PRINTED REPORTS Prints a list of previously printed reports for\n a distribution queue.\nverified reports associated with the various active distribution queues.\n \nRA UNPRINTED REPORTS Prints a list of unprinted reports in alpha-\n betical order by patient name.\n \n \nSort Templates\n--------------\nThe following is a list of sort templates associated with this file:\n \nName Related Print Template\n \n---- ----------------------\nRA ALL UNPRINTED RA ALL UNPRINTED REPORTS\n \nRA CLINIC BY PRINT DATE RA PRINTED REPORTS\n \nRA WARD BY PRINT DATE RA PRINTED REPORTS\nInput Templates\n---------------\nThe package does not use any input templates associated with this file.\n \n \nPrint Templates\n\n
\nContains the site-specific parameters (such as site name) for each VAMC.\n Incident Reporting\n Survey Generator\nThis file serves the entire QM package. Each component, such as\nOccurrence Screening, has one set of fields in the file. This set of\nfields is both number and node spaced. This file is pointed to by the\nOccurrence Screening file (#741). This file is populated at the site.\n PACKAGES USING SITE PARAMETER FILE:\n Occurrence Screen 2.0\n Credentials Tracking 1.0\n Patient Representative 2.0\n\n
\nThis file contains the print and sort macros generated by the Ad Hoc\nreport mechanism. The records in this file should be accessed only\nthrough the Ad Hoc report options.\n\n
\nContains an entry for each QM component, such as Occurrence Screening.\nEach package entry contains the user's name, date of entry, and type of\nentry for every time the QA OCCURRENCE SCREEN file (#741) is accessed.\nThis file is automatically populated every time access is made to this\nfile.\n\n
\nContains Occurrence Screening data for each occurrence screened, with\npatient name at the .01 level. This file is populated at the site.\n\n
\nContains the list of screens required by the Occurrence Screen circular,\nwith their descriptions. This file arrives populated with the standard\nscreens. The site can add their own screens also.\n\n
\nContains the list of review levels, such as Clinical and Peer. This data\nis used in the review process. This file arrives populated.\n\n
\nContains the names of persons authorized to be Clinical reviewers. This\ndata is used in the review process. This file is populated at the site.\n\n
\nContains the list of reasons for Clinical referral for further\nreview, itemized for each screen, as defined by the Occurrence\nScreen circular. This data is used in the review process.\nThis file arrives populated, but may be edited at the site.\n\n
\nContains the list of exceptions for each screen, as defined by the\nOccurrence Screen circular. This data is used in the review process.\nThis file arrives populated, but may be edited at the site.\n\n
\nContains the list of standardized review findings. This data is used in\nthe review process. This file arrives populated.\n\n
\nContains a list of standardized actions to be taken as a result of the\nreview findings. This file arrives populated.\n\n
\nContains the severity of outcome as defined by QM. This data is used in\nthe review process. This file arrives populated.\n\n
\nContains an entry for each treating specialty at the site, indicating\nwhich are considered to be Acute Care, Special Care, Intermediate Care,\nNHCU, or Psychiatry for QM purposes. This data is used in auto enrollment.\nThis file is populated at the site.\n\n
\nContains the list of Medical Teams at the site. This data is used in the\nreview process. This file is populated at the site.\n\n
\nContains the number of cases screened (i.e., total admissions, transfers,\netc.). This data is entered manually from data provided by MAS, and it\nis used for the Semi-Annual Report.\n\n
\nContains the list of standing committees at the site. This data is used\nin the review process. This file is populated at the site.\n\n
\nContains historical list of dates that auto enrollment was run. This\ndata is used for determining the need for reruns. This file is populated\nautomatically every time auto enroll is run.\n\n
\nThis file contains the full description of a monitor. Some of the data\nis purely descriptive. Other data in this file is used by the auto\nenroll portion of the Clinical Monitoring System.\n\n
\nThis file contains the patients who were found to fall out for given\nmonitors. Fall outs are created by the auto enroll batch run or by\nmanual entry. Any fall out record may be manually edited and its data\nor data elements changed.\n\n
\nThis file contains the statistics created by an active monitor and is\nupdated by the auto enroll batch run. The statistics are broken down\nby monitor and are further broken down by the time frame the monitor\nis running in.\n\n
\nThis file contains the conditions a user may select when building a\nmonitor. New conditions may be added by a programmer.\n\n
\nThis file contains the data elements from DHCP a user may select to be\ncaptured when a patient falls out for a given monitor. New data\nelements may be added by a programmer.\n\n
\nThis file contains groups of data from other DHCP files. Group data\nis used by many conditions to determine if a patient should fall out\nfor a given monitor. Users may create new groups and add or delete\ngroup members from existing groups\n\n
\nThis file contains the dates that auto enroll ran and the monitors that\nran for that date.\n\n
\nThis file contains the rationales that may be attached to a monitor.\nThe rationales are the same as those used by JCAHO. Other entries\nmay be added by the user.\n\n
\nThis file contains the time frames over which a monitor may aggregate\nstatistical data. New time frames may be added by a programmer.\n\n
\nThis is the QA survey generator file.\n\n
\nThis file holds the names of files which may be referenced for demographic\npurposes during survey responses by users.\n\n
\nThis file holds the questions for the surveys located in ^QA(748 .\n\n
\nHolds the responses given to survey questions by the survey participants.\n\n
\nThis file contains all information pertaining to an imaging order entered\n------------\nThe data for 'RAD/NUC MED ORDERS' file is stored in the ^RAO(75.1,global..\nThis file is very volatile and should be journaled and translated if the\noperating system supports these two functions.\n \n \n \nInput Templates\n---------------\nThe following is a list of input templates used by the package\nfor a patient. The file structure is like that of the Rad/Nuc Med Patient\nand in the OPTIONS file (#19) that uses the template:\n \n \nInput Template Name Input Template Description Option(s)\n------------------- -------------------------- ---------\nRA ORDER EXAM Enter an order for a VistA RAORDER EXAM \n Radiology procedure.\n \nRA QUICK EXAM ORDER Allows quick entry of one or RAQUICK EXAM ORDER\n multiple exams for a patient.\nfile. This imaging order file allows the storage of General Radiology,\n \nRA OERR EDIT Edit an unreleased order that\n was entered through the OE/RR package.\n \n \n \nPrint Templates\n---------------\nThere are no print templates associated with this file.\n \nNuclear Medicine, Magnetic Resonance Imaging, Computed Tomography,\n \n \nSort Templates\n--------------\nThere are no sort templates associated with this file.\nUltrasound and other types of imaging modality data.\n \n \n \nData Storage\n\n
\nThis file contains the reasons a user may select from when placing an\nInput Templates\n---------------\nThere are no input templates associated with this file.\n \n \n \nPrint Templates\n---------------\nThere are no print templates associated with this file.\n \norder in the 'HOLD' or 'CANCELLED' status.\n \n \nSort Templates\n--------------\nThere are no sort templates associated with this file.\n \nData Storage\n------------\nThe data for the 'RAD/NUC MED REASON' file is stored in the ^RA(75 global.\n \n \n \n\n
\n WARNING: ENTRIES SHOULD NOT BE ADDED/DELETED/CHANGED FROM THIS\n FILE.\n \n This file contains only data supplied by the Office of Community\n Care. The data are sent to the Radiology development and\n maintenance teams.\n \n This file contains the justifications a user may select from when\n referring an order to Community Care.\n\n
\nThis file is a map of Major Concepts within the Lexicon Utility and\ncontained in the expression file (#757.01). While the primary purpose \nof this file is for file maintenance, it also supports various other \nfunctions such as the display of classification codes by linking concepts\nto codes and the ability to filter out unwanted search responses by linking\nconcepts to semantic classes and types.\n\n
\nThis file records the usage of concepts by applications performing lookups\nusing the Special Lookup Routines provided with the Lexicon Utility. A listing\nof concept usage in decending order may be found at the "AF" index.\n\n
\nThis file contains all text pertaining to the Major Concepts, Concept\nSynonyms, Concept Lexical Variants, Synonymous Lexical Variants, and\nModified Concepts. It includes displayable text, distinguishing text (that\nportion of text that makes a modified concept different from the parent\nconcept) and the term definitions (when available). Searches are\nconducted using the special look-up routine LEXA1.\n\n
\nThis file contains the type of the expression (i.e., Major Concept, Synonyms,\nLexical Variants, Modified Concepts).\n\n
\nThis file contains the form of the expression (acronym, plural, trade name,\netc.).\n\n
\nSNOMED CT concepts are organized in hierarchies with multiple levels of \ngranularity. This file stores the names of the hierarchies and when\napplicable, the Lexicon Subset the hierarchy is a member of.\n\n
\nThis file contains classification codes from multiple classification\nsystems (i.e., ICD, CPT, DSM, SNOMED, Title 38, NANDA, NIC, COSTAR, COSTART,\nCRISP, etc.).\n\n
\nThis file contains the descriptive titles for medical terminology and\ndiagnosis and classification systems.\n\n
\nThis file contains the definition of a character\nposition in a code of a coding system where the\ncharacter positions have meaning.\n\n
\nThis file contains words which are meant to be excluded either from\nindexing, look-up, or both indexing and look-up. NOTE: Data Entries in \nthis file should not be altered by the site This file requires re-indexing\nto occur in a specified sequence. The complete re-indexing instructions\nare included in the Technical Manual.\n\n
\nIf the user input contains one of the words (single word) in this file, it\nwill be replaced by the corresponding term (one or more words). NOTE: Data\nEntries in this file should not be altered by the site. This file requires\nre-indexing to occur in a specified sequence. The complete re-indexing \ninstructions are included in the Technical Manual.\n\n
\nThis file provides feedback from the sites regarding the content of the \nNarrative flag set to 1. APPLICATION UNRESOLVED NARRATIVE occur when an\napplication detects a problem with an expression in the Expression file \n(757.01). The application can return the Internal Entry Number (IEN) of \nthat expression along with a short comment stating the problem. Periodically\nthe entries in this file will be packed up into a mail message and sent \nto G.LEXICON@ISC-SLC.DOMAIN.EXT for consideration for possible inclusion\nin the Lexicon. After the mail message is sent the entries in this\nfile are deleted. NOTE: This file is exported without data.\nLexicon. This is done either by a user through a calling application\n(user unresolved narratives) or by the calling application (application\nunresolved narratives). USER UNRESOLVED NARRATIVES occur when the user \nsearches the Lexicon and fails to find a suitable expression in \nthe Expression file (#757.01). If the user select to use his/her original\ntext, then user's input is temporarily stored in this file. However, for a\nUser Unresolved Narrative to be stored, the calling application must be \ndefined in the Subset Definition file (757.2) and have the Unresolved \n\n
\nThis file contains tokens (and abbreviations) that may require special\n PH pH Not as PH or Ph or ph\n IGA IgA Not as IGA or Iga\n COPD COPD Not as Copd or copd\n OR OR Used with an operating room\n OR or Not used with an operating room\n \n S X="CASE CHECK FOR; PH IGA COPD OPERATING ROOM OR"\n \n $$TITLE^XLFSTR(X) Case Check For; Ph Iga Copd Operating Room Or\n $$MIX^LEXXMC(X) Case Check for; pH IgA COPD Operating Room OR\nhandling when displaying on the screen. A token is a short string of\n \nBy placing the rules for case in a global, the rules can be easily \nchanged in data only quarterly patches.\ntext parsed from longer string by using delimiters (i.e., punctuation\nand special characters) and either has meaning by itself or is an \nabbreviation with meaning. For tokens that can be displayed in \nmultiple ways, rules are included to determine how the token is to be\ndisplayed.\n \n Example Displayed as Comment\n\n
\nThis file contains supplemental words to use during lookup and\nthe rules to use to apply the supplemental words to the expression.\n\n
\nThis file maps semantic classes and semantic types to the major concept,\nproviding contextual meaning to both the term as well as the words\ncontained in the term. This semantic meaning, when applied to the terms,\nis used as a filter during term file look-ups.\n\n
\nThis file contains the definitions of the semantical classes (groupings of\nrelated semantical types).\n\n
\nThis file contains the definitions of the semantical types.\n\n
\nThis file contains term categories provided by terminology source files.\n\n
\nThis file contains the name and when applicable, the file number of the source\nof the terminology.\n\n
\nThis file contains the definitions for vocabulary subsets in the Clinical\nLexicon, application definitions and user defaults (by application).\nThese vocabularies (defined primarily by the search filter and the index\nto be used while conducting searches) may be used during look-up in lieu\nof the main expression file (if indicated by either the application\ndefinition or the user's preferences).\n\n
\nThis file contains vocabulary subsets of the main Expressions file\n(#757.01). Each sub-set is defined in file #757.2, and may contain\n[pointers to] terms which are exclusive to a discipline (i.e., Nursing), a\ndevice (i.e., Grid Pad), or an application (i.e., Order Checking,\nEncounter Form, etc).\n\n
\nThis file contains some generic default screens in a DIC("S") format to be\nused while looking up terms in the Expression file.\n\n\nThis file contains some generic default display format to be used while\nlooking up terms in the Expression File.\n\n
\nThis file is used to define a mapping between one coding system (source\ncode) to another coding system (target code). The coding systems are \nlisted in the Coding Systems file 757.03.\n\n
\nThis file contains the mappings from one coding system to \nanother coding system. Selection of a term or a code from\none coding system can be translated to another coding system.\n\n
\nThis file contains a list of expressions (pointers) from the expression file\n#757.01 and shortcuts by context. The expression(s) pointed to will be returned\nimmediately if any of the context sensitive shortcuts associated with that\nexpression are detected (exact match) in the users input. The context must be\na default value stored in the user defaults in the Subset Definition file\n#757.2 to permit the use of the shortcuts.\n\n
\nThe Lexicon has the capability to maintain several\nsets of shortcuts to rapidly access the expression file.\nEach of these shortcut sets is named by the context for which\nthe shortcut set was meant to have been used. The user may\nselect this shortcut set by it's context name as their default\nset of shortcuts to use while searching the Lexicon.\n\n
\nThe Unified Code for Units of Measure (UCUM) Copyright Regenstrief\nInstitute, Inc. and the UCUM Organization, Indianapolis, IN. All rights\nreserved. This table of examples does not include all possible UCUM\ncodes. It does include those needed for routine laboratory and clinical\nmeasures. This table was compiled by the National Library of Medicine,\nNational Institutes of Health, U.S. Department of Health and Human\nServices with content contributions from Intermountain Healthcare and\nthe Regenstrief Institute. \n\n\n
\nThis file contains parameters associated with non-DHCP applications\nfrom whom the DHCP system can accept HL7 transmissions.\n \nThis is the main file that sites must edit before they can begin receiving\nHL7 transmissions from another system. This is done by using the\nNon-DHCP Application Parameters Enter/Edit option on the site manager's\nmenu.\n\n
\nThis file contains a list of Vista applications that are capable of\nsending and receiving HL7 transmissions. \n\n
\nThis file is designed to contain the definition of each standard field\nused by the system. The definition in this file can be compiled into\nroutines which can perform the basic checks of data received from or\nsent to another system.\n\n
\nA list of message types supported by the system.\n\n
\nA list of segments supported by the system.\n\n
\nA list of data types and their corresponding processing rules.\n\n
\nA list of versions of standard protocols supported by the system.\n\n
\nThis file is a table of statuses that are assigned to entries in the\nMessage Text file by the Messaging System.\n \nThis file should not be modified locally.\n\n
\nThis file is a table of error codes and messages that may be assigned to\nentries in the Message Text file by the Messaging System.\n \nThis file should not be modified locally.\n\n
\nThis file is a table of standard protocols supported by the Messaging\nSystem.\n \nThis file should not be modified locally.\n\n
\nA list of educational degrees as specified in the HL7 standard,\nuser-defined DEGREE table 0360.\n\n
\nThis file contains information related to the processing of all incoming\nand outgoing messages.\n\n
\nThis file is used to create and maintain unique message IDs. It also\ncontains a date/time when each ID was created.\n\n
\nThis file is used to control the flow of messages from one system to\nHLNN-Logical Link name\nHLTP-subscription type\n 0-patient descriptive only\n 1-patient clinical and descriptive\n 2-other (locally defined)\nHLAD-activation date\nHLTD-termination date (optional)\nHLRAP-HL7 receiving application\nHLER-error messages (pass by reference)\n \nanother. It is currently used by CIRN to permit sites to subscribe via HL7\nThe patient file maintains a pointer to this file. When a clinical event\ntakes place pertaining to a particular patient, the subscription control\nnumber is looked up in the patient file, then a call is made to return the\ncurrent list of subscribers using:\n \nGET^HLSUB(HLSCN,HLTP,HLCL,.HLL)\n \nHLSCN-subscription control number\nHLTP-subscription type (null returns ALL)\nHLCL-HL7 1.6 client protocol (optional, returned in first piece of return\nMaster File updates to patient information. This subscription 'request'\n array.\nHLL-return array. Always in format HLL("LINKS",n)=CLIENT^LOGICAL\n LINK^remainder of node data\n \nHL7 1.6, Patch 14 provides additional documentation on the HLL array and\ndynamic addressing in general.\nmessage contains the data necessary to update the Subscription Control\nfile via the api:\n \nUPD^HLSUB(HLSCN,HLNN,HLTP,HLAD,HLTD,HLRAP,.HLER)\n \nHLSCN-subscription control number\n\n\nThis file contains personal profiles for displaying events in the HL7 \nMonitor Event Log.\n\n
\nContains the body of an HL7 message, which excludes the message header \nsegment. For batch messages, it does not include the individual message \nheader segments or the batch trailer segment.\n\n
\nUsed to record each message as it is sent or received. The content of the\nmessage is stored in a file #777, as it might be sent to multiple locations\nand applications.\n\n
\nThis file is a table of event codes that are used by the Messaging\nSystem.\n \nThis file should not be modified locally.\n\n
\nThis file is a table of codes used by the Messaging System when\nprocessing acknowledgement messages.\n \nThis file should not be modified locally.\n\n
\nThis file is a table of codes used by the Messaging System when\nprocessing acknowledgement messages.\n \nThis file should not be modified locally.\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nThis file is a table of country codes that are used by the Messaging\nSystem when building message header segments.\n \nThis file should not be modified locally.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nThis file is a table of message structure codes that are defined by HL7\ntable 0354.\nThis file should not be modified locally.\n\n
\nThis file contains parameters used by the HLO (HL7 Optimized)\nthat are specific to the system the software is installed on.\n\n
\nThe Health Leven Seven (Optimized) software (HLO) was released as patch \nin an error report. \n\nA screen is identified by its name. The name should be namespaced and be\ndescriptive as to its intended use.\n\n\nHL*1.6*126 to the HL7 v1.6 software package. Although it is structurally and \nfunctionally an independent system, it is officially part of HL7 1.6. This is \na messaging system similar to the old HL7 1.6 package, but it was designed from \nthe ground up and is more robust, more capable, and supports a much higher \nmessage throughput. \n\nThis file is used create screens for reporting HLO messaging errors. A screen\nis a list of criteria used to either include or exclude specific error types\n\n
\nThis file is used to register sending and receiving applications for HL7\norder for an application to receive messages, it must specify an action \n(M tag^routine) for each type of message that it is capable of receiving, or a\ndefault action that applies when no messsage-specific action is defined.\nmessaging. For receiving applications, the process of registration consists of\nregistering what messages the application is prepared to receive.\n\nFor both sending and receiving applications, it is necessary to specify\nwhat package the application belongs to. For sending applications, that is\nthe only field that applies, other than the name of the sending application.\n\nAn application can be either a sender or a receiver of messages, or both. In \n\n
\nThe process registry is used by the HLO process manager to start, stop, and\nmanage all of the processes used by the HLO system.\n\n
\nThis file is used to store static routing lists for messages. \n \nStatic routing lists are lists of recipients that an application may create in\nadvance for its messages. The alternate routing method is dynamic routing, \nwhereby the recipient list is created by the application at the time the \nmessage is created.\n\n
\nThe Health Leven Seven (Optimized) software (HLO) was released as patch\n\nIt is not necessary to assign a priority to a queue. However, doing so\nwill change the frequency that HLO services the queue. Important queues that\ntend to be backed up should be assigned a higher priority. Less important\nqueues may be assigned a lower priority. The goal of setting queue priorities\nis to balance the HLO resources over the queues in order to obtain a desired\nperformance.\n\nCurrently priorities may be set only for outgoing queues, though the file\nwas designed to also support the assignment of priorities for incomming queues.\nHL*1.6*126 to the HL7 v1.6 software package. Although it is structurally and \nThe option for entering the type of queue (incomming or outgoing) currently\nwill automatically default to outgoing. A future enhancment may support\nthe ability to assign priorities to incomming queues.\n\nTo set the priority the name of the queue must be specified. As explained, \ncurrently the queue will be assumed to be outgoing. Optionally,if the priority\nis to be set only for a specific link then the link must be specified.\n\nExamples:\n\nfunctionally an independent system, it is officially part of HL7 1.6. This is\nYou could set the priority of an outgoing queue named "HLO OUT" without\nspecifying the link. The effect would be to set the priority of all outgoing\nqueues named "HLO OUT" regardless of the link.\n\nYou could set the priority of an outgoing queue named "HLO OUT" and also specify\nthe link. The effect would be to set the priority of the outgoing\nqueue named "HLO OUT" that is sending messages via that specific link only.\n\nIf a queue's priority is specified to apply to all links, but that queue's\npriority is also specified for a specific link, that specific priority setting\na messaging system similar to the old HL7 1.6 package, but it was designed from\nwill override the general one. \n\n\n\n\n\nthe ground up and is more robust, more capable, and supports a much higher\nmessage throughput. \n\nThis file contains the priorities of HLO queues as assigned by the system\noperations staff. \n\n
\nThis file contains the types of complications that may occur while a\nIf a 'contrast medium reaction' is associated with an exam, then the\npatient's record in the Allergy Tracking System will automatically be\nupdated to indicate he/she has had a reaction. As a result, everytime the\npatient is registered for a procedure that may involve contrast material,\nthe receptionist will be warned and he/she should then take appropriate\naction.\n \nEntries in this file should not be deleted. Adding new entries is always\nallowed.\n \nprocedure is being performed. If there is a complication during an exam,\n Data Storage\n ------------\nThe data for the 'COMPLICATIONS TYPE' file is stored in the ^RA(78.1,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\nThe package does not use any input templates associated with\nthen the technologist can indicate which of these complications in this\nthis file.\n \n Print Templates\n ---------------\nThe package does not use any print templates associated with this\nfile.\n \n Sort Templates\n --------------\nThe package does not use any sort templates associated with this\nfile the exam should be associated with by using either the 'Case No. Edit'\nfile.\nor 'Edit Exam By Patient' functions of the module.\n \nWhen the system is initialized, two complications are loaded into the\nmodule. They are 'no complications' and 'contrast reaction'.\n \n\n
\nThis file contains the print formats for the following types of imaging\nThe entries are all site specific. No entries are loaded when the\nmodule is initialized. Each format can contain any of the fields\nfrom the 'LABEL PRINT FIELDS' file.\n \nAlso, if the same print field is desired more than once on the same\n'format', then enclose the print field name in double quotes (").\nFor example, if two FREE TEXT fields are needed on a report header,\nthen at the 'Select PRINT FIELDS:' prompt enter "FREE TEXT".\n \n Data Storage\noutput:\n ------------\nThe data for the 'LBL/HDR/FTR FORMATS' file is stored in the ^RA(78.2,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\nThe following is a list of input templates used by the package\nand the entry in the OPTIONS file (#19) that uses the template:\n \n \n Compiled\n Name Routine Description; Option(s)\n ---- ------- ----------------------\n RA FLASH CARD EDIT Use to enter/edit formats into this file;\n RA FLASHFORM\n \n This input template should not be modified.\n \n Print Templates\n o flash cards\n ---------------\n The following is a list of print templates used by the package:\n \n Name Description; Option(s)\n ---- ----------------------\n RA FLASH PRINT Prints a listing of formats and their attributes;\n RA FLASHFORMP\n \n Sort Templates\n --------------\n o exam labels\n The following is a list of sort templates associated with this file:\n \n Name Related Print Template\n ---- ----------------------\n RA FLASH PRINT RA FLASH PRINT\n \n The modification of any sort template is not recommended.\n o jacket labels\n o report headers\n o report footers\n \n\n\nThis file contains the diagnostic codes that can be associated with an\nmodule is initialized:\n \n 1) NORMAL\n 2) MINOR ABNORMALITY\n 3) MINOR ABNORMALITY, NO ATTN, NEEDED\n 4) ABNORMALITY, ATTN. NEEDED\n 5) MAJOR ABNORMALITY, PHYSICIAN AWARE\n 6) UNDICTATED FILMS NOT RETURNED, 3 DAYS\n 7) UNSATISFACTORY/INCOMPLETE EXAM\n 8) POSSIBLE MALIGNANCY, FOLLOW-UP NEEDED\nexam. The code is attached to an exam at the same time the interpreting\n \nAs part of the system customization process, these entries can be deleted.\nHowever, once the system is in production, you should 'not' delete any\nentries. Adding new entries is always allowed.\n \nIf the site decides to enter diagnostic codes for exams, then\ndatabase searches can be performed using the 'DIAGNOSTIC CODE'\nfield of the exam record in the search criteria. For example, the\ndatabase can be searched for all 'normal' chest procedures.\n \nresident and/or staff physician is entered for the exam. The diagnostic\n Data Storage\n ------------\nThe data for the 'DIAGNOSTIC CODES' file is stored in the ^RA(78.3,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\nThe package does not use any input templates associated with this\ncode represents a quick overall summary of what the interpreting physician\nfile.\n \n Print Templates\n ---------------\n The following is a list of print templates used by the package:\n \n Name Description; Option(s)\n ---- ----------------------\n DIAGNOSTIC CODE PRINT Prints a list of entries in this file;\n RA DIAGP\nwrote in his/her report concerning the exam. [NOTE: Diagnostic code is not\n \n Sort Templates\n --------------\nThe package does not use any sort templates associated with this\nfile.\nthe impression. The impression is stored in the 'IMPRESSION' field of the\n'RAD/NUC MED REPORTS' file (#74).]\n \nThe following is the list of codes that are loaded when the\n\n
\nThis file contains the allowable film sizes that the technologist can\nEntries in this file should not be deleted. Adding new entries is always\nallowed.\n \n Data Storage\n ------------\nThe data for the FILM SIZES file is stored in the ^RA(78.4,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \nchoose from when s/he enters film data for an exam.\n Input Templates\n ---------------\nThe package does not use any input templates associated with this\nfile.\n \n Print Templates\n ---------------\nThe package does not use any print templates associated with this\nfile.\n \n \n Sort Templates\n --------------\nThe package does not use any sort templates associated with this\nfile.\nIf possible, it is a good idea to assign film types names that have\nunique characters at the beginning. If the first few characters are\nnot unique, then the technologist will always have to respond to another\n'Select' prompt when entering only the first few characters. To avoid\nthis second prompt, the technologist will have to enter many characters.\n \n\n
\nThis file contains all the camera/equip/rm that may be used to perform\n \nEntries in this file should not be deleted. Adding new entries is always\nallowed.\n \n Data Storage\n ------------\nThe data for the 'CAMERA/EQUIP/RM' file is stored in the ^RA(78.6,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\nimaging examinations. The 'RADIOLOGY LOCATIONS' file uses this file to\n \n Input Templates\n ---------------\nThe rad/nuc med package does not use any input templates associated with\nthis file.\n \n Print Templates\n ---------------\nThe rad/nuc med package does not use any print templates associated with\nthis file.\nindicate which camera/eqip/rm are allowable choices when the technologist\n \n Sort Templates\n --------------\nThe rad/nuc med package does not use any sort templates associated with\nthis file.\nattaches a camera/equip/rm to an exam s/he has performed. In other\nwords, when the procedure is performed on a patient at a location, the\nonly valid choices are those cameras/equip/rms associated with that\nlocation.\n \nA camera/equip/rm can be associated with more than one location.\n\n
\nThis file contains the names of the data fields that can be printed\n ------------\nThe data for the 'LABEL PRINT FIELDS' file is stored in the ^RA(78.7,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\nThe package does not use any input templates associated with this\nfile.\non a 'flash card', 'exam label', 'jacket label', 'report header' or\n \n Print Templates\n ---------------\nThe package does not use any print templates associated with this\nfile.\n \n Sort Templates\n --------------\nThe package does not use any sort templates associated with this\nfile.\n'report footer'. The formats indicating which fields to print are\nstored in 'FLASH CARD FORMATS' file (#78.2).\n \nThe entries in this file are entered by the developer and should not be\ndeleted. Also, no new entries should be entered.\n \n Data Storage\n\n
\nThis file holds all the information that gets transmitted to Austin\nFunctional Status and Outcome Database (FSOD). This file gets populated\nby the Functional Independence Measurement (FIM) Delphi template.\n\n
\nSite Parameter for Functional Independence (FIM).\n\n
\nThis records information for initial EEO Complaints and subsequent updates of information.\n\n
\nThis file contains the 18 expanded bases for filing EEO complaints.\n\n
\nThe corrective actions that the complainant is seeking to resolve the complaint to his/her satisfaction.\n\n
\nThis file records pre-formal complaint information for any complaint that has a Complaint Status (field #63 of file #785) of Informal.\n\n
\nThis area contains the 25 valid issue codes for initiating an EEO Complaint.\n\n
\nThis file contains all EEO investigators that will be available for\nselection through the EEO Complaint Tracking package. Updates to the\nentries in this file will be made by VA Central Office personnel.\n\n
\nThis search VA files for the proper domain and station to send the message. If the site is the Region, the message is not sent but placed in received file.\n\n
\nThis file contains, for each division entry, parameters that the module\n \nHowever, single division medical centers will not notice this in the\neveryday execution of the module.\n \nWithin a division there may be a number of physical locations\nwhere an imaging procedure can be performed. The module is designed to\nhandle multiple locations within a division. However, each location can\nonly be associated with one division. Location data is stored in the\n'IMAGING LOCATIONS' file (#79.1).\n \nuses during various stages of exam and report processing and inquiring.\nThese parameters are loaded into the user's partition once the module\ndetermines which division and location the user is currently associated\nwith. This is determined by one of two ways: 1) the device the user is\nusing is an entry in the 'INPUT DEVICES' sub-file of the 'IMAGING\nLOCATIONS' file or 2) if (1) is not true than the module will simply ask\nthe user what his/her current location is. Method 1 is becoming obsolete;\nit was used before virtual terminals came into being. Therefore, most\nsystems will ask the user for a sign-on imaging location.\n \n \nThese parameter switches allow the 'customizing' of the module for each\nEntries in this file should not be deleted. Adding new entries is always\nallowed.\n \n Data Storage\n ------------\nThe data for the 'RAD/NUC MED DIVISION' file is stored in the ^RA(79,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \ndivision by the package coordinator.\n Input Templates\n ---------------\nThe following is a list of input templates used by the package\nand the entry in the OPTIONS file (#19) that uses the template:\n \n Compiled\n Name Routine Description; Option(s)\n ---- ------- ----------------------\n RA DIVISION PARAMETERS Used to enter/edit division parameters\n that the package coordinator controls;\n \n RA SYSDIV\n \nIf any modifications to these input templates are needed for local\npurposes, then great care should be taken not to degrade any branching logic\nin the template.\n \n Print Templates\n ---------------\n The following is a list of print templates used by the radiology package:\n \nThe module is designed to handle multiple divisions within a medical\n Name Description; Option(s)\n ---- ----------------------\n RA IMAGE DIV LIST Prints the division parameters for the entries in\n this file;\n RA SYSDIVLIST\n \n Sort Templates\n --------------\nThe radiology package does not use any sort templates associated with this\nfile.\ncenter. While most medical centers only have one division, there are a\nnumber that are multi-divisional. As a result, it was necessary to\nstructure the entire system around the division concept.\n\n
\nThis file contains, for each imagaing location entry, parameters that the\n \nThese parameters are loaded into the user's partition once the module\ndetermines which division and location the user is currently\nassociated with. This is determined by one of two ways: 1) the device\nthe user is using is an entry in the 'INPUT DEVICES' sub-file for\na location or 2) if (1) is not true than the module will simply\nask the user what his/her current location is.\n \nEntries in this file should not be deleted. Adding new entries is always\nallowed.\nmodule uses during various stages of exam and report processing and\n \n Data Storage\n ------------\nThe data for the 'IMAGING LOCATIONS' file is stored in the ^RA(79.1,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\ninquiring. The parameter switches allow the 'customizing' of the module\nThe following is a list of input templates used by the package\nand the entry in the OPTIONS file (#19) that uses the template:\n \n Compiled\n Name Routine Description; Option(s)\n ---- ------- -----------------------\n RA LOCATION PARAMETERS Used to enter/edit location parameters\n that are controlled by the package\n coordinator;\n RA SYSLOC\nfor each location by the package coordinator.\n \n RA SITE MANAGER Used to enter/edit location parameters\n that are controlled by IRM;\n RA DEVICE\n \nIf any modifications to these input templates are needed for local\npurposes, then great care should be taken not to degrade any branching logic\nin the template.\n \n Print Templates\n \n ---------------\n The following is a list of print templates used by the package:\n \n Name Description; Option(s)\n ---- ----------------------\n RA IMAGE LOC LIST Print the location parameters for the entries in\n this file;\n RA SYSLOCLIST\n \n RA EXAM ROOM LIST Prints a list of cameras/equip/rms\nWithin an imaging division there may be a number of physical locations\n and the locations\n associated with the camera/equip/rm;\n RA SYSEXLIST\n \n Sort Templates\n --------------\n The following is a list of sort templates used by the package:\n \n Name Related Print Template\n ---- ----------------------\nwhere a imaging procedure can be performed. The module is designed to\n RA IMAGE LOC LIST RA IMAGE LOC LIST\n \n RA EXAM ROOM LIST RA EXAM ROOM LIST\n \n The modification of any sort templates is not recommended.\nhandle multiple locations within a division. However, each location can\nonly be associated with one division.\n\n
\nThis file contains, for each imaging type entry, parameters that the module\nThe data for the 'IMAGING TYPE' file is stored in the ^RA(79.2,\nglobal. At the present time this file is very static after day-one\ninitialization is complete. However, it still should be journaled.\nIt should also be translated if the operating system supports this function.\n \n Input Templates\n ---------------\nThe following is a list of input templates used by the package and\nthe entry in the OPTIONS file (#19) that uses the template:\n \nuses during various stages of exam and report processing and inquiring. The\n Compiled\n Name Routine Description; Option(s)\n ---- ------- ----------------------\n RA IMAGE PARAMETERS Used to specify timeout seconds and whether\n the hardware system the module is running on\n is under fail-soft mode;\n RA FAILSOFT\n \n RA ON-LINE CRITERIA Used to indicate how long certain data should\n remain on file before it can be purged;\nparameter switches allow the 'customizing' of the module for each type\n RA PURGE\n \nIf any modifications to these input templates are needed for local\npurposes, then great care should be taken not to degrade any branching logic\nin the template.\n \n Print Templates\n ---------------\n The following is a list of print templates used by the package:\n \nof imaging.\n Name Description; Option(s)\n ---- ----------------------\n RA ACTIVITY LOG Prints a list of the activity log entries for the\n imaging type;\n \nWARNING: ENTRIES SHOULD NOT BE DELETED FROM THIS FILE.\n \n Data Storage\n ------------\n\n
\nThe file holds parameters related to the application exceptions in \n \nDifferent HL7 interfaces enforce different business rules. For example,\nRadiology may wish to apply different business rules (for example \nprovider classification) to ''Principal Result Interpreter' (OBR-32) data.\n \nThis file is where interface specific business rules will be codified.\nprocessing of HL7 Radiology messages.\n \nDO NOT EDIT THIS FILE!\n \nFor designated applications, the file entries held the exceptions in \nprocessing of RAD HL7 messages. If the radiology department at the \nfacility chooses to rebroadcast HL7 report messages to the \noriginator of the message, that parameter is set in this file.\n\n
\nThis file contains the names of patient's tracked by the Women's Health\nname of facility responsible for breast and treatment needs, and personal\nhistory of sexual trauma. Information specific to the results of breast\nand cervical exams and procedures are stored in the WV Procedure (#790.1)\nfile. Administrative data is limited to the name of the current case\nmanager, the date of first encounter, and the date the patient record was\ninactivated.\napplication. Patient names may be either manually entered by a case\nmanager or loaded through the Automatically Load Patients [WV AUTOLOAD\nPATIENTS] option.\n \nOther data stored in this file can be categorized as demographic,\nadministrative, and clinical information. The clinical data reflects\ncurrent breast and cervical treatment needs, pregnancy information, breast\nand cervical treatment regimes, family history of breast cancer and DES,\n\n
\nThis file contains the names of Women's Health case managers located at\nthe medical center. Case managers are assigned to each female patient\nentered into the package and the information is used in displays and\nreports.\n\n
\nThis file contains the names of Women's Health maternity care \ncoordinators located at the medical center. Maternity care coordinators \nare assigned to each pregnant female patient entered into the package and \nthe information is used in displays, reports and alerts.\n\n
\nThis file stores the facility configurable software parameters that are\nused by the Women's Health package. Parameters may be specific to a\nsingle facility or multiple divisions within a single facility. The data\nin this file addresses the name of the default case manager, autoqueueing\nof result letters for normal PAPs and mammograms, linkages with the\nRadiology/Nuclear Medicine package, switches permitting the selection of\nspecific procedures, and default dates for marking procedures as\ndelinquent.\n\n
\nThis file contains a list of PAP regimens and their selection numbers.\nThere is no option to edit this file; new entries may be added through\nFileMan.\n\n
\nThis file tracks the PAP regimens, when they begin, who the patient is,\nand who entered the most recent information on the regimen.\n\n
\nThis file contains sources of referral for patients to the Women's Health\nProgram. For example, entries may be references to clinics or hospital\nservices (e.g., General Medicine Clinic, Triage), community activities or\nspecial events (e.g., health fairs), specific individuals, and newspapers\nadvertisements or articles. Additional information may be added to this\nfile by the case manager through the Add/Edit to Referral Source File\noption. This file is also referenced through the Edit/Print Patient Case\nData to document a specific referral source for a patient.\n\n
\nThis file is used to store lab test data sent from the LAB DATA file (#63)\nuntil such time as a Women's Health package user can determine if the lab\ntest should be entered as a procedure in the WV PROCEDURE file (#790.1).\nIf the lab test is converted into a procedure entry in FILE 790.1, it will\nbe deleted from this file. Also, the Women's Health package user may\ndecide to delete the lab test from this file if it is determined that the\nlab test is not to be tracked in FILE 790.1.\n\n
\nThis file contains the Women Veterans Health's database of procedures \nactually performed and the data associated with them.\n\n
\nThis file stores and defines the type of procedures that may be\nassociated with patients within this application. The procedure type\ndefinitions includes the name, abbreviation, synonyms, last accession #,\nCPT and ICD codes, and colposcopy related information. There is no option\nto edit this file although new entries may be added through FileMan. \n\n
\nThis file identifies instances where patients in the Women's Health\ndatabase were offered, but refused care (e.g., screening mammogram).\n\n
\nThis file stores a list of official results/diagnosis based on the\nBethesda Classification system for PAP smears and the American College of\nRadiology (ACR) for mammograms. Every result or diagnosis is associated\nwith procedure types appropriate for that term. File data is used to\ndocument appropriate results for procedures performed on women patients\nthrough the Add a New Procedure and Edit a Procedure options. This file\nis exported with data and should not be locally edited.\n\n
\nThis file allows for entries in the WV Results/Diagnosis (#790.31) file\n(related to radiology procedures only) to be matched to corresponding\nentries in the Radiology Diagnostic Codes (#78.3) file.\n\n
\nThis file stores information surrounding the date/time, purpose, and\ncircumstances (scheduling of procedures, results of tests, etc.) for each\npatient notification. These records are used to view the Browse\nNotifications and Program Snapshot reports.\n\n
\nThis file stores the notification types which decribe how test or\nSynonyms can be entered by the case manager(s) through the Edit Synonyms\nfor Notification Types option. This information is stored in a patient's\nrecord through the Add a New Notification or Edit a Notification option.\nprocedure results and treatment needs are communicated to the patient. The\nnotification type may be a letter, personal contact, an organization's\nname, or other term that describes the communication process. Entries in\nthis file may be tagged to identify the number of attempts associated with\nthe type of contact, e.g., first letter, second letter (certified), 3rd\nphone call.\n \nNew Notification Types can be entered into this file through VA FileMan.\n\n
\nThis file contains reasons for the notification i.e., the notification\nLetters may be created and edited by the case manager through the Add/Edit\na Notification Purpose & Letter option. All information in this file, can\nbe printed through the Print Notification Purpose & Letter File option.\nNotification information can be entered into a patient's record through\nthe Add a New Notification and Edit a Notification options.\nis in response to (a) the results of a test or procedure or (b) the\nscheduling of future treatment needs. The other fields in this file are\nused to (1) assign a priority (urgent, as soon as possible, routine), (2)\nassociate a synonym or abbreviation, (3) flag an entry as active or\ninactive, (4) store the text of the letter, (5) calculate default print\ndates for letters to patients on breast and cervical treatment needs, and\n(6) indicate whether a letter should be printed today or in the future.\n \n\n
\nThis file stores outcomes that can be associated with a patient\nnotification. These entries may be goal oriented (e.g., scheduled appt\nfor PAP, MAM normal letter sent), or an event (e.g., patient decease, Tx\nelsewhere, unable to contact patient). Notification outcomes are\ndocumented through the Add a New Notification and Edit a Notification\noptions.\n\n
\nThis file contains a list of terms/phrases used to describe the cervial\ntreatment needs of women patients. Entries may be tests, therapeutic\nprocedures, or other actions (e.g., referral to another\nfacility, chart review). There is no option to edit this file; new\nentries may be added through FileMan.\n\n
\nThis file contains a list of terms/phrases used to describe breast\ntreatment needs for women patients. Entries may be tests,\ntherapeutic procedures, or other actions (e.g., referral to another\nfacility, chart review) related to breast care. There is no option to\nedit this file; new entries may be added through FileMan.\n\n
\nThis file holds a copy of the original generic notification letter which\ncan be used to restore the sample letter in the Notification Purpose file\n(#790.404) if it is accidentally deleted. The actual restoration or\nplacement of a copy of this letter in File 790.404 is performed by the\ncase manager through the Add/Edit a Notification Purpose & Letter option.\n\n
\nThis file contains information aggregated from data stored in the WV\nProcedure (790.1), WV Notification (790.4), and WV Refusals (790.3) files.\nData storage is dependent upon running the Snapshot of the Program Today\noption and answering YES to the question, "Should today's Snapshot be\nstored for later retrieval and comparisons?" These records provide a\nhistorical perspective of the Woman Veterans Health Program at your\nfacility and may be printed through the Retrieve/Print Earlier Snapshot\noption.\n\n
\nThis file stores an age range that is used to print a Procedure Statistics\nReport and a Screening Rates for PAPs and MAMs report. The age range\nstring is entered through the age range sort prompt within each report\noption and is displayed as the default when printing additional reports.\n\n
\nData stored in the PREGNANCY STATUSES and LACTATION STATUSES multiple\nDOCUMENT ACTION EVENT protocol) populates this file with data. The Edit\nPregnancy/Lactation Status Data [WV EDIT PREG/LAC STATUS DATA] option\nconsumes data in this file.\nfields in the WV PATIENT file are associated with an entry in the VISIT\nfile and an entry in the TIU DOCUMENT file. Since a user can reassign and\nretract documents, the data associated with reassigned or retracted \ndocuments may no longer be valid for the patient, thus prompting a review \nof the patient's chart. This file stores data that will assist case\nmanagers and/or maternity care coordinators in that review.\n \nThe WV ACT ON DOCUMENT ACTION protocol (which is executed by the TIU\n\n
\nThe pregnancy and lactation status of a patient are stored in up to four \nregistration packages are monitored for changes. When a conflict is\nidentified, a Computerized Patient Record System (CPRS) notification is\ngenerated that when processed, allows the recipient to update the \nappropriate status in the women's health package. This file stores the\nevents that triggered that status conflict notification.\ndifferent locations within VistA: the women's health package (data was \nobtained verbally from the patient), the laboratory package (a pregnancy \ntest was resulted), the patient care encounter (PCE) package (a diagnosis\nor procedure code was recorded that indicates the patient's pregnancy or\nlactation status) and the registration package (a diagnosis or procedure \ncode was recorded that indicates the patient's pregnancy or lactation \nstatus). To ensure that all four packages are in agreement as to the\npatient's current pregnancy or lactation status, the laboratory, PCE and \n\n
\nThis file stores data about the various methods of contraception.\n\n
\nThis file contains all order information for orders entered\nthrough the Remote Order/Entry System.\n\n
\nThis file contains information about order types used in the\nRemote Order/Entry System. It consistst of a list of all available\norder types. Associated with each type of order is the type abbreviation,\nwhich is used internally in system routines to determine branching for\ntype specific displays and input sequencing. Each type is also designated\nas a Patient Type of order or a Station Type of order. All data in this\nfile is distributed with the ROES and should not be edited at the local\nfacility.\n\n
\nThis file contains the statuses that orders may have in the\nRemote Order/Entry System. Many funtions of the ROES are restricted\nto orders with a specific status. All data in this file is distributed\nwith the ROES and should not be edited at the local facility.\n\n
\nThe Disability File contains all diagnostic disability codes that may be\nused to establish a veteran's eligibility for ROES orders. Each code is\nassociated with one or more product groups that are available from the\nDDC. The diagnostic codes are looked up in dictionary 31, the\nDisability Condition File, using the "C" cross reference. All data in this\nfile is distributed with ROES and should not be edited at the local\nfacility.\n\n
\nThis file contains the eligibilities that make a veteran eligible for ROES\norders. All data in the file is distributed with ROES and should not\nbe edited at the local facility.\n\n
\nThe ROES Menu file contains the memus for ROES. Each menu is assigned to a\nService and is designed to restrict such things as product groups and\ndisability codes used with the menu or for the Service. All data in this\nfile is distributed with ROES and should not be edited by the local\nfacility.\n\n
\nThis file contains reasons why an order may be delayed\nbeyond the standard time set by Audiology and Speech Pathology Service\nin VACO. All data in this file is distributed with ROES and should not be\nedited by the local facility.\n\n
\nThis file contains all the products. that may be ordered from the\napproximation of the cost. The file should not be edited by the local\nfacility\nDenver Distribution Center through the Remote Order/Entry System.\nThe file contains information about each item that is needed in the order\nprocess. Components, batteries, etc. that may be used with each item are\nalso stored in the file. This file is exported by the DDC. The file will\nbe updated via patch as contracts are updated. Since the unit cost of some\nitems varies with discounts that occur on individual purchase orders for\nthat item, the cost field in this file may not exactly match the cost from\nthe DDC at the time the order is filled, but should give the user a close\n\n
\nThis file contains the product groups for line items that may be ordered\nfrom the Denver Distribution Center through the Remote\nOrder/Entry System. Each item in the Remote Inventory Product File has an\nassigned product group. This file controls the ability of individuals at\nthe station level to order an item. (e.g., Only the staff of ASPS will be\nable to order hearing aids) All data in this file is distributed with the\nROES. The file should not be edited by the local facility.\n\n
\nThis file contains hearing aid components that may be ordered with custom\nhearing aids from the Denver Distribution Center through the DDC\nRemote Order/Entry System. Each hearing aid in the Remote Inventory\nProduct File may have associated with it a component or components from\nthis file. This file is exported by the DDC with data. The file will be\nupdated via patch if components are added or inactivated. The file should\nnot be edited at the local facility.\n\n
\nThis file contains batteries that may be issued for line items distributed\nby the Denver Distribution Center through the Remote Order/\nEntry System. Each entry in the Remote Inventory Product file may have\nassociated batteries from this file. This file is distributed with data.\nUpdates to the file will be made via patch. The file should not be edited\nat the local facility.\n\n
\nThe Remote Prosthetic Item Brands file contains a list of Prosthetic\nBrands available for items contained in the Remote Inventory Product File.\nThis file is distributed with data. Updates to the file will be made via\npatch. The file should not be edited at the local facility.\n\n
\nThe Transmission Batch File contains individual batches of orders with\nexact format that is sent in the mail message to the DDC. This information\nis stored in the "H" node of the file which is a non-standard node. The\n"H" node has been made non-standard in order to conserve space in the\ntransmission message.\n \nData definitions for this file are distributed with the ROES. No data is\ndistributed.\npointers to all orders that have been grouped in that batch for\ntransmission to the DDC. The file contains information specific to each\nbatch, such as the status of the batch and the pointer to the transmission\nmessage. This is a dynamic file whose entries are deleted as part of the\npurge process when all orders in the batch are no longer active.\n \nWhen a transmission batch is closed, all information needed by the DDC for\neach order is gathered and stored in the Transmission Batch File in the\n\n
\nThe Remote Order/Entry Parameter File contains a number of fields\nthat give the ADPAC's at each local facility the ability to customize\nportions of the system for use at their stations. Definitions of each\nparameter and recommendations for the settings to be used are included in\nthe Parameters section of the ROES V2.0 Technical Manual.\n \nData definitions are distributed with the ROES. No data is distributed.\n\n
\nThis file is used to facilitate the approval of ROES eligibilities\norder can be placed. A message is sent to the RMPF ROES UPDATES (PSAS)\nmail group that a request was entered. PSAS uses the RMPFDE2 option\nto evaluate the request and a message back to the RMPF ROES UPDATES (ASPS)\nmail group is sent. From that time, when the ROES application is\naccessed for the patient, the action by PSAS will be noted and the\nconnection will be made if the eligibility was approved.\nthat are entered by ASPS (Audiology and Speech Pathology Service)\nand are required to be approved by PSAS (Prosthetics and Sensory Aids\nService). All of the fields are populated by data from the ROES3.exe\nand the Vista RMPFDE2 option. No direct editing should be necessary.\nROES3 is a GUI application that is accessed from the CPRS Tools menu.\nThrough ROES 3, ASPS connects to the DDC web site to order supplies\nfor patients. If the patient does not have pre-appoved eligibility\nfor ROES orders, it must be sent to PSAS for approval, before the\n\n
\nThe ROR REGISTRY RECORD file contains records of\nand the uniqueness index "KEY" are used for that\npurpose).\n \nWhen the record of this file is deleted, the logic\nof the ADELETE cross-reference tries to delete the\nassociated records from the ROR HIV RECORD \n(#799.4), ROR PATIENT (#798.4), and ROR PATIENT\nEVENTS (#798.3) files.\n \nA permanent screen (the ^DD(798,0,"SCR") node) \nlocal registries. Each record associates a patient\nrestricts access to records of this file. Users\ncan only access records of those registries that\nthey have the security key(s) for. Users with the\nROR VA IRM security key can access all records of\nthe file.\n \nIf you want the changes in the security keys\nallocation to have an effect immediately, you \nshould rebuild the "ACL" cross-reference of the\n.01 field of the SECURITY KEY multiple of the ROR\nwith a registry and contains registry-specific and\nREGISTRY PARAMETERS file (#798.1). See the\ndescription of the cross-reference for more\ndetails.\nadditional service information (when the patient \nwas added to the registry, if they were confirmed,\netc).\n \nRecords of the file are uniquely identified by \nthe patient and the registry (the "A" primary key\n\n
\nRecords of the ROR REGISTRY PARAMETERS file \nA permanent screen (the ^DD(798.1,0,"SCR") node) \nrestricts access to records of this file. Users\ncan only access records of those registries that\nthey have the security key(s) for. Users with the\nROR VA IRM security key can access all records of\nthe file.\n \nIf you want the changes in the security keys \nallocation to have an effect immediately, you\nshould rebuild the "ACL" cross-reference of the\ncontain various registry parameters and the data\n.01 field of the SECURITY KEY multiple of this\nfile. See the description of the cross-reference\nfor more details.\nthat indicates current registry state. Every \nregistry must have a record in this file.\n \nRecords of the file are uniquely identified by the\nregistry name (the "A" primary key and the\nuniqueness index "B" are used for that purpose).\n \n\n
\nThe ROR SELECTION RULES file contains definitions\nadded to the corresponding registry.\n \nLower level rules are referenced only by other \nrules (by rule macros in the expressions). Their\nexpressions are evaluated in the proper order, and\nthe result values are used in the expressions of \nother rules. Lower level rules have an indirect\nimpact on the final result and can be used for\ncomplex processing of linked files and multiples.\n \nof the selection rules that are used to screen\nFor example, a lower level rule can calculate \nmaximum and minimum values of a parameter in the\nsub-file, and a top-level rule will analyze these\nvalues and decide if the patient should be added \nto the registry. Moreover, they could be used to\nsplit a very complex rule into several simpler\nrules.\n \nRecords of the file are uniquely identified by the\nrule name (the "A" primary key and the uniqueness\npatients for addition to the registries. There are\nindex "B" are used for this purpose).\ntwo kinds of rules: top-level and lower level.\n \nIf a rule is referenced by the ROR REGISTRY \nPARAMETERS file, it is the top-level rule.\nNon-zero value of any top-level rule expression \ndirectly determines that the patient should be\n\n
\nThe ROR PATIENT EVENTS file is used to store \n \nRecords of the file have the same internal entry \nnumbers as the internal values of the PATIENT NAME\nfield ('DINUM' feature).\nreferences to those patients that were processed \nwith errors and were not added to the registry \n(see the ERROR multiple).\n \nMoreover, the data references generated by the \nevent protocols are stored in this file (see the \nEVENT multiple). These references are used to \nspeed up the regular registry updates.\n\n\nThe ROR PATIENT file contains patient information\nthat from the PATIENT file (#2) to determine if it\nhas been changed since the last registry data\nextraction. These fields are updated with the\nvalues from the PATIENT file and the UPDATE\nDEMOGRAPHICS flag is set to "YES" in all active\nregistry records of the patient.\n \nRecords in the file have the same internal entry \nnumbers as the patients' records in the PATIENT\nfile. The records are uniquely identified by\nthat is common for all local registries (mostly,\nthe internal value of the PATIENT NAME field.\n \nA permanent screen (the ^DD(798.4,0,"SCR") node) \nrestricts access to the records of this file. Only\nusers with the security key(s) for any defined\nregistry (or those with the ROR VA IRM security\nkey) can access records of the file.\n \nIf you want the changes in the security keys\nallocation to have an effect immediately, you \ndemographic information).\nshould rebuild the "ACL" cross-reference of the\n.01 field of the SECURITY KEY multiple of the ROR\nREGISTRY PARAMETERS file (#798.1). See the\ndescription of the cross-reference for more\ndetails.\n \nMost of the fields in the file have the same \nnumbers and names as the corresponding fields in\nthe PATIENT file.\n \nDemographic data from this file is compared to\n\n
\nThis file stores all the ICD procedure and diagnostic codes and\nthe CPT codes used to identify patients for a given registry during the\nRegistry Update process. The B cross references for the ICD CODE, ICD\nPROCEDURE CODE and the INPATIENT CPT CODE are used in the EXPRESSION of the\nROR SELECTION RULES file (#798.2). The file design allows CCR to support\nan unlimited number of codes selected from the ICD DIAGNOSIS file (#80),\nthe ICD OPERATION/PROCEDURE file (#80.1) and the CPT file (#81).\n\n
\nThis file contains a list of pointers to the VA \nDrug Class file (#50.605). Within the Pharmacy\npackage each class is linked to a group of\nmedications. Each class in this file has an\nassociated registry, the "AC" cross-reference\ngroups all entries by registry.\n\n
\nThe ROR LOG file is used for recording different\nA permanent screen (the ^DD(798.7,0,"SCR") node) \nrestricts access to records of this file. Only\nusers with the security key(s) for any defined \nregistry (or those with the ROR VA IRM security\nkey) can access records of the file.\n \nIf you want the changes in the security keys \nallocation to have an effect immediately, you\nshould rebuild the "ACL" cross-reference of the\n.01 field of the SECURITY KEY multiple of the ROR\nkinds of events (errors, debug messages, etc.)\nREGISTRY PARAMETERS file (#798.1). See the \ndescription of the cross-reference for more\ndetails.\nthat are generated by registry processes.\n \nYou may control event recording via parameters in\nthe ROR REGISTRY PARAMETERS file. Look for\nadditional information in the RORLOG and RORERR\nroutines.\n \n\n
\nThe ROR TASK file enhances the functionality of \n \nUsually, you should not edit records of this file \ndirectly. The file is maintained by the APIs \nlocated in the RORTSK* routines.\n \nA permanent screen (the ^DD(798.8,0,"SCR") node) \nrestricts access to the records of this file. Only\nusers with the security key(s) for any defined\nregistry (or those with the ROR VA IRM security\nkey) can access records of the file.\nTaskman and supports the package APIs used by the\n \nIf you want the changes in the security keys \nallocation to have an effect immediately, you\nshould rebuild the "ACL" cross-reference of the\n.01 field of the SECURITY KEY multiple of the ROR\nREGISTRY PARAMETERS file (#798.1). See the\ndescription of the cross-reference for more\ndetails.\nGUI to schedule and control tasks, and view\nand print reports.\n \nRecords in the file have the same internal entry \nnumbers as the corresponding tasks in Taskman. The\nrecords are uniquely identified by the internal \nvalue of the TASK NUMBER field.\n\n
\nLab search criteria are stored in this file. These\nuniqueness index are used for this purpose.\ncriteria are referenced by the selection rules and\nused in the search for Lab results.\n \nIt is possible but not recommended to use the same\ncriterion for several different registries.\n \nRecords of the file are uniquely identified by the\ncriterion name. The "A" primary key and the "B"\n\n
\nTHIS FILE MUST NOT BE MODIFIED LOCALLY! ONLY \nregistry field), registry and item code. The "A"\nprimary key and the "KEY" uniqueness index are\nused for this purpose.\n \nDO NOT DELETE RECORDS FROM THIS FILE IF THEY HAVE \nBEEN DISTRIBUTED TO THE SITES ALREADY!\nAUTHORIZED NATIONAL REGISTRY DEVELOPERS CAN EDIT\nTHIS FILE!\n \nThis file contains code sets used within different\nregistries.\n \nRecords of the file are uniquely identified by the\ntype (it associates the set of values with the \n\n
\nTHIS FILE MUST NOT BE MODIFIED LOCALLY! ONLY \nengine, data elements and APIs.\n \nThe expression parser uses data stored in this \nfile to validate expressions that implement\nselection rules.\n \nData from this file loaded and prepared by the\n$$METADATA^RORUPR1 function is used by the\nregistry update process to load values of the data\nelements using appropriate APIs.\nAUTHORIZED NATIONAL REGISTRY DEVELOPERS CAN EDIT\n \nDevelopers can use this file as a source of \ninformation required for definition of new \nselection rules for new national or local\nregistries (supported files and data elements,\nAPIs, DBIAs, etc.).\n \nAll modifications of the registry update routines\nthat affect the file-processing tree, APIs or\nsupported data elements MUST be reflected in the \nTHIS FILE!\nROR METADATA file.\n \nRecords of this file have internal entry numbers \nequal to the corresponding file numbers.\n \nThe ROR METADATA file contains descriptors of the\nfiles, data elements and APIs used by the registry\nupdate subsystem (search engine). These\ndescriptors define relationships between files\n("file-processing tree") used by the search\n\n\nTHIS FILE MUST NOT BE MODIFIED LOCALLY! ONLY \nAUTHORIZED NATIONAL REGISTRY DEVELOPERS CAN EDIT\nTHIS FILE!\n \nThe ROR XML ELEMENT file contains a list of XML \ntags and attributes that can be used in the \nreports.\n\n
\nTHIS FILE MUST NOT BE MODIFIED LOCALLY! ONLY \nDO NOT EDIT OR DELETE RECORDS FROM THIS FILE IF\nTHEY HAVE BEEN DISTRIBUTED TO THE SITES ALREADY!\nAUTHORIZED NATIONAL REGISTRY DEVELOPERS CAN EDIT\nTHIS FILE!\n \nThe ROR DATA AREA file stores codes and names of\nthe data areas referenced by the DATA AREA (the\nROR HISTORICAL DATA EXTRACTION file) and the EVENT\n(the ROR PATIENT EVENTS file) multiples.\n \n\n
\nThe ROR REPORT PARAMETERS file stores the report\ndefinitions that are used by the ROR REPORT \nSCHEDULE remote procedure to schedule the reports.\n \nRecords of the file are uniquely identified by the\nreport code (the "A" primary key and the\nuniqueness index "KEY" are used for that purpose).\n\n
\nThe ROR HIV RECORD file stores the patients' data\nREGISTRY RECORD file, the corresponding record of \nthis file is deleted automatically.\n \nA permanent screen (the ^DD(799.4,0,"SCR") node) \nrestricts access to this file. Only the users who\nhave the CCR:HIV security key(s) and those with\nthe ROR VA IRM key can access the records of the\nfile.\nspecific to the Human Immunodeficiency Virus\nRegistry (CCR:HIV).\n \nRecords of this file have the same internal entry\nnumbers as the corresponding records of the ROR \nREGISTRY RECORD file (#798).\n \nWhen an CCR:HIV record is deleted from the ROR \n\n
\nTHIS FILE MUST NOT BE MODIFIED LOCALLY! ONLY \nof the ROR ICR STUDY file (#799.4).\nAUTHORIZED NATIONAL REGISTRY DEVELOPERS CAN EDIT\nTHIS FILE!\n \nThe ROR AIDS INDICATOR DISEASE file contains \ndefinitions of the AIDS indicator diseases \nreferenced by part VIII of the HIV CDC form.\n \nAlso see the AIDS INDICATOR DISEASE multiple (10)\n\n
\nThis file contains a list of registry specific\ngeneric medications. For example, the ARV \n(anti-retroviral) medications associated with the\nHuman Immunodeficiency Virus (HIV) registry are\nstored here.\n\n
\nThe ROR LOCAL FIELD file stores definitions of\nlocal registry-specific fields created at the \nsite.\n \nUniqueness of the field names for a particular\nregistry is enforced by the primary key "A" and \nuniqueness index "KEY".\n\n
\nRecords of this file store parameters of the \nhistorical data extractions (backpulls) performed\non the registries and reflect status of these data\nextractions.\n \nRecords of the file are uniquely identified by the\nhistorical data extraction name (the "A" primary\nkey and the uniqueness index "B" are used for that\npurpose).\n\n
\nICD Diagnosis file #80 contains codes from the International \n \nThis table file should NOT be edited in anyway by the site.\nClassification of Diseases (ICD) Clinical Modification (CM) \nprovided by the Centers for Medicare and Medicaid Services \n(CMS) and the National Center for Health Statistics (NCHS).\nThis file contains both the 9th (ICD-9-CM) and 10th (ICD-10-CM)\nRevisions.\n \nIf an entry needs to be added, modified or deleted, a patch will\nbe issued containing the change.\n\n
\nICD Operations/Procedure file #80.1 contains codes from the \n \nThis table file should NOT be edited in anyway by the site.\nInternational Classification of Diseases (ICD) Procedure Coding\nSystem (PCS) provided by the Centers for Medicare and Medicaid\nServices (CMS) and the National Center for Health Statistics\n(NCHS). This file contains both the 9th (ICD-9-PCS) and 10th\n(ICD-10-PCS) Revisions.\n \nIf an entry needs to be added, modified or deleted, a patch will\nbe issued containing the change.\n\n
\nThis file contains all DRG's, their Trim Points, Affiliated and\nNon-affiliated weights, etc.\n\n
\nThis file contains Major Diagnostic Categories as used in PTF coding.\n\n
\nThis file contains a listing of ICD coding systems stored in\nfile 80 and 80.1. The Internal Entry Numbers (IENs) in this\nfile are identical to those found in the Lexicon's CODING \nSYSTEM file 757.03.\n \nThis table file should NOT be edited in anyway by the site.\n\n
\nThis is the Surgical Hierarchy file. It is populated with data from CMS \n(Centers for Medicare and Medicaid Services). The data is used to \ndetermine the DRG (Diagnosis Related Group) by MDC (Major Diagnostic \nCategory) in surgical order of importance. \n\n
\nThis file is used to check if a Diagnosis Code is a Hospital Acquired \nCondition (HAC)\n\n
\nContains all valid ICD diagnosis codes.\n\n
\nContains all valid ICD Operation/Procedure codes.\n\n
\nThis file contains all DRG's, their Trim Points, Affiliated and\nNon-affiliated weights, etc.\n\n
\nThis file contains the parameters used by the Clinical Reminders\npackage.\n\n
\nThis file contains the data needed for eHMP data retrieval. The top level \nfields store information about servers know to eHMP. Each patient's \nsubscription is stored in #800000.01 sub-file for a server.\n\n
\nThis file is used when transferring specific patient objects\nto JDS.\n\n
\nThis file is a staging area for JSON uid objects.\n\n
\nA translation table for use by eHMP to connect VistA\ndata domains to JSON objects for transmission.\n\n
\nThis File contains the extraction domains which can be\ntransmitted.\n\n
\nThis file contains a list of the attributes of the eHMP\ndata domains.\n\n
\nContains the Rule Sets that contain the cohorts for creating patient panels.\nFor example, panel which includes Diabetic patients will be created\nnightly to update the list of patients. All panels in this file will be\nupdated nightly.\n\n
\nThis file contains eHMP rosters which can be used by\nsubscribed patients.\n\n
\nThe HMP Activity File contains appointments for patients\nwhich are subscribed to eHMP.\n\n
\nThis file is used to log VistA events relevant to the eHMP environment.\nIts primary purpose is to record data that otherwise would not be\nlogged, such as corrupt or missing data, or broken pointers.\n \nIt is also used by the eHMP to log maintenance activities.\n\n
\nThis file contains a list of items that should have a reminder order \ncheck rule(s). The rule(s) attached to an Order Check Items Group will\nonly be evaluated when the pass in Orderable Item or Drug matches to at\nleast one item the Order Check Items Group.\n\n
\nThis file contains a list of order check rules. An order check rule can only\ncontain one reminder term or one reminder definition. When the order check rule\nis processed, it runs either the reminder term or the reminder definition \nevaluation process. When the order check rule evaluates as true, it returns\nthe appropriate order check text.\n\n\n
\nThis file is used to define all of the components that work together to \nwith PXRM. Entries in this file may be auto-generated via the Dialog \nManagement Menu option. Manually created dialog entries should use local \nnamespacing conventions. Nationally distributed entries will have their \nclass type defined as National. Entries created at the VISN level should be \ndefined as VISN and entries created at a site should be defined as Local. \n \nThis file is similar to the option file where there are different types of \nentries (reminder dialog, dialog elements (sentences), prompts, and groups \nof elements, result elements and groups of result elements). Where an option \nhas menu items, the dialog file has components that are entered, with the \ndefine a reminder dialog. Reminder dialog definitions are used by the CPRS \nsequence field as the .01 field. \n \nA prompt is defined for PCE prompts, WH Notification Purpose, or as locally \ncreated comment check-boxes. The prompts will not have any components within \nthem. PXRM-prefixed prompts are distributed in this file with the Clinical \nReminder package. \n \nA dialog element is defined primarily to represent sentences to display in \nthe CPRS window with a check-box. When the user checks the sentence off, the\nFINDING ITEM in the dialog element and the ADDITIONAL FINDINGS will be added \nGUI for reminder resolution. \nto the list of PCE updates, orders, WH Notification Purposes, and mental \nhealth tests. The updates won't occur on the CPRS GUI until the user clicks \non the FINISH button. Dialog elements may have components added to them. \nAuto-generated components will be based on the additional prompts defined in \nthe Finding Type Parameters. Once a dialog element is auto-generated, the \nsites can modify them. \n \nDialog elements may also be instructional text or a header. The FINDING ITEM \nand components would not be defined in dialog elements. \n \n \nA dialog group is similar to menu options. It groups dialog elements and \ndialog groups within its component multiple. The dialog group can be defined \nwith a finding item and a check-box. The components in the group can be \nhidden from the CPRS GUI window until the dialog group is checked off. \n \nA result element contains special logic that uses information entered during \nthe resolution process to create a sentence to add to the progress note. The \nspecial logic contains a CONDITION that, when true, will use the ALTERNATE \nPROGRESS NOTE TEXT field to update the progress note. A separate result \nelement is used for each separate sentence needed. The result element is \nThis file contains a combination of nationally distributed entries, local \nonly used with mental health test finding items. Default result elements are \ndistributed for common mental health tests, prefixed with PXRM and the \nmental health test name. Sites may copy them and modify their local versions \nas needed. \n \nA result group contains all of the result elements that need to be checked \nto create sentences for one mental health test finding. The dialog element \nfor the test will have its RESULT GROUP/ELEMENT field defined with the \nresult group. Default result groups for mental health tests are distributed \nwith the Clinical Reminders package. Sites may copy them and modify their local \nauto-generated entries, site and VISN exchanged entries and local manually \nversions as needed. \n\nSites should name locally created items according to their local naming \nconvention.\ncreated entries. Nationally distributed dialog, element, and group \nentries have their name prefixed with VA-. Nationally distributed Prompts, \nForced Value, Result Groups, and Result Elements have their name prefixed \n\n
\nThis file summarizes GUI functionality that has been created for\nparticular dialog processing on the GUI side. The GUI functionality can\nbe associated with an entry in the Reminder Dialog file.\n\n
\nThis file is used to predefine a preferred dialog element or dialog group\nThis file is for local use only. It does not contain any nationally\ndistributed entries. Local entries in this file are not exchanged with\nother sites via the reminder exchange tool. \nto represent a reminder finding item. Auto generation of a reminder\ndialog from the reminder definition uses the dialog in this file in\npreference to using the Finding Type Parameter's prefix and suffix\nto create a sentence.\n \nThe finding items are restricted to finding types that can be used to\nresolve the reminder from the CPRS GUI.\n \n\n
\nThis file is used by the process that generates reminder dialogs for a\nFactors to represent refusals).\n \nThe entries distributed in this file may not be deleted and new entries\nmay not be added locally. \nreminder. During this process, for each reminder finding item in a\nreminder definition, one or more dialog elements are created, depending on\nthe Finding Type parameters in this file. The file content is distributed\nwith the package, but may be edited by sites to reflect how the site uses\nPCE data. The site can alter the pre-defined prefix and suffix text used\nto create sentences. The site can also disable creation of sentences for\nspecific types of resolution statuses (e.g., disable creation of education\nrefused for an education topic because the site prefers to use Health\n\n
\nThis file is used by Reminder Dialogs and CPRS to allow updating \npackages normally not handled by CPRS. This file is to be controlled by \nnational development and should not be modified at the site.\n\n
\nThis file defines functions that are used by Reminder Dialogs. The \nfunctions can be processed loading a dialog for use by CPRS or as the \nuser process a Reminder Dialogs in CPRS.\n\n
\nThis file can only be used in National Dialog and sites should not be \nable to modify this file. This file is used by CPRS to determine if a GUI \naction should occur when the user takes an action on an existing dialog \nitem.\n\n
\nThis file contains a small amount of static data. Entries are entered and \nremoved as Reminder Geriatric Extended Care Dialogs are processed by the\nCPRS GUI. Its main purpose is to keep track of and supply an Encounter\nDate/Time to the GUI interface so that the date/time can be added later to\nfields in the V HEALTH FACTOR file.\n\n
\nThis file contains a permanent history of activity that occurred during the \nuse of the Reminder Geriatric Extended Care Dialogs. Information is added \nwhen a GEC Dialog is used and information is added about the patient.\n\n\n
\nThis file defines the resolution statuses that may be related to a\nMost of the findings from files can be automatically analyzed and\nassociated with a resolution status. For example, Education topics\nentered for a current visit are "DONE AT ENCOUNTER", Education topics\nentered for a historical visit are "DONE ELSEWHERE", Education topics with\na Level of Understanding of Refused are "PATIENT REFUSED" resolutions. The\nhealth factor is a file of findings that we cannot categorize without the\nsites telling us what the related resolution status should be.\n \nThe statuses will be used in the future for roll-up counts to reflect how\nreminders were resolved (done, historical, refused, contraindicated,\nfinding. National resolution statuses are distributed in this file, but\nordered).\nsites may create local resolution statuses. If local resolutions are\ndefined, they must be mapped to a national resolution status. The\nnational resolution statuses are used by the process that creates dialog\nsentences for finding items. \n \nThe distributed national resolution statuses may not be deleted. \n \n\n
\nThis file defines the resolution statuses that should be related to a\nparticular health factor. The resolution status can be derived for most\npatient findings (visit file helps determine done and historical). In\norder to know the appropriate resolution statuses for a health factor,\nthey must be defined in this file.\n \nThis file is for local use. No health factor resolution statuses are\ndistributed in this file. \n\n
\nThis file contains a list of the coding systems used in the National\nLibrary of Medicine (NLM) Value Set Authority Center (VSAC) value sets.\n\nThis is a reference file and its contents are created with data imported\nfrom a VSAC SVS (sharing value sets) file. None of the contents should\never be changed by users.\n\n\n
\nThis file contains the National Library of Medicine (NLM) value sets.\nThe source of the value sets is the NLM Value Set Authority Center\n(VSAC) web site.\n\nThis is a reference file and its contents are created with data imported\nfrom a VSAC SVS (sharing value sets) file. None of the contents should\never be changed by users.\n\n\n
\nValue Sets, which are stored in file #802.2, were designed for use by\nThis is a reference file and its contents are created with data imported\nfrom a VSAC SVS (sharing value sets) file. None of the contents should\never be changed by users.\n\nClinical Quality Measures. A value set may be used in one or more\nclinical quality measures. To provide context for the value sets, this\nfile stores information about the clinical quality measures and how they\nrelate to the value sets. File #802.2 references this file so that all\nthe clinical quality measures which use a value set can be determined.\nConversely, each clinical quality measure stored in this file contains a\nlist of all the value sets it uses.\n\n\n
\nFunction findings operate on data from standard findings and return\ncomputed data. They can be used in patient cohort logic and resolution\nlogic. This file defines the functions that can be used in function\nfindings.\n\n\n\n
\nThis file tracks patient specific information related to an episode name.\n \n.\n\n
\nThis file contains the Current Procedural Terminology (CPT) codes\n \nPer VHA Directive 10-93-142, this file definition should not be modified.\npublished by the American Medical Association (AMA) and the HCPCS codes,\npublished by the Health Care Financing Administration (HCFA).\nThe entries in this file are "descriptive terms and identifying codes for\nreporting services and procedures performed by physicians."\n \nIf an entry needs to be added, modified or deleted a patch will be issued\ninstructing the site how to make the change. Otherwise, this table file\nshould not be edited in anyway by the site.\n\n
\nThis file is used by the reminder reports options only. For each type of\nto be evaluated for each selected patient.\n \nThe field names in the template file correspond to the local variable and\narray names used in the print routines.\nreport (e.g. Reminders Due), selection parameters used in a report may be\nsaved as a template when the report is being run. When running reports,\nthe user may opt to retrieve parameters from an existing template as the\nbasis of a new report. Templates may be modified, renamed, copied, or\ndeleted from the reminder report options.\n \nThe parameters for the reminder reports consist of a patient sample (e.g.\nPCMM team) from which a patient list is built and also a list of reminders\n\n
\nNational extract definitions were sent out with Clinical Reminders V.2.0 to\n - summarize finding total counts that reflect site activities during the\n EPRP performance measures often require a current qualifying visit and\n an anchor visit during the previous year. Since some patients seen\n during a reporting month do not have a prior year anchor visit, the\n national extract's total patient counts for a given month will\n typically be less than the Reminder Due report's total patient counts\n for the same month.\n \n The lists of patients used for each reporting period's national\n extract are stored on the local system for sites to validate the\n patient denominator counts and provide local quality of care\n reporting month. \n monitoring.\n \n Compliance total counts are accumulated based on the reminder status\n for each patient: total, applicable, not applicable, due, and not\n due. The extract criteria used to create the totals is stored with \n the total counts on the local system, as well as transmitted to the\n AAC.\n \n Finding total counts are accumulated for pre-defined national finding groups\n based on the findings found during reminder evaluation for the patient. The\n - list unique applicable patients included in the finding count (Patient\n finding counts are totaled into categories that reflect the reminder status\n for each patient: total, applicable, not applicable, due and not due patient\n counts. The finding counts are sent to the AAC with the extract criteria \n used to create the counts.\n \n Utilization counts are accumulated for pre-defined national finding groups\n that count how many times specified findings were entered during the \n reporting period for patients for each patient denominator. The finding \n counts are sent to the AAC with the extract criteria used to create the \n counts.\n List is not sent to Austin)\n \n Each patient that had a finding count is stored on the local system for\n follow-up patient care and validation of reporting results. The patients are\n not sent to the AAC.\n \n The national extract tools use Mailman links with the HL7 interface to send\n compliance totals and finding totals for each monthly period to the AAC. AAC\n adds the national monthly reporting to the Compliance Totals National \n Database stored at the AAC.\n \n \n The national extract reports are generated by a job. IRM Staff can help set\n up each type of extract definition to automatically reschedule itself to run\n monthly at each site. The extract run needs to occur prior to the tenth of\n each month. \n \n The sites can manually rerun an extract and/or selectively retransmit an\n extract to AAC in the event of a failed transmission. The Extract Summary\n reports may be used to verify compliance totals. \n \n Parties interested in viewing the AAC Compliance Totals National Database\nAn extract definition may be manually run or set-up to automatically run\n may be granted read-only access to this data. The AAC uses the\n national database to create Simple Authentication and Security (SAS)\n files with read-only access.\n \nFile relationships:\n \n The extract definition uses list rules (#810.4) to build lists of patients.\n If the extract definition is for Compliance and Finding Totals, the extract\n definition will be defined with counting rules (#810.7). The counting rules\n will be defined based on counting groups (#810.8). \nmonthly or quarterly. The extract can be defined to only produce compliance\n \n Data from the extract is stored in the extract summary file (#810.3) and \n patient lists are saved in the patient list file (#810.5). HL7 messages \n containing the extract data from the extract summary (#810.3) are passed\n to the HL7 package for transmission to the AAC. Individual patient\n level data is not sent to Austin. However, a list of patients with\n particular findings may be stored in the extract summary file (#810.3)\n for validation of patients.\n \nNationally distributed definitions are prefixed 'VA-' and cannot be modified \ntotals, or to also include finding totals.\nby site. \n \nSites should name locally created extract definitions according to their local \nnaming convention. \n \nEach extract definition identifies:\nsupport site roll-up of reporting totals to the Austin Automation Center\n - Which type of totals the extract will create: compliance, finding \n - What patient list(s) should be created first, second, third, , and\n what criteria should be used to build the patient list(s).\n - For each patient list created when the extract is run, what reminders\n should be run.\n - For each reminder run, what findings found should be used to include\n in finding count totals, based on the reminder status for each\n patient, and pre-defined counting groups.\n - Counting groups are used to define findings that may have been found\n from reminder evaluation, as well as findings that may not be in the\n(AAC). The generic extract functionality supports corporate level management\n reminder but need to be counted for utilization counts.\n - Counts are accumulated depending on whether the reminder status was\n applicable, not applicable, due or not due for the patient.\n - Utilization counts count how many times the findings in a counting\n group were entered during the reporting period for the patients in\n the patient list.\n \nThe extract definition also identifies the last extract reporting period run\nand the next reporting period to be run. This information is used to support\nmanaging extract runs. The next reporting period is used by the next\nanalysis by providing reports that:\nautomated run to know which period should be run. \n \nThe reporting results are stored in the REMINDER EXTRACT SUMMARY file (#811.3)\n \nThe national extract definitions are defined in this file to support generic\nextract and roll-up needs by facility. The generic extract tools provide\noptions to:\n - manage extract criteria \n - manage extract runs (manual and automated)\n - manage transmissions to AAC\n \n - view extract reporting results\n - view the list of patients making up the patient denominator\n \nWhen analyzing the results of an extract run, it is important to take note of\nthe following information before drawing conclusions:\n - list rule criteria used to create the target patient lists\n (denominators)\n - reminder definition used to create applicable, not applicable, due and\n not due compliance and finding totals\n - counting rules used to accumulate totals \n - summarize patient reminder compliance totals (not applicable,\n - counting groups of findings and the type of totals accumulated (all\n patients, applicable, due or not due patients)\n \nThe following is a comparison of Reminder Due and Reminder Extract report\nfunctionality: \n \n Reminder Due reports:\n \n Use report criteria and pre-defined report templates with location/clinic\n stop, provider, and team lists to build the list of patients that will be \n applicable, due, not due)\n used to evaluate reminders.\n \n National Reminder Due report criteria and pre-defined report templates are \n not nationally distributed.\n \n The Reminder Due report evaluates reminders and provides counts for Total\n patients, applicable patients and patients due.\n \n The patient with a Due status can be saved in a Reminder Patient List for\n further follow-up Patient Demographic and Health Summary reporting.\n - summarize finding total counts that reflect the most recent findings\n \n The findings in the reminder are not used to accumulate counts.\n \n An existing Reminder Patient List can be used to identify target patients,\n instead of report criteria and report templates.\n \n The Reminder Due report can be created in a Summary or detailed report\n format, and is typically queued to run in a job during off-hours.\n \n National extract reports:\n resulting from reminder evaluation\n \n Defines complex extract criteria into one extract definition that is\n pre-defined as a national Reminder Extract Definition.\n \n Pre-defined national extract criteria uses findings (reminder terms),\n independent of a reminder definition, to build one or more lists of\n patients that are used to evaluate one or more reminders.\n \n National extract criteria used to identify patients is similar to VA\n External Peer Review (EPRP) performance measure reporting criteria. \n\n
\nThis file stores compliance totals found for a specific extract. The extract \nThe REMINDER EXTRACT SUMMARY NAME is the combination of a unique abbreviation.\nRUN is run for the month with the error to transmit the entire month's data\nagain. The new data for each patient and finding date replaces the old\npatient and finding date's data. 5) Two new options are available on the\nREMINDER REPORTS menu that provide total counts by finding item, as well as a\ndetailed list by finding item and SSN. 6) Sites are encouraged to provide\nFileMan read-only access to the REMINDER EXTRACT SUMMARY file (810.3) for those\nwho validate the extract data, the Hepatitis C implementation team, and\nHepatitis C Coordinators responsible for monitoring Hepatitis C activities at\neach site. \n\nWhen the extract is created from the EXTRACT manual and automated options, the\nREMINDER EXTRACT SUMMARY NAME will include Q, M, or Y (for quarterly, monthly,\nor yearly), nn for month or quarter, and yyyy for year. The following is an\nexample of extract names:\n VA-IHD QUERI 2006 M2 \n VA-IHD QUERI 2006 M1 \n VA-IHD QUERI 2005 M12 \n\nNational extract summary entries created from generic Reminder Extract\nEntries are read only and may be selected by number or extract name. \nfunctionality (not LREPI) are stored with a VA- prefixed name. Each extract\nentry contains reminder compliance totals for each unique combination of\npatient list and reminder. The extract will optionally store finding\ncompliance totals if the TYPE OF TOTALS for the extract is "Compliance and\nFinding Totals". No patient specific data is stored in the extract summary\nfile for generic extracts. The patient lists (denominators) used to create\nthe extract summary totals, for a particular reporting period, are available\nfrom Reminder Patient List options. \n\nGeneric extract summary entries will default to be purged after 5 years. The\nThe extract Summary entries are currently created from two types of\nautomated purge status can be changed for a particular extract summary entry\nto retain the entry indefinitely. \n\nLREPI extract summary entries:\n\nThe LREPI extract names use YY/MM representing the ending year and\nmonth of the extract date range, and the run date in the format YYMMDD. The\ndate and time of the run is an identifier. The following is an example of\nLREPI extract names.\n LREPI 00/05 061500 \nprocessing:\n LREPI 00/06 073100 \n LREPI 00/07 081500 \n\nThe LREPI extract entries assume all results are for the primary institution,\nand includes patient specific data with findings. The LREPI extracts created\nare based on LREPI reporting criteria which is not available for generic\nreporting functionality. This file will maintain up to 36 extract entries\nfor each type of extract. After 36 entries, when a new entry is added, the\noldest entry is deleted from the file. Sites are asked to run the LREPI\nENHANCE MANUAL RUN for months starting from 10/01/98 through 8/31/00. This will\n1) Generic EXTRACT tool manual runs and automated runs\nseed the Emerging Pathogens Initiative (EPI) database with risk assessment\ndata. Subsequent updates to the EPI database will automatically occur monthly\nvia the LREPI NIGHTLY TASK option. Sites will have up to 36 months of extracts.\nThis may be fewer than 36 months if the site runs extracts for the same month\nmore than once. Multiple extracts for the same month occur when the site runs\nthe LREPI ENHANCE MANUAL RUN for a month to fix errors found by the receiving\nnational database. For LREPI runs, the receiving national database is the\nEmerging Pathogens Initiative (EPI) at the Austin Automation Center (AAC). \n \nAn LREPI entry in the REMINDER EXTRACT SUMMARY file contains information that \n2) LREPI ENHANCE MANUAL RUN and LREPI NIGHTLY TASK on day 15 of each month\nidentifies the extract entry, the extract findings, and totals by finding item. \nThe extract entry information includes the number, extract name, beginning and\nending extract dates, person who ran the extract option, task number, total\npatients evaluated and total patients with findings. The extract findings\ninclude a number (for ease of selecting a finding item), patient, reminder\nterm, value, alternate id, finding date, related visit (if PCE data), encounter\ntype (I/O), result, value, drug and DSUP (days supply). These extract finding\nfields are returned by the reminder evaluation logic. The result, value, and\ndrug are all free text fields without specific input and output transforms\nbecause the data comes from the source VistA data it came from, with read only\n\naccess on this file. The alternate id is specific to the LREPI extracts. A\nnumber value in the alternate id field indicates that the finding is for\nHepatitis C risk assessment. The alternate id will be used for statistical\npurposes in the EPI database. \n \nThe flow of LREPI processing is as follows: 1) LREPI gathers Lab Search/Extract\npatients and findings 2) LREPI gets all patients and findings from a reminder\nextract evaluation process given the extract date range and reminder list. \n(The reminder list is from a new LREPI file 69.51). 2.1) The reminder extract\nevaluation logic uses medications mapped to reminder terms in the VA-NATIONAL\nGeneric extract summary entries:\nEPI RX EXTRACT reminder, and the extract date range, to call new inpatient\npharmacy and outpatient pharmacy extract logic to get patient pharmacy\nfindings. 2.2) The reminder extract evaluation uses the remaining reminder\ncriteria to build a list of patients with findings from the following files in\nthe extract period: \n LAB DATA (#63) \n V POV (#9000010.07) \n V HEALTH FACTORS (#9000010.23) \n V PATIENT ED (#9000010.16) \n V EXAM (#9000010.13) \n\n2.3) The list of patients is used to evaluate the VA-HEP C RISK ASSESSMENT and\nVA-NATIONAL EPI LAB EXTRACT reminders. The findings within the extract date\nrange are added as Extract Findings in the REMINDER EXTRACT SUMMARY file and\nthen returned to the Lab Search/Extract process. 3) The Lab Search/Extract\nprocess uses the final list of patients and findings to create HL7 messages. \nEach reminder finding for a patient is used to create a DSP segment. Pharmacy\nfindings contain both a DSP and ZXE segment. 4) When the AAC processes the\nmessages, error messages are returned for each message with the SSN related to\nthe erroneous data. Note: Messages with errors are not added to the EPI\ndatabase. When erroneous data is fixed at the site, the LREPI ENHANCE MANUAL\n\n
\nThis file is used to define what extract criteria should be used to build\n and the date ranges to use\n Reminder Rule - defines a reminder definition that builds a patient list\n based on the patient cohort logic using the ending date as\n the evaluation date. \n Rule Set - defines a multiple of sequentially defined list rules \n (a rule set can not be included in the multiple). \n\nThe rule criteria are combined into a Rule Set that defines how to use the\ncriteria to create or modify a patient list. Rule Sets allow lists of patients\nto be manipulated when a patient meets specified criteria by the following\nreminder patient lists. Extract criteria is defined as "list rules" in this\noperations: \n \n ADD to a new or existing patient list \n REMOVE from an existing list \n SELECT retain a patient in an existing list if the patient meets the \n criteria, and remove the patient if the patient does not meet \n the criteria. \n \nA rule set can contain multiple operations. One operation can be defined for\neach sequence in the rule set. \nfile. The file is used by the Reminder Patient List option and Reminder\n \nNationally distributed list rules are prefixed with 'VA-' and cannot be\nmodified by sites. \n\nFINDING RULES and Date Ranges:\n------------------------------------------------------------\nA Date Range is used by FINDING RULES to search for findings.\nList build processing determines which Beginning Date/time and Ending Date/time\nto use when evaluating each finding based on where the date/times are defined.\nBeginning Date/Time (BDT) and Ending Date/Time (EDT) fields can be defined at\nExtract Management option to create patient lists. \nmultiple levels:\n\n1 List Build action BDT and EDT: default when not defined at lower level\n 2 Rule Set Sequence BDT and EDT: overrides previous level\n 3 List Rule BDT and EDT: overrides previous levels\n 4 Term Finding BDT and EDT: overrides previous levels\n\nThis override relationship can be defined with the following equation, where\n"<" should be interpreted as "is overridden by":\n\n \nList Build < rule set sequence < list rule < term's finding\n\nList Build and date range evaluation:\n------------------------------------\n\nThe List Build BDT and EDT are specified by the user selecting the List Build\naction. The List Build BDT and EDT is the default date range when the BDT and\nEDT are not defined for the rule set sequence, list rule, or term finding. The\ndefault date range is used to find a match on each finding in the criteria. \n\nThere are four types of rule criteria in the List Rule file: \nIf no date range limits should be used to find a match on finding, either the\nrule set sequence or list rule needs to be defined with a zero in the BDT or\nEDT fields, or both. A zero in the BDT field means start with the patient's\noldest data. A zero in the EDT field represents the end of the day on the day\nthe list is built. Note: This is in contrast to Reminder Definitions, where the\nBDT and EDT for a finding are left blank to specify no limits. In the REMINDER\nLIST RULE file, if zero is defined in the BDT, and the EDT is left blank, the\nlist build tools will assume both BDT and EDT should not have date range\nlimits, and vice versa if EDT has the 0 and the BDT is blank. \n\n \nThe use of "T" in the BDT or EDT fields always represents the List Build ending\ndate/time specified for the list build action or the extract reporting period,\ndepending on whether a reminder patient list or extract option is being used to\nbuild the list.\n\n"BDT" may also be used in the BDT or EDT fields and represents the starting\ndate/time specified for the list build process or the extract reporting period.\nBDT-5Y creates a date five years prior to the beginning date/time. \n\nIf the ending date/time is earlier than the beginning date/time, then no\n Patient List - defines an existing patient list \nfinding matches will be found.\n\nREMINDER RULES and Date Ranges:\n------------------------------------------------------------\nReminder Rules do not use the Beginning Date/time from the List Build, List\nRule Sequence or Reminder Rule Beginning Date/time fields. Reminder evaluation\nusing date ranges is based on existing reminder definitions. However, a\nReminder Rule will use the Ending Date/time (EDT) from the Reminder Rule, List\nRule Sequence, or List Build EDT. The same EDT overrides that are used for\nFinding Rule EDT are also used for Reminder Rule. The EDT used for reminder\n Finding Rule - defines reminder terms that specify findings \nevaluation can be defined at multiple levels:\n1 List Build action EDT: default when not defined at lower level\n 2 Rule Set Sequence EDT: overrides previous level\n 3 List Rule EDT: overrides previous levels\n 4 Reminder evaluation is not impacted by terms in the reminder\n definition.\n\n\n
\nPatient lists in this file are created from the Reminder Due reporting option,\nSites should name locally created patient lists according to their local naming \nconventions. \n\n\nReminder Patient List option or from Reminder Extract runs. Reminder patient\nlists are retained for 5 years in this file before being purged. Individual\npatient lists can have the automatic purge turned off.\n \n\nPatient lists that are created from national extract runs are prefixed with\n"VA-". \n \n\n
\nThis file is used during extract processing when an extract definition's TYPE\n Patient List to build and list rules to build them\n Reminders to be run with the Patient List\n Extract Counting Rules that define how to count findings \n\nAn entry in the REMINDER EXTRACT COUNTING RULE file identifies how groups of\nfindings should be accumulated based on the reminder status.\nEach group of findings is defined as a counting group in the REMINDER EXTRACT\nCOUNTING GROUP file (#810.8).\n\nOne counting group can be referenced multiple times in a particular counting\nOF TOTALS field is defined with COMPLIANCE AND FINDING TOTALS. When the\nrule to collect counts in multiple ways. The unique combination of a counting\ngroup and a Reminder Status field is what makes the counts different. The\nReminder Status field is the status associated with the patient when the\nreminder was evaluated. Each patient is always in the TOTAL PATIENTS count,\nbut the patient is included in the APPLICABLE PATIENTS, DUE PATIENTS, or NOT\nDUE PATIENTS counts depending on the reminder status for each patient. \n\nFor example: A counting group defined with possible LDL value ranges, can be\ndefined to get multiple counts, depending on the patient's REMINDER STATUS.\nWhen TOTAL PATIENTS Reminder Status is defined with the counting group: Every\nextract type is for COMPLIANCE TOTALS only, there will not be an extract\npatient in the patient list is used to find a match on the findings in the\ngroup. If a finding match is found, a count is accumulated into columns based\non the reminder status of APPLICABLE, NOT APPLICABLE, DUE or NOT DUE. \n\nWhen APPLICABLE PATIENTS Reminder Status is defined with the counting group:\nPatients from the patient list, where the reminder was applicable, are used to\nfind a match on the findings in the group. If a finding match is found, a count\nis accumulated into columns for each finding in the group based on the reminder\nstatus of APPLICABLE, NOT APPLICABLE, DUE or NOT DUE. Applicable patients\nshould have 0 counts in the NOT APPLICABLE count for each finding.\ncounting rule defined in the REMINDER EXTRACT DEFINITION file (#810.2). When\n \nWhen DUE PATIENTS Reminder Status is defined with the counting group: Patients\nfrom the patient list, where the reminder was due are used to find a match on\nthe findings in the group. If a finding match is found, a count is accumulated\ninto columns for each finding in the group based on the reminder status of\nAPPLICABLE, NOT APPLICABLE, DUE or NOT DUE. Due patients should have 0 counts\nin the NOT APPLICABLE and NOT DUE count for each finding.\n\nWhen NOT DUE PATIENTS Reminder Status is defined with the counting group:\nPatients from the patient list, where the reminder was not due are used to find\nthe extract type includes FINDING TOTALS, then the extract definition needs to\na match on the findings in the group. If a finding match is found, a count is\naccumulated into columns for each finding in the group based on the reminder\nstatus of APPLICABLE, NOT APPLICABLE, DUE or NOT DUE. Due patients should have\n0 counts in the NOT APPLICABLE and DUE count for each finding.\n\nThe accumulated counts for each finding are stored in the REMINDER EXTRACT\nSUMMARY file (#810.3). The sequence number in the file determines the order\nthe counts will be accumulated for, saved to, and displayed from the REMINDER\nEXTRACT SUMMARY file (#810.3). \nThe counts can be used to make comparisons between TOTAL PATIENTS, APPLICABLE\nreference a counting rule for each reminder processed by the extract. \nPATIENTS, DUE PATIENTS, and NOT DUE PATIENTS counts. \n \nIf no counting groups are defined in the extract counting rule, then no finding\ntotals will be accumulated. \nNationally distributed extract counting rules are prefixed 'VA-' and cannot be\nmodified by sites. \n\nSites should name locally created extract counting rules according to their \nlocal naming convention. \n\n\n\nIn the Extract definition, there is a basic hierarchy as follows\nExtract general information\n\n
\nCounting groups are used for extract processing when the extract type is\n \nNationally distributed counting groups are prefixed 'VA-' and cannot be\nmodified by\nsites. \n \nSites should name locally created counting groups according to their local \nnaming convention. \n\nCOMPLIANCE AND FINDING TOTALS. Each counting group \ndefines reminder terms and type of counts to be totaled during an extract run. \n\nCounting groups are referenced and combined into one Extract Counting Rule in\nthe REMINDER EXTRACT COUNTING RULE file (#810.7). \n \nThe sequence number determines the order in which finding totals are saved to\nand displayed from the REMINDER EXTRACT SUMMARY (#810.3) file. \n\n
\nThis file is used to group a list of locations and give the group a\nname. The locations can be Hospital Locations and/or Clinic Stops\n(which resolve to a list of Hospital Locations).\n\nA Location List finding in Clinical Reminders is based on an entry from\nthis file. A Location List finding will be true when a patient has an\nentry in the Visit file for at least one of the locations in the\nLocation List.\n\n
\nThis file is used to map entries from two different file to each other.\nIt functions as a table.\n \nNOTE: As of patch PX*1.0*215, this file has been superseded. The mappings \nof immunizations and skin tests to CPT codes are now contained in the\nCODING SYSTEM multiple of the IMMUNIZATION (#9999999.14) and SKIN TEST\n(#9999999.28) files themselves.\n\n
\nThis file stores the Clinical Reminders taxonomies. Taxonomies are\nthat meet this criteria are listed for selection in the taxonomy\neditor.\n\nThis file contains a combination of nationally distributed and local\nentries. Nationally distributed entries have their names prefixed with\nVA- and their Class is National. Local entry names cannot start with\nVA- or have a National Class.\n\nused as Clinical Reminders findings and provide a way to define a\nset of codes as a single finding. Taxonomies are structured so that\nany of the coding systems defined in Lexicon's Coding System (file\n#757.03) can be used. However, in order for a coding system to be\nused in Clinical Reminders, there must be a source in VistA where\nthe coded patient data is stored. Examples are V POV (file\n#9000010.07) which stores ICD diagnosis codes and PTF (file #45)\nwhich stores ICD diagnosis and procedure codes. The coding systems\n\n
\nWhen none of the standard Clinical Reminder finding types will work, a\nfinding as finding to a reminder definition or term, it is done using\nthe name. For example, you would type CF.VA-BMI to add the exported\nVA-BMI computed finding to your reminder definition.\n \nROUTINE - this is the name of the MUMPS routine.\n \nENTRY - this is the entry point in the MUMPS routine.\n \nPRINT NAME - this will be displayed on the Clinical Maintenance\ncomponent as the name of the computed finding. If it is blank, then NAME\ncomputed finding can be created. There are two steps in creating a\nwill be used.\n\nTYPE - this is a set of codes that specifies what type of computed\nfinding this is. "S" stands for single occurrence, "M" for multiple occurrence,\nand "L" for list. If it is blank, single will be assumed.\n\nThis file contains a combination of nationally distributed and local\nentries. Nationally distributed entries have their name prefixed with\nVA-. Local entry names cannot start with VA-.\ncomputed finding. First a MUMPS routine must be written. Information\nabout how to do this can be found in the Clinical Reminders Manager\nManual. The second step is to make an entry in this file, which\ncontains a list of reminder computed findings. There are four fields\nfor each entry; they are:\n \nNAME - this is the name of the computed finding. When adding a computed\n\n
\nThis file defines Clinical Reminder terms. Terms have a number of uses,\n\nBefore a term can be used, it must have findings mapped to it. The\nfindings that can be mapped to a term are any of the standard\nClinical Reminder findings with the exception of terms.\n\nReminder terms are useful for national reminders involving findings\nthat are based on local file definitions (e.g., laboratory test, drug\nfile, radiology). National reminder terms have limited editing\ncapabilities, which allow sites to map their local finding items to a\nterm. Sites may create local reminder terms, providing an easy way to\nincluding as findings in a reminder definition, as finding rules for\ngroup a variety of findings and treat them the same way in a reminder.\n \nWhen a reminder with terms is evaluated, the finding items mapped to\nthe term are used to find the patient data, but the patient data is\nreported based on the term the data is mapped to.\nbuilding patient lists, and as elements of extract finding groups.\n \nThis file contains a combination of national, local, and VISN level\nterms. Nationally distributed entries will have a CLASS of "National"\nand the name is prefixed with "VA-". Any terms created at your site\nshould have a CLASS of "Local". Terms created for VISN use will have a\nCLASS of "VISN"\n\n
\nThis file contains the names of organizations, groups, or individuals \nthat are sponsors of reminder components such as definitions, terms,\nand dialogs.\n\nEntries cannot be edited using FileMan; you must use the Reminder\nSponsor Edit option.\n\n
\nThis file contains Reminder Categories. Reminder Categories are\nReminder Categories can also be used in conjunction with Reminder\nDue Summary Reports. The user is given the option to select a\nReminder Category or input a list of individual reminders.\ncreated at each site and are not released with the reminder package.\n \nA Reminder Category is a list of reminders (or other reminder\ncategories) and is used to group reminders for display in the CPRS\nGUI. Reminder categories are allocated to individual users,\nlocations, service or system using the option PXRM CPRS LOOKUP\nCATEGORIES.\n\n\n
\nThe Reminder Exchange File is used to store packed reminder\ndefinitions. All the entries in this file are managed by the\nReminder Exchange Utility and should never be edited by hand.\n\n
\nThis file contains Clinical Reminder definitions. For a detailed\ndescription of the contents of this file, see the Clinical Reminders\nManager Manual. Additional information may be found at the Clinical\nReminders web site: http//vista.domain.ext/reminders\n\nThis file contains a combination of nationally distributed and local\nentries. Any local entries are assigned an internal entry number\nprefixed with your site number. Nationally distributed entries have\ntheir name prefixed with VA-. Local entry names cannot start with VA-.\n\n
\nThis File is used to create additional fields that can be added to the \n'Customized' User Visit Review Report. This option is found under the PCE \nIRM menu and under the PCE Debugging Utilities.\n\n
\nThis file has one entry (1) that contains parameters used by Patient Care\nEncounter (PCE). The "LM" node is used by the User Interface (PXCE).\n\n\n
\nThis file tracks a patient's Acute Suicidal Crisis episodes. It contains\nlocks for the inpatient, outpatient, and extension periods, as needed.\nThis file also points to PTF and VISIT records that were marked as \nrelated to an Acute Suicidal Crisis, which are covered benefits, under the\nCOMPACT Act.\n\n
\nThis file contains data which is used in DRG Grouper calculations. These \ndata specify combinations of procedure codes that, when found to occur \ntogether in one patient case, will lead to a specific DRG code. The DRG \nGrouper routines will check the contents of the "One Of" field and each \n"With One Of" field to make this determination.\n\n
\nThis file contains data which is used in DRG Grouper calculations. These \ndata specify combinations of diagnosis codes that, when found to occur\ntogether in one patient case, will lead to a specific DRG code. The DRG\nGrouper routines will check the contents of the "One Of" field and each\n"With One Of" field to make this determination.\n\n
\nThis file contains data that was extracted from Appendix C of the \nMedicare/Medicaid web site www.cms.gov. The data consists of lists of \nDiagnosis Codes. Each list is stored within an Exclusion Code that \nprovides access to the list from File #80, field 1.11.\n\n
\nFile contains all MDC Categories for Diagnostic Related Groups (DRG). The \nCategories are sub-groups within an MDC of related DRGs. \nThis includes all categories, Medical and Surgical.\n \nThis file should not be modified locally. \n\n
\nFile contains all Diagnostic Related Groups (DRG) with their related \ncriteria required for DRG calculations. There may be multiple entries \nfor a single DRG based on the MCC/CC definition and the various codes \nassigned. \n \nThis file should not be modified locally. \n\n
\nFile contains the hierarchical order of precedence for Diagnostic Related \nGroups (DRG) by version. Multiple DRGs may be calculated based on a set \nof Diagnosis and Procedure Codes, the order in this file will determine \nthe basic precedence for the final selection. Each version where the \norder is modified will have a new record by date with all active DRGs \nassigned in order.\n \nThis file should not be modified locally. \n\n
\nFile contains groups of Code Sets that when used in combination satisfy \nthe definition of a Diagnostic Related Group (DRG). Each Case may have \none or more Code Set assigned and be assigned to one or more DRG. \n \nThis file is the link between individual DRGs and all the Code Sets \nrequired for its selection.\n \nThis file should not be modified locally. \n\n
\nFile contains the definition of sets of codes that satisfy at least one \ncoding criteria of a Diagnostic Related Group (DRG). The sets may cover \neither Diagnosis or Procedure codes and have conditions specific to those \ncodes application to the DRG.\n \nThis file should not be modified locally. \n\n
\nAll Diagnosis codes assigned to a Diagnostic Related Group (DRG). File \ncontains sub-sections for the Diagnosis criteria and associations that \naffect the DRG calculation.\n \nThis file should not be modified locally. \n\n
\nPrincipal Diagnosis Exclusion Groups associated with Diagnostic Related \nGroups (DRG). This file contains all Exclusion Groups and their \nassociated Principal Diagnosis. Any Secondary Diagnosis with a matching \nExclusion Group Attribute may not impart it's MCC/CC Attribute to any \nPrincipal Diagnosis in the Exclusion Group.\n \nThis file should not be modified locally. \n\n
\nAll ICD Procedure codes assigned to a Diagnostic Related Group (DRG). \nFile contains sub-sections for the Procedure criteria and associations \nthat affect the DRG calculation.\n \nThis file should not be modified locally. \n\n
\nProcedure Clusters associated with Diagnostic Related Groups (DRG). \nThis file should not be modified locally. \nClusters or Groups of Procedures that in combination affect the DRG \ncalculations. \n \nAll the Procedures in a cluster must be associated with a patient record \nfor the cluster to be applied to the DRG calculation of that record. The \nset of Procedures in a cluster act as a single Procedure when determining \nif a Code Set is satisfied. \n \n\n
\nFile contains the Hospital Acquired Conditions (HACs) Groups defined by \nthe Diagnostic Related Groups (DRG). The Conditions identified by these \ngroups may not be included in the DRG calculation if they were not present \non admission. \n \nThis file should not be modified locally. \n\n
\nFile contains the definition of sets of codes that satisfy at least one \ncoding criteria of a Hospital Acquired Condition (HAC). The sets may \ncover either Diagnosis or Procedure codes.\n \nThis file should not be modified locally. \n\n
\nThis file holds the PXCA variable and the PXKERROR variable when PXK has\nerror(s).\n\n
\nEntries in this file represent the originating sources of data that is\nstored in PCE.\n\n
\nThis file stores all the changes made to Kiosk's configuration parameters \nto facilitate aggregate business intelligence. The current values of\nKiosk's parameters are stored in Vetlink's KIOSK database. The business\nand administrative parameters are used to configure and direct MRAR\nbehavior amongst the Vetlink KIOSK groups or Clinics. Data in this file is\npopulated via RPC call(s) made by the Vetlink client.\n\n
\nThis file stores VPS HL7 Site parameters. This file contains active flag\nto activate or deactivate HL7 transmission. Since VPS HL7 messages are \ntransmitted in a background process, this file also provides last \ntransmission error and date/time stamp to assist application owner with \ntransmission problem. \n\n
\nThis file contains a list of the various indicators that Vecna will send\nto VistA for the accurate capture of discrepancies and non-discrepancies.\nA fundamental objective of MRAR is to identify allergy data omissions and\nmedication adherence discrepancies. The Kiosk (patient facing) and the\nstaff-facing interface allows a veteran, staff, or provider to change an\nallergy status (e.g., allergic to non-allergic).\n\n
\nThis is the Data file for the VA Point of Service (VPS) kiosk application.\nThe data stored in this file is sorted by PATIENT where each patient entry\nhas one or more Medication Review Allergy Review (MRAR) session instances\nand these MRAR instances are sorted by transaction date/time. Each session\nrepresents a complete or incomplete MRAR.\nData is stored using VPS remote procedure calls that are invoked by the\nVetlink Kiosk (patient-facing) or staff-facing client interface. The\nVetlink system is used by the patient or staff resource at the medical\ncenter or clinic. One of the functions of the Vetlink system is for the\npatient/provider review of the patient's medication history and allergy\nhistory. Each review is saved by Vetlink and then sent to VistA for\nstorage using RPC Broker.\n \n\n
\nThis file contains a list of the various indicators that Vetlink will send\nto VistA for the accurate capture of discrepancies and non-discrepancies.\nA fundamental objective of MRAR is to identify allergy data omissions\nand medication adherence discrepancies. The Kiosk (patient facing) and\nthe staff-facing interface allows a veteran, staff, or provider to change\na medication status (e.g. from 'NO, not taking' to 'Yes, taking as \nwritten').\n\n
\nThis is the Clinical Survey Questionnaire data file for VA Point of \nService (VPS) Kiosk application. VetLink (patient-facing or staff-facing) \nuses Remote Procedure Call (RPC) APIs to store Survey Questionnaire\nquestion-patient responses pairs.\n \nThe data stored in this file is sorted by patient and by survey. Each \npatient will have multiple surveys and each survey contains multiple \nquestions and responses.\n\n
\nThis file contains the key identifiers for a VPS Clinical Survey.\nThe Template ID is the unique identifier of the VPS Clinical Survey. This\nfile contains the Template ID, Survey Name and Version.\n\n
\nThis file contains the unique names of the VPS Clinical Survey\nQuestionnaire Name and also name along with version number. CPRS\nHealth Summary utilizes this file to filter the report results.\n\n
\nThis file is a temporary file containing appointments for a given date\nto the Vecna application. The "VPS GET UPDATED APPOINTMENTS" RPC will \nuse this file to filter out the non-modified appointments displayed in \nthe Vecna's VPS Patient Appointment Queue.\nrange in which initialy populated by "VPS GETALL APPOINTMENTS" RPC. \nThis temporary file represents appointment queue displayed in Vecna's VPS \nPatient Appointment Queue application.\n \nThis temporary file will be updated periodically by Vecna's VPS \nPatient Appointment Queue by calling "VPS GET UPDATED APPOINTMENTS" RPC.\n \nThe main purpose of this file is to minimize number of records returned \n\n
\n \n This file temoprarily holds patient data that is used to\n trigger rules.\n \n This file is only edited by the compiled inferencing routine.\n \n\n
\n \n \n This file holds the rules that determine the conditions necessary\n for a notification or some other action to be performed. Rules consist\n of a set of Conditional Elements and a set of Element relationship\n expressions. When an element is found to be TRUE for a patient, it\n is compared to the other TRUE elements for the patient by evaluating\n all the Element relation expressions that contain it. If an\n expression is found to be TRUE then all of the actions defined for\n that relation are performed.\n\n
\n \n This file holds the definitions for the rule elements. A rule element\n consists of a set of boolean expressions. This takes the form of\n Data Field -> Comparison Operator -> 1 or 2 Comparison fields depending\n on the Operator.\n \n\n
\n \n This file holds a list of all data fields known to the order check \n system. It is also the link to the metadictionary, where the Order check\n system goes to get navigation and data type information.\n \n\n
\n \n This file is just for documentation so the rule editor can keep\n data fields manageable.\n \n\n
\n \n This file keeps a list of data contexts. A rule event/element\n can only compare data fields from the same context. A context\n may have involve several data sources. For example the data context\n of 'HL7' has a data source for each hl7 segment.\n \n\n
\n \n This is a short term data archive that holds historical information\n about triggered rules.\n \n\n
\n \n This file is used primarily by developers and IRM staff to\n troubleshoot HL7 and other related problems.\n \n\n
\nMetadictionary classes\n\n
\nMetadictionary control file used by developers\n\n
\nThis file contains the valid Lower Layer Protocols available for use with\nthe HL7 package.\n\n
\nThis file contains the Lower Layer Protocol Parameters used by the HL7\nThere may be redundant information contained on nodes, the goal was to\nallow the applications to grap a one node for all the parameters required.\nThere should be an entry in this file for each Logical Link defined in\nfile (#870). There is an x-ref "ALLP" defined for file (#870) to\nfacilitate navigation from this file.\npackage. Each protocol will use a separate node to hold the parameters\nassociated will the LLP used by the Logical Link. The currently defined\nnodes are:\n \n100 - MailMan\n200 - HLLP\n300 - X3.28\n \n\n
\nParameter file used by the HL7 Communication Server\n\n
\nThis file serves two purposes. It is a fileman-compatible transmission\ncharacters define the beginning and end of a message (LLP START BLOCK\nand LLP END BLOCK).\n \nThis file also stores information that drives the SYSTEMS LINK MONITOR\ndisplay option. Fields like, IN QUEUE FRONT POINTER, IN QUEUE BACK \nPOINTER are used to manage the data flow in the queues but they are\nalso displayed on the SYSTEMS LINK MONITOR under the alias's MESSAGES\nPROCESSED and MESSAGES RECEIVED. Fields like STATE and DEVICE TYPE\nare also used to drive the SYSTEMS LINK MONITOR. These fields are\nupdated by the lower layer protocols in order to give real-time feedback\nlog. The Low Layer Protocols write and read directly from this file.\nas to what is ocurring on a link. For example, when a message is \nreceived (see HLCSDR1) the state transitions from "IDLE" to "READING".\n(See routines HLCSDR1 and HLCSDR2)\n \nThis file stores parameters that govern the behaviour of the Low Layer\nProtocols. Fields like: READ TIMEOUT, ACK TIMEOUT, LLP START BLOCK, and\nLLP END BLOCK, are fields that govern how long the finite state machine\nwaits for data to come down the line (READ TIMEOUT), how long it waits\nfor a lower level acknowledgement (ACK TIMEOUT), and which control\n\n
\nThis file stores textual information for the clinical record database.\nThough it is designed to initially accommodate Progress Notes, Consult \nReports, and Discharge Summaries, it is intended to be sufficiently\nflexible to accommodate textual reports or provider narrative of any\nlength or type, and to potentially accommodate such data transmitted \nfrom remote sites, which may be excluded from the corresponding local \nDHCP Package databases (e.g., Operative Reports, Radiology Reports, \nPathology Reports, etc.) to avoid confusion with local workload.\n\n
\nThis file stores Document Definitions, which identify and define behavior\n \nWarning: objects embedded in boilerplate text are looked up by multiple\nindex (i.e. DIC(0) contains 'M'). Current code (see routine CHECK^TIUFLF3)\nchecks all present indexes to make sure object names, abbreviations and\nprint names are not ambiguous for this lookup. If new indexes are added,\nthis code MUST BE UPDATED to check the new index as well.\n \nSome entries in this file are developed Nationally and exported across the\ncountry. Others are created by local sites. Entries in the first\ncategory are marked National Standard and are not editable by sites.\nfor documents stored in the TIU DOCUMENTS FILE (#8925). For consistency\n \nThis file does NOT allow multiple entries OF THE SAME TYPE with the same\nname. That is, within a given Type, there are no duplicate names. (This\nrefers to the .01 field, the Technical name of the entry.)\n \nThis file does not allow a parent to have items with the same name, even\nif the items have different internal file numbers (i.e. are different file\nentries). Again, this refers to the .01 Technical name of the entry.\n \nBecause of ownership considerations, the file does NOT allow an entry to\nwith the V-file schema, it may be viewed as the "Attribute Dictionary" for\nbe an item under more than 1 parent. If the same item is desired under\nmore than 1 parent, the item must be copied into a new entry. There is\none exception: Document Definitions of Type Component which have been\nmarked Shared may have more than one parent.\n \nThe Document Definition Utility TIUF categorizes certain fields as Basic,\nTechnical, or Upload, and displays these fields together as a group when\nuser edits or views a Document Definition. BASIC fields include Name,\nAbbreviation, Print Name, Type, Personal Owner, Class Owner, Status, In\nUse, Shared, Orphan, Has Boiltxt, National Standard, OK to Distribute, and\nthe Text Integration Utilities.\nSuppress Visit Selection. TECHNICAL fields include Entry Action, Exit\nAction, Edit Template, Print Method, Print Form Header, Print Form Number,\nPrint Group, Allow Custom Form Headers, Visit Linkage Method, Validation\nMethod, and Object Method. UPLOAD fields include Upload Target File, Laygo\nAllowed, Target Text Field Subscript, Upload Look-up Method, Upload\nPost-Filing Code, Upload Filing Error Code, and multiples Upload Captioned\nASCII Header and Upload Delimited ASCII Header.\n \nThe Document Definition file contains extensive, detailed field\ndescriptions. Likewise, some protocols (File 101) used in TIU have\n \nextensive and careful descriptions in the Protocol file. Many of these\ndescriptions are used in TIU for online help. If it becomes necessary for\na national programmer to edit these descriptions, the programmer should\ncheck to make sure all online help is still displayed properly.\n \nUsers are expected to use the Document Definition Utility TIUF to enter,\nedit, and delete file entries. In fact, the file prohibits the deletion\nof entries through generic Fileman Options. It also prohibits the edit\nthrough generic Fileman of a few critical fields: Type, Status, Shared,\nand National Standard. Adding and Deleting (but not editing) Items is\nIt also stores Objects, which can be embedded in a Document Definition's\nalso prohibited through generic Fileman options. Abbreviation and Print\nName of OBJECTS cannot be edited through generic Fileman Options.\n \nThis does NOT imply that it is SAFE to use generic Fileman to edit other\nfields. Users are cautioned that edit through generic Fileman bypasses\nmany safeguards built in to the Document Definition Utility and can create\nhavoc unless the user THOROUGHLY UNDERSTANDS the File and its uses.\n \nIf users find needs which are not met through TIUF, please communicate\nthem to the TIU development team.\nBoilerplate Text (Overprint). Objects contain M code which gets a piece of\n \n *****************\n \nWARNING: Using generic Fileman options to edit entries can cause SERIOUS\ndatabase problems.\n \n ****************\ndata and inserts it in the document's Boilerplate Text when a document is\nentered.\n\n
\nThis file buffers uploaded ASCII reports during the upload process, until\nthey can be successfully routed to their respective destinations within\nDHCP. It will support the development of tools for responding to error\nmessages (e.g., the correction of errors experienced during\nrouting/filing) by the appropriate users, so as to avoid the necessity of\nmaking all edits on the client system and re-initiating the upload in\nresponse to an error condition.\n\n
\nThis file defines allowable error codes, and their corresponding names\nand textual messages for the error handler module of the ASCII upload\nprocess.\n\n
\nThis file is used by the filer module of the upload process to log\nboth successfully filed records and non-fatal errors which may occur\nduring routing/filing of one or more records in a given batch.\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nThis file contains the allowable statuses which may be applied to a TIU \ndocument during its path through the system.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n \n\n
\nThis file is intended to accommodate the case where multiple cosignatures \nare applied to a document (e.g., team or multi-disciplinary notes, discharge \nplanning check-lists, etc.). Rather than adding a multiple to the TIU \nDocument file, this file supports a 3NF decomposition, allowing multiple \ncosignatures to be applied to the same document.\n\n
\nThe TIU TEXT EVENTS file is used to store data to be used in searching \nfor certain text within Progress Notes in order to alert treating \nspecialty areas of monitored concerns when a patient is seen. Setting up \nentries in this file will cause alerts to be sent to providers and \nservices to indicate a possible care opportunity.\n\n
\nThis file stores parameters which modify the processing requirements of\nindividual document types, and their decendents.\n\n
\nThis file allows a many-to-many relationship between TIU Documents and\nProblems to be maintained.\n\n
\nThis file is intended to allow the definition of many-to-one linkages\nbetween TIU Documents and external data objects (i.e., non-MUMPS data)\nsuch as Images or BLOBs.\n\n
\nThis file describes the parameters for controlling the Printing of\nProgress Notes.\n\n
\nThis file descibes the parameters for the batch printing of progress notes\nfor filing by Medical Center Division.\n\n
\nThis file stores parameters which modify the processing requirements of\nindividual document types, and their decendents.\n\n
\nThis file contains information concerning the conversion of legacy \nfiles such as ^GMR(121, Generic Progress Note File, to ^TIU(8925,\nTIU Document File. \n\n
\nThis file is used to store "pick-lists" of documents (by class), for\nselection by the user.\n\n
\nThis file contains the site-configurable parameters for the Text Integration\nUtilities package. It will have one entry for each division, to support\nvariable definition of package behavior at multi-divisional facilities.\n\n
\nThis file allows the definition of Personal Preferences with respect to a\nvariety of TIU's functions (e.g., Review Screen sort field and order,\nDefault cosigner, default locations, location by day-of-week, suppression\nof review notes prompt on Progres note entry, etc.).\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nThis file supports and facilitates the mapping of local titles to LOINC \nStandard Titles, by simplifying the correct association between partial \nnames and the LOINC Standard Subject Matter Domains. Unlike the TIU LOINC \nSUBJECT MATTER DOMAIN File (#8926.2), this file may be locally extended.\n\n
\nThis file supports and facilitates the mapping of local titles to LOINC \nStandard Titles, by simplifying the correct association between partial \nnames and the LOINC Standard Roles. Unlike the TIU LOINC ROLE File\n(#8926.3), this file may be locally extended.\n\n
\nThis file supports and facilitates the mapping of local titles to LOINC \nStandard Titles, by simplifying the correct association between partial \nnames and the LOINC Standard Settings. Unlike the TIU LOINC SETTING File\n(#8926.4), this file may be locally extended.\n\n
\nThis file supports and facilitates the mapping of local titles to LOINC \nStandard Titles, by simplifying the correct association between partial \nnames and the LOINC Standard Services. Unlike the TIU LOINC SERVICE File\n(#8926.5), this file may be locally extended.\n\n
\nThis file supports and facilitates the mapping of local titles to LOINC \nStandard Titles, by simplifying the correct association between partial \nnames and the LOINC Standard Document Types. Unlike the TIU LOINC \nDOCUMENT TYPE File (#8926.6), this file may be locally extended.\n\n
\nThis file stores TIU Templates, which are on-the-fly boilerplates that\nimplementation is provided or feasible. Maintenance of this file\nshould only be performed using the Template Editor, which is contained\nwithin the CPRS GUI. Bypassing the template editor can cause file\nstructure problems.\ncan be added to any note or addendum in the CPRS GUI. All shared and\npersonal templates, as well as template hierarchy, are stored within\nthis file.\n \nDuplicate template names are allowed, usually distinguished by personal\nowner.\n \nThis file is intended for the CPRS GUI only. No server side\n\n
\nThis file contains a list of UNAUTHORIZED \nABBREVIATIONS. The UNAUTHORIZED ABBREVIATION field (.01)\ncannot be modified once it is created. If the CLASS\nfield (.02) is set to "NATIONAL", the entry cannot be\naltered locally. If the CLASS field (.02) is set to\n"LOCAL", then the rest of the fields can be added or\nmodified locally.\n\n
\nThis file is used by the copy/paste tracking functionality to track pasted\ntext.\n\n
\nThis file is intended to allow the definition of user classes in such a\nsignature.\n \nThe User Authorization/Subscription file points to the User Class file to\nallocate authorizations/subscriptions to appropriate user classes.\n \nThe User Class Membership file links users in the New Person file to User\nClasses.\n \nThis file supports an infinite hierarchy of subclasses, with each entry\nhaving as many subclasses as desired. Subclasses are contained in the\nway that they are useful across packages. It will undoubtedly evolve with\nsame file, as entries in their own right. A class automatically contains\nas members all members of its subclasses, as well as explicit members of\nthe class itself.\nmore experience in this area.\n \nThese user classes are then used to support part of the the\n"authorization" concept - who may do what to a document, order, etc.\n \nThey are also used to support part of the "subscription" concept - who\nshould receive something, e.g. a notification that a document needs\n\n
\nThis file associates users with actions on documents.\ndocument (e.g. author of document).\n \nIf an Authorization/Subscription entry has both User Class AND User Role,\nthe AND FLAG field permits these requirements to be "AND'ed", that is, a\nuser must both belong to the User Class AND must fill the User Role in\norder to perform the action. If the AND FLAG has value OR, or has no\nvalue, then User Class and User Role within the same entry are "OR'ed".\n \nEach file entry associates an action with 1 user class and/or 1 role. The\nentry makes this association for a given Document Definition (e.g.\n \nProgress Note) of a given status (e.g. Unsigned).\n \nMultiple file entries for the SAME action/Document Definition/document\nstatus allow association with more than one user class/role. Such entries\nare "OR'ed": that is, if a user belongs to the user class/role of one OR\nanother of these entries, the user may perform the action.\n \nUser classes automatically INCLUDE user subclasses of the given class as\ndefined in the User Class file.\n \nActions are of 2 kinds: authorization actions such as the signature action,\nDocument Definitions exist in hierarchy in file 8925.1, with Classes at\nthe top level, Document Classes at the next level down, and Titles under\nDocument Classes. Authorization/Subscription entries may be defined at\nany of the above levels. For example, an authorization which applies to\nmost or all Progress Notes should be defined at the Class level for\nDocument Definition "Progress Note." On the other hand, an authorization\nwhich applies only to Progress Notes of Title "Dental Hygiene Note" should\nbe defined at the Title level for Document Definition "Dental Hygiene\nNote".\n \nwhich an associated user is authorized to perform, and subscription\nWhen using authorizations/subscriptions to determine whether a given\nuser should receive/may perform a given action for a Document Definition\nof a given Title, code begins by checking entries for that action and\nstatus FOR THAT TITLE. If ANY such entries exist, then entries for higher\nDocument Definition levels will be ignored, and the user passes/fails\nbased on that level alone. Thus, if a Title is linked with a certain\naction, status and user class, then rules for that Title, action, and\nstatus should be entered for ALL user classes which can perform the\naction on the Title, since broader authorization (e.g. Provider class)\nset at higher levels (e.g. Progress Notes) is ignored.\nactions, such as an unsigned document notification, which the associated\n \nIf such entries do NOT exist, the next higher level of Document Definition\nis checked. And so on.\n \nIf no entries are found on any level, no users can perform/subscribe to\nthe action for the given Document Definition and status.\nuser "signs up to receive."\n \nAn action may be associated with a USER CLASS in the User Class file\n(e.g. Staff Physician class) AND/OR with a USER ROLE in relation to the\n\n
\nThis file links a person from the New Person file to a class in the User\nnursing degree. Smith could be entered twice, once as a Dietician and\nonce as a Student Nurse.\nClass file. Since user class membership includes members of all\nsubclasses, users should be made members of the most discrete class in a\nhierarchy of classes. For example, if Jones is a dentist, Jones should be\nentered into the Dentist class. Since Dentist is a subclass of the\nProvider class, Jones is then automatically a Provider.\n \nPersons wearing several different hats can have more than one entry in the\nfile. For example, Smith might be a dietician also working toward a\n\n
\nThis file contains the allowable statuses which may be applied to a TIU \ndocument during it's path through the system. It also contains statuses\nfor Document Definitions.\n\n
\nThis file encodes actions which occur in connection with clinical\nsubscribes to ("signs up to receive") a Notification action.\nnarrative documents.\n \nThese actions are referenced by entries in the User\nAuthorization/Subscription file to associate users with actions.\n \nThis file contains 2 kinds of actions: those a user is authorized to\nperform on a document, and those a user subscribes to for a document. For\nexample, a user is authorized to perform the Signature action, but a user\n\n\nPer VHA Directive 2005-044, this file has been "locked down" by Data \nThis file holds the CMS (HCFA) provider type data.\n \nIn 2001, ANSI ASC X12N asked the National Uniform Claim Committee (NUCC)\nto become the official maintainer of the Health Care Provider Taxonomy\nList (provider type).\n \nPERSON CLASS is to be used for identifying provider types for roll-ups.\n \nPatches need to review the technical description on field 90002.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the \nfile shall be done by Enterprise Reference Terminology (ERT) using the \nMaster File Server (MFS), provided by Common Services (CS). Creating \nand/or editing locally defined fields in the file are not permitted. Use \nof locally defined fields that were created prior to the VHA Directive's \n2005-044 effective date shall not be supported.\n\n\n
\nThis file serves as a container to track all the changes to specific \nfields for a DUZ in the NEW PERSON (#200) file that were captured and \nneed to be broadcast out.\n\n
\nThe HealtheVet Desktop relies on various modules or plug-ins for proper \ncorresponding plug-in.\n \n******************************************************************************\n* Entries in this file are distributed by HealtheVet Desktop Plug-in * \n* developers, and should NOT be altered by any facility. Altering this file * \n* can severely compromise the behavior of your HeatheVet Desktop plug-ins. * \n* *\n******************************************************************************\nprocessing. Each plug-in may have related VistA parameters from which \nvalues are obtained. This file supports the grouping of parameters into \nlogical categories, and the association of such categories with the module \nor plug-in to which they apply. \n \nCategories may also be associated with Preference Pages. Preference Pages may \nbe composed by plug-in developers, and are used by the HealtheVet Desktop's \nPreferences Dialog to make available user-configurable features of the\n\n
\nThis file contains current configuration data related to the daily \noperation of each monitor deployed.\n\n
\nContains default configuration values for each VSM Monitor deployed. \nThese values can be restored via the Restore action in the VSM Management \nList Manager Application. These values are not to be edited by an \nindividual site.\n\n
\nRecords the time each VSM Monitor is run on a given day. If a monitor is \nnot run the appropriate RUNTIME field for that monitor will be null.\n\n
\nThis file is used by the SAGG (Statistical Analysis of Global Growth)\nProject's collection routines.\n\n
\nThe RESOURCE USAGE MONITOR (RUM) file contains statistical data for\nLegend:\n \n PT - Prime Time\n Workday hours from 8:00 am to 5:00 pm\n NP - Non-Primetime\n Workday hours from midnight up to 8:00 am and after 5:00 pm up to \n midnight\n WD - Workday\n Monday through Friday excluding holidays as listed in the HOLIDAY \n file #40.5\noptions, protocols or RPCs that is gathered from the working system. The \n NW - Non-Workday\n Saturday and Sunday including holidays as listed in the HOLIDAY\n file #40.5\n \nA workday is defined by a call to the $$WORKDAY^XUWORKDY API.\n'RUM Background Driver' [KMPR BACKGROUND DRIVER] compiles data from the\n^KMPTMP("KMPR",DLY") global which is created by the %ZOSVKR routine. The\n'RUM Background Driver', which is scheduled to run every day, consolidates\nthis data into this file. \n \nNOTE: Data within this file should NOT be edited.\n \n\n\nThis file holds CP EVALUATOR data, and the data elements gathered for \neach entry. It is used from the CP EVALUATOR application to compare \nsystem impacts before and after routine changes.\n \n *** THE DATA IN THIS FILE SHOULD NOT BE CHANGED IN ANY WAY BY SITES***\n\n
\nThis file keeps track of all editable parameters for Capacity Planning \npackages. It also stores Start, Stop and Delta times for background \njobs, as well as CPU Node data. There is only one entry allowed in this \nfile, and is a pointer to the Institution file taken from the first piece \nof the $$SITE^VASITE extrinsic function.\n\n
\nHolds HL7 daily statistics.\n\n
\nThis file provides a holding place for data being transferred by the\nKERMIT protocol. By default the data can only be accessed by the user\nthat created it.\n \nThe Kermit Menu (XT-KERMIT options) may be used to send and receive data\nvia this file. The menu also allows the creator of the data to permit\naccess by others. This file is cross-referenced by name, creator, and\naccess allowed to user.\n\n
\nThis file holds the Universal Resource Locator's (URL) for the Certificate\nRevocation List's (CRL) from the Certificate Distribution Points (CDP) in\nthe users Public Key Infrastructure (PKI) Certificate.\nThese URL's are sent up to a Windows server to keep a database of\nCertificate Revocation's up to date.\n\n
\nThe lookup entry (or code) can be associated with multiple key words or\n JIM BLACK AND WHITE\n \nIf each of the above keyphrases are associated with 'JIM' then users can\nenter the following combinations:\n1. SALT, SALT AND PEPPER, SALT & PEPPER, PEPPER, SORT OF PEPPER, SCHNAUZER\nwill return ONLY Jim. Note that SORT OF PEPPER returns only Jim because\nthe tokens 'SORT' and 'PEPPER' must BOTH be true for a match. PEPPER is\nfalse for Mary.\n2. SORT, SORT OF GRAY returns Mary and Jim\n3. GRAY returns Mary, Jim, and Jack\nkey phrases. The entry will be displayed if the user enters all or any\n \nNOTE! LOOKUPS ARE PERFORMED IN THE FOLLOWING ORDER:\n \n 1. SHORTCUT<--stops here if a match is found\n 2. SYNONYM\n 3. KEYWORD\npart of a key phrase. For example:\n |**mtlu x-ref**\n KEYPHRASE: LOOKUP FILE: V\n SALT AND PEPPER NAME: JOHN HAIR COLOR: LIGHT BROWN\n SORT OF GRAY JACK PRETTY GRAY\n SCHNAUZER JILL GEORGIA CLAY\n MARY SORT OF GRAY\n\n
\nThis is a word or phrase which will be used EXCLUSIVELY to find an\nentry. During a lookup, this file is checked first. If a shortcut matches\nthe user's entry, the corresponding entry will be displayed and no other\nlookups will be performed.\n\n
\n \nSynonyms are single terms that can be associated with one or more TERMS in\nthe lookup file (tokens in the MTLU cross-reference). For example, CANCER\ncan be associated with each of the specific forms of cancer that might be\nfound. Note that if the user enters a phrase, all terms in the phrase must\nbe true to get a match, therefore 'LUNG CANCER' might significantly\nrestrict the search.\n\n
\nFiles that have been configured for Multi-term lookups must be defined\nhere, along the the name of the file's MTLU cross-reference.\n\n
\nThis file is used to associate a VHA Unique ID (VUID) to each of the \nelements in a Set of Codes, effectively associating a standard reference \nterm with a non-standard reference term.\n\n
\n This file contains the site specific information for the\nMSM-Capacity Management project. This file should only be edited by the\nmenu option provided.\n\n
\n This file is used the hold the raw MSM-RTHIST data in a VA Fileman\nformat. THIS FILE SHOULD NOT BE EDITED.\n\n
\nThis file holds parameters that Kernel... uses that the site\nis allowed to change. It is still in the development stage.\nAn example is the computer account letter. Kernel load its \nstandard name into the file and if the site builds a new letter\nthen they can enter a replacement name that will be used inplace\nof the standard one.\n\n
\nThis file holds the site parameters for this installation of the Kernel.\nIt will have only one entry -- the domain name of the installation site.\nSome parameters are defined by the systems manager during the installation\nprocess. These include Agence, volume set multiple, Default parameters.\nOthers may be edited subsequent to installation. Spooling, response time,\nand audit parameters may be established. Priorities may be set for\ninteractive users and for TaskMan. Defaults for fields such as timed\nread, auto menu, and ask device are defined for use when not otherwise\nspecified for a user or device.\n\n
\nThis file contains the actual data values for the parameters found in the\nPARAMETER DEFINITION file (#8989.51).\n\n
\nThis file contains the characteristics of parameters. Entries in this\nfile must be namespaced and they are exported by the package which owns\nthem.\n\n
\nThis file contains a list of files which parameter instances can be\nassociated with. Any additions to this file must be coordinated with\nToolkit developers so a patch can be issued.\n\n
\nThis file contains templates which allow developers to group entries in\nthe PARAMETER DEFINITION file (#8989.51) together for editing. Entries in\nthis file must be namespaced and they are exported by the package which\nowns them.\n\n
\n \nThis file is used to record the most current version of a routine, and\ninformation about changes which have occurred in that routine in prior\nversions. Routines are checked for any changes by using the XTVR UPDATE\noption which enters any changes noted and updates the most current\nversion. There is no need for manual entry into this file.\n \nThe option XTVR COMPARE is used to obtain listings of the changes recorded\nfor the routine(s) from the most recent to earlier changes.\n\n
\n \nThis file is used to indicate the file numbers for the main files and\nnamespaces for options, keys, etc., which are to be included as a part of\na package undergoing verification. This file is used to determine the\nfiles and other entries to be included by the routines which are used in\npreparing and comparing the XTV GLOBAL CHANGES file.\n\n
\n \nThis file is used to record the state of a given verification package in\nterms of DD entries, options, keys, templates, etc. for comparison with a\nsubsequent version of the package.\n\n
\nThis file is used to maintain a log of errors occurring at alpha/beta\ntest sites. It normally will contain data only at the originating\nsite for a software package which is in alpha or beta test. The test\nsites will transmit to the originating site information on errors\nwhich have occurred with namespaced routines or options associated with\nthe package in alpha or beta test. This file contains the data in\nthose messages which permits the errors to be evaluated by routine\nname, by site, by date of error, etc.\n\n
\nThis file is used for the ePCS DEA project and it stores audit data. Data\nis stored when a user is allocated or de-allocated the 'PSDRPH' key.\n\n
\nThe DEA BUSINESS ACTIVITY CODES FILE is associated with the DEA numbers \nand provider information in the DEA NUMBERS file. This file links a \nprovider with the type of service provided. It contains BUSINESS \nACTIVITY CODES that are supplied by the DOJ/DEA web service.\n\n
\nThe DEA NUMBERS FILE is designed to contain demographic and permission \ninformation about a provider related to the ability to order controlled\nsubstance prescriptions.\n\n
\nThis file is used to keep track of alerts pending processing for each\nuser. The main entry for each record is a pointer to the NEW PERSON file.\n A multiple under each user is used to record the date and time an alert\nwas generated, the unique ID associated with the alert, the text for\ndisplay, and an optional routine entry point or option for use in\nprocessing the alert, and an optional data string associated with the\nalert.\n\n
\nThis file is used to track the content and interactions with an alert.\ndeleted after processing or associated with another user's processing, or\nwhen the alert was deleted by a clean-up operation.\n \nUnless a longer lifetime is specified for the specific alert, it will be\ndeleted from the file after 30 days. If a longer lifetime is specified,\nit will not be deleted until after that period passes.\nEvery alert which is generated is initially filed within this file. Each\nentry has the date and time the alert was generated, which user generated\nthe alert, whether the alert was generated in a background task, what\naction was to be taken if any (the entry point or option name to be used)\nand the data string, if any, for use with the alert. There is a multiple\nfield which also identifies each user that the alert was sent to, and when\nthe user initially saw the displayed text, when the alert was selected for\nprocessing, when the processing was completed, and when the alert was\n\n
\nThis file contains descriptions and specifications for locks held\nby various applications. The Lock Manager uses it to provide information\nand guidance to the user about locks found in the lock table.\n\n\n
\nThis is the parameter file for the Kernel Lock Manager. It should contain\nonly one entry.\n\n\n\n\n
\nThis file records each instance of the Kernel Lock Manager being used\nto terminate a process and the locks that the process held.\n\n\n
\nThis file is used as a repository of server-based procedures in the context\nof strings or a word processing string as indicated by the RETURN VALUE TYPE\nfield (.04).\n\nThe remote procedure may be available for use by anyone or its use may be\nrestricted to one or more application. The range of availability is indicated\nby the AVAILABILITY field. IF THERE IS NO ENTRY IN THE AVAILABILITY FIELD,\nthen the procedure is assumed to be PUBLIC.\n\nA remote procedure may be removed from service for a period of time by setting\nthe INACTIVE field. A request for use of a procedure which is marked inactive\nof the Client/Server architecture. By using the Remote Procedure Call (RPC)\nwill result in an error being returned to the originating application.\nBroker, applications running on client workstations can invoke (call) the\nprocedures in this file to be executed by the server and the results will be\nreturned to the client application.\n\nEach remote procedure entry is associated with an entry point (ROUTINE with\noptional TAG). Calls to these procedures can include parameters of different\nvalue types. The resulting value of the call can be either a string, a list\n\n
\nThis file holds the site parameters for this installation of the RPC Broker.\nIt will have only one entry -- the domain name of the installation site.\n\n
\nThe REMOTE APPLICATION file was introduced as part of the Broker Security \na one-way hash of a secure phrase. Identification of an entry in the file\nis based on the application passing in the original phrase which is then\nhashed and used for a cross-reference lookup. The application must have at\nleast one entry in the CALLBACKTYPE sub-file indicating a connection type,\na valid address for the authenticating server, and a connection port\nnumber. This information is necessary for the remote server to directly\nconnect the authenticating server to obtain the demographic information\nnecessary to create or match the visitor entry in the NEW PERSON file\n(#200). The application will also specify the desired context option for\nthe user and this will be given to the remote visitor instead of the\nEnhancement to secure access via the remote user or visitor approach by \napplication having to figure out how to set this value.\nGUI applications (formerly known as the CAPRI approach for the first \napplication to use this access style). The remote visitor access permits \napplications where users need to access a large number of sites to do so \nwithout requiring a separate access code and verify code at each site.\n \nFollowing the Broker Security Enhancement, applications will be able to \nuse the remote visitor access only if they have an entry in this file with\n\n
\nThis file identifies the elements of a package that will be transported\nby the Kernel Installation & Distribution System. All components of the\npackage, i.e. templates, options, Security Keys, etc., must be listed in \nin this file.\n\n
\nThis file contains the installation information for a site from the Kernel\nInstallation & Distribution System. This file should not be edited.\nAll information is updated when a new package is installed at a site.\n\n
\nThis file contains VistA patch information which is stored by a server \n 1. If the patch has been installed since last run and the \nparameter file is set in field 3 to delete installed patches, it will\ndelete the entry from this file, regardless of the number of days in \nfield 2. If the parameter file is set to leave patches, it is not \ndeleted.\n \n 2. If the patch has NOT been installed, its information will be \nsaved and reported via a mail message to a group.\n \nThe person(s) who are in charge of monitoring patches at the site or\noption when a patch arrives to G.PATCHES at a site. The server extracts \nperhaps for the VISN will be responsible for following up on delinquent\npatches.\ncertain information and stores it here.\n \nA night-time program will then check the file, match it against the \ninstall file. If the current date is past the compliance date for patch\ninstallation (typically 30 days for regular patches, three days for\nemergency patches) it will do one of two things:\n \n\n
\nThis is the parameter file that controls certain functions of the Patch \n \nMail groups: groups that wish to receive the uninstalled bulletin.\n \nNumber of days to keep data: number of days to allow data to remain, \nprovided field 3 is answered NO. If field 3 is answered YES, this field \nis ignored.\n \nDelete installed patches? - YES allows the nightly job to remove patches \nshown as installed. NO does not remove them. If this field is answered \nYES, field 2 is ignored.\nMonitor software:\n \n .01 SITE NAME\n 1 MAIL GROUPS (multiple)\n 2 NUMBER OF DAYS TO KEEP DATA\n 3 DELETE INSTALLED PATCHES?\n \nSite name: Free text name of the facility.\n\n
\nPHYSICAL EXAMINATION, DSM-III DIAGNOSES AND OTHER FILES FOR\nTHE MEDICAL RECORD\n \nFields annotated with an "*" are scheduled for deletion from\nfile.\n\n
\nThis file is IHS's primary patient data file. The NAME (.01) field of this \npoint to this file.\nfile is a pointer to the VA's patient file (#2). Fields in \ncommon between the two dictionaries actually exist only in the VA patient \nfile and are referenced by the IHS patient file as computed fields. All \nother files containing patient data have backward pointers linking them to \nthis file. The linkage is by patient name and the internal FileMan gener-\nated number of the ancillary file is the same number used in this file.\n \nAll applications developed for the RPMS which require patient data will\n\n
\nThis file contains a record of all patient visits at health care facilities or\nby health care providers, including direct outpatient and clinic visits, as\nwell as inpatient encounters with providers of care. All other visit related\nfiles, such as purpose of visit (diagnoses), operative procedures,\nimmunizations, examinations, etc., will point to a visit in this file. The\nrecords are maintained by date/time of visit, and the patient name field is a\npointer to the IHS Patient file, where the patient must exist before data can\nbe added here.\n\n\n
\nThis file has been designed for joint use by the Indian Health Service and\nvisit. The primary/secondary field identifies which provider is considered\nthe primary provider for this visit.\nthe Department of Veteran Affairs.\n \nIn IHS, this record, along with a purpose of visit, is required for each\npatient encounter at a facility, or at a visit in the home or other field\nlocation. This same requirement does not exist in the VA.\n \nData must exist in both the Patient/IHS file and the Visit file before\ndata can be entered here. There can be multiple providers for a given\n\n
\nThis file has been designed for joint use by the Indian Health Service and the\nthe provider, which will have an ICD Diagnosis code related to it to support\nClinical needs and additionally support Administrative functions such as\nBilling, Workload, and DSS.\n \nThere should be at least one V POV entry for each patient visit, whether it is\nan inpatient, outpatient or field visit, and regardless of the discipline of\nthe provider, i.e., dental, CHN, mental health, etc. There is no limit to\nthe number of POV's that can be entered for a patient for a given encounter. \n \nAt IHS facilities, POV's are generated automatically at the time of discharge \nDepartment of Veteran Affairs. POV is an abbreviation for "Purpose of Visit"\nfrom the Admission, Discharge and Transfer (ADT) system. POVs are entered in \nnarrative form, and coded automatically to the appropriate ICD diagnosis code.\nPhysician entered narrative, which modifies the diagnosis, such as "doubtful",\n"suspect", "resolved" are entered by the data entry person in the MODIFIER\nfield. The file contains pointers to the IHS Patient file, and Visit file, and\ndata must exist in both files for this visit before a POV can be entered.\n \nAt VA facilities, POVs are primarily created for clinic visits from 3 sources: \n 1) In the CPRS encounter form on the Diagnosis Tab. Pre-existing problems\nfrom the patient's Problem List can be selected on this tab.\n(descriptive name used by IHS) or "Problem of Visit" (descriptive name used by\n 2) The scheduling checkout process, in which case the information collected\nabout the POV is limited to the ICD Diagnosis code. The Provider Narrative\nbecomes the ICD long description from the ICD Diagnosis file. \n 3) Encounters created by other packages using the API DATA2PCE^PXAPI. If the\nProvider Narrative is not passed it defaults to the ICD Long Description.\n\nVA). \n \nThe V POV file is used to store clinical data related to the "Purpose of\nVisit" or "Problem of Visit", (POV). This is the provider's definition of what\ndiagnosis represents the patient care given at the visit. The POV entry is\nnot the patient's "Chief Complaint" text. It is the diagnosis as defined by\n\n
\nTo preserve the continuity of files shared by the Indian Health Service and\n \nThis file contains immunizations specific to a visit for a patient. This\nfile contains one record for each immunization.\n \nIn the VA, if an immunization is entered into PCE and it has a related CPT or\nICD code, then a V CPT or V POV entry will automatically be created with the\nCPT or ICD code for the immunization. The Coding System multiple of the\nIMMUNIZATION file, #9999999.14, contains the mapping of the immunization to\nthe related CPT and ICD codes.\n\nthe Department of Veterans Affairs, this file includes fields used by Indian\nHealth Service that will not be used by the Department of Veterans Affairs.\nThese fields may point to other files and routines not deployed by the\nDepartment of Veterans Affairs. Inclusion of these fields, as designed, was\napproved by the DBA. These fields were initially introduced with the release\nof the VISTA IMMUNIZATION ENHANCEMENTS 1.0 (PX*1*201) for the VistA\nImmunization Enhancements Project. Additional fields may be included in\nlater enhancements.\n\n
\nThis file has been designed for joint use by the Indian Health Service and the\nICD code, then a CPT or ICD entry will automatically be entered into the V\nCPT or V POV file. This supports getting workload credit from clinical\nactivities. The CODING SYSTEM multiple of the SKIN TEST file (#9999999.28)\ndefines the relationships between Skin Tests and CPT and ICD codes.\n\nDepartment of Veteran Affairs. There will be one record for each type of skin\ntest given to a patient on a given visit. Data must exist for a patient and a\nvisit before data can be entered here. The record is normally created when a\nskin test is given, and the results, if available, are entered later and\nmatched to the original record. If results are entered and a skin test given\ndoes not exist, a new record is created.\n \nIn the VA, if a skin test is entered into PCE that has a related CPT or\n\n
\nThis file contains exam information specific to a visit for a patient. This\nfile contains one record for each exam for each visit.\n\n\n
\nThis file has been designed for joint use by the Indian Health Service and\nthe Department of Veteran Affairs.\n \nThis file contains a record for each treatment provided to a patient \non a given patient visit. There will be multiple treatment records\nfor the same treatment (.01) field based on the date on which it was \ngiven. Data must exist in the Patient/IHS file and visit file for the\npatients' visit before data can be entered in the V Treatment file.\n\n
\nThis file has been designed for joint use by the Indian Health Service and\nthe Department of Veteran Affairs.\n \nThis file stores educations given to a patient. Data must exist in the\nPATIENT/IHS file and VISIT file for a patient visit before data can be entered\nin the V PATIENT ED File.\n\n\n
\nThe V CPT file has been defined for joint use by the Indian Health Service\nforms are stored here to record that they were done. Results of\nprocedures are not included.\n \nThis file is restricted to procedures that have a CPT code.\n \nThe Provider Narrative field represents the preferred text for this\nprocedure as defined by the clinician.\n\nand the Department of Veteran Affairs. This is the file used to store CPT\nrelated services performed at a visit. Data must exist for a patient and\na visit before data can be entered in the V CPT file.\n \nThis file is used in the VA to identify procedures that were done to a\npatient at an encounter or occasion of service. The procedures may\nhave been performed by a primary or secondary provider of patient\ncare. Procedures checked off and scanned from ambulatory care encounter\n\n
\nThis file has been defined for joint use by the Indian Health Service and\nthe Department of Veteran Affairs.\n \nThis is the file used for storing patient health factors identified at a\nvisit. Data must exist in the Patient/IHS and Visit file for a patient's\nvisit before data can be entered in the V Health Factor file.\n\n
\nThis file is used to document immunization non-administration events,\ncapturing the reasons for not administering immunizations, either that\nadministration was contraindicated or that it was refused by the \npatient.\n\n
\nThe V STANDARD CODES file is used to store standardized codes other than\nCPT and ICD. This allows for more complete standardized documentation of\nthe encounter.\n\n\n
\nThis file contains patient specific problems entered by the various\nproviders of service. The PATIENT NAME field (.02) is a backward pointer\nto the IHS PATIENT file. This file contains one record for each problem\nfor each patient, therefore, the KEY field (.01) is duplicated.\n \nAs of March 17, 1986 the FACILITY must be entered prior to the NUMBER.\nIf the NUMBER is entered without previously entering the FACILITY the\n"AA" index is created with no FACILITY pointer.\n\n
\nThis file contains entries that were deleted out of the V IMMUNIZATION \nfile (#9000010.11). Immediately prior to deleting an entry from the V \nIMMUNIZATION file, a copy of the record is made and filed here. The\ndate/time of deletion and the user that deleted the record will be\nrecorded. Entries in this file should not be edited or deleted.\n \nNote: Any time Data Dictionary (DD) changes are made to the V\nIMMUNIZATIION file, corresponding DD changes should be made to this file\nas well.\n\n
\nIntermediate form of transmissions. Fields are stored in formatted form.\nNCPDP coded values preceded by the NCPDP field identifier to be used \nin the NCPDP transmission. Example: Compound Code is either a 1 or 0. \nThe NCPDP field identifier for 'Compound Code' is 'D6'. The field length \nis 3 thereby allowing the identifier for that field to be included in the \ndata stored in that field. So, 'D61' is stored for that field.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\nRaw packet is also stored.\n \nMost fields are in Free Text format to accommodate NCPDP Standard \nformatting criteria and required field lengths. Fields other than those \nwith decimals in the number correlate directly to the field numbers \nsupplied in the NCPDP Data Dictionary.\n \nWhile many of the fields in this file indicate coded values, they are \n\n
\nThis file stores the response information returned by the third-party\npayer. Most of the fields have 'raw' NCPCP data so it is formatted per the\nNCPDP specifications.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis is ECME log, which is used to store an audit trail of ECME \nactivity. There are currently two types of logs - one for transactions\nand another for purging.\n\n
\nThis file is used to store payers that are asleep or should be ignored \nbecause they are asleep. Generally there should be few or no entries in \nthis file unless there are payers that are asleep.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file comes with standard NCPDP Patient Relationship\ndata to be used in submitting claims. The file and data should never be\nlocally modified, edited or changed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file is used to store the codes and descriptions for NCPDP field \n342-HC (Other Payer Amount Paid Qualifier). These codes are used for \nsecondary electronic claim transmissions to third party payers. No local \nchanges should ever be made to this file.\n \nPer VA Directive 6402, this file definition should not be modified.\n\n
\nNCPDP field 440-E5 - Professional Service Code\n \nThis file is used to store the possible NCPDP PROFESSIONAL SERVICE CODE \nvalues, which are used for overriding DUR rejects. No local changes \nshould ever be made to this file.\n\n
\nNCPDPD field 441-E6 - Result of Service Code\n \nThis file is used to store the possible NCPDP RESULT OF SERVICE CODE \nvalues, which are used for overriding DUR rejects.\nNo local changes should ever be made to this file.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field 439-E4 - Reason for Service Code\n \nThis file is used to store the possible NCPDP REASON FOR SERVICE CODE \nvalues, which are used for overriding DUR rejects. No local changes \nshould ever be made to this file.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field 48-D8 DISPENSE AS WRITTEN (DAW)/PRODUCT SELECTION CODE\n \nThis file is used to store NCPDP DAW (Dispense As Written) codes, which \nare used for prescription electronic claim transmission to third party payers.\nNo local changes should ever be made to this file.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file is used to store the possible NCPDP CLARIFICATION CODES values,\nwhich are used for overriding DUR rejects. No local changes should ever \nbe made to this file. The data stored in this file are based on the \nNCPDP standards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file comes with standard NCPDPD prior authorization data to be used in\nsubmitting claims. The file and data should never be \nlocally modified, edited or changed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file comes with standard NCPDP Patient Residence\ndata to be used in submitting claims. The file and data should never be\nlocally modified, edited or changed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file comes with standard NCPDP Pharmacy Service Type \ndata to be used in submitting claims. The file and data should never be\nlocally modified, edited or changed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file comes with standard NCPDP Delay Reason Code \ndata to be used in submitting claims. The file and data should never be\nlocally modified, edited or changed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nData for development use in certifying software when required by\nswitches and claims end processors. \nAlso contains test claim used by MGR/TEST option.\nThis file is completely overwritten by installation.\n\n
\nThis file is used to store Payer Response Overrides. This file should \nnot be populated on production systems, only on test systems.\n \n \nPer VHA Directive 2004-038, this file definition should not be modified. \n\n
\nNCPDP field D57-RG PRESCRIBER PLACE OF SERVICE CODE\n \nThis file is used to store the possible NCPDP PRESCRIBER PLACE OF SERVICE \nCODES, that can be sent with a claim. No local changes should ever be \nmade to this file. The data stored in this file is based on the NCPDP \nstandards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field C51-9X BENEFIT STAGE INDICATOR\n \nThis file is used to store the possible NCPDP BENEFIT STAGE INDICATOR, \nthat can be sent on a claim or returned by the payer. No local changes \nshould ever be made to this file. The data stored in this file is based \non the NCPDP standards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field C91-KK LTPAC DISPENSE FREQUENCY\n \nThis file is used to store the possible NCPDP LTPAC DISPENSE FREQUENCY, \nthat can be sent on a claim. No local changes should ever be made to this \nfile. The data stored in this file is based on the NCPDP standards and \nare nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field C95-KQ PATIENT PAY COMPONENT QUALIFIER\n \nThis file is used to store the possible NCPDP PATIENT PAY COMPONENT \nQUALIFIER, that can be returned by the payer. No local changes should \never be made to this file. The data stored in this file is based on the \nNCPDP standards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field C47-9T OTHER PAYER ADJUDICATED PROGRAM TYPE\n \nThis file is used to store the possible NCPDP OTHER PAYER ADJUDICATED \nPROGRAM TYPE, that can be returned by the payer. No local changes should \never be made to this file. The data stored in this file is based on the \nNCPDP standards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field F05-Z0 DUR/DUE COMPOUND PRODUCT ID QUALIFIER\n \nThis file is used to store the possible NCPDP DUR/DUE COMPOUND PRODUCT ID \nQUALIFIER CODES, that can be sent with a claim. No local changes should \never be made to this file. The data stored in this file is based on the \nNCPDP standards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field E95-Z9 OTHER PHARMACY ID QUALIFIER\n \nThis file is used to store the possible NCPDP OTHER PHARMACY ID QUALIFIER \nCODES, that can be sent with a claim. No local changes should ever be \nmade to this file. The data stored in this file is based on the NCPDP \nstandards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field F01-Z4 OTHER PRESCRIBER ID QUALIFIER\n \nThis file is used to store the possible NCPDP OTHER PRESCRIBER ID \nQUALIFIER CODES, that can be sent with a claim. No local changes should \never be made to this file. The data stored in this file is based on the \nNCPDP standards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field E87-ZV DATA SOURCE OF INVALID PROVIDER DETERMINATION\n \nThis file is used to store the possible NCPDP DATA SOURCE OF INVALID \nPROVIDER DETERMINATION CODES, that can be sent with a claim. No local \nchanges should ever be made to this file. The data stored in this file \nis based on the NCPDP standards and are nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field 339-C6 OTHER PAYER ID QUALIFIER\nNo local changes should be made to this file. The data stored in this file\nare based on the NCPDP standards and are nationally distributed.\n \nPer VA Directive 6402, this file should not be modified.\n \nThis file is used to store the possible NCPDP OTHER PAYER ID QUALIFIER codes,\nwhich may be sent from a third-party payer to the VA on a claim response.\n \nThird-party payer responses are stored in file 9002313.03, BPS \nRESPONSES. Other payer ID qualifier codes are stored in sub-file \n9002313.035501, OTHER PAYER ID MLTPL, field 339, OTHER PAYER ID QUALIFIER.\n \n\n
\nNCPDP field 549-7F HELP DESK PHONE NUMBER QUALIFIER\n \nNo local changes should be made to this file. The data stored in this\nfile are based on the NCPDP standards and are nationally distributed.\n \nPer VA Directive 6402, this file should not be modified.\n \nThis file is used to store the possible NCPDP HELP DESK PHONE NUMBER\nQUALIFIER codes, which may be sent from a third-party payer to the\nVA on a claim response.\n \nThird-party payer responses are stored in file 9002313.03, BPS \nRESPONSES. Help desk phone number qualifiers are stored in sub-file \n9002313.0301, RESPONSES, field 549, HELP DESK PHONE NUMBER QUAL.\n\n
\nNCPDP field 139-UR MEDICARE PART D COVERAGE CODE\n \nNo local changes should be made to this file. The data stored in this file\nare based on the NCPDP standards and are nationally distributed.\n \nPer VA Directive 6402, this file should not be modified.\n \nThis file is used to store the possible NCPDP MEDICARE PART D COVERAGE CODE\nvalues, which may be sent from a third-party payer to the VA on a claim\nresponse.\n \nThird-party payer responses are stored in file 9002313.03, BPS \nRESPONSES. Medicare Part D coverage codes are stored in sub-file \n9002313.0301, RESPONSES, field 139, MEDICARE PART D COVERAGE CODE.\n\n
\nMore input. Override of specific NCPDP fields.\nBPSOSO* routines (letter O)\n\n
\nPharmacy-specific data -- NCPDP #, default DEA #, etc. One BPS PHARMACY\nhas a list of one or more OUTPATIENT SITES (file 59).\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nA copy of 9002313.59. As each transaction completes, a snapshot of \n9002313.59 entry is placed here in 9002313.57.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nStatistics, as displayed by List Manager and ^BPSOS2.\n\n
\nTransactions in progress. When complete (status 99), a copy of the record\nis placed in 9002313.57.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file is used to store data for queued requests before the ECME \nengine un-queues them and during their processing. The data stored in this\nfile are used to create a record in BPS TRANSACTION file (#9002313.59) to \nbuild a claim request or reversal and send it to the insurer (payer). \nGenerally there should be few or no entries in this file unless there are \nstranded claims/reversal or requests that need to be un-stranded by the \nuser.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file is used to store insurers' details data returned by Integrated\nBilling package to be used by ECME engine to build claim requests and\nreversals and send them to insurers (payers). Generally there should be\nfew or no entries in this file unless there are stranded claims, reversal\nor requests that need to be un-stranded by the user.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nA list of the possible result categories,\nas returned by CATEG^BPSOSUC().\n\n
\nObsolete. But it may be revived.\n\n
\nEach transaction described in the NCPDP Telecommunication Standard is\ncomprised of one or more segments. This file contains a list of\nsegments. The file BPS NCPDP FIELD DEFS lists each field that may be\non an outgoing claim request or an incoming claim response. Each entry\nin that file will have a field that points to this file to indicate\nwhich segment that field is a part of for the claim request (field\nREQUEST SEGMENT) and/or the claim response (field RESPONSE SEGMENT).\n \nPer VA Directive 6402, this file definition should not be modified.\n\n
\nThe NCPDP Data Dictionary Individual fields which combine into formatted \npackets.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThe formats for sending claims. As derived from NDC Payer Sheets and \nEnvoy Plan Sheets. Never modify locally, except in cooperation with \ndevelopment.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nNCPDP field 511-FB REJECT CODE\n \nThis file is used to store the possible NCPDP REJECT CODES, that can be \nreturned by the payer. No local changes should ever be made to this\nfile. The data stored in this file are based on the NCPDP standards and\nare nationally distributed.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nBPS Auto Close Reject Codes file stores reject codes to be defined as \nauto close reject codes. Specific criteria, defined in this file, will \nbe used to determine if a claim should automatically be closed upon the \npharmacist ignoring a reject on the prescription.\n\n
\nParameters that apply to all of ECME. There should only be one record \nwith IEN=1 and name MAIN SETUP ENTRY.\n \nPer VHA Directive 2004-038, this file definition should not be modified.\n\n
\nThis file is used to store intervention types.\nIntervention types are actually reasons that a pharmacist had\nto stop filling a prescription and contact a provider to\neither change the prescription or get clarification of it.\nExamples of intervention types may include things such as:\nCRITICAL DRUG INTERACTION, ALLERGY, INCORRECT DOSE, etc.\n\n
\nThis file is used to enter pharmacy interventions.\nInterventions in this file are records of occurrences where the\npharmacist had to take some sort of action involving a\nparticular prescription or order. A record would record things\nlike the provider involved, why an intervention was necessary,\nwhat action was taken by the pharmacists.\n\n
\nThis file is used to store intervention recommendations.\nIntervention recommendations are actions taken by the pharmacist when\nthere is some reason that a prescription had to be clarified or changed.\nRecommendations would include things like: Change drug, change dosage,\norder lab tests, etc.\n\n
\nThe ESP MASTER NAME INDEX file contains demographic data (e.g.,\nname, social security number, date of birth, age, AKA (also known\nas or alias) of persons have a record with the VA Police. This file\nis pointed to by the name fields in the ESP POLICE REGISTRATION LOG\nfile (#910.2), ESP OFFENSE REPORT file (#912), ESP VIOLATION file\n(#914), and the ESP WANTS & WARRANTS file (#913).\n\n
\nThe ESP ACTIVITY REPORT file contains data recording the types of\nactivities, number of times the activities are performed, and time\nspent performing the activities by each VA Police Officer on an\nassigned shift.\n\n
\nThe ESP POLICE REGISTRATION LOG file contains data required to\nimplement the Vehicle Registration requirement mandated by VA Police\npolicy.\n\n
\nThe ESP SELECTABLES file contains colors and makes of vehicles. It\nis pointed to by the ESP POLICE REGISTRATION LOG file (#910.2) color\nand make fields. This file is also pointed to by the ESP OFFENSE\nREPORT file (#912) hair, skin, and eye color fields. These fields\nare screened so only appropriate choices can be selected.\n\n
\nThe ESP EVIDENCE file contains data necessary to implement the\nEvidence/Property Custody Records requirement mandated by the VA\nPolice policy directives.\n\n
\nThe ESP ACTIVITY CODE file contains a list of work activities performed\nby VA Police Officers during the course of a routine daily shift. It\ncontains the name of the work activity, a code number assigned to the\nwork activity and the number of minutes the work activity\nshould be performed. Local sub-activity codes may be added.\nRefer to the User's Manual for more information.\n\n
\nThe ESP DISPOSITION CODES file contains a series of descriptive codes\nwhich will assist the VA Police in tracking how they resolve or make\ndisposition of recorded offenses and issued violation notices. Some\ndisposition codes apply only to offense dispositions and others only\nto the disposition of violation notices. These codes are screened so\nthey can be selected only for the appropriate type of disposition.\n\n
\nThe ESP OFFENSE REPORT file contains the offense report information.\nThis file points to the ESP MASTER NAME INDEX file (#910). Once a\ncase is closed, the offense report becomes the case history. The\noffense report cannot be edited once a case is closed, but can be\nreopened for editing by the appropriate authority.\n\n
\nThe ESP CRIME DATA file is used to capture data for the Police &\nSecurity Monthly Crime Report. This file allows for a specific\ndate range selection so that the report can be run for alternate\ntime periods. The crime categories included are the only ones\nauthorized by Police & Security managmeent (VACO) for tracking\ncriminal activity by the local sites.\nThe file data is AUTO-GENERATED.\n\n
\nThe ESP CRIME DATA file is used to capture data for the Police &\nSecurity Monthly Crime Report. This file allows for a specific\ndate range selection so that the report can be run for alternate\ntime periods. The crime categories included are the only ones\nauthorized by Police & Security managmeent (VACO) for tracking\ncriminal activity by the local sites.\nThe file data is AUTO-GENERATED.\n\n
\nThe ESP POLICE TRAINING file contains data recording the types of\ntraining, subject matter and number of minutes of training received for\neach VA Police Officer.\n\n
\nThe ESP CRIME CATEGORIES file contains thirteen major crime\ncategories as determined by the VA Police policy managers (VACO).\nAll offense reported will fall initially within one of these\ncategories. No additional categories are to be added by the local\nsite.\n\n
\nThe ESP CRIME TYPES file contains types of criminal activity which\nfall under each of the thirteen Crime Categories within ESP CRIME\nCATEGORIES file (#912.7). These crime types have been identified by\nthe VA Police policy managers (VACO) and no additional crime types\nare to be added by the local sites.\nYou CANNOT add entries to this file.\n\n
\nThe ESP CRIME SUB-TYPES file contains subtypes of specific\ncriminal activities which fall under specific crime types in\nESP CRIME TYPES file (#912.8). These crime subtypes have been\nidentified by the VA Police policy managers (VACO) and no\nadditional crime subtypes are to be added by the local sites.\nYou CANNOT add entries to this file.\n\n
\nThe ESP WANTS & WARRANTS file contains information kept on file (by\nVA Police) on individuals who may be wanted in reference to\nthe commission of a crime, or who may be wanted under some type of\ncriminal or civil court proceeding, violation or holding document.\n\n
\nThe ESP VIOLATIONS file contains data recording the issuing of either\na United States District Court Violation Notice (VA Form 10-9019)\nor VA Police Courtesy Violation Notice (VA Form 10-6160).\n\n
\nThe ESP OFFENSE CODES file contains appropriate offenses contained\nwithin VA Regulations 1.218, United State Codes, Titles 18 and 21.\nThe entries contained within the released version of the program\nare those offenses considered to be standard at all VA facilities.\nThe Chief of VA Police can add any local codes (e.g., VA facility,\ncity, county or state) that might be enforced at the local site.\n\n
\nThis file stores all information currently being recorded on\non VA Form 10-1433 and VA Form 10-1433a Continuation Sheet.\nthe VA Police Daily Operations Journal, VA Form 10-1433 and\nContinuation Sheet, VA Form 10-1433a. The data necessary to\nbe entered into this module is exactly as manually typed on\nthe forms.\nThe ESP DAILY JOURNAL file contains all information currently\nbeing recorded on the VA Police Daily Operations Journal, VA\nForm 10-1433 and VA Form 10-1433a Continuation Sheet. Entries\ninto this file is identical to the information being recorded\n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis file stores Vaccine Information Statements (VISs). These are\ninformation sheets produced by the Centers for Disease Control and \nPrevention (CDC) that explain both the benefits and risks of a vaccine\nto vaccine recipients.\n \nFederal law requires that healthcare staff provide a VIS to a patient, \nparent, or legal representative before each dose of certain \nvaccinations.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nThis file stores the facility default responses for data prompts in the\nimmunization data entry process.\n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis file is a table of standard possible sources from which the\ninformation about a particular immunization event was obtained. The data\nin this file are derived from the CDC-defined Immunization Information\nSource table (NIP001).\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis file is a table of routes of administration for\nvaccines/immunization events. The data in this table are from the\nHL7-defined Table 0162 - Route of Administrations.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis is a table of administration sites - areas of the patient's body\nthrough which a vaccine/immunization can be administered. The values in\nthis table are from the HL7-defined Table 0163 - Administrative site.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis is a table of contraindications regarding immunizations and skin\ntests. The data for this table is derived from the CDC table \nVaccinations Contraindications.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis is a table of reason for the refusal of an immunization or skin \ntest. The data in this file has been derived from the CDC-defined table\nNIP002 - Substance Refusal Reason.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nThis file contains a mapping of applicable immunization administration \nsites for a given administration route.\n\n
\nThis file is used to maintain a list of external agencies (e.g., State \nImmunization Information Registries) to whom immunization data has been \ntransmitted.\n \nThe data in this file is automatically populated and is not editable by\nthe end-user.\n\n
\nEach entry specifies an endpoint for calling the ICE web service. The URL \nis a calculated field that gets generated based on the other field \nvalues. This file is for use by the PX ICE WEB Remote Procedure Call \n(RPC). If there is more than one entry in this file, then the value to be \nused is specified in the Site Parameter, PX ICE WEB DEFAULT SERVER.\n\n
\nThis file is used to control the status of the ICE interface. There should\nonly be one entry in this file.\n\n
\nThis file stores the template elements which are used to construct a SOAP\nnecessary to process the word-processing windows (i.e., |X|), and can\ncontrol if an element should be skipped in its entirety.\n \nNote: When adding or editing an entry in this file, be aware that when \nediting the content fields (i.e., pre-content, content, and \npost-content), that spaces (i.e., " ") matter! When generating the XML \nSOAP message, the lines will be concatenated together, and there are \ntimes where you must leave a space at the end of the line in order for \nit to be valid XML when the lines are concatenated.\n \nmessage to the Immunization Calculation Engine (ICE) server. It is meant\nThis file should not be edited locally by the site.\nto mimic a tree-structure. Each entry in this file represents an element\n(or node) in the tree and can have a parent and sibling elements. The\nmessage is built starting with the root element. The pre-content and\ncontent is then added to the message, followed by the children elements,\nand finally the post-content is added. This is done recursively for all\nthe descendants. Before processing an element, the BUILD LOGIC of that\nelement is executed, and that can be used to set up the variables\n\n
\n This file contains medical journals which provides references for various\nBacteriology articles. These articles offer the user of the laboratory\npackage addition information concerning possible issues relating to patient\ncare treatment plans or departmental procedure guidelines.\n\n
\nThis file stores information and status of lab data archiving activities.\n\n
\nPer VHA Directive, this file has been 'locked down' by Data \nThe LAB LOINC file contains an extraction of the LOINC database. The\nLOINC database provides sets of universal names and ID codes for\nidentifying laboratory and clinical test results. The LAB LOINC file is\nused to map the Laboratory WKLD CODE file(#64), also known as the National\nLaboratory Test file, to LOINC codes.\n \nThis file is a standard file distributed by Dallas CIOFO and should\nnot be edited locally.\n \nLOINC Copyright acknowledgement\nStandardization (DS). The file definition (i.e. data dictionary) shall \n \n1995-2015, Regenstrief Institute, Inc. and the Logical Observation \nIdentifiers Names and Codes (LOINC) Committee. All rights reserved.\nLOINC is a trademark of the Regenstrief Institute.\n \nLOINC\nc/o Regenstrief Institute\n1001 West 10th. Street, RHC-5\nIndianapolis, Indiana 46202 USA\n \nnot be modified. All additions, changes and deprecation to entries in \nThe Department of Veterans Affairs abides by all copyright restrictions,\ncondition and LOINC code use.\n \nPermission was granted, without written agreement and without license or\nroyalty fees, to use, copy, or distribute the LOINC codes, LOINC User's\nGuide, and the contents of the LOINC database for any purpose, so long as\nthis copyright notice appears on any copies of the LOINC database and\nUsers' Guide, and that the following conditions are met.\n \nThe Department of Veterans Affairs agrees to the following conditions:\nthis file shall be done by Enterprise Reference Terminology (ERT) using \n \n1. Will not change the meanings of any of the LOINC codes.\n \n2. Will not change any content in the defined LOINC fields.\n \n3. Will include this notice of copyright and terms in any copies of the\n LOINC database distributed.\n \n4. If new records are added to the LOINC database as distributed to deal\n with local requirements, these records will be assigned a LOINC code\nthe Master File Server (MFS), provided by the Common Services (CS). \n containing a leading alphabetic "X" so that the new term cannot be\n confused with new LOINC codes as they are assigned by the LOINC \n committee.\n \n5. Incorporation of any part of the LOINC database into another laboratory\n test definition database for distribution outside of their corporation\n must include the LOINC code (field #1) all six names fields (#2-7), the\n related terms field (#8), and the answer list field (#19), and include\n this copyright notice on the electronic document that incorporates the\n LOINC database.\nCreating and/or editing locally defined fields in the file are not \n \nRegenstrief Institute and members of the LOINC Consortium do not accept\nliability for any omissions or errors in the LOINC database, and all \nEXPRESS AND IMPLIED WARRANTIES, INCLUDING THOSE RELATED TO MERCHANTABILITY\nOR FITNESS FOR A PARTICULAR PURPOSE, ARE DISCLAIMED.\npermitted. Use of locally defined fields that were created prior to \nthe VHA's effective Directive shall not be supported.\n \n\n
\nThis file contains the name of the component or analyte measured for the \nLAB LOINC file (#95.3). This file is a standard file distributed\nby Dallas CIOFO and should not be edited locally.\n\n
\nThis file is used to transport STS mapping to target sites for \ninstallation by the laboratory auto mapping software.\n\n
\nThis file is used to assign Local ICNs (Integration Control Numbers) when\nthe Master Patient Index (MPI) is unavailable.\n\n
\nThis file is used to calculate the check digit (check sum) for an ICN\n(Integration Control Number).\n\n
\nThis file is used to track the MPI Initialization process. It is utilized\nwhen stopping and restarting the initialization process.\n\n
\nThis file holds all requests for change a patient's CIRN Master of Record.\nRequests being sent to remote locations and received from remote\nlocations are stored in this file and updated.\n\n
\nThe purpose of this file is to track admissions and discharges of Active \n \nIn the case of admission and discharge occurring in the same collection \nperiod there will only be one entry. In the case that a discharge occurs \nin a subsequent collection period there will be a second entry. Entries \nare dinum to the Patient Movement file (#405)\n \nEntries into this file should NOT be done manually.\nThe option WII REVIEW ADT EVENTS WILL utilizes List Manager to allow a \npoint of contact at the local facility to approve entries for \ntransmission or just the opposite block transmission.\nduty Veterans and to facilitate the notification of these movements to \nthe DOD. This file is populated by the weekly back ground job [WII BUILD \nADT EVENTS]. In order for a patient to be in this file, the veteran must \nhave one of three eligibilities entered in the Patient File (#2). TRICARE \n, SHARING AGREEMENT or OTHER FEDERAL AGENCY. \n \nEntries that have a status of approved to transmit will be sent to the \nVISN for review and then roll up to the DOD. \n\n
\nThe WII PARAMETERS file (#987.6) is a parameter file that controls what \nmail group notices are sent to and the mail server address of the central\ncollection site. This file is populated with patch WII*1.0*1 and should\nnot be edited at the local facility.\n\n
\nFile contains portions of a patient's general clinical data.\n \nFields annotated with an "*" are scheduled for deletion from\nthis file.\n\n
\nThis file contains settable parameters that control the behavior of various \ncomponents of the CIRN Object Repository.\n\n
\nThis is the CIRN HL7 EXCEPTION LOG file (#991.1), used\nfor tracking CIRN HL7 exception information.\n\n
\nThis file holds the CIRN HL7 exception types. It is pointed to by\nthe TYPE field (#2) for the EXCEPTION subfield (#991.12) of the CIRN\nHL7 EXCEPTION LOG file (#991.1).\n\n
\nFile to store generic site parameters for the Master Patient Index/\nPatient Demographic (MPI/PD) package. Only one entry (entry number 1)\nshould exist in this file.\n\n
\nThis file holds definitions of CIRN events that occur. When an event\noccurs, and entry is placed into a queue and is associated with\nan entry in this file. This file will determine how the event\nis processed (i.e., the routine to call to process the event and\nrelated HL7 Protocol).\n \nSince each event type is placed on it's on queue, this file also\ndetermines characteristics of the queue itself.\n\n
\nIf a soft-error or hard-error occurs while processing a CIRN event,\nan entry is placed in this file and the event is removed from the\nactive queue.\n \nThis file holds all necessary information to research the error and\nto re-process the event after the error-condition is corrected.\n\n
\nFor each event association (or event type) statistics are automatically\nstore each time the event is triggered. Statistics are grouped by date and\nevent type.\n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis file is a table of immunization and/or vaccine manufacturers. The\ndata in this file are derived from the CDC (Center for Disease Control)\nHL7 Table 0227 (Manufacturers of Vaccines (MVX)).\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nThis file contains the IHS Standard Facilities and their Associated codes,\nnot be made. Monthly updates (if required) are provided by the IHS DBA\nthru the patch module.\nCHS Vendors, pointers to their respective service units and areas, a 2-4\ncharacter abbreviation, and the highest medical record number assigned by\nthat facility.\n \nChanges to this data dictionary should be coordinated thru the IHS DBA.\n \nThis file reflects entries in the IHS Standard Code Book, section VIII-C\nArea - Service Unit - Facility. Local additions or modifications should\n\n
\nThis file defines education topics.\n\nEducation topics that are not to be used should be marked "Inactive" in the\nActive Status field.\n \nChanges to this data dictionary should be coordinated thru the IHS DBA.\n \nA x-ref on the MNEMONIC field was added to version 93.2.\n\n\n
\nPer VHA Directive, this file has been "locked down" by Data \nIn order to preserve the continuity of files shared by the Indian Health\nService and the Department of Veterans Affairs, this file includes\nfields used by Indian Health Service that will not be used by the\nDepartment of Veterans Affairs. These fields may point to other files\nand routines not deployed by the Department of Veterans Affairs.\nInclusion of these fields, as designed, was approved by the DBA. These\nfields were initially introduced with the release of the VISTA\nIMMUNIZATION ENHANCEMENTS 1.0 (PX*1*201) for the VistA Immunization\nEnhancements Project. Additional fields may be included in later\nenhancements.\nStandardization (DS). The file definition (i.e. data dictionary) shall \n \nThis file is a list of Immunizations and associated codes developed\nspecifically for use in the IHS. This file contains a full descriptive \nname for each Immunization, plus a shortened name of Ten Characters \nwhich is used on the Health Summary and on reports where space is \nlimited, plus a Two Digit Code for each Immunization.\nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nThis file is a list of Physical Exams that have been defined specifically\nfor use in entering Examinations performed on an Outpatient or Inpatient\nEncounter. \n \nThis file was developed by IHS and adopted by the VA. \n\n
\nThis file is a table with site defined Treatment names. These are names\nof treatments that are not covered in the ICD-CM Procedures or the CPT\nProcedures. Examples may include treatments such as Ear Irrigation, or \nInstructions or Counseling given to a patient for a Medical Problem.\n \nWhen the treatment names are associated with a patients visit, they are\nfor clinical use and do not contribute to billing and workload because of\nthe lack of a coded CPT or ICD-CM.\n\n
\nThis file contains each unique POV NARRATIVE QUALIFIER.\n \n\n\n
\nPer VHA Directive, this file has been "locked down" by Data \nThis file contains Skin Tests. It consists of a full descriptive name,\na Ten Character Abbreviated Name for the Health Summary and other\nreports where spaces are limited, plus a Two Digit Code (IHS only).\n \nThis file was developed by IHS, and adopted by the VA for the source \nfile representing Skin Tests.\nStandardization (DS). The file definition (i.e. data dictionary) shall \nnot be modified. All additions, changes and deletions to entries in the\nfile shall be done by Enterprise Reference Terminology (ERT) using the\nMaster File Server (MFS), provided by the Common Services (CS). Creating\nand/or editing locally defined fields in the file are not permitted. Use\nof locally defined fields that were created prior to the VHA Directive\nshall not be supported.\n \n\n
\nIn order to preserve the continuity of files shared by the Indian Health \n \nThis file contains the Immunization Manufacturers' LOT NUMBERS for the \nimmunizations/vaccines administered in the VA. The LOT NUMBERs themselves\nmay not be unique, but the combination of LOT NUMBER and MANUFACTURER\nmust form a unique entry. This file also relies on a nightly background\ntask that checks the entries' EXPIRATION DATE field. If the date is equal\nto that day's date, or has passed, that entry's STATUS is set to EXPIRED.\nService and the Department of Veterans Affairs, this file includes fields \nused by Indian Health Service that will not be used by the Department of \nVeterans Affairs. These fields may point to other files and routines not \ndeployed by the Department of Veterans Affairs. Inclusion of these fields, \nas designed, was approved by the DBA. These fields were initially \nintroduced with the release of the VISTA IMMUNIZATION ENHANCEMENTS 1.0 \n(PX*1*201) for the VistA Immunization Enhancements Project. Additional \nfields may be included in later enhancements. \n\n
\nThis file defines health factors. Note that there are two types of entries\n\nChanges to this data dictionary should be coordinated thru the IHS DBA.\n\nas defined by the field Entry Type, they are factor and category. Every entry\nthat is a factor must belong to a category. Category type entries should never\nbe given to a patient.\n\nWhen defining a new health factor, you should always create a Description that\nincludes its purpose and use and the concept that it represents. It is also\ngood practice to add a Print Name, which is used for display purposes in health\nsummaries and Clinical Reminders.\n\n