View raw Markdown
type: resourceresource: profile-heartrate

profile-heartrate

Introduction

Note to Balloters: To ensure that the Observation resource is ready for Normative status, we are seeking ballot comments on the substantive content. The key changes made since R5 include:

  • Multiple updates to the Vital Signs profiles (including the Vital Signs Base profile and the set of specific Vital Signs profiles). The primary changes include:

  • Removed references to the LOINC "magic value" code, and instead refer to it as the "interoperability category".

  • Created value sets of the specific LOINC codes that should apply for each vital sign profile, and create a 'preferred' binding from Observation.code to the value set for that profile.

  • Renamed the main vital signs page to "Observation Vital Signs Profiles", and adjust other names and text accordingly.

  • Renamed the title of the "base" vital signs profile (which the other specific vital sign profiles are based on) to "Vital Signs Base Profile", to help make this clear.

  • Move the reference and link to the "Vital Signs Base Profile" to a more prominently visible location on the Observation Vital Signs Profiles page (as the "header" for the requirements list).

  • Made additional text changes needed for overall clarity and consistency.

  • Updated the vital signs examples where needed to be consistent with the updated profiles.

  • The Observation.bodySite element has been deprecated, corresponding with the change to make Observation.bodyStructure a CodeableReference.

  • The 'instantiates[x]' element (with the 'instantiatesCanonical' and 'instantiatesReference' choices) has been removed and is replaced with the workflow instantiation extensions: https://build.fhir.org/workflow-extensions.html.

  • These elements previously marked as 'Trial Use' (TU) are now Normative candidates:

  • Observation.triggeredBy

  • Observation.focus

  • Observation.bodyStructure

  • Observation.referenceRange.normalValue

  • Observation.referenceRange.type

  • Observation.organizer

  • The 'organizer' element was newly added to the Observation resource in the previous R6 3rd Draft ballot cycle (2025-04-03), so there has been less time available for it to be reviewed, but it is now also a Normative candidate. The 'organizer' element is intended to help clarify and make explicit when an instance of the Observation resource is used for organizing/grouping sets of sub-observations (e.g., for laboratory panel/battery result reporting). This capability is particularly applicable for use in laboratory result reporting, but it can also be used as appropriate with other types of observations.

Scope and Usage

This resource is an event resource from a FHIR workflow perspective - see Workflow.

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, substances, and environments. 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.

Uses for the Observation resource include:

*The boundaries between clinical findings and disorders remains a challenge in medical ontology. Refer to the Boundaries section below and in Condition for general guidance. These boundaries can be clarified by profiling Observation for a particular use case.

Core Profiles for Observation

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:

ProfileDescription
Vital SignsThe 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

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 ClinicalAssessment 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 are 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.

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 ClinicalAssessment resource. The Observation resource should not be used to record clinical diagnosis about a patient or subject as discussed above.

The Observation resource is used extensively for observations about people, groups, devices, locations, substances, and procedures – not about the record describing these entities. For example, DeviceAlert represents a single alert or alarm condition detected and signaled by a patient-connected health / medical device to create clinician’s awareness of a patient safety risk that needs to be addressed, whereas Observation captures any evidentiary data needed to interpret the alert condition or that is the reason why the alert condition is present.

The Observation resource contains several elements related to the origin and quality of the observation. To record more detailed information about the source of an Observation, the Provenance resource may be used. More in-depth commentary about or evaluation of the Observation record itself may be recorded in ArtifactAssessment.

Notes

Notes:

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.

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, two attributes may be used for representing the focus of the observation if it is not the subject itself. The specimen, and bodyStructure 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.

There may be some confusion about what to record in the subject, focus, and device elements, and the observation-recording extension, particularly involving Devices.

Note that a device could appear in any of these elements depending on the role it is playing in a particular Observation; there is no fixed element where a device would be recorded. Similarly, patients, related persons, practitioners and other entities may in may appear in various elements. As a result, finding all Observations involving a particular device, etc. may require multiple searches.

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.

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.

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. Another example are ST segment measurements from the different ECG leads (e.g., ST I, ST II, etc.).
  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.

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) as described in the Diagnostics Module
  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.

Observation Delta

To perform a delta check one can instantiate a new observation (the comparison observation) with derivedFrom populated with references to the two prior Observations that triggered the delta check. Also, the Observation.interpretation of the comparison Observation has the code of the interpretation of the delta check.

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.

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"
    }

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 ...
}

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:

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

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
  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 )

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.

[%stu-note dstu%] We are seeking input from the implementer community in evaluating existing Observation Extensions for this purpose

Feedback here. [%end-note%]

Value[x] and Datatypes

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.

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.

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.

For Observations that will not or were not performed:

Genomic Reporting

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 when that file was produced as part of a GenomicStudy output. Also, derivedFrom MAY be used to reference the GenomicStudy where the data was produced.

Operations defined for Observation

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:

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

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:

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

StructureDefinition

Elements (Simplified)

Mappings

Mapping Exceptions

observation-event-mapping-exceptions.xml

Divergent Elements

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. | resource=This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.

Unmapped Elements

observation-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements