HL7 OBX Observation Result
HL7 field reference OBX fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| OBX.1 | Set ID - OBX | No | No | SI | |
| OBX.2 | Value Type | No | No | ID | 0125 |
| OBX.3 | Observation Identifier | Yes | No | CE | |
| OBX.4 | Observation Sub-ID | No | No | ST | |
| OBX.5 | Observation Value | No | Yes | var | |
| OBX.6 | Units | No | No | CE | |
| OBX.7 | References Range | No | No | ST | |
| OBX.8 | Abnormal Flags | No | Yes | IS | 0078 |
| OBX.9 | Probability | No | No | NM | |
| OBX.10 | Nature of Abnormal Test | No | Yes | ID | 0080 |
| OBX.11 | Observation Result Status | Yes | No | ID | 0085 |
| OBX.12 | Effective Date of Reference Range Values | No | No | TS | |
| OBX.13 | User Defined Access Checks | No | No | ST | |
| OBX.14 | Date/Time of the Observation | No | No | TS | |
| OBX.15 | Producer's Reference | No | No | CE | |
| OBX.16 | Responsible Observer | No | Yes | XCN | |
| OBX.17 | Observation Method | No | Yes | CE | |
| OBX.18 | Equipment Instance Identifier | No | Yes | EI | |
| OBX.19 | Date/Time of the Analysis | No | No | TS | |
| OBX.20 | Performing Organization Name | No | No | XON | |
| OBX.21 | Performing Organization Address | No | No | XAD | |
| OBX.22 | Performing Organization Medical Director | No | No | XCN |
OBX is the segment people usually mean when they say "the result is in the HL7 message." OBR gives you the report or request header. OBX gives you the individual observation: the glucose value, the radiology impression, the organism name, the susceptibility, the immunization funding answer, the device reading, or sometimes the PDF itself.
That is why this segment feels so flexible and so dangerous at the same time. A tiny OBX can carry 5.6 as a numeric glucose result. Another OBX can carry a coded "detected" answer. Another can carry three paragraphs of report text. Another can carry Base64 encoded binary content. The receiver cannot understand OBX-5 unless it reads OBX-2, OBX-3, OBX-6, OBX-8, OBX-11, and the surrounding OBR context. When a result looks odd, opening it in HL7 Soup Web and checking those fields together is usually faster than staring at the raw line.
The heart of the segment is the question-and-answer shape. OBX-3 says what was observed. OBX-5 says what was found. OBX-2 tells you what kind of value OBX-5 is. OBX-6 gives units when the answer is quantitative. OBX-11 tells you whether that answer is final, preliminary, corrected, unavailable, or only order context. Once that clicks, most OBX messages stop looking like a bag of pipes and start looking like a report made of small clinical facts.
First, think in result patterns
The classic lab pattern is numeric: OBX-2=NM, a LOINC or local code in OBX-3, a number in OBX-5, UCUM-style units in OBX-6, a reference range in OBX-7, an interpretation flag in OBX-8, and F in OBX-11 when the value is final. That pattern also turns up in vitals, bedside devices, point-of-care testing, and plenty of pharmacy-adjacent monitoring such as weight, creatinine, INR, or drug levels.
The coded-answer pattern is just as common, but people notice it less at first. Microbiology uses coded organisms, susceptibility interpretations, detected/not detected results, and sometimes structured numeric MIC values. Immunization messages use OBX like a tidy question-and-answer section: vaccine funding source, funding eligibility, VIS dates, vaccine type, contraindications, reactions, and other context. In that style, OBX-3 is the question and OBX-5 is a coded or dated answer.
Pharmacy and treatment-order messages use OBX in a slightly different way again. The medication order itself belongs in the pharmacy order segments, but OBX can carry the clinical facts around that order: patient weight for dosing, renal function, pregnancy status, infusion context, drug level observations, or other order-entry answers the pharmacist or treatment system needs before acting.
Radiology, ultrasound, cardiology, and pathology often lean on text. You may see one OBX for an impression, another for findings, another for a generated comment, or a series of FT/TX OBXs that together form the report. Imaging workflows may also use OBX to carry or point at richer payloads such as CDA, DICOM structured reports, PDFs, or other documents. So do not assume OBX means "a lab number." OBX means "one observation or observation fragment," and the fragment can be a sentence, a section, a value, a code, or a document.
There is one more pattern worth keeping in your head: OBX can appear in orders, not just results. In that situation it may carry information the filler needs before doing the work, such as inspired oxygen for a blood gas, menstrual phase for a pap smear, pregnancy status for imaging, clinical history for radiology, or other order-entry answers. The segment looks the same, but OBX-11 and the message context tell you it is order context rather than a performed result.
So let's go through each of the OBX fields and talk about how they tend to behave in real interfaces.
Numbering matters because OBX repeats so often. In a simple result group you normally see 1, 2, 3, and so on as each observation appears under the OBR. It gives humans and some receiving systems a simple sequence to follow.
Keep it boring. It is not the observation code, accession number, organism number, or line identifier. If your interface uses OBX-4 to group related observations, OBX-1 should still just count the OBX segments in order. If a correction arrives later, matching should rely on the real observation identity and local rules, not only the row number.
This is the decoder ring for OBX-5. A value of NM means the observation value should be read as a number. SN means structured numeric, which is useful for things like <1, ratios, titers, and ranges. CWE or CE means a coded answer. ST, TX, and FT mean text. ED means encapsulated data, such as an embedded PDF or other binary content.
This is one of the easiest fields to under-value and one of the fastest ways to break an interface. A receiver that treats every OBX-5 as plain text will display a lot of messages, but it will lose meaning. Numbers cannot be graphed properly without numeric typing and units. Coded values cannot be decision-supported if the code is flattened. FT text can carry formatting that ST does not. ED content is not a sentence; it is a packaged object. When OBX-2 and OBX-5 disagree, fix the sender or build a very explicit local exception.
A common practical rule is to choose the narrowest honest type. If the result is truly numeric, use NM. If it is a coded answer, use CWE or the code system your guide expects. If it is a narrative section, use TX or FT according to how formatting should be handled. Do not use ST everywhere just because it is easy to send.
Think of this as the question being answered. 2345-7^Glucose^LN asks for a glucose observation. 94531-1^SARS-CoV-2 RNA panel^LN asks for a specific coded lab observation. In immunization messages, a code such as 64994-7 can ask for vaccine funding eligibility, and OBX-5 carries the answer. In report text, OBX-3 may identify "findings", "impression", "generated comment", or a local report section.
Use standard vocabularies when they fit. LOINC is widely used for lab, vitals, report sections, and many public-health observations. SNOMED CT, CVX, local lab codes, and local radiology section codes also appear depending on the domain. A good OBX-3 includes the identifier, text, and coding system. 2345-7^Glucose^LN is far clearer than GLUCOSE floating by itself.
Do not overload one generic code with lots of different meanings just because the value text differs. If OBX-3 says "comment" for every line of a complex report, the receiver has to guess whether OBX-5 is a result, a warning, a section heading, or a real comment. When you need to send distinct facts, give them distinct observation identifiers or a well-documented OBX-4 structure.
When one observation code needs several related lines, OBX-4 is the local handle that keeps them grouped. It is common in microbiology, where one organism may have a set of susceptibility results and another organism has a different set. The organism line and its children often share or refer to the same sub-ID pattern so the receiver knows which susceptibility belongs to which organism.
Report sections and repeating coded answers use the same idea. A message may reuse the same OBX-3 code for several headings, findings, or comments, and OBX-4 gives each one a place in the structure. Some guides use values like 1, 1.1, and 1.2 to show parent-child relationships. Others use a simpler sequence.
The danger is that OBX-4 has no universal meaning by itself. It is powerful because implementation guides and local agreements give it meaning. If the receiver does not know the syntax, it can preserve the value but may not be able to safely reconstruct the hierarchy. Document this field carefully whenever you rely on it.
This is the field everyone comes looking for, and it is also the field you should be slowest to flatten. OBX-5 is not "just the result"; it is the result in the shape declared by OBX-2. For a glucose it may be 5.6. For a COVID answer it may be 260373001^Detected^SCT. For a radiology impression it may be a paragraph. For an embedded document it may be encoded data. Same field number, very different payloads.
Numeric results are the easiest pattern to understand. Use NM for ordinary numbers and put the units in OBX-6. If the result is below a detection limit, a ratio, a titer, or a range, consider SN instead of inventing a string such as <1 and hoping every receiver parses it the same way. Microbiology susceptibility feeds often use structured numeric values for MIC-style results, with interpretation in OBX-8.
Coded answers are common in microbiology, public health, immunization, problem lists, device alarms, and order-entry questions. In these feeds, OBX-3 is often best read as "which question?" and OBX-5 as "which answer?" That might be vaccine funding source, vaccine type, VIS presented date, contraindication, reaction, detected/not detected, organism identified, or a yes/no style clinical fact. Send the code, display text, and coding system where the guide allows it; a display string alone is brittle.
Narrative results deserve a bit of respect. Radiology, ultrasound, pathology, cardiology, and procedure reports may send findings, impressions, comments, or whole report sections in text OBXs. FT can carry HL7 formatting commands such as line breaks, while TX is plain display text. If the OBX-3 is only a section code, the report text usually belongs in OBX-5. Do not display the code as though it were part of the clinical report unless the guide tells you to.
Documents and images are the heavy end of OBX-5. With ED, the value can carry an encapsulated object: source application, data type, subtype, encoding, and the data itself. PDF and CDA payloads are common examples, and imaging workflows may point to or carry DICOM-related content. Base64 makes the content fit into HL7 text, but it also makes the message large, so test line lengths, parser limits, and downstream storage carefully. For more detail on that workflow, see the PDF, Binary, and RTF in HL7 tutorial.
Repeating OBX-5 is for multipart values that still represent one logical observation. It is not a shortcut for putting five different observations into one OBX. If the values need different units, abnormal flags, methods, statuses, timestamps, or identifiers, they should almost certainly be separate OBX segments.
Units are not decoration. 5.6 mmol/L and 5.6 mg/dL are not the same clinical statement. For quantitative observations, OBX-6 should be populated with the agreed unit code and coding system, often UCUM in modern guides. Examples include mmol/L, mg/dL, mm[Hg], %, cm, kg, and /min, depending on the observation.
The unit must match the value and the observation identifier. If OBX-3 identifies a blood pressure systolic value, the unit should not wander between mmHg, mm[Hg], and a local free-text spelling unless the receiver has agreed to normalize it. For coded answers, units often do not apply. Do not send a unit just because the field exists.
With structured numeric values, the relationship can be more subtle. A ratio, range, or comparator may still need units, but the receiver needs to understand the SN components as well as OBX-6. This is a good place to test real examples, not just a happy-path number.
The reference range is usually display text, not a guaranteed machine-readable rule. You may see 3.9-5.8, <5, Negative, See comment, or a lab-specific sentence. It helps a human understand the result in the context supplied by the producing system.
Do not assume you can safely calculate abnormality just by parsing this field. Age, sex, pregnancy status, specimen type, method, race, species, and local lab practice can all change the range. OBX-8 is usually the sender's interpretation. OBX-7 is the reference text that supports that interpretation.
This is where the producer tells you how to interpret the result. Common lab flags include N for normal, H and L for high and low, and HH or LL for critical high or low. You will also see positive, negative, detected, abnormal, and other interpretation-style values depending on the table and the guide.
Microbiology is a special case worth calling out. Susceptibility reporting often uses S, I, and R for susceptible, intermediate, and resistant, with possible variants such as moderately susceptible. In those messages, OBX-5 may hold the numeric MIC or coded susceptibility value, while OBX-8 carries the interpretation the clinician expects to see quickly.
If you receive a numeric value and no OBX-8, you can display the value, but be cautious about inventing your own abnormal flag. If you do calculate flags locally, make that an explicit business rule. The result producer usually knows the method, range, and clinical interpretation better than a downstream interface mapper.
Probability is one of the quieter fields. It can carry a numeric probability associated with an observation, but many mainstream lab, radiology, ADT, and immunization feeds leave it empty. When it does appear, the meaning should be defined by the sending profile.
Do not use it as a general confidence note unless the receiver knows that convention. A percentage, likelihood score, or algorithmic confidence can be clinically interesting, but it needs context. If the score belongs to a coded interpretation or a device algorithm, the method and observation identifier should make that clear.
This field gives extra context about why a result is considered abnormal or which reference population was used. Values can indicate that the range was age-based, sex-based, race-based, species-based, generic, or otherwise specialized.
It is not a replacement for OBX-7 or OBX-8. Think of it as supporting information for interpretation. If a receiver ignores it, the main value may still display, but the subtle reason behind the abnormal flag may be lost. Use it only when the producing system can send it deliberately.
Status is required because a result value without lifecycle is not enough. F means final. P means preliminary. C means a correction to a final result. R can mean entered but not verified. X means the result cannot be obtained. N means the observation was not asked. O is order detail only, with no result value.
This field is separate from OBR-25. OBR-25 is the status of the report group. OBX-11 is the status of this individual observation. In a real panel, one observation might be corrected while another is unchanged. A microbiology report might send preliminary organism information before final susceptibility values. A radiology report might move from preliminary to final as interpretation is completed.
Correction handling needs special care. A corrected OBX should be matched to the original observation using the identifiers and grouping rules agreed by the interface, not just by "same row number." If you store results, keep enough identity and status history to avoid showing both the wrong old value and the corrected new value as if they were separate final facts.
Reference ranges change. Labs update methods, calibrations, populations, and reporting conventions. OBX-12 can say when the reference range values became effective, which matters if you are comparing historical results or auditing an old report.
Most routine interfaces leave it empty, but it is useful when the range is not timeless. If you receive it, preserve it with the result rather than treating it as a message timestamp. It belongs to the interpretation context of the observation.
This is a local access-control hook, and local is the important word. It can carry site-defined access checks for the observation, but it is not a universal confidentiality model.
If a result is sensitive, do not rely on OBX-13 alone unless the receiving system has explicitly implemented the same policy. Privacy, masking, release rules, break-glass behavior, and audit expectations need a proper agreement. For many feeds this field is empty, and that is usually better than sending a code nobody enforces.
This is the clinically relevant time of the observation. For lab it may be the collection time or the time the observed value applies to. For a device feed it may be when the measurement was taken. For imaging or ultrasound it may be the study or observation time. In immunization-style OBX usage, it may be the time that the observation answer was true or recorded.
Keep it separate from MSH-7, OBR-22, and OBX-19. MSH-7 is the message time. OBR-22 is the report or status-change time. OBX-19 is the analysis time. OBX-14 is the observation time. A specimen can be collected at 08:00, analyzed at 10:00, reported at 11:00, and transmitted at 11:05. Those are not interchangeable.
The producer's reference identifies the producer of the observation. In lab work it may point toward the producing lab, organization, location, analyzer context, or a regulatory identifier such as a lab identifier depending on the profile. In device and point-of-care contexts it may help distinguish who or what created the value.
Do not confuse this with the ordering provider or the responsible observer. OBX-15 is about the producer. OBX-16 is about the person responsible for the observation. OBR and ORC have their own provider fields. In clean interfaces those ideas stay separate, even if a legacy feed leaves several of them empty.
When a person is responsible for the observation, this is the place to identify them. It uses XCN, so a useful value includes an identifier, name components, and the assigning authority or identifier type. Names alone are not great integration keys.
Radiology, pathology, cardiology, and verified lab workflows may care about who interpreted, performed, or validated a result. Still, role boundaries matter. OBX-16 is not automatically the ordering provider, attending doctor, transcriptionist, or report recipient. If the report has several people with different roles, check OBR-32 through OBR-35 and the local guide as well.
Method can change meaning. PCR, antigen, culture, microscopy, automated count, manual differential, immunoassay, imaging protocol, device algorithm, and calculation method can all affect how a result should be interpreted. If the method is not obvious from OBX-3, OBX-17 is where it can be stated.
This matters in public health, microbiology, infectious disease testing, point-of-care devices, and lab-method transitions. A receiver may display the same observation code differently when the method differs, or it may avoid trending two values together. Do not bury method in a comment if the guide gives you this field and the receiver uses it.
Device identity becomes important the moment a value is questioned. Point-of-care testing, bedside monitors, analyzers, imaging equipment, and automated lab instruments may all need traceability back to the device that produced the observation.
For ordinary display, this field may never be shown. For quality control, troubleshooting, recalls, calibration questions, or audit work, it can be extremely useful. If the value comes from a device and the receiving workflow cares about device traceability, do not throw this field away just because clinicians do not read it every day.
Analysis time answers a different question from observation time. It says when the analysis was performed. In lab this may be when the specimen was run. In a device workflow it may be when the instrument calculated or processed the value.
This distinction becomes useful when delays matter. A blood sample collected at 08:00 and analyzed at 14:00 tells a different operational story than a value collected and analyzed at the bedside in the same minute. Store it if you receive it, but do not use it as a substitute for OBX-14.
The last few fields in this v2.5.1 reference data identify the performing organization name, address, and medical director. They are the report-provenance end of the segment: who performed the observation, where they are, and who is medically responsible for the organization.
These fields are especially useful in lab reporting, outsourced testing, regulatory reporting, and situations where the producing organization differs from the sending application. They are not a substitute for the observation value, the producer reference, or the responsible observer. They answer the organizational provenance question that sits behind the result.