10.1.15 Introduction

The FHIR Vitals Signs profile sets a minimum expectations for the Observation Resource to record, search and fetch the vital signs associated with a patient that include the primary vitals signs plus additional measurements such as height weigth and BMI. When a FHIR implementation supports any of the vital signs listed below, the implementation SHALL conform to this profile for the vitals sign observation.

This profile identifies the required core elements and values. Support for basic mandatory searching of resources are defined below in the Quick Start section. It is based on the Argonaut DSTU2 Vital Signs Profile .

10.1.16 Scope and Usage

Example Usage Scenarios:

The following are example usage scenarios for the US VitalSigns profile:

• Query for vital signs of a particular patient

10.1.16.0.0.1 Mandatory Data Elements and Terminology

The following data-elements are mandatory (i.e data MUST be present). These are presented below in a simple human-readable explanation. Profile specific guidance and an example are provided as well. 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 LOINC code which tells you what is being measured and is taken from the LOINC Code column in the table below.
   • note: If a more specific code is recorded, the generic code and the translated coded must be sent - e.g. method specific LOINC Codes, SNOMED CT concepts, system specific (local) codes
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 LOINC Code column in the table below.
   • note: if there is no numeric result then you have to supply a reason

Profile specific implementation guidance:

• This table represents a minimum set of vital sign concepts , the required LOINC codes, and UCUM units of measure codes used for representing vitals signs observations. These are extensible bindings and require that when a system supports of any of these vital signs concepts, they must represent them using these codes. In addition, if you have a blood pressure observation, you must have both a systolic and a diastolic component, though one or both may have dataAbsentReason instead of a value.
• Alternate codes may be provided in addition to the standard LOINC and UCUM codes defined here. The examples illustrate using other codes as translations.
• Other profiles may make rules about which vital sign must be present or must be present as part of a panel or expand the list to include other vital sign.

Vital Sign Name	LOINC Code	UCUM Unit Code	Notes	Examples
Vital Signs Panel	8716-3	-	This is the top-level grouping structure for a set of vital signs. It has no value in Observation.valueQuantity ; instead, it just includes related links (with type=has-member) to the Observations in this set (e.g. respiratory rate, heart rate, BP). Note that querying for the panel may miss individual results that are not part of an actual panel.	Vital Signs Panel Example
Respiratory Rate	9279-1	/min		Vital Signs Respiratory Rate Example
Heart rate	8867-4	/min		Vital Signs Heart Rate Example
Oxygen saturation	59408-5	%	59408-5 (Oxygen saturation in Arterial blood by Pulse oximetry) replaces the deprecated code 2710-2 which had been listed in C-CDA.	Vital Signs Oxygen Saturation Example
Body temperature	8310-5	Cel, [degF]		Vital Signs Body Temperature Example
Body height	8302-2	cm, [in_i]		Vital Signs Body height Example
Body length	8306-3	cm, [in_i]	Like height, but lying down, typically this is used for infants	Vital Signs Body Length Example
Head circumference	8287-5	cm, [in_i]		Vital Signs Head Cirmcumference Example
Body weight	29463-7	g, kg,[lb_av]		Vital Signs Body Weight Example
Body mass index	39156-5	kg/m2		Vital Body Mass Example
Blood pressure systolic and diastolic	55284-4		This is a grouping structure. It has no value in Observation.valueQuantity but contains at least one component (systolic and/or diastolic).	Vital Signs Blood Pressure Example, Vital Signs Blood Pressure Example with missing Diastolic measurement
Systolic blood pressure	8480-6	mm[Hg]	Observation.component code for a blood pressure Observation	Vital Signs Blood Pressure Example
Diastolic blood pressure	8462-4	mm[Hg]	Observation.component code for a blood pressure Observation	Vital Signs Blood Pressure Example
Mean blood pressure	8478-0	mm[Hg]	The mean blood pressure is most commonly a direct average taken off of an instrument.	Vital Signs Mean Blood Pressure Example

10.1.17 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 below 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 below 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 below 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 below 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.17.0.1 GET [base]/Observation?patient=[id]&category=vital-signs

Example: Search for all Vitals Signs measuirements for a patient

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

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.17.0.2 GET [base]/Observation?patient=[id]&code=[vital sign LOINC{,LOINC2,LOINC3,...}]

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

GET [base]/Observation?patient=1186747&code=8867-4

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

GET [base]/Observation?patient=1186747&code=8867-4,9279-1,55284-4

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 Argonaut Observation "code" parameter has been defined to search both in both Observation.code and Observation.component.code. For example when fetching blood pressures the same resources will be returned whether the search is based on 55284-4(Systolic and Diastolic BP), or the component codes 8480-6(Systolic BP) or 8462-4 (Diastolic BP).

Response Class:

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

---

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

Example: Find all the blood pressures after 2013-03-14

GET [base]/Observation?patient=555580&code=55284-4&date=ge2015-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