FHIR Chat · SNOMED CT filters · snomed

Stream: snomed

Topic: SNOMED CT filters

Dion McMurtrie (May 23 2018 at 02:45):

@Grahame Grieve we've beed discussing the SNOMED CT canonical CodeSystem resource at https://confluence.ihtsdotools.org/display/FHIR/SNOMED+CT+canonical+CodeSystem+resource.

One of the topics has been the filters, and the two filters "expression" and "expressions" came up. Firstly there was concern that these are very similar - one character different. We discussed potential name changes, conceding that the "expression" filter is already used a fair bit and it would be disruptive to change it.

However this led to a longer discussion about any practical use of, and the intent of the "expressions" filter. It seems to operate more like something that should be part of an expansion profile - whether to include post coordinated content in the expansion or not, which could come from a ValueSet or a ValueSet composed in as part of its definition.

We tried to find more about its intended use etc from the spec, but it tracks all the way back to early version and there's no tracker item we could find to help determine why it is there. It looks like it predates the expansion profile stuff.

Can you help with its history and any suggestions on what you think its future might be?

Thanks,
Dion

Grahame Grieve (May 23 2018 at 02:48):

I don't know how much it's used. But the idea for me is that very few people - experts only - will get into something like an expression constraint, or ECL, or whatever. But almost everybody is going to need to say 'I can't deal with expressions, don't give them to me'

Grahame Grieve (May 23 2018 at 02:50):

with regard to expansion profile Vocab decided in Cologne that this resource is going to be deleted - we're just going to take parameters. But I think that that this is value set thing, not a parameter - whether or not you wnat post-coordinated expressions is pretty fundamental to the way the value set is defined

Dion McMurtrie (May 23 2018 at 03:26):

Thanks, good to know about expansion profiles.

There's a couple of things at play here...

First the expression filter which allows you to define the content of a ValueSet using ECL - very, very useful. ValueSets can be defined using this that can then be combined more simply by other ValueSets using include and exclude which is more approachable. I don't think there's an issue here.

Second is whether a ValueSet contains post-coordinated expressions (i.e. not constraints which define a set, but post coordinated expressions each defining a concept). That can be declarative, or part of the expansion request at run time - i.e. "this ValueSet does/doesn't contain post-coordinated expressions" versus "expand this value set and do/don't give be post-coordinated expressions in the result if they are present in the expansion".

So with regard to this second point, which is really the issue, I don't think the current "expressions" CodeSystem filter achieves the aim. Depending upon which case we're trying to enable you could have

• a property of a ValueSet that indicates whether it does or doesn't contain post-coordinated expressions...you'd then expect its expansion to never contain them, but it does raise other validation questions. For example if ValueSet A declares post-coordination=false but it includes ValueSet B that contains post-coordination is that an error, or do those expressions just get filtered (perhaps silently?) at runtime. More rules would be required to define this behaviour and what is and isn't valid to do for predictability.
• a parameter for a ValueSet expansion which could optionally include or omit any pos-coordinated expressions...although excluding them if they've been designed into the content may not be a good thing and using that parameter might need to be cautioned with some forethought required

Are you thinking this is a declarative statement about the ValueSet (former) rather than parameter (latter), or both? Did you have thoughts on how this might work from a validation perspective? That's something we can also discuss further this week.

Dion McMurtrie (May 23 2018 at 03:31):

@Michael Lawley and @Jim Steel might also have opinions and might not have spotted this yet...

Michael Lawley (May 23 2018 at 03:55):

As I understand it, expressions is a filter, not a declarative statement at the ValueSet-level about the CLD; it is saying that this include (or exclude) allows (or not) post coordinated codes.

This is orthogonal to the client saying - 'don't give me any post coordinated things in the expansion'

I expect there's also another dimension which comes from the TerminologyCapabilities side where a server can say whether it even supports post coordination for a given CodeSystem

Grahame Grieve (May 23 2018 at 06:41):

There's a parameter on valueset/$epand: excludePostCoordinated - that's Dion's second.

Grahame Grieve (May 23 2018 at 06:41):

yes, it's a filter, not a declarative statement

Grahame Grieve (May 23 2018 at 06:43):

Michael's 3rd is TerminologyCapabilities.codeSystem.version.compositional

Peter Jordan (May 23 2018 at 20:29):

@Michael Lawley or @Dion McMurtrie do you have an example of a ValueSet containing post coordinated SCT expressions that you'd be willing to share? It would be extra helpful if this only contained concepts from the International Edition.

Michael Lawley (May 23 2018 at 23:17):

Not an in-the-wild / real-world one, no.

Dion McMurtrie (May 24 2018 at 01:03):

No, I don't have a real world example either.

So we have

• $expand: excludePostCoordinated for runtime expansion filtering of post coordinated expressions
• TerminologyCapabilities.codeSystem.version.compositional to declare a server's support for post coordination for a code system

From the discussion above we're missing (if we actually need it at all?) the ability for a ValueSet definition to declaratively say it doesn't (or does) contain post coordination. I'm not sure that the "expressions" filter is the right tool for that if we did decide we want to be able to say that, or if it is how it would work.

What is the intended use of the "expressions" filter? Is there an example of how it might be used?

Michael Lawley (May 24 2018 at 01:46):

Firstly, I'm not sure that a ValueSet needs to be able to say 'I do/don't contain post coordinated expressions'

Dion McMurtrie (May 24 2018 at 01:47):

No, I'm not sure it does either, but I'm keen to hear if anyone can come up with a use case for that.

Michael Lawley (May 24 2018 at 01:49):

Regarding examples for expressions, one might consider:

    "include": [
      {
        "filter": [
          {
            "property": "expressions",
            "op": "=",
            "value": "false"
          }
        ],
        "valueSet": [
          "http://snomed.info/sct?fhir_vs"
        ]
      }
    ]

which would mean all pre-coordinated SNOMED codes

But equally, that valueSet inclusion could be some other ValueSet instance that explicitly lists some pre- and post-coordinated codes

Michael Lawley (May 24 2018 at 01:49):

(It's actually a way of expressing excludePostCoordinated via a wrapper-ValueSet)

Michael Lawley (May 24 2018 at 01:54):

A usage scenario might be a search like /Condition?code:in=http://example.com/myPrimitiveCodesValueSet which would only find Conditions where the code was not post-coordinated. (I'm not sure why you'd want t do this)

Michael Lawley (May 24 2018 at 01:55):

and here's a more realistic definition for http://example.com/myPrimitiveCodesValueSet:

"include": [
      {
        "filter": [
          {
            "property": "expressions",
            "op": "=",
            "value": "false"
          },
          {
            "property": "concept",
            "op": "is-a",
            "value": "1234567"
          }
        ],
        "system": "http://snomed.info/sct"
      }
    ]

Grahame Grieve (May 24 2018 at 03:01):

the main use I thought it would have would be
- include all clinical findings
- but only pre-coordinated ones

Grahame Grieve (May 24 2018 at 03:03):

but it would make perfect sense to say
+ include all pre-coordinated liver disease concepts
+ these specific 2 post-coordinated codes
- 1 few specific pre-coordinated codes

Dion McMurtrie (May 24 2018 at 03:21):

and here's a more realistic definition for http://example.com/myPrimitiveCodesValueSet:

But isn't the expressions=false redundant in that definition? By definition SNOMED CT releases contain only precoordinated concepts, only instance data would contain post coordinated expressions, so if I expanded that definition I'd get no post coordinated expressions. I can only see expressions=false suppressing expressions that come from the inclusion of other ValueSet's content that contain explicitly enumerated expressions.

Aside from expansion...in the code:in example, the server would need to subsumption test all instances of Condition.code to be subtypes of 1234567 and be the most trivial expression - a single concept id - is that right? That's probably going to be much more expensive than expanding the ValueSet and joining it to the instance data, but expressions would never be properly supported that way. Is that your expectation of what servers do (or should do)?

But I guess this is the way to find all Conditions where the code is not precoordinated if that's a requirement, although I'm not clear why you'd want to do that?

Dion McMurtrie (May 24 2018 at 03:23):

@Grahame Grieve can't you define a ValueSet to include all pre-coordinated liver disease concepts plus a list of specific post-coordinated expressions minus a fee specific pre-coordinated codes entirely without using "expressions=false"?

Michael Lawley (May 24 2018 at 03:27):

If you look at what @Grahame Grieve 's server does when you try to expand http://snomed.info/sct?fhir_vs you'll see it refuses because it is technically unbounded - all codes in SCT includes all post coordinated codes.

Dion McMurtrie (May 24 2018 at 03:45):

Right...so expansion of all codes in SNOMED CT includes all possible valid post coordinated expressions, which is very big (but finite). Taking that to its logical extension...what if I expand

 "filter": [
          {
            "property": "concept",
            "op": "is-a",
            "value": "1234567"
          }
]

Does that also implicitly contain (and should return) all possible valid post coordinated expressions that evaluate as sub types of 1234567? That doesn't seem very practical.

Peter Jordan (May 24 2018 at 04:35):

Has anyone seen a post coordinated expression returned in response to a FHIR ValueSet $expand request and, if so, are they willing to share the request URL?

Grahame Grieve (May 24 2018 at 04:58):

my server will expand post-coordinateds if specifically defined by won't do as an expansion of a subsumption

Grahame Grieve (May 24 2018 at 04:59):

but to be clear: all clinical findings includes everything, not just pre-coordinated codes

Grahame Grieve (May 24 2018 at 05:00):

@Dion McMurtrie " can't you define a ValueSet to include all pre-coordinated liver disease concepts plus a list of specific post-coordinated expressions minus a fee specific pre-coordinated codes entirely without using "expressions=false"?" It's not obvious to me how without using ECL. And that alone would be justification for having it

Michael Lawley (May 24 2018 at 22:53):

but to be clear: all clinical findings includes everything, not just pre-coordinated codes

agreed, but this begs the question as to why your server returns the 'too costly' response for the 'all of snomed' ValueSet, but not for a ?fhir_vs=isa/[sctid] style ValueSet

Grahame Grieve (May 24 2018 at 22:55):

because my implementation is inconsistent

Grahame Grieve (May 24 2018 at 22:56):

and wrong in the second case

Michael Lawley (May 24 2018 at 23:01):

but pragmatic & useful

Grahame Grieve (May 24 2018 at 23:02):

don't agree. I should return too costly unless the client specifically says that it's ok to return a subset

Grahame Grieve (May 24 2018 at 23:02):

or unless we redefine the value set template

Michael Lawley (May 24 2018 at 23:06):

I don't think we should redefine the template

Grahame Grieve (May 24 2018 at 23:07):

I agree

Michael Lawley (May 24 2018 at 23:08):

I wonder how many systems would break if I "fixed" our server to enumerate the infinite set of codes (using paging)

Grahame Grieve (May 24 2018 at 23:08):

it sounds like fun watching you try

Michael Lawley (May 24 2018 at 23:17):

It would be enough to trivially enumerate the combinatorial explosion of |situation with explicit content| and >= 1 associated finding

Dion McMurtrie (May 28 2018 at 00:46):

so I my question

can't you define a ValueSet to include all pre-coordinated liver disease concepts plus a list of specific post-coordinated expressions minus a fee specific pre-coordinated codes entirely without using "expressions=false"?

I was referring to $expand, which probably hits at my confusion with this issue, compared to code:in

So my preconception was that if you're expanding a ValueSet against a SNOMED CT edition, then the expansion results contains only matching pre-coordinated concepts defined in that edition of SNOMED CT. Therefore saying "expressions=false" or "expressions=true" makes no difference to $expand, because the underlying code system doesn't statically define any expressions, unlike instance data which might.

I think there is a practical problem having "expressions=true" for $expand against something like a SNOMED CT edition (or UCUM too) and expecting that to contain not only every precoordinated code but every possible post-coordinated expression. I think technically it is a finite set, but it is pretty big, expensive to calculate and not very useful in the response of $expand. I think a response of too costly is fair enough in that context.

So for me the big question is should (if a server actually calculates it) a $expand of /ValueSet/$expand?url=http://snomed.info/sct?fhir_vs return only precoordinated things or all possible post-coordinated expressions as well? Ontoserver says this is too costly, but if a count=10 is added it returns a set with a total of 561,387 from SCT-AU, which is going to be the former, not the latter. I think that's sensible.

This begs the question, what is the default for "expressions" if no value is given? False I assume?

Perhaps that makes it OK...except that when doing code:in you more than likely want to find any instance data where the code _or expression_ matches the ValueSet definition.

Therefore the definition of the ValueSet that is useful most of the time in code:in isn't something that would lend itself to $expand. And if I'm right about the default value of "expressions" being false if not stated, most of the definitions for ValueSets for SNOMED CT floating around probably won't give people what they expect for code:in if instance data exists including expressions. If I'm wrong and the default is expressions=true then most of the server's expansion results are wrong at the moment, and a ValueSet defined and useful for code:in will be problematic for $expand.

Note this doesn't just affect SNOMED CT but code systems with grammars - what about UCUM for example?

My head hurts...what's the default for "expressions" if not stated and how is the difference between $expand and code:in use of a ValueSet definition reconciled with regard to the expressions filter and its behaviour?

Grahame Grieve (May 28 2018 at 05:30):

ucum is a bit different because most people just support a set of known expressions, but everyone actually supports expressions because you have no choice.

Grahame Grieve (May 28 2018 at 05:31):

the default value for expressions is true

Dion McMurtrie (May 28 2018 at 05:38):

so...that means that Ontoserver's expansion of SNOMED CT value sets is currently wrong, i.e. http://ontoserver.csiro.au/stu3-latest/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=isa/243796009 should actually return all possible post-coordinated expressions as well as all the precoordinated content as it currently does?

Michael Lawley (May 28 2018 at 05:40):

I could argue that we just support a set of known expressions

Dion McMurtrie (May 28 2018 at 05:41):

i.e. just the precoordinated ones?

I guess from an interoperability perspective this is a bit of an issue if server behaviour would vary that wildly

Michael Lawley (May 28 2018 at 05:44):

Fortunately(?), at the moment, most servers support the same set of known expressions.

Dion McMurtrie (May 28 2018 at 05:44):

i.e. none? (aka the precoordinated ones)?

Michael Lawley (May 28 2018 at 10:51):

Yes, the pre-coordinated ones :)

Michael Lawley (May 29 2018 at 21:23):

For clarity - I'm drawing an analogy here between servers supporting a 'known set of codes' in the infinite code system ucum, and the corresponding behaviour of supporting pre-coordinated concepts in snomed

Grahame Grieve (May 29 2018 at 21:25):

servers can do that, and they should declare that they do this in their terminology capabilities

Michael Lawley (May 29 2018 at 21:26):

More broadly, I think the key goals here are for interoperability of different terminology server implementations (so clients can have reasonable expectations), and usefulness of behaviour (if it's not useful, then why care).

So this leads me to the questions:
1. is it useful for a server to return TooCostly for expansion of http://snomed.info/sct?fhir_vs
2. is it useful for a server to return TooCostly for expansion of ValueSets like http://snomed.info/sct?fhir_vs=isa/1234567

Grahame Grieve (May 29 2018 at 21:28):

we say that if the server is not going to return the entire expansion, then it should return an error unless the client has advised that it's happy to get a partial expansion in the return. and then, when the server does return a partial, it must say that it's partial

Grahame Grieve (May 29 2018 at 21:29):

what we haven't said is whether the same rule applies for compositional grammars if the server declares that it does not support compositional grammar

Michael Lawley (May 29 2018 at 21:30):

which doesn't answer the question as to whether this is useful behaviour when the partial-ness is due to composition grammars

Grahame Grieve (May 29 2018 at 21:31):

well, things that are useful are sometimes unexpected. which means that different people have different views about it's usefulness

Michael Lawley (May 29 2018 at 21:31):

(aside: "support compositional grammar" is not a binary state)

Grahame Grieve (May 29 2018 at 21:31):

no it's not.

Grahame Grieve (May 29 2018 at 21:31):

but we've simplified it to that....

Michael Lawley (May 29 2018 at 21:34):

SNOMED ECL has the notion of a "substrate" - the context in which the ECL is evaluated. For a simple $expand, this would default to the pre-coordinated codes. But for a $validate-code or code:in search, it would (hopefully) include any actual post-coordinated expressions.

Michael Lawley (May 29 2018 at 21:37):

Isn't this a statement of the rule for compositional grammars?

If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension http://hl7.org/fhir/StructureDefinition/valueset-unclosed can be used to indicate that the expansion is incomplete

Michael Lawley (May 30 2018 at 01:18):

Another wrinkle/corner case - for code systems that support subsumption where there may be equivalent codes (and in the SNOMED case, this includes post-coordination, but there may be code systems with equivalent codes that don't have grammars). If a ValueSet includes one of these codes, should the expansion include the equivalent codes?

Robert McClure (May 30 2018 at 13:55):

Catching up on this and need some help figuring out the scope and boundries of the discussion: Are you all in agreement that a value set that has at least one concept drawn from a code system that is based on compositional grammar is in fact defining all potential equivalent post-coordinated expressions that could be made using the grammar, for every concept identified by the base CLD? If that is not where you are, then what are you in agreement on?

You might sense I don't think that should be the approach we take. In fact, I would say that a value set must explicitly define the exact grammatic expression that can be used to create post-coordinated expressions that are to be in the expansion. If you don't expressly include an expression as part of the CLD, then you can not get post-coordinated expansion members in the expansion.

Keep in mind the infamous 80% rule here...

Grahame Grieve (May 30 2018 at 13:58):

it depends how the value set is defined. If the value set is defined by enumerating codes, then this is not a discussion.

Grahame Grieve (May 30 2018 at 13:59):

but if the value set set says 'all clinical findings' then any post-coordinated expression that is a clinical finding is in the value set

Robert McClure (May 30 2018 at 14:20):

I think we need use carefully selected words here. what do you mean by "says all clinical findings"? Do you mean the CLD says (404684003 = Clinical finding):

<compose>
        <include>
            <system value="http://snomed.info/sct"/>
           <filter>
             <property value="concept"/>
             <op value="is-a"/>
             <value value="404684003"/>
          </filter>
        </include>
</compose>

because if that is what you all are agreeing to, I am not in agreement and am very concerned with this assumption for basic functionality.

Rob Hausam (May 30 2018 at 17:37):

Well, part of the issue is that "is in the value set" in this case isn't entirely clear and has some context dependency. Some of the related discussion on the SNOMED on FHIR call yesterday (and maybe also elsewhere?) was that there likely needs to be different expectations depending on, in particular, if we are talking about the behavior for $expand vs. $validate-code. The discussions seemed to be leaning toward for $expand to only return the published codes or expressions (assuming that sometimes expressions may be published), so in that context only those officially published artifacts would be considered to be "in" the value set, but for $validate-code the desired behavior would be to recognize any valid post-coordinated expression (user created, typically) that logically meets the criteria of the definition (VSD) as being valid and therefore "in" the value set. I think that may be a useful approach, and we need to consider it in our discussion and any decisions that we make. @Robert McClure, I'm not sure if or how that affects your disagreement or agreement with what Grahame said?

Grahame Grieve (May 30 2018 at 19:52):

@Robert McClure , are you claiming that post coordinated expressions cannot have an is-a relationship with clinical finding? (I hope not)

Peter Jordan (May 30 2018 at 20:05):

I would still like to see actual examples of a SNOMED CT Reference Set, or FHIR Value Set, containing post coordinated expressions. From an implementation perspective, until it's clear how this content is actually requested by, and delivered to, clients, post coordination remains one of those things that people talk about, but nobody actually does!

Grahame Grieve (May 30 2018 at 20:24):

we have examples, mostly involving laterality

Peter Jordan (May 30 2018 at 20:59):

Where - any links?

Grahame Grieve (May 30 2018 at 21:12):

I don't think they're public... unless the agency wants to publish any - I just don't think they've moved past concept stage on this (@Dion McMurtrie - there's some implicit value sets like this in the CDA specs, but we haven't turned them into real fhir value sets)

Robert McClure (May 30 2018 at 22:15):

@Grahame Grieve No, I'm not saying that at all. What I'm saying is something aligned with what @Rob Hausam is referring to: I.E.: the set of members in a value set expansion should be "well defined" and I agree with the proposal Rob outlines for $expand. If the approach is to have a different behavior for $validate-code then I find that interesting but worry that it will mean lots of variation across FHIR servers because very few would ever try to validate any possible expression that "belongs in the value set." In particular if we go beyond testing for exact expression equivalence - by this I do not mean subsumption/is-a - when testing an expression as a member of a value set, I have real concerns. This will muddy the water with what is actually a member of the value set, I.E.; the expansion set. Rob - was the discussion about $validate-code interested in testing for subsumption, or for testing equivalence? I'm fine with it supporting the latter including expressions. I'm not fine with the former. That should be a different operation, #subsume?

Grahame Grieve (May 30 2018 at 22:27):

I think that's all confused. If the definition of a value set is "all concepts that have an is-a relationship with X", then the membership of the set is is "all concepts that have an is-a relationship with X' and the correct expansion is all those concepts

Grahame Grieve (May 30 2018 at 22:27):

I don't see the equivalence issue has to do with this?

Grahame Grieve (May 30 2018 at 22:28):

but all this is why there's a filter for snomed to say 'no expressions', because expressions are difficult and not well supported, and if you mean 'no expressions' you should just say so, and we could stop circling on this

Rob Hausam (May 30 2018 at 22:33):

Yes, I was just getting ready to say something similar. Most of the time with intensional definitions we will be dealing with subsumption. And some systems can or will be able to support that with expressions.

Peter Jordan (May 30 2018 at 22:51):

Looking at Section 4.2.1.0.7 of the spec "SNOMED CT Filters" @Rob Hausam, just to be 100% clear, are you referring to intensional definitions that are expression constraints (4.2.1.0.7.3) in addition to those that are simple is-a operations (4.2.1.0.7.1)?

Michael Lawley (May 31 2018 at 00:01):

@Grahame Grieve are you saying that for a ValueSet, urn:vs, that is defined as including the specific code 74400008 |Appendicitis|, then a search for /Condition?code:in=urn:vs and a Condition resource that has code = 64572001:{116676008=23583003,363698007=66754008 it would not be a match? i.e., :in semantics is about lexical code matching and not code equivalence? (This seems to be what @Robert McClure is advocating if I understand correctly.)

Grahame Grieve (May 31 2018 at 07:52):

if the definition of the code system is based on subsumption testing, then the test should be based on subsumption so that should be a match

Grahame Grieve (May 31 2018 at 07:52):

that's my personal opinion. Unless the value set says that it doesn't include post-coordinates.

Michael Lawley (May 31 2018 at 08:10):

phew - I was expecting it should be a match

Robert McClure (May 31 2018 at 15:45):

@Grahame Grieve Let's make sure we are talking about like things. To be sure, you understand that in compositional code systems there is a difference between expression equivalence and subsumption, right? A value set CLD is defining a query to find all the concepts in the namespace that are equivalent to the expression in the CLD. Set aside the idea of a CLD using subsumption, that is secondary to the point I'm making because it's simply a (very) special case of graph traversal that includes transitive closure as a way of defining "equivalence" (you might think that's a stretch but let's just assume it's one way of saying this.) So, for a CLD that does not use subsumption, and the value set "supports the inclusion of expressions as members in the expansion" we would say that any concept with a normal form that is equivalent to the expression in the CLD, should be a member of the expansion (ie, is in the value set.) This is complicated by the structure of the CLD, but one way to think of it is find all the precoordinated concepts, transform them to normal form, then any expression that can also be transformed to a normal form you already have, is also a member. If you add into the mix a CLD that includes subsumption, then you would first define the subsumption root into normal form, then include all concepts that have an equivalent normal form or one that is subsumed as members. BUT remember that SNOMED CT (not sure how this plays out in UCUM) is not well formed because there are many primatives that screw with using normal form as the only source for determining concept "inclusion" so you'd really have to go get all the subsumed precoordinated concepts and do this normal form comparison for each one. At least that is my understanding - @Michael Lawley am I not understanding how this would work?

Grahame Grieve (May 31 2018 at 20:35):

I think it depends how it's defined. if the definition is by enumeration, then equivalent expressions would not be in the value set, just like aliases would not be in the value set

Grahame Grieve (May 31 2018 at 20:35):

if the definition is 'all codes = to this code' then they would be in the value set

Michael Lawley (May 31 2018 at 22:18):

@Grahame Grieve the catch for me here is the (apparently) subtle differences between the semantics of $validate-code(code,valueset), is code a member of $expand(valueset), and the search code:in=valueset (for code systems supporting composition or other aliasing that allows for code equivalence).

Michael Lawley (May 31 2018 at 22:22):

@Robert McClure for me, equivalent codes are any codes A and B such that the subsume each other. Converting to normal form works for some kinds of subsumption semantics, but not all; it is a form of structural subsumption. It used to be sufficient for SNOMED, but is no longer a sufficient mechanism.

Michael Lawley (May 31 2018 at 22:23):

Also, I don't understand your claims about SNOMED being not well-formed.

Robert McClure (May 31 2018 at 22:33):

@Michael Lawley To be clear, you are saying A subsumes B AND B subsumes A == Equivalent. You are also saying that if A subsumes B AND NOT B subsumes A, meaning B is a descendant of A, they are NOT equivalent. Correct?

Michael Lawley (May 31 2018 at 23:04):

Yes for the first case. The second case may depend on whether you have open or closed world semantics in effect. That is, you may know that A subsumes Band also not be able to infer that B subsumes A, but that's not the same as knowing NOT B subsumes A. That is, just because you can't prove something doesn't make it false. So, all you can conclude is that you don't know the equivalence status of A and B. Of course, the effect is then the same.

Peter Jordan (Jun 01 2018 at 01:22):

Are there any equivalent pre-coordinated concepts in the International Edition of SNOMED CT? In the generated transitive closure table, I don't see any instances where one concept is both the subtype and supertype of another concept.

Michael Lawley (Jun 01 2018 at 01:24):

SNOMED International has an editorial rule that this will never be the case (for active concepts). If it happens, then they retire one concept and add an entry in an historical-association map.

Robert McClure (Jun 02 2018 at 20:42):

@Michael Lawley My point was to clarify where it is provable that B is subsumed by A, as is true for all the current hierarchies in published SCT. This get's back to the original $expand and what concepts are members. In re-reading I may have mis-stated my position. I would agree that if the CLD has an "is-a" in the compose, then any concept that is subsumed by that concept is in the expansion and the only way to not have to deal with expressions right now is to set excludePostCoordinated as T in the $expand operation. Seems to me we might want to add another element in Compose that is the same thing (default to T if that is possible) so that default behaviors would be tractable. Does that make sense?

My concern in this discussion is that we agree that only by including transitive closure requirement inside the compose (op value="is-a"/ or similar) can subsumed expressions be included within the expand. All other expressions will be exactly equivalent to a defined value set member using the A>B and B>A test.

Grahame Grieve (Jun 02 2018 at 21:00):

Actually, we already have such a control in compose, and we are discussing it's use

Robert McClure (Jun 04 2018 at 23:36):

What control? I don't see it in the spec.

Grahame Grieve (Jun 04 2018 at 23:38):

http://build.fhir.org/snomedct.html#4.2.1.0.7.4

Robert McClure (Jun 05 2018 at 20:07):

Ok, yes, I've gotten lost as we have wandered a bit in this discussion and I was lost: "Expressions" is available for SCT in compose. So I assume that if this is not included in the compose, then the value set MUST generate post-coordinated expressions in the $expand? I have to admit, making "Expressions" a filter is a bit weird because it normally would apply for the entire compose but that would not be true of other filters would it?

Peter Jordan (Jun 05 2018 at 20:29):

@Robert McClure - are you referring to SCT expressions or expression constraints? From a practical perspective, I'm still trying to ascertain where an implementer might find post-coordinated expressions. So far, no one has been able to show me an instance of a SNOMED CT Reference Set or a FHIR Value Set that contains post-coordinated expressions.

Rob Hausam (Jun 05 2018 at 22:55):

I agree with what I think @Robert McClure is questioning regarding how we understand and use the "expressions" filter and what it means if it is or isn't present and whether its value is true or false within one or more instances of 'include' or 'exclude' in ValueSet.compose. I expect we have a fair bit more work to do to understand and explain it (among ourselves and to others).

Peter Jordan (Jun 05 2018 at 23:23):

Which SCT filter is being discussed here - 4.2.1.0.7.3 By SNOMED Expression Constraint (property name ="constraint") and/or 4.2.1.0.7.4 By whether post-coordination is allowed (property name = "expressions")?

Rob Hausam (Jun 05 2018 at 23:50):

I was referring to 4.2.1.0.7.4

Grahame Grieve (Jun 06 2018 at 03:09):

you'd mix filters. e.g. this value set includes (clinical findings + expressions = true), then that includes post-coordinated expression as well as pre-coordinated ones. Where as (clinical findings + expressions = false) means that post-coordinated expressions are not allowed.

Grahame Grieve (Jun 06 2018 at 03:11):

http://build.fhir.org/snomedct-usage.html - there's no post-coordinated value sets. the Australian CDA specs have one for laterality

Michael Lawley (Jun 06 2018 at 06:31):

Which CDA spec is that?

Grahame Grieve (Jun 06 2018 at 06:48):

discharge summary? Note that it doesn't feature in the value set in the CDA framework but it would in the FHIR equivalent

Michael Lawley (Jun 06 2018 at 06:51):

@Peter Jordan Is this the sort of thing you want?

{
  "resourceType": "ValueSet",
  "url": "urn:postcoordination-test",
  "version": "0.0.1",
  "name": "ValueSet with post coordination",
  "status": "draft",
  "compose": {
    "include": [
      {
        "system": "http://snomed.info/sct",
        "concept": [
          {
            "code": "71341001:272741003=7771000",
            "display": "Left femur"
          }
        ]
      },
      {
        "system": "http://snomed.info/sct",
        "filter": [
          {
            "property": "concept",
            "op": "is-a",
            "value": "71341001"
          },
          {
            "property": "expressions",
            "op": "=",
            "value": "false"
          }
        ]
      }
    ]
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>ValueSet with post coordination</h2><tt>urn:postcoordination-test</tt></div>"
  },
  "experimental": true,
  "publisher": "CSIRO"
}

Grahame Grieve (Jun 06 2018 at 06:54):

that's an interesting combination....

Grahame Grieve (Jun 06 2018 at 06:54):

but a good test case for expansion - @Rob Hausam can we capture this for the connectathon?

Michael Lawley (Jun 06 2018 at 06:54):

ValueSet above = femur, all (pre-coordinated) sub-types, plus left femur (post-coordinated)

Michael Lawley (Jun 06 2018 at 06:56):

Here's another

{
  "resourceType": "ValueSet",
  "url": "urn:postcoordination-test2",
  "version": "0.0.1",
  "name": "ValueSet with post coordination - 2",
  "status": "draft",
  "compose": {
    "include": [
      {
        "system": "http://snomed.info/sct",
        "filter": [
          {
            "property": "concept",
            "op": "is-a",
            "value": "71341001:272741003=7771000"
          },
          {
            "property": "expressions",
            "op": "=",
            "value": "true"
          }
        ]
      }
    ]
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>ValueSet with post coordination</h2><tt>urn:postcoordination-test</tt></div>"
  },
  "experimental": true,
  "publisher": "CSIRO"
}

Grahame Grieve (Jun 06 2018 at 06:59):

right. no way to enumerate that, but you can test membership

Peter Jordan (Jun 06 2018 at 07:54):

Interesting examples @Michael Lawley! I'm not quite sure if expanding the second example would produce anything other than a post coordinated concept that matches the expression in the filter value?

Rob Hausam (Jun 06 2018 at 14:40):

@Michael Lawley You described the second one as "femur, all (pre-coordinated) sub-types, plus left femur (post-coordinated)" - I think that's not quite what you intended to say (or I'm misunderstanding how we/you think the expressions filter works)?

Robert McClure (Jun 06 2018 at 15:02):

@Peter Jordan when I say SCT expressions, I mean post-coordinated expressions as ways of representing clinical information in a patient record, and therefore would be of use as a single "concept" in a value set. When I say expression constraint statement, I'm think of those occurring all the time in a value set CLD - it would be the way we define the value set membership, i.e.; a refset definition. But these things are all so squishy in the theoretical space because of all the things 'one could do' when using expression-based statements and the exact same expression constrain could be used in both places. I'm not sure how to definitely make a clean separation.

Michael Lawley (Jun 06 2018 at 19:56):

@Rob Hausam sorry, that was a description of the first ValueSet

Peter Jordan (Jun 06 2018 at 22:47):

Thanks @Robert McClure. The distinction is reasonably clear to me...
SCT expression = definition of an individual concept
SCT expression constraint = computable rules to define sets of concepts - invoked by Expression Constraint Language (ECL) queries
The problem is when the term "expression" is used to cover both cases (and I'm a guilty party here) and, unless the upcoming SNOMED Query Language subsumes ECL, then this will continue to cause issues between terminologists and implementers.

Grahame Grieve (Jun 06 2018 at 22:49):

I don't mind if we want to clarify the terminology but I think that we need the functionality

Dion McMurtrie (Jun 07 2018 at 07:26):

I don't think they're public... unless the agency wants to publish any - I just don't think they've moved past concept stage on this (@Dion McMurtrie - there's some implicit value sets like this in the CDA specs, but we haven't turned them into real fhir value sets)

WRT to SNOMED CT the short answer is no, all the value sets being used for bindings are implicit value sets referring to reference sets in SNOMED CT-AU. There is a grow set of other value sets https://api.healthterminologies.gov.au/integration/v2/fhir/ValueSet

There's also somewhat of an anti pattern there, in that the implicit value set http://snomed.info/sct?fhir_vs=refset/32570071000036102 is what has been used, but for the purposes of expressions in code:in and validate-code we really mean http://snomed.info/sct?fhir_vs=ecl/<<(^32570071000036102) . That is all concepts/expressions subsumed by the concepts in the reference set, not just the set of concepts in the reference set itself...but that's a whole other discussion.

Dion McMurtrie (Jun 07 2018 at 07:30):

I think it is worth coming back to the original discussion which is what is practical and useful to do with $expand and expressions, versus $validate-code or code:in. I think it is reconcilable.

There are two possible positions for what $expand against http://snomed.info/sct?fhir_vs=isa/404684003 (clinical finding) should return
1. all pre-coordinated concepts in the SNOMED CT version the terminology server has loaded that are sub types of 404684003
2. all pre-coordinated concepts in the SNOMED CT version the terminology server has loaded that are sub types of 404684003 and all possible post-coordinated expressions valid for the SNOMED CT version's grammar and pre-coordinated content that are sub types of 404684003

I think 1 is practical and useful - in fact that's what most of the servers around actually do and are used for right now.

I think 2 isn't practical (calculating all the possible valid expressions wouldn't be easy and would be expensive), and isn't useful (what would the use case be for getting all the possible post-coordinated expressions?).

I don't think anyone (I hope) is arguing about the behaviour of $validate-code or code:in - they should admit or return true for any expression that meets the definition of the ValueSet. In this example, if an expression is a subtype of 404684003 $validate-code should return true, code:in should admit it. The filter "expressions=false" can be used by the ValueSet definition to explicitly prevent this, although I'm not really clear why someone would want to (I don't mean by that there isn't a good reason, I just don't know it).

To me this is down to the definition of what we are asking $expand to do. In my mind behaviour 1 above is justifiable because we are asking the server to expand the definition of the ValueSet against a specific version of the terminology (even if we don't specify one the server must pick one). That specific version of the terminology has a set of statically published content and that forms the "substrate" (as @Michael Lawley referred to it as) for the expansion.

So it seems entirely reasonable that the definition of $expand be that a server applies the rules in the ValueSet definition to that set of statically published content and returns what matches. For Michael's example that explicitly included a specific post-coordinated expression in the ValueSet definition, I'd expect to get that back too. If SNOMED CT started to publish a library of statically defined post-coordinated expressions, I'd expect to see them in the result too...but not any possible post-coordinated expression given the grammar and content.

For $validate-code and code:in the context is different. They are being passed some finite set of instance data to test against the ValueSet definition which may or may not contain post-coordinated expression. I think (hope) we are all on the same page with this part...

Grahame Grieve (Jun 07 2018 at 07:38):

so it might just be terminology, but there has seemed to be a deeper disagreement than this.

Grahame Grieve (Jun 07 2018 at 07:38):

for instance, there was a question about whether post-coordinated terms were even 'in' the value set

Grahame Grieve (Jun 07 2018 at 07:39):

if we want to say that in cases where a SNOMED CT value set allows a grammar, expand is implicitly known to return a subset, and the client doesn't need to say explicitly that that's ok, well... ok. I can deal with that.

Grahame Grieve (Jun 07 2018 at 07:40):

but we should not say that this is a property of $expand itself, since I think that would be a wrong thing in some other code systems that have grammar.

Grahame Grieve (Jun 07 2018 at 07:40):

but if we say that a server can not return some of the members of the value set, is a server now wrong if it does choose to post-coordinate and return some of them?

Dion McMurtrie (Jun 07 2018 at 07:42):

I think at the last SNOMED CT FHIR meeting we were looking for consistency and utility, and where we landed was that $expand makes sense to evaluate against the static content of the code system, while code:in and $validate-code are being asked a different question which was already constrained to a finite set of post-coordination.

Grahame Grieve (Jun 07 2018 at 07:43):

so you're saying that a server cannot return any post-coordinated content that is not explicit in the value set? that sounds ..... difficult.

Dion McMurtrie (Jun 07 2018 at 07:44):

We did agree that for UCUM for instance that there was a set of well known expressions that servers actually currently implement - but it isn't the complete set of all possible UCUM expressions (because that isn't useful). So we agreed it would be useful to specify this set to give clients and servers some consistency.

Grahame Grieve (Jun 07 2018 at 07:44):

"we"? SNomed CT is making rules about UCUM?

Grahame Grieve (Jun 07 2018 at 07:45):

and it might be useful, but it would be rather dificult.

Dion McMurtrie (Jun 07 2018 at 07:45):

LOL, no, "we" that SNOMED FHIR group has no powers over anything - even SNOMED CT and FHIR

Grahame Grieve (Jun 07 2018 at 07:46):

I think it might have some influence there

Dion McMurtrie (Jun 07 2018 at 07:46):

We were discussing the behaviour generally and trying to determine what was useful for a terminology server to do. We were looking for some sort of consistency which may help server implementers and server clients - and the interoperability of them

Grahame Grieve (Jun 07 2018 at 07:47):

well, i challenge that notion with regard to UCUM: can anyone identify this 'set of well known expressions'?

Dion McMurtrie (Jun 07 2018 at 07:47):

if I expand the same ValueSet definition against two different terminology servers loaded with the same terminology versions I'd like to think we shoot for the position where I'd get the same result (maybe different order but same overall expansion content)

Dion McMurtrie (Jun 07 2018 at 07:48):

Sure, I'm far from a UCUM expert, but we were searching for what could possibly be defined in an effort to bring consistency and predictability

Grahame Grieve (Jun 07 2018 at 07:48):

because all roads will lead to one of 3 places:
- the infoway one (with errors)
- the loinc one(with errors)
- the one I build fro them and the google data set that is not otherwise published. and for which I have received 0 comments

Grahame Grieve (Jun 07 2018 at 07:49):

so I don't think either of the 3 of them have production use

Dion McMurtrie (Jun 07 2018 at 07:49):

I'd actually say pick one, put it in the spec and change manage it based on feedback - better a consistent list that people disagree about than fragmented confusion

Grahame Grieve (Jun 07 2018 at 07:50):

I think if w're going to say: don't return post-coordinated terms unless... X.... that will be a problem twice over: once getting a useful definition of X and then finding all the things that breaks over time

Dion McMurtrie (Jun 07 2018 at 07:50):

I think it is more we are saying that when you $expand you are expanding against something - return all the things predefined in that something.

Grahame Grieve (Jun 07 2018 at 07:51):

the 'predefined' is the problem. it isn't what we said until now, and the 'something' is a problem

Grahame Grieve (Jun 07 2018 at 07:52):

and I think it's critical to know: is this $expand that I have, is that all the valid codes, or just some of them? so to this point, we've said:
- if the client doesn't ask, it gets all or an error
- the client says it's ok, the server can return a subset for practical reasons, with a clear indication that it's a subset

Grahame Grieve (Jun 07 2018 at 07:52):

and then the server can choose the grounds on which it's a subset.

Grahame Grieve (Jun 07 2018 at 07:53):

I don't see why this isn't an acceptable solution for expanding and post-coordinates in SCT value sets

Dion McMurtrie (Jun 07 2018 at 07:53):

well the something is possibly code system dependent, but there's already different definitions for specific well known code systems. For SNOMED CT we're proposing (we being the people on the call last week, not a formal group) that be all the statically published pre-coordinated concepts in the SNOMED CT version that is the subject of the expansion....if SNOMED CT adds libraries of expressions in publications in the future that may need to be revisited.

Dion McMurtrie (Jun 07 2018 at 07:56):

I think this is an issue because people definitely have use cases for getting the pre-coordinated content that matches a ValueSet definition.

We've not yet heard of any real use cases for getting all possible post-coordinated expression matching the ValueSet definition...and yet that's the default, or rather an error message is, as no server is actually going to return all the post-coordinated expressions - it is too expensive and not useful.

Dion McMurtrie (Jun 07 2018 at 07:58):

It also isn't a subset, depending upon the way you want to look at it. It is likely a complete set of the matching pre-coordinated codes in the relevant SNOMED CT version...which is of course a subset of all of the possible post-coordinated expressions which we're pretty sure the client doesn't want

Grahame Grieve (Jun 07 2018 at 07:58):

and so there's a way to get all the pre-coordinated content

Dion McMurtrie (Jun 07 2018 at 07:59):

yes, but the intuitive thing to do (that most of us have been doing naively without knowing until now) results in an error

Grahame Grieve (Jun 07 2018 at 07:59):

and I can see why you'd say that getting an error for value sets that might include post coordinated terms if less than optimal, but replacing it with a rule that you can't include them is must less optimal

Dion McMurtrie (Jun 07 2018 at 08:00):

what is the use case for including all possible matching post-coordinated expressions for a ValueSet definition in an expansion?

Dion McMurtrie (Jun 07 2018 at 08:00):

it would make sense (to me) for that to be the non-default behaviour activated by an optional parameter that most servers are going to respond to with an error

Grahame Grieve (Jun 07 2018 at 08:05):

I'm ok in principle with it not being the default behaviour. But I don't see a clear path to a specified behaviour that is safe and predictable and reasonable. I believe that the current behavior is safe and predicable but not reasonable. I'm not really interested in giving up safety and predictability though

Grahame Grieve (Jun 07 2018 at 08:06):

in particular, laterality is where I'm going to hang my hat on. If a server identifies that a concept has laterality, it should be at least able to auto-post-coordinate that term with left and right. (if not should outright)

Dion McMurtrie (Jun 07 2018 at 08:08):

OK...but there goes predictability. Where's the set of things that should and shouldn't be auto-post-coordinated? If you do laterality and don't do others, what does the absence of those others in the result mean to the client and how does it know?

How does the client even use the auto-post-coordinated lateralised expression? What's the use case?

Dion McMurtrie (Jun 07 2018 at 08:09):

I'm also not really sure about the safety angle, can you elaborate on that too?

Grahame Grieve (Jun 07 2018 at 08:14):

unpredictable = unsafe. Though if the only predictable option is also not useful, I think that's a shallow victory at best

Grahame Grieve (Jun 07 2018 at 08:15):

so not as significant as I first thought

Grahame Grieve (Jun 07 2018 at 08:15):

still... I remain concerned about this, and banning post-coordination isn't making me happy

Dion McMurtrie (Jun 07 2018 at 08:16):

I think that's what we're shooting for too, predictable, but perhaps we're coming at it from different angles? Maybe talking about it in person at the next SNOMED CT FHIR call on Wednesday morning may be easer to make faster progress?

Dion McMurtrie (Jun 07 2018 at 08:19):

BTW the aim isn't to ban post-coordination. It is to make the default behaviour of servers useful, tractable and predictable for server implementers and clients, otherwise we lose interoperability...and possibly safety as you mentioned.

Grahame Grieve (Jun 07 2018 at 08:22):

I can join next week.

Dion McMurtrie (Jun 07 2018 at 08:29):

ok great - anyone else on this thread that's interested is of course welcome. It is an open group
Tuesday 12th 20:00 UTC for 90 minutes
Online: https://snomed.zoom.us/my/snomedhl7
Phone: See https://zoom.us/zoomconference for available phone numbers (meeting id 242-348-6949)

Dion McMurtrie (Jun 07 2018 at 08:30):

There's usually a meeting page which hasn't been created yet at https://confluence.ihtsdotools.org/display/FHIR/2018+Meetings with the details too @Peter Williams or @Rob Hausam can maybe post that when it is up?

Michael Lawley (Jun 07 2018 at 08:57):

and I think it's critical to know: is this $expand that I have, is that all the valid codes, or just some of them? so to this point, we've said:
- if the client doesn't ask, it gets all or an error
- the client says it's ok, the server can return a subset for practical reasons, with a clear indication that it's a subset

Just catching up on the thread here - it seems to me that the only real dispute here is whether the default should be client has to choose, or server gets to choose if client doesn't specify.

The key thing for me is that the client needs to be able to say "I'm happy with a (server defined) subset" without being forced to say/only being able to say "Only give me pre-coordinated things". At the moment there is limitedExpansion and excludePostCoordinated (in R4) which seems to cover it. However, most servers seem to, in most cases, behave as though limitedExpansion defaults to true rather than false

Michael Lawley (Jun 07 2018 at 08:59):

@Grahame Grieve your laterality example is good - I had been toying with something like this myself

Michael Lawley (Jun 07 2018 at 09:03):

The only thing that slowed me down was something in the spec that I remember (I can't find it just now) that seemed to say that post coordinated codes don't / can't have display text

Grahame Grieve (Jun 07 2018 at 09:05):

what we say is that they're not defined. If SCT wants to define them... sensational

Michael Lawley (Jun 07 2018 at 09:06):

It would be. Would it also be okay if a terminology server did its own thing in the meantime?

Grahame Grieve (Jun 07 2018 at 09:07):

sure, here's what we do say:

SNOMED International does not define terms for expressions. If a SNOMED terminology producer publishes human-readable terms for expressions in an expression repository, this term may be used as the display. Similarly, if a SNOMED terminology producer publishes an official template for generating terms from an expression, a term generated using the template may be used as the display. If no term or description template has been published, the full expression with terms embedded may be used

Grahame Grieve (Jun 07 2018 at 09:07):

given that... we don't say anything about not doing anything

Michael Lawley (Jun 07 2018 at 09:08):

I can work with all of that

Rob Hausam (Jun 07 2018 at 15:31):

Here's the page for next week's SNOMED on FHIR Terminology Services call:
https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=64260509

Peter Jordan (Jun 08 2018 at 00:28):

Some random comments on post-coordination (but not a vote for abolition)...

• Laterality is an interesting choice as the 'poster child' for post-coordination given that there are now around 4,700 active pre-coordinated concepts in the 20180131 version of International Edition of SCT with laterality attributes - although I'm not sure if that's actually a drop in the proverbial ocean.
• From an EHR/PHR UI perspective - without a human readable term, post-coordinated concepts have little value.
• Many/most/all client systems will have to make significant changes to handle post-coordinated concept identifiers.
• Once equivalence testing requires the use of a classifier, it's hard to envisage endpoint systems creating their own post-coordinated expressions without a Terminology Server.
• The big challenge, as I see it, for the Terminology Server developers is to figure out a way to persist post-coordinated expressions alongside RF2-formatted content in a way that facilitates single queries to implement $expansion requests. I'm guessing that's one of the things that @Michael Lawley is working on and it will be good to discuss this at the upcoming HL7NZ Event. My initial thought, for a RDBMS schema, is to treat it as a local concept with it's own SCTID and add a nvarchar(max) field to the Concept Table to hold the expression.
• I wonder if anyone has tried to perform a $lookup operation on a post-coordinated SCT concept?

Grahame Grieve (Jun 08 2018 at 00:32):

I haven't really gone through and implemented post-coordination. but with regard to this:

Many/most/all client systems will have to make significant changes to handle post-coordinated concept identifiers.

Not if they're using a terminology service. If you're using a terminology service that handles it, then that's completely opaque to you

Grahame Grieve (Jun 08 2018 at 00:33):

The big challenge, as I see it, for the Terminology Server developers is to figure out a way to persist post-coordinated expressions alongside RF2-formatted content

Depends how you implement - for me, it's a logic challenge not a persistence challenge. but why not go through and generate a bunch of relevent/likely post-coordinations....

Peter Jordan (Jun 08 2018 at 00:34):

Agree that post-coordination requires the use of a terminology service - but if an NZ General Practice PMS receives a post-coordinated SCT code in a GP2GP transfer, it will break the bank.
Not sure if your implementation of SCT is typical :). If there are obvious candidates for post-coordination, surely they should be promoted to pre-coordinated concepts in the International Edition?

Grahame Grieve (Jun 08 2018 at 00:37):

if we move systems to using terminology servers, then that will no longer be true. but since it is currently true, that's why you can specify value sets and say that they do not include post-coordination

Michael Lawley (Jun 08 2018 at 00:38):

@Peter Jordan why the need to allocate a local ID? the expression is its own identifier. ie. it is the local code

Peter Jordan (Jun 08 2018 at 00:41):

@Michael Lawley - it might be neater to use a 19 character SCTID for linking to the other RF2 tables, rather than a long expression. I struggle to see a long post-coordinated expression as an identifier - makes a GUID look elegant!

Michael Lawley (Jun 08 2018 at 00:43):

URIs are identifiers and often very long; if you need to "understand" the identifier (expression), then that's what the services part of Terminology Services provides

Michael Lawley (Jun 08 2018 at 00:48):

Can you tell me what specifically would be improved by using a 19char SCTID?

Grahame Grieve (Jun 08 2018 at 00:48):

consistent internal indexing?

Michael Lawley (Jun 08 2018 at 00:52):

Is that something to do with having a bounded length? That's normally solved with a good hash algorithm, and it's should also be a low-level implementation detail

Peter Jordan (Jun 08 2018 at 00:59):

I've had a career-long preference for surrogate primary keys in RDBMS. Even though there are meaningful elements in SCTIDs, they are strong candidates for primary keys - IMHO, post-coordinated expressions are poor candidates (and are they guaranteed to be immutable??). BTW, had a re-think on where I would store the expression, within the RF2 format - as the Fully-Specified name.

Michael Lawley (Jun 08 2018 at 01:00):

Sure, but you don't exchange surrogate keys; they're an internal construct

Peter Jordan (Jun 08 2018 at 01:11):

Not necessarily true, in NZ anyway. We use GUIDs as Entry Identifiers in CDA instances and these are persisted and used by endpoint systems to identify returning records, for example in GP2GP. Basically, they're required in any replication use case. The thing is that they shouldn't be presented to end users - from that perspective they are 'internal', but they can have a life outside of DBMS.

Michael Lawley (Jun 08 2018 at 01:14):

Ah, but in that case they only carry 'identity' and the instance itself is still exchange (ie the inputs to the key). If you replace an expression by a local code then you're no longer exchanging the expression

Peter Jordan (Jun 08 2018 at 01:19):

Would the endpoint system care? Most would be happy with the preferred term and a concept identifier that they can persist within a fixed-length field. If they are interested in the expression - then request a $lookup, as they would do if they are interested in viewing the expression for a pre-coordinated code.

Grahame Grieve (Jun 08 2018 at 01:19):

then it becomes a question about interop between terminology servers.

Grahame Grieve (Jun 08 2018 at 01:19):

because to everyone else, the identifier is opaque.

Grahame Grieve (Jun 08 2018 at 01:20):

and that's what the expression format is for... unless we decide to use supplements to distribute assigned identifiers for expressions

Rob Hausam (Jun 08 2018 at 01:20):

that might be something to consider

Grahame Grieve (Jun 08 2018 at 01:21):

now i should wash my mouth out for merely suggesting the possibility. Syntax switches don't solve semantic problems...

Grahame Grieve (Jun 08 2018 at 01:22):

mind you, you could say that about quite of things that happen in SCT

Rob Hausam (Jun 08 2018 at 01:22):

sure

Michael Lawley (Jun 08 2018 at 01:22):

that's my point - the identifier (the code) is opaque. It's also of unbounded length. If brown-fields backends can't deal, then they can use expression libraries, but I don't see a use

Rob Hausam (Jun 08 2018 at 01:24):

I don't disagree - I was going to mention expression libraries, but they probably don't really solve anything

Peter Jordan (Jun 08 2018 at 01:29):

My perspective is a little different - pre or post-coordinated, these are all concepts defined by expressions and, as far as possible, should be treated in the same way. In practical terms, what's the difference between a post-coordinated concept and a locally-created concept? Placing expressions in a library looks like a poor solution to me.

Rob Hausam (Jun 08 2018 at 01:29):

the bottom line I think is that for post-coordination to catch on we'll have to come up with some sufficiently robust and realistic prototype implementations - and test in connectathons and elsewhere - so that people can finally see something that's tangible and have their "aha" moment and catch on to how it can practically work (using terminology services)
maybe you've already done or started doing a good bit of that in Australia, but I don't know for sure how far you really are with it

Grahame Grieve (Jun 08 2018 at 01:30):

it would be a good connectathon to have at a SNOMED CT event rather than an HL7 event

Jim Steel (Jun 08 2018 at 01:30):

There was a terminology connectathon after the london snomed international business meeting

Peter Jordan (Jun 08 2018 at 01:30):

Anyone else going to Vancouver in October?

Grahame Grieve (Jun 08 2018 at 01:30):

not me

Rob Hausam (Jun 08 2018 at 01:31):

yes, that makes sense - it's not something I've ever seen at a SNOMED event, but maybe it could be done
the London connectathon didn't really begin to approach anything like that, but it might set a bit of a precedent

Rob Hausam (Jun 08 2018 at 01:31):

I'll be there

Michael Lawley (Jun 08 2018 at 01:31):

We'll be in Vancouver.
I'd also be very interested in anyone with real examples of SNOMED post coordination in actual data

Rob Hausam (Jun 08 2018 at 01:32):

if you don't know of them already, Michael, I'm guessing they may not exist

Peter Jordan (Jun 08 2018 at 01:33):

It's a bit like the old adage about teenage s**

Grahame Grieve (Jun 08 2018 at 01:33):

so in the Australian CDA discharge summary, we're using CD.qualifier for laterality. In the FHIR equivalent, that's post-coordination. Note that I don't think anyone actually has done this because the interface terminologies have this pre-coordinated, and no one has translated this one to SCT to my knowledge. But there we are...

Rob Hausam (Jun 08 2018 at 01:34):

should we think about something we could still propose at this point for Vancouver? we might be too late for anything very official, but I don't know

Michael Lawley (Jun 08 2018 at 01:34):

Ah, that's interesting, so the CD does pc itself. Interesting that that maps to pc in FHIR and not another information model element

Grahame Grieve (Jun 08 2018 at 01:35):

CD.qualifier is post-coordination done badly. I retired that in everything we've done since....

Rob Hausam (Jun 08 2018 at 01:35):

well, we did that later in V3, too (like FHIR) - but CDA stayed with the earlier approach

Grahame Grieve (Jun 08 2018 at 01:36):

y. that's right. but the CD.qualfiier approach is awful if you try to actually make it work. the information model definitions work against the pc definitions in snomed ct

Rob Hausam (Jun 08 2018 at 01:36):

totally agree

Rob Hausam (Jun 08 2018 at 01:36):

that's why it got dropped

Grahame Grieve (Jun 09 2018 at 12:27):

so ironically I just ran into another code system that has composition in it today, and now I'm wondering what to do for an $expand request for the specification itself.

Grahame Grieve (Jun 09 2018 at 12:28):

the code system is... mime types. (url = urn:ietf:bcp:13)

Rob Hausam (Jun 10 2018 at 02:06):

I would think that $expand should return the list of registered (pre-coordinated) mime types - of whatever version(s) the server is aware. I don't think it would make sense to compute and return any additional unregistered compositional combinations.

Grahame Grieve (Jun 10 2018 at 03:51):

unregistered with.... who?

Robert McClure (Jun 10 2018 at 15:01):

@Grahame Grieve I'm a bit late back to the party here and was going to comment on your statement that terminology servers will solve this and implied that yours already had solved the problem of supporting the use of PCE (Post-Coordinated Expressions) in records. Given the subsequent discussion it should be be clear that we have a long way to go before calling this "solved" - need I mention versioning?

It's interesting that much of this discussion is a re-hash of material Linda Bird and I put together in 2016 with the eventual conclusion that expression libraries were the only current practical way of supporting "Expressions in the wild." I don't think that document was ever circulated but we evaluated a range of approaches - I really wanted to make a hash work - and all other solutions came up short. Perhaps we can get SCT Int to release the document?

And yes - the mime types is another compositional code system. Actually the one HL7 uses is considered an internal to HL7 code system because the selected format and content is what HL7 decided we needed and is not all that can be done based on BCP 13.

Rob Hausam (Jun 10 2018 at 20:05):

I was thinking of unregistered = not registered with IANA (as bcp13 describes)

Grahame Grieve (Jun 10 2018 at 20:08):

Actually the one HL7 uses is considered an internal to HL7 code system because the selected format and content is what HL7 decided we needed and is not all that can be done based on BCP 13

I don't believe that this is true in the FHIR context; that's a v3 special. But only because we didn't have the max value set concept in v3

Michael Lawley (Jun 11 2018 at 04:18):

There are (probably) a bunch "well known" X- mime types that would be useful to return

Michael Lawley (Jun 11 2018 at 04:44):

@Robert McClure So where would this "expression library" live and how would the Terminology Service know about it / interact with it?

Grahame Grieve (Jun 11 2018 at 05:31):

I think it smells like a code system supplement

Robert McClure (Jun 11 2018 at 17:01):

For better of for worse, our practical proposal was that SNOMED CT would host and manage it - so a central repository. I think it could be decentralized if consistently implemented but the approach required 24/7 availability so that any organization that created or received an identifier for an expression could resolve it. In essence as I remember it (I need to go back and re-read it) this proposal built upon our existing SCT usability, the only thing you did not get when compared to the published precoordinated set was consistent naming and guaranteed (initially) non-equivalence with another expression.

Rob Hausam (Jun 11 2018 at 17:42):

There was certainly considerable discussion about expression library(s) for a while, but not much (if any) that I'm aware of recently. So I'm assuming that there is no current resourcing for it from SNOMED Int. at this point? There is also the possibility that local institutions can develop their own libraries (Univ. of Nebraska comes to mind). I agree that if it's done in FHIR a code system supplement would seem likely.

Peter Jordan (Jun 11 2018 at 20:46):

My understanding is that supplements are for adding designations and properties to code systems - not concepts.

Grahame Grieve (Jun 11 2018 at 23:02):

we did say that, but this is not about defining concepts... just code aliases... not a differentiation we had previously made...

Peter Jordan (Jun 11 2018 at 23:04):

We may be at cross-purposes. I'm referring to post-coordinated SCT concepts, not MIME types.

Grahame Grieve (Jun 11 2018 at 23:23):

so was I

Peter Jordan (Jun 12 2018 at 01:24):

In which case, I don't see how creating post-coordinated concepts isn't, in effect, defining new concepts?

Michael Lawley (Jun 12 2018 at 01:30):

Why not a ValueSet that enumerates a list of post-coordinated codes as an expression library?

Peter Jordan (Jun 12 2018 at 02:16):

That still begs the question of how one might query across both pre and post-coordinated concepts (e.g. ECL queries, subsumption tests, etc.). Surely that would be easier if the post-coordinated concepts were stored as local extensions in RF2 Format? The idea of an international Expression Library also baffles me - why not just promote them to pre-coordinated concepts and add them to the International Edition? I guess that sounds almost too simple, so I must be missing something? :)

Grahame Grieve (Jun 12 2018 at 05:03):

value set doesn't solve the problem for re-use of the library in other value sets

Robert McClure (Jun 13 2018 at 00:00):

@Peter Jordan Your question is indeed the one we had too, and the answer is these expressions are not curated while promoted ones are. That is the primary distinction between them. In part, it's all about resourcing - by allowing expressions to flourish (in the wild!) without requiring curation, we get something useful (but a bit unruly.) From that, sea of goods, some may be promoted...

Grahame Grieve (Jun 13 2018 at 00:02):

or, in my language, the governance criteria are lower

Peter Jordan (Jun 13 2018 at 01:14):

@Robert McClure That sounds like my approach to gardening, the risk is that the good stuff gets buried in the weeds.

Peter Jordan (Jun 13 2018 at 05:56):

@Michael Lawley recent discussions, have left me wondering if I'm heading to the left of this scenario... https://imgur.com/gallery/LTYjp

Grahame Grieve (Jun 13 2018 at 06:00):

that's my new favourite false dichotomy

Grahame Grieve (Jun 13 2018 at 06:00):

is the cartoon itself going left or right?

Peter Jordan (Jun 13 2018 at 06:01):

I'm just concerned about falling over the cliff! :)

Grahame Grieve (Jun 13 2018 at 06:02):

well, thats one thing the cartoon is right about... both paths go off the cliff....

Peter Jordan (Jun 13 2018 at 06:06):

...not sure if that's the intention, but it certainly looks that way.

Rob Hausam (Jun 13 2018 at 17:49):

...but I believe the intention is that the complex path goes down the cliff in a controlled fashion :)

Grahame Grieve (Jun 13 2018 at 21:52):

of course, you get to experience going to the cliff alone, instead of a with a group.

Last updated: Apr 12 2022 at 19:14 UTC