Observation-vitalsigns - FHIR v4.0.1 (2024)

10.1.17 Introduction

Vital signs will be one of the first areas where there is a need for a single, global vocabulary to allow for ubiquitous access and re-use. Particularly with the use of wearables by patients where they want to/need to share information from those devices. To meet this need there must be a consistent vocabulary and a common syntax to achieve semantic interoperability. The FHIR Vital Signs profile sets minimum expectations for the Observation resource to record, search and fetch the vital signs associated with a patient that include the primary vital signs plus additional measurements such as height, weight and BMI. Support for basic mandatory searching of resources is defined below in the Quick Start section. When a FHIR implementation supports any of the vital signs listed below, the implementation SHALL conform to this profile for the vital sign observation.

These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the ONC sponsored Data Access Framework (DAF) project and were subsequently updated to define the minimum mandatory conformance requirements needed for accessing patient data as defined by the Argonaut pilot implementations.

10.1.18 Scope and Usage

Example Usage Scenarios:

The following are example usage scenarios for this profile:

• Query for vital signs of a particular patient

10.1.18.0.0.1 Mandatory Data Elements and Terminology

The following data-elements are mandatory (i.e. data SHALL be present). These are presented below in a simple human-readable explanation. Profile-specific guidance and valid examples are provided as well. Note that many of the examples capture more than the minimum required. The links to the Profile Definitions provide the formal views of the profile content, descriptions, mappings and the StructureDefinitions in JSON and XML.

Each Observation must have:

1. a status
2. a category code of 'vital-signs'
3. a "magic value" which tells you what is being measured
   • LOINC was chosen for the "magic values" because this aligns with the most countries, but it can be treated as simply a fixed core set of common codes to communicate basic vital signs. Implementers that need to use a different code system can still map accordingly.
4. a patient
5. a time indicating when the measurement was taken
6. a numeric result value and standard UCUM unit which is taken from the Unit Code column in the table below.
   • note: if there is no numeric result then you have to supply a reason

10.1.20 Quick Start

Below is an overview of required search and read operations

Clients

• A client has connected to a server and fetched all of a patient's vital signs by searching by category using GET [base]/Observation?patient=[id]&category=vital-signs.
• A client has connected to a server and fetched all of a patient's vital signs searching by category code and date range using GET [base]/Observation?patient=[id]&category=vital-signs&date=[date]{&date=[date]}.
• A client has connected to a server and fetched any of a patient's vital signs by searching by one or more of the codes listed above using GET [base]/Observation?patient=[id]&code[vital sign LOINC{,LOINC2,LOINC3,...}].

• A client SHOULD be capable of connecting to a server and fetching any of a patient's vital signs searching by one or more of the codes listed above and date range using GET [base]/Observation?patient=[id]&code=[LOINC{,LOINC2...}]vital-signs&date=[date]{&date=[date]}.

Servers

• A server is capable of returning all of a patient's vital signs that it supports using GET [base]/Observation?patient=[id]&category=vital-signs.
• A server is capable of returning all of a patient's vital signs queried by date range using GET [base]/Observation?patient=[id]&category=vital-signs&date=[date]{&date=[date]}.
• A server is capable of returning any of a patient's vital signs queried by one or more of the codes listed above using GET [base]/Observation?patient=[id]&code[vital sign LOINC{,LOINC2,LOINC3,...}].

• A server SHOULD be capable of returning any of a patient's vital signs queried by one or more of the codes listed above and date range using GET [base]/Observation?patient=[id]&code=[LOINC{,LOINC2...}]vital-signs&date=[date]{&date=[date]}.

• A server has ensured that every API request includes a valid Authorization token, supplied via:Authorization: Bearer {server-specific-token-here}
• A server has rejected any unauthorized requests by returning an HTTP 401 Unauthorized response code.

10.1.20.0.1 GET [base]/Observation?patient=[id]&category=vital-signs

Example:Search for all Vital Signs measurements for a patient

Support: Mandatory to support search by category code.

Implementation Notes: Search based on vital sign category code. This search fetches a bundle of all Observation resources with category 'vital-signs' for the specified patient (how to search by reference) and (how to search by token). The table above is the minimum set, additional vital signs are allowed.

Response Class:

• (Status 200): successful operation
• (Status 400): invalid parameter
• (Status 401/4xx): unauthorized request
• (Status 403): insufficient scope

10.1.20.0.2 GET [base]/Observation?patient=[id]&code=[vital sign LOINC{,LOINC2,LOINC3,...}]

Example:Search for all heart rate observations for a patient:

Example:Search for all heart rate, respiratory rate and blood pressure observations for a patient:

Support: Mandatory to support search by vital sign LOINC(s) listed above.

Implementation Notes: 1)Search based on vital sign LOINC code(s). This fetches a bundle of all Observation resources for specific vital sign(s) listed in the table above for the specified patient (how to search by reference) and [how to search by token)]. 2) The "code" parameter searches only Observation.code. For example when fetching blood pressures the resource will be only be returned when the search is based on 85354-9(Systolic and Diastolic BP). Using the component codes 8480-6(Systolic BP) or 8462-4 (Diastolic BP) will not return the resource . In order to search both Observation.code and Observation.component.code in a single query, use the "combo-code" search parameter.

Response Class:

• (Status 200): successful operation
• (Status 400): invalid parameter
• (Status 401/4xx): unauthorized request
• (Status 403): insufficient scope

10.1.20.0.3 GET [base]/Observation?patient=[id]&category=vital-signs&date=[date]{&date=[date]}

Example:Find all the blood pressures after 2015-01-14

Support: Mandatory to support search by category code and date

Implementation Notes: Search based on vital sign category code and date. This fetches a bundle of all Observation resources with category 'vital-signs' for the specified patient for a specified time period (how to search by reference) and (how to search by token).

Response Class:

• (Status 200): successful operation
• (Status 400): invalid parameter
• (Status 401/4xx): unauthorized request
• (Status 403): insufficient scope