Observations are a central element in healthcare, used to support diagnosis, monitor progress, determine baselines and patterns and even capture demographic characteristics, as well as capture results of tests performed on products and substances. Most observations are simple name/value pair assertions with some metadata, but some observations group other observations together logically, or even are multi-component observations. Note that the DiagnosticReport resource provides a clinical or workflow context for a set of observations and the Observation resource is referenced by DiagnosticReport to represent laboratory, imaging, and other clinical and diagnostic data to form a complete report.
Social history like tobacco use, family support, or cognitive status
Core characteristics like pregnancy status, or a death assertion
Product quality tests such as pH, Assay, Microbial limits, etc. on product and substance
*The boundaries between clinical findings and disorders remains a challenge in medical ontology. Refer the Boundaries section below and in Condition for general guidance. These boundaries can be clarified by profiling Observation for a particular use case.
The following set of core profiles for the Observation resource have been defined. Implementations using the Observation resource when expressing the profile-specific concepts as structured data, SHALL conform to the specified profiles:
The FHIR Vital Signs profiles set the minimum expectations for the Observation resource to record, search and fetch the vital signs (e.g. temperature, blood pressure, respiration rate, etc.) associated with a patient
10.1.2 Boundaries and Relationships
At its core, Observation allows expressing a name-value pair or structured collection of name-value pairs. As such, it can support conveying any type of information desired. However, that is not its intent. Observation is intended for capturing measurements and subjective point-in-time assessments. It is not intended to be used for those specific contexts and use cases already covered by other FHIR resources. For example, the AllergyIntolerance resource represents a patient allergies, MedicationStatement resource: medications taken by a patient, FamilyMemberHistory resource: a patient's family history, Procedure resource: information about a procedure, and QuestionnaireResponse resource: a set of answers to a set of questions.
The Observation resource should not be used to record clinical diagnosis about a patient or subject that are typically captured in the Condition resource or the ClinicalImpression resource. The Observation resource is often referenced by the Condition resource to provide specific subjective and objective data to support its assertions, including symptoms and assessments of the presence or absence of diagnostically significant phenomena. Symptoms may sometimes be recorded as Conditions if no etiology has yet been identified, or if the symptom is severe enough to merit independent treatment, but in most cases a symptom can be represented in an Observation with a relationship to the Condition of concern. There will however be situations of overlap. For example, a response to a question of "have you ever taken illicit drugs" could in principle be represented using MedicationStatement, but most systems would treat such an assertion as an Observation. In some cases, such as when source data is coming from an HL7 V2 feed, a system might not have information that allows it to distinguish diagnosis, allergy and other "specialized" types of observations from laboratory, vital sign and other observation types intended to be conveyed with this resource. In those circumstances, such specialized observations may also appear using this resource. Adhering to such convention is an appropriate use of Observation. If implementers are uncertain whether a proposed use of Observation is appropriate, they're encouraged to consult with implementers on chat.fhir.org implementer's stream
When an Observation instantiates an ObservationDefinition, the elements of the Observation resource are expected to inherit their content from the corresponding definitional elements declared in the ObservationDefinition resource listed here here.
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Laboratory reports, pathology reports, and imaging reports should be represented using the DiagnosticReport resource. The Observation resource is referenced by the DiagnosticReport to provide the atomic results for a particular investigation. "Laboratories routinely have a variable that is summative across a series of discrete variables - these are usually called 'impressions' or 'interpretations'. Sometimes they are algorithmically specified and sometimes they have the imprimatur of pathologists and they are conveyed in Observation or DiagnosticReport instead of the Clinical Impression resource. The Observation resource should not be used to record clinical diagnosis about a patient or subject as discussed above.
Measurements and simple assertions + Rule: dataAbsentReason SHALL only be present if Observation.value[x] is not present + Rule: If Observation.component.code is the same as Observation.code, then Observation.value SHALL NOT be present (the Observation.component.value[x] holds the value). + Rule: bodyStructure SHALL only be present if Observation.bodySite is not present + Rule: dataAbsentReason SHALL only be present if Observation.component.value[x] is not present
Measurements and simple assertions + Rule: dataAbsentReason SHALL only be present if Observation.value[x] is not present + Rule: If Observation.component.code is the same as Observation.code, then Observation.value SHALL NOT be present (the Observation.component.value[x] holds the value). + Rule: bodyStructure SHALL only be present if Observation.bodySite is not present + Rule: dataAbsentReason SHALL only be present if Observation.component.value[x] is not present
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.
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.
If Observation.component.code is the same as Observation.code, then Observation.value SHALL NOT be present (the Observation.component.value[x] holds the value).
value.empty() or component.code.where(coding.intersect(%resource.code.coding).exists()).empty()
dataAbsentReason SHALL only be present if Observation.component.value[x] is not present
component.empty() or component.where(dataAbsentReason.exists()).all(value.empty())
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 need to be grouped together in some fashion to document critical
relationships for interpretation of the observations. The methods to do so primarily are
through DiagnosticReport using DiagnosticReport.result and Observation using
Observation.component, Observation.hasMember, and
Observation.derivedFrom. See the Diagnostics Module for guidance related to
Microbiology reporting and relevant relationships necessary to support reflex, follow-up,
and add-on orders.
Note that Composition may also be used to organize observations and
diagnostic reports, but that is only for purpose of readability, not to record critical
relationships for interpretations. See DiagnosticReport.composition and Composition for
further considerations for that separate purpose.
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:
Observations that are commonly produced and interpreted together. For example, systolic and diastolic blood pressure are represented as a single Blood pressure panel.
Assessment tool results that are commonly produced and interpreted together. For example, a newborn Apgar score that is a single Observation with five components.
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:
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)
as described in the Diagnostics
Module
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:
When the data element is usually coded or the type associated with the code element defines a coded value, use valueCodeableConcepteven 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:
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]
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]
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]
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:
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.
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))
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.
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.:
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
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.
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:
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 Cancelled or Not Performed 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
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)
Diagnostics
Observation 
identifier 
instantiates[x] 
instantiatesCanonical
triggeredBy 
type 
referenceRange 
obs-3
obs-10
|
Propose a change