Stream: implementers
Topic: Subsumption testing in Token search params
emilio (Mar 12 2018 at 23:51):
Hi, I read the relevant info in the documentation, but still cannot understand the concept of Subsumption for implementation of the modifiers :below and :above on search parameters of type "Token". Could someone please help me with a more intuitive explanation?
Lloyd McKenzie (Mar 13 2018 at 01:02):
@Rob Hausam ?
Grahame Grieve (Mar 13 2018 at 01:43):
GET [base]/Condition?code=http://snomed.info/sct|126851005
Grahame Grieve (Mar 13 2018 at 01:44):
find all conditions that have the SCT code Neoplasm of liver
Rob Hausam (Mar 13 2018 at 01:45):
Here are a couple of examples that I've used in the FHIR terminology tutorial:
Subsumption-based Modifiers
Code in a resource subsumes the specified search code (e.g. is-a* relationship): below “Diabetes mellitus” (73211009)
http://fhirtest.uhn.ca/baseDstu3/Condition?code:below=http://snomed.info/sct|73211009
Code in a resource is subsumed by the specified search code (e.g. is-a* relationship): above “Viral pneumonia” (75570004)
http://fhirtest.uhn.ca/baseDstu3/Condition?code:above=http://snomed.info/sct|75570004
The :below search is returning Condition resources for "Type 2 diabetes mellitus" (44054006) (however, for some reason the HAPI server is returning some resource instances with incorrect 'display' values!), which is "below" “Diabetes mellitus” in the code system hierarchy. The :above search is generally less useful, and in this case it's not returning any Condition resource instances, but it might be expected to return cases of "Pneumonia" if they existed on the server.
Grahame Grieve (Mar 13 2018 at 01:46):
ah I'll let Rob answer this nicely
Rob Hausam (Mar 13 2018 at 01:47):
I guess the markdown doesn't work correctly inside the quote block, but hopefully it's readable
emilio (Mar 13 2018 at 19:14):
Hi @Rob Hausam , I understand the concept. But how do I –as an implementer– know that "Type 2 diabetes mellitus" (44054006) is "below" “Diabetes mellitus” (73211009)?
Rob Hausam (Mar 13 2018 at 19:34):
Well, I guess there are a couple of basic answers. Assuming that you trust the implementation of the FHIR terminology services, you will know that because the resources with those codes were returned by your :below search, because that's how it's supposed to work. If within the FHIR context you still need to verify that for some reason you can ask the server to verify it using the CodeSystem $subsumes operation (although that should be unnecessary to do in addition to the :below search). If you need to verify it outside of the FHIR terminology services context, you can do that manually in a variety of ways with different tools - possibly starting with the SNOMED CT browser at http://browser.ihtsdotools.org/. If you enter 44054006 in the search there you will see that it shows 73211009 as the immediate parent concept. Sometimes you have to traverse multiple levels to see the descendant or ancestor relationship, but theoretically that is doable.
Michael Lawley (Mar 14 2018 at 00:44):
@emilio One option is that for every Condition in your server you add the associated code to a $closure table, and then also add the :below code (73211009) when the search happens. Then your closure table will tell you directly all the things that are below "Diabetes mellitus” (73211009). Alternatively, you could expand a ValueSet with a filter of "concept is-a 73211009" and use the results to test against the codes in your Conditions.
The best / most efficient approaches depend on how you store/index your data, what terminology service capabilities you have, and whether you need to also handle infinite CodeSystems/ValueSets and things like post coordination.
emilio (Mar 14 2018 at 21:06):
@Rob Hausam Oh, so, I, as the implementer of a FHIR server with search capabilities, but no terminology service, each time that I get a query with a :below modifier, will have to consult with a terminology service to know the parents of the code in the query?
Grahame Grieve (Mar 14 2018 at 21:15):
well, you have several choices:
- you can consult a terminology service each time you get the query
- you can maintain a closure table internally using the closure table maintenance service from the terminology server interface (several open source implementations provide this).
- you can not support the :below modifier
Rob Hausam (Mar 16 2018 at 12:39):
Another option is that you can build your own terminology service capabilities (whether exposed as a FHIR endpoint or accessed internally).
Last updated: Apr 12 2022 at 19:14 UTC
