10.1.14 Introduction

Vital signs is 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 profiles set the minimum expectations for the Observation resource to record, search and fetch the vital signs associated with a patient. These include the "primary" vital signs of heart rate, respiratory rate, blood pressure (systolic and diastolic) and body temperature, plus additional measurements such as body height, body weight, BMI and oxygen saturation. Support for basic mandatory searching of resources is defined below in the Quick Start section.

Instances of the Observation resource that contain de-identified data that is no longer associated with a specific patient or measurements coming directly from a device that have not yet been associated with a patient are not required to conform to the Vital Signs profiles.

10.1.15 Scope and Usage

10.1.15.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 in the table of profile formal views provide the details of the profile content, descriptions, mappings and the StructureDefinitions in JSON and XML.

1. a status
2. a 'category' code of 'vital-signs'
   • When needed, one or more additional category codes (from the preferred HL7 observation-category or a different code system) may also be included along with the 'vital-signs' category code.
3. an additional "interoperability standard" high level (methodless LOINC) code for what is being measured
   • The selected code for the actual measurement will often be different from (usually more specific than) the "interoperability standard" code. When that is the case, the selected code (from LOINC or a different code system) is expected to also be included in the 'code' element, as a repetition of 'code.coding', in addition to the "interoperability standard" code. Potentially other codes (from the same or different code systems) may also be included as appropriate (also as additional 'code.coding' repetitions).
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 available for a required observation or observation component, then you must supply a data absent reason

10.1.15.2 Vital Signs Profile Conformance

When a FHIR implementation supports any of the vital signs observations listed in the table below, the implementation SHALL conform to the Vital Signs Base profile and also the profile for the specific vital sign observation. The observation-vitalsign-measurement value set bound to Observation.code in the Vital Signs Base profile contains the set of code values for Observation instances which are expected to conform with the Vital Signs Base profile. Similarly, the corresponding observation-vitalsign-* value set bound to Observation.code in a specific Vital Signs Profile contains the set of code values for Observation instances which are expected to conform with that specific profile.

10.1.15.3 Support For Additional Terminologies

When the code value in an Observation instance is populated using a code system that is not included in the definition of the observation-vitalsign-measurement value set, any code that is considered to be semantically equivalent to one of the codes that is included in the value set should also be considered to require that the Observation instance conform to both the Vital Signs Base and the corresponding specific Vital Signs Profile.

10.1.16 Must Support Expectations for Vital Signs Profiles

When a Vital Signs profile element is marked as mustSupport, the minimum expectations are:

• Senders must populate the mustSupport element if the data is available and permissions allow.
• Receivers must be capable of consuming the mustSupport element if the element is relevant to their business case.

10.1.17 Formal View of Vital Signs Profile Content

• The Vital Signs Profiles are intended to be applied only to point-in-time observations as the "Interoperability Standard" codes selected only reflect point-in-time concepts.
  • Any calculated observations based on two or more point-in-time vital sign observations cannot be based on one of these Vital Signs profile and its components, thus one cannot add the point-in-time vital sign observation "Interoperability Standard" code in Observation.code. Separate profiles and appropriate LOINC codes representing such calculated vital sign related observations must be created.
  • While such profiles cannot be derived from the vital signs profile directly or indirectly, they may use the vital-signs observation category "vital-signs" to enable queries for all observations related to vital signs generally, i.e., use Observation.category = "vital-signs".
• The table below represents the set of vital sign concepts and the profiles that have been defined for representing them in the Observation resource, along with the associated required high level (methodless) LOINC "interoperability standard" codes, and the UCUM units of measure codes that are used for representing the vital signs observations. When a system supports any of these vital signs profiles, 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, in situations where it is appropriate and necessary, one of the components (usually not both) may have a dataAbsentReason instead of a value.
  • The first column of this table links to the formal views of the individual profile for each vital sign.
• Other profiles may make rules about which vital sign must be present, or must be present as part of a panel, or may expand the list to include additional vital sign observations.

Profile Name	"Interoperability Standard" Code (LOINC)	LOINC Name and Comments	UCUM Unit Code	Examples
Vital Signs Base	-	Vital signs base This is the base profile that all of the specific vital sign profiles derive from. The use of a base profile provides a common pattern and helps ensure consistent representation for all of the specific vital signs profiles (listed below).	-	-
Vital Signs Panel	85353-1	Vital signs, weight, height, head circumference, oxygen saturation and BMI panel This represents a panel of vital signs, e.g. those listed in this table. All members of the panel are optional and note that querying for the panel may miss individual results that are not part of the actual panel. In this panel, Observation.valueQuantity is not present - instead, it uses Observation.hasMember to reference individual vital signs observations (e.g. respiratory rate, heart rate, BP, etc.).	-	Vital Signs Panel Example
Respiratory Rate	9279-1	Respiratory Rate	/min	Respiratory Rate Example
Heart rate	8867-4	Heart rate To supplement this vital sign observation, 8887-2 - Heart rate device type MAY be included as an additional component observation.	/min	Heart Rate Example
Oxygen saturation	2708-6	Oxygen saturation in Arterial blood The 2708-6 code or the more specific 59408-5 Oxygen saturation in Arterial blood by Pulse oximetry code (or another appropriate code for arterial oxygen saturation) may be used in Observation.code to specify the actual measurement that was performed.	%
Body temperature	8310-5	Body temperature To supplement this vital sign observation, 8327-9 - Body temperature measurement site (oral, forehead, rectal, etc.) and 8326-1 -Type of body temperature device MAY be used as additional component observations.	Cel, [degF]	Body Temperature Example
Body height	8302-2	Body height The more specific code 8306-3 -Body height - lying (i.e., body length - typically used for infants) MAY also be used in Observation.code to specify the actual measurement that was performed.	cm, [in_i]	Body height Example
Head circumference	9843-4	Head Occipital-frontal circumference	cm, [in_i]	Head Circumference Example
Body weight	29463-7	Body weight The more specific code 8352-7 - Clothing worn during measure and 8361-8 - Body position with respect to gravity MAY be used as an additional Observation.component or as a linked Observation (e.g, using hasMember).	g, kg,[lb_av], [oz_av]	Body Weight Example
Body mass index	39156-5	Body mass index (BMI) [Ratio]	kg/m2	Body Mass Example
Blood pressure arterial systolic and diastolic	85354-9	Blood pressure panel with all children optional This is a multi-component observation. It has no value in Observation.value[x]. It contains the following required component observations for systolic and diastolic blood pressure: "Interoperability Standard" Component Code (LOINC) LOINC Name UCUM Unit Code 8480-6 Systolic arterial blood pressure mm[Hg] 8462-4 Diastolic arterial blood pressure mm[Hg] Normally both the systolic and diastolic blood pressure components are expected to be present, though in some less common circumstances a value for one of the blood pressure components (most likely the diastolic) could be absent (and only in very rare circumstances would values for both components be absent). If a value is not available for one of the required blood pressure components, then a dataAbsentReason for that component must be provided. To supplement this vital sign observation, 8478-0 - Mean blood pressure, 8357-6 - Blood pressure method, 41904-4 - Blood pressure measurement site, 8358-4 - Blood pressure device cuff size, 41901-0 - Type of blood pressure device MAY be used as additional component observations.	-	Blood Pressure Example, Blood Pressure Example with missing Diastolic measurement

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

Example: Search for all Vital Signs measurements 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.18.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,85354-9

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.18.3 GET [base]/Observation?patient=[id]&category=vital-signs&date=[date]{&date=[date]}

Example: Find all vital signs after 2015-01-14 for a patient

GET [base]/Observation?patient=555580&category=vital-signs&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