FHIR Chat · What SNOMED capabilities exist? · terminology

Stream: terminology

Topic: What SNOMED capabilities exist?

Lloyd McKenzie (Oct 11 2018 at 20:57):

I'm planning to demonstrate some of the "cool" things we can do with SNOMED using FHIR-based terminology services. After some discussion with Grahame, I'm getting the impression that things aren't as far along as I thought they were. For example, he wasn't aware of anyone who has ability to do subsumption testing on data with post-coordinated codes or doing "in:" testing for value sets that include filters on anything other than is-a relationships. So what I'm looking for now is what SNOMED terminology capabilities do exist in publicly accessable test servers that I can show off and that implementers can do some testing with.

Grahame Grieve (Oct 11 2018 at 20:58):

also, we have not defined a way - other than ECL - to say "all codes with a body-site of liver"

Lloyd McKenzie (Oct 11 2018 at 21:02):

Our link to ECL in the spec doesn't resolve. If I can define the value sets using ECL, that might be good enough. But I need to know how to write it...

Grahame Grieve (Oct 11 2018 at 21:02):

I'm not going to support ECL anytime soon. @Michael Lawley might

Michael Lawley (Oct 11 2018 at 21:03):

Not true regarding in: -- while we don't yet support SNOMED post coordination, Ontoserver supports $expand (with filter) and $validate-code are supported for SNOMED, LOINC and FHIR CodeSystems with ValueSets using "arbitrary" filters (as declared in the CodeSystem resource)

Michael Lawley (Oct 11 2018 at 21:03):

We have full ECL support too, both via the ECL Implicit ValueSet URIs and in filters

Grahame Grieve (Oct 11 2018 at 21:04):

what filters do you support for SCT?

Grahame Grieve (Oct 11 2018 at 21:04):

and you don't unfortunately, have what Lloyd meant when he referred to :in

Michael Lawley (Oct 11 2018 at 21:04):

You can play with ECL here http://ontoserver.csiro.au/shrimp/ecl/

Grahame Grieve (Oct 11 2018 at 21:04):

GET [base]/Condition?code:in=[valueset]

Grahame Grieve (Oct 11 2018 at 21:05):

which I do have, but none of the SCT smarts; just straight is-a

Michael Lawley (Oct 11 2018 at 21:05):

Re :in, we have done (do) this using a generic HAPI server that delegates terminology operations to an external Ontoserver instance.

Michael Lawley (Oct 11 2018 at 21:06):

@Mark Braunstein and @Jim Steel are using such a server for the student projects in the FHIR course they're teaching at Uni of Queensland this semester

Rob Hausam (Oct 11 2018 at 21:06):

which link were you referring to?
the one in 4.3.1.0.8.4 resolves

Grahame Grieve (Oct 11 2018 at 21:07):

is that server publicly available?

Michael Lawley (Oct 11 2018 at 21:08):

Ontoserver 5.2.0 (on the cusp of release, but also in the currently deployed public endpoint) also supports /$validate for arbitrary resources

Rob Hausam (Oct 11 2018 at 21:08):

yes, I'm pretty much certain that it is publicly available

Rob Hausam (Oct 11 2018 at 21:09):

although I'm always logged in, so a little harder to check

Grahame Grieve (Oct 11 2018 at 21:09):

I meant, is the ontoserver for QU students publicly available

Rob Hausam (Oct 11 2018 at 21:09):

sorry

Michael Lawley (Oct 11 2018 at 21:10):

Wrt supported SNOMED filters:

"filter": [
                    {
                        "code": "concept",
                        "description": "Includes all concept ids that have a transitive is-a relationship with the code provided as the value.",
                        "operator": [
                            "is-a"
                        ],
                        "value": "A SNOMED CT code"
                    },
                    {
                        "code": "concept",
                        "description": "Includes all concept ids that have a transitive is-a relationship with the code provided as the value, excluding the code itself.",
                        "operator": [
                            "descendent-of"
                        ],
                        "value": "A SNOMED CT code"
                    },
                    {
                        "code": "concept",
                        "description": "Includes all concept ids that are active members of the reference set identified by the concept id provided as the value.",
                        "operator": [
                            "in"
                        ],
                        "value": "A SNOMED CT concept id"
                    },
                    {
                        "code": "constraint",
                        "description": "The result of the filter is the result of evaluating the given SNOMED CT Expression Constraint.",
                        "operator": [
                            "="
                        ],
                        "value": "A SNOMED CT Expression Constraint"
                    },
                    {
                        "code": "expression",
                        "description": "The result of the filter is the result of evaluating the given SNOMED CT Expression Constraint.",
                        "operator": [
                            "="
                        ],
                        "value": "A SNOMED CT Expression Constraint"
                    },
                    {
                        "code": "parent",
                        "description": "Includes all concept ids that have/do not have a parent concept.",
                        "operator": [
                            "exists"
                        ],
                        "value": "A boolean, to specifiy whether or not the property has a value."
                    },
                    {
                        "code": "child",
                        "description": "Includes all concept ids that have/do not have a child concept.",
                        "operator": [
                            "exists"
                        ],
                        "value": "A boolean, to specifiy whether or not the property has a value."
                    }
                ],

Grahame Grieve (Oct 11 2018 at 21:12):

so could you use one of those filters to say 'with a bodysite of X'? (or 'with laterality')?

Michael Lawley (Oct 11 2018 at 21:14):

I'm not sure whether that UQ server is publicly available. We can sort out something short-term for demo purposes for @Lloyd McKenzie -- you'll need to contact @Jim Steel though as I'm about to jump on a plane to Vancouver

Michael Lawley (Oct 11 2018 at 21:16):

Certainly you can use the constraint filter to do that with ECL - eg
constraint = * : << 363698007|Finding site| = << 122865005|Gastrointestinal tract structure|

Michael Lawley (Oct 11 2018 at 21:18):

However, the ECL support only works with pre-coordinated concepts, not post-coordinated ones (wrt the :in implementation)

Peter Jordan (Oct 11 2018 at 21:43):

My server (Terminz) supports creating implicit ValueSets using ECL - although it's very much WIP, a little slow, and doesn't yet implement the entire language. @Lloyd McKenzie , I'll be happy to demonstrate this to you in Vancouver. As for post-coordination, I don't know any FHIR API that supports that or, indeed, how one might return these expressions to FHIR clients in a 'standard' format as there are several options for doing this.

Michael Lawley (Oct 11 2018 at 22:02):

@Grahame Grieve does your server support externalised terminology operations?

Grahame Grieve (Oct 11 2018 at 22:03):

no. it's possible; I would just use the closure operation (that's what i used internally)

Lloyd McKenzie (Oct 11 2018 at 22:22):

@Rob Hausam ECL link was from 3.0. You're right that the one on build.fhir.org works.

Lloyd McKenzie (Oct 11 2018 at 22:34):

@Michael Lawley @Peter Jordan I'm trying to figure out scenarios for the developers at the Day of the Dev session on Wednesday in Vancouver to try out. The intention is to show software developers how they can start doing clinically useful things with SNOMED once they've got FHIR Terminology services in the mix - decision support, data entry, etc.

Use-case 1 was to be: App supports a user in choosing a code that meets the requirements of an intensional SNOMED value set - including the ability to pick appropriate post-coordinated qualifiers.

While it sounds like there's an ability for some servers to use $validate to test "is this post-coordinated expression valid under this value set", there's no way for a system to expose what qualifiers and values would be legal for a user to choose from in doing the post-coordination. So for this one we'll have to settle for using the $expand with filter for type-ahead and indicate that post-coordination selection is "future".

Use-case 2 was to be: App allows filtering for Observations and/or Conditions that meet complex SNOMED filters (including qualifier relations and post-coordinated concepts) and returns relevant data using ValueSet definitions and the :in search modifier.

It sounds like we can do some ECL-based stuff if we can get a server set up, but the post-coordinated subsumption testing is still a no-go.

Is that an accurate assessment?

Michael Lawley (Oct 11 2018 at 22:49):

Post coordination is pretty much a no go, yes. However, we've struggled to find people with real post coordination needs. Our previous (non fhir) generation of ontoserver had post coordination support but nobody (except us, on internal research projects) ever really used it

Grahame Grieve (Oct 11 2018 at 22:50):

it's a mexican stand off. no one uses it because no one is able to use it. no one is able to use it because the tools don't support it because no one uses it

Lloyd McKenzie (Oct 11 2018 at 22:53):

SNOMED's a lot more limited in expressiveness without it. If we can make it "easy" for apps to use it, they will. Have we defined the necessary services? E.g. "What are the qualified codes that are specializes of code x that are valid against value set y, organized by qualification type?"

Michael Lawley (Oct 11 2018 at 22:55):

WRT scenario 1, you'd need the SNOMED machine readable concept model (MRCM) to do this in a general purpose way, but could still use ECL to demo the concept. E.g., if a code X has been selected and you want to offer appropriate 'severity' qualifiers, then the ECL < severity MINUS > X.severity should work (this is offering descendants of severity as per the MRCM, but excluding any severity that's not compatible with an possibly already modelled severity for X)

Michael Lawley (Oct 11 2018 at 23:03):

We are aiming to support post coordination, but there are significant changes happening to snomed's description logic at the moment that we need to deal with first.
Also, we need to understand better what the use-cases are so we can prioritise the feature set

Jim Steel (Oct 12 2018 at 00:22):

@Lloyd McKenzie Our UQ Student deployment of our FHIR server (which delegates :in searches to a terminology server, in our case Ontoserver) is part of a SMART-on-FHIR framework, so its not publicly accessible at present. I can hook you up with credentials if you like (either client credentials for Postman requests, or a google OpenID account authorisation for an authorization code flow.

Or if that's too confusing for your demo, I can probably arrange to stand up a FHIR server without any of the SMART stuff. It may not have data in it though.

Peter Jordan (Oct 12 2018 at 00:27):

My understanding is that, after those changes, it will no longer be possible to perform equivalence testing without a classifier. That would raise the bar even higher for those implementing post-coordination. The key issue for me is how we render them so that they are interoperable, distributable and searchable using the RF2 format. I'd love to see some good examples as test cases, but my gut feeling is that if they are useful they should be promoted, as pre-coordinated concepts, to the International Edition asap rather than sitting in Expression Libraries for years.

Lloyd McKenzie (Oct 12 2018 at 02:25):

@Jim Steel The intention is to have something developers can try hands-on with that they can get done in a couple of hours after some training. SMART-on-FHIR (and probably even TLS) might be too steep to climb in the time we have available

Jim Steel (Oct 12 2018 at 02:39):

Yeah, I agree. I can try and stand something up on Monday (our time, late Sunday US/CA time) if you like. Do you need (or do you have) sample data that you'd like in there?

Lloyd McKenzie (Oct 12 2018 at 02:59):

For the first use-case, raw SNOMED and a value set for SNOMED diagnosis codes is probably sufficient. For the second, perhaps a set of patients with conditions that are variations of hypertension and diabetes - and some that have both.

Adam Flinton (Oct 12 2018 at 09:33):

you could ping dev ppl at snomed (or chat to them if you're going to the vancouver snomed meeting) as snowstorm has just hit 2.0.0 and... I believe it's available as a read-only instance somewhere. I believe it now has owl axioms but don't know if they've done the fhir api.

Rob Hausam (Oct 12 2018 at 11:53):

We can also load patient data on my HAPI server. There's are still issues with the HAPI uploader and the FHIR examples, but I'll see if I can get through that and get that set uploaded on the server.

Lloyd McKenzie (Oct 15 2018 at 15:24):

Any luck @Jim Steel , @Rob Hausam ?

Last updated: Apr 12 2022 at 19:14 UTC