• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• Operations
• R4 Conversions
• Search Params

10.1 Resource Observation - Content

Orders and Observations Work Group

Maturity Level: N

Normative (from v4.0.0)

Security Category: Patient

Compartments: Device, Encounter, Patient, Practitioner, RelatedPerson

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

10.1.3 References to this Resource

• Implements: Event
• Resource References: AdverseEvent, AllergyIntolerance, Appointment, CarePlan, ChargeItem... Show 23 more, ClinicalImpression, Condition, Contract, DeviceRequest, DeviceUsage, DiagnosticReport, Encounter, FamilyMemberHistory, GenomicStudy, Goal, ImagingStudy, Immunization, MedicationAdministration, MedicationRequest, MedicationUsage, NutritionIntake, itself, Procedure, QuestionnaireResponse, RequestOrchestration, RiskAssessment, ServiceRequest and SupplyRequest
• Extension References: FamilyMemberHistory Observation, Observation Precondition, Observation Replaces, Observation Sequel To, Procedure Caused By and reason

10.1.4 Resource Content

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

10.1.4.1 Terminology Bindings

Path	Definition	Type	Reference
Observation.triggeredBy.type	Codes providing the type of triggeredBy observation.	Required	triggeredBytype
Observation.status	Codes providing the status of an observation.	Required	ObservationStatus
Observation.category	Observation Category codes.	Preferred	ObservationCategoryCodes
Observation.code	This value set includes all LOINC codes	Example	LOINCCodes (a valid code from LOINC )
Observation.dataAbsentReason	Used to specify why the normally expected content of the data element is missing.	Extensible	DataAbsentReason
Observation.interpretation	A categorical assessment, providing a rough qualitative interpretation of the observation value, such as “normal”/ “abnormal”,”low” / “high”, “better” / “worse”, “susceptible” / “resistant”, “expected”/ “not expected”. The value set is intended to be for ANY use where coded representation of an interpretation is needed. Notes: This is being communicated in v2.x in OBX-8 (Observation Interpretation), in v3 in ObservationInterpretation (CWE) in R1 (Representative Realm) and in FHIR in Observation.interpretation. Historically these values come from the laboratory domain, and these codes are extensively used. The value set binding is extensible, so codes outside the value set that are needed for interpretation concepts (i.e. particular meanings) that are not included in the value set can be used, and these new codes may also be added to the value set and published in a future version.	Extensible	ObservationInterpretationCodes (a valid code from ObservationInterpretation )
Observation.bodySite	This value set includes all codes from SNOMED CT where concept is-a 442083009 (Anatomical or acquired body site (body structure)).	Example	SNOMEDCTBodyStructures
Observation.method	Observation Method codes from SNOMED CT where concept is-a 272394005 (Technique (qualifier value)) or is-a 129264002 (Action (qualifier value)) or is-a 386053000 (Evaluation procedure(procedure))	Example	ObservationMethods
Observation.referenceRange.normalValue	Codes that describe the normal value in the reference range, such as “Negative” or “Absent”	Extensible	ObservationReferenceRangeNormalValueCodes (a valid code from ObservationreferenceRangeNormalValue)
Observation.referenceRange.type	This value set defines a set of codes that can be used to indicate the meaning/use of a reference range for a particular target population.	Preferred	ObservationReferenceRangeMeaningCodes
Observation.referenceRange.appliesTo	This value set defines a set of codes that can be used to indicate the particular target population the reference range applies to.	Example	ObservationReferenceRangeAppliesToCodes
Observation.component.code	This value set includes all LOINC codes	Example	LOINCCodes (a valid code from LOINC )
Observation.component.dataAbsentReason	Used to specify why the normally expected content of the data element is missing.	Extensible	DataAbsentReason
Observation.component.interpretation	A categorical assessment, providing a rough qualitative interpretation of the observation value, such as “normal”/ “abnormal”,”low” / “high”, “better” / “worse”, “susceptible” / “resistant”, “expected”/ “not expected”. The value set is intended to be for ANY use where coded representation of an interpretation is needed. Notes: This is being communicated in v2.x in OBX-8 (Observation Interpretation), in v3 in ObservationInterpretation (CWE) in R1 (Representative Realm) and in FHIR in Observation.interpretation. Historically these values come from the laboratory domain, and these codes are extensively used. The value set binding is extensible, so codes outside the value set that are needed for interpretation concepts (i.e. particular meanings) that are not included in the value set can be used, and these new codes may also be added to the value set and published in a future version.	Extensible	ObservationInterpretationCodes (a valid code from ObservationInterpretation )

10.1.4.2 Constraints

10.1.5 Notes:

10.1.5.1 Profiling Observation

At its simplest, a resource instance 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 are created to provide guidance on capturing certain types of observations for a given use case. The Observation resource focuses on the level of detail captured by most systems. However, for a given use case there may be additional constraints and additional information relevant in certain circumstances. As with other resources, extensions can be used to introduce this additional complexity.

10.1.5.2 Subject of an Observation

Typically, an observation is made about the subject - a patient, or group of patients, location, or device - and the distinction between the subject and what is directly measured for an observation is specified in the observation code itself ( e.g., "Blood Glucose") and does not need to be represented separately. However, three attributes may be used for representing the focus of the observation if it is not the subject itself. The specimen and bodySite elements are used to represent measurements taken on subject samples or anatomic and morphological locations, and focus represents specific aspect of the subject that are the point of attention such as another observation or a device implanted in a patient.

10.1.5.3 Observation Grouping

Many observations have important relationships to other observations and need to be grouped together. These structures have been defined to do this: DiagnosticReport and DiagnosticReport.result, Observation and the elements: Observation.component, Observation.hasMember and Observation.derivedFrom. The sections below provides guidance around which structure to use. Because the idea of what to group together is often highly contextual and based upon the end user's point of view, the choice of which structure to use will be driven by jurisdiction, organizational practice and context. Profiling will normally be necessary for implementation.

10.1.5.3.1 DiagnosticReport.result

DiagnosticReport relates directly to an order (ServiceRequest). The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations. Several examples demonstrate observation grouping using DiagnosticReport as the grouping structure.

10.1.5.3.2 Observation.component

Observation.component is used for any supporting result that cannot reasonably be interpreted and used outside the scope of the Observation it is a component of. Component observations may make up the separate and individual parts of the observation or may provide qualifying information to Observation.code and may only be able to be understood in relation to the Observation.code (for example, see the $stats operation). Therefore all code-value and component.code-component.value pairs need to be taken into account to correctly understand the meaning of the observation. Components should only be used when there is only one method, one observation, one performer, one device, and one time. Some use cases for using this structure include:

1. Observations that are commonly produced and interpreted together. For example, systolic and diastolic blood pressure are represented as a single Blood pressure panel.
2. Assessment tool results that are commonly produced and interpreted together. For example, a newborn Apgar score that is a single Observation with five components.
3. Representing multiple answers to a question (relationship and boundaries between Observation and Questionnaire/QuestionnaireResponse). For example, reporting the types of alcohol consumed by a patient

On the other hand, any observations that are clinically relevant outside the context of being a component of another observation should be represented by separate Observation resources. For example a Body Mass Index (BMI) Observation should not contain components for height and weight because they are clinically relevant observations on their own and should be represented by separate Observation resources. See the section below on how to relate independent Observations.

10.1.5.3.3 Observation.hasMember of and Observation.derivedFrom

Observation.hasMember and Observation.derivedFrom and the core extensions: Observation-sequelTo and Observation-replaces are used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. Two common use cases for using this structure are:

1. For grouping related observations such as for a "panel" or "battery". In this case the Observation.code represents the "panel" code, typically Observation.value[x] is not present, and the set of member Observations are listed in Observation.hasMember. This structure permits nested grouping when used with DiagnosticReport (e.g. complex micro isolate and sensitivities report).
2. When linking to other Observations from which an Observation is derived. In this case both Observation.code and Observation.value[x] are present, and the linked observations are listed in Observation.derivedFrom. An example of this would be a Body Mass Index (BMI) Observation where the height and weight measurements are referenced.

10.1.5.4 Using codes in Observation

When a result value is represented as a predefined concept using a code, valueCodeableConcept is used. This element is bound to a value set comprised of a standard nomenclature such as SNOMED CT or a source system ("local") coded result values.

10.1.5.4.1 Multiple Codings

Results may be coded in multiple value sets based on different code systems and these may be mapped using the ConceptMap resource and/or given as additional codings directly in the element as shown in the example below.

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, valueCodeableConcept would be:

		"valueCodeableConcept": {
			"coding": [
				{
					"system": "http://snomed.info/sct",
					"code": "260385009",
					"display": "Negative"
				}, {
					"system": "https://acme.lab/resultcodes",
					"code": "NEG",
					"display": "Negative"
				}
			],
			"text": "Negative for Chlamydia Trachomatis rRNA"
		}

		

10.1.5.4.2 Text values for coded results:

When the data element is usually coded or the type associated with the code element defines a coded value, use valueCodeableConcept even if there is no appropriate code and only free text is available. For example using text only, the valueCodeableConcept element would be:

		"valueCodeableConcept": {
			"text": "uncoded free text result"
		}

				

When a coded answer list includes a concept code for "other" and there is a free text description of the concept, the valueCodeableConcept.text element should be used to capture the full meaning of the source. In the example below, the answer code "Other" is provided in the valueCodeableConcept element and the text value supplied value in the CodeableConcept.text element.

	{
		"resourceType": "Observation",
		... snip ...
		"code": {
			"coding": [
				{
					"system": "http://loinc.org",
					"code": "74076-1",
					"display": "Medication or substance involved"
				}
			]
		},
		.. snip ...
		"valueCodeableConcept": {
			"coding": [
				{
					"system": "http://loinc.org",
					"code": " LA20343-2",
					"display": "Other substance: PLEASE SPECIFY"
				}
			],
			"text": "Other: Blue pills I found under my couch"
		}
		.. snip ...
	}
		   

10.1.5.4.3 Interoperability Issues using code value pairs in FHIR

A recurring issue for many observation events, regardless of the particular pattern, is determining how to populate observation.code and observation.value. While this is typically straight-forward for laboratory observations, it can get blurry for other types of observations, such as findings and disorders, family history observations, etc. This discussion focuses on the way in which the coded representation of such statements is expressed using the Observation.code and Observation.value elements.

There are two distinct facets that are central to a FHIR Observations:

• The action taken to make the finding and/or the property about which the property was observed. For example: measurement of blood hemoglobin.
• The result of the observation. For example: 14 g/dl.

Several different ways of representing the same information exist using different combinations of the Observation.code and Observation.value. Unconstrained use of the alternatives presents a major challenge for computation of semantic equivalence and for safe interpretation of observations originating from different applications and users. The following four patterns could reasonably represent the same case. Considering that the Observation resource needs to support many use cases, the appropriate place to define the specific pattern is expected to be done through profiles and implementation guides as specified by the jurisdictions and/or organizations implementing FHIR:

1. Observation.code represents the nature of the observation and the Observation.value a code represents the non-numeric result value. These are two distinct facets that are central to a FHIR Observations. For example:
   • code=[Examination]
   • value=[Abdomen tender]
2. Observation.code is nearly identical to 1) above, but the level of granularity is shifted from the value to code. For example:
   • code=[Abdominal examination]
   • value=[Tenderness]
3. The Observation.code is also expressed in a way that does not specify the observation action but indicates a statement about findings reduced to a single name (or term), as in the above item. In this example, the Observation.value is present and "qualifies" the finding typically confirming or refuting it. For example:
   • code=[Abdominal tenderness]
   • value=[found/true]
4. in this example the Observation.code is expressed in a way that does not specify the observation action but indicates a statement about findings reduced to a single name (or term). In this particular example in that context, the Observation.value is omitted. For example:
   • code=[Abdominal tenderness]
   • value element is omitted

10.1.5.4.4 Guidance:

1. Recommended rules for case 1 and 2 patterns:
   • The Observation.code is preferably a LOINC concept code.
     • If a SNOMED CT concept code is used, the expression SHOULD represent a 363787002 (Observable entity(Observable entity)) or 386053000 (Evaluation procedure(evaluation procedure))
   • For non-numeric values, the Observation.value is preferably a SNOMED CT concept code.
2. Recommended rules for case 3 pattern:
   • The Observation.code is preferably a LOINC or SNOMED CT concept code.
     • If a SNOMED CT concept code is used, the expression SHOULD represent a 404684003 (Clinical finding (finding)) , 413350009 (Finding with explicit context(finding)), or 272379006 (Event(event)).
   • The Observation.value is represented by either
     • valueBoolean
     • valueCodeableConcept preferably using:
       • SNOMED CT where concept is-a 362981000 (Qualifier value (qualifier value))
       • v2 Yes/no Indicator
       • v2 Expanded Yes/no Indicator (unfortunately is missing 'not given')
3. Recommended rules for case 4 pattern:
   • The Observation.code is preferably a SNOMED CT concept code where the concept is-a 404684003 (Clinical finding (finding)) , 413350009 (Finding with explicit context(finding)), or 272379006 (Event(event)).
   • The Observation.value is omitted. The default interpretation is the concept (single code or expression) represented in Observation.code is present in the patient. An Observation.dataAbsentReason value of 'clinical-finding' SHOULD be used to indicate why the expected value is missing.
4. SHOULD NOT use the Assertion pattern as described in HL7 Version 3 Implementation Guide: TermInfo - Using SNOMED CT in CDA R2 Models, Release 1 . ( The code is 'ASSERTION' and the value is a SNOMED CT concept or expression )

10.1.5.5 Refining the interpretation of an Observation using additional codes or Observations

The following list provides guidance on using codes or other observations to provide additional context that may alter how an observation is interpreted.:

1. If possible, use the most specific code you can

   e.g.:

   	{
   	"resourceType": "Observation",
   	... snip ...
   	"code": {
   		"coding": [
   			{
   				"system": "http://loinc.org",
   				"code": "6689-4",
   				"display": "Glucose [Mass/​volume] in Blood --2 hours post meal"
   			}
   		]
   	},
   	... snip ...
   	}
   			

2. Alternatively, use additional codes in Observation.code as described above.

   e.g.: Observation.code = coding-1: 59408-5 Oxygen saturation in Arterial blood by Pulse oximetry, coding-2: 20564-1 Oxygen saturation in Blood

   	{
   	"resourceType": "Observation",
   	... snip ...
   	"code": {
   		"coding": [
   			{
   				"system": "http://loinc.org",
   				"code": "59408-5",
   				"display": "Oxygen saturation in Arterial blood by Pulse oximetry"
   			},
   			{
   				"system": "http://loinc.org",
   				"code": "20564-1",
   				"display": "Oxygen saturation in Blood"
   			}
   		]
   	},
   	... snip ...
   	}
   			

3. As described above, observations are typically grouped together to provide additional information needed for correctly understanding and interpreting the observation. As an alternative to grouping observations, extensions may be used to provide references to other observations needed for understanding and interpreting an observation.

Note to Implementers: We are seeking input from the implementer community in evaluating existing Observation Extensions for this purpose

Feedback here .

10.1.5.6 Value[x] and Datatypes

• The element, Observation.value[x], has a variable name depending on the type as follows:
  • valueQuantity
  • valueCodeableConcept
  • valueString
  • valueBoolean
  • valueInteger
  • valueRange
  • valueRatio
  • valueSampledData
  • valueTime
  • valueDateTime
  • valuePeriod
  • valueAttachment
  
  
• See above section on Using codes for result values
• The Attachment data type is used to represent an observation result value if the actual value is a binary file such as an image. If the observation result value is derived from the binary file (for example 'X' detected and here is the the proof in this image), the binary file may be directly represented using DocumentReference and referenced in the Observation with derivedFrom. Images that are referenced as part of a report should be represented with DiagnosticReport.media or, if the entire report is in a binary format such as pdf, with DiagnosticReport.presentedForm.
  
  Examples Scenarios for using valueAttachment:
  • ...todo...
• The Boolean data type is rarely used for value[x] because most observations result values are never truly Boolean due to exceptional values such as "unknown", therefore they should use the CodeableConcept data type instead and select codes from http://terminology.hl7.org/ValueSet/v2-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 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 valueCodeableConcept element would be absent and dataAbsentReason element would be:

  		"dataAbsentReason": {
  			"coding": [
  				{
  					"system": "http://terminology.hl7.org/CodeSystem/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 Ratio

10.1.5.7 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.5.8 Reference Range

Most common observations will only have one generic reference range. Reference ranges may be useful for laboratory 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 might 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.5.9 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 "cancelled" and the specific details given - preferably as coded values in the dataAbsentReason or valueCodeableConcept element. Additional information may be provided in the `note` element as well. The specimen reject example demonstrates this using a coded value for unsatisfactory specimen in dataAbsentReason.

10.1.5.10 Genomic Reporting - Trial Use

Genomic reporting makes heavy use of the DiagnosticReport and Observation resources to represent structured, computable genomic data. An implementation guide describing how to represent genetic results can be found here .

Beyond the structured, computable data available in DiagnosticReport and Observation, metadata about the analysis performed is captured in the GenomicStudy resource. GenomicStudy aims at delineating relevant information of a genomic study. A genomic study might comprise one or more analyses, each serving a specific purpose. These analyses may vary in method (e.g., karyotyping, CNV, or SNV detection), performer, software, devices used, or regions targeted.

When referencing genomic analysis from an Observation, the partOf attribute MAY be used to reference the GenomicStudy that led to this observation being made. Another option is that derivedFrom MAY be used to reference a DocumentReference when the observation was derived from the data in the file, even with that file was produced as part of a GenomicStudy output. Also, derivedFrom MAY be used to reference the GenomicStudy where the data was produced.

10.1.6 Operations defined for Observation

10.1.6.1 Searching for the Last N Observations

The lastn query operation meets the common need for searching for the most recent or "last known" Observations for a subject. Examples where this query could be used:

• Fetch the last 5 temperatures for a patient to view trends
• Get the most recent laboratory results for patient
• Fetch the last 3 results for all vitals for a patient

See the Last N Observations Query section in the Observation resource operations page for more information and examples

10.1.6.2 Retrieving Statistics for Laboratory Observations

The stats operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation is focused on Observation resources with valueQuantity elements that have UCUM unit codes. Examples where this operation could be used:

• Get the average, min, max and count of a series of BP measurements for a patient
• Determine 20th or 80th percentile on a set of measurements over a time period

See the Observation Statistics section in the Observation resource operations page for more information and examples

10.1.7 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	Expression	In Common
based-on	reference	Reference to the service request.	Observation.basedOn (CarePlan, MedicationRequest, NutritionOrder, DeviceRequest, ServiceRequest, ImmunizationRecommendation)
category	token	The classification of the type of observation	Observation.category
code	token	The code of the observation type	Observation.code	13 Resources
code-value-concept	composite	Code and coded value parameter pair	On Observation:   code: code   value-concept: value.ofType(CodeableConcept)
code-value-date	composite	Code and date/time value parameter pair	On Observation:   code: code   value-date: value.ofType(DateTime) | value.ofType(Period)
code-value-quantity	composite	Code and quantity value parameter pair	On Observation:   code: code   value-quantity: value.ofType(Quantity)
code-value-string	composite	Code and string value parameter pair	On Observation:   code: code   value-string: value.ofType(string)
combo-code	token	The code of the observation type or component type	Observation.code | Observation.component.code
combo-code-value-concept	composite	Code and coded value parameter pair, including in components	On Observation | Observation.component:   combo-code: code   combo-value-concept: value.ofType(CodeableConcept)
combo-code-value-quantity	composite	Code and quantity value parameter pair, including in components	On Observation | Observation.component:   combo-code: code   combo-value-quantity: value.ofType(Quantity)
combo-data-absent-reason	token	The reason why the expected value in the element Observation.value[x] or Observation.component.value[x] is missing.	Observation.dataAbsentReason | Observation.component.dataAbsentReason
combo-value-concept	token	The value or component value of the observation, if the value is a CodeableConcept	Observation.value.ofType(CodeableConcept) | Observation.component.value.ofType(CodeableConcept)
combo-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.value.ofType(Quantity) | Observation.value.ofType(SampledData) | Observation.component.value.ofType(Quantity) | Observation.component.value.ofType(SampledData)
component-code	token	The component code of the observation type	Observation.component.code
component-code-value-concept	composite	Component code and component coded value parameter pair	On Observation.component:   component-code: code   component-value-concept: value.ofType(CodeableConcept)
component-code-value-quantity	composite	Component code and component quantity value parameter pair	On Observation.component:   component-code: code   component-value-quantity: value.ofType(Quantity)
component-data-absent-reason	token	The reason why the expected value in the element Observation.component.value[x] is missing.	Observation.component.dataAbsentReason
component-value-concept	token	The value of the component observation, if the value is a CodeableConcept	Observation.component.value.ofType(CodeableConcept)
component-value-quantity	quantity	The value of the component observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)	Observation.component.value.ofType(Quantity) | Observation.component.value.ofType(SampledData)
data-absent-reason	token	The reason why the expected value in the element Observation.value[x] is missing.	Observation.dataAbsentReason
date	date	Obtained date/time. If the obtained element is a period, a date that falls in the period	Observation.effective.as(dateTime) | Observation.effective.as(Period) | Observation.effective.as(Timing) | Observation.effective.as(instant)	17 Resources
derived-from	reference	Related measurements the observation is made from	Observation.derivedFrom (GenomicStudy, Observation, ImagingStudy, MolecularSequence, ImagingSelection, QuestionnaireResponse, DocumentReference)
device	reference	The Device that generated the observation data.	Observation.device (Device, DeviceMetric)
encounter	reference	Encounter related to the observation	Observation.encounter (Encounter)	11 Resources
focus TU	reference	The focus of an observation when the focus is not the patient of record.	Observation.focus (Any)
has-member	reference	Related resource that belongs to the Observation group	Observation.hasMember (Observation, MolecularSequence, QuestionnaireResponse)
identifier	token	The unique id for a particular observation	Observation.identifier	30 Resources
method	token	The method used for the observation	Observation.method
part-of	reference	Part of referenced event	Observation.partOf (GenomicStudy, Immunization, MedicationDispense, MedicationAdministration, Procedure, ImagingStudy, MedicationUsage)
patient	reference	The subject that the observation is about (if patient)	Observation.subject.where(resolve() is Patient) (Patient)	33 Resources
performer	reference	Who performed the observation	Observation.performer (Practitioner, Organization, CareTeam, Patient, PractitionerRole, RelatedPerson)
specimen	reference	Specimen used for this observation	Observation.specimen (Specimen, Group)
status	token	The status of the observation	Observation.status
subject	reference	The subject that the observation is about	Observation.subject (Practitioner, Group, Organization, BiologicallyDerivedProduct, NutritionProduct, Device, Medication, Patient, Procedure, Substance, Location)
value-concept	token	The value of the observation, if the value is a CodeableConcept	Observation.value.ofType(CodeableConcept)
value-date	date	The value of the observation, if the value is a date or period of time	Observation.value.ofType(dateTime) | Observation.value.ofType(Period)
value-quantity	quantity	The 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.value.ofType(Quantity) | Observation.value.ofType(SampledData)
value-string	string	The value of the observation, if the value is a string, and also searches in CodeableConcept.text	Observation.value.ofType(string) | Observation.value.ofType(CodeableConcept).text