Reference Vital Sign ranges


Hi @akanter, I would like to ask your advice on how we should proceed with setting Vital Sign ranges for the O3 RefApp.

Currently, we are using CIEL concepts for the vital signs in O3 (SBP/DBP, Pulse, SpO2, RR, etc).

However, these CIEL concepts don’t have complete ranges. We’d like folks to easily see that visual alerts are triggered if concerning vitals are recorded, but this is not triggering right now because I cannot set the ranges on CIEL concepts. Since some implementations will likely copy our distro, I would also very much like our config to be a wise starter-kit - and that includes the Vitals ranges.

How do you recommend we proceed? Should we:

A) Manually copy/re-create the CIEL concepts for Vitals, so we can customize the ranges ourselves? (Obvs we would map to the original CIEL concept)

B) Wait for range changes in the CIEL concepts themselves? (Assuming CIEL is willing to appoint sample regerence ranges to existing Vitals concepts, and assuming this would not create breaking issues for other implementations)

Once again, this is a great example of the need for Curated Concept Customization :wink: (CC @jamlung & @paynejd)

Totally agree that these customizations would be non-breaking changes. I just had a conversation with EthiOHRI about cloning as I had thought that the OpenMRS Dictionary Manager actually allowed customization of cloned concepts. However, they said that cloning is not working.

In this case, I think that I could add ranges if it makes the RefApp work. Alternatively, one could copy the CIEL concepts with SAME-AS maps to CIEL as you suggest. We need a way as @burke has described to relink historical SAME-AS maps in his life of a concept planning.

As long as the reference ranges are not absolute, I think it probably would be OK to add them. I am working on a release now (Mpox from Monkeypox and others) so let me know ASAP.

Andy and I slacked about this but for benefit of public record, here are the ranges I propose: Vital Sign Ranges: Proposal for CIEL - Google Sheets

Just consulting some reference resources and other physicians to ensure these are reasonable ranges.

@grace, the vitals ranges look reasonable to me. :+1:

I’d suggest adding absolute ranges. As long as we’re defining ranges, let’s not ignore absolute ranges. My suggestions would be 0-400 for pressures, 0-500 for pulse, abs low of 0 for resp, 0-100 for SpO2, and 0-50 for temp) to help prevent nonsensical data. An absolute max resp rate is probably not worth setting, since there can be exceptional cases (like high frequency ventilation of neonates) where resp rate can be in the 100s.

FYI - the phrases like “12 and below” in your spreadsheet are misleading, since low & high define inclusive ranges. For example, a “Normal Low” of 12 for resp rate means 12 is normal. Any value below 12 (down to & including the critical low value of 10) would be abnormal and values below (but not including 10) would be critical.

Hi @akanter, thanks so much for adding these reference ranges in last year :smiley: I have an update request from a physician funder/supporter, who’s asking if we can make these changes:

  • "HR normal low should start at 59, not 60.
  • Temp normal low should be 35.5, and temp critical low should be 34.5"

Both of these make sense to me, especially the HR adjustment; I realize now I’d be annoyed if the EMR was alerting me for a “normal low” of 60. Do they sound clinically prudent to you?

I also like @burke’s suggestion of the Absolute Ranges, although I suggest 60C for Temp high because highest recorded temp has been >46 C; may as well round to a high but not blocking number (I’m reminded of cases where we’ve had to change our absolute highs because of remarkable clinical cases, like extreme reported age). Same logic for Pulse at 600; since one article states highest tachy on record was 480. May as well round high enough so not to be prohibitive.

I’ve added these suggestions to the spreadsheet.

Minor changes really. Shown in bold:

Could these make it into the next CIEL version? And when do you think that could be?

The normal range is from low_normal to hi_normal, inclusive, so a pulse of 60 would be normal with low_normal of 60. Your spreadsheet is misleading, because, for example, a phrase like “60 and below” describes what is outside of normal instead of the lowest value of the normal range (i.e., low_normal).

So how does the app respond? If normal low is 60, then 60 should not throw an alert. I will not make any changes until I get a firm recommendation… I am working on the ANC DAK maps but could put out a new release this weekend if Burke is up for it.

Values should be displayed this way. If they aren’t, I’d consider it a bug to be fixed in the UI:

Range Display
low_normal ≤ x ≤ hi_normal Normal
low_critical ≤ x < low_normal or
hi_normal < x ≤ hi_critical
low_absolute ≤ x < low_critical or
hi_critical < x ≤ hi_absolute
x < low_absolute or
x > hi_absolute

So, with low_normal set to 60, a pulse of 60 would display as normal.

1 Like

Given this, what (if any) are recommended changes to the ranges in CIEL?

I would use the values from Grace, but use 60 as the low normal for pulse. A pulse of 59 shouldn’t show as normal.

1 Like

@akanter I see the Max possible value for Temp (c) in CIEL currently is 43 degrees. I know that’s ridiculously hot already but can I suggest putting a max of 47, or 50? According to Google etc the highest known recorded value was 46.

I have 2 reasons for this, despite yes, this being a wildly high temp:

  1. Equipment in LMICs can give odd readings; I don’t know that we want to completely block folks from entering the values a machine is telling them because that will make them very frustrated with the system, meaning they won’t add the value, and we’d even miss the chance to show “Critical High”
  2. We both know that wild cases can be seen in LMIC settings that often don’t reach the same severity in HICs - e.g. I have seen SpO2 readings in the 70%'s on women with extreme cooking-fire-induced COPD, walking around, discharged not on oxygen. Stranger things have happened, is all I’m saying.

Is the concern that we’re trying to prevent a situation where someone accidentally uses a “4” instead of a “3” and enters “46” when they mean “36”?

p.s. - Also, any concerns with changing the unit from “DEG C” to just “C”? It looks weird when it auto-populates our VS tables in the clinician UI:

@ball any concerns with this just being (C)?

C (Celsius/Centigrade) is great for all the places that PIH works.

We do allow capture in C or F (and convert) for Haiti and maybe other countries because we get donations of vital sign devices that capture temperature in non-metric units. I don’t know if this still continues but it did when we built the RefApp2. I can check with our site colleagues if this is a requirement.

1 Like

Wow I’m not surprised by that medical device situation but we don’t handle that well in o3 refapp yet. Yes, a sense of how common it is that folks have to toggle the units would be nice to know.

From the PIH Biomedical Equipment Specialist about Haiti, Lesotho, Liberia, Malawi, Mexico, and Sierra Leone. Similar feedback from a colleague in Sierra Leone:

I would say that it would most likely be beneficial to keep both options [metric + imperial] available in our EMR because of the vast array of different brands and models of vital signs and patient monitors we have across our various sites, unless it has become very cumbersome or confusing to do so.

Our current formulary recommendation for Patient Monitors and Vital Signs Machines are from Edan Diagnostics, but we have many different manufacturers currently in use including GE, Philips, Welch Allyn, Mindray, etc. across our various sites globally.

I do believe most of this equipment can be set to either imperial or metric, so it should be possible to standardize (to the obvious choice of metric), but I would think having the most options available would be the safest option considering the possibility for future expansion.

1 Like

Very helpful. Wow what an array of equipment manufacturers. Thanks so much Ellen.