Stream: implementers
Topic: cardinality and :not
Keith Boone (Apr 02 2018 at 22:43):
I'm trying to understand the application of :not in the presence of different cardinalities for values.
Given a resource with a SNOMED and ICD-10 code of SOMESNOMEDCODE and SOMEICD10CODE
Does Condition?code:not=SOMESNOMEDCODE match that resources because it has a code that doesn't match SOMESNOMEDCODE (specifically SOMEICD10CODE).
Taking this a step further. If I have two security flags on a Condition resource, call them SFLAG1 and SFLAG2
does Condition?_security:not=SFLAG1 match that resource because it has SFLAG2 which is NOT SFLAG1?
Or does Resource?searchkey:not=SOMEVALUE for resource X mean that Resource X has NO searchkey value that matches SOMEVALUE?
I THINK this has been SOMEWHAT clarified in STU4 current code in this text:
GET [base]/Composition?section:not=48765-2
Search for any Composition that does not contain an Allergies and adverse reaction section. Note that this search does not return "any document that has a section that is not an Allergies and adverse reaction section" (e.g. in the presence of multiple possible matches, the negation applies to the set, not each individual entry)
But I am not entirely certain, since this text is new and not entirely clear.
Is there any variation of interpretation different in STU2, 3 and 4 intended? In implementations?
Grahame Grieve (Apr 02 2018 at 22:47):
we clarified this in R4 - it was not clarifed until then and different implementations did different things
Grahame Grieve (Apr 02 2018 at 22:47):
what is not clear about the R4 documentation?
Keith Boone (Apr 02 2018 at 22:52):
Well, first of off, it went to the deep case of Composition.section.code, instead of the simpler case of _tag, _security or other cases where there could be multiple codings (not using CodeableConcept) or identifiers, and so it took interpretation to work back to the simpler case. Also, Composition.section is confusing since it (as a search term) refers to Composition.section.code, and as a resource field, to a BackboneElement (both with Cardinality > 1), so it took some thinking to understand what was meant. I think that code:not=foo means HAS NO CODE with the value of foo, rather than has at least one code that does not have the value of foo, and that's what I eventually got out of the R4 documentation, but like I said, it was a bit of a struggle because of cognitive dissonance present in the example. A simpler example preceding the more complex one would help, but you can save that for responding to my ballot comments.
Grahame Grieve (Apr 02 2018 at 22:54):
sure. please ballot about that
Grahame Grieve (Apr 02 2018 at 22:54):
anyway, the interpretation is clear now, yes?
Keith Boone (Apr 02 2018 at 22:55):
If you can tell me that my thinking agrees with yours, then it does, but not until you say that ;-)
Grahame Grieve (Apr 02 2018 at 22:56):
using your example: Condition?_security:not=SFLAG1 does not match that resource because it has SFLAG1?
Grahame Grieve (Apr 02 2018 at 22:56):
and "Resource?searchkey:not=SOMEVALUE for resource X mean that Resource X has NO searchkey value that matches SOMEVALUE?" - yes
Keith Boone (Apr 02 2018 at 22:58):
Thank you. I now understand. Blog posting coming on this one. I like that this is being clarified. Information I was finding in implementations wasn't helping.
Grahame Grieve (Apr 02 2018 at 23:08):
no. probably none have been updated for the clarification yet
John Moehrke (Apr 03 2018 at 15:22):
Opportunity for test tools @Richard Ettema ???
Richard Ettema (Apr 03 2018 at 22:56):
@John Moehrke Always looking for opportunities :wink: Just need well defined positive and negative scenarios and the test data with enough variance to support them.
John Moehrke (Apr 04 2018 at 12:50):
good test scenarios with details can be found on the various FHIR blogs... Keith especially http://motorcycleguy.blogspot.com/
Last updated: Apr 12 2022 at 19:14 UTC
