Conformance Statements have been developed to help in formulating conformance testing of pathology messaging implementations in Australia against this Implementation Guide. The list below is not exhaustive. The entries are included here primarily if they:-
- are important from a safety or quality perspective, or
- are commonly not correctly implemented, or
- are at variance with the base HL7 v2.4 specifications.locallaly
Conformance of messages to base HL7 2.4 standards is otherwise assumed, and individual conformance tests or test applications may check against the base specification.
The following table indicates whether a conformance statement applies to a message sender, a message receiver, or both. In the case where a conformance statement applies to a message sender, it is expected that automated conformance checking can be carried out on one or more real or sample messages. For testing conformance of receiving implementations, the behaviour of the system must be observed in response to one or more real or sample messages.
The table of conformance statements indicates, for each statement, if it applies to order messages only, result messages only, or both.
Note: For the conformance points, generally the rule is stated first followed by the why. The why may also be referenced in other sections.
Note: HL7au Identifiers in () parenthesis are headings/groupers and not conformance points in themselves.
HL7au Identifier | Applicable to Senders/Receivers/Both | Orders or Results | Conformance point text | Comments |
|---|---|---|---|---|
| HL7au:000001 | Senders/Receivers | Orders | Order addressing - Senders and receivers must ensure an order message is addressed using MSH-6 Receiving facility, as per rules in sub points of HD Datatype conformance heading HL7au:00044.2. | |
HL7au:000001.1 | Receivers | Orders | The system must actively reject an order message where the MSH-6 Recieving Facility does not identify their organisation |
|
| HL7au:000001.2 | Senders | Orders | When using SMD refer to HL7au:000044.2 otherwise; senders should address order messages in MSH-6 Receiving facility using the NATA number if available. | |
| HL7au:000001.2.1 | Senders | Orders | In MSH-6 the namespace ID should contain the registered NATA name for the laboratory as published by NATA ( www.nata.com.au ) | |
| HL7au:000002 | Receivers | Results | The system receiving messages must ensure the received message is adequately identified. (HD component of EI must be valued as well) | |
| HL7au:000003 | Senders | Orders, Results | To ensure the uniqueness of the Entity Identifier (EI) in OBR-2 (Placer Order Number) for a request identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and/or Universal ID (third component) and Universal ID type (4th component) must be populated. | |
| HL7au:000004.1 | Senders | Orders, Results | To ensure the uniqueness of the Entity Identifier (EI) in OBR-3 (Filler Order Number) for a result identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated. | |
| HL7au:000004.2 | Receivers | Orders, Results | Older results with identical Entity Identifier (EI) in OBR-3 (Filler Order Number) to that of a newly received result message (by comparing OBR-22 Rpt/Status Change Date/Time field) should be replaced with the new message, and the older marked as deleted/superseded. | |
| HL7au:000005 | Senders | Orders, Results | To ensure the uniqueness of the Entity Identifier (EI) in ORC-2 (Placer Order Number) for a request identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated. | |
| HL7au:000006 | Receivers | Orders, Results | To ensure the uniqueness of the Entity Identifier (EI) in ORC-3 (Filler Order Number) for a result identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated. | |
| HL7au:000007 | Senders | Orders, Results | To ensure the uniqueness of the Entity Identifier (EI) in ORC-4 (Placer Group Number) for a request identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated. |
|
| (HL7au:000008) | Display Segments | |||
| HL7au:000008 | Senders | Results | The ORU message must contain at least one OBX display segment. |
|
| HL7au:000008.1 | Senders | Results | Display segments must use the appropriate valid values within the AUSPDI coding system in OBX-3 for the content that is represented in it:
| |
| HL7au:000008.1.1 | Receivers | Results | Receivers must be capable of displaying all display formats HTML, PDF, RTF, TXT (HL7 FT), and must provide users access to all of these in an external viewer application in addition to any embedded viewers. | |
| HL7au:000008.1.2 | Senders and Receivers | Results | An OBX display segment is identified using OBX-3 Identifier (CE-1) and Name of Coding System (CE-3) components. The text component of the CE may be blank and only CE1 and CE-3 components need to match. | |
| HL7au:000008.1.3 | Senders and Receivers | Results | In an OBX display segment, the OBX-2 Value Type field must match its corresponding display format specified in OBX-3 Identifier (ST) component as per table Display Format codes in Section 4.5. | |
| HL7au:000008.1.4 | Senders and Receivers | Results | In an OBX display segment, the OBX-3 <name of coding system (IS)> must be valued "AUSPDI". | |
| HL7au:000008.2 | Senders | Results | There must NOT be conflicting content between the OBX display segment and the preceding OBX atomic data. A compliant rendering of the atomic data (if present) should contain the same clinical information. |
|
| (HL7au:000008.2.3) | XHTML Display Segment | |||
| (HL7au:000008.2.3.1) | XHTML Display Segment - Sender | |||
| HL7au:000008.2.3.1.01 | Senders | Results | Any OBX HTML display segments must be valid HTML and conform to the Document Type defined in 'XHTML 1.0 Strict' standard. Refer to http://validator.w3.org/ to validate XHTML content. | |
| HL7au:000008.2.3.1.02 | Senders | Results | All embedded hyperlinks must be secure hyperlinks ie. https:// . That is http:// is disallowed. | |
| HL7au:000008.2.3.1.03 | Senders | Results | Sender must not use external style sheets. Internal style sheets are allowed. Note: external stylesheets are a security risk and could affect presentation of content. | |
| HL7au:000008.2.3.1.04 | Senders | Results | Sender must not use scripts e.g. Javascript etc. Note: active content is not allowed either inline or as external references. | |
| HL7au:000008.2.3.1.05 | Senders | Results | Sender must not use the following elements:
| |
| HL7au:000008.2.3.1.06 | Senders | Results | If there is an image map, senders must have an additional mechanism for communicating that information because there is no obligation on receiving systems to deal with image maps. | |
| HL7au:000008.2.3.1.07 | Senders | Results | Embedded CSS shall conform to the CSS3 specification. | |
| HL7au:000008.2.3.1.08 | Senders | Results | The core display of the report should be encapsulated in a 'div' element of html class ‘reportDisplay’. | |
| HL7au:000008.2.3.1.09 | Senders | Results | Letter head information should be encapsulated in XHTML elements outside of the the scope of the core display of the report identified by 'div' html class 'reportDisplay'. | |
| HL7au:000008.2.3.1.10 | Senders | Results | Letter head images may not be embedded in the html but served externally. | |
| HL7au:000008.2.3.1.11 | Senders | Results | External letter head image sources must not be used, except when used outside a 'div' 'reportDisplay' class html element and only when that 'div' it is present.
| |
| HL7au:000008.2.3.1.12 | Senders | Results | The core report should display in a readable way with the CSS removed. | |
| HL7au:000008.2.3.1.13 | Senders | Results | Information in the core report data should not be hidden by CSS formatting directives. | |
| HL7au:000008.2.3.1.14 | Senders | Results | Image element "src" attributes must use the value "hl7v2://OBX.<setID>" where the setID reference the OBX in the message containing the Encapsulated Data (ED) image or Reference Pointer (RP) to the data, except for images which are a part of a letterhead as per HL7au:000008.2.3.1.10. | |
| HL7au:000008.2.3.1.15 | Senders | Results | External images may be linked from the report body via a clickable link which the user can manually select. | |
| (HL7au:000008.2.3.2) | XHTML Display segment - Receiver | |||
| HL7au:000008.2.3.2.01 | Receivers | Results | HTML display segments must be displayed using a HTML/CSS component that is compliant for rendering of XHTML and CSS3. | |
| HL7au:000008.2.3.2.02 | Receivers | Results | Receiver must support embedded images in XHTML that must be proper URLs suitable for browser use directly, or use the HL7 V2: scheme defined in the HTML Appendix. | |
| HL7au:000008.2.3.2.03 | Receivers | Results | Secure hyperlinks (https://) must be able to be clicked by a user and client application should enable navigation to secure https:// sites . | |
| HL7au:000008.2.3.2.04 | Receivers | Results | Receiving software may filter or disable all embedded javascript. | |
| HL7au:000008.2.3.2.05 | Receivers | Results | Receiving software may suppress objects, iframes, forms with base/link/xlink | |
| HL7au:000008.2.3.2.06 | Receivers | Results | Receiving software may block access to insecure hyperlinks eg file://, http:// | |
| HL7au:000008.2.3.2.07 | Receivers | Results | It should be possible for users in receiving software to selectively hide content outside of the 'div' element of html class ‘reportDisplay’. | |
| HL7au:000008.2.3.2.08 | Receivers | Results | Receiving software should not selectively hide any html when no 'div' element of html class ‘reportDisplay’ is not present in XHTML content. | |
| HL7au:000008.2.3.2.09 | Receivers | Results | XHTML containing images with a source referring back to an RP OBX segment using the 'hl7v2://OBX.<setID>' must be resolved. | |
| HL7au:000008.2.3.2.10 | Receivers | Results | XHTML containing images with a source referring back to an ED OBX segment using the 'hl7v2://OBX.<setID>' must be resolved. | |
| (HL7au:000008.2.4) | PDF Display segment | |||
| (HL7au:000008.2.4.1) | PDF Display segment - Sender | |||
| HL7au:000008.2.4.1.1 | Senders | Results | Documents should be valid according to the PDF/A-1b profile. | |
| HL7au:000008.2.4.1.2 | Senders | Results | Must embed fonts | |
| HL7au:000008.2.4.1.3 | Senders | Results | Must not use encryption/password protection | |
| HL7au:000008.2.4.1.4 | Senders | Results | Must not use PDF Comments | |
| HL7au:000008.2.4.1.5 | Senders | Results | Must not restrict printing. | |
| HL7au:000008.2.4.1.6 | Senders | Results | Must not restrict copying. | |
| HL7au:000008.2.4.1.7 | Senders | Results | May use PDF digital signature | |
| HL7au:000008.2.4.1.8 | Senders | Results | May use PDF restrict changes | |
| HL7au:000008.2.4.1.9 | Senders | Results | May use PDF compression | |
| (HL7au:000008.2.4.2) | PDF Display segment - Receiver | |||
| HL7au:000008.2.4.2.1 | Receivers | Results | Receiver software must display the received PDF with a PDF viewer component. | |
| HL7au:000008.2.4.2.2 | Receivers | Results | Receiver software should be capable of rendering PDF/A-1b content. | |
| HL7au:000008.2.4.2.3 | Receivers | Results | Receiver must support embedded fonts. This is because content is laid out based on font metrics. | |
| HL7au:000008.2.4.2.4 | Receivers | Results | Receiver must support PDF compression. | |
| HL7au:000008.2.4.2.5 | Receivers | Results | Receivers may validate for PDF digital signatures. | |
| HL7au:000008.2.4.2.6 | Receivers | Results | Receiver software must not allow changes to documents in all circumstances. This is irrespective of PDF flags to restrict changes. | |
| (HL7au:000008.2.4.3) | RTF Display segment | |||
| (HL7au:000008.2.4.3.1) | RTF Display segment - Sender | |||
| HL7au:000008.2.4.3.1.1 | Senders | Results | RTF must not contain nested tables (ie. tables inside tables) | |
| HL7au:000008.2.4.3.1.2 | Senders | Results | RTF must not contain active content such as Objected Linking and Embedding Objects (OLE), except with image rendition subject to site-specific negotiation. | |
| HL7au:000008.2.4.3.1.3 | Senders | Results | RTF must not contain embedded fonts | |
| HL7au:000008.2.4.3.1.4 | Senders | Results | RTF must not contain smart shapes/other drawing objects (convert these to PNG images) | |
| HL7au:000008.2.4.3.1.5 | Senders | Results | RTF must not contain smart tags | |
| HL7au:000008.2.4.3.1.6 | Senders | Results | RTF must not contain change tracking markup or comments | |
| HL7au:000008.2.4.3.1.7 | Senders | Results | RTF must not contain section specific page layout | |
| HL7au:000008.2.4.3.1.8 | Senders | Results | RTF must not contain word forms | |
| HL7au:000008.2.4.3.1.9 | Senders | Results | Clinical information must not be presented in Header/footer/cross-references. | |
| HL7au:000008.2.4.3.1.10 | Senders | Results | Branding information may be presented in Header/footer/cross-references. | |
| HL7au:000008.2.4.3.1.11 | Senders | Results | Watermark must not be required to be viewed. | |
| HL7au:000008.2.4.3.1.12 | Senders | Results | All field values are up to date, as fields may not updated, only displayed as text. | |
| (HL7au:000008.2.4.3.2) | RTF Display segment - Receiver | |||
| HL7au:000008.2.4.3.2.01 | Receivers | Results | Receivers must process the \binXXXX control word and skip processing of RTF control words for XXX bytes. | |
| HL7au:000008.2.4.3.2.02 | Receivers | Results | Receivers must support tables, except for nested tables | |
| HL7au:000008.2.4.3.2.03 | Receivers | Results | Receivers must support hyperlinks | |
| HL7au:000008.2.4.3.2.04 | Receivers | Results | Receivers must allow secure https:// hyperlinks to be clickable and navigable into a web browser. | |
| HL7au:000008.2.4.3.2.05 | Receivers | Results | Receivers must support display of RTF embedded bmp, gif, png, jpg, and emf. | |
| HL7au:000008.2.4.3.2.06 | Receivers | Results | Receivers must support display of RTF columns | |
| HL7au:000008.2.4.3.2.07 | Receivers | Results | Receivers must support Lists including bullet and numbers. | |
| HL7au:000008.2.4.3.2.08 | Receivers | Results | Receivers must support display of nested lists with indication of logical nesting. | |
| HL7au:000008.2.4.3.2.09 | Receivers | Results | Display of selected field values. | |
| HL7au:000008.2.4.3.2.10 | Receivers | Results | Receivers may support Header/footer/cross-references | |
| HL7au:000008.2.4.3.2.11 | Receivers | Results | Receivers may support watermarks | |
| HL7au:000008.2.4.3.2.12 | Receivers | Results | Receivers must display field values. | |
| HL7au:000008.2.4.3.2.13 | Receivers | Results | Receivers may not calculate field values. | |
| (HL7au:000008.2.4.4) | FT Display segment | |||
| (HL7au:000008.2.4.4.1) | FT Display segment - Sender | |||
| HL7au:000008.2.4.4.1.01 | Senders | Results | Senders must escape '|' character to the field separator character escape sequence "\F\" | |
| HL7au:000008.2.4.4.1.02 | Senders | Results | Senders must escape '^' character to the component separator character escape sequence "\S\" | |
| HL7au:000008.2.4.4.1.03 | Senders | Results | Senders must escape '&' character to the sub-component separator character escape sequence "\T\" | |
| HL7au:000008.2.4.4.1.04 | Senders | Results | Senders must escape '~' character to the repeat character escape sequence "\R\" | |
| HL7au:000008.2.4.4.1.05 | Senders | Results | Senders must escape '\' character to the escape character escape sequence "\E\" | |
| HL7au:000008.2.4.4.1.06 | Senders | Results | Senders must escape new line character(s) to the escape sequence "\.br\" | |
| HL7au:000008.2.4.4.1.07 | Senders | Results | Senders must design FT content for presentation with a monospaced font | |
| HL7au:000008.2.4.4.1.08 | Senders | Results | Senders must not use "\Xdddd...\" hexadecimal data escape sequences | |
| HL7au:000008.2.4.4.1.09 | Senders | Results | Senders must not use "\Zdddd..\" locally defined escape sequences | |
| HL7au:000008.2.4.4.1.10 | Senders | Results | Senders must not use "\.ce\" escape sequences. | |
| HL7au:000008.2.4.4.1.11 | Senders | Results | Senders must not break FT content into multiple components or repeats. | |
| HL7au:000008.2.4.4.1.12 | Senders | Results | Senders must limit intended display line lengths to 80 characters. | |
| HL7au:000008.2.4.4.1.13 | Senders | Results | Senders must not use "\M" escape sequences. | |
| HL7au:000008.2.4.4.1.14 | Senders | Results | Senders must not use "\C" escape sequences. | |
| (HL7au:000008.2.4.4.2) | FT Display segment - Receiver | |||
| HL7au:000008.2.4.4.2.01 | Receivers | Results | FT datatype content SHALL be displayed using monospaced font | |
| HL7au:000008.2.4.4.2.02 | Receivers | Results | Receivers must de-escape "\F\" to the field separator character '|' |
|
| HL7au:000008.2.4.4.2.03 | Receivers | Results | Receivers must de-escape "\S\" to the component separator character '^' | |
| HL7au:000008.2.4.4.2.04 | Receivers | Results | Receivers must de-escape "\T\" to the sub-component separator character '&' | |
| HL7au:000008.2.4.4.2.05 | Receivers | Results | Receivers must de-escape "\R\" to the repetition character '~' | |
| HL7au:000008.2.4.4.2.06 | Receivers | Results | Receivers must de-escape "\E\" to the escape character '\' | |
| HL7au:000008.2.4.4.2.07 | Receivers | Results | Receivers must start highlighting text whenever "\H\" escape sequence is encountered | |
| HL7au:000008.2.4.4.2.08 | Receivers | Results | Receivers must end highlighting text whenever "\N\" escape sequence is encountered. | |
| HL7au:000008.2.4.4.2.09 | Receivers | Results | Receivers must support "\.sp <number>\" escape sequences, and must maintain horizontal position while skipping positive <number> vertical spaces. (If <number> is not specified 1 should be assumed). | |
| HL7au:000008.2.4.4.2.10 | Receivers | Results | Receivers must support "\.br\" escape sequence and must begin a new left justified line. | |
| HL7au:000008.2.4.4.2.11 | Receivers | Results | Receivers must support the fill mode (word wrap) "\.fi\" escape sequence. This means that after this sequence is encountered a soft line break should be introduced when horizontal space runs out. | |
| HL7au:000008.2.4.4.2.12 | Receivers | Results | Receivers must support the no fill mode (no word wrap) "\.nf\" escape sequence. This means after this sequence is encountered a soft line break should not be introduced when horizontal space runs out. | |
| HL7au:000008.2.4.4.2.13 | Receivers | Results | Receivers must support indent "\.in <number>\" escape sequences. This means that on encountering this sequence each subsequent new line should be indented by positive <number> characters until the end of the document or another indent escape sequence sets the indent state. | |
| HL7au:000008.2.4.4.2.14 | Receivers | Results | Receivers must support temporary indent "\.ti <number>\" escape sequences. This means that on encountering this sequence the first character of the each line in the paragraph (ie until \.br\ is encountered) will be indented to the absolute <number> value of fixed-width characters from the left hand side (not relative to the current .in value). | |
| HL7au:000008.2.4.4.2.15 | Receivers | Results | Receivers must support skip "\.sk <number>\" escape sequences. This means that on encountering a skip sequence that the next character position will be advanced by <number> spaces to the right. | |
| HL7au:000008.2.4.4.2.16 | Receivers | Results | Receivers should ensure that 80 characters of text (using a non-proportional font) can be displayed without word wrapping the line of text. | |
| HL7au:000008.2.4.4.2.17 | Receivers | Results | Receivers must support 8859/1 character encoding when specified in MSH-18. | |
| HL7au:000008.2.4.4.2.18 | Receivers | Results | Receivers may support UTF-8 character encoding when specified in MSH-18. | |
| (HL7au:000010) | Digital signatures | |||
| HL7au:000010 | Receivers | Orders, Results | If a digital signature is received in an OBX segment, receiving systems must recognise the digital signature and not inadvertently process it as data for display. |
|
| HL7au:000010.1 | Receivers | Orders, Results | If a digital signature is received in an OBX segment, then the signature and report content should if possible be verified and the results presented to the user on the display with the report. | |
| HL7au:000019 | Senders and Receivers | Orders, Results | A single message of up to 16 MB (16,777,216 bytes) must be able to be received by both the transmitters and receivers of messages. Note: Larger sized messages are feasible, but only under specific trading partner agreements. | |
| HL7au:000020 | Senders | Orders, Results | All message types and trigger event codes beginning with the letter “Z” are reserved for locally-defined messages and must NOT be used. |
|
| HL7au:000021 | Senders | Results | Data type TX must NOT be used as a value in the OBX-2 Value Type field. |
|
| (HL7au:000022) | File and Batch Segments | |||
| HL7au:000022.1 | Senders | Orders, Results | If the batch header is used it must specify individual message acknowledgement. No information from the file header/footer or batch segments should be used. | |
| HL7au:000022.2 | Receivers | Orders, Results | All messages between the batch header (BHS) and the file trailer (FTS) must be acknowledged individually. The batch itself is not acknowledged. |
|
| HL7au:000023 | Senders | Orders, Results | The NTE segment must NOT be used in messages. |
|
| (HL7au:000024) | Delimiters of ‘|^~\&’ from HL7 V2.4 must be used in the message. |
| ||
| HL7au:000024.1 | Senders | Orders, Results | FHS, BHS, and MSH segments must specify the Field separator character as '|' | |
| HL7au:000024.2 | Senders | Orders, Results | FHS, BHS, and MSH segments must specify the Components separator character as '^' | |
| HL7au:000024.3 | Senders | Orders, Results | FHS, BHS, and MSH segments must specify the Sub-components separator characteras '&' | |
| HL7au:000024.4 | Senders | Orders, Results | FHS, BHS, and MSH segments must specify the repeat separator character as '~' | |
| HL7au:000024.5 | Senders | Orders, Results | FHS, BHS, and MSH segments must specify the escape separator character as '\' | |
| General Conformance Points | ||||
| HL7au:000025 | Senders | Orders, Results | The sending facility must ensure their MSH-4 Sending facility identifier is unique. | |
| HL7au:000026 | Senders | Results | When sending a report to multiple "copy to " doctors the MSH-10 Message control ID must be unique in each message produced for each recipient. | |
| HL7au:000027 | Senders | Orders, Results | When re-transmitting a message the MSH-10 Message control ID must be unique. | |
| HL7au:000028 | Senders | Results | When there are multiple OBR segments in an ORU message, the OBR-3 Filler order number must be unique within messages. | |
| HL7au:000029 | Senders | Results | When re-transmitting/forwarding a message from one system to another the MSH-4 Sending facility should be the re-transmitting/forwarding Sending facility (HD components) and not the original authoring organisation (HD components). | |
| HL7au:000030 | Senders | Results | When re-transmitting/forwarding a message from one system to another the MSH-10 Message control ID must be unique for each message. | |
| HL7au:000031 | Senders | Results | When re-transmitting/forwarding a message from one system to another OBR-3.2 Filler order number.namespace ID must be used for the display of the authoring organisation e.g. |123456^Path Lab Name^43210^AUSNATA|. The Filler order number of a result should not be changed. | |
| HL7au:000032 | Senders | Results | In the ORU message the field OBR-24 "Diagnostic serv sect ID" must be valued and should have values from HL7 table 0074 - diagnostic service section. | |
| HL7au:000033 | Senders | Results | In the ORU message the field OBX-3 "Observation identifier" should, if possible, have values from the LOINC coding system except for display segments. | |
| (HL7au:000034) | Use of Codes | |||
| HL7au:000034.1 | Senders | Results | When using a CE data type in an OBX segment in either OBX-3 (Observation Identifier) or as an Observation Value, if the system transmits both the public (e.g. LOINC) and local terminology, then the public (eg LOINC) code should appear in the identifier. | |
| HL7au:000034.2 | Senders | Results | When using a CE data type in an OBX segment, in OBX-3 (Observation Identifier), if the system transmits both a public (e.g. LOINC) and a local terminology, then the local terminology should be transmitted in the second CE triplet i.e. the alternate identifier. | |
| HL7au:000034.3 | Senders | Results | When using a CE data type in an OBX segment, In either OBX-3 (Observation Identifier) or as an Observation Value, if the system transmits both a public (e.g. LOINC) and a local terminology, then concepts from the different terminologies should convey the same clinical meaning. Generally this means there is no need to populate the Alternate Text field. | |
| HL7au:000034.4 | Receivers | Receivers should recognize Result and Report comment LOINC codes and Template ID/Section Header LOINC codes and display appropriately. | See 4.6 Specific LOINC codes | |
| (HL7au:000040) | MSH-12 Version ID Field Conformance Points | |||
| HL7au:000040.1 | Senders | Orders, Results | Senders conforming to this specification must specify "2.4" as the value of version ID (ID) component of MSH-12 Version ID (VID) | |
| HL7au:000040.2 | Senders | Orders, Results | MSH-12 Version ID <internationalization code (CE)> component must be valued "AUS^Australia^ISO3166_1" | |
| HL7au:000040.3 | Senders | Orders, Results | MSH-12 Version ID <internal version ID (CE)> component should be valued as "HL7AU-OO-201701^^L". (Note that the number scheme used in this identifier is HL7 date format: YYYYMM) | |
| HL7au:000041 | Senders | Orders, Results | MSH-17 Version ID should be valued as "AUS" | |
| HL7au:000040.5 | Senders | Orders, Results | MSH-19 must be valued as "en^English^ISO639". | |
| (HL7au:000043) | MSH-4 Sending Facility conformance points | |||
| HL7au:000043.1 | Senders | Orders, Results | MSH-4 – Sending Facility must be filled in with the sending facility HPI-O when sending a message via Secure Message Delivery (SMD) and secured by NASH Certificates. The format must be <hpio>^1.2.36.1.2001.1003.0.<hpio>^ISO where <hpio> is a 16-digit number. The identifier is essentially used to locate the endpoint of the sending facility and will be used by the receiving facility to return an acknowledgement. | |
| HL7au:00043.2 | Receivers | Orders, Results | MSH-4 – Sending Facility when using SMD with NASH certificates must be validated against the SMD sending organisation. The message should be rejected. (This is an anti spoofing check) | |
| (HL7au:00044) | Datatype conformance points | |||
| (HL7au:00044.1) | CX datatype conformance points | |||
| HL7au:00044.1.1 | Senders | Orders, Results | CX <ID (ST)> component must be specified and valid according to the identifier scheme of selected by the Identifier type code and Assigning Authority components. | |
| HL7au:00044.1.2 | Senders | Orders, Results | CX <assigning authority (HD)> component must be valued. | |
| HL7au:00044.1.3 | Senders | Orders, Results | CX <identifier type code (ID)> component should be valued with a valid value from HL7 Table 0203 - Identifier type. | |
| (HL7au:00044.2) | HD Datatype conformance points | |||
| HL7au:00044.2.1 | Senders | Orders, Results | When SMD with NASH certificates is used the HD Namespace ID component must contain the registered organisation name as registered by in the Medicare Australia HPOS/HI service, otherwise it should contain the registered NATA name for the laboratory as published by NATA ( www.nata.com.au ) | |
| HL7au:00044.2.2 | Senders | Orders, Results | When SMD with NASH certificates is used the HD Universal ID component must contain the HPI-O formatted as 1.2.36.1.2001.1003.0.<hpio>, otherwise it should contain the registered NATA number for the laboratory as published by NATA ( www.nata.com.au ) | |
| HL7au:00044.2.3 | Senders | Orders, Results | When SMD with NASH certificates is used the HD Universal ID Type component must be "ISO", otherwise if the laboratory NATA number is number used in HD Universal ID Type should be "AUSNATA". | |
| (HL7au:00044.3) | EI datatype conformance points | |||
| HL7au:00044.3.1 | Senders | Orders, Results | The EI Entity identifier component must be valued | |
| HL7au:00044.3.2 | Senders | Orders, Results | When SMD with NASH certificates is used the EI Namespace ID component must contain the registered organisation name as registered by in the Medicare Australia HPOS/HI service, otherwise it should contain the registered NATA name for the laboratory as published by NATA ( www.nata.com.au ) | |
| HL7au:00044.3.2 | Senders | Orders, Results | When SMD with NASH certificates is used the EI Universal ID component must contain the HPI-O formatted as 1.2.36.1.2001.1003.0.<hpio>, otherwise it should contain the registered NATA number for the laboratory as published by NATA ( www.nata.com.au ) | |
| HL7au:00044.3.3 | Senders | Orders, Results | When SMD with NASH certificates is used the EI Universal ID Type component must be "ISO", otherwise if the laboratory NATA number is number used in EI Universal ID Type should be "AUSNATA". | |
| (HL7au:00044.4) | CE datatype conformance points | |||
| HL7au:00044.4.1 | Senders | Orders, Results | When an <identifier (ST)> component is specified, the <name of the coding system> must also be specified. | |
| HL7au:00044.4.2 | Senders | Orders, Results | If no <identifier (ST)> component is specified then no <name of coding system> (primary coding system) should be specified | |
| HL7au:00044.4.3 | Senders | Orders, Results | <text (ST)> component should be valued as what is intended for display to the user. (In some locations user display is not intended and the text may be blank.) | |
| HL7au:00044.4.4 | Senders | Orders, Results | When multiple codes are used Loinc codes (LN) should be placed first using the identifier rather than the alternate identifier. | |
| HL7au:00044.4.5 | Senders | Orders, Results | When an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified. | |
| HL7au:00044.4.6 | Senders | Orders, Results | If no <alternate identifier (ST)> component is specified then no <name of alternate coding system> should be specified | |
| HL7au:00044.4.7 | Senders | Orders, Results | Both <identifer> and <alternative identifier> must reflect the same concept in each of the primary and alternate coding system respectively. Each code may reflect differing levels of granularity within each coding system as the level of granularity differs between coding systems. | |
| HL7au:00044.4.8 | Senders | Orders, Results | Alternate coding system must be a different from the primary coding system. As the 2 codes should describe the same concept the alternate text is optional. | |
| (HL7au:00044.5) | CNE datatype conformance points | |||
| HL7au:00044.5.1 | Senders | Orders, Results | An <identifier (ST)> component is specified, the <name of the coding system> must also be specified. | |
| HL7au:00044.5.2 | Senders | Orders, Results | If no <identifier (ST)> component is specified then no <name of coding system> should be specified | |
| HL7au:00044.5.3 | Senders | Orders, Results | <text (ST)> component must be valued and this should be what is intended for display to the user. | |
| HL7au:00044.5.4 | Senders | Orders, Results | When an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified. | |
| HL7au:00044.5.5 | Senders | Orders, Results | If no <alternate identifier (ST)> component is specified then no <name of alternate coding system> should be specified | |
| HL7au:00044.5.6 | Senders | Orders, Results | <alternate text (ST)> component must be valued and this should be what is intended for display to the user. | |
| (HL7au:00044.6) | CWE datatype conformance points | |||
| HL7au:00044.6.1 | Senders | Orders, Results | When an <identifier (ST)> component is specified, the <name of the coding system> must also be specified. | |
| HL7au:00044.6.2 | Senders | Orders, Results | If no <identifier (ST)> component is specified then no <name of coding system> should be specified | |
| HL7au:00044.6.3 | Senders | Orders, Results | <text (ST)> component must be valued and this should be what is intended for display to the user. | |
| HL7au:00044.6.4 | Senders | Orders, Results | When an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified. | |
| HL7au:00044.6.5 | Senders | Orders, Results | If no <alternate identifier (ST)> component is specified then no <name of alternate coding system> should be specified | |
| HL7au:00044.6.6 | Senders | Orders, Results | <alternate text (ST)> component must be valued and this should be what is intended for display to the user. | |
| (HL7au:00044.7) | XCN datatype conformance points | |||
| HL7au:00044.7.1 | Senders | Orders, Results | XCN <ID (ST)> component should be specified and valid according to the identifier scheme of selected by the Identifier type code and Assigning Authority components. | |
| HL7au:00044.7.2 | Senders | Orders, Results | XCN <assigning authority (HD)> component should be valued and valid. | |
| HL7au:00044.7.3 | Senders | Orders, Results | XCN <name type code (ID)> component should be valued and valid from HL7 Table 200. | |
| HL7au:00044.7.4 | Senders | Orders, Results | XCN <identifier type code (ID)> component should be valued with a valid value from HL7 Table 203. | |
| HL7au:00044.7.5 | Senders | Orders, Results | XCN <family name (FN)> :<surname (ST)> sub-component should to be valued. | |
| HL7au:00044.7.6 | Senders | Orders, Results | XCN <given name (ST)> should to be valued. | |
| (HL7au:00044.8) | TS datatype conformance points | |||
| HL7au:00044.8.1 | Senders | Orders, Results | Correct timezone should be specified | |
| (HL7au:00044.10) | ED datatype conformance points | |||
| (HL7au:00044.10.1) | ED datatype - Senders | |||
| HL7au:00044.10.1.1 | Senders | Results | ED <type of data (ID)> must be valued. | |
| HL7au:00044.10.1.2 | Senders | Results | ED <data subtype (ID)> must be valued. | |
| HL7au:00044.10.1.3 | Senders | Results | ED <encoding (ID)> must be valued. | |
| HL7au:00044.10.1.4 | Senders | Results | ED <data (ST)> must be valued. | |
| HL7au:00044.10.1.5 | Senders | Results | When the ED <subtype (ID)> component is valued with a MIME sub-type value, then the corresponding MIME type must be used in the <Type of data (ID)> component. | |
| HL7au:00044.10.1.6 | Senders | Results | When the ED <subtype (ID)> component is valued with a HL7 2.4 defined <Subtype (ID)> (Table 0291) value, then the corresponding HL7 2.4 type of data (Table 0191) must be used in the <Type of data (ID)> component. | |
| (HL7au:00044.10.2) | ED datatype - Receivers | |||
| HL7au:00044.10.2.1 | Receivers | Results | Receivers should process <type of data (ID)> component case insensitively. | |
| HL7au:00044.10.2.2 | Receivers | Results | Receivers should process <data subtype (ID)> case insensitively. | |
| HL7au:00044.10.2.3 | Receivers | Results | Receivers should process the <encoding (ID)> component case insensitively. | |
| (HL7au:00044.11) | RP datatype conformance points | |||
| (HL7au:00044.11.1) | RP datatype (senders) | |||
| HL7au:00044.11.1.1 | Senders | Results | RP <pointer (ST) > component must be valued | |
| HL7au:00044.11.1.2 | Senders | Results | RP <application ID (HD)> component must be valued | |
| HL7au:00044.11.1.3 | Senders | Results | RP <type of data (ID)> component must be valued | |
| HL7au:00044.11.1.4 | Senders | Results | RP <subtype (ID)> component must be valued | |
| HL7au:00044.11.1.5 | Senders | Results | When the RP <subtype (ID)> component is valued with a MIME sub-type value, then the corresponding MIME type must be used in the <Type of data (ID)> component. | |
| HL7au:00044.11.1.6 | Senders | Results | When the RP <subtype (ID)> component is valued with a HL7 2.4 defined <Subtype (ID)> (Table 0291) value, then the corresponding HL7 2.4 type of data (Table 0191) must be used in the <Type of data (ID)> component. | |
| HL7au:00044.11.1.7 | Receivers | Results, Orders | Receivers should understand that a LOINC code of 60572-5 (Report Template ID) signifies the identifier of the report template used to structure the data and not render as patient data. | See 4.6 Specific LOINC codes |
| (HL7au:00044.11.1.5) | Encoding URLs into RP datatype | |||
| HL7au:00044.11.1.5.1 | Senders | Results | When "URI" is specified in RP <application ID (HD)> component - <universal id type (ID)> sub-component value: the URL should be specified by the concatenation of the RP <application ID (HD)> component, <universal id (ST)> sub-component followed by the RP <pointer (ST)>. | |
| HL7au:00044.11.1.5.2 | Senders | Results | When "URI" is specified in RP <application ID (HD)> component - <universal id type (ID)> sub-component value: the RP <application ID (HD)> component-<namespace id (IS)> sub-component must not be valued. | |
| HL7au:00044.11.1.5.3 | Senders | Results | When "URI" is specified in RP <application ID (HD)> component - <universal id type (ID)> sub-component value: the RP <application ID (HD)> component, <universal id (ST)> sub-component must be the scheme | server and application path parts of the URL. | |
| (HL7au:00045) | Message Acknowledgement | |||
| HL7au:00045.1 | Receivers | Orders | Receivers of a valid ORM Order messages must produce an application level acknowledgement - order response message ORR and transmit it back to the original sender. | |
| HL7au:00045.2 | Receivers | Results | Receivers of valid ORU result messages must produce an application level acknowledgement - ACK^R01 and transmit it back to the original sender. | |
| HL7au:00045.3 | Receivers | Orders, Results | Receiving systems unable to process a HL7 message must produce the appropriate reject or error application level application level acknowledgement and transmit it back to the sender, provided that the message has a valid MSH and Sending Facility and MSH Control ID field. | |
| (HL7au:00046) | General HL7 | |||
| (HL7au:00046.1) | Sender Escaping Rules | |||
| HL7au:00046.1.1 | Senders | Orders, Results | Senders must escape | characters as '\F\' in all fields, components, subcomponents | |
| HL7au:00046.1.2 | Senders | Orders, Results | Senders must escape '^' characters as '\S\' in all HL7 fields, components and subcomponents | |
| HL7au:00046.1.3 | Senders | Orders, Results | Senders must escape '&' characters as '\T\' in all HL7 fields, components and subcomponents | |
| HL7au:00046.1.4 | Senders | Orders, Results | Senders must escape '~' characters as '\R\' in all HL7 fields, components and subcomponents | |
| HL7au:00046.1.5 | Senders | Orders, Results | Senders must escape '\' characters as '\S\' in all HL7 fields, components and subcomponents | |
| (HL7au:00046.2) | Receiver Escaping Rules | |||
| HL7au:00046.2.1 | Receivers | Orders, Results | Receivers must unescape '\F\' escape sequences to character '|' for all fields, components, subcomponents | |
| HL7au:00046.2.2 | Receivers | Orders, Results | Receivers must unescape '\S\' escape sequences to character '^' for all fields, components, subcomponents | |
| HL7au:00046.2.3 | Receivers | Orders, Results | Receivers must unescape '\T\' escape sequences to character '&' for all fields, components, subcomponents | |
| HL7au:00046.2.4 | Receivers | Orders, Results | Receivers must unescape '\R\' escape sequences to character '~' for all fields, components, subcomponents | |
| HL7au:00046.2.5 | Receivers | Orders, Results | Receivers must unescape '\E\' escape sequences to character '\' for all fields, components, subcomponents | |
| HL7au:00046.3 | Senders | Orders, Results | All fields required by HL7 segments table must be validly valued. | |
| HL7au:00046.4 | Receivers | Orders, Results | Receiving implementations when receiving HL7 messages and converting their contents to data values must ignore segments, fields, components, sub-components, and extra repetitions of a field that are present but were not expected. | HL7 2.4 2.11 |
| HL7au:00046.5 | Receivers | Orders, Results | Receiving implementations when receiving HL7 messages and converting their contents to data values must treat segments that were expected but are not present as consisting entirely of fields that are not present | HL7 2.4 2.11 |
| HL7au:00046.6 | Receivers | Orders, Results | Receiving implementations when receiving HL7 messages and converting their contents to data values must treat fields and components that are expected but were not included in a segment as not present. | HL7 2.4 2.11 |
| HL7au:00047.1 | Senders | Orders, Results | MSH-15 Accept acknowledgement type (ID) must be valued AL | |
| HL7au:00047.2 | Senders | Orders, Results | MSH-16 Application acknowledgement type (ID) should be valued AL | |
| HL7au:00048.1 | Senders | Orders, Results | When MSH-18 is unvalued or valued as "ASCII" the message must contain only characters in the range ASCII 32 to ASCII 127 and cursor return ASCII 13 which should only be used as segment separator. | |
| HL7au:00048.2 | Senders | Orders, Results | When MSH-18 is valued and is not "ASCII" encoding the message must not contain characters less than ASCII 32, except for ASCII 13 which should only be used as segment separator. | |
| HL7au:00048.3 | Senders | Orders, Results | MSH-18 may only contain one of the following values "", "ASCII", "UTF-8", "UNICODE", "8859/1" | |
| HL7au:00048.4 | Senders | Orders, Results | When UNICODE is specified in MSH-18 a byte order mark (BOM) must be present at the start of the transmission. | |
| HL7au:00049.1 | Senders | Orders, Results | MSH-9 Message type <message type (ID)> component must be valued. | |
| HL7au:00049.2 | Senders | Orders, Results | MSH-9 Message type <trigger event (ID)> component must be valued. | |
| HL7au:00049.3 | Senders | Orders, Results | MSH-9 Message type <message structure (ID)> component must be valued. | |
| HL7au:00050.1.1 | Senders (Pathology only) | Results | When sending pathology messages:
| |
| HL7au:00050.1.2 | Senders (Pathology only) | Results | When sending pathology messages OBX-3 must be valued according to the APUTS standard where a code is available. | |
| HL7au:00050.1.3 | Senders (Pathology only) | Results | The OBX-6 (Units) <text (ST)> component of the primary identifier must be valued according to APUTS preferred unit for the term. | |
| HL7au:00050.1.4 | Senders (Pathology only) | Results | The OBX-6 (Units) <identifier (ST)> component of the primary must be the case sensitive UCUM code. | |
| HL7au:00050.1.5 | Senders (Pathology only) | Results | The OBX-6 (Units) <name of coding system (IS)> component must be "UCUM". | |
| HL7au:00050.1.6 | Senders (Pathology only) | Results | The OBX-7 References range (ST) should be valued as the APUTS harmonised reference intervals where defined and applicable. | |
| HL7au:00050.1.7 | Senders (Pathology only) | Results | Display segments must be produced according to the APUTS Chapter 7 rendering rules. | |
| HL7au:00050.2.1 | Receivers | Results | Where a receiving system renders an atomic pathology result it must comply with the rendering APUTS Chapter 7 rendering rules. | |
| HL7au:00050.2.2 | Receivers | Results | When rendering a cumulative table or graph of pathology data, do not combine series which have different LOINC codes or have the "Do not combine" flag indicated in any repeat of OBX-17 which is indicated by "765921000168105^Do not combine laboratory test result^SCT". | See 4.13 |
| HL7au:00060.1 | Senders | Orders, Results | HL7 message elements with a usage of R (required) must be valued. | |
| HL7au:00060.2 | Senders | Orders, Results | HL7 message elements with a usage of RE (required or empty) should be valued, except if the data is unknown to the sending application. | |
| HL7au:00060.3 | Senders | Orders, Results | HL7 message elements with a usage of C (conditional) must be valued when the associated predicate is satisfied. | See section 2.B.7.6 |
| HL7au:00060.4 | Senders | Orders, Results | HL7 message elements with a usage of C (conditional) must not be valued when the associated predicate is not satisfied. | See section 2.B.7.6 |
| HL7au:00060.5 | Senders | Orders, Results | HL7 message elements with a usage of CE (condition or empty) must be valued when known to the application knows the value, and must be unvalued when the application does not know the value. | |
| HL7au:00060.6 | Senders | Orders, Results | Sending application must be capable of knowing elements when predicate is true for all CE (conditional or empty) elements. | |
| HL7au:00060.7 | Senders | Orders, Results | HL7 message elements with a usage of CE (condition or empty) must not be valued when the associated predicate is not satisfied. | |
| HL7au:00061.1 | Receivers | Orders, Results | If a HL7 message element with a usage of CE is not present, the receiving application shall not raise an error due to the presence or absence of the element. | |