Stream: argonaut
Topic: Vitals Category
Jenni Syed (Nov 16 2018 at 08:43):
We had a question come up around the argonaut Observation.category that is allowed for vitals (likely applies to the other Observation profiles as well). If I remember, the intent of the category restriction was similar to the intent of the code restriction: you must have at least one coding in the list that matches the pattern/value, but should be able to put more than one category. With the way the profile is described today, I can't tell what technical restriction would come into play: http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-vitalsigns-definitions.html#Observation:argoprofile.category
Jenni Syed (Nov 16 2018 at 08:44):
I recall there being a lot of questions around how to get the structureDefinition to match the functional intent. However, I don't know what the "required pattern" means (nor do I recall why that was chosen instead of a binding).
Jenni Syed (Nov 16 2018 at 08:48):
The core vitals profile that went out in STU3, and that we tried to keep in line with as they were both developing, has the category binding set to preferred and the invariant defined as an exists check. This seems more clear that it is allowed to have more than one value in the category.
http://hl7.org/fhir/stu3/vitalsigns-definitions.html#vitalsigns.Observation.category
Jenni Syed (Nov 16 2018 at 08:49):
STU3 does also allow more than one codeableConcept, which came out of the clarification around when you should put multiple codings in a list vs. multiple codeable concepts (all of the "granularity" and translation vs. completely different concept discussions)
Jenni Syed (Nov 16 2018 at 08:50):
So: What was the intent of the restriction? What is the current technical implementation of it?
Jenni Syed (Nov 21 2018 at 15:56):
@Eric Haas ?
Brian Reinhold (Nov 21 2018 at 16:06):
@Eric Haas ?
Not Eric but I am not sure I understand the dilemma. In the profile I am developing I had to deal with including the vital signs category when the measurement was a vital signs even though I did not want to (required by the base standard). In my case I do not use the category at all but if I did and had an additional category, I would include 2 category elements (since it is 0..*), one for the one I wanted and one for the vital signs. Now in each case, I could represent each category code in an additional code system if such a code system exists. On the other hand, these additional codes are to represent the same concept as the 'primary' code.
Does that make sense? I don't know if it answers your question but it seems it might. Of course I am talking version 3.6.0. As I recall the category was only 0..1 in early versions.
Jenni Syed (Nov 21 2018 at 16:59):
Right, and I think STU3's invariant is written in a way that makes that more clear (it's an exists check but the Argonaut guide is a match instead of exists)
Jenni Syed (Nov 21 2018 at 17:00):
@Grahame Grieve may also be able to help with the technical interpretation side/how the existing argonaut profile on DSTU2 would be expected to be enforced. I'm worried it's not in line with the original intent...
Eric Haas (Nov 21 2018 at 19:51):
Will check into it when get chance
Jenni Syed (Dec 05 2018 at 15:18):
@Eric Haas have you had a chance to check this out? I know it's that time of year when everyone gets busy or (gasp) takes time off :)
Brett Marquard (Dec 05 2018 at 15:46):
with this being 1..1, I don't see how required vs the pattern would have been any different..
Eric Haas (Dec 05 2018 at 18:17):
I have not looked at it closely...yet
Jenni Syed (Dec 05 2018 at 20:08):
the codeableConcept allows multiple codings
Jenni Syed (Dec 05 2018 at 20:09):
There were a lot of parallel discussions at the time about what that means (multiple codings in the list vs multiple category.codeableConcept), which is what resulted in Observations moving that to a 0..* under the covers
Jenni Syed (Dec 05 2018 at 20:09):
For STU 3
Jenni Syed (Dec 05 2018 at 20:10):
That were all about specificity of the codes
Jenni Syed (Jan 07 2019 at 18:47):
@Eric Haas @Grahame Grieve any thoughts? Is that pattern restriction enforced as "just in the list" or "only 1 in the list that must match" for argonaut: http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-vitalsigns-definitions.html#Observation:argoprofile.category (I'm assuming the "just one in the list" based on the way it displays, but I haven't seen the restriction written like this before)
Jenni Syed (Jan 07 2019 at 18:48):
And finally: what was the intent - I thought it was to allow for multiple (like the vitals core)... but I know all the granularity clarifications happened around the same time (CodeableConcept 0..* vs CodeableConcept.coding 0..*)
Grahame Grieve (Jan 08 2019 at 19:17):
just one in the list
Grahame Grieve (Jan 08 2019 at 19:17):
not sure about the other quetsion
Jenni Syed (Jan 28 2019 at 18:22):
@Grahame Grieve Vitals core actually only allows one category per vital type... so, for example, it also does not allow for you to say this is a category of "vital-sign" and "height"
Jenni Syed (Jan 28 2019 at 18:22):
Even if US-Core does allow multiple... Not sure why we haven't noticed that before...
Jenni Syed (Jan 28 2019 at 18:23):
or "vital sign" and "child-well-care"
Jenni Syed (Jan 28 2019 at 18:26):
http://hl7.org/fhir/r4/bodyheight.html
Eric Haas (Jan 28 2019 at 18:36):
I'm not sure of your question. after DSTU2 Observation category went from 0..1 to 0..* and the Vitals Profile reflects that. So you can have a category of "vital-sign" and "height". ( at least that was the intent) and it validates this way too
Jenni Syed (Jan 28 2019 at 18:37):
it's the international profile on observations that locks it down to 1..1 for core
Jenni Syed (Jan 28 2019 at 18:37):
at least, based on the profiles I'm seeing
Jenni Syed (Jan 28 2019 at 18:38):
or how I'm reading it. I would love to know that I'm wrong :)
Eric Haas (Jan 28 2019 at 18:38):
is has a 1..1 slice for category code = vital-sign with a Slice: Unordered, Open by value:coding.code, value:coding.system which means you can add other categories
Eric Haas (Jan 28 2019 at 18:39):
Which profile are you looking at? IPS or in the base spec?
Jenni Syed (Jan 28 2019 at 18:39):
eg: http://hl7.org/fhir/r4/bodyheight.html snapshot
Eric Haas (Jan 28 2019 at 18:39):
http://build.fhir.org/bodyheight.html is.
pasted image
Jenni Syed (Jan 28 2019 at 18:40):
it shows the slice, but also 1..1 on category
Eric Haas (Jan 28 2019 at 18:41):
This is how I wrote and read the slice. "you need to have at least the category of vital-sign but other categories are OK too. If I'm wrong please correct me.
Eric Haas (Jan 28 2019 at 18:42):
the 1..1 is on that slice as opposed to 0..1
Eric Haas (Jan 28 2019 at 18:46):
let me look at the structuredefinition more closely just in case. I remember now that I had to use the profiling spreadsheet here and struggled with getting the slicing to do what I wanted because of that.
Eric Haas (Jan 28 2019 at 18:49):
<element id="Observation.category">
<path value="Observation.category"/>
...
<min value="1"/>
<max value="*"/>
Eric Haas (Jan 28 2019 at 18:51):
looks OK to me. the tree structure doesn't display the "1..*" is that throwing you off? I'll make a tracker ( if there isn't one already)
Eric Haas (Jan 28 2019 at 19:03):
Jenni Syed (Jan 29 2019 at 16:18):
Yes, it was how that should be interpreted b/c the slice shows category by itself, then the other "category" says 1..1. If it allows multiple, then that's where we were confused
Pascal Pfiffner (Feb 07 2019 at 18:26):
Just caught up to this. So we're saying you must have vital-sign but you can have other categories? This makes things hard for clients, e.g. when a second category is laboratory, what do we do, is this now a lab or a vital? We'd have to implement our own logic looking at the actual Observation.code, meaning ignoring the provided category. Is there opposition to saying "category is 1..1", period?
Josh Mandel (Feb 07 2019 at 18:42):
After reviewing discussion here, I'm pretty confused. It looks like the functional intent was "require a vital-sign category and allow others too". Are you saying you disagree with this intent @Pascal Pfiffner ?
Josh Mandel (Feb 07 2019 at 18:43):
(Re: generic client behavior, you do have options without resorting to looking at the Observation.code values -- e.g., you could define a precedence hierarchy of categories to trigger from, or you could surface individual Observations in multiple parts of your UI -- e.g., on two screens if two categories are present.
I'm not saying this is a good idea, but just questioning the "we'd have to implement our own logic" assertion.)
Pascal Pfiffner (Feb 07 2019 at 19:15):
I'm saying allowing more than 1 category makes things harder for clients, especially in the vitals vs. lab results categories. A category precedence would be easier than code-level lookups, yes; I'm not saying we can't work with it, I'm just wondering about the need for it since the preferred codes in http://terminology.hl7.org/CodeSystem/observation-category seem to be exclusive. Ideally it would be "only one category of system http://terminology.hl7.org/CodeSystem/observation-category and whatever else you want to put there", but I don't think that's what the profile mandates, right?
Lloyd McKenzie (Feb 07 2019 at 19:23):
There are lots of reasons for multiple categories. You might need finer-grained categorization (so chemistry, microbiology, etc. for lab). You might also have a distinct axes such as "genetic" or "maternity". There should only be a problem with multiple categories if the categories you care about have overlap. In the vitals and labs space, that's not super-likely, though perhaps pulse-ox could be determined by lab? If that were to happen, having both categories would be appropriate as you'd want to see the observation in both categories.
Pascal Pfiffner (Feb 07 2019 at 19:25):
I do totally agree with that, but am questioning the need of having multiple categories of the preferred ones in http://terminology.hl7.org/CodeSystem/observation-category.
Eric Haas (Feb 07 2019 at 19:31):
I am confused @Pascal Pfiffner I don't think you are saying only one category
do you mean you want to limit the category from http://terminology.hl7.org/CodeSystem/observation-category to only vitals
and not have the option as LLoyd stated of a second from http://terminology.hl7.org/CodeSystem/observation-category?
Also I think @Lloyd is incorrect in stating that finer-grained labs should be separate category - they should be an additional coding on laboratory.
Lloyd McKenzie (Feb 07 2019 at 19:33):
Whether they're an additional coding on laboratory depends on the nature of the "finer grain". If it's known that they're always specializations of lab, then sure. But that might not be true of all categorizations.
Lloyd McKenzie (Feb 07 2019 at 19:33):
In looking at the preferred value set, it's not clear that all of the codes are guaranteed to be mutually exclusive. For example, something could be both a survey and part of social-history.
Eric Haas (Feb 07 2019 at 19:34):
I agree with you there spO2 can be a lab and a vital
Pascal Pfiffner (Feb 07 2019 at 19:36):
My preference would be to only have one of http://terminology.hl7.org/CodeSystem/observation-category and allow additional categories of whatever system. Agree with Lloyd that they are not 100% mutually exclusive but it would be good to force data producers to pick since it should be easy to pick most of the time.
Eric Haas (Feb 07 2019 at 19:37):
SpO2 can be both and that will lead to more endless debate if we try to constrain. I think it always is vital and sometimes belongs in both depending how is captured.
Pascal Pfiffner (Feb 07 2019 at 19:38):
Agreed
Pascal Pfiffner (Feb 07 2019 at 19:38):
Worse, it could be either depending on source.
Lloyd McKenzie (Feb 07 2019 at 19:38):
I'm not understanding the problem for an Observation to be categorized under multiple labels.
Pascal Pfiffner (Feb 07 2019 at 19:38):
So, for us, the best solution for consistency is actually to look at code to decide what goes into vitals and just ignore category. Which is a bit sad.
Lloyd McKenzie (Feb 07 2019 at 19:39):
If I query for most recent vitals, I'm going to want the SpO2 even if it was done by a lab.
Lloyd McKenzie (Feb 07 2019 at 19:39):
And if I query for labs, I'm going to want to see the SpO2 there too
Lloyd McKenzie (Feb 07 2019 at 19:39):
The client has the identifier for the Observation, so if they see the same thing coming back in more than one query, they can know it's the same instance.
Lloyd McKenzie (Feb 07 2019 at 19:39):
What's the downside?
Eric Haas (Feb 07 2019 at 19:40):
O2 sa tvitals profile
2708-6 Oxygen saturation in Arterial blood - This code replaces 59408-5 Oxygen saturation in Arterial blood by Pulse oximetry which MAY be included as an additional observation code.
Eric Haas (Feb 07 2019 at 19:40):
so I interpret (as the author) as always a vital sometimes a lab
Pascal Pfiffner (Feb 07 2019 at 19:41):
Lloyd, the downside for us is inconsistency. It could come back under either category depending on source, so to present them consistently for our users (and only in one category) we'd just ignore category. If the limit was 1 and, similar to Argo v1, we'd define what is a vital sign, then consistency could come from the profile.
Eric Haas (Feb 07 2019 at 19:43):
so its easier for a client to maintain a code list for each categorythan have the data producer decide?
Pascal Pfiffner (Feb 07 2019 at 19:43):
Maybe not easier, but better for consistency.
Eric Haas (Feb 07 2019 at 19:43):
I've done that and it aint' easy
Pascal Pfiffner (Feb 07 2019 at 19:43):
(Not that it's hard... :) )
Pascal Pfiffner (Feb 07 2019 at 19:43):
Well, the list for vitals is pretty short. Yes, you need to collect the sub-codes, but it's not thousands of codes.
Lloyd McKenzie (Feb 07 2019 at 19:47):
Consistency is a concern independent of multiple vs. 1. One source could choose lab and one could choose vital. Allowing multiple at least avoids arbitrary choices - if someone thinks it might correspond to both, it'll appear in both. In general it's better to have data in all potentially appropriate places rather than having it only appear in one (and not the one the user was necessarily hoping for/expecting).
Eric Haas (Feb 07 2019 at 19:47):
Actually if everyone adheres to the vitals profile you just have to look for twelve or so codes... We sort of baked in category there too.
Eric Haas (Feb 07 2019 at 19:48):
so I see your point...
Elliot Silver (Feb 07 2019 at 19:58):
the downside for us is inconsistency. It could come back under either category depending on source
Wouldn't it always come back as a vital, and may come back as lab too, rather than coming back as either vital or lab?
Pascal Pfiffner (Feb 07 2019 at 20:28):
If it's on the list of vitals it's likely to come back as vital or vital & lab, yes, but Observations outside of the official vitals list could come back as vital, as lab, or as lab & vital.
Lloyd McKenzie (Feb 07 2019 at 20:33):
And of those options, why would coming back as both be problematic? Wouldn't that be the easiest for the users to manage?
Pascal Pfiffner (Feb 07 2019 at 20:40):
For non-medical users it's not clear why something could be both in labs and in vitals. And that's only if everybody sent them back as both, which will not be the case.
Lloyd McKenzie (Feb 07 2019 at 20:49):
It won't be the case that everyone sets categories consistently period. That's certainly an issue, but it's not driven by the cardinality of category. For non-medical users, they'll see their O2 saturation when they look at vitals and they'll see a bunch of lab results when they look at labs. Most of them won't even recognize it's the same measurement. If you find that it's a common question, then it might be a reasonable thing to add to a FAQ (along with the fact that inconsistency can happen). However, I don't see limiting things to only one place (which might still be inconsistent) just to avoid a user asking a question is worth it.
Pascal Pfiffner (Feb 07 2019 at 21:02):
I don't disagree with the technical premises. Since we have a strong opinion on consistency and clarity however, we will end up ignoring category in at least some cases. I'd prefer to point to a profile and say "these 12 things are vitals and you put them into the vital-signs category of http://terminology.hl7.org/CodeSystem/observation-category" (and whatever additional system you want), and you use laboratory for all the labs, even if you think it's a vital. In such a scenario a cardinality restriction would at least make the vitals/labs separation clearer (but isn't a silver bullet, agreed).
Pascal Pfiffner (Feb 07 2019 at 21:03):
And since I don't assume what I just mentioned is workable for everybody, ¯\_(ツ)_/¯, I guess it stays where it's at.
Rob Hausam (Feb 07 2019 at 23:50):
Category has always been problematic - there are different needs/uses/desires for it which aren't all compatible. Given that, the least bad solution that we've been arriving at seems generally to be to allow multiple categories to be assigned where and when needed, depending on the particular requirements that are in mind. If you really want to know exactly what is going on then I think you do have to look at and rely on the code itself (plus whatever additional context may be necessary if the code alone isn't sufficient for your purpose), and in that case not rely on and possibly just ignore the category value(s).
Robert McClure (Feb 14 2019 at 19:17):
Chiming in here as both a doc and terminologist. Using O2 Sat as the use case, it is a lab value that is commonly grouped in with vital signs. If vitals and lab are both "categories" then if someone designs a system that hides this result in either lab section or the vitals section because it doesn't understand/support the truth of what I just said, they are potentially liable for mistakes in care that result. I really doesn't matter if you disagree with me, it just matters that you are putting patients, and the companies that choose to work with such a system at risk. I think the "consistency" argument is misleading you, be consistent and put the data in all the places it has a category for. How is that "not consistent"?
Last updated: Apr 12 2022 at 19:14 UTC
