Stream: terminology
Topic: Calculate Observation.category from SNOMED Concept
Kevin Mayfield (Oct 07 2017 at 07:08):
More of a SNOMED question: Is it possible to infer Observation.category from a SNOMED Concept. E.g. for a concept 160621008 (Ex-cigar smoker) would it be possible to use the CodeSystem to find out this is social-history ... Would I need to use a refset?
Peter Jordan (Oct 07 2017 at 09:13):
You can use the CodeSystem $subsumes operation to return any relationship between SCT codes. This will tell you that 160621008|Ex-cigar smoker| is not subsumed by 160476009|Social history|... CodeSystem/$subsumes?system=http://snomed.info/sct&codeA=160621008&codeB=160476009
These concepts come from different SCT hierarchies. Ex-cigar smoker is a clinical finding and social history an observable entity.
Kevin Mayfield (Oct 07 2017 at 10:08):
So using this example https://gist.github.com/KevinMayfield/a1921748f91e6245319132989be14909
Kevin Mayfield (Oct 07 2017 at 10:13):
I think this is true: valueQuantity 428041000124106 Occasional tobacco smoker is a child code of 229819007 Tobacco use and exposure.
Kevin Mayfield (Oct 07 2017 at 10:13):
Which in turn comes under category social-history from CodeSystem http://hl7.org/fhir/observation-category
Kevin Mayfield (Oct 07 2017 at 10:16):
From an implementation point of view: Given many systems I've worked on would have just recorded the code: 428041000124106 Occasional tobacco smoker. When I recieved a search on category social history I need to find the correct place in the SNOMED heirarchy to search from and then search for child codes.
Kevin Mayfield (Oct 07 2017 at 10:19):
Alternatively we should use a SNOMED ValueSet for category. (I’m not a clinical coder) Something like we would use https://snomedbrowser.com/Codes/Details/228272008 in place of social-history.
Kevin Mayfield (Oct 07 2017 at 10:21):
So observation.valueQuantity is a child of observation.code is a child of observation.category.
Rob Hausam (Oct 07 2017 at 14:51):
Ideally, you should be able to infer the Observation.category code(s) from Observation.code, but there is no guarantee of (or even suggestion of, really) whether that will be possible in any given case. The only explanation in the Observation resource documentation is "Used for filtering what observations are retrieved and displayed". That pretty much reflects the original intent of the 'category' element, and the thought at that time was that it could be used for that purpose by applications that weren't able to understand the semantics of the code system being used in Observation.code, but by using the 'category' code they could at least figure out where to display the data in their application. In practice, what people need and want in that regard is obviously rather implementation and system dependent, and it's difficult to find a single set of codes that will work for that purpose for everyone. So now the 'category' element has become 0..* Codeable concept, so you can pretty much categorize the resource however you want - essentially treating 'category' as a set of one or more "tags". Getting back to the original intent, if your system does understand the semantics of the code system that is being used in Observation.code, then you can make use of the code system semantics instead to achieve that purpose, and in that case you really wouldn't need to use the 'category' element at all. And if you do populate Observation.category, the code(s) there should be semantically consistent with Observation.code, as I think you've described above (e.g. if using SNOMED CT they would be at a higher level in the SNOMED CT hierarchy). You might map the FHIR observation-category codes to the code system being used in Observation.code (but you don't have to do that) - if you did do that then you could provide both the FHIR code and the mapped code (e.g. SNOMED CT), since translations are allowed. In your own situation, using SNOMED CT, I suspect that you might want to consider one of those options.
Kevin Mayfield (Oct 07 2017 at 15:16):
Thanks. So I believe we would need a SNOMED ValueSet for observation.categories and observation.codes - the (UK) profiles I looked at, had standard fhir 'example' bindings to valuesets but when I looked at the detail they are both bound to SNOMED CT. Nothing to stop us from going live soon though.
Rob Hausam (Oct 07 2017 at 17:50):
Yes, I think that's what I would do in your situation.
Kevin Mayfield (Oct 08 2017 at 07:49):
I think this is showing a constraint between valueQuantity->code->category which isn't apparent in the profile. The most detailed concept (valueCodeableConcept/code) will dictate concepts above it (code/category) in the resource - so when a Observation is POSTed in it may be different when retrieved. Think we need to build this into UK validation tools to prevent this.
Kevin Mayfield (Oct 08 2017 at 07:51):
The validation would ensure SNOMED CT parent/child relationships are correct
Last updated: Apr 12 2022 at 19:14 UTC
