1.Messaging Infrastructure

1.1 Messaging Framework

1.1.1 Overview

A HL7 V2 message has a number of logical components and rules to enable transmission of data records. The segment contains the details to describe a single type of information.  The structure of each segment type enables the different aspects of clinical information to be processed in a standardized way. For example, specific segments contain information for the patient (PID), order information (ORC) and results (OBX).

The combination of these segments in a standardized structure forms the HL7 message.

Where the essential concepts are:

(a)   Messages are comprised of segments.

(b)  Segments are comprised of fields.

(c)   Fields may be divided into components.

(d)  Components may be divided into sub-components.

A message segment is divided into fields with a field separator character (|)—the vertical bar (hex 7C).

1.1.2 Delimiters

This profile supports the use of the normal HL7 delimiters.  It is recommended, but not required, that implementers be able to send messages using the standard HL7 delimiters.  Receivers must be capable of receiving any legal delimiters that are sent in a particular message instance.

This table is pre-adopted from the HL7 Version 2.6, which offers information regarding best practices.  The intent has not changed from Version 2.4.  Note that this implementation guide includes additional constraints and explanations for the entries.

Table 2?1. Delimiters

1.1.1 Null Values In Fields Vs. Components

In HL7, a null value for a field is indicated by paired double quotes (|""|).  The null value applies to the field as a whole, not to the components/subcomponents of the field.  A null field value indicates that the receiver of the message should delete the corresponding set of information from the data store.  For this implementation guide ((what is this document going to be referred to as?? - need to be consistent throughout document)) , null values within components and subcomponents are meaningless.  For example, |lastname^firstname^""^^^^L| would be interpreted exactly as |lastname^firstname^^^^^L|.  The components and subcomponents of a data type constitute a snapshot of the data.  The set of data represented by the data type is handled as a complete set; therefore, using the null value to indicate a missing component or subcomponent is unnecessary.

‘No data’ is sent as an empty field ||. Leave the receiving field unchanged.

Where all fields are not populated then trailing field separators are not required to be included.

1.1.1 Lengths

For HL7 V2.4 there are no restrictions on the message length (refer to section 2.4, section 2.4, 2nd (c)); however in Australia for practical reasons it has been agreed that the total message size should be less than or equal to 16 MB. For transmitted messages greater than 16 MB there should be no expectation that it will be delivered, unless there are existing trading partner agreements in place.

1.1      Segment names  ((taken from section 4.4 of combined document and the edited from HL7 Intl manual)) 

The data fields are combined into logical groupings called segments. Segments are separated by segment separator characters. Each segment begins with a
three-character literal value that identifies it within a message and is terminated by a carriage return (0x0D).

Individual data fields are found in the message by their position within their associated segments. A segment contains only part of the information required for a message. Therefore a segment is only valid and only has meaning when combined with other related segments into a complete HL7 message. A new segment may have a different segment ID or the same segment ID as the previous segment with an incrementing ‘set-ID’ (read sequence) number field.

These are the HL7 segments that may be used:

NOTE: If an adverse reaction is required to be recorded an OBX segment should be used.

When messages are transmitted using files then the messages may be required to be enclosed within the following segments:

The following segments are not used:

Further detail on the composition and sequence of the segments is provided in the following sections.

1.1      Message format

This is a description of how segments are combined to produce a valid HL7 message.

Message segments can be required (mandatory), optional and/or repeating.

LEGEND:

Brackets may be nested.

NOTE: ‘Optional’ means it is not mandatory for the segment to be always present. However where it is necessary to be present then it is mandatory. For example: When the subject of care services are to be billed to a medical fund then the IN1 segment must be included.

Following is an illustration of an ORM (order message) message format:

NOTES:  

1. This is a generalized format. See Clauses 4.2 ((to be updated)) and 4.3 ((to be updated)) for a more specific definition of the segments required in particular messages.
2. The PV1 segment is included for financial detail.

The preferred message formatting rule is:

(a)   The OBR segment relates to one discrete panel or test code. The subject of care episode may involve several discrete tests. For orders this requires an {ORC-OBR} pair for each group ordered. For results there will be one OBR per panel of results.

(b)  Each OBX segment relates to an individual analyte or component of a structured report or question/answer for each discrete panel, or in the context of orders, it will carry any clinical information required for interpretation of the result.

The ‘test results’ will contain as many OBX segments as are required to report the results. In the case of narrative-type results the complete result may be included in a single OBX segment with embedded text formatting control sequences.

NOTES:  

1. It is recommended that separate episodes be transmitted as separate HL7 messages.
2. As part of the control mechanism of HL7 a unique ‘message control number’ is sent as part of the MSH segment. If several subject of cares or different subject of care episodes are included within a single message and one is rejected then by definition all must be rejected as there is a single ‘message control number’ for that transmission.

For orders that require a subject of care-specific interpretation of the pathology results by a knowledgebase, test results and order information for previous results may be provided in the same HL7 order message as supporting information.

This implies that one message will contain the orders/results for one subject of care. If there are several sets of orders to request or results to report which originate from a single visit for a subject of care then they can all appear in the same message. Conversely if the same subject of care has other results to be reported from a different visit then use a new message as the Filler Order Number will be different.

1.2      Field length

The recommended maximum length of a field is stated in AS 4700.2.

1.1      Data Types

1.1.1     Introduction

((DMc note:  change all instances of the term "Clause" to the term "Section" as per HL7 rather than SA)) Clauses 4.2 to 4.30 ((to be updated)) define each of the field data types used in message segments. These are the main data types required and their use should conform to these rules.

The rules are generally standard HL7 with formatting/content as per AS 4700.1.2.4—2014.  ((need to refer to HL7 V2.4 international))

HL7 protocols are maintained with exceptions based on:

(a)   HL7 protocol allows user definition or ‘agreement between parties’; and

(b)  AS 4700.X variations.

All components are defined but trailing ‘not used’ components are truncated.

Where examples are shown, lower case may be used for readability.

Field values may be upper case, lower case or sentence case.

1.1.2     CD – Channel definition

This data type is used for labelling of digital waveform data e.g. graphs, echo cardiographs.

The CD data type defines a recording channel which is associated with one of the values in each time sample of waveform data.  Each channel has a number (which generally defines its position in a multichannel display) and an optional name or label (also used in displays). One or two named waveform sources may also be associated with a channel (providing for the use of differential amplifiers with two inputs).

1.1.3     CE – Coded element

This data type transmits codes and text associated with the code.

The CE data type is generally used in areas like item level analyte descriptions.

Name of coding system must identify the source of the coding system. Use of 'L' is insufficient in this instance as the same item could be coded identically by different sources. The required format is:

Both xxxx and nnnn are variable length and need only contain significant digits.

The ‘-’ (dash) separator delimits the items.

Example: NATA2184-3 version 3

Example of CE data type:

|14682-9^CREATININE^LN^Cr^CREATININE^NATA1234-007|

NOTE: NATA1234-007 denoting Local coding system, LN denoting LOINC coding system.

1.1.4     CM – Composite

This data type is a combination of other data types. It is used for MSH-9 Message Type and OBR-15 Specimen Source only.

 No new CMs are allowed after HL7 version 2.2. The CM data type is maintained strictly for backward compatibility and may not be used for the definition of new fields.

1.1.5     CX – Extended composite ID with check digit

This data type is used for a complex identification number requiring certification.

This data type is used in PID and PV1 segments where some subject of care identification such as Pension Card Number or Health Card number is used.

Refer to Clause 13.11 ((to be updated)) Patient identifiers for a complete discussion.  ((query include the HB 262 blurb here))

Example:

1.1.6     DT – Date

Format: YYYY[MM[DD]]

In prior versions of HL7, this data type was always specified to be in the format YYYYMMDD.  In the v2.4 and future versions, the precision of a date may be expressed by limiting the number of digits used with the format specification YYYY[MM[DD]].

Example:

1.1.7     ED – Encapsulated data

This data type transmits encapsulated data from a source system to a destination system.  It contains the identity of the source system, the type of data, the encoding method of the data, and the data itself.

The ED data type is used to convey images (see Clause 13.16) ((to be updated & include content here)) and display formats for reports (see Clause 13.15 and Appendices D and E) ((to be updated)).  Refer to Appendix F ((to be updated)) for an example XHTML display segment using an ED datatype.

1.1.8     EI – Entity identifier

The entity identifier defines a given entity within a specified series of identifiers. The specified series, the assigning authority, is defined by components 2 through 4. The assigning authority is of the hierarchic designator (HD) data type (highlighted in bold) ((query delete the highlighted in bold)), but it is defined as three separate components in the EI data type, rather than as a single component as would normally be the case. This is in order to maintain backward compatibility with the EI’s use as a component in several existing data fields.

Conformance Guide: Entity Identifier

HL7v2.4 Australian Pathology Conformance Statement Standard Date.XX: When used as a result or request identifier the NamespaceID and/or Universal ID MUST be populated (in addition to the Entity Identifier) to ensure uniqueness of the complete EI instance across organizations.

Example:

1.1.9     FC—Financial class

This data type indicates a classification for billing purposes. It is used for PV1-20 Financial Class field only.

1.1.10  FT—Formatted text

This is derived from the string data type with embedded formatting codes.

For further information on use of FT, consult Appendix D and Clause 13.15 ((to be updated)), Display format of results.

1.1.11  HD—Hierarchic designator.

This data type is a multi-level field definition composed of three parts.

The first component can exist by itself.

If the second exists then the third must exist—and vice-versa.

One use is placer/filler site identification.

Example:

|LAB^1234^AUSNATA|

NOTE: Be aware that ‘This means that if all components of the HD are valued, the entity identified by the first component is the same as the entity identified by components two and three taken together. However, implementers may choose, by site agreement, to specify that if all three components of the HD are valued, the first component defines a member in the set defined by the second and third components.’— HL7 V2.4, Section 2.9.21.

1.1.12  ID—Coded values for HL7 tables

This is a ST data type field used as an index to valid values from a standard HL7 defined table.

See Clause 14 ((to be updated or modified if the HL7 tables are removed or moved to another source)), Identified tables and occurrences for Sex Table 0001.

NOTES:  

1     ID can only be used for HL7 defined tables.

2     Refer IS data type for user-defined tables.

1.1.13  IS—Coded values for user-defined tables

This is a ST data type field used as an index to valid values from a user-defined table.

See Clause 14, Identified tables and occurrences for Patient location Table 0260.

1.1.14  NA—Numeric array

This data type is used to represent a series (array) of numeric values, each one having a data type of NM, e.g. graph points from an echo cardiograph.  A field of this type may contain a one-dimensional array (vector or row) of numbers.  Also, by allowing the field to repeat, a two-dimensional array (table) of numbers may be transmitted using this format, with each row of the table represented as one repetition of the field.  Arrays which have one or more values not present may be transmitted using this data type. ‘Not present’ values are represented as two adjacent component delimiters.  If the absent values occur at the end of a row, the trailing component delimiters may be omitted.  If an entire row of a table has no values, no component delimiters are necessary (in this case, there will be two adjacent repetition delimiters).  The maximum number of values in one repetition of an NA format field is determined by the maximum field length.

Examples:

1.1.15  NM—Numeric

This data type is a number represented by a string of digits with leading +/- and an optional decimal point. No other non-numeric characters are allowed.

Examples:

|123|, |-12|, |156.7248|, |1.0|, |0.27|, |0.0001|

NOTES:  

1     A value like >1000 or <10 is not numeric type.

2     Use SN (structured numeric) data type in this situation (see Clause 10.19).

3     Do not use ST.

4     Used for OBX segments where the data is numeric.

5     See NM (HL7 V2.4, Section 2.9.28).

1.1.16  PL—Person location

This specifies a subject of care location within a healthcare institution.

There is one reference in segment PV1 where it is used to indicate the ward/bed for an inpatient.

It is peculiar to a hospital environment and may require user-defined tables (IS type) if used in this context.

Currently, there is no single Australian register of healthcare locations. Work on a register is underway and currently there are various identifiers such as the government provider numbers for private hospitals that may be used.

This item will have to be determined on a site-negotiated basis as different formats will most likely be used.

Example:

|W4C^R3^B1^TWH^^^^^WES|

1.1.17  RP—Reference pointer

This data type transmits information about data stored on another system.  It contains a reference pointer that uniquely identifies the data on the other system, the identity of the other system, and the type of data.

NOTE: See also HL7 V2.4, Section 2.9.37.

Usage Note:

When using RP with a URI/URL, the address is broken into two parts, an ‘application ID’ which is the portion of the address that identifies the application, and the ‘pointer’ which identifies the particular data. These parts are placed in component 2 and component 1 respectively. In general, the address is composed of scheme | server | path | query; the scheme and server are part of the application ID, and the query is part of the pointer. The path may be part of either. In practice, it doesn’t matter, as the full address is simply component 2 + component 1. The following two examples (from HL7 V2.7 Section 2.A.65.2) illustrate this:

Example 1:

A CDA document accessed by FTP at

ftp://www.saintelsewhere.org/cdasvc/u28864099/s9076500a/e77534/d55378.xml:

|/cdasvc/u28864099/s9076500a/e77534/d55378.xml^&ftp://www.saintelsewhere.

org&URI^text^x-hl7-cda-level-one|

Example 2:

An image on a web server at:

http://test/synapsestudy.asp?path=/All%20Studies/AccessionNumber=2011F0001000-1:

|?path=/All%20Studies/AccessionNumber=2011F0001000-1^ http://test/synapsestudy.asp&URI^IMAGE^JPEG|

1.1.18  SI—Sequence ID

This data type is a non-negative number in the form of a numeric (NM) field.

This item is used in the ‘Set-ID’ fields of PID/PV1/IN1/GT1/OBR/OBX segments.

1.1.19  SN—Structured numeric

This data type is used to express qualified numeric values. This type allows receiving systems to store the components separately—allowing the use of numeric fields in a database.

It is used for results that are below or above a cut-off point or a ratio or a range:

Examples:

Examples:

1       The separator value ‘.’ is not recommended for use as it implies a decimal point.NOTES:  

2       No examples can be found of its use in this context.  ((query if this item can be deleted))

3       The use of 1.2:3.5 is ambiguous as both . and : can be separators.

4       Only single occurrences of the separator can be accommodated within the specification.

5       Reference Range (Item #575) is not data type SN.  ((what is "item #575"??))

6       Results which are date and time are not SN.

7       See HL7 V2.4, Section 7.4.2.2 for other discussion.

1.1.20  ST—String

This data type is a left justified string of characters—no leading or trailing spaces.

All data is in ASCII display format (0x20–0x7E)

It is used for small fields (<200 characters). Use FT for longer strings.

Example:

|this is can be any string data|

1.1.21  TM—Time

Time conforms to HL7 protocol: HH[MM[SS[.SSSS]]][±ZZZZ])

Example:

Example:

1.1.23  TS—Time stamp

Example:

NOTE: Some TS fields may only require the date.

Examples:

Date and Time of Birth where ‘Time of Birth’ is not known: YYYYMMDD

Date of Birth where ‘Day of Birth’ is unknown: YYYYMM

Date of Birth where ‘Day of Birth’ and ‘Month of Birth’ are not known: YYYY

It is highly recommended that the time zone be included in date references. Systems will need to make allowance for daylight saving and cross-time-zone operations.

The HL7 protocol specifies fractions of seconds (to ten-thousandth) for precision and time zones relative to Universal Coordinated Time (previously GMT).

NOTE: All HL7 systems are required to accept the time zone offset. However, its implementation is application specific. The HL7 protocol allows conversion to a common representation for clinical systems where sender and receiver are in different time zones and where daylight saving is in effect.

±ZZZZ is the time zone of sender relative to GMT.

If used then use the time zone value of the sending system.

Example:

199708081430+1000 is 2:30 pm AEST.

In Australia there is a complexity of variations in time standards and time zones within and across the country. Therefore, differences within zones between standard and summer time and across zones are implicit. Sending/Receiving applications may require processes for time zone processing or they can be detected and ignored.

1.1.24  TX—Text

Conformance Guide: Text

HL7v2.4 Australian Pathology Conformance Statement Standard Date.XX: The TX data type MUST NOT be used.

1.1.25  VID—Version identifier

This data type specifies the HL7 Version being used.

It comprises added definition for country and any variation to the standard version.

Example:

It is presumed that all Australian implementations are AS 4700 compliant and therefore the |2.4^AUS^ISO3166-1| format should be used.  ((query retain complaiance to AS 4700??))

1.1.26  XAD—Extended address  

This data type is used for subject of care and doctor address.

Example:

NOTE: Country is specified in HL7 as data type ID and that it should be a three-character code from ISO 3166 (identical to AS/NZS 2632). HL7 V2.4 may be at variance with AS 4590—2006. The HL7 standard usage is preferred.

1.1.27  XCN—Extended composite ID number and name for persons

This data type is used for representing doctor names.

Examples:

|1234567P^SMITH^BILL^W^^DR^^^AUSHICPR|

HPI-I      |8003619900015717^Smith^John^S^^DR^MD^^AUSHIC^^^^NPI|

1.1.28  XON—Extended organization name

This data type provides a composite name and identification number for organizations eg ORC-21.

Examples:

|XYZ Medical Fund^^1234567|

Or

HPI-O:

| XYZ Organisation^L^8003621566684455^^^AUSHIC^NOI|

1.1.29  XPN—Extended person name

This data type is used for representing individual’s names.

Example:

|Smith^Bill^W^Jnr^Mr|

|Jones^John^^^Dr|

1.1.30  XTN—Extended telecommunications number

This data type is used for representing the standard format for all telephone numbers.

NOTE:This is standard HL7.

NOTE:For HL7 compatibility the leading component separators are included.

Example:

 See note in HL7 V2.4, Section 2.9.55.4. For international use the recommended format is the delimited form using sub-fields 5-9 rather than the structured form of the first field.

1       Healthcare Identification   ((similar content to the prev SA doc content - Diagnostic imaging content has been removed))

1.1      Patient (subject of care) identification 

ISO/TS 22220:2011, Clause 3.2, defines subject of care as follows: ‘any person who uses or is a potential user of a health care service’, and notes, further, that ‘subjects of care can also be referred to as patients, health care consumers or subjects of care’. In general in this document, the broader term ‘subject of care’, which includes people who are well ‘patients’ under preventative care, is preferred to the term ‘patient’. However, the term ‘patient’ has been retained when it refers to a specific term or where its use is well-established or prescribed, as in HL7 Patient Identification (PID) Segment, or where it is part of an existing document title, for example AS 4700.1.2.4—2014, Implementation of Health Level Seven (HL7) Version 2.4, Part 1: Patient administration.

The PID segment permits transmission of all known subject of care identifiers.

For further information about subject of care identification and business processes, see SA HB 234—2012, Healthcare identifier HL7 implementation guide; also see AS 4846—2014, and AS 4700.1.2.4—2014. AS 4700.1.2.4-2014, contains information and references for healthcare identifiers, and readers are encouraged to refer to this document.  ((query refer to these SA documents - all are still current ))

NOTES:  

1.     Subject of care identifiers may not necessarily be unique.

1.2      Site Identification 

Placer and filler sites are specified uniquely by a code contained in the last three components of ORC-2/OBR-2 Placer Order Number and ORC-3/OBR-3 Filler Order Number. (These components of the entity identifier (EI) data type are the equivalent of the three components of the hierarchic designator (HD) data type.)

The second component of the EI data type (first component of the HD data type) can be populated with a composite identifier. Generally, unique identifiers should be chosen from a controlled namespace. The namespace IDs are listed in HL7 User-defined table 0300—Namespace ID; see usage notes against ORC-2 Placer Order Number in Table 8-1.  ((ref to "table 8-1" to be checked/updated))

It is suggested that, for local use, a composite identifier comprise sub-components separated by dots.

The first sub-component should indicate the identifier. The second sub-component should indicate the controlled namespace.

Recognized national namespaces should be identified by a code whose format is determined by whether it is a pathology or diagnostic imaging order. National namespaces should start with ‘AUS’, followed by a unique code (e.g. AUSNATA). The identifier within the namespace precedes the namespace code.

For pathology namespaces:

Example: ‘Sussex Pathology^1234567^AUSNATA’, where ‘1234567’ is the NATA number of the laboratory.

Local namespaces should be identified by a unique code, preceded by the identifier.

Example: ‘AYR GP Surgery^AYBR32615492.BRIS^L’

An HD data type with an ISO ‘Object Identifier’ as a unique identifier can be used. The first component refers to the same identity as the second and third component (taken together). The example shows how this can be used to identify entities.

Example: Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID

NOTES:  

1.     Current Australian namespaces in use are ‘AUSHIC’ (Medicare Australia), ‘AUSDVA’ (Department of Veterans’ Affairs), ‘AUSNATA’ (National Australian Testing Authority) and ‘AUSHICPR’ (Australian Provider Number).

2.     All Australian namespaces will be coded as ‘local’ in HL7 terms, unless they are part of an internationally recognized namespace. Namespaces ‘AUSHIC’, ‘AUSDVA,’ ‘AUSNATA’ and ‘AUSHICPR’ are internationally recognized namespaces that reference Australian assigning authorities.

3.     The values ‘AUSNATA' and ‘AUSHICPR’ are added to User Table 0363 in HL7 V2.4 (see Appendix C).   (( reference location to be updated))

Internet domain names are a suitable controlled namespace identifier where available. Their usage is defined in HL7 V2.4, section 2.9.21.3.

Example: ‘^www.sussexlis.com.au^DNS’

The use of the Healthcare identifiers, including Healthcare Practitioner Identifier—Individual (HPI-I) and Healthcare Practitioner Identifier—Organisation (HPI-O), is described in SA HB 234—2012, Healthcare identifier HL7 implementation guide. Refer to SA HB 234—2012 for further information and examples.

1.2.1     Placer facility or site guidance

The ‘Placer facility or site’ is the surgery, hospital, etc. It identifies the originating site of the order.

Each site requires a unique identifying code to attach to the order number.

Arbitrary assignment of codes by independent operators can result in replication.

Since there is no common identification criteria applied across all placer sites it may be useful to use the first two characters of the town prefixed to the telephone number as a unique identifier for surgeries, e.g. BR32615492. With regard to hospitals, negotiation between users will determine an appropriate site code, e.g. TWH-B for The Wesley Hospital in Brisbane and TWH-S for the Wesley Hospital in Sydney.

Sites should settle on a format for the ‘universal ID’ part and reinforce it with a text description of the practice in the ‘namespace ID code’ with an associated ‘^L’ to indicate that it is a local definition.

The ‘namespace ID’ can exist by itself as a description of the site.

The ‘namespace ID’ and the combination of the ‘universal ID’ and ‘universal ID’ type must identify the same entity.

Example: 

The Placer Site may be appended to order numbers and the like to provide uniqueness.

1.2.2     Filler facility or site guidance

These are diagnostics providers.  It identifies who generates the results.

With the introduction of Healthcare Identifiers it is important to note that when using a HPI-O the actual testing laboratory needs to be known and not just the organisation that the testing laboratory belonged to.  It is a NATA/NPAAC guideline that the testing laboratory be indicated.  ((? this document requires instead of AS 4700.2 update)) AS 4700.2—201x Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and diagnostic imaging (diagnostics) requires that the NATA Accreditation Number be used as a unique identifier for provider laboratories. 

The data type is HD.

Examples:

Assuming NATA laboratory number is 3715 for laboratory name ‘ACME Pathology’ :

|ACME Pathology ^3715^AUSNATA|.

The following examples uses an ISO ‘Object Identifier’ as an UID. The first component and the second and the third component (taken together) refer to the same identity.

MSH-4  |LAB1^1.2.3.4.5.6.7^ISO|

MSH-4  |8003621566684455^1.2.36.1.2001.1003.0.8003621566684455^ISO|

MSH-4  |^1.2.36.1.2001.1003.0.8003621566684455^ISO|

NOTE: The HPI-O may be omitted from the Namespace ID field.

1.3      Message Identifiers 

1.3.1     Introduction

Normal HL7 messaging in the context of diagnostics messaging between diagnostics providers (fillers) and external requesters (placers) in Australia requires the data to be transmitted in messages that are most likely to be contained within files. In a non-real time situation this is essential.

Conformance Guide: Message Identifiers  ((update to the consistent term to be used for this document))

HL7v2.4 Australian Pathology Conformance Statement Standard Date.XX: The receiver of a message MUST be able to verify that: 

(a)    This message is for this site; 

(b)   This message has not been received before; and 

(c)    No messages have been lost since the last received message. 

This is achievable through combinations of the following:

(a)   The use of a placer site code field, internal to the MSH segment, will identify the site for the message.

(b)  The Message Control ID field, internal to the MSH segment, is the primary message identifier.

(c)   A ‘site’ sequence number internal to the FHS/BHS/MSH segments can identify the correct receipt of messages by sequence.

(d)  A File Number to identify an individual file from a particular site.

NOTE: The use of multiple sequence numbers may seem complex but it is necessary to control message identification across all sites in a two-way messaging context.

Remember that—

(i)    many messages (with many internal message control IDs—to identify each individual message);

(ii)  make up a site run (with a site sequence number—to verify receipt of runs );

(iii)                    make up a single file (with a file number—to identify this file from all other files for this site).

The complexity is associated with diagnostics providers having to control (and differentiate between) the many messages and files to many different sites. Therefore, the following Clauses may be biased towards the diagnostics providers’ viewpoint.

The Message Control ID is described in this Clause while site sequence numbers and file numbering/naming are discussed in Clause 12, Site sequence number and file naming as they are not formally part of the HL7 protocol.

NOTES:  

(1)  The Message Control ID does not imply any sequencing and cannot be relied upon to act as a check on the receipt of messages from any source.

(2)  File Naming (where a number is used as part of the filename) cannot be used to check for the correct sequence of messages.

(3)  The Site Sequence Number (if used) is the only valid sequencing check to ensure that all data that is sent to a site is received at that site.

(4)  This section deals with Message Control ID only. See Clause 12, Site sequence number and file naming, describes the use and effect of Site Sequence Number and File Naming.

Clauses 5.3.2 to 5.3.7 ((references to be updated)) are provided as a working example of how the necessary level of control can be maintained and managed. It is not mandatory to adhere to the following methodology. However, implementers should familiarize themselves with the reasoning given for each issue and ensure that alternative methodologies provided meet these criteria.

1.3.2     Message control ID

Message control ID is sent in MSH-10 Message Control ID.

When a message is assembled it requires a unique message identifier called the Message control ID. It is generated by the sending system to distinguish this message from every other message that is sent from this site.

NOTES:  

1     This is not an order number for a request nor is it a specimen number identifier used by the diagnostics provider. It is a unique internal identifier for this one message originating from a particular site in the context of Diagnostics Messaging.

2     As this is an internal field in a message it will not conflict nor cause problems when two messages with the same Message Control ID are received from two different placers/fillers. All systems should ensure that data tables are not keyed uniquely on this value.

For the receiver of the message the primary use for the ID is to indicate to the sending system which message is being acknowledged.

If a subject of care has results for multiple tests and these are all returned under one Message Control ID (i.e. one MSH with multiple OBRs) then if one result has an error all results in this message are rejected, not just the one in error. This occurs because there is only one message reference (Message Control ID) to which an error can be attached.

However, when multiple results are sent—each with individual MSH segments—then only the result in error is rejected and the others can be accepted because each result has its own Message Control ID.

The suggested format for the Message Control ID is a combination of two, or three, parts.

The first part is a control stub identifying the sending facility.

The second, and optional, part is the date in YYYYMMDD format.

The third part is a counter—an ever-incrementing number starting at 1.

 The ‘sending facility’ in this context is not intended to be the form ‘QML^2184^AUSNATA’. It is not correct usage as the ‘AUSNATA’ component is being used out of context. A shortened version is recommended with a compromise being the first component of the sending facility only.

The use of the date in the ID is useful for obvious reasons.

The generalized form is:

<sending facility>_<date>.n{nnnnnnn..}

Example:

1.3.3     Acknowledgment messages

For ACK messages, the sending system must:

(a)   Generate a new Message Control ID for its MSH segment; and

(b)  Return the Message Control ID from the received message in the MSA segment.

Message error condition codes: (See HL7 Table 0357) below.

Clauses 3.4 to 3.7 describe the general sequence of an Order Placement/Results Delivery process.

The clauses are intended to provide an overview of the messaging and the associated message segments and message types. The actual content and field values and their meaning are not relevant at this time and no significance should be placed on them; they are used for completeness of the messages only to highlight content and the interrelationships of the fields between different message types.

1.3.4     Order[DMc1]  

The order from the Placer is identified by a Placer Order Number and Placer Group Number.

The Order Identification information is carried in the ORC segment.

The Testing information is carried in the OBR segment.

Both segments are required to provide all of the necessary information.

The order identifications are an Order ID not a Message Control ID.

Generate a new Message Control ID to transmit the order.

The Message Type in the MSH segment is ORM.

The Trigger Event is O01

The Placer Group Number only occurs in the ORC segment.

There is an ORC/OBR pair for each required test. (Two requested tests in this case)

Field 1 in the OBR segment is a sequence number for panels being ordered.

1.3.5     Order  Acknowledgement

The diagnostics provider returns the Placer message control ID in the MSA segment to acknowledge the order.

The acknowledgment is made using the Message Control ID.

If the order is being rejected an error message is returned in the MSA segment. Additional error information may be sent in an associated ERR segment.

The details being acknowledged are returned in the ORC and OBR segments.

The message type in the MSH segment is ORR. The trigger event code for ORR is (O02).

In response to an ORM message, an ORR message is strongly recommended, even where enhanced acknowledgment mode using an immediate ACK is being used.

NOTES:

1          Sending-MSH-5         = Receiving-MSH-3   (MDW2.8)

2          Sending-MSH-6         = Receiving-MSH-4   (gx_32615492^GOLD^L)

3          Sending-MSH-11        = Receiving-MSH-11 (P)

4          Sending-MSA-2         = Receiving-MSH-10 (gx_971129.7)

See HL7 V2.4, Section 2.13.1.2.1.

1.3.6     Results from filler

The diagnostics provider sends the results as an ‘unsolicited’ observation in a new message.

The Message Type in the MSH segment is ORU.

The Trigger Event is R01.

1.3.7     Results acknowledgment

The placer returns the filler message control ID in the MSA segment to acknowledge the result.

The Message Type in the MSH segment is ACK.

NOTES:  

See HL7 V2.4, Section 2.13.1.2.1

1.4      Representation of Healthcare Identifiers in HL7 Version 2 messaging 

1.4.1     General

With the release of Healthcare Identifiers it is necessary to specify how these identifiers will be represented. Refer to SA AS 4700.1.2.4-2014 , Implementation of Health Level Seven (HL7) Version 2.4 - Patient administration , Clause 5.2.1, and SA HB 234—2012, Healthcare identifier HL7 implementation guide.   ((Query include the detail in this document))

1       ORDER MANAGEMENT   (( will need more work especially replacing the workflow diagrams))  ((DI content has been removed))

1.1      Introduction

Order management is the mechanism by which electronic requests for pathology are handled. This Clause details the principles for order management, specifically in relation to order management scenarios, and provides diagrams to represent each of them.

Conformance Statement: Order Management

HL7v2.4 Australian Pathology Implementation Guide Standard 3-1: The receiving system SHALL –

• check that the message is addressed to the current receiving system;
• check the uniqueness of received message; and
• check that no messages have been lost since the last message received.

The system can claim conformance if it passes the listed set of conformance items.

1.2      General order management

1.2.1     General

Orders required for a single episode or request should be sent within one message, i.e. under a single message header (MSH) segment.

The order should be identified by a placer group number (contained in the ORC segment only).

Each ordered test within the episode or request should be placed in a single (ORC, OBR) segment pair and identified by a unique placer order number (contained in both the ORC and OBR segments).

Figure 3-1 ((to be updated)) illustrates the relationship between placer group number (PGN in the figure) and placer order numbers (PON in the figure).

Figure 6?1 ((a new diagram of different format needs to be added)). Relationship between placer group and placer order numbers

1.2.2     Use of group numbers and order numbers

1.2.2.1    General

Placer group number, placer order number and filler order number should be used in a clearly defined way.

To minimize the amount of site-specific negotiation, the recommended methodology is described below. This methodology provides a consistent mechanism to match results to orders where a one-to-one relationship between requested tests and test results is not possible. There are numerous circumstances where this occurs. The method remains consistent when one-to-one relationships do exist.

1.2.2.2    Placer Group Number

ORC-4 Placer Group Number is used to identify a particular episode or request and to link all tests that comprise that request (this is equivalent to an episode or request identifier). All tests from a particular episode or request should have the same placer group number, including add-on tests, reflex/self-determined tests and laboratory department generated investigation requests.

1.2.2.3    Placer Order Number

The placer order number is the order reference number generated by the placer site (surgery, hospital, etc.) when ordering pathology. It is a multi-component field comprising a unique number and the placer site identifier to ensure that the request does not duplicate a request from another site.

A separate placer order number should be used for each test in the episode or request. This allows each item in the episode or request to be individually referenced, especially in situations where part of the order is to be cancelled.

The method for generating a placer order number is to concatenate the placer group number with a ‘counter’ for each test in the request.

1.2.2.4    Filler Order Number

The filler order number is essentially an ‘acceptance or receipt number’ from the pathology provider to acknowledge that an order has been received and accepted. It may be sent when returning results to the placer. It should not be used to link results to orders, as there are instances where more than one filler order number could be generated in response to a single request.

In terms of pathology only, filler order number may equate to the laboratory number assigned to the specimen when it is collected.

Episode numbers are often not unique for each specimen, and in the context of the messages from one laboratory they shall be unique. One method of achieving this is to use the test code and a specimen counter which is appended to the episode number, e.g. episode number 07-1234, which includes three sputum samples and could have specimen numbers such as the following:

07-1234-SPU-1
07-1234-SPU-2
07-1234-SPU-3

Alternatively, if the laboratory is able to assign unique specimen numbers across departments, the test code may be omitted.

1.2.3     Specimen or episode and result identifiers

Historically, results have been identified by the laboratory/accession number. However, in HL7 ‘Orders’, chapter 4, and ‘Observations’, chapter 7, the pathology number is not available until the subject of care presents for specimen collection, which will generally be some time after the order has been submitted. The order and the collection are often two disparate events separated by time and distance.

When the pathology department receives an electronic request it shall respond with a filler order number. If several requests are received for the same episode (same placer group number) then an equivalent number of order responses will be sent.

The pathology department may adopt one of the following two positions:

(a)      It may respond immediately to the order with a ‘receipt reference’ as the filler order number. When the subject of care eventually presents either for the specimen to be collected or for an examination, a number is allocated by the pathology department.
This number and the paperwork are linked to the original order, which is then entered against the order, and the order is activated.

(b)     It may hold the order and not respond until either the specimen is collected or the subject of care presents and a pathology number is assigned to the specimen or request; it may then use this as the filler order number. The order is activated when the pathology number is entered and an order response can then be sent to the placer using the pathology number as the filler order number.

In an electronic environment, the pathology number is not required by the requestor to link results to an order; the placer group number/placer order number/filler order number should be used for this purpose.

1.2.4     Message conformance

Conformance Statement: Message conformance

HL7v2.4 Australian Pathology Implementation Guide Standard 3-2 ((to be updated)): When used as a result or request identifier, the Namespace ID and/or Universal ID MUST – be populated (in addition to the Entity Identifier (EI)) to ensure uniqueness of the complete EI instance across organizations.

1.3      Providing structured clinical information with an order

OBR-13 allows for brief text clinical notes (ST data type with field length of 300). Clinical information can also be provided in a structured form using associated OBX segments.

1.4      Diagnostics order management

1.4.1     Placer order management

1.4.1.1    Introduction

Placer order management is the process of managing orders between order placer and order filler. It allows the order placer to place a new order with the order filler. It also allows the order placer to cancel the order. To change order information, the order placer would cancel the initial order and place the new one. If used, recurring orders and panel orders are the subject of agreement between the order placer and the department system scheduler/order filler.

Recurring order: An order with a performance frequency greater than one.

Examples:

Pathology—Early morning sputum m/c/s times 3.

Panel order: A service item with more than one observation component.

Examples:

Pathology—A significant proportion of pathology is ordered by panels of individual tests, including FBC, UE, LFT.

1.4.1.2    Add-on tests/procedures

Add-on tests/procedures maintain the same placer group number as the original episode, with a new placer order number. Results are correlated with placer order number.

1.4.1.3    Reflex tests/procedures

Reflex tests/procedures will be associated with the original order by placer group number but may not have a placer order number. Placer applications shall be able to receive reports for which there is no placer order number.

1.4.1.4    Self-determined tests/procedures

Self-determined tests/procedures are generally not ordered by the placer—they are
self-determined by the pathologist. They will be associated with the original order by placer group number but may not have a placer order number. Placer applications shall be able to receive reports for which there is no placer order number.

1.4.1.5    Order management—new order from Order Placer

1.4.1.5.1       General

The placer system sends a new pathology order to the filler system. The filler system sends an acknowledgement back to confirm that the original message has been received (see Figure 3-2).

((replacement diagram to be added))

Figure 6?2. Order Management – New Order

1.4.1.5.2       Order control codes for specific trigger events

The order placer places a new order (control code = NW) for the department system scheduler/order filler. The order filler sends an acknowledgement message (control code = OK) ‘order accepted’.

1.4.1.5.3       Message semantics

The order start date/time is required in the ORC-9 field and the collection start date/time or exam date/time is required in the OBR-7 field.

1.4.1.6    Order management—order cancelled by order placer

1.4.1.6.1       General

The placer system cancels an order on the filler system. The filler system sends an acknowledgement back to confirm that the message has been received (see Figure 3-3).

Figure 6?3. Order Management – Cancel Order  ((replacement diagram to be added))

1.4.1.6.2       Order control codes for specific trigger events

Order placer cancels an order (control code = CA).

Order placer discontinues (attempts to stop) an ongoing order (control code = DC). Order filler sends an acknowledgement (control code = CR) ‘cancelled as requested’.

1.4.2     Filler order management

1.4.2.1    Introduction

This transaction is used by the order filler to inform the order placer about the orders it creates and cancels, including the status of the orders it is fulfilling. If the order filler needs to change an order, it has to do so as a combination of order cancel followed by new order.

A one-for-one relationship between order placer number and order filler number should be established before the order filler creates new orders.

1.4.2.2    Filler order management—new order from order filler

1.4.2.2.1       General

The filler system places a new order. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-4). For an example ORM message, refer to Appendix B.  ((to be updated))

Figure 6?4. Order Management – New Order from Filler

1.4.2.2.2       Order control codes for specific trigger events

Department system scheduler/order filler places an order (control code = SN).

Order placer replies (control code = NA).

1.4.2.3    Order management—status changed by filler

1.4.2.3.1       General

The filler system sends a status change to the order to the placer system. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-5).

Figure 6?5. Order Management – Status Changed  ((replacement diagram to be added))

1.4.2.3.2       Order control codes for specific trigger events

Order filler changes status of order (control code = SC). Order placer sends an acknowledgement (control code = OK) ‘accepted’.

1.4.2.4    Filler order management—order rejected by the order filler

1.4.2.4.1       General

The filler system rejects an order from the placer system. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-6).

Figure 6?6. Order Management – Reject Order   ((replacement diagram to be added))

1.4.2.4.2       Order control codes for specific trigger events

Department system scheduler/order filler rejects the order received from order placer (control code = OD).

If the order filler is unable to process an order, an ORR message will be sent to the order placer with an explanation/reason in ORC-16 (control code = DR).

NOTE: ORR is the ‘general order response message to any ORM (event O02)’; see HL7 V2.4, section 4.4.2.

1.4.2.5    Filler order management—order status update

1.4.2.5.1       General

The filler system sends a status update to the placer system. The placer system sends an acknowledgement back to confirm that the message has been received
(see Figure 3-7).

Figure 6?7. Order Management – Status Update  ((replacement diagram to be added))

1.4.2.5.2       Order control codes for specific trigger events

Department system scheduler/order filler updates an order status (control code = SC). Order filler sends an acknowledgement (control code = OK) ‘accepted’.

1.4.2.6    Filler order management—order cancelled by the order filler

1.4.2.6.1       General

The filler system cancels an order on the placer system. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-8).

Figure 6?8. Order Management – Order Cancelled  ((replacement diagram to be added))

1.4.2.6.2       Order control codes for specific trigger events

Department system scheduler/order filler cancels the order previously received from order placer (control code = OC). Order filler sends an acknowledgement (control code = OK) ‘accepted’.

1.4.2.7    Order management – battery replaced or cancelled by filler

1.4.2.7.1       General

The filler system cancels an order or replaces a battery of tests/procedures. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-9).

Figure 6?9. Order Management – Replace/Cancel Order   ((replacement diagram to be added))

1.4.2.7.2       Order control codes for specific trigger events

Order filler cancels a test/procedure or battery of tests/procedures (control code = CA). Order placer sends an acknowledgement (control code = CR) ‘cancelled as requested’.