# | Name | Location | Type | Details | Index | Description |
---|---|---|---|---|---|---|
.01 | configuration(+) | 0;1 | FREE TEXT | B | This field contains the descriptive name for all Lab Messaging configurations. Each external partner that the Lab system exchanges messages with should have an entry in the file, e.g. OERR, Universal Interface. | |
1 | protocol | 0;2 | SET OF CODES | HL7:HEALTH LEVEL SEVEN X12:ANSI X.12 1238:ASTM 1238 1381:ASTM 1381 1394:ASTM 1394 LOCAL:LOCAL | This field should contain the type of messages that are used by this configuration. This field is primarily for documentation. | |
2 | status | 0;3 | SET OF CODES | 1:ACTIVE 0:INACTIVE | This field is used to turn this configuration on or off. | |
3 | grace period for messages | 0;6 | NUMERIC | Grace period determines the number of days that messages for this configuration are kept on the system before purging when the message status is "purgable". If this field is left blank, the system assumes 3 days. These messages are found in the LA7 MESSAGE QUEUE file (#62.49). When messages have status of "error" they remain on the system until their corresponding error message is removed from the XTMP global by a KERNEL cleanup task. The messages then become "purgable". | ||
4 | log errors | 0;4 | SET OF CODES | 0:OFF 1:ON | If turned on, errors or exceptional conditions that occur during message processing are stored in the ^XTMP global for review. To review the log, in programmer mode, type D PRINT^LA7LOG. | |
5 | process in | 1;E1,245 | FREE TEXT | This field is executable MUMPS code. It should contain a call to an application routine that will process the incoming message. For a Universal Interface setup, it should contain the call D QUE^LA7UIIN. | ||
6 | process download | 2;E1,245 | FREE TEXT | This field contains executable MUMPS code. It should contain the call point in a routine that will process building a message to be sent to the receiving system. For a Universal Interface configuration it should contain the call D EN^LA7UID1. | ||
7 | hl7 non-dhcp application | 0;5 | POINTER | 770 | This field is a pointer to the HL7 NON-DHCP APPLICATION PARAMETER file (#770). The field is used by the Universal Interface to create an Health Level Seven message using the Vista HL7 v1.5 package. | |
10 | multiple orders | 0;8 | SET OF CODES | 0:MULTIPLE PATIENTS 1:SINGLE PATIENT 2:SINGLE ORDER | Determines when building a HL7 message if message should contain only one patient/order or multiple patients/orders. Default is multiple patients per message if possible. This allows site to configure message building when communicating with a non-VA system that can not handle a message that has more than one patient in the message. It applies to both order (ORM) and result (ORU) messages. When communicating with a VA facility this field can be left blank (default) or set to 0 - MULTIPLE PATIENTS If the receiving system can only accept one patient per HL7 message then select 1 - SINGLE PATIENT. This will place multiple orders or results for multiple orders in one message but only one patient will be contained in the message. If the receiving system can only accept one order per HL7 message then select 2 - SINGLE ORDER. This will place in the message one order or the results associated with one order for a single patient Note: An order in the VA is considered those tests found on one accession. What the VA considers as an accession other non-VA systems may refer to as an order. | |
11 | interface type | 0;9 | SET OF CODES | 1:LAB UI 10:LEDI 20:POC 21:POCA 30:HDR 40:OCS 99:OTHER | This field determines how and for what purpose this configuration is used. It allows the laboratory software to generate, handle and process messages. LAB UI - Used to identify configurations that are for processing laboratory automated instrument data via a generic interface manager. LEDI - Designate entries involved with Laboratory Electronic Data Interchange (LEDI). Used to identify interfaces involved in the generation, transmission and processing of HL7 order (ORM) and result (ORU) messages involving reference laboratory testing between VistA and other VistA systems, commercial reference laboratories, DoD laboratories and civilian institutions. POC - Point of Care (POC) interface. These interfaces transmit laboratory test results for which there is no pre-existing VistA laboratory order. VistA creates an order as part of result processing and storage. POCA - Point of Care interface that subscribes to HL7 patient demographic (ADT) messages from VistA. Used by POC interfaces that subscribe to patient information from VistA to maintain the POC's patient database. HDR - Designates interface to the VA Health Data Repository (HDR). And those systems which subscribe to VistA Lab HL7 Result (ORU) messages broadcast by VistA when lab results are made available within VistA. Examples are COTS clinical decision support systems. OCS - Order Collection System. Interfaces involved in phlebotomy and other specimen collection systems. Information regarding lab orders and specimen requirement are transmitted to an external system which assists in the specimen collection and updates VistA Lab with information related to the specimen and the related order/accession. OTHER - Designate other non-laboratory interfaces that utilize the Laboratory package. | |
20 | alert condition | 20;0 | MULTIPLE | 62.481 | This field allows the user to identify whether to receive alerts when there are new results, new orders or when an error is logged to the ^XTMP global. | |
30 | non-va order snomed codes | SCT;0 | MULTIPLE | 62.482 | Allows mapping a SNOMED CT code to specimen (topography) and/or collection sample which an external system requires and which is different from the SNOMED CT code assigned to the concept by the Dept of Veterans Affairs. | |
90 | remote system id | 90;0 | MULTIPLE | 62.483 | This field is used to locate the correct configuration in this file when a message is received from a remote system. Most messaging protocols contain information about the system that originated the message and the system that is the destination. Since there can be several senders and receivers, this field can be used to determine the correct receiver by using a special lookup on this field. The Universal Interface utilizes this field in the following manner. The VISTA Health Level Seven (HL7) package requires that every message must have four fields in the message header so that it can determine the application route for the message. Those four fields are called Sending Application, Sending Facility, Receiving Application, and Receiving Facility. The HL7 software must find values for each of these fields in the message within the HL7 package files. The fields must match in the following way. For HL7 v1.5 interfaces Sending Application = the NAME field (#.01) in the HL7 NON-DHCP APPLICATION PARAMETER file (#770) Sending Facility = the NON-DHCP FACILITY NAME field (#3) in File 770 Receiving Application = the NAME field (#.01) in the HL7 APPLICATION PARAMETER file (#771) Receiving Facility = the DHCP STATION NUMBER field (#2) in File 770 For HL7 v1.6 interfaces Sending Application = the NAME field (#.01) in the HL7 APPLICATION PARAMETER file (#771) Sending Facility = the FACILITY NAME field (#3) in File 771 Receiving Application = the NAME field (#.01) in the HL7 APPLICATION PARAMETER file (#771) Receiving Facility = the FACILITY NAME field (#3) in File 771 For the Universal Interface, all four of those fields should be entered into this multiple field, exactly as they are entered in the HL7 fields listed above, including upper and lower case characters. No spaces should be entered between the field values. An example of a Universal Interface value for this field is listed below. LAB INTERFACEInstrument ManagerLA AUTO INST695 Where LAB INTERFACE is the NAME in File 770, Instrument Manager is the NON-DHCP FACILITY NAME in File 770, LA AUTO INST is the NAME in File 771, and 695 is the DHCP STATION NUMBER in File 770. When an HL7 message comes in, these four fields are taken out of the message, concatenated together, and a lookup is done on the "C" cross reference to find this configuration and its associated parameters. The processing routine can then continue to process the data. |