Stream: terminology
Topic: SNOMED properties
Michael Lawley (Dec 01 2017 at 00:29):
http://hl7.org/fhir/snomedct.html#props defines a set of properties for the SNOMED CT code system. Specifically, it says that "any SNOMED CT relationships where the relationship type is subsumed by Attribute (246061005) automatically become properties".
However, it goes on to say that the (input) property code is a human readable code, eg 'Laterality' or 'Procedure site - Direct', but that in the output Parameter, the (sub)property code is the associated URI (http://snomed.info/id/272741003 and http://snomed.info/id/405813007 respectively).
This raises a number of issues:
1. Having the input and output codes being different means a client needs to maintain its own mapping between them in order to interpret the results.
2. What is the canonical mapping from the SCTID to the human readable string? It's not the Fully Specified Name (because it's missing the text in brackets at the end), and using the preferred term means that it can change depending on the locale (eg Swedish and other translations).
3. What are the reasons for not just adopting the approach of using the SCTID for the input and output code values?
There are other corner-cases to consider as well:
4. Not all descendants of Attribute are "real" properties eg, |Concept history atttribute|, |Concept model attribute|, and |Unapproved attribute| - are these valid and if so how should they be interpreted? (Note, not all non-leaf descendants are abstract like these three. For example |Procedure site| has two child attributes)
5. If so, then Attribute (246061005) itself a valid property?
6. What about |Is a| - it's already covered by the parent and child properties and it is not a relationship in the same sense as the others
7. How should 609096000 | Role group | behave as an input property?
Peter Jordan (Dec 01 2017 at 05:52):
Thus far, I haven't come across a requirement to request individual SCT attributes in a CodeSystem $lookup and would prefer an explicit property called 'attribute' that would return all defining relationships. Otherwise I agree with Michael Lawley that the SCTID should be used for both input and output attribute code values.
Michael Lawley (Dec 01 2017 at 05:57):
My first cut at this actually used 246061005 to mean "all of the (non-ISA) SNOMED relationships", but we do have use-cases where people want only some of them
Michael Lawley (Dec 01 2017 at 05:58):
There's another issue too - SNOMED CT-AU has decimal-valued properties and these aren't supported by $lookup
Peter Jordan (Dec 01 2017 at 06:02):
There's another issue too - SNOMED CT-AU has decimal-valued properties and these aren't supported by $lookup
Nasty! Has the terminology world ever debated an alternative to the slightly Orwellian term 'non-ISA'?
Michael Lawley (Dec 01 2017 at 07:47):
GF#14236 created for the decimal issue
Rob Hausam (Dec 01 2017 at 19:19):
These are good observations, Michael. I think that the point about not being able to rely on the human readable string to define the property is definitely valid, and I also agree with using the SCTID for this (for code system defined properites we need to reference them the same way that the code system does). It's also true that some of the descendants of Attribute (including Attribute itself and the other "abstract" descendants) are not really valid properties, and "Is a" is handed separately. And "Role group" is also special in its own way. But maybe we don't need to worry about that too much and assume that (at least for the most part) people won't try to use those descendants in ways that don't make sense (or, if they do, they'll need to figure that out)? I agree with updating $lookup per GF#14236.
Grahame Grieve (Dec 04 2017 at 21:06):
the problem with this is that some things that have concept ids are already fixed to FIR defined codes for cross-code system consistency
Rob Hausam (Dec 05 2017 at 13:35):
Grahame, I'm not quite sure which "this" and the context for cross-code system consistency that you are referring to here. Can you clarify a bit?
Grahame Grieve (Dec 05 2017 at 18:54):
using snomed concept ids for relationships. I'll be face to face with @Michael Lawley today - we'll grab some time to talk about it
Michael Lawley (Dec 05 2017 at 21:33):
Sadly not - I was only able to do day 1 of the connectathon & am back at home in Brisbane doing family stuff today
Grahame Grieve (Dec 05 2017 at 21:34):
oh. I wish you'd said yesterday....
Michael Lawley (Dec 05 2017 at 21:36):
me too...
Rob Hausam (Dec 06 2017 at 01:56):
It's too bad the face to face didn't happen, but we can keep discussing here. And I do get the point about using the FHIR-defined codes (when they exist) for cross-code system consistency. It seems to me that both could be used. If you want to be general you can use a FHIR-defined standard property code (assuming that one exists for the relationship that you're interested in), or if you want to be specific to SNOMED CT you can use the sctid (or the url?). Is that going to be a problem?
Michael Lawley (Dec 07 2017 at 23:01):
If there are fixed cross-code system FHIR-defined property codes then naturally they should work. If there are also SNOMED relationship types that are equivalent then they should work too (with the SCTID), but I'm not sure what these might be (not parent/child, nor status).
As an example of what Ontoserver currently does, see http://ontoserver.csiro.au/stu3-latest/CodeSystem/$lookup?system=http%3A%2F%2Fsnomed.info%2Fsct&code=14207011000036103&property=246061005&property=version&property=display&_format=json
Note, Ontoserver does not return these relationship properties by default, but only on request using the property parameter. You can also request them all by specifying 246061005 (Attribute) as the property
Peter Jordan (Dec 08 2017 at 00:03):
@Michael Lawley the way that Ontoserver renders the attribute/values pairs, as two-part sub-properties, probably needs to be proposed as an addition to the specification (unless I've missed something).
Michael Lawley (Dec 12 2017 at 02:48):
@Peter Jordan How else would you do it? Did you expect something like:
{ "name" : "property", "part" : [ { "name" : "subproperty" "part" : [ { "name" : "700000061000036106", "valueCode" : "700031831000036109" }, { "name" : "description", "valueCode" : "esomeprazole 20 mg enteric tablet, 14" } ] } ] }, ...
Peter Jordan (Dec 12 2017 at 03:52):
@Michael Lawley - maybe something like this...
<parameter> <name value="property" /> <part> <name value="code" /> <valueCode value="363705008" /> </part> <part> <name value="valueCode" /> <valueCode value="24184005" /> </part> </parameter>
I view it as a single property exposing a name/value pair - both of which happen to be coded values. I'm not quite sure how the notion of a sub-property arises but, as ever, will bow to your subject-matter expertise.
Michael Lawley (Dec 12 2017 at 04:25):
The subproperty stuff encodes role grouping
Peter Jordan (Dec 12 2017 at 04:30):
Couldn't role grouping numbers be just another part?
Michael Lawley (Dec 12 2017 at 04:38):
Two problems:
1. exposing the the number-value of a role group is bad (an internal implementation detail that is too complex to expect people to process correctly)
2. How do you associate the group numbers with the property-value pairs?
Peter Jordan (Dec 12 2017 at 06:30):
If the concept of grouping is too complex for clients to process correctly, isn't expecting them to parse a parameter-->property-->part-->subproperty-->part structure to identify groups, without a group identifier, going to be even more problematic? Why not just add another part to parameter-->property and treat the group number as a surrogate identifier - or leave the joys of grouping to the NormalForm property?
Michael Lawley (Dec 12 2017 at 20:30):
The current approach with subproperty already does, I think, what's needed to make things simpler for clients -- it groups the actual attribute/value pairs together and hides the group numbers. All a client needs to know at this point is that "grouping" is happening.
Peter Jordan (Dec 12 2017 at 20:32):
Something is happening, but they don't know what it is - sounds like a Bob Dylan lyric.
Might be a case of trying both approaches and seeing what clients prefer?
Michael Lawley (Dec 12 2017 at 20:43):
I think this concept is a useful one to illustrate why the grouping is needed:
{ "resourceType": "Parameters", "parameter": [ { "name": "version", "valueString": "http://snomed.info/sct/32506021000036107/version/20171130" }, { "name": "display", "valueString": "Creation of connection from spinal syrinx" }, { "name": "property", "part": [ { "name": "subproperty", "part": [ { "name": "code", "valueCode": "260686004" }, { "name": "valueCode", "valueCode": "129284003" } ] }, { "name": "subproperty", "part": [ { "name": "code", "valueCode": "363704007" }, { "name": "valueCode", "valueCode": "280401006" } ] } ] }, { "name": "property", "part": [ { "name": "subproperty", "part": [ { "name": "code", "valueCode": "260686004" }, { "name": "valueCode", "valueCode": "360240009" } ] }, { "name": "subproperty", "part": [ { "name": "code", "valueCode": "363700003" }, { "name": "valueCode", "valueCode": "75797008" } ] }, { "name": "subproperty", "part": [ { "name": "code", "valueCode": "405813007" }, { "name": "valueCode", "valueCode": "39916009" } ] } ] } ] }
Peter Jordan (Dec 12 2017 at 20:50):
Is 'subproperty' the correct name and construct? Does your example include un-grouped properties?
Michael Lawley (Dec 12 2017 at 22:01):
Here's an example with an ungrouped property:
{ "resourceType": "Parameters", "parameter": [ { "name": "version", "valueString": "http://snomed.info/sct/32506021000036107/version/20171130" }, { "name": "display", "valueString": "Xenon-133" }, { "name": "property", "part": [ { "name": "code", "valueCode": "127489000" }, { "name": "valueCode", "valueCode": "80751004" } ] } ] }
Michael Lawley (Dec 12 2017 at 22:09):
subproperty is what appears in the specification http://hl7.org/fhir/codesystem-operations.html#4.7.15.1
But maybe I am misreading the spec. There are no examples included for this.
I've tried to see what @Grahame Grieve 's server does but I can't work out how to get at these properties via $lookup
Peter Jordan (Dec 13 2017 at 03:51):
Don't think you're misreading the spec. Just a failure on my part, due to fixation on the SCT-specific properties on the Using SNOMED... page! In fact, it cites SCT Relationship Groups as the main use of nested properties. Still not convinced that nesting is the best construct for rendering grouping, and would prefer Group IDs, but will go with the consensus - or maybe not implement this variation as it will only be applicable to a request for all, non is-a, attributes.
Last updated: Apr 12 2022 at 19:14 UTC
