4 Observation Reporting

4.1 Purpose

This section describes the transaction set required for sending structured patient-oriented clinical data from one computer system to another. A common use of these transaction sets will be to transmit observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, Radiology system) (the filler), to the ordering system (e.g., GP Surgery, specialists office system) (the placer). However, the transaction set is not limited to such transactions. Observations can be sent from producing systems to archival medical record systems (not necessarily the order placer) and from such medical record systems to other systems that were not part of the ordering loop, e.g., an office practice system of the referring physician for inpatient test results ordered by an inpatient surgeon. These transaction sets permit the transmission of any kind of clinical observations including (but not limited to) clinical laboratory results, the results of imaging studies (excluding the image), Pulmonary function studies, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms, drug allergies, problem lists, diagnostic lists, physician and nursing history, physicals, progress notes, operative notes and so on. An observation can be one of many data types. The main ones are text, numbers and codes. This provides the flexibility needed to transmit observations that are recorded as continuous values (e.g., glucose, diastolic blood pressure), as categorical values, e.g., patient position (sitting, reclining or standing), VDRL (reactive, weakly reactive or nonreactive), or as text. An entire History and Physical could be transmitted as an observation whose value is one large chunk of formatted text.

This section provides mechanisms for transmitting structured, record-oriented reports. This means that individual observations are transmitted as separate logical entities (objects), and within this entity, separate fields are defined for identifying the observation, its values, its units, normal ranges, etc., such that the receiving system can “understand,” reorganize and/or react to the contents of these messages. 

Observations may be transmitted in a solicited (in response to a query) or unsolicited mode. In the solicited mode, a user requests a set of observations according to criteria transmitted by the user. The sending system responds with existing data to satisfy the query (subject to access controls). Queries do not elicit new observations by the target system, they simply retrieve old observations. (The query message is covered in the International standard but is not covered in this guide) The unsolicited mode is used primarily to transmit the values of new observations. It is the mode used by Laboratories to return the values of observations requested by an ordering provider/system. A laboratory system, for example, would usually send the results of an morning electrolytes to the ordering system via the unsolicited mode. Calling such transactions unsolicited may sound like a misnomer, but is not. The placing service solicits the producing service to make the observation. It could also (through a query) solicit the value of that observation after it has been made. However, such an approach would demand continuous polling of the producing system until the result was produced. Using the unsolicited mode, the producing service returns the value of an observation as soon as it is available. The unsolicited mode can also be used to transmit new results to a system (e.g., an archival medical record system or copy doctor) that did not order the observation.

Observations are usually ordered and reported as sets (batteries) of many separate observations. Physicians order electrolytes (consisting of sodium, potassium, chloride, bicarbonate) or vitals (consisting of diastolic blood pressure, systolic blood pressure, pulse, and temperature). Moreover, tests that we may think of as single entity, e.g., cardiac echo, usually yield multiple separate measurements, e.g., left ventricular diameter, left atrial diameter, etc. Moreover, observations that are usually reported as text (e.g., the review of systems from the history and physical) can also be considered a set of separately analysable units (e.g., cardiac history, pulmonary history, genito-urinary history, etc.). We strongly suggest that all text clinical reports be broken down into such separate analysable entities and that these individual entities be transmitted as separate OBX segments. Because many attributes of a set of observations taken at one time will be identical, one OBR segment serves as a header for the report and carries the information that applies to all of the individual observations in the set. In the case of ordered observations, the OBR segment is a “turn-around document” like the manual request forms it replaces. It carries information about the order to the producing service; a copy of the OBR with additional fields completed is returned with the observations to the requesting service. Not all observations are preceded by an order. However, all observations whether explicitly ordered or initiated without an order are reported with an OBR segment as the report header.

The OBR segment provides information that applies to all of the observations that follow. It includes a field that identifies a particular battery (or panel or set) of observations (e.g., electrolytes, vital signs or Admission H&P). For simplicity we will refer to the observation set as the battery. The battery usually corresponds to the entity that is ordered or performed as a unit. (In the case of a query, observation sets may be a more arbitrary collection of observations.) The OBX segment provides information about a single observation, and it includes a field that identifies that single observation (e.g., potassium, diastolic blood pressure or admission diagnosis). The codes used in these fields (OBX-3) are usually LOINC codes and standard LOINC codes, units and reference ranges for many common Observations have been specified by the RCPA here.   In the past, local institutions tended to invent their own unique code systems for identifying test and other clinical observations because standard codes were not available. Such local code systems sufficed for transmitting information within the institutions but presented high barriers to pooling data from many sources for research or for building medical record systems. However, standard code systems such as LOINC® and SNOMED now exist for many of these purposes, and we strongly encourage their use in observation reporting. These codes can be sent either as the only code or they can be sent along with the local historic code as the second code system in a CE code.

4.2 Glossary

Placer:
Person or service that requests (places order for) an observation battery, e.g., the physician, the practice, clinic, or ward service, that orders a lab test. The meaning is synonymous with,
and used interchangeably with, requester. See ORC-2-placer order number, Section 4.5.1.2, “Placer order number” of HL7 International V2.4.

Filler:
Person, or service, who produces the observations (fills the order) requested by the requestor. The word is synonymous with "producer" and includes diagnostic services and clinical services and care providers who report observations about their patients. The clinical laboratory is a producer of lab test results (filler of a lab order), the nursing service is the producer of vital signs observations (the filler of orders to measure vital signs), and so on. See ORC-3-filler order number, Section 4.5.1.3, “Filler order number.” of HL7 International V2.4.

Battery:
A set of one or more observations identified as by a single name and code number, and treated as a shorthand unit for ordering or retrieving results of the constituent observations. In keeping with the mathematical conventions about set, a battery can be a single observation. Vital signs, electrolytes, routine admission tests, and obstetrical ultrasound are all examples. Vital signs (conventionally) consist of diastolic and systolic blood pressure, pulse, and respiratory rate. Electrolytes usually consist of Na+, K+, Cl-, and HCO3-. Routine admission tests might contain FBC, Electrolytes, LFTs, and Urinalysis. (Note that the elements of a battery for our purposes may also be batteries). Obstetrical ultrasound is a battery made up of traditional component measurements and the impression, all of which would be returned as separate results when returned to the requestor. A test involving waveform recording (such as an ECG) can be represented as a battery comprised of results of many categories, including digital waveform data, labels and annotations to the data, measurements, and the impression The word battery is used in this specification synonymously with the word profile or panel. The individual observation elements within a battery may be characteristic of a physiologic system (e.g., liver function tests), or many different physiologic systems.

Observation:
A measurement of a single variable or a single value derived logically and/or algebraically from other measured or derived values. A test result, a diastolic blood pressure, and a single chest X-ray impression are examples of observations. In certain circumstances, tracings and images may be treated by HL7 as individual observations and sent as a single OBX. These include waveform data described in Section 7.15, “Waveform – Trigger Events & Message Definitions,” of HL7 International V2.4 and encapsulated data aggregates using the ED data type described in Section 2.9.16, “ED-encapsulated data,” of HL7 International V2.4 (which can represent actual images, audio data, etc.).

4.3 Trigger Events and Message Definitions

The triggering events that follow are all served by the ORU (Observational report – Unsolicited) or the ORF (Observational Report Response) messages in combination with ACK and QRY. Only the ORU messsage is covered in the Australian localisation and some of the optional segments have been removed.

ORU – unsolicited observation message (event R01)

ORU^R01 Unsolicited Observation Message

The structure documented here differs from the international version as NTE Segments have been removed from under both OBR and OBX segments and SHOULD NOT be used in Australian messages. The PV1 segment is also mandatory, whereas it is optional in the International standard. The optional FTI (Financial Transaction) and CTI (Clinical Trials identification) which are present in the international standard, have also been removed from the ORU Message structure

The CTD segment in this trigger is used to transmit temporary patient contact details specific to this order.

MSH Message Header
{
    PID Patient Identification
    [
       [PD1] Additional Demographics
       [{NK1}] Next of Kin/Associated Parties
       PV1 Patient Visit
       [PV2] Patient Visit - Additional Info
    ]
    {
        [ORC] Order common
        OBR Observations Report ID
        [CTD] Contact Data
        {
            [OBX] Observation/Result
        }
    }
}
[DSC] Continuation Pointer

The ORU message performs three functions:

1. It returns the filler's status on the tests ordered by the placer.
2. It contains the atomic results in OBX segments which are used to populate the placer's result database.
3. It contains the formatted report e.g. pdf, of how the laboratory intended the results to be presented and to be displayed on the placer's system.

The ORU^R01 message is sent out by the laboratory and in respose a ACK^R01 message should be produced to confirm receipt of the ORU message. The structure of the ACK message is as below:

MSH Message Header
MSA Message Acknowledgment
[ ERR ] Error

The Message ID in the original  MSH from the ORU^R01 message is returned in the MSA -2 Message Control ID to confirm receipt as detailed in section 2.16.8.2 of HL7 International V2.4.

4.4 Segments

The full definitions of many segments required for reporting clinical observations are included in other sections.

4.4.1 OBR – Observation Request Segment

In the reporting of clinical data, the OBR serves as the report header. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations.

When a set of observations is ordered, the order message contains an OBR segment. However, observations can be collected and reported without an antecedent order. When observations are reported, the report message also includes one or more OBR segments. So, the OBR segment is like a turn-around document. Some fields in the OBR segment apply only to the ordering message and some to the reporting message. To those familiar with healthcare procedures, these should be obvious from their names (e.g., transcriptionist or principal result interpreter could only apply to the reporting phase).

The OBR segments confirm the status and completion of the ordered tests back to the placer allowing the placer to check off each test ordered as it is received. The OBR segments do not contain the results or when the results will be available. However, the structure of the OBR and OBX segments in the ORU can reflect the specimen used to determine the results e.g. specimen ID. 

HL7 Attribute Table – OBR – Observation Request 

Legend:

** ALERT: The field length of OBR-2 and OBR-3 of 250 characters for Australian usage is a variance to the HL7 V 2.4 field length of 22 characters.
*** ALERT: The field length of OBR-9 of 250 characters for Australian usage is a variance to the HL7 V 2.4 field length of 20 characters.

**** ALERT: Variance with HL7 2.4 International. 

Fields with Strikethrough are either deprecated or not used in Australia.

The daggered (†) items in this segment are not created by the placer known to the filler, not the placer. They are created by the filler and valued as needed when the OBR segment is returned as part of a report. Hence on a new order sent to the filler, they are not valued. There is an exception when the filler initiates the order. In that case, the filler order number is valued and the placer order number may be blank. They are valued by the filler as needed when the OBR segment is returned as part of a report.

The starred (*) fields are only relevant when an observation is associated with a specimen. These are completed by the placer when the placer obtains the specimen. They are completed by the filler when the filler obtains the specimen.

OBR-24 (Diagnostic Serv Section ID) has been changed to required as many end points need to know if the message contains pathology, radiology or a clinical message to allow routing of a message to the appropriate location in a practice management application.

OBR-7-observation date/time and OBR-8-observation end date/time (flagged with #) are the physiologically relevant times. In the case of an observation on a specimen, they represent the start and end of the specimen collection. In the case of an observation obtained directly from a subject (e.g., BP, Chest X-ray), they represent the start and end time of the observation.

OBR-28 Repeat is NOT restricted to 5 copy doctors in this specification as it is in the HL7 International specification.

4.4.1.1 OBR-1 Set ID - OBR (SI) 00237 

Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.  This field is required if more than one OBR segment is sent with the order.

4.4.1.2 OBR-2 Placer order number (EI) 00216 

Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field is a case of the Entity Identifier data type (See Datatypes, “EI - Entity identifier”). The first component is a string that identifies an individual order (e.g., OBR).  It is assigned by the placer (ordering application/site). It identifies an order uniquely among all orders from a particular ordering site (identified by subsequent components). The second through fourth components contain the site ID of the placing site in the same form as the HD data type which is covered in the datatypes section.

Since third party providers at another site (those other than the placer and filler of an order) can send and receive ORM and ORR messages (ie create orders), the placer site ID in this field may not be the same as any sending and receiving HDs  (as identified in the MSH segment).

ORC-2-placer order number is the same as OBR-2-placer order number. If the placer order number is not present in the ORC, it must be present in the associated OBR and vice versa. If both fields, ORC-2-placer order number and OBR-2-placer order number, are valued, they must contain the same value. When results are transmitted in an ORU message, an ORC is not required, and the identifying placer order number must be present in the OBR segments. These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers). 

An ORC/OBR segment pair must be used for each test where the Placer Order Number under the one MSH can be the same for each requested test or a different (recommended) number can be allocated to each test. The Placer Group Number in the ORC segment only, links all orders into a request for that patient episode. 

Note: The field length of 250 characters is a variation to the HL7 International standard which has a length of 22 characters.

Placer order numbers are optional in patient referral messages (but OBR-3 Filler Order number below are required).

4.4.1.3 OBR-3 Filler order number (EI) 00217

Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Example: 16-72012244-BFM-0^QML^2184^AUSNATA

Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (See Datatypes, “EI - Entity Identifier”). Its first component is a string that identifies an order detail segment (e.g., OBR). It is assigned by the order filler application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time. The second through fourth components contain the the original authoring filler site ID, in the form of the HD data type (see Datatypes, “HD - hierarchic designator”). The second component of the filler order number always identifies the actual filler of an order. Since third party sites/applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application HDs (as identified in the MSH segment).

ORC-3-filler order number is the same as OBR-3-filler order number. If the filler order number is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments. The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common application would be that of the original filler and placer, respectively, rather than a new one assigned by the common application.

Note: The field length of 250 characters is a variation to the HL7 International standard which has a length of 22 characters.

Messages other than order messages must have the filler order number present and must qualify the identifier using the site identifier (HD components: namespace, universal id, universal ID type of EI) of the authoring organisation which allows for the unique identification of the document across all practices.

The filler order number includes the site identifier of the organisation that generates the document/result/referral and the entity identifier (generated by the clinical application) which must be unique to each document/result/referral, within the same filler site, over time. This should allow for corrected documents to be issued (using the same OBR-3 Filler Order number (EI) as the original document).

4.4.1.4 OBR-4 Universal service identifier (CE) 00238

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Example: CBC^MASTER FULL BLOOD COUNT^2184

Definition: This field is the identifier code for the requested observation/test/battery. This can be based on local and/or “universal” codes. We recommend the “universal” procedure identifier if available (eg SNOMED-CT). 

This field is used for the requested service. The RCPA Board approved Requesting Pathology Terminology Reference Set is available on the RCPA website. 

To indicate the completion of an order, the code set used in the result (ORU) should be the same code set used in the order (ORM).

If local coding systems are used should be of a standard format i.e. code^description^NATA#-Version#

For example:

|26958001^liver function test^SCT|  -  SNOMED CT

|COAG^Coagulation studies^NATA4810-4|  

|FBE^Full Blood Examination^NATA7816|  - version number not included.

The 'NATA3-Version#' indicates the test was done by a specific laboratory using the methods and formats linked to the version number.

4.4.1.4.1 OBR-4 codes in referral messages

In referral messages the referral summary is indicated by the OBR-4 code, which should be either a child concept of the SNOMED CT-AU concept 373942005 Discharge Summary (record artifact), for hospital discharge or a child of 3457005 | Patient referral (procedure) for provider to provider referral. This OBR/OBX group should contain the VMR data if available. Senders may include older referrals in a REF message but the current referral must appear as the first OBR/OBX group. A initial candidate set of record artifact decended codes has been submitted to the Australian Digital Health Agency 

4.4.1.4.1.1 Examples of codes (non-exhaustive) for use in referral messages to indicate referral summary.

Refer to SNOMED-CT AU for complete list of codes.

4.4.1.5 OBR-5 Priority - OBR (ID) 00239

Definition: This field has been deprecated. It is not used. Previously priority (e.g., STAT, ASAP), but this information is carried as the sixth component of OBR-27-quantity/timing.

4.4.1.6 OBR-6 Requested date/time (TS) 00240

Definition: This field has been deprecated. This is not used. Previously requested date/time. That information is now carried in the fourth component of the OBR-27- quantity/timing.

4.4.1.7 OBR-7 Observation date/time (TS) 00241

Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant datetime of the observation.

If time is transmitted it should be specified to the minimum precision of minutes and the time zone must be included.

4.4.1.8 OBR-8 Observation end date/time (TS) 00242

Definition: This field is the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.

If time is transmitted it should be specified to the minimum precision of minutes and the time zone must be included.

4.4.1.9 OBR-9 Collection volume (CQ) 00243

Components: <quantity (NM)> ^ <units (CE)>

Subcomponents of units: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (IS)>
Definition: For laboratory tests, the collection volume is the volume of a specimen. The default unit is ML. Specifically, units should be expressed using UCUM (unitsofmeasure.org). This is a results-only field except when the placer or a party has already drawn the specimen.

Note: The field length of 250 characters is a variation to the HL7 International standard field length of 20 characters.

4.4.1.10 OBR-10 Collector identifier (XCN) 00244

Components:  <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)> 

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> &<universal ID type (ID)> 

Subcomponents of assigning facility ID: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present.

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

4.4.1.11 OBR-11 Specimen action code (ID) 00245

Definition: This field is the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC - “NW”) is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen (“L” or “O”).

HL7 Table 0065 - Specimen Action Code

4.4.1.12 OBR-12 Danger code (CE) 00246

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field is the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter.

Snomed-CT AU is a recommended source terminology for this field. 

eg. 71837009^Cytotoxic agent (product)^SCT

4.4.1.13 OBR-13 Relevant clinical information (ST) 00247

Definition: This field contains any additional clinical information about the patient or specimen. This field is used to report the suspected diagnosis and clinical findings on requests for interpreted diagnostic studies. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. For some orders this information may be sent on a more structured form as a series of OBX segments that immediately follow the order segment.

4.4.1.14 OBR-14 Specimen received date/time (TS) 00248

Definition: For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.

If time is transmitted it should be specified to the minimum precision of minutes and the time zone must be included.

4.4.1.15 OBR-15 Specimen source (CM) 00249

Components: <specimen source name or code (CE)> ^ <additives (TX)> ^ <freetext (TX)> ^ <body site (CE)> ^ <site modifier (CE)> ^ <collection method modifier code (CE)>

Subcomponents of specimen source name or doe: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (ST)>

Subcomponents of body site: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (ST)>

Subcomponents of site modifier: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> &<alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (ST)>

Subcomponents of collection method modifier code: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (ST)>

Definition: This field identifies the site where the specimen should be obtained or where the service should be performed.

The first component contains the specimen source name or code (as a CE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture – heart blood.) Refer to HL7 table 0070 - Specimen source codes for valid entries. 

SNOMED-CT AU is recommended as a terminology source this field. e.g. 122575003&Urine Specimen&SCT

HL7 Table 0070 – Specimen source codes

The second component should include free text additives to the specimen such as Heparin, EDTA, or Oxlate, when applicable.

The third is a free text component describing the method of collection when that information is a part of the order. When the method of collection is logically an observation result, it should be included as a result segment.

The fourth component specifies the body site from which the specimen was obtained, and the fifth is the site modifier. For example, the site could be antecubital fossa, and the site modifier “right.” The components of the CE fields become subcomponents. Refer to HL7 Table 0163 – Body site.  SNOMED-CT AU is recommended as a terminology source this field. e.g. 64033007&kidney structure&SCT

HL7 Table 0163 – Body site

The fifth component indicates whether the specimen is frozen as part of the collection method. Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.

4.4.1.16 OBR-16 Ordering provider (XCN) 00226

Components: <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility ID: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field identifies the provider who ordered the test. Either the ID code or the name, or both, may be present. This is the same as ORC-12-Ordering provider. If ORC-12 does not contain the ordering provider then it must be present in the associated OBR and vice versa.  If both, ORC-12 Ordering provider and OBR-16 Ordering Provider are valued, then both must contain the same value. When results are sent in an ORU message, an ORC is not required, so the identifying ordering provider must be present in the OBR segment.  See also PV1-8 Referring Doctor.

In the Australian setting Medicare provider numbers are used to provide a location specific identifier.

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

In referral messages this field may be blank in the case of the referral letter, but the original value should be preserved in the case of existing reports that are being forwarded in OBR/OBX groups. e.g. copies of pathology and radiology reports.

4.4.1.17 OBR-17 Order callback phone number (XTN) 00250

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>

Definition: This field is the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.

Note: This field is not the same as ORC-14 Call-back Phone Number.

4.4.1.18 OBR-18 Placer field 1 (ST) 00251

Definition: This field is user field #1. Text sent by the placer will be returned with the results.

4.4.1.19 OBR-19 Placer field 2 (ST) 00252

Definition: This field is similar to placer field #1.

4.4.1.20 OBR-20 Filler field 1 (ST) 00253

Definition: This field is defined for any use by the filler (diagnostic service) and in Australia has a specific usage to allow transmission of values not allowed for in the international standard.

Example: DR=UMA2P,LN=16-72012244,RC=Y

The ST field is encoded with repeating name=value pairs separated by commas. eg. |name=value,name=value,name=value|

The current allowable codes are:

When transmitted all reserved HL7 delimiters must be escaped and the OBR-20 ST result extracted, unescaped and then parsed as a comma separated name=value pairs.

eg. |LN=2016-1234-XYZ\T\LBA| is extracted as LN=2016-1234-XYZ&LBA

4.4.1.21 OBR-21 Filler field 2 (ST) 00254

Definition: This field is similar to filler field #1.

To be valued by the filler of the order. This data element can be used for contact detail for OBR-32 to OBR-35.

4.4.1.22 OBR-22 Results rpt/status chng - date/time (TS) 00255

Definition: This field specifies the date/time results reported or status changed. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5-order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for untransmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.

To be valued by the filler of the order. If time is transmitted it should be specified to the minimum precision of minutes and the time zone must be included.

4.4.1.23 OBR-23 Charge to practice (CM) 00256

Components: <dollar amount (MO)> ^ <charge code (CE)>

Subcomponents of dollar amount: <quantity (NM)> & <denomination (ID)>

Subcomponents of charge code: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (IS)>

Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).

To be valued by the filler of the order.

4.4.1.24 OBR-24 Diagnostic serv sect ID (ID) 00257

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here.

Refer to HL7 Table 0074 - Diagnostic service section ID for valid entries. This field is required in Australian implementations to indicate to the placer system which clinical area to display the results. 

HL7 Table 0074 - Diagnostic service section ID 

4.4.2 OBX - Observation/Result segment

Note: † An Australian extension to the the laboratory department code. 

4.4.1.25 OBR-25 Result status (ID) 00258

Definition: This field is the status of results for this order. This conditional field is required whenever the OBR is contained in a report or referral message. It is not required as part of an initial order.

There are two methods of sending status information. If the status is that of the entire order, use ORC-15- order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results report/status change - date/time. If both are present, the OBR values override the ORC values. This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11- observ result status may be used. In the Australian environment, when any part of a report is corrected,  a complete report, containing all the OBX segments should be transmitted with an OBR-25 status of 'C'. The individually updated OBX segments can be flagged with their own result status in OBX-11.

Refer to HL7 Table 0123 - Result status for valid OBR Result Status entries.

HL7 Table 0123 - Result status 

4.4.1.26 OBR-26 Parent result (CM) 00259

Not used in Australian messages. Use observation Sub-ID in OBX-4 to link results

4.4.1.27 OBR-27 Quantity/timing (TQ) 00221

Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing> ^ <occurrence duration (CE)> ^ <total occurrences (NM)>

Definition: This field contains information about how many services to perform at one service time and how often the service times are repeated, and to fix duration of the request. See Section 7.4.1.27, “Quantity/Timing (TQ) Definition.” of HL7 International V2.4

ORC-7-quantity/timing is the same as OBR-27-quantity/timing. If the ORC-7 and OBR-27 are both valued, then both should be valued exactly the same. If the quantity/timing is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments. For example, if an OBR segment describes a unit of blood, this field might request that three (3) such units be given on successive mornings. In this case ORC-7-quantity/timing would be “1^XQAM^X3”. ORC-7-quantity/timing is the same as OBR-27-quantity/timing. 

If time is transmitted it should be specified to the minimum precision of minutes and the time zone must be included.

Note: In the Australian context only components 4 "start date/time" and 6 "priority" are used of the TQ data type.

4.4.1.28 OBR-28 Result copies to (XCN) 00260

Components: <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type(ID)> Subcomponents of assigning facility ID: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field is the people who are to receive copies of the results.  

In the Australian setting Medicare provider numbers are used to provide a location specific identifier.

Variance: While the International standard restricts this to 5 copy doctors, the Australian standard does not have this restriction and allows an unlimited number. 

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

4.4.1.29 OBR-29 Parent (CM) 00261

Not used in Australian messages. Use observation Sub-ID in OBX-4 to link results.

4.4.1.30 OBR-30 Transportation mode (ID) 00262

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 - Transportation mode for valid codes.

HL7 Table 0124 - Transportation mode 

4.4.1.31 OBR-31 Reason for study (CE) 00263

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Snomed-CT AU is a recommended source terminology for this field. 

eg. 274640006^Fever with chills (finding)^SCT

4.4.1.32 OBR-32 Principal result interpreter (CM) 00264

Components: <name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)>

Subcomponents of name: <ID number (ST)> & <family name (ST)> & <given name (ST)> & <middle initial or name (ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g., DR)> & <degree (e.g., MD) (ST)> & <source table (IS)> & <assigning authority (HD)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field identifies the physician or other clinician who interpreted the observation and is responsible for the report content. In the Australian context this field may be used for the billing doctor information.

This field should be valued where the original authoring provider for the content is known.

4.4.1.33 OBR-33 Assistant result interpreter (CM) 00265

Components: <name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)>

Subcomponents of name: <ID number (ST)> & <family name (ST)> & <given name (ST)> & <middle initial or name (ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g., DR)> & <degree (e.g., MD) (ST)> & <source table (IS)> & <assigning authority (HD)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field identifies the clinical observer who assisted with the interpretation of this study.

4.4.1.34 OBR-34 Technician (CM) 00266

Components: <name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)>

Subcomponents of name: <ID number (ST)> & <family name (ST)> & <given name (ST)> & <middle initial or name (ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g., DR)> & <degree (e.g., MD) (ST)> & <source table (IS)> & <assigning authority (HD)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field identifies the performing technician.

4.4.1.35 OBR-35 Transcriptionist (CM) 00267

Components: <name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)>

Subcomponents of name: <ID number (ST)> & <family name (ST)> & <given name (ST)> & <middle initial or name (ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g., DR)> & <degree (e.g., MD) (ST)> & <source table (IS)> & <assigning authority (HD)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field identifies the report transcriber.

4.4.1.36 OBR-36 Scheduled - date/time (TS) 00268

Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = “S”). This is a result of a request to schedule a particular test and provides a way to inform the Placer of the date/time a study is scheduled (result only).

4.4.1.37 OBR-37 Number of sample containers (NM) 01028

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

4.4.1.38 OBR-38 Transport logistics of collected sample (CE) 01029

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table.

4.4.1.39 OBR-39 Collector's comment (CE) 01030

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficult clotting after venipuncture and ecchymosis.

Snomed-CT AU is a recommended source terminology for this field. 

e.g. 161156004^Language difficulty (finding)^SCT

161156004 | Lang161156004 | Language difficulty (finding)uage difficulty (finding)

4.4.1.40 OBR-40 Transport arrangement responsibility (CE) 01031

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table

4.4.1.41 OBR-41 Transport arranged (ID) 01032

Definition: This field is an indicator of whether transport arrangements are known to have been made.

Refer to HL7 Table 0224 - Transport arranged for valid codes.

HL7 Table 0224 - Transport arranged 

4.4.1.42 OBR-42 Escort required (ID) 01033

Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in the OBR-43-planned patient transport comment field. See 

HL7 Table 0225 - Escort required 

4.4.1.43 OBR-43 Planned patient transport comment (CE) 01034

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table.

4.4.1.44 OBR-44 Procedure code (CE) 00393

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the Universal Service ID reported in field 4. User-defined Table 0088 - Procedure code is used as the HL7 identifier for the user-defined table of values for this field. This field is a CE data type for compatibility with clinical and ancillary systems. 

User-defined Table 0088 - Procedure code

4.4.1.45 OBR-45 Procedure code modifier (CE) 01316

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains the procedure code modifier to the procedure code reported in field 44, when applicable. Procedure code modifiers are defined by regulatory agencies. Multiple modifiers may be reported. User-defined Table 0088 - Procedure code is used as the HL7 identifier for the user-defined table of values for this field.

4.4.1.46 OBR-46 Placer supplemental service information (CE) 01474

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other, specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined table 0411 - Supplemental service information values for suggested values. This field can be used to describe details such as whether study is to be done on the right or left, for example where the study is of the arm and the order master file does not distinguish right from left or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

Snomed-CT AU is a recommended source terminology for this field. 

e.g. 266919005^Never smoked tobacco (finding)^SCT

161156004 | Language difficulty (finding)

4.4.1.47 OBR-47 Filler supplemental service information (CE) 01475

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information details that is not available in other, specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplement information unless the order was modified in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values for suggested values.

This field can be used to describe details such as whether study is to be done on the right or left, for example where the study is of the arm and the order master file does not distinguish right from left or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

User-defined Table 0411 - Supplemental service information values  

Individual implementations may extend this table using other appropriate vocabularies.

4.4.2 OBX - Observation/Result segment

The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. Its principal mission is to carry information about observations in report messages. But the OBX can also be part of an observation order (see Section 4.2, “Order Message Definitions” of HL7 International V2.4). In this case, the OBX carries clinical information needed by the filler to interpret the observation the filler makes. For example, an OBX is needed to report the inspired oxygen on an order for a blood oxygen to a blood gas lab, or to report the menstrual phase information which should be included on an order for a pap smear to a cytology lab.  OBX segments are also found in other HL7 messages that need to include relevant clinical information.

Following the final atomic OBX segment are the OBX display segment(s) with the presented report. There must be at least one display segment per OBR segment and where there is more than one display type it must contain the same report detail. If there is a digital signature it will appear after the OBX display segments.

HL7 Attribute Table – OBX – Observation/Result

** ALERT: The field length of OBX-2 of three characters for Australian usage is a variance to the HL7 V 2.4 field length of two characters.

*** ALERT: The field length of OBX-18 of 250 characters for Australian usage is a variance to the HL7 V 2.4 field length of 22 characters.

† ALERT: The field length of OBX-5 is a variable number of characters to a maximum of up to 16 MB, though specific trading partner agreements may agree to other maximum sizes.

4.4.2.1 OBX-1 Set ID - OBX (SI) 00569

Definition: This field contains the sequence number.

4.4.2.2 OBX-2 Value type (ID) 00570

Definition: This field contains the format of the observation value in OBX. It must be valued if OBX-11- Observation result status is not valued with an ‘X”. If the value is CE then the result must be a coded entry. When the value type is FT then the results are bulk text. The valid values for the value type of an observation are listed in HL7 Table 0125 - Value type. The observation value must be represented according to the format for the data types defined earlier in Data Types.  Although NM is a valid type, observations which are usually reported as numbers will sometimes have a non numeric value e.g., >300 to indicate the result was off-scale for the instrument. In the example, ">300", ">" is a symbol and the digits are considered a numeric value. The SN (structured numeric) data type accommodates such reporting and, in addition, permits the receiving system to interpret the magnitude. 

All HL7 data types are valid, and are included in Table 0125 except CM, CQ, SI, and ID. For a CM definition to have meaning, the specifics about the CM must be included in the field definition. OBX-5- observation value is a general field definition that is influenced by the data type OBX-3, so CMs are undefined in this context. CQ is invalid because units for OBX-5-observation value are always specified explicitly in an OBX segment with OBX-6 units. SI is invalid because it only applied to HL7 message segments, and ID because it requires a constant field definition. The RP value (reference pointer) must be used if the actual observation value is not sent in OBX but exists somewhere else. For example, if the observation consists of an image (document or medical), the image itself may not necessarily be sent in OBX. The sending system may in that case opt to send a reference pointer. The receiving system can use this reference pointer whenever it needs access to the actual image through other interface standards, e.g., DICOM, or through appropriate servers.

HL7 Table 0125 - Value type 

Strikethrough Elements should not be used in Australian implementations. FT should be used instead of TX. The extended version of datatypes should be used rather than datatypes from prior versions of HL7 V2.

The full definition of these data types is given in  Data Types.

Note: The field length of OBX-2 of three characters for Australian usage is a variance to the HL7 V 2.4 field length of two characters.

4.4.2.3 OBX-3 Observation identifier (CE) 00571

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains a unique identifier for the observation. The format is that of the Coded Element (CE). Example: 11259-9^Hepatitis C Virus RNA Qualitative^LN^HCVRQL^Hepatitis C Virus RNA Qualitative^NATA2623.

In most systems the identifier will point to a terminology or master observation table that will provide other attributes of the observation that may be used by the receiving system to process the observations it receives. 

The first triplet of the CE data type will contain a universal identifier i.e. LOINC or SNOMED.  If both LOINC and SNOMED are sent then LOINC is to be in the first triplet. Where two codes are sent, these codes must be codes for the same concept.

The terminology for observation identification must come from the RCPA pathology terminology reference set (available from the NCTS), where an appropriate code exists.

When local codes are used as the first identifier in this field we strongly encourage sending a universal identifier as well to permit receivers to equivalence results from different providers of the same service (e.g., a hospital lab and commercial lab that provides serum potassium to a nursing home). LOINC® is an HL7 approved code system for the Observation identifier. It covers observations and measurements, such as laboratory tests, physical findings, radiology studies, and claims attachments and can be obtained from loinc.org. LOINC codes, selected by the RCPA for Standards for Pathology Informatics in Australia (SPIA) reporting terminology reference sets which can be obtained at RCPA website or from the National Clinical Terminology Service.

HL7 V2.6, Table 0396 Coding system table has the correct codes to be used for the terminology systems e.g. LN for LOINC and SCT for SNOMED CT.

On occasions no code will be defined or available and only the text component of the CE will be valued. Where a coded term exists in a standard terminology then the identifer and coding system name component should be valued.

There are specific LOINC codes used for result and report comments, template IDs and section headings detailed below in Section 4.6 (Specific LOINC codes) that modify the display of OBX segments and should be handled specifically.

4.4.2.4 OBX-4 Observation sub-ID (ST) 00572

Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. For example, a chest X-ray report might include three separate diagnostic impressions. The standard requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of the first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely identify each OBX segment for editing or replacement.

In Microbiology there may be multiple organisms isolated and each organism can have sensitivities specific to each isolate. This is reported under one OBR segment and the organism and its sensitivities are linked by using "1" for the Sub-ID fore first organism and "2" for the Sub-ID for the second organism etc. This links the relevant data together for machine processing even though the same OBX-3 (Observation Identifier) may be used multiple times. An example of a micro example is below.

MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY^L|Acme Pathology^1001^AUSNATA|||20050420221113+1000||ORU^R01^ORU_R01|20050420.736715|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL||AUS
PID|1|...
PV1|1|O||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN
ORC|RE||05-6690882-URC-0^Acme Pathology^1001^AUSNATA||CM|||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN
OBR|1||05-6690882-URC-0^Acme Pathology^1001^AUSNATA|URC^URINE MICRO^1001|||200503081300+1000|||||||200503081928+1000||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||||DR=MME,LN=05-6690882,RC=Y||200504181642+1000||MB|F||^^^200503080000+1000|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||||Reporting Pathologist
OBX|1|ST|19159-3^Collection Method^LN||Mid stream urine||||||F|||200503082316+1000
OBX|2|ST|25428-4^Glucose^LN||Negative||||||F|||200503082350+1000
OBX|3|ST|2514-8^Ketones^LN||Negative||||||F|||200503082350+1000
OBX|4|ST|20454-5^Protein^LN||Negative||||||F|||200503082350+1000
OBX|5|NM|30405-5^Leucocytes^LN||30|10*6/L^10*6/L^UCUM|<10|+|||F|||200503090015+1000
OBX|6|NM|30391-7^Erythrocytes^LN||40|10*6/L^10*6/L^UCUM|<10|+|||F|||200503090015+1000
OBX|7|SN|30383-4^Epithelial cells^LN||<^10|10*6/L^10*6/L^UCUM|||||F|||200503090015+1000
OBX|8|ST|8269-3^^LN|1|Organism 1||||||F
OBX|9|CE|630-4^Bacteria Identified^LN|1|112283007^Escherichia coli^SCT|||A|||F
OBX|10|SN|19090-0^Colony Count^LN|1|>^10|||A|||F
OBX|11|ST|18864-9^Amp/Amoxycillin^LN|1|S|||S|||F
OBX|12|ST|18862-3^Amoxycillin+Clavulanic acid^LN|1|S|||S|||F
OBX|13|ST|18897-9^Cephalexin^LN|1|S|||S|||F
OBX|14|ST|18955-5^Nitrofurantoin^LN|1|S|||S|||F
OBX|15|ST|18956-3^Norfloxacin^LN|1|S|||S|||F
OBX|16|ST|18997-7^Trimethoprim^LN|1|S|||S|||F
OBX|17|ST|18928-2^Gentamicin^LN|1|S|||S|||F
OBX|18|ST|8270-1^^LN|2|Organism 2||||||F
OBX|19|CE|630-4^Bacteria Identified^LN|2|131269001^Klebsiella^SCT|||A|||F
OBX|20|SN|19090-0^Colony Count^LN|2|>^100|||A|||F
OBX|21|ST|18864-9^Amp/Amoxycillin^LN|2|R|||R|||F
OBX|22|ST|18862-3^Amoxycillin+Clavulanic acid^LN|2|R|||R|||F
OBX|23|ST|18897-9^Cephalexin^LN|2|R|||R|||F
OBX|24|ST|18955-5^Nitrofurantoin^LN|2|R|||R|||F
OBX|25|ST|18956-3^Norfloxacin^LN|2|S|||S|||F
OBX|26|ST|18997-7^Trimethoprim^LN|2|R|||R|||F
OBX|27|ST|18928-2^Gentamicin^LN|2|S|||S|||F
OBX|28|FT|8251-1^Generated comment^LN||\.br\May be suggestive of UTI in the presence of symptoms.\.br\||||||F

The use of the observation Sub-ID can be extended to use a dotted Sub-ID notation which allows a hierarchy to be defined. This can in addition be linked back to a template ID to relate the OBX segments to the metadata definition. An example is illustrated below. The LOINC code "70949-3" can be used to indicate a section header. This is used in the Differential section header below.

MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:3.1.2^L|Acme Pathology^1001^AUSNATA|||20160713174923+1000||ORU^R01^ORU_R01|07131749373-8576|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL||AUS
PID|1|...
PV1|1|O||||||0626518F^DOCTOR^PAUL ^^^DR^^^AUSHICPR^L^^^UPIN|0626518F^DOCTOR^PAUL ^^^DR^^^AUSHICPR^L^^^UPIN|||||||N
ORC|RE||16-123456^Acme Pathology^1001^AUSNATA||CM|||||||0626518F^DOCTOR^PAUL ^^^DR^^^AUSHICPR^L^^^UPIN
OBR|1||16-123456^Acme Pathology^1001^AUSNATA|26604007^Full Blood Count^SNOMED-CT^CBC^^AUSNATA.15454||20160713+1000|20160713+1000|||||||||0626518F^DOCTOR^PAUL ^^^DR^^^AUSHICPR^L^^^UPIN||From Acme Pathology"XX07131747062-4944" 13.07.2016||LN=16-123456||201607131748+1000||HM|F||^^^20160713+1000|0626518F^DOCTOR^PAUL ^^^DR^^^AUSHICPR^L^^^UPIN~0626518F^DOCTOR^PAUL^^^DR^^^AUSHICPR^L^^^UPIN||||0626518F&DOCTOR&PAUL &&&Dr.&&&AUSHICPR
OBX|1|RP|60572-5^^LN^ENTRY^^EN 13606|1|CEN.FULL-BLOOD-COUNT.v3^FULL BLOOD COUNT&99A-B758ABA873EFC4A1&L^TX^Octet-stream||||||F
OBX|2|NM|718-7^Haemoglobin^LN|1.1.1|118|g/L^g/L^UCUM|115-165||||F
OBX|3|NM|789-8^Red cell count^LN|1.1.2|3.9|10*12/L^10*12/L^UCUM|3.8-5.8||||F
OBX|4|NM|4544-3^Haematocrit^LN|1.1.3|0.39|L/L^L/L^UCUM|0.37-0.47||||F
OBX|5|NM|787-2^Mean cell volume^LN|1.1.4|88|fL^fL^UCUM|80-100||||F
OBX|6|NM|785-6^Mean cell haemoglobin^LN|1.1.5|28.0|pg^pg^UCUM|26.5-33.0||||F
OBX|7|NM|786-4^MCHC^LN|1.1.6|320|g/L^g/L^UCUM|310-360||||F
OBX|8|NM|777-3^Platelet count^LN|1.1.7|190|10*9/L^10*9/L^UCUM|150-400||||F
OBX|9|NM|6690-2^White cell count^LN|1.1.8|7.8|10*9/L^10*9/L^UCUM|4.0-11.0||||F
OBX|10|CE|70949-3^^LN|1.1.9|DIFF^Differential^L||||||F
OBX|11|NM|26499-4^Neutrophils^LN|1.1.9.1|4.0|10*9/L^10*9/L^UCUM|2.0-7.5||||F
OBX|12|NM|26474-7^Lymphocytes^LN|1.1.9.2|3.2|10*9/L^10*9/L^UCUM|1.0-4.0||||F
OBX|13|NM|26484-6^Monocytes^LN|1.1.9.3|0.4|10*9/L^10*9/L^UCUM|0.2-1.0||||F
OBX|14|NM|26449-9^Eosinophils^LN|1.1.9.4|0.2|10*9/L^10*9/L^UCUM|0-0.4||||F
OBX|15|NM|26444-0^Basophils^LN|1.1.9.5|0.0|10*9/L^10*9/L^UCUM|0-0.1||||F

4.4.2.5 OBX-5 Observation value (*) 00573

Definition: This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to which observation value is formatted.

Representation:

This field contains the value for the OBX-3-observation identifier of the same OBX segment. Depending upon the observation, the data type may be a number (e.g., a respiratory rate), a coded answer (e.g., a pathology impression recorded as SNOMED), or a date/time (the date/time that a unit of blood is sent to the ward). An observation value is always represented as the data type specified in OBX-2-value type of the same segment. Whether numeric or short text, the answer shall be recorded in ASCII text.

Reporting logically independent observations:

The main sections of dictated reports, such as radiologic studies or history and physicals, are reported as separate OBX segments. In addition, each logically independent observation should be reported in a separate OBX segment, i.e. one OBX segment should not contain the result of more than one logically independent observation. This requirement is included to assure that the contents of OBX-6-units, OBX- 8-abnormal flags, and OBX-9-probability can be interpreted unambiguously. The electrolytes and vital signs batteries, for example, would each be reported as four separate OBX segments. Two diagnostic impressions, e.g., congestive heart failure and pneumonia, would also be reported as two separate OBX segments whether reported as part of a discharge summary or chest X-ray report. Similarly, two bacterial organisms isolated in a single bacterial culture would be reported as two separate OBX segments. 

The combination of OBX-3 (Observation Identifier) and OBX-4 (Observation Sub-ID) should be unique in a result. In Australia when a report is updated the complete report, including all OBX segments and an OBR with a OBR-25 (Result Status) of 'C' should be sent.

The field length of OBX-5 is a variable number of characters depending on the Data Type, up to a maximum of up to 16 MB for ED/FT segments, though specific trading partner agreements may agree to other maximum sizes.

4.4.2.6 OBX-6 Units (CE) 00574

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Background: When an observation’s value is measured on a continuous scale, one must report the measurement units within the units field of the OBX segment. 

The Unified Code for Units of Measure (UCUM) has been devised by the Regenstrief Institute. The UCUM system gives just one logical, unambiguous way of describing the units and should be used in Pathology messages within Australia and is the preferred coding system for units. There are two variants of UCUM which are case sensitive and case insensitive, it is the case sensitive variant which has been chosen.

The preferred units of measure which are to be used in Australia are available by test on the RCPA website.

Example: mL/min/{1.73_m2}^mL/min/1.73m2^UCUM

4.4.2.7 OBX-7 References range (ST) 00575

Components: for numeric values in the format:
a) lower limit-upper limit (when both lower and upper limits are defined, e.g., for potassium 3.5 - 4.5)
b) > lower limit (if no upper limit, e.g., >10)
c) < upper limit (if no lower limit, e.g., <15)
alphabetical values: the normal value may be reported in this location

Definition: When the observation quantifies the amount of a toxic substance, then the upper limit of the range identifies the toxic limit. If the observation quantifies a drug, the lower limits identify the lower therapeutic bounds and the upper limits represent the upper therapeutic bounds above which toxic side effects are common.

Numeric result values should have a suitable reference range.

4.4.2.8 OBX-8 Abnormal flags (IS) 00576

Definition: This field contains a table lookup indicating the normalcy status of the result. We strongly recommend sending this value when applicable. (See ASTM 1238 - review for more details). Refer to User-defined Table 0078 - Abnormal flags for valid entries.

When the laboratory can discern the normal status of a textual report, such as chest X-ray reports or microbiologic culture, these should be reported as N when normal and A when abnormal. Multiple codes, e.g., abnormal and worse, would be separated by a repeat delimiter, e.g., A~W.

User-defined Table 0078 - Abnormal flags 

4.4.2.9 OBX-9 Probability (NM) 00577

Definition: This field contains the probability of a result being true for results with categorical values. It mainly applies to discrete coded results. It is a decimal number represented as an ASCII string that must be between 0 and 1, inclusive.

4.4.2.10 OBX-10 Nature of abnormal test (ID) 00578

Definition: This field contains the nature of the abnormal test. Refer to HL7 Table 0080 - Nature of abnormal testing for valid values. As many of the codes as apply may be included, separated by repeat delimiters. For example, normal values based on age, sex, and race would be codes as A~S~R.

HL7 Table 0080 - Nature of abnormal testing 

4.4.2.11 OBX-11 Observation result status (ID) 00579

Definition: This field contains the observation result status.

Refer to HL7 table 0085 - Observation result status codes interpretation for valid values.

This field reflects the current completion status of the results for one Observation Identifier. It is a required field. Previous versions of HL7 stated this implicitly by defining a default value of “F.” Code F indicates that the result has been verified to be correct and final. Code W indicates that the result has been verified to be wrong (incorrect); a replacement (corrected) result may be transmitted later. Code C indicates that data contained in the OBX-5-observation value field are to replace previously transmitted (verified and) final result data with the same observation ID (including suffix, if applicable) and observation sub-ID usually because the previous results were wrong. Code D indicates that data previously transmitted in a result segment with the same observation ID (including suffix) and observation sub-ID should be deleted.

When changing or deleting a result, multiple OBX segments with the same observation ID and observation sub-ID are replaced or deleted as a unit. Normal progression of results through intermediate (e.g., ‘gram positive cocci’) to final (e.g., ‘staphylococcus aureus’) should not be transmitted as C (correction); they should be transmitted as P or S (depending upon the specific case) until they are final.

Multiple preliminary results may be reported at different observation times. e.g. a microbiology culture.

HL7 Table 0085 - Observation result status codes interpretation 

4.4.2.12 OBX-12 Date last observation normal value (TS) 00580

Definition: This field contains the changes in the observation methods that would make values obtained from the old method not comparable with those obtained from the new method. Null if there are no normals or units. If present, a change in this date compared to date-time recorded, the receiving system’s test dictionary should trigger a manual review of the results to determine whether the new observation ID should be assigned a new ID in the local system to distinguish the new results from the old.

4.4.2.13 OBX-13 User defined access checks (ST) 00581

Definition: This field permits the producer to record results-dependent codes for classifying the observation at the receiving system. 

However, there are a few cases when such controls vary with the value of the observation in a complex way that the receiving system would not want to re-calculate. An example is an antimicrobial susceptibility result. Some systems prefer to display only the susceptibility results of inexpensive antimicrobials depending upon the organism, the source of the specimen and the patient’s allergy status. The sending service wants to send all of the susceptibilities so that certain privileged users (e.g., Infectious Disease specialists) can review all of the results but nonprivileged users would see only the “preferred” antimicrobials to which the organism was susceptible. We expect that other cases also occur.

4.4.2.14 OBX-14 Date/time of the observation (TS) 00582

Definition: This field is required in two circumstances. The first is when the observations reported beneath one report header (OBR) have different dates/times. This could occur in the case of queries, timed test sequences, or clearance studies where one measurement within a battery may have a different time than another measurement. It is also needed in the case of OBX segments that are being sent by the placer to the filler, in which case the date of the observation being transmitted is likely to have no relation to the date of the requested observation.

In France, requesting services routinely send a set of the last observations along with the request for a new set of observations. The date of these observations is important to the filler laboratories. In all cases, the observation date-time is the physiologically relevant date-time or the closest approximation to that date-time. In the case of tests performed on specimens, the relevant date-time is the specimen’s collection date-time. In the case of observations taken directly on the patient (e.g., X-ray images, history and physical), the observation date-time is the date-time that the observation was performed.

4.4.2.15 OBX-15 Producer's ID (CE) 00583

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains a unique identifier of the responsible producing service. It should be reported explicitly when the test results are produced at outside laboratories, for example. When this field is null, the receiving system assumes that the observations were produced by the sending organization. For example: <identifier> = NATA laboratory number; <name of coding system> = ‘AUSNATA’.

4.4.2.16 OBX-16 Responsible observer (XCN) 00584

Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility ID: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: When required, this field contains the identifier of the individual directly responsible for the observation (i.e., the person who either performed or verified it). In a nursing service, the observer is usually the professional who performed the observation (e.g., took the blood pressure). In a laboratory, the observer is the technician who performed or verified the analysis. The code for the observer is recorded as a CE data type. If the code is sent as a local code, it should be unique and unambiguous when combined with OBX-15-producer ID.

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

4.4.2.17 OBX-17 Observation method (CE) 00936

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

This optional field can be used to transmit the method or procedure by which an observation was obtained when the sending system wishes to distinguish among one measurement obtained by different methods and the distinction is not implicit in the test ID. Chemistry laboratories do not usually distinguish between two different methods used to measure a given serum constituent (e.g., serum potassium) as part of the test name. See the LOINC® Users Manual3 for a more complete discussion of these distinctions. If an observation producing service wanted to report the method used to obtain a particular observation, and the method was NOT embedded in the test name, they can use this field.

The Centers for Disease Control and Prevention (CDC) Method Code (CDCM) is one candidate code system for reporting methods/instruments. EUCLIDES method codes are another. User defined tables are an alternative.

In Australia this field is used to transmit code that indicate if it is safe to combine results across labs (assuming same LOINC code). Refer to the examples at the section 4.13 Combining test values from different organisations below.

4.4.2.18 OBX-18 Equipment instance identifier (EI) 01479

Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field identifies the Equipment Instance (e.g., Analyzer, Analyzer module, group of Analyzers,...) responsible for the production of the observation. This is the identifier from an institution's master list of equipment, where the institution is specified by the namespace ID or if it is blank, then by the “Producer’s ID” (OBX-15). It should be possible to retrieve from this master list the equipment type, serial number, etc., however it is not planned to transfer this information with every OBX. The repeating of this field allows for the hierarchical representation of the equipment (lowest level first), e.g., module of an instrument, instrument consisting of modules, cluster of multiple instruments, etc.

The field length of 250 characters for Australian usage is a variance to the HL7 V 2.4 field length of 22 characters.

4.4.2.19 OBX-19 Date/time of the analysis (TS) 01480

Definition: This field is used to transfer the time stamp associated with generation of the analytical result by the instrument specified in Equipment Instance Identifier (see above).

4.4.3 Addition OBX usage

4.4.3.1 Use of OBX for Specific Information

Instead of using prohibited message types and trigger event codes beginning with the letter “Z (conformance point HL7au:000020), the OBX segment offers sufficient versatility to cover the majority of requirements for localised content. The combined use of OBX-2 Value type and OBX-3 Observation identifier can be used to structure the type and format of the information. For example if the height and/or weight of the patient are required they would be transmitted as:

4.4.3.2 Use of OBX with Formatted Text (FT) in Headings

When an OBX segment contains Free Text (FT) data the value of OBX-3 Observation Identifier is not displayed to the user and the text is displayed across the full width of the users display window to allow for a minimum of 80 columns of text to be displayed. If fillers wish a heading to be displayed in association with FT OBX segments the heading text should be included within OBX-5 as part of the FT data. Systems displaying results should ensure that there is a minimum of 80 columns of displayable text and should also use a non proportional font to allow fillers to reliably format the text. Fillers have no control over the font used for display, but can assume that it is non proportional and there is sufficient room for 80 columns of character data to display without word wrapping.

4.5 Display Segments

Australia uses an extension to the HL7 conventions by including at least one, but potentially many OBX segments that contain a display orientated version of the data included in the message. Ideally the data should be transmitted in atomic form as well as a display orientated form, but in some cases only the display orientated data is transmitted. (In which case the display segment will be the only OBX segment present) These OBX segments are positioned as the last OBX segments and can be identified by the use of the coding scheme "AUSPDI" in OBX-3 Observation Identifier, Name of Coding System. There are multiple potential formats that the display orientated version of the data can be transmitted but all display segments should be equivalent and contain a rendering of all the data and (if atomic data is present) should not contain clinical results not included in the atomic data. For each display format there must be only one 'AUSPDI' OBX segment. The potential formats are given in the following table.

See conformance points section HL7au:000008.

Display Format codes

• Only the Code and Coding System are significant and the text may be absent or vary from what is shown.
• *PIT display is deprecated and will be removed in future standards. Note that references to PIT are left in with "strikethrough" styling here to alert readers to its existence and that it is currently used in practice although not recommended for use by senders, receivers may find that they need to support it for practical reasons.

All sending systems should make at least one display format available to the user as it provides for a display format of the results that the pathologist is confident will convey the intended significance of the results. Due to limitations in receiving systems it is recommended that a text based format be included as one of the available display segments.

For receivers, when a display segment is shown, earlier atomic OBX segments should not be rendered (See HL7au:000008.1.6). Where there is one or more display segments available only one should be visible at a time, however the system must allow users to access the alternative formats provided. See HL7au:000008.1.1.

4.5.1 Using the PIT display format

This has been widely used in the past and is likely to be seen for some time, but is being phased out in favor of other formats. It does allow colour based highlighting and is lightweight.

Only the display lines of the PIT format should be used and applications should not depend on the patient demographics or copy doctors being present and these details should be obtained from the HL7. As in every field reserved HL7 characters and line breaks need to be escaped.

Example:

OBX|3|FT|PIT^Display format in PIT^AUSPDI||301 \.br\301 B12 - Folate\.br\301 \.br\301 \.br\301 \.br\301 Testing\.br\309   \.br\319   \.br\390 End of Report  :\.br\||||||F

4.5.2 Using RTF Display format.

If this format is used the range of rtf supported by PMS systems may be much less than is supported by MS Word and only basic rtf features should be used. Senders SHOULD base64 encode the rtf as shown below as rtf can contain binary data outside the ASCII character set and usually contains many characters requiring escaping inside HL7.

Example:

OBX|2|ED|RTF^Display format in RTF^AUSPDI||MERIDIAN&MERIDIAN:3.1.2 [win32-i386]&L^TEXT^RTF^Base64^e1xydG...FsIE9iamVjdHN9||||||F

(Note that the RTF base64 encoded data has been shortened for display and is incomplete).

4.5.3 Using the HTML display Format

The html format uses xhtml and the details regarding the format of the html are given in the Appendix. xHTML display data should be base64 encoded in an ED segment. The xhtml should be valid xml. Any html display segment SHOULD be displayed with a compliant browser control. These are available of virtually all platforms an ensure reliable display of compliant xhtml. When handled correctly xhtml is the most inter-operable of all formats.

Example:

OBX|5|ED|HTML^Display format in HTML^AUSPDI||ECLIPSE&ECLIPSE:3.1.2 [win32-i386]&L^text^HTML^Base64^PGRpdj48ZG...+PC9kaXY+PC9kaXY+||||||F

4.5.4 Using the PDF Display format

While PDF is considered inter-operable there are issues with reliable display with various toolkits on different platforms and any PDF documents should be tested on a variety of viewers on different platforms. Features such as Encryption, password protection and restrictions on copying/Printing SHOULD NOT be used. Care should be taken not to depend on Fonts that may not be available on all platforms.

Example:

OBX|6|ED|PDF^Display in PDF Format^AUSPDI||MERIDIAN&MERIDIAN:3.1.2 [win32-i386]&L^application^pdf^Base64^JVBERi0xLjM...OQ0KJSVFT0YNCg==||||||F

Using Display Format in Text

This mechanism uses the display abilities of HL7 Free Text to produce a rendering of the whole report. The only text formatting available is highlighting which is usually implemented in receiving systems as bold. Text display segments use a value type of FT and the usual escaping of delimiters and Free Text formatting commands.

4.6 Specific LOINC codes

4.6.1 Result Comments

NTE segments are not used in the Australian setting but comments about individual results (A single OBX) or a report (All OBX segments under a OBR Segment) are supported by the use of OBX segments with specific LOINC codes. Result Comments are in an OBX segment immediately following the result OBX and report comments are contained in an OBX segment at the end of the report but before the display orientated OBX segments detailed in Section 4.5. The LOINC code in a Comment OBX Segment (In OBX-3) allows differentiation between result and report comments. Ideally result comments should be linked to result by use of OBX-4 Observation Sub-ID as well as the position in the message.

Most Comment OBX segments are of type FT and no display of the code or text in OBX-3 is expected but comment OBX segments can be of other value types and OBX-3 should not be displayed in those cases either.

Example of report comment:

OBX|28|FT|8251-1^Generated comment^LN||\.br\May be suggestive of UTI in the presence of symptoms.\.br\||||||F

The value of OBX-3 "Generated Comment" SHOULD NOT be displayed as per FT display conventions.

4.6.2 Section Headings

In structured reports there may be a number of sections in a report and these OBX segments are defined by 2 specific LOINC codes

When these codes are used the display of OBX-3 should be suppressed and the Value component displayed as a heading. The value component is usually of type CE (Coded Entry) or ST (String). These LOINC codes are usually used in conjunction with the OBX-4 Observation SubID to allow repetition of the codes for multiple headings and nested sections.

Example of Section Heading:

OBX|2|CE|70949-3^^LN^CLUSTER^^EN 13606|1.1|70949-3^Clinical details^LN||||||F

4.6.3 Template Identifiers

When highly structured reports are used to report complex results such as Colorectal Cancer Histopathology the reports as based on a template. The template is identified by:

This OBX segment can be omitted from the display but for systems capable of interpreting the template provides an identifier for the template that the data confirms to. Any data in the list of OBX segments under the current OBR segment that has a OBX-4 Observation SubID starting with the SubID of the Template identifier OBX is a part of the templated data.

Example of Template Identifier:

OBX|1|RP|60572-5^^LN^ENTRY^^EN 13606|1|CEN.RCPA-ColorectalCancer.v3^Colorectal Cancer Structured Pathology Report&99A-4DD10FEE7661CBF6&L^TEXT^Octet-stream||||||F

4.7 Digital Signatures

ORU messages can be digitally signed and receiving systems should be aware of this even if the digital signature is not evaluated. The specification for digital signing of ORU messages is detailed in the Standards Australia Technical Specification HB 308-2011  "Location of digital signatures in HL7 V2 Messages"

4.8 Display of Atomic Data

While there SHOULD be a display version of the atomic data contained in a message there are many situations where display of atomic data is desirable. OBX segments carry a single atomic piece of data and the display conventions are mostly dependent on the OBX Value Type which specifies the Data Type of the atomic data. The data is presented in a name=value format and can be rendered in a band like or tabular format. There are a number of factors that influence the display, some are general to every OBX segment and some depend on the data types. If an application displays the atomic data these considerations apply.

General considerations:

OBX-2 Value type (ID) Application SHOULD support display of all the allowable value types.

OBX-8 Abnormal flags should be taken into consideration and atomic results with abnormal flags SHOULD be highlighted. If colour is used, then highlighting must be achived by an additional method not relying on colour to accomodate colour blind readers. The abnormal flags SHOULD be displayed and displayed immediately after any Numeric, Structured numeric, String or Coded data.

OBX-11 Observation result status (ID) will commonly be "F" for final, but could be for example "C" for corrected and this should be indicated to the user so they are aware that this result has a new value. HL7 table 0085 contains the possible values in this field and while some of them are unlikely to be displayed to a clinician, the display SHOULD provide an indication that the result is not the normal Final status.

OBX-14 Date/time of the observation (TS), if it is valued and different from the OBR value indicates that the clinically significant time (Date/time of collection for blood testing) differs from what is in the OBR and SHOULD be displayed with the value in the OBX to alert any clinician that this is the case

Specific Considerations:

When the OBX value Type is Free Text (FT) the value of OBX-3 (Observation identifier) should not be displayed. This is not the case for OBX-3 values of ST which should have the value of OBX-3 displayed.

When OBX-3 contains a LOINC Comment code (Section 4.6) OBX-3 is not displayed. Commonly comments will be FT which also suppresses the display, but it should be suppressed for other value types as well.

The display of Free Text (FT) data SHOULD use a non proportional font to allow data of separate lines to align. This display SHOULD allow for a minimum of 80 characters before any word wrapping occurs. Free Text that is specified as able to be wordwrapped should be word wrapped to make it visible to the user on one screen and not be hidden off the right hand side of the screen as one line of text.

When a RP datatype indicates and internet URL a mechanism should be provided for the user to open that URL if desired.

A mechanism SHOULD be provided for a clinician to view at least one of the available display formats if desired.

The identity of the original report Authors is provided by the OBR Filler order number which has a HD component as part of the EI datatype. This should be displayed as the authoring organisation. The result may have been forwarded by another organisation and the identity of the organisation that actually sent the result can be obtained from the MSH Sending Facility. While they are commonly the same it is not always the case.

For receiving systems, when one or more display segments are present in the OBR/OBX group, the system should default to show one of the available display segments, but may provide the user access to view the atomic information rendering.

4.9 Pathology terminology

Pathology terminology is published on the RCPA website and the National Clinical Terminology Service.

4.10 Units of measure

The following is a summary of chapter 6 Units of measure from the RCPA's Standards for Pathology Informatics in Australia (SPIA), for further detail refer to this document.

The preferred units of measure which are to be used in Australia are available by test on the RCPA website.

Common Australian Units of Measure with their UCUM representation and standard display form are available on the RCPA website see Preferred units list.

4.10.1 Summarised background

The Standards for Pathology Informatics in Australia (SPIA) aims to reduce variability in the usage of units and increase patient safety; the following Guiding Principles, Implementation and Standards are extracted from the Standards for Pathology Informatics in Australia (SPIA).

Note: Implementers should check the current version of Standards for Pathology Informatics in Australia (SPIA) on the RCPA website.

4.10.2 Guiding principles

1. The standardisation of units used for reporting pathology in Australia is desirable and achievable.

2. All standardised pathology terminology and associated units should be available in one place.

3. A single, test-specific, standardised unit of measure is preferred for use in reports from pathology laboratories.

4. Units should be represented in electronic messages in such a way that receiving systems can readily convert units under the clinical governance of the receivers.

5. The Unified Code for Units of Measure (UCUM) is to be used as the logical representation of units of measure in electronic messages (to allow for principle 4).

6. Numeric results should always have the appropriate units associated with them and they should never be displayed without them.

4.10.3 Implementation

Refer to Standards for Pathology Informatics in Australia (SPIA) section 6 units of measure:

• Units of measure should always be shown where a quantity is shown on pathology reports.
• The exception is where it is explicit that no units are used for a particular test such as Human chorionic gonadotropin qual.
• Pathology reports should use the units specified in the Standards for Pathology Informatics in Australia (SPIA) for those tests where units have been determined.
• A single, standardised unit of measure should be used for tests in reports from pathology laboratories.
• There may, however, be valid exceptions to this rule; 
  • • in a transition from one preferred unit to another 
    • where alternate units are required by legislation or regulation such as for a registry 
    • during a period of consensus building as to which will be the preferred unit, but this period should be as short as practical 
    • where a facsimile of an historic report is produced – historic data need not comply.
• Units should be represented in electronic messages in fields for units in such a way that receiving systems can readily convert units under the clinical governance of the receivers. The Unified Code for Units of Measure (UCUM) must be used where it is the intention to represent units in a computable form (see http://unitsofmeasure.org/).
• Where the unit is not specified here, UCUM should be used for the unit. UCUM lexical elements such as square brackets (‘[’ and ‘]’) can be removed in the display format for enhanced clarity. However, the fully defined UCUM syntax should be used in electronic messaging.
• Superscripts and subscripts should not be used in units.
• The caret symbol (^) should be used to represent “raised to a power of”. Care must be taken to appropriately “escape” and "unescape" the caret symbol (^) as this symbol is used as a component separator in HL7 messages. Refer to examples in clause G6.08. 
• Units raised to a power should be indicated in the preferred display unit by the exponent as an integer written immediately behind the unit term. For example, the preferred display unit for millilitre per minute per 1.73 square metre is mL/min/1.73m^2. Powers of ten should be represented by 10^ e.g. 10^12/.
  • • Display example:  
      • mL/min/1.73m^2  
      • 6.1x10^12/L  
    • Message example:  
      • ml/min/1.73m\S\2 
      • 6.1x10\S\12/L

4.11 SPIA Rendering of numeric results, ranges, units, previous results and flagging

The following is a summary of chapter 7 Rendering of numeric results, ranges, units, previous results and flagging from the RCPA's Standards for Pathology Informatics in Australia (SPIA), for further detail refer to this document.

4.11.1 Summarised background

The PITUS project did an initial survey to identify common practices and the variation in reporting across Australia.  A second survey looked at specific design issues related to cumulative reporting.  This data in-conjunction with literature findings on the benefits of standardised representation of data i.e. aviation and other industries, as well as considering other national programs (including the National Medication Chart) made recommendations for reporting in Australia.

The following Guiding Principles, Implementation and Standards are extracted from the Standards for Pathology Informatics in Australia (SPIA).

4.11.2 Guiding Principles

1. Missed or misunderstood test results as the consequence of poor rendering on paper or screen are as dangerous to patients as lost or wrong results.

2. The intention is not to stifle innovation in presentation through standardisation and so only those aspects of rendering where there is a concern around safety and broad support for standardisation were considered.

3. Numeric results are incomplete without associated units and guidance for interpretation (eg reference intervals) and so these must always be shown with the number.

4. Guidance values may be reference intervals, healthy limits or therapeutic ranges depending on the test.

5. Guidance values should be in the context (clinical history) of the subject of the report where this context is known and relevant.

6. Because errors are known to be made in reading and interpreting numbers and risk is reduced with consistency it is appropriate to standardise aspects of their presentation.

7. Further interpretation of results over time depends on knowing the latest results (and the direction of time) therefore when results are shown in columns, rows or graphically these must be consistent across disciplines and laboratories and the latest results must be differentiated from previous results.

8. Standards for the rendering of the pathology report must be practical and capable of implementation taking account of the different media and methods of display that are used.

9. Changes to configuration in the rendering of a report must be thoroughly tested in both printed and electronic format to ensure the report is displayed as intended by the receiver.

10.The rendering of the pathology report as the issuing laboratory intends it to be read must be sent by the laboratory in all electronic messages and be able to be displayed to the reader on screen or printed out.

11.Conveying meaning from one party to the other is dependent on appropriate testing of the different methods of display at both ends of the communication.

12.When reports are displayed on screen the latest results must be shown on the first display screen to avoid any chance of missing a latest result column or row that is off-screen.

13.Because around 4.5% of the population are colour blind and because some methods of communication remove colour, colour cannot be used as the only method for highlighting.

14. Multi-level flagging may be used

Implementation

An example of the application of the standards and guidelines for report rendering is shown for a columnar cumulative report in Figure 3 below.

• Numeric results must be right justified (when shown in columns) and have corresponding guidance values (e.g. reference interval) and units if these exist.
• Numeric results must have a leading zero where there is no number in the units place (i.e. 0.7 not .7).
• For columnar cumulative reports the latest result must be shown in the furthest right column of results (i.e. time must go from left to right across the page) or at the top for cumulative reports shown in rows (i.e. time must go from the bottom to the top of the page).
• The latest result must be differentiated from earlier results by at least two methods one of which is a heading ‘Latest Results’.
  • A box such as that shown in Figure 3 was favoured by 75% of survey respondents for columnar reports.
  • Bolding of the heading text was considered effective by the Committee.
• Guidance values must be bounded by parentheses and have no spaces.
• Italics should not be used.
• The column showing units must be headed ‘Units’, be left justified and be to the immediate right of the ‘Reference’ column.
• The numbers used for guidance must be rendered with the same number of decimal places as the related result.
• For some analytes, such as tumour markers, a result may be orders of magnitude above guidance in which case current practice for some laboratories is to adjust for significant figures because of concern at overstating precision. It is not known whether it is safer to do this or to adopt the number of decimal places for the low range result. If a different number of decimal places is used at different concentrations, the guidance should be rendered to the same number of decimal places as the results of a similar magnitude to the guidance values.
• Results are considered outside the guidance values if after rounding to the format of the displayed result (and the guidance) the result is greater than the higher number or less than the lower number of the guidance values. S7.10  Results outside the guidance values must be highlighted by at least two methods one of which is either an ‘L’ or ‘H’ one space to the right of the result (‘L’ for a result lower and ‘H’ for a result higher).
• A single asterisk (‘*’) and the ‘+’ and ‘-‘characters should not be used for flagging results
• Underlining of results should not be used for highlighting results
• Colour was preferred by most respondents in the survey but because of colour blindness and possible loss of colour in some communications, if colour is used, then the font should also be bolded.
• Multi-level flagging may be used in which case ‘LL’ or ‘HH' should be used for the second level.
• Headings must be differentiated from test names.
• Dates must be shown in the form 30-Jan-14 (i.e. not in the form 30/01/14).

4.12 Harmonised reference intervals

The following is a summary of chapter 8 Harmonised reference intervals from the RCPA's Standards for Pathology Informatics in Australia (SPIA) for further detail refer to this document.

A set of harmonised reference intervals for reporting pathology in Australia (and New Zealand) is available on the RCPA website. These reference intervals are by age and sex where appropriate and include values used in paediatrics.

4.12.1 Summarised background

Scientific evidence supports the use of common reference intervals for many general chemistry analytes, in particular those with sound calibration and trace ability in place. The harmonisation working group of the AACB developed a number of common reference intervals for chemical pathology tests for routine use for adults and children in Australia.

The following Guiding Principles, Implementation and Standards are extracted from the Standards for Pathology Informatics in Australia (SPIA).

4.12.2 Guiding principles

1. Guidance values should be evidence based but as simple and consistent as real biological variation and good medical practice allows.

2. Because common usage for analyte reference limits has both the low and high values included while for age limits the higher value is not included, to avoid any confusion in interpretation of boundary conditions these need to be represented in different ways in reports and tables used outside the laboratory.

3. There is as yet no international standard for representing age intervals and the committee proposes the format ‘1w to <12y’ to show the time interval in a table or on a report. This was done to avoid confusion on reading and with the meaning of mathematical notation.

4. The same method for representing age intervals must be used for adults and children.

4.12.3 Implementation

The aim is to have the proposed intervals used as widely as possible within Australia (and New Zealand). The responsibility for use of the intervals lies with the Laboratory Director but the NATA 15189 field application document supports consideration of the use of common reference intervals such as those referenced here.

Laboratories should however ensure the intervals are appropriate for their methods and population by a combination of the following activities: 

• Demonstrating that the methods in use can demonstrate low bias against international reference methods or material, or against the methods used in the Bias study; 
• Validating by a CLSI-based protocol measuring 20 or more samples from healthy persons; 
• Using data mining techniques to show minimal bias of the midpoint of their population as well as flagging rates (% high and low) similar to other laboratories.

Where reference intervals other than those provided here are used, laboratories should document their reasons and the evidence that alternate intervals are preferable

• Age intervals are calculated in days from date of birth to date of collection starting with day 0 being the day of birth with the result always rounded down.
• Age intervals must be rendered using days, weeks or years (but not months) in the form shown in the Table below. The Table also provides the interpretation of time ranges for common age intervals.
• mixture of days, weeks and years is permissible where it is appropriate (e.g. ‘7d to <10y’).

4.14 Pathology Specialisations

4.14.1 Histopathology

For histopathology reports that do not comply with the RCPA structured cancer protocol, the body of the report should be in an OBX segment using an FT data type.  If a conclusion is included in the report it should be coded using a CE data type. However, if a suitable code is not available, then it is acceptable to transmit free text in the second component of the CE data type.

4.14.1.1 Structured cancer reporting

Significant work has been done by the RCPA in developing structured cancer protocols.  These protocols are shown in a HL7 V2.4 format:

Example -  refer to Example: Structured reporting of colorectal cancer.

Note:

1. Dot notation is used in OBX-4 Observation sub-ID to indicate a hierarchy of headings, data groups and data elements

More recently in the RCPA PITUS 15-16 working group 5 "Report modelling for safe atomic reporting to registries" have progressed FHIR artefacts which are then transported in a HL7 V2.4 message. The initial work is based on the colorectal cancer protocol and the prostate (radical prostatectomy) cancer protocol and is available at http://fhir.hl7.org.au/fhir/rcpa/index.html.

4.14.2 Blood bank

In the OBX segments, the same LOINC code is used to indicate the item eg unit of blood or fresh frozen plasma etc, and OBX-4 Observation sub-ID is used to indicate the separate units of red cells or fresh frozen plasma etc.

MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY^L|Hospital Pathology^2112^AUSNATA|||20070620221113+1000||ORU^R01^ORU_R01|51150420.834715|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL||AUS
PID|1|...
PV1|1|O||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN
ORC|RE||05-6690882-URC-0^Hospital Pathology^2112^AUSNATA||CM|||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN
OBR|1||05-6690882-URC-0^Hospital Pathology^2112^AUSNATA|XM^CROSS MATCH^NATA2112|||200706011300+1000|||||||200706011928+1000||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||||DR=MME,LN=05-6690882,RC=Y||200706011642+1000||MB|F||^^^200706010000+1000|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||||Reporting Pathologist
OBX|1|ST|882-1^ABO+RH GROUP^LN||O Rh(D) Positive||||||F|||200706022316+1000
OBX|2|FT|888-8^ANTIBODIES IDENTIFIED^LN||Anti-K antibodies detected.\.br\\.br\ Anti-E antibodies detected. \.br\\.br\||||||F|||200706022316+1000
OBX|3|ST|14577-1^ABO+RH GROUP^LN|1|2322112 A Rh(D) Positive||||||F|||200706022316+1000
OBX|4|ST|14577-1^ABO+RH GROUP^LN|2|2322112 A Rh(D) Positive||||||F|||200706022316+1000
OBX|5|ST|14577-1^ABO+RH GROUP^LN|3|2322112 A Rh(D) Positive||||||F|||200706022316+1000
OBX|6|FT|15412-0^Service Comment^LN||The following units(s) have been found to be \.br\compatible with this patient.||||||F|||200706022316+1000

4.14.3 Microbiology example    

In Microbiology there may be multiple organisms isolated and each organism can have sensitivities specific to each isolate. This is reported under one OBR segment and the organism and its sensitivities are linked by using "1" for the Sub-ID fore first organism and "2" for the Sub-ID for the second organism etc. This links the relevant data together for machine processing even though the same OBX-3 (Observation Identifier) may be used multiple times. A microbiology example is below.

MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY^L|Acme Pathology^1001^AUSNATA|||20150420221113+1000||ORU^R01^ORU_R01|20150420.123321|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL||AUS
PID|1|...
PV1|1|O||||||01234567W^BROWN^Bill^^^DR^^^AUSHICPR^L^^^UPIN|01234567W^BROWN^Bill^^^DR^^^AUSHICPR^L^^^UPIN
ORC|RE||03-7654321-URC-0^Acme Pathology^1001^AUSNATA||CM|||||||01234567W^BROWN^Bill^^^DR^^^AUSHICPR^L^^^UPIN
OBR|1||03-7654321-URC-0^Acme Pathology^1001^AUSNATA|URC^URINE MICRO^L|||201503081300+1000|||||||201503081928+1000||01234567W^BROWN^Bill^^^DR^^^AUSHICPR^L^^^UPIN||||DR=MME,LN=03-7654323,RC=Y||201504181642+1000||MB|F||^^^201503080000+1000|01234564W^GREEN^Wilma^^^DR^^^AUSHICPR^L^^^UPIN||||Reporting Pathologist
OBX|1|ST|19159-3^Collection Method^LN||Mid stream urine||||||F|||201503082316+1000
OBX|2|ST|25428-4^Glucose^LN||Negative||||||F|||201503082350+1000
OBX|3|ST|2514-8^Ketones^LN||Negative||||||F|||201503082350+1000
OBX|4|ST|20454-5^Protein^LN||+||||||F|||201503082350+1000
OBX|5|NM|30405-5^Leucocytes^LN||40|10*6/L^10*6/L^UCUM|<10|+|||F|||201503090015+1000
OBX|6|NM|30391-7^Erythrocytes^LN||20|10*6/L^10*6/L^UCUM|<10|+|||F|||201503090015+1000
OBX|7|SN|30383-4^Epithelial cells^LN||<^10|10*6/L^10*6/L^UCUM|||||F|||201503090015+1000
OBX|8|ST|8269-3^^LN|1|Organism 1||||||F
OBX|9|CE|630-4^Bacteria Identified^LN|1|40886007^Klebsiella oxytoca^SCT|||A|||F
OBX|10|SN|19090-0^Colony Count^LN|1|>^10|||A|||F
OBX|11|ST|18864-9^Amp/Amoxycillin^LN|1|R|||R|||F
OBX|12|ST|18862-3^Amoxycillin+Clavulanic acid^LN|1|R|||R|||F
OBX|13|ST|18897-9^Cephalexin^LN|1|R|||R|||F
OBX|14|ST|18955-5^Nitrofurantoin^LN|1|R|||R|||F
OBX|15|ST|18956-3^Norfloxacin^LN|1|S|||S|||F
OBX|16|ST|18997-7^Trimethoprim^LN|1|R|||R|||F
OBX|17|ST|18928-2^Gentamicin^LN|1|S|||S|||F
OBX|18|ST|8270-1^^LN|2|Organism 2||||||F
OBX|19|CE|630-4^Bacteria Identified^LN|2|73457008^Protues mirabilis^SCT|||A|||F
OBX|20|SN|19090-0^Colony Count^LN|2|>^100|||A|||F
OBX|21|ST|18864-9^Amp/Amoxycillin^LN|2|R|||R|||F
OBX|22|ST|18862-3^Amoxycillin+Clavulanic acid^LN|2|S|||S|||F
OBX|23|ST|18897-9^Cephalexin^LN|2|S|||S|||F
OBX|24|ST|18955-5^Nitrofurantoin^LN|2|S|||S|||F
OBX|25|ST|18956-3^Norfloxacin^LN|2|S|||S|||F
OBX|26|ST|18997-7^Trimethoprim^LN|2|R|||R|||F
OBX|27|ST|18928-2^Gentamicin^LN|2|S|||S|||F
OBX|28|FT|8251-1^Generated comment^LN||\.br\May be suggestive of UTI in the presence of symptoms.\.br\||||||F

4.15 Registry reporting

Notifiable conditions are under review by the PITUS working group and are one kind of registry reporting. 

Notifiable diseases are to be reported to the respective state authority or notifiable diseases register.

4.16 Encoding URLs into RP datatype

URLs to external resources can be encoded into an RP datatype using the following method:-

The URL address is composed of scheme | server | application path | data path | query parts.

URL's are represented in the RP data type where the URL address is split into 2 parts:

1) the application part of the URL address: scheme | server | application path

2) the data pointer part of the URL address: data path | query

4.16.1 Histopathology

A histopathology image on a web server at:

https://labtest.com.au/mylabapp/data%20path/id/2016F0001000-1?view=jpegrender&mode=online

We will match the URL parts as follows:

These parts would be encoded into a RP datatype as follows:

|/data%20path/id/2016F0001000-1?view=jpegrender\T\mode=online^&https://labtest.com.au/mylabapp&URI^image^jpeg|

NB. The '&' in the query part is encoded as "\T\". (This is because reserved characters in data should be escaped when written and de-escaped when read from HL7 messages.)

4.16.2 Radiology

Example 4.16.2:

A radiology report on a web server at:

https://images.rad.com.au/imageserver?Parameter1&Parameter2=Value2

This then would be encoded into an OBX as follows:

OBX|2|RP|55113-5^Radiology Images^LN||?Parameter1\T\Parameter2=Value2^&https://images.rad.com.au/imageserver&URI^text^html

4.17 Reconciling pathology orders and observation messages

4.17.1 Introduction

There is not always a direct reconciliation between an order and the observation in the report.  This may be due to many scenario's including:

• The request test may have multiple components that are reported.
• Multiple requested tests may be reconciled with the completion of an individual test or different group of tests.
• The requested test may be superseded by a better test.
• Reflex or self determined types tests added by the pathology provider
• Different coding systems are used for requesting and reporting

Hence, the use of the correlation between the placer order number and the requested test provides the most suitable way of determining if an order has been completed. This process does not rely on matching order codes with result codes which are quite often different.

4.17.2 Reconciling Results

Generally the placer systems may expect that result test codes match the ordered test codes; however when this does not occur the following process is followed to align tests ordered and results received.

1. Filler systems are to transmit results as they have historically reported them;
2. Placer systems are to receive result test codes for matching to the ordered test code; and 
3. Placer systems are to accept additional test codes as a consequence of:
   1. rationalised order/result reporting by the filler;
   2. added tests as determined by the filler; or
   3. report copies requested by another doctor.

The general rules for reconciling tests ordered and resulted are:

1. When ordered tests codes match the result test codes then the results are returned as expected.
2. When the ordered test codes do not match the result test codes, the ordered test codes are returned as completed, but with no associated results, then followed immediately by the corresponding result test with the associated results.
3. Add-on tests can only be returned as an extra result test code. 

Basic method - if there is an OBR segment with no associated OBX segments then the order is marked off as complete and results are looked for in the first immediately following OBR/OBX segment set.

This methodology is demonstrated in the following examples:

An order is sent to the pathology laboratory for these tests:

• Haemoglobin (Hb) and white cell count (WCC)
• Urea and Electrolytes (UE)
• Magnesium
  
  

With the following order message:

MSH|...|ORM^O01^ORM_O01
PID|
ORC|NW|P41234^98765432^DRS^L||PG4567^98765432^MDW^L
OBR|1|P41234^98765432^DRS^L||271026005^Hemoglobin level estimation^SCT|....
ORC|NW|P41235||PG4567|
OBR|2|P41235||767002^White blood cell count^SCT|
ORC|NW|P41236||PG4567|
OBR|3|P41236||444164000^Urea, electrolytes and creatinine measurement^SCT|
ORC|NW|P41237||PG4567|
OBR|4|P41237||63571001^Magnesium measurement, serum^SCT|

The pathology provider will respond with the the following ORR^O02 message - ignoring the two-stage acknowledgement for this scenario: 

MSH|...|ORR^O02^ORR_O02
MSA|AA|
PID|
ORC|OK|P41234|F98765|PG54321|
OBR|1|P41234|F98765|271026005^Hemoglobin level estimation^SCT|
ORC|OK|P41235|F98766|PG54321|
OBR|2|P41235|F98766|767002^White blood cell count^SCT|
ORC|OK|P41236|F98767|PG54321|
OBR|3|P41236|F98767|444164000^Urea, electrolytes and creatinine measurement^SCT|
ORC|OK|P41237|F98768|PG54321|
OBR|4|P41237|F98768|63571001^Magnesium measurement, serum^SCT|

The Pathology provider receives and evaluates the order and processes the request as follows:

1) A Full Blood Count (FBC) is used to replace the HB and WCC

2) A Urea, Electrolytes and Glucose (UEG) is done instead of a UE to provide more information to the requester with minimal additional cost to the pathology provider.

3) A magnesium (MG) test is done for the MG serum test i.e. the request ordered is the test being performed.

4) A moderately elevated glucose is identified, so the laboratory adds an additional haemoglobin A1c (HbA1c).

The laboratory will report the results depending on the processing within the organisation, so there could be some variation in the order.  It is normal for each result to be reported within its own message.

The following is the format used when the results are being reported for the first time. If there is a correction to a result and the test is re-reported then it is not necessary for the (ORC/OBR) message set to contain the initial OBR segments from the examples below which indicate that the ordered tests are complete. That is, it is optional to leave them out. For further information on corrected results refer to section OBR-25 Result status (ID) above.

The (OBR/OBX) segment set containing the atomic results is for a procedure substituted by the filler that replaces one or more procedures ordered by the placer. Therefore, no Placer Order Number is available, because the placer has no knowledge of this order prior to this transaction. The placer would post this as an unsolicited result.

Scenario 1:

When the test code for the result being reported is different to the test being requested then the OBR segment for the actual result is preceded by the OBR segments showing which orders are being replaced by this result.

In this case there are 2 requested tests (Hb and WCC) that have been combined and reported with a different test (FBC) code.

NOTES:
1 The ORC segment does not contain the Placer Order Number as two orders are being reported within a single ORC segment. The immediately following OBR segments return the Placer Order Number and the test/procedure code for tests/procedures that have been ordered by the placer but will be reported by the filler as part of another procedure. The OBR-25 Result Status of F indicates that this order is complete and that the placer can mark the order accordingly. 
2 It is imperative that you mark the orders indicated by these OBR segments as complete as this is the only indication that you will receive with regard to these Placer Order Numbers. The group of orders indicated by the Placer Group Number in the ORC segment may not yet be complete so the ORC-5 Order Status will not necessarily contain ‘CM’.
3 The immediately following set of OBR and OBX segments contain the atomic results for the tests/procedures directly ordered by the placer. Correspondingly there is no Placer Order Number in the OBR segment, as the test/procedure was not ordered—it is a replacement for the tests/procedures in the two immediately preceding OBR segments. The OBR-25 Result Status has a value of ‘F’ to indicate that the result is complete.
4 In this case the Filler Order Number for ‘OBR|3|..’ contains the laboratory number.

MSH|...|ORU^R01^ORU_R01
PID|
PV1|
ORC|RE|||PG54321|
ORC|RE|P41234^98765432^DRS^L|01-8615014-CBC-0^NATA^2184^N|PG54321^98765432^DRS^L|CM
OBR|1|P41234^98765432^DRS^L|01-8615014-CBC-0^NATA^2184^N|271026005^Hemoglobin level estimation^SCT|||||||||||||||||||||F (Placer order is complete)
ORC|RE|P41234^98765432^DRS^L|01-8615014-CBC-0^NATA^2184^N|PG54321^98765432^DRS^L|CM
OBR|2|P41234^98765432^DRS^L|01-8615014-CBC-0^NATA^2184^N|767002^White blood cell count^SCT|||||||||||||||||||||F|(Placer order is complete)
OBR|3||01-8615014-CBC-0^NATA^2184^N|26604007^Full blood count^SCT||..|F| (Replacement test of results)
OBX|1|ST|15430-2^^LN||FULL BLOOD EXAMINATION||||||F
OBX|2|NM|718-7^Haemoglobin^LN||131|g/L^^ISO+|135-180|-|||F
OBX|3|NM|789-8^Red Cell Count^LN||4.2|x10*12/L^^ISO+|4.2-6.0||||F
OBX|4|NM|4544-3^Haematocrit^LN||0.38||0.38-0.52||||F
OBX|5|NM|787-2^Mean Cell Volume^LN||91|fL^^ISO+|80-98||||F
OBX|6|NM|785-6^Mean Cell Haemoglobin^LN||31|pg^^ISO+|27-35||||F
OBX|7|NM|777-3^Platelet Count^LN||249|x10*9/L^^ISO+|150-450||||F
OBX|8|NM|6690-2^White Cell Count^LN||15.0|x10*9/L^^ISO+|4.0-11.0|++|||F
OBX|9|NM|770-8^Neutrophils^LN||88|%|||||F
OBX|10|NM|751-8^Neutrophils^LN||13.2|x10*9/L^^ISO+|2.0-7.5|++|||F
OBX|11|NM|736-9^Lymphocytes^LN||4|%|||||F
OBX|12|NM|731-0^Lymphocytes^LN||0.6|x10*9/L^^ISO+|1.1-4.0|-|||F
OBX|13|NM|5905-5^Monocytes^LN||6|%|||||F
OBX|14|NM|742-7^Monocytes^LN||0.9|x10*9/L^^ISO+|0.2-1.0||||F
OBX|15|NM|713-8^Eosinophils^LN||2|%|||||F
OBX|16|NM|711-2^Eosinophils^LN||0.30|x10*9/L^^ISO+|0.04-0.40||||F
OBX|17|NM|706-2^Basophils^LN||0|%|||||F
OBX|18|NM|704-7^Basophils^LN||0.00|x10*9/L^^ISO+|< 0.21||||F
OBX|19|FT|5909-7^Interpretation^LN||Red cells are normochromic

and…..

This completes the haematology results and reporting.

Scenario 2:

This example illustrates a where a different test code is substituted for the requested test. This is similar to the first scenario except that in this scenario there is a one to one replacement of test codes.

The UE requested is replaced by a more informative UEG by the pathology provider as part of the laboratory policy to value add where they can with minimal cost implications.

MSH|...|ORU^R01^ORU_R01
PID|
PV1|
ORC|RE|||PG54321|
OBR|1|P41234|F98765||||||||||||||||||||||F (Placer order is complete)
OBR|2||01-8614957-UEG-0^NATA^2184^N|UEG^ELECTROLYTES UREA GLUCOSE^2184|||...|F (substitute for the ordered test)
OBX|1|ST|15428-6^^LN||SERUM CHEMISTRY||||||F
OBX|2|NM|2951-2^Sodium^LN||128|mmol/L^^UCUM|137-147||---|||F
OBX|3|NM|2823-3^Serum Potassium^LN||4.2|mmol/L^^UCUM|3.5-5.0||||F
OBX|4|NM|2075-0^Chloride^LN||97|mmol/L^^UCUM|96-109||||F
OBX|5|NM|1963-8^Bicarbonate^LN||19|mmol/L^^UCUM|25-33|---|||F
OBX|6|NM|1863-0^Anion gap^LN||16|mmol/L^^UCUM|4-17||||F
OBX|7|NM|14749-6^Glucose random^LN||9.0|mmol/L^^UCUM|3.0-5.4||||F

NOTE: The ORC segment does not contain the Placer Order Number as the test/procedure code being reported was not ordered. The immediately following OBR segment returns the Placer Order Number and the test/procedure code for the replacement  test/procedure. This process is similar to scenario 1.

Scenario 3:

In this scenario the test resulted is the same the the test ordered; hence there no combining or replacing of test codes as per scenario 1 and 2.

The ORC fields are populated and there is only a single OBR segment.

MSH|...|ORU^R01^ORU_R01
PID|
PV1|
ORC|RE|P41237|F98768|PG54321|CM
OBR|1|P41237|01-8614957-MG-0^NATA^2184^N|63571001^Magnesium measurement, serum^SCT
OBX|1|NM|2601-3^Magnesium^LN||0.95|mmol/L^^UCUM|0.70-1.10||||F

Scenario 4:

A test that has not been requested is added by the pathology provider and hence no order exists in the placer system. This test must be added as an unsolicited test using the Placer Group Number. 

MSH|...|ORU^R01^ORU_R01
PID|
PV1|
ORC|RE|||PG54321|
OBR|1||01-8614957-A1C-0^NATA^2184^N|43396009^Hemoglobin A1c measurement^SCT|
OBX|1|NM|4548-4^HbA1c^LN||8.0|%^^UCUM|<7.0||||F

NOTE: A similar situation exists where the placer system receives results as a consequence of being nominated as a copy doctor by another site. However, in this case, the Placer Group Number is not relevant either and procedures must be in place to manage it.

Scenario 5 -an unavailable result:

A result may be unavailable due to a number of factors including:

• insufficient specimen - where specimen was collected the patient or the requester or circumstances prevent the laboratory from recollecting.
• sample degraded in collection or processing including transport to the laboratory
  

In this case the OBX segment for the unavailable result may be suppressed or it can be reported as follows.

In either case a comment will be attached to indicate the situation. For this reason the result item has to be returned because the comment is attached to that item.
OBX-2 value type is null

OBX-11 Result status is ‘X’. Refer HL7 V2.4, Section 7.4.2.2. Using HL7 Table 0085 - Observation result status codes interpretation

Example: Potassium result is not available.

OBR|2||01-8614957-UEG-0^NATA^2184^N|UEG^ELECTROLYTES UREA GLUCOSE^2184|||...|F (substitute for the ordered test)
OBX|1|ST|15428-6^^LN||SERUM CHEMISTRY||||||F
OBX|2|NM|2951-2^Sodium^LN||128|mmol/L^^UCUM|137-147||---|||F     
OBX|3||2823-3^Serum Potassium^LN|||mmol/L^^UCUM|3.5-5.0||||X    (Note: no value for value type i.e. OBX-2 and Result status (OBX-11) value is "X")
OBX|4|... 
OBX|3|FT|15412-0^Service Comment 21^LN||\.nf\Specimen haemolysed and unable to be recollected||||||F|

Alternatively, a value of |""| (no result and update field in database) as opposed to ‘null’ (no result and do not update data base field) may be used. If the |""| format is used then OBX- 11 will not contain ‘X’ as OBX-2 is valued.

OBX|3|NM|2823-3^Serum Potassium^LN||""|mmol/L^^UCUM|3.5-5.0||||F

4.18 Matching Patient Identifiers

A pathology provider will want to match the patient identifier to enable the provision of cumulative results which provides more information over time than just a snapshot and Medicare has rules on some tests regarding the frequency a test can be ordered over a period of a specific period of time.  The pathology results receiver will want the patient identifier to match results on a patient where the order originated from another provider eg copy to doctor, to determine if it is an existing patient or a new patient to their patient management system. It is therefore useful to the receivers of the request or the results to receive as many patient identifiers as possible.

The PID-3 field Patient Identifier List is to be used for patient identifiers and the field PID-18 Patient Account Number is to be used when the patient account details are needed. PID-18 is a CX datatype and the type code is not required due to the uniquely titled field. 

Other PID fields such as PID-2 External Identifier, PID-4 Alternate Identifiers, PID-19 SSN Number and PID-27 Veteran's Military Status are no longer used in the Australian context and PID-3 should be used instead.  PID-3 is also a CX datatype - refer to examples in Table 6-1. Examples.

4.19 Reporting corrected results

Flagging of results is accommodated at both the individual observation level and the report level. Comments generally apply to the report and the placer systems act on the basis of the report. Normally only final results flagged with an "F" are transmitted and are indicated in OBR-25 Result Status - refer to HL7 table 0123 Result status for valid values.

A corrected result (an amendment of a previous final result) will be flagged in OBR-25 with a "C" as will the relevant OBX-11 segment be flagged with a "C". The unchanged OBX segments of the results will contain the normal "F" flag. All OBX segments are to be re-transmitted, not just the corrected ones and the OBR segment should be marked as Corrected when any OBX segments are corrected.

Note: A corrected report may not necessarily have an associated corrected OBX segment as an additional result or comment may have been added by a scientist/pathologist and this additional result will be flagged with a "C".

For a pathology example, the Potassium result has been corrected below:

OBR|2||01-8614957-UE-0^NATA^2184^N|444164000^ Urea, electrolytes and creatinine measurement^SCT|||...|C
OBX|1|ST|15428-6^^LN||SERUM CHEMISTRY||||||F
OBX|2|NM|2951-2^Sodium^LN||128|mmol/L^^UCUM|137-147||---|||F
OBX|3|NM|2823-3^Serum Potassium^LN||4.0|mmol/L^^UCUM|3.5-5.0||||C
OBX|4|NM|2075-0^Chloride^LN||97|mmol/L^^UCUM|96-109||||F
OBX|5|NM|1963-8^Bicarbonate^LN||19|mmol/L^^UCUM|25-33|---|||F
OBX|6|NM|1863-0^Anion gap^LN||16|mmol/L^^UCUM|4-17||||F

When results are corrected and sent, and then further corrections are made and sent in a second transmission, only the results that were corrected for the second transmission are flagged as being corrected. That is, the originally corrected items are not flagged a second time.

Example:
If in the above pathology example, the Bicarbonate is corrected after the Potassium correction is sent, then in the second transmission only the Bicarbonate is marked as Corrected.

OBR|2||01-8614957-UE-0^NATA^2184^N|444164000^ Urea, electrolytes and creatinine measurement^SCT|||...|C
OBX|1|ST|15428-6^^LN||SERUM CHEMISTRY||||||F
OBX|2|NM|2951-2^Sodium^LN||128|mmol/L^^UCUM|137-147||---|||F
OBX|3|NM|2823-3^Serum Potassium^LN||4.0|mmol/L^^UCUM|3.5-5.0||||F
OBX|4|NM|2075-0^Chloride^LN||97|mmol/L^^UCUM|96-109||||F
OBX|5|NM|1963-8^Bicarbonate^LN||20|mmol/L^^UCUM|25-33|---|||C
OBX|6|NM|1863-0^Anion gap^LN||16|mmol/L^^UCUM|4-17||||F

4.20 Linking results to comments

Comments can be associated with results and more generally with the report.  To indicate which is being referenced the following protocol is used:

4.21 Processing FT value types in OBX segments

Both sending and receiving sites need to take care when a value type FT in an OBX segment is transmitted.

In the following example, it would indicate that the OBX-3 Observation Identifier should be discarded and only OBX-5 Observation value formatted and displayed as per embedded formatting content.

OBX|10|FT|8251-1^SERVICE COMMENT 01^LN||POTENTIAL DIGOXIN TOXICITY.\.br\ Nausea, vomiting, diarrhoea and blurred vision may be noted at this level.\.br\||||||F

If pathology providers require OBX-3 Observation Identifier to be displayed then the value type (OBX-2) should be ST and not FT. In the example above, if ST is used any embedded FT formatting, including line breaks,  will not be available. Alternatively the heading text can be included with the FT value.

Pathology providers should ensure that any short result lines (e.g. < 50 characters) of the ST datatype should not contain embedded formatting controls.  

4.22 Using OBR user defined fields in the Australian context

The HL7 V2.4 data model does not accommodate all the possible use cases required and hence OBR-18 Placer field 1, OBR-19 Placer field 2, OBR-20 Filler field 1 and OBR-21 Filler field 2 have been provided for free use for placers and fillers. These fields enable specific processing that is not handled elsewhere in the HL7 V2.4 standard. Each of these fields are two components i.e. "code=value", where the code defines the element and the second item value is the relevant value for that code. Within the field the repeating sets are separated by a comma (',')  but this is not a HL7 repeat, but is encoded within the text.

|code=value,code=value,code=value,………|

In the Australian context the following elements are defined for OBR-20.

4.23 Tracking Result Identifiers

Although a laboratory will often track a request internally using their lab number, the lab number is not allocated until the specimen has been collected and is therefore only useful as a component of the Filler Order Number. While the lab number will be the same for all specimens received together, each individual battery will have a unique Filler Order Number. This is often achieved by appending text to the lab number, but practices may vary.

When an electronic request is made the order will be transmitted to the laboratory, the laboratory must respond with with a Filler Order Number: If the order contains more than one order on the same request ie same Placer Group Number then the laboratory must respond with the same number of order responses. 
The preferred response is to respond immediately to the order with an ACK message and transmit an ORR message with a Filler Order Number when the specimen is received.
An optional method is for the laboratory to hold the order and not respond until the specimen has been received by the laboratory and the lab number can be used as one part of the Filler Order Number. 

The order becomes activated when the laboratory number is is entered enabling the order response message to be sent to the placer using the laboratory number as part of the Filler Order Number, e.g. 'LAB-9876543-LFT', 'LAB-9876543-UEG' where the test suffix differentiates the orders on the same request. When several identical tests are done under the same lab number a specimen number is often appended to ensure each result has a unique fille order number.

Results returned to the placer of the electronic order will contain the Placer Order Number where relevant and both the Placer Group Number and the Filler Order Number to link results to the order along with the laboratory number enabling the placer (surgery/GP) to follow up with any queries to the laboratory.  For results transmitted to the non-requesting provider e.g. a copy to Dr, the Placer Group Number is included, but not the Placer Order Number or the Filler Order Number. 

4.24 Messaging negative numbers

It is important to be able to represent negative numbers in messages as the "-" character is the same used for both negative numbers and a hyphen separator e.g. in reference ranges.  Negative numbers must not have a space between the sign and the number. 

Parsing on a "-" character can be dangerous as there could be confusion with the negative number and the hyphen between the two reference  range values.

A negative reference range is presented as:

OBX|7|NM|1555-0^Base Excess in blood by calculation^LN||7.6|mmol/L|-7.0 - -1.0|H|||F|||20110531101400

Note: no space between hyphen and number for a negative number and a space either side of the hyphen for the character between the reference range values.

4.25 Delete messages for reports and results

The reasons for deleting a report and results include:

• when a patient merge is required where a delete message is sent for each report then the new results are sent with the correct UR number.
• When a report is attached to the wrong patient.

In either case the process is the similar.

To delete a report:

ORC-5 Set to "CA" Cancel
OBR-25 Set to "X"
OBX-11 Set to 'D' or 'W' depending on the reason for the delete message.
D - delete a single result e.g. clotted tube—no platelet count.
W - wrong results sent e.g. results on wrong patient

Example:

MSH|...
PID|...
PV1|....
ORC|RE||11P123456-98765432^MLS^2623^AUSNATA|996042222^SNP^1964^AUSNATA|CA||||20160623164200|JAMB^James Brown^^^^^^^NATA2623||049266KX^Teste^Testy^^^Mr^^^AUSHIC|||20160810171724
OBR|1||11P123456-98765432^MLS^2623^AUSNATA|ALL^ALL^NATA2623||20110623164200|20160623164200|||||""|Nil - Testing Hl7|||049266KX^Teste^Testy||MPATH|KEST|IMAGE|12552953|||CH|X
OBX|1|ST|ALL^ALL^L|1|Delete all results for this report||||||D

4.26 Non-Displayable Supporting data

Encapsulated data attachments are non-displayable files that are ancillary to the main report. They are not e.g. images that form part of the report, related documents, or data which could be used in a display segment. An example of an attachment would be raw XML data from an instrument. Documents which are related to the current report (defined by the OBR) and are displayable using one of the supported AUSPDI display segment datatypes should appear under their own OBR. Attachments can also be represented inline (meaning under the same OBR) or under their own OBR which has the advantage of having a unique document identifier for citation purposes (OBR-3 Filler Order Number), a representation of relevant dates and authorship to be associated with the attachment. Where an attachment is used some narriative documenting the attachment should appear in the display segment associated with the OBR under which the attachment appears.

There can be no expectation that the receiver will be able to process the attachment except by mutual agreement.

Attachments must be represented with ED datatypes in OBX, and must use Base64 encoding.

The sending application must select the appropriate MIME type and sub-type for the attached document and convey that in the corresponding ED value components <type of data (ID)>  and <data subtype (ID)>. See 3.10 ED - encapsulated data.

ORC|RE||2.25.263498878813690208021966154988434320272^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|1||2.25.263498878813690208021966154988434320272^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|18842-5^Discharge Summarization Note^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|18842-5^Discharge Summarization Note^LN||^application^x-hl7-cda-xdm-zip^base64^UEsDBBQ
OBX|2|ED|HTML^Display format in HTML^AUSPDI||^text^html^Base64^PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjwh....
OBX|3|ED|PDF^Display in PDF Format^AUSPDI||^application^pdf^Base64^JVBERi0xLjQNCiXi48/TDQolDQol...ORC|RE||12123-1^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN

ORC|RE||12123-2^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|3||12123-2^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|52033-8^General correspondence^LN Note^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|52033-8^General correspondence^LN|2|^application^octet-stream^Base64^...||||||F
OBX|2|ED|PDF^Display format in PDF^AUSPDI||^application^pdf^Base64^...||||||F|||20170322

ORC|RE||12123-3^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|4||12123-3^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|52033-8^General correspondence^LN Note^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|PDF^Display format in PDF^AUSPDI|Supporting Letter|^application^pdf^Base64^...||||||F|||20170322
OBX|1|ED|RTF^Display format in RTF^AUSPDI|Supporting Letter|^application^rtf^Base64^...||||||F

ORC|RE||12123-4^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|5||12123-4^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|52070-0^Workers compensation^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|PDF^Display format in PDF^AUSPDI|claimform1|^application^pdf^Base64^...||||||F|||20170322

4.27 Referencing other documents

To refer to another document under another OBR then the OBR can be referenced using an OBX EI (Entity Identifier) with a OBX-3 Observation Identifier value of LP72255-0^Citation^LN.

eg. 

OBX|4|EI|LP72255-0^Citation^LN||1234^ACME Pathology^7654^AUSNATA||||||F

Receivers may provide navigation between results using this information. 

Hospital discharge summary (record artifact)Hospital to GP discharge summary (record artifact)Referral to exercise physiologist (procedure)Discharge summary to pharmacist (record artifact)Discharge summary to community health service (record artifact)Discharge summary to GP (record artifact)Enhanced primary care referral (procedure)