This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• Operations

10.1 Resource Observation - Content

Orders and Observations Work Group

Maturity Level: 3

Compartments: Device, Encounter, Patient, Practitioner, RelatedPerson

Measurements and simple assertions made about a patient, device or other subject.

This resource is referenced by ClinicalImpression, Condition, DiagnosticReport, DiagnosticRequest, Goal, Immunization, ImmunizationRecommendation, MedicationAdministration, MedicationRequest, MedicationStatement, Procedure, QuestionnaireResponse and Sequence

10.1.3 Resource Content

 

Alternate definitions: Master Definition (XML, JSON), XML Schema/Schematron (for ) + JSON Schema, ShEx (for Turtle), JSON-LD (for RDF as JSON-LD),

10.1.3.1 Terminology Bindings

Path	Definition	Type	Reference
Observation.status	Codes providing the status of an observation.	Required	ObservationStatus
Observation.category	Codes for high level observation categories .	Example	Observation Category Codes
Observation.code Observation.component.code	Codes identifying names of simple observations.	Example	LOINC Codes
Observation.dataAbsentReason Observation.component.dataAbsentReason	Codes specifying why the result (Observation.value[x]) is missing.	Extensible	Observation Value Absent Reason
Observation.interpretation Observation.component.interpretation	Codes identifying interpretations of observations.	Extensible	Observation Interpretation Codes
Observation.bodySite	Codes describing anatomical locations. May include laterality.	Example	SNOMED CT Body Structures
Observation.method	Methods for simple observations.	Example	Observation Methods
Observation.referenceRange.meaning	Code for the meaning of a reference range.	Example	Observation Reference Range Meaning Codes
Observation.related.type	Codes specifying how two observations are related.	Required	ObservationRelationshipType

10.1.3.2 Constraints

• obs-3: On Observation.referenceRange: Must have at least a low or a high or text (expression on Observation.referenceRange: low.exists() or high.exists() or text.exists())
• obs-6: dataAbsentReason SHALL only be present if Observation.value[x] is not present (expression : dataAbsentReason.empty() or value.empty())
• obs-7: If code is the same as a component code then the value element associated with the code SHALL NOT be present (expression : value.empty() or code!=component.code)

10.1.4 Notes:

At its simplest, a resource instances can consist of only a code and a value, and status flag. The relevance of other properties will vary based on the type of observation.

Profiles will be created to provide guidance on capturing certain types of simple observations. This resource focuses on the level of detail captured by most systems. However, any "simple" observation can easily be broken into numerous components and sub-components to provide additional information relevant in certain circumstances. As with other resources, extensions can be used to introduce this additional complexity.

10.1.4.1 Grouping of Observations

Many observations have important relationships to other observations and need to be assembled in groups together (traditionally referred to as "panels" or " batteries" by laboratories) that can be used to represent relationships between the individual data items. Typically this is done by referencing the individual observations in the DiagnosticReport resource where the DiagnosticReport.code names the panel and serves as the grouping element. Several examples demonstrate observation grouping using DiagnosticReport as the grouper.

The Observation resource has two structures for grouping observations which allow for grouping and even complex nesting of results. In addition to representing a single observation. the Observation resource can group other observations.

First, several observations can be linked together using the Observation.related element with a defined relationship type. This approach should be used when the attributes within the resource for each observation are different and/or each panel result exists or needs to be processed as independent FHIR resource (i.e they "stand alone"). The Observation.related element defines the grouping of observations into a panel/battery in this case. The Observation.code names the panel but typically does not have its own Observation.value and the set of member observations for a panel or battery are listed in the Observation.related element. This structure also permits further nesting of groups (panel of panels). For example, a bacterial cultures with susceptibility testing can use this structure for grouping, because a panel for susceptibility tests (one for each bacterium isolated) would be linked as panel to the observation about each organism isolated. The example of a complex micro isolate and sensitivities report demonstrates this.

Secondly Observations can be grouped using the Observation.component element. Observation.component SHOULD NOT be used to group results that can be reasonably interpreted independently. If the panel members share the same attributes and are not separable observations (i.e - they don't "stand alone") or don't need to be processed independently, then the Observation.component element may be used to group them within a single resource. As is true when using Observation.related above, the observation for a panel that carries the component typically does not have its own Observation.value. For example systolic and diastolic blood pressure are represented as single Observation - Blood Pressure Panel because the two are almost always produced together. The GFR example demonstrates another example grouping of observations using Observation.component to tie together the race based estimates of glomerular filtration based upon a serum creatinine measurement. Grouping via components should be used judiciously because what is available to group can vary widely with the source and the idea of what to group together is often highly contextual and based upon the end user's point of view.

Assessment tools such as an Apgar or Glasgow score may be represented with both an overall value and related observations or answers from which a final score or value is derived and may be grouped as a set of observations using the Observation.related structure. For example, the Glasgow coma score example is structured like a panel with 3 component observations that measure the status of a given aspect of the patients neurological status. These are added together to get Glasgow Coma Score value.

10.1.4.2 Value[x] and Datatypes

• The element, Observation.value[x], has a variable name depending on the type as follows:
  • valueQuantity
  • valueCodeableConcept
  • valueString
  • valueRange
  • valueRatio
  • valueSampledData
  • valueAttachment
  • valueTime
  • valueDateTime
  • valuePeriod
• If the data element is usually coded or if the type associated with the Observation.code defines a coded value, use CodeableConcept instead of string data type even if the value is uncoded text. For example the LOINC 43304-5 Chlamydia trachomatis rRNA [Presence] in Unspecified specimen by Probe and target amplification method is typically associated with coded presence/absence concepts. Using the coded value for 'negative' with a standard code translation, the Observation.valueCodeableConcept would be:

  			"valueCodeableConcept": {
  			"coding": [
  			  {
  				"system": "http://snomed.info/sct",
  				"code": "260385009",
  				"display": "Negative"
  			  },
  			  {
  				"system": "urn:oid:2.16.840.1.113883.3.72.5.24",
  				"code": "NEG",
  				"display": "Negative"
  			  }
  			],
  			"text": "Negative for Chlamydia Trachomatis rRNA"
  			  }
  			

  Using text only, the Observation.valueCodeableConcept the would be:

  			"valueCodeableConcept": {
  			"text": "Negative for Chlamydia Trachomatis rRNA"
  			  }
  			

• A value set comprised of a standard nomenclature such as SNOMED CT or a source system ("local") coded result values is bound to the ValueCodeableConcept element. Coded results are often coded in multiple value sets based on different code systems and these may be mapped using the ConceptMap resource and/or given as translations directly in the element as shown in the example above.
• The Boolean data type is rarely used for Observation.value[x] because most observations result values are never truly Boolean due to exceptional values such as "unknown". If needed, use valueCodeableConcept for a Boolean concept instead, and select codes from HL7 v2 Table 0136. These "yes/no" concepts can be mapped to the display name "true/false" or other mutually exclusive terms that may be needed.
• The special values "E" (error), "L" (below detection limit) and "U" (above detection limit) can be used are in the SampledData data type. However when using valueQuantity in an observation for above and below detection limit values, valueQuantity should be used by stating the limit along with the comparator. In addition, when there is an error the dataAbsentReason element should be used with the appropriate value ( 'error' or "NaN"). For example if the value was below the lower limit of detection of <2.0 mmol/L the Observation.valueQuantity would be:

  		"valueQuantity": {
      "value": 2.0,
       "comparator" : "<",
      "unit": "mmol/l",
      "system": "http://unitsofmeasure.org",
      "code": "mmol/L"
       }
  			

  If the value was "NaN" (i.e. an error) the Observation.valueCodeableConcept would be absent and Observation.dataAbsentReason would be:

  "dataAbsentReason": {
      "coding": [
        {
          "system": "http://hl7.org/fhir/data-absent-reason",
          "code": "NaN",
          "display": "Not a Number"
        }
        

• Because there are multiple types allowed for the value element, multiple value search parameters are defined. There is no standard parameter for searching values of type Attachment, or Ratio

10.1.4.3 Physiologically Relevant Time of the Observation

The effectiveDateTime or effectivePeriod is the time that the observation is most relevant as an observation of the subject. For a biological subject (e.g. a human patient), this is the physiologically relevant time of the observation. In the case of an observation using a specimen, this represents the start and end of the specimen collection (e.g. 24 hour Urine Sodium), but if the collection time is sufficiently short, this is reported as a point in time value (e.g. normal venipuncture). In the case of an observation obtained directly from a subject (e.g. BP, Chest X-ray), this is the start and end time of the observation process, which again, is often reported as a single point in time.

10.1.4.4 Reference Range

Most commonly observations will only have one generic reference range. Reference ranges may be useful for lab tests and other measures like systolic blood pressure, but will have little relevance for something like "pregnancy status". Systems MAY choose to restrict to only supplying the relevant reference range based on knowledge about the patient (e.g. specific to the patient's age, gender, weight and other factors), but this may not be possible or appropriate. Whenever more than one reference range is supplied, the differences between them SHOULD be provided in the reference range and/or age properties.

10.1.4.5 Canceled or Aborted Observations

If a measurement or test could not be completed (for example if the specimen is unsatisfactory or the provider cancelled the order), then the status value should be updated to "canceled" and the specific details given - preferably as coded values in the dataAbsentReason or valueCodeableConcept element. Additional information may provided in comments as well. The specimen reject example demonstrates this using a coded value for unsatisfactory specimen in dataAbsentReason.

10.1.5 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Paths	In Common
category	token	The classification of the type of observation	Observation.category
code	token	The code of the observation type or component type	Observation.code, Observation.component.code	8 Resources
code-value-concept	composite	Code and coded value parameter pair, including in components
code-value-date	composite	Code and date/time value parameter pair, including in components
code-value-quantity	composite	Code and quantity value parameter pair, including in components
code-value-string	composite	Code and string value parameter pair, including in components
data-absent-reason	token	The reason why the expected value in the element Observation.value[x] is missing.	Observation.dataAbsentReason, Observation.component.dataAbsentReason
date	date	Obtained date/time. If the obtained element is a period, a date that falls in the period	Observation.effective[x]	18 Resources
device	reference	The Device that generated the observation data.	Observation.device (Device, DeviceMetric)
encounter	reference	Healthcare event related to the observation	Observation.encounter (Encounter)	12 Resources
identifier	token	The unique id for a particular observation	Observation.identifier	26 Resources
method	token	The method used for the observation	Observation.method
patient	reference	The subject that the observation is about (if patient)	Observation.subject (Patient)	31 Resources
performer	reference	Who performed the observation	Observation.performer (Practitioner, Organization, Patient, RelatedPerson)
related	composite	Related Observations - search on related-type and related-target together
related-target	reference	Resource that is related to this one	Observation.related.target (Observation, Sequence, QuestionnaireResponse)
related-type	token	has-member | derived-from | sequel-to | replaces | qualified-by | interfered-by	Observation.related.type
specimen	reference	Specimen used for this observation	Observation.specimen (Specimen)
status	token	The status of the observation	Observation.status
subject	reference	The subject that the observation is about	Observation.subject (Group, Device, Patient, Location)
value-concept	token	The value or component value of the observation, if the value is a CodeableConcept	Observation.valueCodeableConcept, Observation.component.valueCodeableConcept
value-date	date	The value of the observation, if the value is a date or period of time	Observation.valueDateTime, Observation.valuePeriod
value-quantity	quantity	The value or component value of the observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)	Observation.valueQuantity, Observation.component.valueQuantity
value-string	string	The value or component value of the observation, if the value is a string, and also searches in CodeableConcept.text	Observation.valueString, Observation.component.valueString