Stream: terminology
Topic: Handling SNOMED qualifiers
Richard Kavanagh (Jul 20 2016 at 06:43):
Is there an agreed method for catering for SNOMED qualifiers.
Richard Kavanagh (Jul 20 2016 at 06:43):
Looking at the following V3 snippet, how would this be coded in FHIR.
Richard Kavanagh (Jul 20 2016 at 06:43):
<value xsi:type="CD" code="405843009" displayName="Widespread metastatic malignant neoplastic disease" codeSystem="2.16.840.1.113883.2.1.3.2.4.15">
<qualifier>
<name codeSystem="2.16.840.1.113883.2.1.3.2.4.15" code="106229004" displayName="Qualifier for type of diagnosis"/>
<value codeSystem="2.16.840.1.113883.2.1.3.2.4.15" code="8319008" displayName="Principal diagnosis"/>
</qualifier>
</value>
Grahame Grieve (Jul 20 2016 at 07:05):
http://hl7-fhir.github.io/snomedct.html#4.1.1.1.1
Grahame Grieve (Jul 20 2016 at 07:05):
The following SNOMED CT artifacts are valid in the code element for the http://snomed.info/sct namespace: Concept IDs , Expressions (grammar ) and SNOMED Legacy codes .
Grahame Grieve (Jul 20 2016 at 07:06):
so you would convert that to the snomed grammar prior to expressing in FHIR.
Grahame Grieve (Jul 20 2016 at 07:06):
405843009: 106229004= 8319008 off the top of my head
Richard Kavanagh (Sep 05 2016 at 16:17):
Back on the subject of qualifiers. using the example by @Grahame Grieve above. How would this impact a RESTful query if say this was an Observation.Code value?. We have some partners here in England that are currently looking to handle qualifiers using a datatype extension as opposed to a compositional expression.
How are others doing this?
Grahame Grieve (Sep 05 2016 at 20:42):
I have not heard of any one doing extensions for this.
Grahame Grieve (Sep 05 2016 at 20:42):
why would people choose to use an extension rather than a snomed ct expression?
Eric Haas (Sep 06 2016 at 00:53):
What is the example exactly? can't find it
Richard Kavanagh (Sep 06 2016 at 07:54):
I asked how to cater for SNOMED qualifiers and the response was to use a compositional expression. So in FHIR the following
405843009: 106229004= 8319008
would be comparable to this V3 construct
Richard Kavanagh (Sep 06 2016 at 07:55):
<value xsi:type="CD" code="405843009" displayName="Widespread metastatic malignant neoplastic disease" codeSystem="2.16.840.1.113883.2.1.3.2.4.15">
<qualifier>
<name codeSystem="2.16.840.1.113883.2.1.3.2.4.15" code="106229004" displayName="Qualifier for type of diagnosis"/>
<value codeSystem="2.16.840.1.113883.2.1.3.2.4.15" code="8319008" displayName="Principal diagnosis"/>
</qualifier>
</value>
Grahame Grieve (Sep 06 2016 at 09:35):
yes that's correct
Eric Haas (Sep 06 2016 at 18:28):
I assume you mean by the question of how to do a RESR Query for SNOMED Expression you have an expression in a coded element.
For Example:
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "405843009: 106229004= 8319008",
"display": "Widespread metastatic malignant neoplastic disease: Qualifier for type of diagnosis= Principal diagnosis"
}
]
},
And you want this Condition to show up in your query for code = 405843009
GET [base]/Condition?code=http://snomed.info.sct|405843009
Eric Haas (Sep 06 2016 at 18:29):
I don't think that has been answered or at least documented in the specification...
Rob Hausam (Sep 06 2016 at 19:00):
For this to work (if the server supports reasoning on SNOMED CT compositional expressions - not too likely), the search also needs subsumption, such as:
GET [base]/Condition?code:below=http://snomed.info.sct|405843009
Grahame Grieve (Sep 06 2016 at 20:05):
I think this works on my server
Rob Hausam (Sep 06 2016 at 20:09):
that's great - I need to check that out
Eric Haas (Sep 06 2016 at 22:28):
do we document that Queries may need to consider expressions rather than simple lists of codes?
Grahame Grieve (Sep 06 2016 at 23:09):
subsumption logic, yes
Michael Lawley (Sep 07 2016 at 01:26):
@Grahame Grieve Your server does full subsumption reasoning?
Would GET [base]/Condition?code:below=http://snomed.info.sct|128462008 match the code 64572001:116676008=14799000 ?
Grahame Grieve (Sep 07 2016 at 05:01):
umm, it should.... but it's possible I haven't strung all the pieces together yet.
Last updated: Apr 12 2022 at 19:14 UTC
