Stream: terminology
Topic: CodeSystem property types
Michael Lawley (Sep 29 2016 at 00:44):
Is there a raionale for the set of types available for CodeSystem properties?
We would *really* like to use a uri or url. But also, decimal and Quantity seem to be omissions
Grahame Grieve (Sep 29 2016 at 00:48):
main rationale is only to ad what is needed, not to throgh in a kitchen sink of possibiliites. name you use cases
Michael Lawley (Sep 29 2016 at 01:27):
uri would be a general mechanism to link to more complex things. For example an image or diagram associated with a code.
decimal / quantity would be for things like meds properties (concentration of a solution, or quantity of an ingredient)
Grahame Grieve (Sep 29 2016 at 19:59):
do we have code systems with that level of graunalarity? it sounds like medication resources to me,
Michael Lawley (Sep 30 2016 at 00:11):
I wanted to attach a property carrying the SNOMED CT diagramming syntax to each code.
Additionally, we're try to work out how best to expose the SNOMED CT relationships since their structure is more complex than a simple valueCode will support. We'd also like such a solution to be generalisable to various OWL-based terminologies
Grahame Grieve (Sep 30 2016 at 00:29):
a diagram for each code?
Grahame Grieve (Sep 30 2016 at 00:29):
amazing
Grahame Grieve (Sep 30 2016 at 00:29):
and perhaps you can explan the other a bit more
Michael Lawley (Sep 30 2016 at 01:54):
Do you mean the complex relationship structure? This relates to "nesting"
Consider 30392007 | Laparoscopy with excision of lesion |
http://ontoserver.csiro.au/shrimp/?concept=30392007&versionId=http%3A%2F%2Fsnomed.info%2Fsct%2F32506021000036107%2Fversion%2F20160831
There are two values for |method| - |excision| and |inspection| and one for |direct morphology| = |lesion|, if the SNOMED relationships get flattened into simple property-value pairs (which is all CodeSystem currently allows), then the association between |excision| and |lesion| is lost.
Grahame Grieve (Sep 30 2016 at 02:34):
I asked about value set filters. Given that we allow expression = [x] as a filter, why is there are use case for Concept is-a [y] where [y] is post-coordinated?
Michael Lawley (Oct 04 2016 at 02:11):
Right. Okay, while SNOMED does not support general concept inclusions it is possible to rewrite a subsumption query with post coordination as an ECL query. If / when this changes, then this will no longer be true.
Grahame Grieve (Oct 04 2016 at 03:15):
this is going to change?
Michael Lawley (Oct 06 2016 at 04:57):
I have no useful sense of how long it might be before GCIs are supported, but there's certainly an appetite for them in some quarters. Also, they are a core part of the work to redo the anatomy hierarchy and align it with FMA.
Grahame Grieve (Oct 06 2016 at 04:58):
what's a GCI?
Michael Lawley (Oct 06 2016 at 04:59):
GCI = General Concept Inclusion (allows for multiple sufficient conditions in the definition of a concept).
Michael Lawley (Oct 07 2016 at 03:36):
@Grahame Grieve This looks wrong to me http://fhir3.healthintersections.com.au/open/CodeSystem/$lookup?code=192030003&system=http%3A%2F%2Fsnomed.info%2Fsct
It shows inactive as "False" - would expect this to be a valueBoolean and also should be true not false
It shows moduleId as "22215336" - should be 900000000000207008
See https://ontoserver.csiro.au/shrimp/?concept=192030003&versionId=http%3A%2F%2Fsnomed.info%2Fsct%2F32506021000036107%2Fversion%2F20160731 for my reference
Grahame Grieve (Oct 07 2016 at 06:03):
agree about inactive being wrong, and moduleId being wrong - will be fixed next update. (oops on both).
Grahame Grieve (Oct 07 2016 at 06:03):
but all properties are type string, according to the spec
Michael Lawley (Oct 07 2016 at 07:11):
Which spec? CodeSystem allows for multiple types: http://hl7-fhir.github.io/codesystem.html#properties and I don't see anything relevant here http://hl7-fhir.github.io/snomedct.html
Grahame Grieve (Oct 07 2016 at 09:32):
the spec for $lookup
Michael Lawley (Oct 07 2016 at 11:45):
Ah, well, that's interesting. So properties go in typed, but come out "untyped" (through $lookup) but not in the CodeSystem resource itself. Where do I find the mapping between the type and the String representation? I presume dateTime is as documented for search, but what about Coding? Also, boolean - I would have expected true/false but I see you have True and False
Grahame Grieve (Oct 07 2016 at 11:57):
well, it's really something we need to fix
Grahame Grieve (Oct 07 2016 at 11:57):
want to create a task?
Michael Lawley (Oct 07 2016 at 21:40):
Peter Jordan (Oct 19 2016 at 22:37):
When requesting the definition property in a $lookup operation for a SNOMED CT Code should the Fully Specified Name be returned, or something else? I'm looking for a property which might contain defining attributes (other than direct parent and child which are already defined as properties).
Grahame Grieve (Oct 19 2016 at 22:49):
have you seen this task?
Grahame Grieve (Oct 19 2016 at 22:49):
Grahame Grieve (Oct 19 2016 at 22:50):
and since that is somewhat short hand, try doing $lookup on a snomed code on fhir3.healthintersections.com.au
Grahame Grieve (Oct 19 2016 at 22:50):
you should get back a bunch of properties now
Peter Jordan (Oct 19 2016 at 23:33):
Thanks, Grahame. I was aware of the task, as the result of the breakout session in Baltimore, but not the new CodeSystem $lookup properties that effectively implement decomposition. Looking at the response from...
http://fhir3.healthintersections.com.au/open/CodeSystem/$lookup?system=http://snomed.info/sct&code=28576007
I see a new 'normalForm' property containing a normalized expression and 'normalFormTerse' with the canonical version of that expression.
What I'm not seeing are individual attributes and relationship group numbers - which was discussed in Baltimore - or do I need to request them explicitly with another property?
Still not sure what should go in the 'definition' property for an SCT Code - if anything (possibly not FSN as that's included in the designations)?
Grahame Grieve (Oct 20 2016 at 01:47):
I need to add the other relationships - may get to that today
Grahame Grieve (Oct 20 2016 at 01:48):
I don't give a definition for a SCT term.
Grahame Grieve (Oct 20 2016 at 07:09):
I just committed the write up of this; it will take some time to get published, but it will be build 10029
Peter Jordan (Oct 26 2016 at 03:06):
Looking at the SCT-specific properties for $lookup operations, I have a couple of questions. Firstly is 'Normal Form' short nf or long nf (and that is different from verbose/terse versions). Secondly, as alternative to specifying attribute types as properties (e.g. laterality), what if a user requires all attributes (possibly because they don't know what the attributes of the concept are)?
Grahame Grieve (Oct 26 2016 at 03:33):
I'm using short form. And we should say that it's short form
Grahame Grieve (Oct 26 2016 at 03:35):
? list 246061005 as a requested property - that means any attribute.
Peter Jordan (Oct 26 2016 at 04:49):
Short Normal Form to be accurate, I think. In the SCT TIG, the term 'short form is used in relation to SCTIDs. BTW: it would be interesting to hear the answer to Michael's question about how 'short normal form' might be used - I believe that 'long normal form' is required for equivalence testing. Look forward to implementing all this...and $compose.
Grahame Grieve (Oct 26 2016 at 06:10):
I primarily think of the short normal form as documentation for the user at this time
Last updated: Apr 12 2022 at 19:14 UTC
