Table of Contents
...
The following table describes the various attributes used by this guide to document data type attribute tables, message structure attribute tables and segment attribute tables. Not all attributes apply to all attribute tables.
Table 1-1. Message Element AttributesAnchor table1-1 table1-1
Attribute | Definition |
Seq | Sequence of the elements as numbered in the HL7 message element. The Seq attribute applies to the data type attribute table and the segment attribute table. |
Segment | Three-character code for the segment and the abstract syntax (e.g., the square and curly braces). [ XXX ] Optional { XXX } Repeating XXX Required [{ XXX }] Optional and Repeating Note that for segment groups there is no segment code present, but the square and curly braces will still be present. The Segment attribute only applies to the Message attribute table. |
Length | Maximum length of the element. Lengths are provided only for primitive data types. The length attribute applies to data type attribute tables and segment attribute tables. Lengths should be considered recommendations, not absolutes. The receiver can truncate fields, components and sub-components that are longer than the recommended length. The receiver should continue to process a message even when a field, component, or sub-component length exceeds the maximum recommended length identified in this specification. Because the maximum length is that of a single occurrence, the repetition separator is not included in calculating the maximum length (See HL7 International V2.4 Section 2.7.5, “Repetition”). Each occurrence of a repeating field may contain the number of characters specified by the field’s maximum length. (See HL7 International V2.4 Section 2.7.2, “Maximum length.”) |
DT | Data type used by this profile for HL7 element. The data type attribute applies to data type attribute tables and segment attribute tables. |
Usage | Usage of the message element for this profile. Indicates whether the message element (segment, segment group, field, component, or subcomponent) is required, optional, or conditional in the corresponding message element. Usage applies to the message attribute table, data type attribute table and the segment attribute table. See HL7 International standard section C.3.1 – Usage for documentation on how usage has been implemented in this guide. Legal usage values are: R – Required. RE – Required, but can be empty. O – Optional. C – Conditional. CE – Conditional, but may be empty. X – Not used for this profile. - - The hyphen (-) Indicates the profile using the actor does not provide documentation of the structure containing the particular element or does not provide documentation of the particular element in the structure. For instance in a data type specification for CE, if a profile does not provide documentation of the CE data type, then each component of the data type would have a “-“ for the usage for the actor associated with that profile. |
Cardinality | Minimum and maximum number of times the element may appear. [0..0] Element never present. [0..1] Element may be omitted and can have, at most, one occurrence. [1..1] Element must have exactly one occurrence. [0..n] Element may be omitted or may repeat up to n times. [1..n] Element must appear at least once, and may repeat up to n times. [0..*] Element may be omitted or repeat an unlimited number of times. [1..*] Element must appear at least once, and may repeat unlimited number of times. [m..n] Element must appear at least m, and at most, n times. Cardinality applies only to message attribute tables and segment attribute tables. See Section C.3.2 for additional information on how cardinality is handled in this guide. |
Value Set | The set of coded values to be used with the field. The value set attribute applies only to the data type attribute tables and the segment attribute tables. The value set may equate with an entire code system part of a code system, or codes drawn from multiple code systems. Note: Where a table constraint is indicated, or where HL7 Version 2.6 standards are pre-adopted, the constrained or specified HL7 table is included below the data type table. |
Name | HL7 descriptor of the message element. Name applies to the message attribute table, data type attribute table and the segment attribute table. |
Description/Comments | Context and usage for the element. Description/Comments applies to the message attribute table, data type attribute table and the segment attribute table. |
...
The following table provides some recommendations for testing the various usage codes described in the previous table.
| Anchor | ||||
|---|---|---|---|---|
|
Usage | Recommendation |
R – Required | Required elements must be present in a message instance with the following caveats: A required segment, which is contained within a segment group, is required only when the segment group is present in the message. For instance if the segment group is RE, then when the segment group is present, the required segments in that group must be present. A required field in a segment is required only when the segment itself is present in the message. For instance if the segment is CE (conditional or empty) and the conditional predicate is satisfied, then the segment is present in the message and the required fields must be present in the segment. A required component of a data type is required only when the field the data type is associated with is present in the message. Testing of a required element generally involves generating both a fully populated message instance as well as a minimally populated message instance. It may be necessary to generate specific test cases to handle separate segment groups, segments, etc. depending on the usage associated with these higher level elements within a message. |
RE – Required, but can be empty | Since conformant senders must be able to show they can send this data, the primary mechanism for testing the RE usage would involve requiring the sender to transmit a “fully” populated message instance from their application. In this case, the expectation is that the message will be generated by the application, not handcrafted. The message would contain all data the sending application can populate in the message. This generally means the sender would be populating in their application all data elements being tested, including those that are optional in the application. |
O – Optional | Conformance testing for optional elements would not normally be performed. If a particular implementation decides to use an optional element, it should create an implementation specific profile which further constrains this profile, making the optional element either required, required but may be empty, condition or conditional but may be empty, and then test the element in question based upon the assigned usage in that profile. |
C – Conditional | Testing conditional elements generally means a special test case must be developed based upon the specific conditional rule or conditional predicate documented for the element. |
CE – Conditional, but may be empty | Testing conditional but may be empty elements generally means a special test case must be developed based upon the specific conditional rule or conditional predicate documented for the element. |
X – Not used for this profile | Testing this usage code usually involves looking at both fully populated and minimally populated messages. Note that the sending application may collect the data element in question, but it should not communicate that data element in message instances. |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
FHS|^~\&|EQUATORDXTRAY:0.12.8 (Build 310)|1FFA8984-7166-4655-B195-7B4FFFD2F136|||20050417220634+1000 BHS|^~\&|EQUATORDXTRAY:0.12.8 (Build 310)|1FFA8984-7166-4655-B195-7B4FFFD2F136|||20050417220634+1000 MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:0.12.8 (Build 310)^L|Demo Practice^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|||20050417220634+1000||ORU^R01|20050417.736428|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL|AL|AUS PID|1||100333^^^Medical-Objects&7C3E3682-91F6-11D2-8F2C-444553540000&GUID^SR^Demo Practice&1FFA8984-7166-4655-B195-7B4FFFD2F136&GUID||TESTER^Testy^^^Mr^^L||19900101|M|||3 Drury Lane^^NAMBOUR^QLD^4560^AUS^H||61(07)54455055^PRN^PH^^61^07^54455055|||||||||||||||||N PV1|1|O||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|||||||N ORC|RE||E062CF28-A67B-45D6-A5F8-B1423EDFB093^Demo Server^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID||CM|||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN OBR|1||E062CF28-A67B-45D6-A5F8-B1423EDFB093^Demo Practice^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|11486-8^Chemotherapy Record^LN|||20050417+1000|||||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||From Demo Practice in File 20050417.736425 dated 17.04.2005||LN=E062CF28-A67B-45D6-A5F8-B1423EDFB093||200504172206+1000||PHY|C||^^^20050417+1000|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||||0191322W&ANDERSON&THOMAS&&&Dr&&AUSHICPR&AUSHICPR OBX|1|NM|3141-9^Weight^LN||70|kg^^ISO+|||||F OBX|2|NM|28325-9^Performance Status^LN||2||||||F OBX|3|ST|21946-9^Chemotherapy Rx^LN||CHOP||||||F OBX|4|FT|11486-8^^LN||This is a record of chemo being given.\.br\||||||F BTS|1||1 FTS|1 |
1.8 ACKNOWLEDGEMENT PROCESSING
The International HL7 standard specifies two levels of acknowledgement processing: Original and Enhanced Modes.
...
(b) Enhanced mode, The HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments. With a positive accept acknowledgment, the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message. After the message has been processed by the receiving system, an application acknowledgment may be used to return the resultant status to the sending system.
This Australian HL7 standard requires the use of Enhanced Mode Acknowledgment and this is described in 8 Acknowledgement.