Stream: conformance
Topic: eld-13
Brian Postlethwaite (Sep 22 2017 at 07:55):
Is there something wrong with the definition of invariant eld-13
type.select(code&profile&targetProfile).isDistinct()
The & is a string concatenation of uri values, and then distinct on that.
Patrick Werner (Sep 22 2017 at 08:07):
as select excepts a collection it seems to be wrong. Correct term would be:
type.select(code,profile,targetProfile).isDistinct()
The current invariant always resolves to a{ } collection after the type select, an then the isDistinct always returns true.
Lloyd McKenzie (Sep 22 2017 at 15:41):
Why would that be wrong?
Patrick Werner (Sep 23 2017 at 13:52):
i'm no Fhirpath expert at all, but as pointed out by brian &is a String concat.
Imaginary Example:
<code value="HumanName" />
<profile value="http://fhir.de/StructureDefinition/humanname-de-basis" />
given the existing eld-13 this will evaluate to:
type.select(HumanNamehttp://fhir.de/StructureDefinition/humanname-de-basis).isDistinct()
--> the select returns an empty collection --> { }.isDistinct()--> true
Patrick Werner (Sep 26 2017 at 13:52):
after some more reading in the FHIRPath Spec i assume i missed the collection brackets.
type.select({code,profile,targetProfile}).isDistinct()is my best guess for the corrected invariant
Ewout Kramer (Sep 26 2017 at 13:59):
right.....did type.select(code,profile,targetProfile).isDistinct() not trigger an error (incorrect number of parameters) from the evaluator you are using?
Stefan Lang (Sep 26 2017 at 14:18):
To my understanding (and I'm not a FHIRPath expert either), the current version of eld-13, using Patrick's example, would evaluate to
type.select(HumanNamehttp://fhir.de/StructureDefinition/humanname-de-basis).isDistinct()
while Patrick's version would evaluate to
type.select(['HumanName', 'http://fhir.de/StructureDefinition/humanname-de-basis', null]).isDistinct()
IMHO this should result in the same behavior, but the string concatenated version has the caveat that it hypothetically might find duplicates where there are none.
E.g.
<code value="HumanName" />
<targetProfile value="http://fhir.de/StructureDefinition/humanname-de-basis" />
would have the same string result as Patrick's example. That, at least would be wrong.
Patrick Werner (Sep 26 2017 at 14:25):
i did the validation via HAPI 2.5 (validation the whole StrucDef), i just tried:
<type>
<code value="Address" />
<profile value="http://fhir.de/StructureDefinition/address-de-basis" />
<targetProfile value="http://fhir.de/StructureDefinition/address-de-basis"/>
</type>
with the current eld-13 and it doesn't fail.
I still assume because:
type.select(http://fhir.de/StructureDefinition/address-de-basishttp://fhir.de/StructureDefinition/humanname-de-basis).isDistinct() --> { }.isDistinct() --> true
Stefan Lang (Sep 26 2017 at 15:05):
I wouldn't expect an element with only one type to fail eld-13, so returning true seems correct to me
Patrick Werner (Sep 27 2017 at 09:18):
i got confused an thought that the FHIR Path Expression was on Elementdefinition.type
I now see, that it evaluates the distinctness of the Elements of a resource. Than the expression makes sense the way it is. The only theoretical problem was pointed out by Stefan. Sorry for the confusion.
Last updated: Apr 12 2022 at 19:14 UTC
