Draft Website - For Review Purposes Only

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

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

(Definition from OBX.2 in Ch. 7)

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.

(Definition from OM3.7 in Ch. 8)

Definition: This field contains the allowed data type for a single categorical observation (code A or C in OM1-18 - Nature of Observation). Refer to HL7 Table 0125 – Value Type in Chapter 2C, Code Tables, for valid values.

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.

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>

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 '\X0D0AVALUE#39;) 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.

(Definition from OBX.6 in Ch. 7)

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

(Definition from TCC.13 in Ch. 13)

Definition: This field is the units that have a data type of CWE. The default coding system for the units codes consists of the ISO+ abbreviation for a single case unit (ISO 2955-83) plus extensions, that do not collide with ISO abbreviations (see Chapter 7, section 7.4.2.6). We designate this coding system as ISO+. Both the ISO unit's abbreviations and the extensions are defined in Chapter 7, section 7.4.2.6.2 and listed in Figure 7-9. The ISO+ abbreviations are the codes for the default coding system. Consequently, when ISO+ units are being used, only ISO+ abbreviations need be sent, and the contents of the units field will be backward compatible to HL7 Version 2.1. For more information on this field see reference Chapter 7, section 7.4.2.6.

These units apply to fields "Endogenous content of pre-dilution diluent" and "Equipment dynamic range".

Refer to Table 0788 - Units in Chapter 2C for valid values.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

(Definition from OBX.18 in Ch. 7)

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.

(Definition from EQU.1 in Ch. 13)

Definition: This field identifies the equipment. This is the identifier from an institution's master list of equipment. The <namespace ID> identifies the institution.

The Equipment Instance Identifier shall be unique, meaning that the “Entity Identifier” component shall be unique within the Namespace ID that should accommodate hierarchical representation of equipment (recursive hierarchy like in "Russian dolls", e.g., a sub-module embedded in a module assembled in a system being a member of a cluster).

If this attribute repeats, all instances must represent the same device.

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

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.

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

(Definition from OBX.22 in Ch. 7)

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

(Definition from GOL.22 in Ch. 12)

Definition: This field indicates the Mood of the Goal. It allows expression of the context of the problem.

Refer to HL7 Table 0725 – Mood Codes in Chapter 2C, Code Tables, for allowed values.

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

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.

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.

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.

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.

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.

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.

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.

(Definition from OH1.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH2.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH3.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH4.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from ORC.35 in Ch. 4)

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 either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBR.55 in Ch. 4)

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 either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from IPC.10 in Ch. 4)

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 the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.

(Definition from BPX.22 in Ch. 4)

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 BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BTX.21 in Ch. 4)

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 BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.

(Definition from DON.34 in Ch. 4)

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 DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BUI.13 in Ch. 4)

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 BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2

(Definition from RXV.22 in Ch. 4A)

Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from CDO.2 in Ch. 4A)

Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.55 in Ch. 7)

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 either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBX.31 in Ch. 7)

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.

(Definition from SPM.35 in Ch. 7)

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 SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PRT.2 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

(Definition from CSR.17 in Ch. 7)

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 CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from CTI.4 in Ch. 7)

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 CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from SHP.12 in Ch. 7)

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 SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PAC.9 in Ch. 7)

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 PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from GOL.1 in Ch. 12)

Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PRB.1 in Ch. 12)

Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PTH.1 in Ch. 12)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from DEV.1 in Ch. 17)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

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.

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.