Vitals (Charts) Overview

Definition and Structure

Recording patient vitals is an important part of the patient's visit. There are several different ways that vitals are stored in athenanet:

  1. Entered as part of an encounter
  2. Manually entered in a patient's flowsheet(s)
  3. Manually entered via the 'Historical Pediatric Growth Data' section
  4. Manually entered via the 'Prenatal History' section
  5. As part of procedural vitals (which is used by very few practices).

This API allows reading of all types of vitals except for procedural vitals, as well as adding device-generated vitals to the patient's flowsheet. By default, these are hidden from the user, so contact us if you wish to add vitals this way. If you want to add vitals to an encounter, see the Encounter section.

In the API, vitals are structured in three heirarchy levels (from highest to lowest): Vitals, Vital Attributes, Readings.  Example of vitals are 'Blood Pressure' and 'Pulse'. Each vital contains a set of attributes. Each attribute identifies a sub-vital. For Blood Pressure for example, you have the Systolic BP, the Diastolic BP, as well as the BP type (sitting, standing, etc), the BP site (L arm, R wrist, etc).  Readings are the measurements and values, with each reading associated with a given vital attribute. Readings and attributes are linked via the clinicalelementid.

Getting Configured Vitals

Each practice selects the list of vitals that are used for that practice from a global list defined by athena. You can see and configure these in athenaNet by going to Settings => [Admin] Clinicals => [History/Intake] Vitals.

If the practice is a multi-specialty practice, then you will see a list for each specialty. For multi-specialty practices, the list of eligible vitals is determined by the specialty of the rendering provider in the encounter. If the practice is a single-specialty practice, then you will only see one list.

Via the API, you can get the list of configured vitals via:

Via the API, you can get the list of configured vitals via:

1. For single speciality practices:

2. For multi-speciality practices

 (use /chart/configuration/vitals?specialtyid={specialtyid})

3. To get the entire global athena list via:

(use GET /chart/configuration/vitals?showunconfigured=true)

This API returns a list of vitals. Each vital in turn contains a list of attributes and meta information about that attribute (data type, options, and default units). Note that the units given is not for display purposes. It is the units the readings are stored in athena and returned. For example, Weight is stored in grams.

Compared to the admin page in athenaNet, the API doesn't allow you to get or modify some of the additional configuration criteria. Some of these are only for display inside athenanet. Please inform us if some of the other configuration options are useful for your use cases.

See the API input and output fields here.

Getting Patient Vitals

You can get a patient's vitals via:

(use GET /chart/{patientid}/vitals?departmentid={departmentid})

This returns a list of vitals, and for each vital, a list of readings (in different sub sections).  The list of vitals and attributes reflect what's returned by the configuration, except that for a given patient, the list of vitals and attributes may span multiple specialties. By default, only the attributes for which there are readings for this patient are returned, but you can get the complete list via:

(use GET /chart/{patientid}/vitals?departmentid={departmentid}&showemptyvitals=true)

Each reading will also usually return the LOINC code associated with it (if available).  Readings are grouped and tied together by source, sourceid, clinicalelementid, and readingid. So if the patient's blood pressure was taken twice in a given encounter, the readingid will be different for those two measurements, but the systolic and disastolic values for each of the two measurements will have the same readingid.  Even though we are specifying a source of ENCOUNTER, all vitals except procedural vitals are returned. This will likely change in the future, and source will become an optional argument.

You can also specify a STARTDATE or ENDDATE to limit the vitals returned.

See the API input and output fields here.

Adding Device Generated Vitals

The vitals value in the POST API is a complex url-encoded JSON structure. It is an array of arrays. Each subarray contains a group of related readings. Example POST body:

departmentid=1
source=DEVICEGENERATED
vitals=(the following should be url encoded)
  [
    [
      {
        "clinicalelementid" : "VITALS.BLOODPRESSURE.SYSTOLIC",
        "readingtaken" : "01/01/2016", 
        "value": "160"
      },
      {
        "clinicalelementid" : "VITALS.BLOODPRESSURE.DIASTOLIC",
        "readingtaken" : "01/01/2016", 
        "value": "90"
      }
    ],
    [
      {
        "clinicalelementid" : "VITALS.BLOODPRESSURE.SYSTOLIC",
        "readingtaken" : "01/01/2016", 
        "value": "120"
      },
      {
        "clinicalelementid" : "VITALS.BLOODPRESSURE.DIASTOLIC",
        "readingtaken" : "01/01/2016", 
        "value": "70"
      }
    ],
    [
      {
        "clinicalelementid" : "VITALS.TEMPERATURE",
        "readingtaken" : "01/01/2016", 
        "value": "98.6"
      }
    ]
  ]

The readingtaken field is optional, and will default to today. NOTE that there is a restriction where all of the vitals you add in a given call MUST have the same readingtaken date (or are all null/today).

See the API input and output fields here.

Updating Vitals

The list of readings returned by the GET contains a 'vitalid' value. This uniquely identifies that particular reading. You can use the vitalid to update the value of that particular reading. You can only update values that you added previously.

See the API input and output fields here.

Was this information helpful? Yes | No Thank you for your feedback! What went wrong? Incomplete or incorrect information | Irrelevant Content | Others
Submit