2 Patient Administration for Pathology
- Former user (Deleted)
- Former user (Deleted)
- Former user (Deleted)
2.1 Message Control Segments
The following segments are necessary to support the functionality described in this chapter.
If a value is the usual default for use in Australia it has been highlighted in blue.
Figure 2-1. HL7 message segments
Segment Name | HL7 Section Reference |
|---|---|
| BHS | 2.1.2 |
| BTS | 2.1.3 |
| DSC | 2.1.4 |
| ERR | 2.1.5 |
| FHS | 2.1.6 |
| FTS | 2.1.7 |
| MSA | 2.1.8 |
| MSH | 2.1.9 |
2.1.2 BHS - batch header segment
The BHS segment defines the start of a batch.
HL7 Attribute Table - BHS – Batch Header
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 1 | ST | R | 00081 | Batch Field Separator | ||
| 2 | 3 | ST | R | 00082 | Batch Encoding Characters | ||
| 3 | 15 | ST | O | 00083 | Batch Sending Application | ||
| 4 | 20 | ST | O | 00084 | Batch Sending Facility | ||
| 5 | 15 | ST | O | 00085 | Batch Receiving Application | ||
| 6 | 20 | ST | O | 00086 | Batch Receiving Facility | ||
| 7 | 26 | TS | O | 00087 | Batch Creation Date/Time | ||
| 8 | 40 | ST | O | 00088 | Batch Security | ||
| 9 | 20 | ST | O | 00089 | Batch Name/ID/Type | ||
| 10 | 80 | ST | O | 00090 | Batch Comment | ||
| 11 | 20 | ST | O | 00091 | Batch Control ID | ||
| 12 | 20 | ST | O | 00092 | Reference Batch Control ID |
2.1.2.0 BHS field definitions
2.1.2.1 BHS-1 Batch field separator (ST) 00081
Definition: This field contains the separator between the segment ID and the first real field, BHS-2-batch encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is |,(ASCII 124).
2.1.2.2 BHS-2 Batch encoding characters (ST) 00082
Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape characters, and subcomponent separator. Australian values are ^~\& (ASCII 94,126, 92, and 38, respectively).
2.1.2.3 BHS-3 Batch sending application (ST) 00083
Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.
2.1.2.4 BHS-4 Batch sending facility (ST) 00084
Definition: This field contains the address of one of several occurrences of the same application within the sending system. Absent other considerations, the Medicare Provider ID might be used with an appropriate sub-identifier in the second component. Entirely user-defined.
2.1.2.5 BHS-5 Batch receiving application (ST) 00085
Definition: This field uniquely identifies the receiving applications among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.
2.1.2.6 BHS-6 Batch receiving facility (ST) 00086
Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. See comments BHS-4-batch sending facility. Entirely site-defined.
2.1.2.7 BHS-7 Batch creation date/time (TS) 00087
Definition: This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.
2.1.2.8 BHS-8 Batch security (ST) 00088
Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified.
2.1.2.9 BHS-9 Batch name/ID/type (ST) 00089
Definition: This field can be used by the application processing the batch. It can have extra components if needed.
2.1.2.10 BHS-10 Batch comment (ST) 00090
Definition: This field is a comment field that is not further defined in the HL7 protocol.
2.1.2.11 BHS-11 Batch control ID (ST) 00091
Definition: This field is used to uniquely identify a particular batch. It can be echoed back in BHS-12-reference batch control ID if an answering batch is needed.
2.1.2.12 BHS-12 Reference batch control ID (ST) 00092
Definition: This field contains the value of BHS-11-batch control ID when this batch was originally transmitted.
Not present if this batch is being sent for the first time. See definition for BHS-11-batch control ID.
2.1.3 BTS - batch trailer segment
The BTS segment defines the end of a batch.
2.1.3.0 BTS field definitions
HL7 Attribute Table - BTS – Batch Trailer
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 10 | ST | O | 00093 | Batch Message Count | ||
| 2 | 80 | ST | O | 00090 | Batch Comment | ||
| 3 | 100 | NM | O | Y | 00095 | Batch Totals |
2.1.3.1 BTS-1 Batch message count (ST) 00093
Definition: This field contains the count of the individual messages contained within the batch.
2.1.3.2 BTS-2 Batch comment (ST) 00090
Definition: This field is a comment field that is not further defined in the HL7 protocol.
2.1.3.3 BTS-3 Batch totals (NM) 00095
Definition: We encourage new users of this field to use the HL7 Version 2.3 data type of NM and to define it as “repeating.” This field contains the batch total. Only a single Batch is allowed in Australia.
This field may be defined as a CM data type for backward compatibility with HL7 Versions 2.2 and 2.1with each total being carried as a separate component. Each component in this case is an NM data type.
2.1.4 DSC - continuation pointer segment
The DSC segment is used in the continuation protocol.
2.1.4.0 DSC field definitions
HL7 Attribute Table - DSC – Continuation Pointer
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 180 | ST | O | 00014 | Continuation Pointer | ||
| 2 | 1 | ID | O | 0398 | 01354 | Continuation Style |
2.1.4.1 DSC-1 Continuation pointer (ST) 00014
Definition: This field contains the continuation pointer. In an initial query, this field is not present. If the responder returns a value of null or not present, then there is no more data to fulfill any future continuation requests. For use with continuations of unsolicited messages, see HL7 International Standard chapter 5 and section 2.15.2, "Continuation messages and segments.” Note that continuation protocols work with both display- and record-oriented messages.
2.1.4.2 DSC-2 Continuation style (ID) 01354
Definition: Indicates whether this is a fragmented message (see HL7 International Standard Section 2.15.2, "Continuation messages and segments"), or if it is part of an interactive continuation message (see HL7 International Standard Section 5.6.3, "Interactive continuation of response messages").
Refer to HL7 Table 0398 – Continuation style code for valid values.
HL7 Table 0398 - Continuation style code
| Value | Description |
|---|---|
| F | Fragmentation |
| I | Interactive Continuation |
2.1.5 ERR - error segment
The ERR segment is used to add error comments to acknowledgment messages.
HL7 Attribute Table - ERR –Error
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 80 | CM | R | Y | 00024 | Error Code and Location |
2.1.5.0 ERR field definition
2.1.5.1 ERR-1 Error code and location (CM) 00024
Components: <segment ID (ST)> ^ <sequence (NM)> ^ <field position (NM)> ^ <code identifying error (CE)>
Definition: This field identifies an erroneous segment in another message. The second component is an index if there is more than one segment of type <segment ID>. For systems that do not use the HL7 Encoding Rules, the data item number may be used for the third component. The fourth component (which references HL7 Table 0357 - Message error condition codes, (as a CE data type) is restricted from having any subcomponents as the subcomponent separator is now the CE’s component separator.
2.1.6 FHS - file header segment
The FHS segment is used to head a file as defined in Overview.
HL7 Attribute Table - FHS - File Header
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 1 | ST | R | 00067 | File Field Separator | ||
| 2 | 4 | ST | R | 00068 | File Encoding Characters | ||
| 3 | 15 | ST | O | 00069 | File Sending Application | ||
| 4 | 20 | ST | O | 00070 | File Sending Facility | ||
| 5 | 15 | ST | O | 00071 | File Receiving Application | ||
| 6 | 20 | ST | O | 00072 | File Receiving Facility | ||
| 7 | 26 | TS | O | 00073 | File Creation Date/Time | ||
| 8 | 40 | ST | O | 00074 | File Security | ||
| 9 | 20 | ST | O | 00075 | File Name/ID | ||
| 10 | 80 | ST | O | 00076 | File Header Comment | ||
| 11 | 20 | ST | O | 00077 | File Control ID | ||
| 12 | 20 | ST | O | 00078 | Reference File Control ID |
2.1.6.0 FHS field definitions
2.1.6.1 FHS-1 File field separator (ST) 00067
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.2 FHS-2 File encoding characters (ST) 00068
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.3 FHS-3 File sending application (ST) 00069
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.4 FHS-4 File sending facility (ST) 00070
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.5 FHS-5 File receiving application (ST) 00071
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.6 FHS-6 File receiving facility (ST) 00072
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.7 FHS-7 File creation date/time (TS) 00073
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.8 FHS-8 File security (ST) 00074
Definition: This field has the same definition as the corresponding field in the MSH segment.
2.1.6.9 FHS-9 File name/ID (ST) 00075
Definition: This field can be used by the application processing file. Its use is not further specified.
2.1.6.10 FHS-10 File header comment (ST) 00076
Definition: This field contains the free text field, the use of which is not further specified.
2.1.6.11 FHS-11 File control ID (ST) 00077
Definition: This field is used to identify a particular file uniquely. It can be echoed back in FHS-12-reference file control ID.
2.1.6.12 FHS-12 Reference file control ID (ST) 00078
Definition: This field contains the value of FHS-11-file control ID when this file was originally transmitted.
Not present if this file is being transmitted for the first time.
2.1.7 FTS - file trailer segment
The FTS segment defines the end of a file.
HL7 Attribute Table - FTS - File Trailer
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 10 | NM | O | 00079 | File Batch Count | ||
| 2 | 80 | ST | O | 00080 | File Trailer Comment |
2.1.7.0 FTS field definitions
2.1.7.1 FTS-1 File batch count (NM) 00079
Definition: This field contains the number of batches contained in this file. In Australia there is a maximum of 1 batch in a file.
2.1.7.2 FTS-2 File trailer comment (ST) 00080
Definition: The use of this free text field is not further specified.
2.1.8 MSA - message acknowledgment segment
The MSA segment contains information sent while acknowledging another message.
HL7 Attribute Table - MSA - Message Acknowledgment
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 2 | ID | R | 0008 | 00018 | Acknowledgment Code | |
| 2 | 20 | ST | R | 00010 | Message Control ID | ||
| 3 | 80 | ST | O | 00020 | Text Message | ||
| 4 | 15 | NM | O | 00021 | Expected Sequence Number | ||
| 5 | 1 | ID | B | 0102 | 00022 | Delayed Acknowledgment Type | |
| 6 | 250 | CE | O | 0357 | 00023 | Error Condition |
The sending system must return the Message Control ID from the received message in the MSA segment.
2.1.8.0 MSA field definitions
2.1.8.1 MSA-1 Acknowledgment code (ID) 00018
Definition: This field contains an acknowledgment code, see message processing rules. Refer to HL7 Table 0008 - Acknowledgment code for valid values.
HL7 Table 0008 - Acknowledgment code
| Value | Description |
|---|---|
| AA | Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept |
| AE | Original mode: Application Error - Enhanced mode: Application acknowledgment: Error |
| AR | Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject |
| CA | Enhanced mode: Accept acknowledgment: Commit Accept |
| CE | Enhanced mode: Accept acknowledgment: Commit Error |
| CR | Enhanced mode: Accept acknowledgment: Commit Reject |
2.1.8.2 MSA-2 Message control ID (ST) 00010
Definition: This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended.
2.1.8.3 MSA-3 Text message (ST) 00020
Definition: This optional field further describes an error condition. This text may be printed in error logs or presented to an end user.
Use of MSA-3-text message and MSA-6-error condition are deprecated in favor of ERR-1-Error code and location. The ERR segment allows for richer descriptions of the erroneous conditions.
2.1.8.4 MSA-4 Expected sequence number (NM) 00021
Definition: This optional numeric field is used in the sequence number protocol.
2.1.8.5 MSA-5 Delayed acknowledgment type (ID) 00022
Definition: This field has been retained for backward compatibility. This field is used only as described above, in the HL7 International Standard Section 2.13.2, “Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only).” Otherwise this field is not used.
HL7 Table 0102 - Delayed acknowledgment type
| Value | Description |
|---|---|
| D | Message received, stored for later processing |
| F | acknowledgment after processing |
2.1.8.6 MSA-6 Error condition (CE) 00023
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field allows the acknowledging system to use a user-defined error code to further specify AR or AE type acknowledgments. This field is a generalized replacement for MSA-3-text message .
Use of MSA-3-text message and MSA-6-error condition are deprecated in favor of ERR-1 -Error code and location. The ERR segment allows for richer descriptions of the erroneous conditions.
The Message Error Condition codes are defined by HL7 Table 0357 - Message error condition codes.
HL7 Table 0357 - Message error condition codes
| Error Condition Code | Error Condition Text | Description/Comment |
|---|---|---|
| Success | ||
| 0 | Message accepted | Success. Optional, as the AA conveys success. Used for systems that must always return a status code. |
| Errors | ||
| 100 | Segment sequence error | The message segments were not in the proper order, or required segments are missing. |
| 101 | Required field missing | A required field is missing from a segment |
| 102 | Data type error | The field contained data of the wrong data type, e.g. an NM field contained "FOO". |
| 103 | Table value not found | A field of data type ID or IS was compared against the corresponding table, and no match was found. |
| Rejection | ||
| 200 | Unsupported message type | The Message Type is not supported. |
| 201 | Unsupported event code | The Event Code is not supported. |
| 202 | Unsupported processing id | The Processing ID is not supported. |
| 203 | Unsupported version id | The Version ID is not supported. |
| 204 | Unknown key identifier | The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a non-existent patient. |
| 205 | Duplicate key identifier | The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.). |
| 206 | Application record locked | The transaction could not be performed at the application storage level, e.g. database locked. |
| 207 | Application internal error | A catchall for internal errors not explicitly covered by other codes. |
2.1.9 MSH - message header segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.
HL7 Attribute Table - MSH - Message Header
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 1 | ST | R | 00001 | Field Separator | ||
| 2 | 4 | ST | R | 00002 | Encoding Characters | ||
| 3 | 180 | HD | O | 0361 | 00003 | Sending Application | |
| 4 | 180 | HD | O | 0362 | 00004 | Sending Facility | |
| 5 | 180 | HD | O | 0361 | 00005 | Receiving Application | |
| 6 | 180 | HD | O | 0362 | 00006 | Receiving Facility | |
| 7 | 26 | TS | R | 00007 | Date/Time Of Message | ||
| 8 | 40 | ST | O | 00008 | Security | ||
| 9 | 15† | CM | R | 0076 / 0003 | 00009 | Message Type | |
| 10 | 199†† | ST | R | 00010 | Message Control ID | ||
| 11 | 3 | PT | R | 00011 | Processing ID | ||
| 12 | 250†††† | VID | R | 0104 | 00012 | Version ID | |
| 13 | 15 | NM | O | 00013 | Sequence Number | ||
| 14 | 180 | ST | O | 00014 | Continuation Pointer | ||
| 15 | 2 | ID | R††† | 0155 | 00015 | Accept Acknowledgment Type | |
| 16 | 2 | ID | R††† | 0155 | 00016 | Application Acknowledgment Type | |
| 17 | 3 | ID | R††† | 0399 | 00017 | Country Code | |
| 18 | 16 | ID | O | N†††††† | 0211 | 00692 | Character Set |
| 19 | 250 | CE | R††† | 00693 | Principal Language Of Message | ||
| 20 | 20 | ID | O | 0356 | 01317 | Alternate Character Set Handling Scheme | |
| 21 | 10 | ID | O | Y | 0449 | 01598 | Conformance Statement ID |
| 22 | Reserved | ||||||
| 23 | Reserved | ||||||
| 24 | Reserved | ||||||
| 25 | Reserved | ||||||
| 26 | Reserved | ||||||
| 27 | 250††††† | CWE | O | Y | 02430 | Security Handling Instructions |
† Australian variation to HL7 V2.4 with the length changed from 13 to 15 characters.
†† Australian variation to HL7 V2.4 with the length changed from 20 to 199 characters to accommodate a globally unique identifier. This has been pre-adopted from HL72.6-2.9.
†††Australian variation to HL7 V2.4, field optionality has been changed to required.
††††Australian variation to HL7 V2.4 with the length changed from 60 to 250 characters.
††††† Australian variation to HL7 V2.4, field is pre-adopted from HL7 International v2.9. Length of 250 has been set consistent with the CWE length specified in section 3.6 CWE – coded with exceptions.
†††††† Australian variation to HL7 V2.4, field repeat is disallowed.
2.1.9.0 MSH field definitions
2.1.9.1 MSH-1 Field separator (ST) 00001
Definition: This field contains the separator between the segment ID and the first real field, MSH-2-encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is |, (ASCII 124).
2.1.9.2 MSH-2 Encoding characters (ST) 00002
Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. Recommended values are ^~\& (ASCII 94,126, 92, and 38, respectively). In the Australian context the separators are fixed to these values.
2.1.9.3 MSH-3 Sending application (HD) 00003
Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.
User-defined Table 0361-Sending/receiving application is used as the user-defined table of values for the first component.
User-defined Table 0361 – Sending/receiving application
| Value | Description |
|---|---|
| MERIDIAN^MERIDIAN:3.1.4 (Build 6934) [win32-i386]^L | Example application identifier |
| Best Practice 1.8.5.743 | Application identifier with only namespace ID valued |
| PRSLT^HL7PIT^L | Example Lab Sending application |
Note: By site agreement, implementors may continue to use User-defined Table 0300 - Namespace ID for the first component.
2.1.9.4 MSH-4 Sending facility (HD) 00004
Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Definition: This field further describes the sending application, MSH-3-sending application . With the promotion of this field to an HD data type, the usage has been broadened to include not just the sending facility but other organizational entities such as a) the organizational entity responsible for sending application; b) the responsible unit; c) a product or vendor’s identifier, etc. Entirely site-defined.
User-defined Table 0362 - Sending/receiving facility is used as the HL7 identifier for the user-defined table of values for the first component.
User-defined Table 0362 – Sending/receiving facility
| Value | Description |
|---|---|
| Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID | Example sending facility identified with GUID |
| QML^2184^AUSNATA | Lab example using AUSNATA as coding scheme |
Note: By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first component.
2.1.9.5 MSH-5 Receiving application (HD) 00005
Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Definition: This field uniquely identifies the receiving application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined. User-defined Table 0361- Sending/receiving application is used as the HL7 identifier for the user-defined table of values for the first component.
Note: By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first component.
2.1.9.6 MSH-6 Receiving facility (HD) 00006
Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations.
User-defined Table 0362 - Sending/receiving facility is used as the HL7 identifier for the user-defined table of values for the first component. Entirely site-defined.
Note: By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first component.
2.1.9.7 MSH-7 Date/time of message (TS) 00007
Definition: This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.
Note: This field was made required in version 2.4. Messages with versions prior to 2.4 are not required to value this field. This usage supports backward compatibility.
2.1.9.8 MSH-8 Security (ST) 00008
Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified.
2.1.9.9 MSH-9 Message type (CM) 00009
Components: <message type (ID)> ^ <trigger event (ID)> ^ <message structure (ID)>
Definition: This field contains the message type, trigger event, and the message structure ID for the message.
The first component is the message type code defined by HL7 Table 0076 - Message type. This table contains values such as ACK, ADT, ORM, ORU etc. See HL7 International Standard section 2.17.1 for complete listing.
The second component is the trigger event code defined by HL7 Table 0003 - Event type. This table contains values like A01, O01, R01 etc. See HL7 International Standard section 2.17.2 for a complete listing
The third component is the abstract message structure code defined by HL7 Table 0354 - Message structure.
This table has two columns. The first column contains the value of this code, which describes a particular HL7 “abstract message structure definition” in terms of segments, as defined in HL7 International Standard sections 2.12, “CHAPTER FORMATS FOR DEFINING HL7 MESSAGES” and 2.12.1, “HL7 abstract message syntax example”. The second column of table 0354 lists the various HL7 trigger events that use the particular abstract message definition. For example, the message structure code ADT_A01 describes the single abstract message structure used by the trigger events A01, A04, A05, A08, A13, A14, A28 and A31. See HL7 International Standard section 2.17.3 for a complete listing.
Note: Australian variation to HL7 V2.4 with the length changed from 13 to 15 characters.
2.1.9.10 MSH-10 Message control ID (ST) 00010
Definition: This field contains a number or other identifier that uniquely identifies the message. The receiving system echoes this ID back to the sending system in the Message acknowledgment segment (MSA).
The Message Control ID is not an order number for the request nor is it a specimen identifier used by the pathology provider. It is a unique internal identifier for one specific message originating from a particular site. This internal field in the message will not conflict when messages from different placers/fillers with the same Message Control ID are received. All systems should ensure that their data tables are not keyed uniquely using the value from Message Control ID.
If a patient has one MSH with multiple OBR segments and if there is an error in one result then all results in the message are rejected, not just the OBR with the error. However, when one MSH is sent for each OBR then only the result with the error is rejected.
The recommended format for Message Control ID is a combination of two or three components, including:
1) The first component is to identify the sending facility.
2) The second (optional) component is a date in YYYYMMDD format.
3) The third component is an incremental counter starting at number 1.
The generalised format is:
<sending facility>_<date>.n{nnnnnnn..}
Example:
dhm_20160505.2178
qml_20160915.789
Note: It is not intended for the full AUSNATA form to be used, only the first component of the AUSNATA code.
For placers, they could use their <site code> or <site code>_<date> e.g. px_45678912.25
Note: Australian variation to HL7 V2.4 with the length changed from 20 to 36 characters to accommodate a globally unique identifier (GUID).
2.1.9.11 MSH-11 Processing ID (PT) 00011
Components: <processing ID (ID)> ^ <processing mode (ID)>
Definition: This field is used to decide whether to process the message as defined in HL7 Application (level 7) Processing rules. The first component defines whether the message is part of a production, training, or debugging system (refer to HL7 Table 0103 - Processing ID for valid values). The second component defines whether the message is part of an archival process or an initial load (refer to HL7 Table 0207 - Processing mode for valid values). This allows different priorities to be given to different processing modes. The value used in normal usage is highlighted in blue.
HL7 Table 0103 - Processing ID
| Value | Description |
|---|---|
| D | Debugging |
| P | Production |
| T | Training |
HL7 Table 0207 - Processing mode
| Value | Description |
|---|---|
| A | Archive |
| R | Restore from archive |
| I | Initial load |
| T | Current processing, transmitted at intervals (scheduled or on demand) |
| Not present | Not present (the default, meaning current processing) |
2.1.9.12 MSH-12 Version ID (VID) 00012
Components: <version ID (ID)> ^ <internationalization code (CE)> ^ <internal version ID (CE)>
Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. Beginning with Version 2.3.1, it has two additional “internationalization” components, for use by HL7 international affiliates. The <internationalization code> is CE data type (using the ISO country codes where appropriate) which represents the HL7 affiliate. The <internal version ID> is used if the HL7 Affiliate has more than a single ‘local’ version associated with a single US version. The <internal version ID> has a CE data type, since the table values vary for each HL7 Affiliate.
HL7 Table 0104 —Version ID
| Value | Description | |
|---|---|---|