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 message 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 response 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 (i.e. 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 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 (e.g. 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 descended 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. 

e.g. 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. e.g. |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.

e.g. |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 

Note: † An Australian extension to 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. 

e.g. 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

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