Stream: implementers
Topic: Expression Constraint Language (ECL)- available elsewhere?
Jeremy R (Nov 04 2020 at 14:59):
HI,
Am I right in thinking that ECL is currently confined to SNOMED, and not available to say restrict a patient search query by encounter attributes, eg encounter.status or encounter.location or encounter.serviceProvider ? thanks!
Lin Zhang (Nov 04 2020 at 16:28):
ECL is just a member of the SCT language family.
Jeremy R (Nov 05 2020 at 10:05):
Lin Zhang said:
ECL is just a member of the SCT language family.
Thanks Lin
Corey Smith (Mar 15 2021 at 19:15):
Hello all. We are experimenting with the inclusion of SNOMED expressions in Condition examples in an IG. We have tried several variations of the following in a Condition example:
<code>
<coding>
<system value="http://snomed.info/sct"/>
<code value="284196006|:363698007=770850006|"/>
</coding>
<text value="Burn of skin of left index finger"/>
</code>
Each time we are getting the following error message when we try to run it through the publisher:
Term ":363698007=770850006" doesn't match a defined term at 1 (valid terms would be from this list: ""Burn of skin","Burn of skin (disorder)"") (from http://tx.fhir.org/r4) for 'http://snomed.info/sct#284196006|:363698007=770850006|
We have done it with a display value, no display value, text, and no text.
Any ideas?
Lloyd McKenzie (Mar 15 2021 at 20:53):
@Grahame Grieve
Lloyd McKenzie (Mar 15 2021 at 20:54):
@Rob Hausam
Michael Lawley (Mar 15 2021 at 21:28):
The | symbols are the problem -- they are used to surround the display text of a code and anything inside them is ignored. Thus 284196006|:363698007=770850006| is syntactically equivalent to 284196006. The validation is then attempting to check that the display you've provided is a valid synonym of that concept, which it clearly is not.
The correct syntax would be 284196006:363698007=770850006.
Corey Smith (Mar 15 2021 at 21:52):
Excellent. We will give this a shot and will report back... It was the example in the SNOMED documentation that led us down this path: https://confluence.ihtsdotools.org/display/DOCGLOSS/expression Thanks for the quick response.
Lloyd McKenzie (Mar 15 2021 at 22:11):
Maybe let the SNOMED folks know? Suspect they originally had the display text included and stripped it out, but missed a couple of the delimiters.
Rob Hausam (Mar 16 2021 at 06:24):
I suppose that could be what happened. It seems a little odd that would have slipped through - but I don't have another good explanation for it. We can let them know.
Corey Smith (Mar 16 2021 at 15:14):
@Michael Lawley Your solution worked. Thank you. It did however raise some other questions about what validation logic is being used for the display value associated with expressions. We were surprised that the validation process was attempting to validate the display term for for the expression. The process was nice enough to tell us what display it wanted. In our case it told us to use - "Burn of skin where Finding site = Skin structure of left index finger" Is this validation logic documented somewhere? @Monique van Berkum
Michael Lawley (Mar 17 2021 at 03:31):
That string is arbitrary -- neither FHIR nor SNOMED provide definitive guidelines on how to construct display text for an expression. SNOMED does indicate that one option is just to replace each code with its preferred term. In this case you'd get Burn of skin : Finding site = Skin structure of left index finger
Lloyd McKenzie (Mar 17 2021 at 14:23):
The HL7 terminology server has an algorithm that determines display name based on the syntax and the display names of the components. The objective is to allow IG authors to check that they haven't messed up their codes (or their display names). You're free to publish with an alternate display name - you just have to suppress the warning. (And you'd only suppress the warning after you'd manually looked up the codes and confirmed that the codes are right and the display name accurately represents the code you're conveying and that there's a legitimate need to vary the display name from the default.)
David Simons (Aug 04 2021 at 13:24):
Lloyd McKenzie said:
The HL7 terminology server has an algorithm that determines display name based on the syntax and the display names of the components. ... you'd only suppress the warning ...
Can I suppress this warning somehow via a tag/pragma in the FHIR Resource, to guide the hl7validator/TX to suppress that particular instance of a warning, after ensuring I want to override the default display string?
Also, will this help in suppressing warnings when using designations (synonym), instead of the default display?
Lloyd McKenzie (Aug 04 2021 at 22:13):
I know there was a TODO to be able to pass in an 'ignore warnings' file to the validator similar to what we use with the IGPublisher, but I don't know if it happened or not. In the past, a project that had a similar issue simply built their own wrapper around the validator that suppressed messages they didn't care about.
David Simons (Sep 13 2021 at 13:21):
Lloyd McKenzie said:
I know there was a TODO to be able to pass in an 'ignore warnings' file to the validator similar to what we use with the IGPublisher, but I don't know if it happened or not. In the past, a project that had a similar issue simply built their own wrapper around the validator that suppressed messages they didn't care about.
Indeed I only found https://confluence.hl7.org/pages/viewpage.action?pageId=35718580#UsingtheFHIRValidator-Extensiblebindingwarnings.
Still would be nice to review/track and suppress these warnings individually, via some kind of tags/pragma in the FHIR artifact source itself, rather than wrappers or out-of-band lists.
(I do not know how this is done in the IG Publisher, yet, btw)
for example add a <!-- hl7validator:warning:suppress rationale goes here -->annotation on the line that triggers a warning
Submitted as an Issue: https://github.com/hapifhir/org.hl7.fhir.core/issues/605
Grahame Grieve (Sep 13 2021 at 20:08):
at present, this functionality is only supported when the validator is hosted in HAPI. I guess the place to start is to create an issue, and then we'd have to figure out how to pass whatever is provided on the command line into the existing framework inside the validator
Mark Iantorno (Sep 24 2021 at 14:56):
I'm just looking at this issue now in the repo. I'm confused on exactly what the desired behaviour is? You want to be able to pass in arguments when you run the validator CLI, such that some warnings are filtered out?
Mark Iantorno (Sep 24 2021 at 14:56):
Are you mimicking an existing behaviour in HAPI-FHIR? If so, how does that behave?
Grahame Grieve (Sep 24 2021 at 16:40):
see line 166, org.hl7.fhir.validation.BaseValidator
David Simons (Sep 28 2021 at 17:04):
Mark Iantorno said:
I'm just looking at this issue now in the repo. I'm confused on exactly what the desired behaviour is? You want to be able to pass in arguments when you run the validator CLI, such that some warnings are filtered out?
Indeed desire is to suppress warnings/errors selectively, to not have the entire build fail.
Do not prefer to supply separately, but would like these to be annotated somehow in the source FHIR artifacts - in context - and as such loaded into the hl7validator along with the FHIR artifacts, such as a .structuredefinition.xml or .valueset.xml .
Lloyd McKenzie (Sep 28 2021 at 18:00):
Filtering out errors is pretty much a non-starter. If you want to ignore errors in production, you'd have to wrap the validator and have the wrapper code suppress things. We do allow filtering out warnings in the publication process. I suppose we could embed that 'ignore' file in the publication package and have the validator take advantage of it. In practice, it should only include the locationless messages - things like "unable to find code system xyz" which we expect all the time. Warnings such as "non-matching slice" are context-specific and wouldn't generally be safe to suppress across the board.
David Simons (Sep 28 2021 at 18:42):
yes, I can accept focussing on warnings only, not errors.
In our case, the remaining warnings are on example resources, not so much SD, VS, CS, actually, now that I revisited our logs.
Mostly related to non-matches of valudset bindings, codesystem display strings and indeed non-matching (additional, alternately coded) slices.
I understand the valid point about context - we would not include such annotations in the NPM packaged versions - only in the source repo.
For now I have accepted that we will not be able to resolve all warnings across our profiles.
Hence focussing on resolving all errors, and most warnings.
If only there was a way to not have to revisit known warnings each and every time, when looking for newly introduced ones... That is really the key driver here.
Thank you all!
Lloyd McKenzie (Sep 28 2021 at 18:59):
With the publisher, you can use the ignoreWarnings.txt to suppress both warning and information messages.
Grahame Grieve (Sep 29 2021 at 06:10):
but not in the validator, which is the ask here. The underlying code exists, but it is not surfaced as an option on the command line
Last updated: Apr 12 2022 at 19:14 UTC
