Stream: argonaut
Topic: Vital signs
Josh Mandel (Jun 28 2019 at 22:35):
On my reading, this example
"coding": [
{
"system": "http://loinc.org",
"code": "8310-5",
"display": "Body temperature"
},
{
"system": "http://loinc.org",
"code": "8716-3",
"display": "Vital signs"
}
]
},
doesn't quite line up with the argonaut spec since 8716-3 isn't being used as a panel. Is my assessment correct? Is there a way to bring this to the attention of the right team @Isaac Vetter?
Pascal Pfiffner (Jul 02 2019 at 18:55):
Pointing out that we do see this scenario A LOT. Now I know where it's coming from. :grinning:
Rob Hausam (Jul 04 2019 at 15:49):
Yes, your assessment is correct. This isn't a correct use of Coding repetitions in a CodeableConcept - if multiple Codings are present, each of them is expected to represent essentially the same meaning (allowing for potential differences in granularity in different code systems). In this case, the code system is LOINC in both cases and the meanings are completely different, and only 8310-5 "Body temperature" corresponds to the actual meaning of the observation, so there's no justification for also including the 8716-3 "Vital signs" panel code here.
Lloyd McKenzie (Jul 04 2019 at 16:00):
It is permitted to send codes with higher or lower granularity as translations. The problem here is that the code is actually wrong for the Observation. The observation isn't a vital signs panel, so it's wrong to call it one. If LOINC had a code that said "vital signs measurement", then that would actually be a legitimate translation. (Not that LOINC would ever create a code that abstract... :>)
Rob Hausam (Jul 04 2019 at 16:05):
Yes, that's right.
Douglas DeShazo (Jul 30 2020 at 15:23):
Question around BMI as vital sign or lab. The LOINC code for BMI in US Core > Vital Signs profile is 39156-5 and thus would be represented with the appropriate fixed values for category and code. Changing the category from VSCat to Laboratory would make this non conformant. Is that a correct assumption?
Jay Lyle (Nov 20 2020 at 19:06):
That sounds correct.
Jay Lyle (Nov 20 2020 at 19:07):
We have a vitals module, but they are not grouped in panels. So to expose them in US Core, we expect to use the individual vitals observation profiles without having to group them in panels. Is that right? I suppose we could infer panels based on date & time, and it would be fine. Usually.
Also, our vitals module records several observations not in the Core profile. If we were using the panel, they'd be excluded by the closed slicing. So even though we're not, we'll still exclude them. Right, @Eric Haas ?
Eric Haas (Nov 20 2020 at 19:20):
no panel defined in US Core but in base FHIR. What closed slicing?
Jay Lyle (Nov 23 2020 at 16:44):
That is weird. I know the page I was looking at said closed, because I tried to look up what it meant for conformance. OK, so we can return all our "vitals" in the vitals profile.
But the first question: are we expected to wrap them in a panel?
Brett Marquard (Nov 23 2020 at 17:11):
no, wrapping in a panel is not a requirement...
Last updated: Apr 12 2022 at 19:14 UTC
