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. The OBX segment can also contain encapsulated data, e.g., a CDA document or a DICOM image.

Its principal mission is to carry information about observations in report messages. But the OBX can also be part of an observation order (see Chapter 4, section 4.4, "General Trigger Events & Message Definitions"). 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. Appendix 7A includes codes for identifying many of the pieces of information needed by observation producing services to properly interpret a test result. OBX is also found in other HL7 messages that need to include patient clinical information.

HL7 Attribute Table - OBX - Observation/Result Segment

Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
OBX
1	Set ID – OBX	SI	O		[0..1]	00569	[1..4]
2	Value Type	ID	C	0125(R) Value Type(Required)	[0..1]	00570	[2..3]
3	Observation Identifier	CWE	R	0622	[1..1]	00571
4	Observation Sub-ID	OG	C		[0..1]	00572		20	#
5	Observation Value	Varies	C		[0..*]	00573
6	Units	CWE	O	0623	[0..1]	00574
7	Reference Range	ST	O		[0..1]	00575		60	#
8	Interpretation Codes	CWE	O	0078(R) Interpretation Codes(Required)	[0..*]	00576
9	Probability	NM	O		[0..1]	00577		5	#
10	Nature of Abnormal Test	ID	O	0080(R) Nature of Abnormal Testing(Required)	[0..*]	00578	[1..2]
11	Observation Result Status	ID	R	0085(R) Observation Result Status Codes Interpretation(Required)	[1..1]	00579	[1..1]
12	Effective Date of Reference Range	DTM	O		[0..1]	00580
13	User Defined Access Checks	ST	O		[0..1]	00581		20	#
14	Date/Time of the Observation	DTM	O		[0..1]	00582
15	Producer's ID	CWE	B	0624	[0..1]	00583
16	Responsible Observer	XCN	B		[0..*]	00584
17	Observation Method	CWE	O	0626	[0..*]	00936
18	Equipment Instance Identifier	EI	B		[0..*]	01479
19	Date/Time of the Analysis	DTM	O		[0..1]	01480
20	Observation Site	CWE	O	0163(R) Body Site(Required)	[0..*]	02179
21	Observation Instance Identifier	EI	O		[0..1]	02180
22	Mood Code	CNE	C	0725(R) Mood Codes(Required)	[0..1]	02182
23	Performing Organization Name	XON	B		[0..1]	02283
24	Performing Organization Address	XAD	B		[0..1]	02284
25	Performing Organization Medical Director	XCN	B		[0..1]	02285
26	Patient Results Release Category	ID	O	0909(R) Patient Results Release Categorization Scheme(Required)	[0..1]	02313	[1..10]
27	Root Cause	CWE	O	0914 Root Cause	[0..1]	03308
28	Local Process Control	CWE	O	0915 Process Control Code	[0..*]	03309
29	Observation Type	ID	O	0936(R) Observation Type(Required)	[0..1]	03432
30	Observation Sub-Type	ID	O	0937(R) Observation Sub-Type(Required)	[0..1]	03475
31	Action Code	ID	O	0206(R) Segment Action Code(Required)	[0..1]	00816	[2..2]
32	Observation Value Absent Reason	CWE	C	0960(S) Data Absent Reason(Suggested)	[0..*]	03510
33	Observation Related Specimen Identifier	EIP	O		[0..*]	02454

OBX-1: Set ID – OBX (SI) 00569

Definition: This field contains the sequence number. For compatibility with ASTM.

OBX-2: Value Type (ID) 00570

Definition: This field defines the data type of OBX-5, Observation Value. If OBX-5, Observation Value, is valued then OBX-2, Value Type, SHALL be valued. When OBX-5, Observation Value, is not valued, OBX-2 Value Type MAY be valued to represent a data type used to value the observation expressed in OBX-3, Observation Identifier. See HL7 Table 0125 – Value Types for valid values.

Condition: This field is required if OBX-5, Observation Value, is valued.

For example, if the value is 'CWE' then the result in OBX-5 must be a coded entry or text or both. As of v 2.7, the ST data type may not be used to transmit data that can be more precisely transmitted using other data types, e.g. SN when comparative symbols are needed.

The RP value (reference pointer) must be used if the OBX-5 contains a pointer to the data e.g., a URL of an image. The receiving system can use this reference pointer whenever it needs access to the actual data through other interface standards, e.g., DICOM, or through appropriate data base servers.

The structured numeric (SN) data type provides for reporting ranges (e.g., 3-5 or 10-20), titres (e.g., 1:10), and out-of-range indicators (e.g., >50) in a structured and computer-interpretable way.

We allow the FT data type in the OBX segment, but its use is discouraged. Formatted text usually implies a meaningful structure, e.g., a list of three independent diagnoses reported on different lines. But ideally, the structure in three independent diagnostic statements would be reported as three separate OBX segments.

TX should not be used except to send large amounts of text. In the TX data type, the repeat delimiter can only be used to identify paragraph breaks. Use ST to send short, and possibly encodable, text strings.

CDA documents are to be exchanged in the OBX segment in any message that can exchange documents (such as MDM or ORU). Within the OBX segment, the MIME package is encoded as an encapsulated (ED) data type.

OBX-3: Observation Identifier (CWE) 00571

Definition: This field contains a unique identifier for the observation. The format is that of the Coded Element (CWE). Example: "8625-6^P-R interval^LN". Refer to Table 0622 - Observation Identifier in Chapter 2C for valid values.

In most systems the identifier will point to a 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. A set of message segments for transmitting such master observation tables is described in Chapter 8. The relation of an observation ID to a master observation table is analogous to the relationship between a charge code (in a billing record) and the charge master.

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 one possible universal and HL7-approved code system for the Observation identifier. It covers observations and measurements, such as laboratory tests, physical findings, radiology studies, and claims attachments. See HL7 Table 0396 – Coding System, the HL7 www list server and Appendix X2 of ASTM E1467 for neurophysiology tests, or it can be obtained from www.regenstrief.org/loinc/loinc.htm.

The use of suffixes as described in section 7.2.4 and section 7.2.5has been deprecated as of v 2.7.

OBX-4: Observation Sub-ID (OG) 00572

Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. Starting with V2.8.2 the data type was changed from ST to OG to enable improved structured grouping of observation segments. In this enhanced mode, the first component provides backwards compatibility with existing grouping schemes, while the additional components can be used for improved structures as defined in specific conformance profiles. 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.

The sub-identifier is also used to group related components in reports such as surgical pathology. It is traditional for surgical pathology reports to include all the tissues taken from one surgical procedure in one report. Consider, for example, a single surgical pathology report that describes the examination of gallbladder and appendix tissue. This report would be transmitted roughly as shown in Figure 7-2.

Figure 7-2. Example of sub-identifier usage – enhanced mode

OBR|1||1234^LAB|11529-5^Study report^LN|...<cr>

OBX|1|CWE|31208-2^Specimen source [Identifier] of Unspecified specimen^LN|^1^1^1|8231008^Gallbladder structure (body structure)^SCT|...<cr>

OBX|2|TX|22634-0^Path report.gross observation^LN|^1^2^1|THIS IS A NORMAL GALLBLADDER|...<cr>

OBX|3|TX|22635-7^Path report.microscopic observation^LN|^1^3^1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLY NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CWE|34574-4^Path report.final diagnosis^LN|^1^4^1|300355005^Gallbladder normal (finding)^SCT|...<cr>

OBX|5|CWE|31208-2^Specimen source [Identifier] of Unspecified specimen^LN|^2^1^1|66754008^Appendix structure (body structure)^SCT|...<cr>

OBX|6|TX|22634-0^Path report.gross observation^LN|^2^2^1|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX|...<cr>

OBX|7|TX|22635-7^Path report.microscopic observation^LN|^2^3^1|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORY CHANGE|...<cr>

OBX|8|CWE|34574-4^Path report.final diagnosis^LN|^2^4^1|M-40000^INFLAMMATION NOS^SNM|...<cr>

The example in Figure 7-2 has two segments for each component of the report, one for each of the two tissues. Thus, there are two "31208-2^Specimen source [Identifier] of Unspecified specimen^LN" segments; there are two "22634-0^Path report.gross observation^LN" segments, and there are two "22635-7^Path report.microscopic observation^LN" segments. Segments that apply to the gallbladder all have the sub-identifier 1. Segments that apply to the appendix all have sub-identifier 2.

The observation sub ID has other grouping uses. It can be used to organize the reporting of some kinds of fluid intakes and outputs. For example, when intake occurs through multiple intravenous lines, a number of separate observations (OBX segments), the intake volume, the type of intake (Blood, D5W, Plasma, etc.), the site of the IV line, etc. may be needed for each intravenous line, each requiring a separate OBX segment. If more than one IV line is running, we can logically link all of the OBX segments that pertain to the first IV line by assigning them an observation sub ID of 1. We can do the same with the second IV line by assigning them a sub ID 2 and so on. The same would apply to the outputs of surgical drains when there are multiple such drains.

The use of the sub ID to distinguish repeating OBXs for the same observation ID is really a special case of using the sub ID to group, as can be seen if we picture the OBX segments in Figure 7-2 as part of a table where the rows correspond to a particular species of observation and the cells correspond to the sub ID numbers that would be associated with each corresponding OBX.

Distinct Observations	88304&ANT	22634-0^Path report.gross observation^LN	22635-7^Path report.microscopic observation^LN	34574-4^Path report.final diagnosis^LN
Sub ID 1st Group	1	1	1	1
Sub ID 2nd Group	2	2	2	2

The use of Sub IDs to group results is equivalent to defining a table, and the use of sub IDs to distinguish repeats is just a special case, represented by one column in this table.

However, this approach introduces ambiguities if we have a set of repeating observations within a group, e.g., if the appendix observations include two impressions as in the 8th and 9th OBXs shown in Figure 7-3. This really represents the existence of a row nested within a single cell of the table given above.

Figure 7-3. Example of sub-identifier usage – original mode

OBX|1|CWE|880304&ANT|1|T57000^GALLBLADDER^SNM|...<cr>

OBX|2|TX|22634-0^Path report.gross observation^LN|1|THIS IS A NORMAL GALL BLADDER|...<cr>

OBX|3|TX|22635-7^Path report.microscopic observation^LN|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

    NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CWE|34574-4^Path report.final diagnosis^LN|1|M-00100^NML^SNM|...<cr>

OBX|5|CWE|880304&ANT|2|T57000^APPENDIX^SNM|...<cr>

OBX|6|TX|22634-0^Path report.gross observation^LN|2|THIS IS A RED, INFLAMED APPENDIX|...<cr>

OBX|7|TX|22635-7^Path report.microscopic observation^LN|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION|...<cr>

OBX|8|CWE|34574-4^Path report.final diagnosis^LN|2|M-40000^INFLAMMATION NOS^SNM|...<cr>

OBX|9|CWE|34574-4^Path report.final diagnosis^LN|2|M-30280^FECALITH^SNM|...<cr>

The text under OBX-5-observation value provides guidance about dealing with two OBXs with the same observation ID and observation sub IDs. They are sent and replaced as a unit. However, some systems will take this to mean that the set of OBXs is to be combined into one composite observation in the receiving system. In original mode, this could use a dot and a string (similar to the Dewey Decimal system) notation that would be used when users wish to distinguish each of the repeats within one type, or results within a cell for editing and correction purposes. Using this system, Figure 7-3 would become 7-4. If there are cases where such nesting occurs at even deeper levels, this approach could be extended, although with the introduction of the OG data type we suggest the use of components 2-4 as described in Figure 7-2.

Figure 7-4. Example of sub-identifier usage – original mode with nesting

OBX|1|CWE||31208-2^Specimen source [Identifier] of Unspecified specimen^LN|1|28231008^Gallbladder structure (body structure)^SCT|...<cr>

OBX|2|TX|22634-0^Path report.gross observation^LN|1|THIS IS A NORMAL GALL BLADDER|...<cr>

OBX|3|TX|22635-7^Path report.microscopic observation^LN|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

    NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CWE|34574-4^Path report.final diagnosis^LN|1|300355005^Gallbladder normal (finding)^SCT|...<cr>

OBX|5|CWE|31208-2^Specimen source [Identifier] of Unspecified specimen^LN|2|66754008^Appendix structure (body structure)^SCT|...<cr>

OBX|6|TX|22634-0^Path report.gross observation^LN|2|THIS IS A RED, INFLAMED APPENDIX|...<cr>

OBX|7|TX|22635-7^Path report.microscopic observation^LN|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION|...<cr>

OBX|8|CWE|34574-4^Path report.final diagnosis^LN|2.1|M-40000^INFLAMMATION NOS^SNM|...<cr>

OBX|9|CWE|34574-4^Path report.final diagnosis^LN|2.2|M-30280^FECALITH^SNM|...<cr>

Use a null or 1 when there is no need for multiples.

If the observation includes a number of OBXs with the same value for the observation ID OBX-3, then one must use different values for the sub-ID. If there is no need to group or sequence any further, the original mode can continue to be used to ensure uniqueness of OBX as shown in the example below of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results.

Figure 7-5. Example of Sub-ID used to distinguish three independent results with the same observation ID – without grouping/sequencing

OBX|1|CWE|8601-7^EKG IMPRESSION ^LN|1|^atrial fibrillation|...<cr>

OBX|2|CWE|8601-7^EKG IMPRESSION ^LN|2|^OLD SEPTAL MYOCARDIAL INFARCT|...<cr>

OBX|3|CWE|8601-7^EKG IMPRESSION ^LN|3|^poor R wave progression|...<cr>

OBX-5: Observation Value (Varies) 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. It is not a required field because some systems will report only the Interpretation Codes (OBX-8), especially in product experience reporting. The length of the observation field is variable, depending upon OBX-2-value type. This field may repeat for multipart, single answer results.

Representation

This field contains the value related to the OBX-3-observation identifier of the same 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, unless it is part of a list of like concepts that belong together (e.g., a list of conditions tested for in newborn screening or mutations looked for in genomic testing). This requirement is included to assure that the contents of OBX-6-units, OBX-8-interpretation codes, and OBX-9-probability can be interpreted unambiguously. This means that all other OBX field values apply equally to the whole of OBX-5 noting that OBX-6 does not apply in the case of coded values. 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.

Though two independent diagnostic statements cannot be reported in one OBX segment, unless they represent elements of a single list to which all other OBX field values apply equally, multiple categorical responses are allowed (usually as CWE data types separated by repeat delimiters), so long as they are fragments (modifiers) that together construct one diagnostic statement. Right upper lobe (recorded as one code) and pneumonia (recorded as another code), for example, could be both reported in one OBX segment. Such multiple "values" would be separated by repeat delimiters. The other example where use of repeat delimiters is allowed for coded values would be a list of conditions or mutations tested for to provide reference for the test results reported in related, but independent OBX segments. Multiple answers to a single question (for example mark all that apply type questions) could also be handled using this approach. It is important to state that ANY independent observation, that may require parent-child linking to additional tests, such as reflex testing, SHALL NOT be included in a single OBX-5 field using repeat delimiters, nor any list elements that require variations in the values of other OBX field values.

The following provides an example of how this may be communicated for 10 Cystic Fibrosis mutations, where the mutations are highlighted in red font (note that some labs test for as many as 140 mutations):

OBX|1|CWE|21656-4^CFTR gene mutations tested for in Blood or Tissue by Molecular genetics method Nominal ^LN|1|c.254G>A^^HGVS~c.350G>A^^HGVS~c.489+1G>T^^HGVS~c.579+1G>T^^HGVS~c.1000C>T^^HGVS~c.1040G>C^^HGVS~c.1364C>A^^HGVS~c.1519_1521del^^HGVS~c.1521_1523del^^HGVS~c.1585-1G>A^^HGVS|||N|||F

Multiple OBX segments with the same observation ID and Sub ID

In some systems, a single observation may include fragments of more than one data type. The most common example is a numeric result followed by coded comments (CWE). In this case, the logical observation can be sent in more than one OBX segment. For example, one segment of numeric data type for the numeric result and another segment of CWE data type for coded comments. If the producer was reporting multiple coded comments they would all be sent in one OBX segment separated by repeat delimiters because they all modified a single logical observation. Multiple OBX segments with the same observation ID and sub ID should always be sent in sequence with the most significant OBX segment (the one that has the normal flag/units and or reference range and status flag) first. The value of OBX-6 through 12 should be null in any following OBX segments with the same OBX-3-observation identifier and OBX-4-observation sub-ID. For the purpose of replacement or deletion, multiple OBX segments with the same observation ID and sub ID are treated as a unit. If any are replaced or deleted, they all are replaced.

Coded values

When an OBX segment contains values of CWE data types, the observations are stored as a combination of codes and/or text. In Section 7.8.3, "CSS - Clinical Study Data Schedule Segment," examples of results that are represented as CWE data types are shown in the first and second OBX segments of OBR 1 and the first and second OBX segments of OBR 2. The observation may be an observation battery ID (for recommended studies), a diagnostic code or finding (for a diagnostic impression), or an anatomic site for a pathology report, or any of the other kinds of coded results.

It is not necessary to always encode the information stored within a coded observation. For example, a chest X-ray impression could be transmitted as pure text even though it has a CWE data type. In this case, the test must be recorded as the second component of the result code, e.g.,

OBX|1|CWE|19005^X-Ray Impression^LN|1|^CONGESTIVE HEART FAILURE.|...<cr>

However, separate impressions, recommendations, etc., even if recorded as pure text, should be recorded in separate result segments. That is, congestive heart failure and pneumonia should not be sent as:

OBX|1|CWE|19005^X-Ray Impression^LN|1|^CONGESTIVE HEART FAILURE AND PNEUMONIA|...<cr>

but as:

OBX|1|CWE|19005^X-Ray Impression^LN|1|^CONGESTIVE HEART FAILURE|...<cr>

OBX|2|CWE|19005^X-Ray Impression^LN|2|^PNEUMONIA|....<cr>

Even better would be fully-coded results that include computer understandable codes (component 1) instead of, or in addition to, the text description (component 2). One may include multiple values in a CWE value and these can be mixtures of code and text, but only when they are needed to construct one diagnosis, impression, or concept. When text follows codes as an independent value it would be taken as a modifier or addenda to the codes. E.g.,

OBX|1|CWE|19005-8^X-ray impression^LN~29548-5^DiagnosisImpPatient^LN |1|428.0^CONGESTIVE HEART FAILURE^I9C~^MASSIVE HEART|...<cr>

• The text in component 2 should be an accurate description of the code in component 1. Likewise, if used, the text in component 5 should be an accurate description of the code in component 4.

• Insertion of CDA within an OBX:

CDA documents are to be exchanged in the OBX segment. The value of OBX-2-Value Type should be set to 'ED'. OBX-5-Observation Value contains the MIME package encoded as an encapsulated data type. The components should be valued as follows:

• Set the value of OBX-5.2-Type of Data to 'multipart.'

• Set the value of OBX-5.3-Data Subtype to '-hl7-cda-level-one.'

• Set the value of OBX-5.4-Encoding to 'A'. (Note that a MIME package is not itself Base64-encoded. Rather entities within the MIME package are Base64-encoded. A MIME package is sent as ASCII text. Therefore, the correct value is 'A' not 'Base64.'

• Set the value of OBX-5.5-Data to equal the MIME package. Every entity within the MIME package must be Base64-encoded. As stated in Chapter 2, "the data component must be scanned before transmission for HL7 delimiter characters (and other non-printing ASCII or non-ASCII characters such as LineFeed), and any found must be escaped by using the HL7 escape sequences defined in Section 2.7 'Use of escape sequences in text fields.' On the receiving application, the data field must be de-escaped after being parsed." As a result, CR/LF sequences required in the MIME package need to be escaped (i.e., converted to '\X0D0A\') prior to transmission. The content type of the first MIME entity is set to 'application/x-hl7-cda-level-one+xml', and should contain the CDA document itself. Multimedia objects referenced by the CDA document that need to be transmitted within the CDA document are to be placed in successive entities of the MIME package.

OBX-6: Units (CWE) 00574

Definition: This field contains the units of measurement for the value in OBX-5, Observation Value. Coding system from which the values may be drawn include, UCUM, ISO+, ANSI X3.50 - 1986 and site specific (local) coding systems. Considering Version 3 direction and consistent use of V2 and V3 messages/documents within an organization, use of UCUM is strongly recommended. Refer to Table 0623 - Units in Chapter 2C for valid values.

Note that OBX-6 applies to both OBX-5.2 and OBX-5.4 if OBX-2 = “SN”.

OBX-7: Reference Range (ST) 00575

Components: for numeric values in the format:

1. lower limit-upper limit (when both lower and upper limits are defined, e.g., for potassium 3.5 - 4.5)

2. > lower limit        (if no upper limit, e.g., >10)

3. < 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.

OBX-8: Interpretation Codes (CWE) 00576

Definition: One or more codes specifying a categorical assessment of the observation value (OBX.5), such as "Normal", "Abnormal", "Positive", "Negative", "Resistant", "Susceptible", etc.

This field may also be used to convey an assessment of an observation where no legitimate result may be obtained. This includes laboratory assays that are rejected due to the presence of interfering substances, specimen toxicity or failure of quality control.

As a CWE data type, this field may be populated with either HL7-defined codes or codes derived from other code systems (such as SNOMED). See User-defined Table 0078 – Interpretation Code for potential entries.

When the filler 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".

Results may also be reported in shorthand by reporting the normalcy status without specifying the exact numeric value of the result. Such shorthand is quite common in clinical notes, where physicians will simply say that the glucose result was normal. Such shorthand reporting is also seen in drug experience reporting. In such cases, the result can be reported in the OBX by reporting the interpretation code in OBX-8-Interpretation Codes without specifying any value in OBX-5-observation value.

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.

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".

The constraints on the use of the codes in this table must be consistent with those defined in the PID segment, specifically PID-35-Species Code, PID-36-Breed Code and PID-37-Strain.

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 (depending upon the specific case) until they are final.

If an observation involves multiple OBX segments with the same observation ID (including suffix) and observation sub-ID, the observation result status applies to all OBX segments, except where the value is D or X. The value of D or X is applicable only to the individual OBX. All other OBX segments with the same Observation ID and observation sub-ID must have the same value.

In the case of coding systems such as LOINC, the preceding rules typically mean that this field applies to a single OBX segment.

There are situations where the observation battery required for the order needs to be dynamically specified at the time of ordering. That is, this battery is then defined by the set of OBX segments transmitted along with the order and generated by the placing system. For example, timed measurements of serum glucose challenge tests may vary among laboratories. One institution may report them at –30, -15, 0, 30, 60, and 120 minutes, while another may report them at –30, 0, 30, 60, 90, and 120 minutes. Master file entries may exist for each individual element of the battery but not for the battery itself. Another example may be Renin Studies where the specification may be done upon ordering without having a master file definition for each permutation of the possible element. The OBX segments in the ORM message can be used to create dynamic specifications to accommodate these permutations without defining pre-existing master file definitions for the battery itself. The result status field in the OBX can be used to indicate whether the OBX in the ORM message is used to provide a dynamic specification or is used to communicate a result as context to the order. The status of O shall be used to indicate that the OBX segment is used for a dynamic specification of the required result. An OBX used for a dynamic specification must contain the detailed examination code, units, etc., with OBX-11 valued with O, and OBX-2 and OBX-5 valued with null.

OBX-12: Effective Date of Reference Range (DTM) 00580

Definition: This field contains the date (and, optionally, the time) on which the values in OBX-7-reference range went into effect.

Usage Rule: This field can be valued only if OBX-7-reference range is populated.

When this field is present, it facilitates comparison between identical results with different reference ranges. Reference range values may vary because of changes in laboratory practice over time. Such variances could reflect updated practice in laboratory medicine, or the use of updated instrumentation.

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. This field should be needed only rarely, because most classifications are fixed attributes of the observation ID and can be defined in the associated observation master file (see description in Chapter 8).

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 non-privileged users would see only the "preferred" antimicrobials to which the organism was susceptible. We expect that other cases also occur.

OBX-14: Date/Time of the Observation (DTM) 00582

Definition: This field is needed 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.

The Date/Time of observation can be used to identify when the answer was determined, i.e., when the answer to an Ask at Order Entry question was acquired.

OBX-15: Producer's ID (CWE) 00583

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. 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. This information supports CLIA regulations in the US. The code for producer ID is recorded as a CWE data type. In the US, the Medicare number of the producing service is suggested as the identifier. Refer to Table 0624 - Producer's ID in Chapter 2C for valid values.

OBX-16: Responsible Observer (XCN) 00584

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. 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 CWE data type. If the code is sent as a local code, it should be unique and unambiguous when combined with OBX-15-producer ID.

OBX-17: Observation Method (CWE) 00936

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 Manual¹ 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. Refer to Table 0626 - Observation Method in Chapter 2C for valid values.

OBX-18: Equipment Instance Identifier (EI) 01479

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field identifies the Equipment Instance (e.g., Analyzer, Analyzer module, group of Analyzers, etc.) 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.

OBX-19: Date/Time of the Analysis (DTM) 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).

OBX-20: Observation Site (CWE) 02179

Definition: This field typically contains the body site(s) where the measurement being reported was obtained. This field should not be used for a specimen source or specimen collection site.

This information is of particular importance if the clinical meaning of a value is modified either directly by the site (for example, is the temperature central or peripheral?) or if the site of one measurement impacts the value of another measurement (for example, is the finger SpO2 probe on the same arm as the NIBP cuff?). In most cases these observations are performed directly upon the patient and do not involve a specimen.

Any nationally recognized coding system might be used for this field including SNOMED or MDC; alternatively the HL7 Table 0163 – Body Site may be used. Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

OBX-21: Observation Instance Identifier (EI) 02180

Definition: This field contains a unique identifier for this observation. This instance identifier is persistent between messages.

OBX-22: Mood Code (CNE) 02182

Definition: This field identifies the actuality of the observation (e.g., intent, request, promise, event). Refer to HL7 Table 0725 – Mood Codes for valid values. This field may only be used with new trigger events and new messages from v 2.6 onward. When this field is not valued in a message that qualifies, then the Value is assumed to be 'EVN'.

OBX-23: Performing Organization Name (XON) 02283

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field contains the name of the organization/service responsible for performing the service. When this field is null, the receiving system assumes that the observations were produced by the sending organization. The information for performing organization is recorded as an XON data type. In the US, the Medicare number of the performing organization is suggested as the identifier (component 10).

For lab, this field specifies the laboratory that produced the test result described in this OBX segment. It should be reported explicitly when the test results are produced at outside laboratories, for example. This information supports CLIA regulations in the US. For the US producing laboratories, which are CLIA certified, the CLIA identifier should be used for the organization identifier (component 10).

OBX-24: Performing Organization Address (XAD) 02284

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field contains the address of the organization/service responsible for performing the service.

For labs, this field specifies the address of the laboratory that produced the test result described in this OBX segment. It should be reported explicitly when the test results are produced at outside laboratories, for example. This information supports CLIA regulations in the US.

OBX-25: Performing Organization Medical Director (XCN) 02285

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field contains the medical director of the organization/service responsible for performing the service.

For labs, this field specifies the medical director of the laboratory that produced the test result described in this OBX segment. This field is different than OBX-16 in that OBX-16 identifies the individual who performed the lab test (made the observation) whereas this field identifies the individual who is the medical director of the organization responsible for the result. It should be reported explicitly when the test results are produced at outside laboratories, for example. This information supports CLIA regulations in the US.

OBX-26: Patient Results Release Category (ID) 02313

Definition: This field contains instructions on whether to share the results with the patient, and if so how.

Valid values are provided in HL7 Table 0909 – Patient Results Release Categorization Scheme.

OBX-27: Root Cause (CWE) 03308

Definition: This element contains the reason code indicating the root cause for the reissue of a previously released lab report. This element is used in conjunction with OBX-11 Observation Result Status to define the root cause for a reissued laboratory result in the case of a corrected, amended, appended, or revised result. For example, if the laboratory result was reissued due to an equipment malfunction.

Refer to User-defined Table 0914 – Root Cause in Chapter 2C, Code Tables, for potential values.

OBX-28: Local Process Control (CWE) 03309

Definition: This element contains information intended to be used for locally defined processing, particularly process control/status type information. It is defined as repeating and as a CWE data type to provide flexibility. The specific use may be specified in a message profile or implementation guide (see Chapter 2.B), or use may be specified by local agreement internally within an organization.

For example, a laboratory information system might use this element to convey an internal status during processing before the result is communicated outside the organization, such as revision previously reported, revision report pending.

See User-Defined Table 0915 – Process Control Code in Chapter 2C, Code Tables, for a list of suggested values.

OBX-29: Observation Type (ID) 03432

Definition: This field indicates the type of observation to enable systems to distinguish between observations sent along with an order, versus observations sent as the result to an order. See HL7 Table 0936 – Observation Type in Chapter 2C, Code Tables, for valid values.

OBX-30: Observation Sub-Type (ID) 03475

Definition: The result sub-type provides further classification of OBX-29 Observation Type. This may aid in the grouping of OBX-segments. See HL7-defined Table 0937 – Observation Sub-Type in Chapter 2C, Code Tables, for a set of valid values.

OBX-31: Action Code (ID) 00816

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.

OBX-32: Observation Value Absent Reason (CWE) 03510

Definition: This field reports the reason(s) why there is no value reported in the Observation Value (OBX-5) field. This field can be used when OBX-5-Observation Value is empty.

See HL7 Table 0960 – Observation Value Absent Reason for valid values.

Condition: This field must be blank if OBX-5, Observation Value, is valued.

OBX-33: Observation Related Specimen Identifier (EIP) 02454

Definition: This field contains the unique identifier for the specimen as referenced by the Placer application, the Filler application, or both in the SPM segment that describes the specimen this observation is related to, allowing an explicit linkage between the two.