Stream: implementers
Topic: Using Components in Observations
Alejandro Lopez Osornio (Feb 04 2020 at 19:58):
Hello, for an interoperability project for AI engines, we are planning to use the Observation resource to share patient signs and symptoms data. The idea is to use the resource following the "case 3 pattern" described in the documentation:
Code = SNOMED CT Clinical finding -> Value = found/true
We would like to use the Components property to add additional details that are not described in the SNOMED CT findings model (out of scope for the SCT model), like "quality of pain":
For example, representing "Sharp epigastric pain":
- Code
- 79922009 |Epigastric pain (finding)|
- Value
- 52101004 |Present (qualifier value)|
- BodySite
- Automatically mapped from SCT Attributes (27947004 |Epigastric region structure (body structure)|)
- Component (SNOMED CT attribute value pair)
---- Code: 64625007 |Characteristic of pain (observable entity)|
---- Value: 410707003 |Sharp sensation quality (qualifier value)|
Does this sound correct? is this a valid use of the components property?
Thanks
Richard Townley-O'Neill (Feb 04 2020 at 21:05):
It agree with what I know of Observation.
Alejandro Lopez Osornio (Feb 05 2020 at 13:49):
Thanks
Rob Hausam (Feb 13 2020 at 06:40):
@Alejandro Lopez Osornio So, it appears to me that what you want to do is effectively create the equivalent of a SNOMED CT compositional expression using the Observation.component information model structure as the "syntax" for adding SNOMED CT qualifying attributes (name-value pairs)? Is that correct? Assuming that's the case, if "valid" is understood as anything that is "not prohibited", then I think this use is valid. But whether this use of Observation.component is expected, intended or desirable, I'm not quite so sure. If you as the "sender" understand it that way and anyone who "receives" the data from you also understands it that way, then it should work. I think the Observation.component structure itself probably is relatively understandable when used this way, but I'm also thinking that the expectation of receiving data that is structured in this way may not be so common. In my (re)reading of our documentation on the use of Observation.component, including here, I don't think I'm seeing this type of use described. Of course, support for representation of compositional expressions (particularly for SNOMED CT) is provided in Coding.code and, as I'm sure you know, is described here. Representing the expression in Coding.code of course means that you need to parse the code string to be able to understand and utilize any of the individual qualifying attribute data, but for the AI engines project that you are describing, I wonder if that might not be possible? Another note, even if you did use an expression in Coding.code you could still separately populate Observation.bodySite if you wanted to, as the semantics for that element are rather straightforward and should match well with the SNOMED CT concept model. And finally, I think that if I wanted to represent "post-coordinated" qualifying attribute data like this discretely without using a compositional expression in Coding.code, I would be inclined to use extension(s) (one or more) to do it, rather than trying to "shoehorn" it (in my opinion) into Observation.component. Those are some thoughts. And I'm interested in hearing your further thoughts, particularly if you think that I have missed or mis-stated something.
Alejandro Lopez Osornio (Feb 13 2020 at 20:06):
Hi @Rob Hausam , thanks, you have described the scenario pretty well, these were the options that were considered. As you said, one of the considerations is how deep the clients would want to go into managing SNOMED CT Compositional Grammar and extending the concept model.
If all the required expressivity would be covered by the standard SNOMED CT concept model, the best solution would probably be that, using expressions, even if it would be more complex to work with post-coordination.
In this case, pain quality and other examples they propose are not part of the standard concept model, this would require to create new concepts for the attributes on the expression (as the observable is not a relationship type, it would need a new linkage concept), and to formalize the domain and range of these attributes in the MRCM (machine-readable concept model). This way the new expressions can be validated against this extended concept model, and even subsumption queries can be used to analyze data later.
The obstacle to such implementation is the complexity that the AI engines participating in this project would be able to implement regarding SNOMED and that maintaining a SNOMED CT extension with an extended concept model would be too complex/expensive for the organization that runs the interoperability experiment.
Having the observation attributes readily available as FHIR properties is a much simpler scenario, and in some cases like "body site" the information can be conveyed from the SNOMED CT definition.
I think that your suggestion to think about whether it is better to use extensions or components is very interesting. Extensions would be more clear, I agree, but if the group comes up with any new attribute this would require to update the extension profile or to create a collection of profiles for specific types of observations like "pain observation" or "diarrhea observation" etc. This a complex task also. And if a single profile is created for a generic "AI Symptom observation" having a collection of very specific clinical attributes may be confusing as well.
And of course, going to the third option of using components in the proposed way will not be understood outside this project, so actual interoperability outside the scope of an implementation guide is limited.
I don't see a perfect solution, will discuss options with the group (it's a topic group on WHO - AI4H - https://www.itu.int/en/ITU-T/focusgroups/ai4h/Pages/default.aspx).
Thanks for your input!
Last updated: Apr 12 2022 at 19:14 UTC
