Stream: implementers
Topic: Observation.category required if vital sign?
Brian Reinhold (Sep 07 2017 at 08:52):
There has been a requirement added into FHIR that LOINC is required in at least one coding element if the measurement is a vital sign. The requirement is written loose enough that it is not clear to me if the requirement is such that the Observation resource must also comply with the vital signs profile. The vital signs profile requires the Observation.category. So my question is:
If the measurement is a vital sign, am I required to populate the Observation.category element?
I would prefer NOT to include it to reduce the size of the resource as all it states is that the Observation is a vital sign which I already know from the Observation type.
Eric Haas (Sep 07 2017 at 18:28):
You may not need it but your trading partner might. Observation.category help EHRs for example in filtering through all the observaions.
Rob Hausam (Sep 07 2017 at 19:19):
Actually, I think the documentation in the Observation resource as it is currently (STU3 and current build) is pretty clear that this is required:
10.1.1.1 Core Profiles for Observation
The following core profiles for the Observation resource have been defined as well. If implementations use this Resource when expressing the profile-specific concepts as structured data, they SHALL conform to the following profiles:
Profile Description
Vital signs The FHIR Vital Signs profile sets a minimum expectations for the Observation Resource to record, search and fetch the vital signs (e.g. temperature, blood pressure, respiration rate, etc) associated with a patient
There have been questions raised about whether the VS profile should be required, and that's still under discussion, but that's the way that it is at present.
Geoff Low (Sep 07 2017 at 19:29):
Speaking as a possible consumer (clinical research), I'd like to vote for it being very necessary.
Chris Grenz (Sep 12 2017 at 01:23):
Are there reference ValueSets or mappings from codes to categories? In other words, can the category be reliably inferred from the code in some or all cases?
Grahame Grieve (Sep 12 2017 at 01:26):
some cases, but not reliably
Eric Haas (Sep 12 2017 at 05:31):
you could use the LOINC classes as a category for that though
Rob Hausam (Sep 12 2017 at 21:50):
It depends on what you think 'category' is intended to convey - or really what you need or want it to convey for your particular purposes. I think that's why we keep discussing it, because it's probably impossible to come to a consensus on it - although maybe in a number of cases we can come "close enough". Ideally we would be relying on understanding the meaning of the code itself, so that anyone can categorize it in however many ways are required to meet their own needs. We said that 'category' was for the cases where that level of understanding of the codes wasn't possible or practical - but there is not really an easily achievable "one size fits all" for that.
Jenni Syed (Sep 12 2017 at 21:53):
I think in this specific case (and actually, lab as well), the intent was to defer the understanding of what a "vital" or "lab" is to the underlying system
Jenni Syed (Sep 12 2017 at 21:53):
If an app or other FHIR client has a solid definition of its own, it would use the code field.
Jenni Syed (Sep 12 2017 at 21:54):
For Vitals, HL7 took a stab at "minimum set" but allows for other concepts to be under that vitals category
Jenni Syed (Sep 12 2017 at 21:55):
b/c we know it's very hard to keep and maintain a value set globally that defines all vitals or all labs - even within a specific country
Chris Grenz (Sep 12 2017 at 21:57):
As a naive IT guy, the relationship between category and code was clear enough only for me to jump to poorly formed conclusions when implementing. May be good to explicitly comment on the relationship...
Eric Haas (Sep 13 2017 at 15:25):
@Chris Grenz Something like "The category element groups concepts (codes) to meet the various needs of the client or server such as... and should not be used to infer the specific concept meaning - for that you need to interrogate the code"
Chris Grenz (Sep 13 2017 at 16:17):
No, I don't think I was confusing that the specific meaning was in the code. What I thought was that the category was simply an optimization of a terminology hierarchy operation - that the code would be a child of the category in some sense and that, in the absence of category I could just calculate it from code. OR, even further, once I had a solid terminology service in place, I'd cease to use category and simply use the terminology service to group codes. What I'm hearing here is that the category may carry information explicitly not derivable from the code and an associated terminology.
Chris Grenz (Sep 13 2017 at 16:18):
"various needs of the client or server" doesn't convey this adequately. Again, I read "needs" as potentially performance of some sort and not necessarily a clinical need.
Rob Hausam (Sep 14 2017 at 04:22):
I think that your interpretation is the way that category should be, Chris
but on the other hand, if that's what category actually is, then you probably don't really need it and can just rely on the code
Last updated: Apr 12 2022 at 19:14 UTC
