10.1.17 10.1.14 Introduction

Vital signs will be 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 profile sets profiles set the minimum expectations for the Observation resource to record, search and fetch the vital signs associated with a patient that patient. These include the primary "primary" vital signs of heart rate, respiratory rate, blood pressure (systolic and diastolic) and body temperature, plus additional measurements such as body height, weight body weight, BMI and BMI. oxygen saturation. 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 observations listed in the table below, the implementation SHALL conform to this 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. 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 Observation instance to conform to both the Vital Signs Base and the corresponding specific Vital Signs Profile.

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.

[Note: These requirements profiles have been updated and were originally derived from and based on the minimum mandatory conformance requirements for accessing patient data as defined by the Argonaut pilot implementations that were developed, balloted, and published in the U.S. Data Access Framework (DAF) FHIR Implementation Guide (IG) 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 project.] pilot implementations.

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

Each The Vital Signs Base profile requires that each Observation must have:

1. a status
2. a category 'category' code of 'vital-signs'
• When needed, one or more additional category codes (from the preferred HL7 observation-category or a "magic value" which tells you 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
   • LOINC was chosen The selected code for the "magic values" because this aligns with actual measurement will often be different from (usually more specific than) the most countries, but it can "interoperability standard" code. When that is the case, the selected code (from LOINC or a different code system) is expected to also be treated included in the 'code' element, as simply a fixed core set repetition of common codes to communicate basic vital signs. Implementers that need 'code.coding', in addition to use a the "interoperability standard" code. Potentially other codes (from the same or different code system can still map accordingly. 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 then you have to supply a reason

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.19 10.1.17 Formal View of Specific Vital Signs Profile Content

• The Vital Signs Profile : Link Profiles are intended to be applied only to point-in-time observations as the formal definition views for "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 these Vital Signs profile and its components, thus one cannot add the point-in-time vital signs listed sign observation "Interoperability Standard" code in this table. 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 a minimum the set of vital sign concepts, concepts and the profiles that have been defined for representing them in the Observation resource, along with the associated required codes ("magic values"), high level (methodless) LOINC "interoperability standard" codes, and the UCUM units of measure codes that are used for representing the vital signs observations. These terminology bindings are extensible bindings and require that when a system supports 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.
• The first column of this table links to the formal views of the individual profile for each vital sign.
• If a more specific code or another code system is recorded or required, implementers must support both the values (LOINC) listed below and the translated code - e.g. method specific LOINC codes, SNOMED CT concepts, system specific (local) codes. In addition the implementer may choose to provide alternate codes in addition to the standard codes defined here. The examples illustrate using other codes as translations. Other profiles may make rules about which vital sign must be present present, or must be present as part of a panel panel, or may expand the list to include other vital signs. For implementers using LOINC, optional qualifier codes are provided in the notes below.

Oxygen Saturation Example

Profile Name	"Magic Value" "Interoperability Standard" Code (LOINC)	LOINC Name and Comments	UCUM Unit Code	Examples
Vital Signs Panel	85353-1	Vital signs, weight, height, head circumference, oxygen saturation and BMI panel - It represent This represents a panel of vital signs 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. When used, In this panel, Observation.valueQuantity is not present; present - instead, related links (with type=has-member) it uses Observation.hasMember to reference the individual vital signs observations (e.g. respiratory rate, heart rate, BP, etc.). This code replaces the deprecated code 8716-3 - Vital signs which is used in the Argonaut Data Query Implementation Guide.	-	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 - This The 2708-6 code replaces or the more specific 59408-5 Oxygen saturation in Arterial blood by Pulse oximetry which MAY code (or another appropriate code for arterial oxygen saturation) may be included as an additional observation code. 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 - To supplement this vital sign observation, The more specific code 8306-3 - Body height - lying (i.e., body length - typically used for infants) MAY also be included as an additional observation code. 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 - To supplement this vital sign observation, The more specific code 8352-7 - Clothing worn during measure and 8361-8 - Body position with respect to gravity MAY be included used as an additional observation codes. Observation.component or as a linked Observation (e.g, using hasMember).	g, kg,[lb_av] 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 component observation. It has no value in Observation.valueQuantity Observation.value[x] and contains at least one component (systolic and/or diastolic). 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
Systolic arterial blood pressure	8480-6	Systolic arterial blood pressure - Observation.component code for a blood pressure Observation	mm[Hg]	Blood Pressure Example
Diastolic arterial blood pressure	8462-4	Diastolic arterial blood pressure - Observation.component code for a blood pressure Observation	mm[Hg]	Blood Pressure Example

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

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

GET [base]/Observation?patient=555580&code=85354-9&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