Stream: terminology
Topic: Block vote on Vocab Main call 2020-07-23
Rob Hausam (Jul 17 2020 at 22:35):
On the FHIR Tracker Issues call yesterday we reviewed a set of 11 issues that have been marked as ready-for-vote. We finalized the dispositions and have prepared a block vote, and we're proposing to vote on the block during the Main Vocab call next Thursday (7/24). Here is a link to the Confluence page with the list of the trackers to be voted on in the block.
Please let me know if you have any questions or if there are any issues that you would like to have pulled from the block. And please join the conference call next Thursday at 3:30 Eastern for the vote. Thanks!
Michael Lawley (Jul 18 2020 at 01:10):
FHIR-23785 (J#23785) still seems problematic - the proposed text change does not clarify whether the URL is intended to be that of a FHIR Tx endpoint (and thus used for base in [base]/ValueSet/$expand?url=[valueSetUri] to obtain the trusted expansion, or directly resolved and thus a GET on the url would retrieve the trusted expansion.
Rob Hausam (Jul 18 2020 at 14:14):
Thanks, @Michael Lawley. Do you want to pull the issue from the block to discuss separately (and potentially revise the resolution) on the call?
Michael Lawley (Jul 19 2020 at 00:30):
As the revised text doesn't resolve or address the ambiguity, yes I think it needs to be pulled.
Due to timezones (3:30 Eastern), it would be great if we could discuss here or on the ticket itself.
Michael Lawley (Jul 19 2020 at 00:33):
@Carmela Couderc are you able to provide insight as to whether this URL is meant to be of an (authoritative) expanded ValueSet or an (authoritative) FHIR endpoint from which to obtain an expansion?
Rob Hausam (Jul 20 2020 at 13:23):
Yes, if we can agree on an updated resolution (here or in Jira) within the next 24 hours or so then we may be able to revise the tracker and keep it in the block. @Robert McClure- your thoughts?
Robert McClure (Jul 20 2020 at 15:55):
Good question @Michael Lawley . My opinion on this is that it would be an authoritative expansion resource. I do not think we should expect the ability to respond to an $Expand. But I'd like to hear what people think is most useful, doable. I'm assuming that this will not be something that most value sets will have so perhaps we say it has to support $expand?
Michael Lawley (Jul 20 2020 at 23:12):
Thanks Rob, I would also expect it to be to a pre-expanded ValueSet and not a FHIR endpoint.
Michael
Sent from my iPhone
Rob Hausam (Jul 21 2020 at 12:51):
I think there is (at least implicit) agreement that this needs to return a ValueSet resource with an authoritative expansion (that's what this is all about). But is that a single, static item, apparently based on an assumed fixed set of the expansion parameters? If not, then it seems that you would need it to be a FHIR endpoint, so that it can return the authoritative expansion for any combination of the $expand operation parameters.
Robert McClure (Jul 21 2020 at 19:49):
@Rob Hausam Can you say what parameters you think should be considered? My assumption is "current code system version and nothing filtered out." I think we'd want to say in the comment that best practice would be that the source for this is committing to keep the expansion UTD based on the most recent code system version. We should also say that users that access the expansion should confirm that the expansion is based on the code system version they expected. Perhaps we also should note that the expansion should include the parameters used to generate the expansion. FWIW, I'd also like to say (someday) that the expansion resource SHALL conform to the following profiles cpg-executablevalueset, cpg-computablevalueset, and cpg-publishablevalueset.
Michael Lawley (Jul 22 2020 at 02:12):
I think all expansions MUST contain the parameters that were used to derive the expansion (such as code system version).
I would also expect that any use of a "authoritative expansion" should also check that the parameters are compatible with the context of use.
Naturally then there may be many "authoritative" expansions, each with different expansion parameters.
Rob Hausam (Jul 22 2020 at 07:09):
Agree with Michael. I could probably go with "current code system version and nothing filtered out", as long as that is explicit. But anything else ('activeOnly, excludeNested, system-version or force-system-version, etc.) requires a FHIR endpoint and the $expand operation (which might be a reasonable approach to it?).
Rob Hausam (Jul 23 2020 at 13:27):
@Michael Lawley Would you have any time to suggest a revised proposed resolution for FHIR-23785 (J#23785) that would meet your needs and expectations that we can discuss on the call today? It looks like we will pull this from the block and discuss it separately. if you are able to join at some point (maybe during the latter part of the call?) that would be great (but not necessarily expected). One thing I think we should consider is if whatever solution we decide on is required or suggested (i.e. best practice) behavior for servers that implement it.
Michael Lawley (Jul 24 2020 at 03:20):
Thanks Rob, I've added suggested text to the ticket, but it has raised further (similar) questions about the associated valueset-authoritativeSource extension.
Robert McClure (Jul 30 2020 at 21:32):
FHIR-23785 was discussed on the Vocab FHIR tracker call today. I would like to propose the following solution but we want input from zulip:
I propose that valueset-trusted-expansion should be defined to contain a URL of a FHIR server where an authoritative value set expansion may be obtained that conforms to the requirements that are consistent with those specified by the following two profiles:
I think that the valueset-authoritativeSource extension should be defined as the url of a FHIR terminology service endpoint that is capable of generating an authoritative valid FHIR expansion for the value set.
I think these two extensions should not be co-dependent. They may be the same server (likely will be when authoritative source is populated.) I also understand that we need to provide "best practice" guidance as to the parameters that should be used to generate the trusted expansion, which other than those needed to support the profiles, should be to use the most recent code systems and to not evoke any other restrictive parameters.
I also encourage @Peter Jordan to comment on the potential to have a terminology service to choose (as should be noted in the capability statement) that they populate the trusted expansion with a url that holds a persisted expansion resource for the returned expansion. This would allow requesters the ability to get the expansion without performing another $expand. This is something Peter suggested and while it's not directly aligned and may have some difficult implications, it's an interesting use.
Grahame Grieve (Jul 30 2020 at 23:10):
This would allow requesters the ability to get the expansion without performing another $expand
Don't understand why this is useful.
Grahame Grieve (Jul 30 2020 at 23:13):
cpg-computablevalueset
Don't understand why this profile is part of the discussion. nor do I understand why it exists, actually
Michael Lawley (Jul 30 2020 at 23:14):
Thanks for the summary @Robert McClure , unfortunately I was on another call at the same time.
Can you provide explicit examples of values for these extensions?
Michael Lawley (Jul 30 2020 at 23:16):
There's also http://hl7.org/fhir/R4/extension-valueset-expression.html which worries me - fine for documentation purposes, but I can see it being used as a proprietary crutch that blocks interoperability.
Robert McClure (Jul 31 2020 at 16:08):
@Michael Lawley The valueset-expression extension was originally created to meet the need of computably defining a value set content logical definition in the FHIR space that does not use the standard FHIR compose structure. I'm surprised you think this is "a crutch that blocks interoperability" when it is defined to be computable and requires the identification of the computable syntax used. FHIR's compose sytax is pretty thin and other terminology query systems exist (eg: TQL) or SQL queries against standard table structures (eg: RxNorm, UMLS, etc.) so providing a way to include those actually improves interoperability. Not everyone uses SNOMED CT that supports intra-FHIR compose approach that can utilize ECL.
Robert McClure (Jul 31 2020 at 16:15):
@Michael Lawley @Grahame Grieve and others: @Bryn Rhodes and I are working on improving the demonstrably incomplete documentation on the cpg value set profiles. I'll note that these are still in flux and include elements and MustSupport that I do not think belong in a general core profile, hence my statement above that trusted expansion should be consistent with (but note specifically use) the cpg profiles. We plan to improve upon the material at the FHIR Clinical Guidelines IG and will launch a zulip thread to open discussion on these ValueSet profiles once the documentation is up to snuff.
Grahame Grieve (Jul 31 2020 at 20:08):
perhaps better documentation will help me understand the purpose
Michael Lawley (Aug 01 2020 at 02:45):
By blocking interoperability, I mean that this extension imposes a requirement (or demand) on terminology servers to 1. use or re-implement SQL / TQL / other query language, and 2. use "standard table structures".
The alternative is to expose the required (by the SQL / etc) information in the CodeSystem itself, and to express the SQL etc using the compose syntax, which is actually pretty expressive. It would seem not unreasonable to attempt to do a standard mapping from RxNorm and UMLS file formats into FHIR CodeSystem so that all terminology servers can provide a consistent support at some established minimal level.
Michael Lawley (Aug 01 2020 at 02:47):
Looking at the ValueSets in the IG linked above, I see nothing that requires the valueset-expression extension -- I'd be interested to see some examples that involve queries that can't be expressed as a ValueSet.compose
Peter Jordan (Aug 01 2020 at 05:06):
Looking at the expressiveness of the ValueSet compose syntax, I note that multiple filters within a single compose.include are resolved using conjunction. However, I can't see any rules for how to handle multiple compose.include elements that each contain filters; although it might make sense to use disjunction?
Grahame Grieve (Aug 02 2020 at 21:37):
is this what you are asking about?
Multiple include statements are cumulative - e.g. the value set contains the union of all the includes
Within an include, all the criterion apply -e.g. the value set contains the intersection of the criterion
Grahame Grieve (Aug 02 2020 at 21:37):
?
Peter Jordan (Aug 02 2020 at 22:04):
Yes, thanks. Not quite sure how I missed those Composition Rules!
Robert McClure (Aug 03 2020 at 16:51):
@Michael Lawley So your answer to this is to force everyone to use FHIR compose or not use FHIR, right? I don't support such a hard-line take my ball and leave approach. I think allowing users to express how they actually created a member set using non-FHIR terminology server capabilities is actually useful and you might be surprised to discover that there are more people using SQL to create what we call value sets, then are using a FHIR terminology service.
As for examples, I have some Apelon TQL I can send but you are missing the point. I don't agree with your demand that everyone must use FHIR compose or they don't get to use FHIR.
Lloyd McKenzie (Aug 03 2020 at 17:57):
TQL is probably a reasonable ask. SQL is absolutely not. There's nothing interoperable about SQL because don't expect (or want) database designs to be consistent, and furthermore, allowing execution of arbitrary SQL on a server is something no sane DBA would ever allow. I do agree that using something like TQL for an expression that could be done using ValueSet.compose is an anti-pattern and should be strongly discouraged. However, allowing for it in an extension to support communication with systems that can't convert is reasonable (at least in some spaces), just as we allow folks to transmit CDA documents embedded in DocumentReference. You can't, however, expect that most terminology servers are going to pay attention to such extensions or do anything useful with them. For many, an extension with TQL will be no more computable than a value set defined in narrative.
Michael Lawley (Aug 04 2020 at 03:42):
I would argue that if all you are doing is wrapping a proprietary query in a FHIR ValueSet skin, then you are not "using FHIR". In my book, FHIR is about interop, so this approach is not in the right spirit. It's not that "you don't get to use FHIR" if you don't use compose, it's that there is limited _value_ to using FHIR if you don't use compose.
But, by all means, include the TQL as documentation; that is really valuable, and also useful to some if it's machine readable (not just replicated in the narrative, but at least include the pre-expanded ValueSet or an extensional definition.
One concern I have about TQL (based on things I seen in the context of LOINC), is that it still queries a proprietary data model, not something sanctioned by the code system publisher. The strength of the FHIR CodeSystem is that it provides a mechanism for having a consistent and agreed on API (table design) to the code system content.
My second concern is that I cannot find any documentation for it online.
However, if a language such as TQL is widely used, then it might make sense to make it a first-class citizen in the FHIR Terminology ecosystem, just like ECL is for SNOMED.
Grahame Grieve (Aug 04 2020 at 11:54):
you could use TQL in a filter just like ECL, but I'm not sure that it's standardised enough?
Grahame Grieve (Aug 04 2020 at 11:55):
but also, that's not what Rob's trying to do, from what he says. Obviously clearer documentation would help
Grahame Grieve (Aug 04 2020 at 11:55):
but @Robert McClure the expression extension seems far removed from the start of this conversation about trusted source
Peter Jordan (Aug 06 2020 at 23:44):
Grahame Grieve said:
This would allow requesters the ability to get the expansion without performing another $expand
Don't understand why this is useful.
Distributing expansions for IGs and Profiles?
Grahame Grieve (Aug 06 2020 at 23:57):
that's a provisioning question. Does it make any difference to the client?
Peter Jordan (Aug 07 2020 at 01:44):
It might make a difference to the application developers using an IG to have a consistent rendering of a complex ValueSet expansion.
Robert McClure (Aug 08 2020 at 23:24):
@Grahame Grieve @Lloyd McKenzie @Michael Lawley The issue with TQL vs ECL is that ECL can declare all operators within a single code system because that is all it's good for and it fits with the everything must be code system specific mindset of FHIR. TQL is code system agnostic and is not declared within a code system. I might not understand how FHIR works now, but I was under the impression that concept filters had to be declared within a code system. Not true?
Grahame Grieve (Aug 09 2020 at 19:55):
not quite true, no. A code system can define filters for use with the code system, but it's also possible for us to define filters that can be used against all code systems. And so we could choose to define a TQL query, if there was a standard to refer to. Or we could do it less formally if there was a less formal to base it on
Robert McClure (Aug 09 2020 at 23:21):
@Grahame Grieve @Carol Macumber I've asked to find an accessible TQL reference. So I take from your comment, there is no way to use TQL or any other general terminology query syntax other than FHIR compose but FHIR-I and Vocab are open to making some changes to the Filter element (specifically filter.property and filter.op) to support a more complex compose that matches what TQL would create? We need to add support what in SQL would be inner joins at least. I'd have to spend more time with this to be more clear but it would be a lot simpler to acknowledge that there are existing users that are interested in exchanging operable TQL even if others can't use it. The community certainly has no problem promoting ECL when very few can use that. I really don't see why there is such pushback on making value sets understandable and useful for users that can not get what they want using compose. If you refuse to accept an expression extensions, just assume it's rules-text. The only other outcome is all the logic used to craft an expansion is hidden in user files and they have to continue to make brittle enumerated compose.include when that brittleness is not clearly communicated.
Grahame Grieve (Aug 10 2020 at 00:57):
there is no way to use TQL or any other general terminology query syntax other than FHIR compose
I didn't say that. Nor did the committee. Michael pushed back on it, if people use a TQL expression in place of what can be said in a compose. Which I think is reasonable. But I think it's reasonable to allow people to exchange additional metadata about how they defined the value set, while not encouraging them to avoid actually defining them properly. From that regard, the definition of the extension and it's examples clearly need additional work.
But I think it's reasonable also to define how TQL could be used in a compose, which would have a different purpose and different ramifications. (Though I don't see how that relates to inner joins)
So: I don't think there's underlying disagreement here - we just need clarity in both the source definitions and this discussion
Michael Lawley (Aug 10 2020 at 22:55):
Michael pushed back on it, if people use a TQL expression in place of what can be said in a compose. Which I think is reasonable.
Exactly. I also asked for examples of things that can be said in TQL that could not be expressed (or are difficult to express) in a ValueSet.compose. It sounds like inner joins might be related to this?
Carol Macumber (Aug 11 2020 at 14:26):
@Michael Lawley , @Jessica Snell (Apelon), is going to post how to access the TQL Documentation and provide some examples
Jessica Bota (Aug 11 2020 at 14:56):
The Apelon TQL Documentation is available on the Documentation Downloads page at http://www.apelondts.org/Downloads/Documentation/tabid/137/Default.aspx. Access does require creating a free login to apelondts.org. I am working with our developer to get a list of TQL functionality that cannot be represented in FHIR and will be in touch.
Michael Lawley (Aug 11 2020 at 19:58):
Thanks Jessica - not sure how I missed this
Jessica Bota (Aug 11 2020 at 20:10):
Michael Lawley said:
Thanks Jessica - not sure how I missed this
It was posted in there this morning, so you didn't miss it! Let me know if you have any questions, happy to help.
Michael Lawley (Aug 13 2020 at 00:25):
So, I see from the documentation that TQL is a lot more than a query language -- it includes DML-like statements, IO statements etc.
Would it be reasonable to assume that only collection-statements are used for ValueSet definition? (and that such collection-statements do not themselves contain statements?
i.e., the grammar is effectively limited to:
collection-statement := FROM [ collection-mods ] collection “;”
Rob Hausam (Aug 13 2020 at 21:28):
This topic has moved on somewhat to the valueset-expression extension and TQL, but I'll move us back (at least for the moment) to the discussion of the proposed resolution text for J#23785. We looked at this again on the first 30 min. of the FHIR Tracker call today (ended early for the co-chair webinar) and came up with this update. We tried to take into account the most recent comments. This doesn't specify conformance to the cpg-executablevalueset and cpg-computablevalueset profiles, but I'm not sure that's a requirement (and if it is, it can be added)? It would be great to be able to get this issue resolved with a vote on the Vocab Main call next week.
Last updated: Apr 12 2022 at 19:14 UTC
