FHIR R4 Observation · US Core Laboratory Result Observation · US Core Vital Signs · US Core Clinical Result Observation

Observation covers three distinct kinds of data in the Patient Everything and Patient Summary bundles — laboratory results, vital signs, and the findings contained inside a DiagnosticReport. Each uses a different US Core profile and is documented separately below. It is not produced for Bulk Medication History.

Usage 1: Laboratory results

Laboratory Observation resources are top-level entries in the bundle, and are produced identically for both bundles.

Stable ID

The id is derived from the patient, the result date, the result code, the value, the unit, and the reference range (low, high, and text).

Fields

Field	Cardinality	Notes
`meta.profile`	1..1	Always set to the US Core Laboratory Result Observation profile URL.
`status`	1..1	Always `final`.
`category`	1..1	Always `laboratory` from the observation-category system.
`subject`	1..1	Reference to the Patient.
`effectiveDateTime`	1..1	The result date.
`code`	1..2	The result’s own coding, plus a second coding for the Connective Health panel classification when one applies — see Panel classification.
`value[x]`	0..1	See Result values.
`interpretation`	0..1	The result’s interpretation (for example `H` high or `POS` positive) from the v3-ObservationInterpretation system. The `display` is the code system’s own display for the code. Omitted when the result has no interpretation.
`note`	0..1	Free-text comment accompanying the result. Omitted when there is none.
`referenceRange`	0..1	See Reference ranges.
`performer`	0..1	Contained PractitionerRole built from the result’s provider and performing facility. Omitted when neither is known.

specimen and issued are not populated.

Result values

A result carries one value. When the source has more than one, the first present in this order is published: a number, a range, a code, then text.

Source data	Published as
A number with a unit	`valueQuantity`, with the value and unit normalized to UCUM. The original unit text is preserved in `valueQuantity.unit`.
A one-sided range with a unit, such as `>60`	`valueQuantity` with a `comparator` of `>`, `>=`, `<`, or `<=`, so `>60 mL/min/{1.73_m2}` is published as a quantity of 60 with the comparator `>`.
A two-sided range with a unit	`valueRange`, with `low` and `high` as quantities. FHIR cannot mark a `Range` bound as exclusive, so an exclusive bound is published as its value.
A number or range with no unit	`valueString`, carrying the number or a description of the range, such as `>=5` or `3.4 - <4`, where `>` and `<` mark exclusive bounds.
A code	`valueCodeableConcept`, with the code as its coding. `text` is the source’s original result text when there is one, otherwise the code’s display.
Text	`valueString`, carrying the raw source text — this covers qualitative results such as `POSITIVE` or `NEGATIVE`.
A value whose unit cannot be normalized to UCUM	Nothing. `value[x]` is left unset rather than published with an invalid unit.

Reference ranges

Each bound is published on its own, so a reference range can be one-sided. The bounds are in the reference range’s own unit when the source gives one, otherwise in the unit of the result’s value.

Source data	Published as
A numeric low, high, or both	`referenceRange.low` and `referenceRange.high` as quantities, each only when present. When neither the reference range nor the result’s value has a unit, a bound is published as a quantity with a value only; a bound whose unit cannot be normalized to UCUM is omitted.
A non-numeric bound, such as `UNK`	Nothing for that side, so the range is open on that side.
An exclusive bound, such as `<200`	The bound as a quantity, as above. FHIR cannot mark a reference range bound as exclusive, so `referenceRange.text` also describes the range, such as `<200 mg/dL`, unless the source has text of its own.
Reference range text from the source	`referenceRange.text`, carrying the raw source text, such as `NEGATIVE`. It is published alongside any numeric bounds.
None of these	Nothing. `referenceRange` is omitted.

Panel classification

Where a result belongs to a Connective Health panel grouping, that grouping is published as an additional coding on code using the http://connectivehealth.io/fhir/panel-classification system. This is a Connective Health terminology, not a standard one, and is additive — the result’s own standard coding is always present as well.

Usage 2: Vital signs

Vital sign Observation resources are top-level entries in the bundle, and are produced identically for both bundles.

Only the vital signs in the table below are published. A vital sign recorded under any other LOINC code, or with no value or no date, is not included in either bundle.

Vital sign	LOINC code	Additional US Core profile
Blood pressure panel	`85354-9`	US Core Blood Pressure
Body height	`8302-2`	US Core Body Height
Body weight	`29463-7`	US Core Body Weight
Body temperature	`8310-5`	US Core Body Temperature
Body mass index	`39156-5`	US Core BMI
Heart rate	`8867-4`	US Core Heart Rate
Respiratory rate	`9279-1`	US Core Respiratory Rate
Pulse oximetry	`59408-5`, `2708-6`	US Core Pulse Oximetry
Oxygen saturation	`2708-6`	None

Every vital sign Observation claims the US Core Vital Signs profile. The additional, more specific US Core profile is only claimed when the source data meets that profile’s requirements, so it is not always present. For example, an oxygen saturation is only published as US Core Pulse Oximetry, with both the 59408-5 and 2708-6 codings, when the source record identifies it as measured by pulse oximetry (59408-5). Otherwise it carries only the 2708-6 coding and the US Core Vital Signs profile.

Stable ID

The id is derived from the patient, the observation date, the vital sign code, the value, and the unit.

Fields

Field	Cardinality	Notes
`meta.profile`	1..2	The US Core Vital Signs profile, plus the specific profile for that vital sign from the table above when one applies.
`status`	1..1	Always `final`.
`category`	1..1	Always `vital-signs` from the observation-category system.
`subject`	1..1	Reference to the Patient.
`effectiveDateTime`	1..1	The observation date. Vital signs with no date are excluded entirely.
`code`	1..1	The vital sign’s LOINC coding. For a blood pressure panel this is fixed to LOINC `85354-9`, “Blood pressure panel with all children optional”.
`valueQuantity`	0..1	The measured value, normalized to UCUM, with the source unit preserved in `valueQuantity.unit`. Omitted for blood pressure panels, whose values live on `component` instead, and omitted when the value is not numeric.
`component`	0..2	Blood pressure only — see Blood pressure.
`performer`	0..1	Contained PractitionerRole built from the recording provider and facility. Omitted when neither is known.

Blood pressure

Blood pressure is always published as a panel rather than as two independent observations: one Observation coded 85354-9 with a systolic and a diastolic component.

Component	Notes
Systolic	`component.code` carries the source systolic coding (normally LOINC `8480-6`); `component.valueQuantity` uses UCUM `mm[Hg]` with a display unit of `mmHg`.
Diastolic	`component.code` carries the source diastolic coding (normally LOINC `8462-4`); same unit handling as systolic.

The panel’s effectiveDateTime and stable id are taken from the systolic reading.

Usage 3: Diagnostic report findings

Findings belonging to a DiagnosticReport are published as Observation resources contained inside that report and referenced from DiagnosticReport.result.

Stable ID

No id is assigned — these observations exist only inside their parent report and are neither addressable on their own nor deduplicated. Use the parent DiagnosticReport’s id to track them over time.

Fields

Field	Cardinality	Notes
`meta.profile`	1..1	Always set to the US Core Clinical Result Observation profile URL — note this differs from the laboratory profile above.
`status`	1..1	Always `final`.
`category`	1..1	Always `imaging` from the observation-category system.
`subject`	1..1	Reference to the Patient.
`effectiveDateTime`	1..1	The report date.
`code`	1..2	The report’s panel coding. In the Patient Everything bundle a panel classification coding is added where one applies; in the Patient Summary bundle it is never added.
`value[x]`	1..1	Either the discrete result value or the narrative report text — see below.
`referenceRange`	0..1	Populated on the discrete-value observation only: `low` and `high` as quantities when both are numeric, otherwise `text` carrying the source’s reference range text. Omitted when there is neither.
`performer`	0..1	Contained PractitionerRole built from the report’s provider and facility.

A report produces up to two contained observations, depending on what the source carries:

Source data	Contained observations
A discrete result value	One observation whose `value[x]` is a `valueQuantity` normalized to UCUM when the value has a unit (left unset when the unit cannot be normalized), otherwise a `valueString`.
A narrative report text	One observation whose `valueString` is the report narrative.
Both	Two observations, one of each.
Neither	None — `DiagnosticReport.result` is empty.

Welcome

Product

FHIR

Implementation

APIs

Observation

Usage 1: Laboratory results

Stable ID

Fields

Result values

Reference ranges

Panel classification

Usage 2: Vital signs

Stable ID

Fields

Blood pressure

Usage 3: Diagnostic report findings

Stable ID

Fields

​Usage 1: Laboratory results

​Stable ID

​Fields

​Result values

​Reference ranges

​Panel classification

​Usage 2: Vital signs

​Stable ID

​Fields

​Blood pressure

​Usage 3: Diagnostic report findings

​Stable ID

​Fields

Usage 1: Laboratory results

Stable ID

Fields

Result values

Reference ranges

Panel classification

Usage 2: Vital signs

Stable ID

Fields

Blood pressure

Usage 3: Diagnostic report findings

Stable ID

Fields