Stream: terminology
Topic: using post-compositional expressions
Joel Schneider (Sep 27 2017 at 02:10):
The CodeSystem.compositional element indicates whether the CodeSystem defines a post-composition grammar. (The HL7 version 3 core principles document seemingly uses the term post-coordination rather than post-composition for this.)
The FHIR documentation on Using Codes in Resources currently doesn't discuss usage of a post-composition grammar.
http://build.fhir.org/terminologies.html
Some questions about usage of post-compositional expressions in FHIR ...
1. May post-compositional expressions be used in places where FHIR requires a coded value (code)? If so, what binding strength should be used in cases where post-compositional expressions are allowed (required, extensible, etc.)?
2. Is there a standard terminology service operation for validating post-compositional expressions? If not, should there be one?
3. Is it possible to use a post-composition grammar with a ValueSet that contains concepts from multiple code systems?
Lloyd McKenzie (Sep 27 2017 at 03:36):
Binding strength won't influence post-coordination support. The value set will decide whether (and which) post-coordinated expressions are allowed. To my knowledge, we don't have any "core" mechanisms to control that. If you define a value set that says "all SNOMED CT procedure codes with a body site of lung", by default that means every pre-coordinated and every possible post-coordinated code that fits those criteria. We probably should have extensions that provide more control. There is an ability to have control over post-coordination when you generate an expansion using the ExpansionProfile resource, though there it's a "include/exclude post-coordinated concepts" - there's no fine-grained control that would support some types of post-coordination and not others.
Grahame Grieve (Sep 27 2017 at 06:51):
it's a filter property for snomed - one property, on or off, because mostly that's how servers work - they either support it or dont
Joel Schneider (Sep 27 2017 at 14:28):
Ok, post-coordinated expressions are allowed in coded values.
Can the validity of a post-coordinated expression be verified using the ValueSet/$validate-code operation?
Joel Schneider (Sep 27 2017 at 14:54):
Another way to phrase that is, would it be non-conformant if I implemented a ValueSet/$validate-code operation capable of validating a post-coordinated expression?
Grahame Grieve (Sep 27 2017 at 21:09):
if a code system defines a post-coordinated grammar, then the terminology servers should fully support that grammar if they claim to support the code system, and that would include properly understanding it in $validate-code.
Grahame Grieve (Sep 27 2017 at 21:10):
We're working on a new resource that allows a terminology server to declare it's capabilities, and that is expected to allow a server to declare that it supports a code system without implementing the grammar
Rob Hausam (Sep 27 2017 at 21:45):
I don't think "post-composition" is the intended term (or even valid). The phrase should be either "compositional grammar" or "post-coordination grammar", I believe, and we should fix the definition of CodeSystem.compositional to reflect that and avoid confusion. If there is general agreement on that I can create a tracker.
Grahame Grieve (Sep 27 2017 at 21:56):
I agree with that
Peter Jordan (Sep 28 2017 at 00:25):
We're working on a new resource that allows a terminology server to declare it's capabilities, and that is expected to allow a server to declare that it supports a code system without implementing the grammar
It will be interesting to see what might be required to implement SCT Grammar. At present, it's possible to place expression constraints as filters in ValueSet composition statements, display normalForm expressions as $lookup properties and validate post-coordinated expressions in codes...but I'm not sure what else? I guess that it's possible to place expression constrains in the filter parameter that's passed to $expansion operation requests, but I'm not certain if that's good practice and/or we're still waiting for the SCT Query Language to be published (2018) before adding a dedicated parameter for requests based on that dialect.
Joel Schneider (Sep 28 2017 at 04:19):
Thanks @Grahame Grieve for the explanation of grammar support in $validate-code.
Joel Schneider (Sep 28 2017 at 04:21):
My last question on this may be unusual ...
Suppose I have 2 CodeSystem resources, both of which utilize the same post-coordinated grammar, and a ValueSet composed of codes from both of them. Would it be valid to construct a post-coordinated expression composed of codes from both systems? Would it be reasonable to expect the ValueSet/$validate-code operation to handle such an expression? Would this only make sense under special circumstances (e.g. as a $validate-code "extension")?
Lloyd McKenzie (Sep 28 2017 at 04:45):
You could only mix and match across the code systems if the grammar of one or both code systems allowed that. An example of where this occurs is the IETF language codes whose post-coordinated syntax includes codes from the ISO country code table.
Joel Schneider (Sep 28 2017 at 14:15):
Thanks @Lloyd McKenzie, that's good to know.
Grahame Grieve (Oct 03 2017 at 05:46):
and if they did define that, you'd be expected to support it if you supported the grammar
Last updated: Apr 12 2022 at 19:14 UTC
