It should be possible to use ECL for implicit Valueset expansion using a remote TermServiceProvider

[jaykola]

Is your feature request related to a problem? Please describe. FHIR Implicit Value Sets can be defined via ecl for SNOMED CT. You already added some support for this in #2092 and #2198. As you are aware SNOMED CT has this Expression Constraint Language (SQL equivalent of sorts for SNOMED CT) and is pretty powerful. But right now using ecl for implicit valuesets does not work when accessing from the fhir-server, even though the remote server supports the operation.

Describe the solution you'd like It would be great to see support for ECL based queries added to the ValueSet expansion operator.

Here are specific examples: Query: 'http://localhost:9070/fhir-server/api/v4/ValuSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/<<27624003' produces response

{
    "resourceType": "OperationOutcome",
    "id": "ac-16-0-3-f827c8a2-6c77-490b-8485-805442338e45",
    "issue": [
        {
            "severity": "fatal",
            "code": "not-supported",
            "details": {
                "text": "ValueSet with url 'http://snomed.info/sct?fhir_vs=ecl/<<27624003' is not available"
            },
            "expression": [
                "<empty>"
            ]
        }
    ]
}

You can verify this query is supported by the remote terminology server - equivalent call:

https://snowstorm-fhir.snomedtools.org/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/%3C%3C27624003

Describe alternatives you've considered Now the semantic equivalents of that expansion usingisa and below both work. But they are limited since ecl is more expressive and allows you to refine/filter SNOMED CT beyond just what isa allows.

Acceptance Criteria

1. GIVEN [a ValueSet expansion that uses ecl] AND [an external terminology service provider that supports full expressivity of SNOMED CT] WHEN [we use ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/ecl_query_here] AND [access the expansion at http://localhost:9070/fhir-server/api/v4/ValuSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/ecl_query_here] THEN [expansion operation outcome must not fail with unsupported error] AND [Outcome must return a successful valueset expansion as the remote terminology server would]

Additional context Add any other context or screenshots about the feature request here.

[jaykola]

Some related background is in comment: https://github.com/IBM/FHIR/issues/745#issuecomment-898508477

[prb112]

Per discussion - a relevant link for ECL and Snowmed https://confluence.ihtsdotools.org/display/DOCECL and per team review of open Term Graph issues.

[jaykola]

Please let me know if I can help in any way on this. It’ll be great to see if want to implement it in TermGraph too. Delegating to an external remote server would still be helpful.

On 9 Sep 2021, at 21:19, Paul Bastide @.***> wrote:

Per discussion - a relevant link for ECL and Snowmed https://confluence.ihtsdotools.org/display/DOCECL https://confluence.ihtsdotools.org/display/DOCECL and per team review of open Term Graph issues.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/IBM/FHIR/issues/2681#issuecomment-916408265, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJC5HKZNAYGZROOLGKNXGTUBEJGHANCNFSM5CECJ3ZA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[sidharthramesh]

Any progress on this? Having ECL support would be great!

[sidharthramesh]

Having the FHIR Server implement all the ECL logic would probably be overkill. It's going to be very hard to maintain. However, delegating the ECL queries to a remote terminology server would be an excellent feature to have. The IBM FHIR server is the only thing close to becoming a "complete" FHIR solution for Demographics and Terminology. This feature will be a superb addition.

Please let me know if I can contribute or help somehow. Would really like to see this.

[sidharthramesh]

The issue is not with ecl itself. If you do a query like:

GET ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/707480001

it works!

However, when using certain special characters like "<, >, ^" which is used extensively in SNOMED CT ECL, example:

GET ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/<707480001

the server seems to use the SnomedRegistryResourceProvider and throws:

[9/26/22, 8:38:39:076 UTC] 000001cb SnomedRegistr W The code '<707480001' is invalid or SNOMED CT is not supported
[9/26/22, 8:38:39:077 UTC] 000001cb FHIRResource I ValueSet with url 'http://snomed.info/sct?fhir_vs=ecl/<707480001' is not available

The request to the remote server never goes through.

This is probably from https://github.com/LinuxForHealth/FHIR/blob/4f46e15c05463ff02d4bb45e215dbfad1610afaa/term/fhir-term-graph/src/main/java/org/linuxforhealth/fhir/term/graph/registry/SnomedRegistryResourceProvider.java#L126

[sidharthramesh]

I've tried writing a test to check if it's the SNOMED CT validation that's causing this error:

@Test
    public void validateCode() {
        Code code = Code.of("<707480001");
        ValidationOutcome outcome = FHIRTermService.getInstance().validateCode(loadCodeSystem(), code, null);
        Assert.assertNotNull(outcome);
        Assert.assertTrue(Boolean.TRUE.equals(outcome.getResult()));
    }

However, this test passes! When doing a query using ECL, the above error still happens. I'm not sure what's happening.

@JohnTimm @prb112 @jaykola any idea where the source of this issue might be?

[sidharthramesh]

The implicit value set: http://snomed.info/sct?fhir_vs=ecl/287139006 and http://snomed.info/sct?fhir_vs=refset/287139006 and everything else is getting converted to:

    "compose": {
        "include": [
            {
                "system": "http://snomed.info/sct",
                "filter": [
                    {
                        "property": "concept",
                        "op": "is-a",
                        "value": "287139006"
                    }
                ]
            }
        ]
    }

before the server posts to the remote terminology server. So the operation in fhir_vs=<operation>/<code> never gets relayed and the FHIR server always composes an is-a query on $expand.

This seems to be the relevant code responsible for this https://github.com/LinuxForHealth/FHIR/blob/f7ba4d2e5ee2319ec5dec41f3319eb26e3b56ff1/term/fhir-term-remote/src/main/java/org/linuxforhealth/fhir/term/remote/provider/RemoteTermServiceProvider.java#L241