| # | Name | Location | Type | Details | Index | Description |
|---|---|---|---|---|---|---|
| .01 | name | 0;1 | FREE TEXT | B | A unique name, which is preceded by the package namespace. | |
| 1 | item text | 0;2 | FREE TEXT | C | The protocol's text as it appears to the user on the menu or subheader. | |
| 1.1 | synonym | 2;0 | MULTIPLE | 101.02 | This is another name for the protocol that may be used on lookup. | |
| 1.11 | print name | .1;1 | FREE TEXT | This is a shortened version of the item text to be used on print-outs where the name must be abbreviated. | ||
| 2 | disable | 0;3 | FREE TEXT | This field disables use of the protocol when there is text in it. The text should be a short message explaining why use of the protocol has been disabled, as it will be displayed if the protocol is selected. | ||
| 3 | lock | 0;6 | FREE TEXT | This field is used to deny access to users who have this option as part of their menu. If an option has a lock, then only users who hold the matching key can access it. | ||
| 3.5 | description | 1;0 | WORD-PROCESSING | This field contains a brief explanation of the protocol. | ||
| 3.9 | prohibited times | 0;9 | FREE TEXT | This specifies a time range during which this option cannot be accessed. The time should be entered in military format. For example, to prohibit an option from running between 9 AM and 2 PM, enter 0900-1400. | ||
| 4 | type(+) | 0;4 | SET OF CODES | A:action M:menu O:protocol Q:protocol menu L:limited protocol X:extended action D:dialog T:term E:event driver S:subscriber | This field defines the type of protocol to be executed. Types Q, O, and L are strictly related to the 'Add orders' function. Q = Protocol menu - used for displaying and selecting orderable items during the add sequence. When this type of protocol is encountered OE/RR will ask the 'Select PATIENT:,' 'LOCATION:,' 'Provider:' prompts and execute the transaction logic for the new orders screen. This is also true for type O and L. O = Protocol - same as Q but the protocol is the item selected. Protocols are directly executed when encountered. L = Limited protocol - same as O but any existing sub-items are not executed. M = Menu - used for displaying and selecting items. X = Extended action - protocols of this type execute the entry action plus all sub-items. A = Action - same as X but any existing sub-items are not executed. X = Extended action - protocols of this type execute the entry action plus all sub-items. A = Action - same as X but any existing sub-items are not executed. | |
| 5 | creator(+) | 0;5 | POINTER | 200 | This field identifies who created the protocol. | |
| 6 | file link | 5;1 | VARIABLE-POINTER | 19, 60, 62, 61, 71, 62.05, 62.07, 123.5, 123.1 | AE | This field is a variable pointer which may point to the entry in a file to which a protocol is linked. |
| 8 | cost | 5;2 | NUMERIC | This is the cost of filling the order associated with this protocol. | ||
| 10 | item | 10;0 | MULTIPLE | 101.01 | This is the item multiple for a protocol | |
| 12 | package | 0;12 | POINTER | 9.4 | Pointer to Package File (#9.4). | |
| 15 | exit action | 15;E1,245 | FREE TEXT | This field contains MUMPS code which will be executed on leaving this option. It is only applicable to Menu types. | ||
| 20 | entry action | 20;E1,245 | FREE TEXT | This field contains MUMPS code which will be executed on entering this option. It is applicable to Menu and Action types. | ||
| 21 | required variables | 21;0 | MULTIPLE | 101.021 | This lists the variables that must be defined for the proper execution of this protocol. This aids in documenting the protocol. Also, in the case of ';' jumping, the variables defined as required may be newed before jumping, thus preserving the context when returning from the jump. | |
| 24 | screen | 24;E1,245 | FREE TEXT | This field contains MUMPS code that screens out menu items or the execution of particular items in a protocol. Before each item is displayed or executed, the screen is executed and the item is only processed if $T is true. | ||
| 26 | header | 26;E1,245 | FREE TEXT | In the case of menus (type M or Q), this contains MUMPS code that is executed to display a header for the menu. | ||
| 27 | menu help | 27;E1,245 | FREE TEXT | This contains MUMPS code that displays additional help to that already given with the menu. | ||
| 28 | menu prompt | 28;E1,245 | FREE TEXT | This contains text to replace the standard "Select Item: " prompt normally given with a menu. | ||
| 29 | menu default | 29;E1,245 | FREE TEXT | This field contains a default response (i.e., default selection from the menu), if desired. | ||
| 30 | dic {dic} | 30;E1,64 | FREE TEXT | This field is used as the global reference passed to ^DIC for a file look-up. The entry should be in the regular format for a call to ^DIC i.e. ^GL(41, | ||
| 41 | column width | 4;1 | NUMERIC | This is the width, in characters, for each column on a menu. For example, to have 3 columns on an 80 character device, enter a column width of 26. | ||
| 42 | mnemonic width | 4;2 | NUMERIC | This field allows the width allowed for mnemonics to be varied. The default width is 5. | ||
| 43 | path switch | 4;3 | BOOLEAN | Y:YES N:NO | This allows the user, when traversing back UP the tree of protocols, to select a new path back down the tree. In other words, the menu is redisplayed when returning to that menu's level in the tree, and processing back down the tree is possible from that point. If nothing is selected from the menu, the path continues back up the tree. | |
| 44 | identifier | 4;4 | FREE TEXT | Entries into this file can be given identifiers to show context, function and/or relationships. For example, Digoxin may exist in the file as three different entries with identifiers of SERUM, PLASMA and Drug. | ||
| 99 | timestamp | 99;1 | FREE TEXT | This contains the $H time that fields which are necessary to menu display were last changed. | ||
| 100 | *order print action | 100;E1,245 | FREE TEXT | ***NOTICE- THIS FIELD WILL BE REMOVED IN A FUTURE VERSION*** Package action when a detailed listing of an order is requested. Included in this file for backward compatability with earlier versions of OE/RR. | ||
| 100.1 | *order cancel action | 100.1;E1,245 | FREE TEXT | ***NOTICE- THIS FIELD WILL BE REMOVED IN A FUTURE VERSION*** Package action when an order is cancelled or discontinued. Included in this file for backward compatability with earlier versions of OE/RR. | ||
| 100.2 | *order purge action | 100.2;E1,245 | FREE TEXT | ***NOTICE- THIS FIELD WILL BE REMOVED IN A FUTURE VERSION*** Package action when an order is to be purged from file 100. Included in this file for backward compatability with earlier versions of OE/RR. | ||
| 100.3 | access | 3;0 | MULTIPLE | 101.03 | This multiple contains the list of security keys which allow access to the protocol. If there are no keys, all users have access. | |
| 101.01 | requires signature | 101.01;1 | SET OF CODES | 0:PHYSICIAN SIGNATURE 1:NO SIGNATURE REQUIRED | This field is used to specify an orderable/protocol that does not require a physician signature in OE/RR. Some of the things entered in OE/RR are considered instructions and don't require physician signature. An example of this might be an entry for an Early/Late tray. | |
| 101.041 | domain (data type) | 101.04;1 | SET OF CODES | D:date/time F:free text L:list or range N:numeric S:set of codes Y:yes/no P:pointer M:menu W:word processing | This is the data type of a term (i.e. protocol of type term) used in a dialog. | |
| 101.042 | default prompt | 101.04;2 | FREE TEXT | For this term, this is the prompt that is automatically used when the term is used as an item in a dialog. The prompt may be modified at the item level. | ||
| 101.043 | default answer | 101.04;3 | FREE TEXT | For a term protocol, this is the default answer that is automatically used when the term is used as an item in a dialog. The default may be modified at the item level. | ||
| 101.0431 | default word processing answer | 101.0431;0 | WORD-PROCESSING | This is text used as a template for an item in a dialog that is a word processing type. | ||
| 101.044 | default help | 101.04;4 | FREE TEXT | For a term protocol, this is the help text that is automatically used when the term is used as an item in a dialog. The help text may be replaced at the item level. | ||
| 101.045 | domain parameter | 101.04;5 | FREE TEXT | This is a parameter that may be used to further specify the data type (i.e. input transform) for a term protocol. The parameter is what would be placed in the second up-arrow piece of DIR(0) when calling the reader. | ||
| 101.05 | method | 101.05;0 | MULTIPLE | 101.05 | This number identifies individual methods (actions) that may be invoked for this protocol. | |
| 101.07 | set membership | 101.07;0 | MULTIPLE | 101.07 | This is a namespaced name of a set. If this is entered, a cross reference of the format "S.set membership" is created. This allows rapid lookups on subsets of the Protocol file. | |
| 770.1 | sending application | 770;1 | POINTER | 771 | Enter the name of the application that initiates a transaction. It is required only when defining an EVENT POINT protocol. | |
| 770.11 | response message type | 770;11 | POINTER | 771.2 | Enter the message type of the expected RESPONSE. It should only be defined on a SUBSCRIBER PROTOCOL. NOTE: In a contract between the initiating system and the responding system, the Event Driver protocol defines the characteristics of the INITIATING SYSTEM. The Initiating System initiates either queries or unsolicited update messages. A Subscriber Protocol defines the characteristics of the RESPONDING SYSTEM. The responding system completes a transaction by returning either an acknowledgement and/or a response to the specific query message. | |
| 770.14 | batch/file message commit ack | 770;14 | BOOLEAN | 1:YES 0:NO | In a bi-directional interface, this field will be used to determine whether or not a Batch or File message should send or receive a Commit Acknowledgement. A Batch or File message will always send/receive an Application Ack. This feature is non-standard according to HL7. It is needed to insure the receipt of a message. | |
| 770.2 | receiving application | 770;2 | POINTER | 771 | AHL2 | This is the application that receives a message. It is otherwise known as the "responding" application when a transaction takes place. This information is required for SUBSCRIBER protocols only. |
| 770.3 | transaction message type | 770;3 | POINTER | 771.2 | Enter the name of the message type for the the message that is sent from the initiating system. When initiating a new transaction, this field is referenced when generating the header for the outbound message. NOTE: In a contract between the initiating system and the responding system, the Event Driver protocol defines the characteristics of the INITIATING SYSTEM. The Initiating System initiates either queries or unsolicited update messages. A Subscriber Protocol defines the characteristics of the RESPONDING SYSTEM. The responding system completes a transaction by returning either an acknowledgement and/or a response to the specific query message. | |
| 770.4 | event type | 770;4 | POINTER | 779.001 | This is the HL7 Event Type code for the message represented by this protocol. In HL7, the message type and event type of an application response message may be different from the original message. If this is an event point protocol, enter the event type corresponding to the initial message generated by the SENDING APPLICATION. If this is a subscriber protocol, then enter the event type corresponding to the RECEIVING APPLICATION response. Note that an event type is not required when responding with a general acknowledgement (ACK) and the receiving application does not always need to generate a response. NOTE: 1. In "original acknowledgement mode" the receiving application always generates the response. 2. In "enhanced acknowledgement mode" the HL7 package may be configured to produce a "commit ack" before the application receives the message. If the receiving application does not need to generate a response in addition to the ack, then the event type is the same as the original message (and the message type would be ACK) 3. In "enhanced acknowledgement mode with two-phase commit" the HL7 package generates a commit ack, and passes the message to the application. The second phase of the transaction occurs when the application is ready to initiate a response. This is interpreted as the start of a new transaction and may require a commit ack itself. | |
| 770.5 | message structure | 770;5 | POINTER | 779.005 | The message structure is associated with the message type and event type defined by HL7 v2.3.1 and beyond. | |
| 770.6 | processing id | 770;6 | SET OF CODES | D:debug | This field describes how a message should be processed once it is handed off to the receiving application. PROCESSING ID is a required field in the HL7 message header. However, the Event Driver protocol entry is only used whenset to DEBUG. Data for the header is normally derived from the HL COMMUNICATION SERVER FILE. If testing a transaction in Debug mode, make sure it is changed on both the sending and receiving system. The receiving application developer should consider checking this portion of the header before filing data on a production system. Training and Debug messages may not be suitable for filing. | |
| 770.7 | logical link | 770;7 | POINTER | 870 | This field is used with a SUBSCRIBER PROTOCOL to describe the network path to the subscriber. It is most often used with a fixed point-to-point interface between Vista and another system, e.g., a local COTS application or another Vista facility. See the documentation on use of the ROUTING LOGIC field and "dynamic addressing" for more complex routing scenarios. | |
| 770.8 | accept ack code | 770;8 | POINTER | 779.003 | This field defines whether or not a COMMIT ACK will be generated by the HL7 package. This only applies to transactions using version 2.2 and higher of the HL7 Standard. See Chapter 2 of the HL7 Standard for details of Enhanced Mode Acknowledgements. | |
| 770.9 | application ack type | 770;9 | POINTER | 779.003 | For transactions using versions 2.2 and higher of the HL7 standard, this field defines whether or not the receiving application is expected to return an acknowledgement. Enhanced Mode Application Acks are always initiated as a new transaction. The following is an example of a 2-phased acknowledgement over a tcp connection. (A)INITIATING SYSTEM (B)RESPONDING SYSTEM PHASE I Open connection to B send ADT/A04----------------->receive ADT/A04 validate header commit to safe storage receive CA<-------------------send CA to A Close connection PHASE II handoff to receiving Application parse and validate message content generate APPLICATION ACCEPT ACK Open connection to A receive AA<-------------------send AA validate header commit to safe storage send CA to B------------------>receive CA close connection | |
| 770.95 | version id | 770;10 | POINTER | 771.5 | Enter the version of the HL7 standard used to implement this transaction. Note that a screen has been added to insure that the version selected corresponds to the appropriate version of the Message Type defined. | |
| 771 | processing routine | 771;E1,245 | FREE TEXT | This field is executed on the receiving system. It defines the routine used to process the original inbound message in a transaction and to GENERATE and APPLICATION response/ACK back to the sending system using the entry point, GENACK^HLMA1. | ||
| 772 | response processing routine | 772;E1,245 | FREE TEXT | This field is executed on the sending system when an Acknowledgement or Query response is received. The message ID of the original message is always contained within the response. This is used to identify the location of the original message and the corresponding event point protocol. Note that this pertains to Original and Enhanced Mode Application Acks only. The HL7 package generates and processes Enhanced mode Commit Accepts internally. | ||
| 773.1 | sending facility required? | 773;1 | BOOLEAN | 1:YES 0:NO | ||
| 773.2 | receiving facility required? | 773;2 | BOOLEAN | 1:YES 0:NO | ||
| 773.3 | security required? | 773;3 | BOOLEAN | 1:YES 0:NO | ||
| 773.4 | date/time of message required? | 773;4 | BOOLEAN | 1:YES 0:NO | ||
| 773.5 | ack mode set in subscriber | 773;5 | BOOLEAN | 1:YES 0:NO | A 'YES' of this field will indicate that MSH-15 and MSH-16 will be taken from Subscriber protocol instead of the value(s) defined in Event driver protocol. | |
| 774 | routing logic | 774;E1,245 | FREE TEXT | M code in this field is executed only when a message is in an OUTBOUND state. Normally, Vista HL7 'broadcasts' a message to all subscribers whenever a message is generated. However, in some cases, a client may need to receive the message only if it matches a particular condition. This field allows you to set up screening logic to interpret the message and dynamically address the message to those interested in the data when it meets these conditions. The output of your routing logic routine should be the creation of a list of additional message recipients set into the HLL("LINKS") array. For details on dynamic addressing, see the documentation for HL*1.6*14. | ||
| 775 | subscribers | 775;0 | MULTIPLE | 101.0775 |