Stream: conformance
Topic: Validator and slicing
Richard Townley-O'Neill (Mar 11 2020 at 01:33):
@Grahame Grieve
I want Composition.section.entry to specify slices for profiled observations. So I sliced Composition.section.entry by pattern:resolve().code.coding.
I also want to require each observation to have a particular code, but allow others, so I sliced Observation.code.coding by pattern:$this and made the slice with my preferred code 1..1.
See structuredefinition-ncdhc-composition-estimated-date-birth.json in https://github.com/RichardTON/au-fhir-childhealth/tree/906a32c580d55c369319b003393bb3dcfcb37f39
My examples throw a "Could not match discriminator " error. See ncdhc-estimated-date-birth-document-example.json
I think that the validator should allow this.
If I change the observation to eliminate slicing Observation.code.coding by pattern:$this and only allow the one coding, without alternates, my example validates. See https://github.com/RichardTON/au-fhir-childhealth/tree/b00dcfdaf307315f77d1c14efde80ce449ca5c20
Is this a reasonable use of slicing?
Grahame Grieve (Mar 11 2020 at 01:51):
I
Grahame Grieve (Mar 11 2020 at 01:52):
I'm not sure. how does the validator know what values are in the value set of the discriminated slice if the element is sliced? Does any acceptable slice meet the pattern? If so, how does it discriminate?
Grahame Grieve (Mar 11 2020 at 01:53):
why note slice on the code rather than on the coding? do you have other slices?
Richard Townley-O'Neill (Mar 11 2020 at 02:28):
Typo above: " So I sliced Observation.section.entry" should have been "So I sliced Composition.section.entry by"
Now corrected.
Grahame Grieve (Mar 11 2020 at 02:35):
I didn't notice that typo - don't think it makes any difference?
Richard Townley-O'Neill (Mar 11 2020 at 02:36):
how does the validator know what values are in the value set of the discriminated slice if the element is sliced?
I thought that as the element has a required slice, you could use a value matching the required slice.
image.png
Richard Townley-O'Neill (Mar 11 2020 at 02:37):
Does any acceptable slice meet the pattern? If so, how does it discriminate?
Would it make a difference if the slicing was closed?
Richard Townley-O'Neill (Mar 11 2020 at 02:39):
why note slice on the code rather than on the coding? do you have other slices?
I cannot slice on Observation.code as it is 1..1
The reason for slicing Observation.code.coding is to follow a design pattern used in the project where future permitted coding can be added by simply adding a new slice.
Richard Townley-O'Neill (Mar 11 2020 at 02:41):
(deleted)
Richard Townley-O'Neill (Mar 11 2020 at 02:41):
The idea is to require one coding of Observation.code, but allow others in the future.
Richard Townley-O'Neill (Mar 11 2020 at 02:43):
I guess something similar could be done by a required binding of Observation.code to a valueset with one entry.
Must give the required value, can give translations.
That would be less obvious, and would be harder to test for agreement with the profile.
Grahame Grieve (Mar 11 2020 at 02:55):
you could just use a pattern on the code with the required details ?
Richard Townley-O'Neill (Mar 11 2020 at 02:56):
A pattern on code can say "all codings will have this system and code", it cannot say "at least one coding will have this system and code"
Richard Townley-O'Neill (Mar 11 2020 at 02:57):
The idea is that sometime in the future a second coding might be permitted, and it will then be added as a new slice.
Grahame Grieve (Mar 11 2020 at 02:57):
permitted? that means you're closing the slicing for now?
Grahame Grieve (Mar 11 2020 at 02:57):
why not just a fixed value then?
Richard Townley-O'Neill (Mar 11 2020 at 02:58):
Yes. It is open in what I have committed, but it is meant to be closed.
Richard Townley-O'Neill (Mar 11 2020 at 03:01):
why not just a fixed value then?
Because the project likes the design pattern of having a slicing with the currently permitted codings in slices, even when there is only one permitted coding.
Richard Townley-O'Neill (Mar 11 2020 at 04:36):
Note: If you want to build the ig, the config file ig-dphr.json runs much faster than ig,json.
Lloyd McKenzie (Mar 11 2020 at 14:18):
A pattern on Observation.code that declares a single coding says exactly what you want I think - "at least one coding must match what I've specified, but others are allowed". That's why pattern is the recommended way of expressing constraints on CodeableConcept.
Shovan Roy (Mar 11 2020 at 20:27):
@Grahame Grieve , @Lloyd McKenzie thanks for the clarification. I have a quick question on this. How to profile an Observation using pattern where we want to say that a LOINC code and/or a SNOMED code is required to be present and the implementer can send any other code?
Grahame Grieve (Mar 11 2020 at 20:28):
you can't do that with a pattern. you need to slice for that
Grahame Grieve (Mar 11 2020 at 20:28):
or maybe just use a value set binding with a value set that covers both
Shovan Roy (Mar 11 2020 at 20:29):
Thanks @Grahame Grieve , we have actually did the sliced with pattern on the Observation.coding.code
Shovan Roy (Mar 11 2020 at 20:33):
As @Richard Townley-O'Neill mentioned that with this slicing in the observation, pattern:resolve().code.coding as the discriminator in the composition doesn't work. It's working fine with profile=resolve(). The first question I have is do you see any issue of using profile=resolve() in Composition section entry slicing?
Shovan Roy (Mar 11 2020 at 20:35):
what kind of benefit I'm expecting to get if I use pattern:resolve().code.coding as opposed to profile=resolve(). does pattern:resolve().code.coding do the profile validation of the entire resource or it just checks if the code is present or not?
Grahame Grieve (Mar 11 2020 at 20:37):
pattern:resolve().code.coding
just checks the coding
Shovan Roy (Mar 11 2020 at 20:39):
Ok, which means, If I use that in a FHIR document, then I've to perform explicit profile validation for each individual resource seperately. The Composition validation will only help to check if the document contains the right list of 'things' (e.g.: Observation) but it doesn't validate if they are also proper as per profile..If this is correct assumption, then It seems to me that profile = resolve() is a better option at this stage isn't it?
Lloyd McKenzie (Mar 11 2020 at 20:42):
For and/or you'd actually need an invariant. Slicing would let you define the two slices, but wouldn't let you say you need at least one of them.
Grahame Grieve (Mar 11 2020 at 20:43):
well, we're talking about the discriminator. It's a lot easier for anyone reading the documentation if the discriminator refers to a fixed value. The validator will still validate the whole profile, but the error messages will be much easier to understand when referring to a fixed value, and you can also figure out which slice is which without a full validator in play
Shovan Roy (Mar 11 2020 at 20:44):
@Lloyd McKenzie agreed.
Shovan Roy (Mar 11 2020 at 20:48):
thanks @Grahame Grieve , in the context of a FHIR document, what is your recommendation to use as discriminator? is there any documentation I can refer to? As of now I've used profile=resolve() for all of our FHIR documents ( we have many of them) and it works. It comes back with proper error if there is anything wrong. But if there is a better way of doing it.I'm happy to take that option and propose of inclusion.
Grahame Grieve (Mar 11 2020 at 20:50):
it's not wrong. it's just tough for users. It's always better if you can refer to a fixed value
Grahame Grieve (Mar 11 2020 at 20:50):
what happens if you refer to a fixed value of resolve().code.coding[0]?
Shovan Roy (Mar 11 2020 at 20:53):
as @Richard Townley-O'Neill mentioned, we are getting "could't match discriminator' error since we have used sliced pattern in Observation.coding.code
Shovan Roy (Mar 11 2020 at 20:56):
looping in @Rob Hausam in this discussion. @Rob Hausam what approach you guys are taking in IPS for FHIR document entry slicing discriminator?
Shovan Roy (Mar 11 2020 at 21:13):
@Grahame Grieve sorry, I missed to answer your question..I haven't tried with fixed value. Our project adopted to use 'pattern' as the Observation.coding. We are extensively using 'pattern' in all over the places as discussed in https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Fixed.20Code.20vs.20Pattern.
I'm happy to check the behavior with using a fixed value and try with resolve().code.coding[0]
Grahame Grieve (Mar 11 2020 at 21:18):
I meant pattern not fixed
Rob Hausam (Mar 11 2020 at 21:24):
After many trials and iterations, in IPS we have arrived at this for our Composition.section.entry slicing definitions:
<slicing>
<discriminator>
<type value="profile"/>
<path value="$this.resolve()"/>
</discriminator>
<rules value="open"/>
</slicing>
There can be issues with "This element does not match any known slice defined in the profile" information qa messages for some of our example instances (depending on whether or not the possible profile matches are entirely non-overlapping), but this gives the choices the visibility that we were looking for in the IG for the IPS instance creators (and depending on what, if anything, you want or need to do with validation on the receiving end there isn't likely going to be a problem with that).
Shovan Roy (Mar 11 2020 at 21:30):
@Grahame Grieve sorry, my bad..I'll try and let you know..
Shovan Roy (Mar 11 2020 at 21:30):
thanks @Rob Hausam I'm inline with what approach you have taken...the only different in our case is that we are using closed slicing. We don't want the implements to send any extra section/entry that is not defined in our profile.
Rob Hausam (Mar 11 2020 at 21:36):
sure - that makes sense
Rob Hausam (Mar 11 2020 at 21:37):
for IPS we didn't want to constrain it that tightly
Rob Hausam (Mar 11 2020 at 21:50):
I'm also going to look further into the possibility of using multiple discriminators (for both type and profile) to further tighten up the slicing in at least some of our cases. I did that successfully in a different context (not involving a reference) in a PlanDefinition profile for Order Catalog, and I think it may also have some applicability here - but that's still to be determined.
Shovan Roy (Mar 11 2020 at 22:02):
sounds like something interesting @Rob Hausam .. I'll keep watching that space :)
Rob Hausam (Mar 11 2020 at 22:06):
I'll let you know how it goes.
Shovan Roy (Mar 11 2020 at 22:58):
@Grahame Grieve I used image.png and got "illegal function name null() in discriminator" error.
Then I used
image.png
and got "Profile based discriminators must have a type with a profile" I double checked, the sample has the meta.profile populated..
Richard Townley-O'Neill (Mar 12 2020 at 01:14):
To use resolve().code.coding the type of slicing is pattern, not profile.
Try pattern:resolve().code.coding[0].
When I tried it, it behaved the same as pattern:resolve().code.coding. Which makes sense, as I have only one coding in the code.
Shovan Roy (Mar 12 2020 at 01:20):
I tried with pattern and got the same error as with profile
image.png
Eroor: illegal function name null() in discriminator
Richard Townley-O'Neill (Mar 12 2020 at 01:21):
I did not use Forge.
Grahame Grieve (Mar 12 2020 at 03:51):
oh yes you would. duh.
Last updated: Apr 12 2022 at 19:14 UTC
