Stream: implementers
Topic: Slice by profile: what's the path?
Alexander Henket (Jun 25 2018 at 10:39):
Suppose I slice by profile. What would be in the discriminator.path? Is "meta.profile" too easy? I'm trying to profile MedicationRequest.supportingInformation that has Resource(any).
Alexander Henket (Jun 25 2018 at 10:41):
Follow up question. If I slice by profile: am I effectively requesting at least that particular profile be present in the meta.profile of the instances? I would expect I am, but just making sure.
Lloyd McKenzie (Jun 25 2018 at 10:47):
If you slice by profile, you're checking whether the instance matches that profile and requiring that it can only match one of the profiles.
Lloyd McKenzie (Jun 25 2018 at 10:47):
There's no requirement if be declared
Alexander Henket (Jun 25 2018 at 11:09):
In STU3 I get an error if I omit path. Also the definition in STU3 says "Each discriminator is a pair of values: a type that indicates how the field is processed when evaluating the discriminator, and a FHIRPath expression that identifies the element in which the discriminator is found."
Alexander Henket (Jun 25 2018 at 11:15):
The thing with "resource that matches the profile", suggests that the instance needs to be valid against that profile.
Suppose I want to profile MedicationRequest.supportingInformation to BodyWeight and BodyHeight. Both are profiles on Observation.
If the supportingInformation instance reference goes to an Observation with meta.profile BodyWeight I would expect the validator to 'see' that BodyWeight is referenced and that this satisfies the supportingInformation requirement.
Next, if the Observation with profile BodyWeight then yields a validation error, then this would be reported only on BodyWeight, but not on MedicationRequest. Are my assumptions correct here?
Lloyd McKenzie (Jun 25 2018 at 14:31):
So supportingInformation would be the path and the profile would be the targetProfile of the resource
Chris Moesel (Jun 27 2018 at 22:01):
@Alexander Henket -- if I'm understanding you correctly, I think you want to put the slicing on Medication.supportingInformation, so you can't use supportingInformation as the discriminator path (since discriminator path is relative to the element with the slicing). In this case, since it's a reference, and the discriminator type is profile, I think your discriminator path needs to be reference.resolve().
Chris Moesel (Jun 27 2018 at 22:03):
I could be wrong (slicing is tricky), but that's my understanding based on the STU3 spec docs here: http://hl7.org/fhir/STU3/profiling.html#discriminator. See the 3rd row in the discriminator examples table.
Alexander Henket (Jun 28 2018 at 06:54):
@Chris Moesel You could be right. I thought of that too and I'd agree with you that putting supportingInformation in the path when your context is already just that, doesn't seem right.
That path excludes use of Reference.identifier + display does it not? Because there is no reference to resolve in that case. Would a validator need to error on use of identifier + display or just warn because it cannot establish conformance to the targetProfile?
Is there something worth discussing here for R4? It feels like there are a couple of uncertainties we need to iron out.
Just in case: here's the profile we're discussing zib-MedicationAgreement
Chris Moesel (Jun 28 2018 at 12:31):
Ah. Gotcha. If you just have an identifier (or worse yet, just a display), then it may not be resolvable anyway-- and as you noted, it certainly would not be resolvable via the reference.resolve() path. Without resolving it, it's impossible to check if the reference conforms to the profile.
That said, I think it would still pass validation? You're using an open slicing and each of your slices (BodyWeight and BodyHeight) have a min 0. If an instance had supportingInformation that used logical references (by identifier), I think the validator would not be able to identify them as belonging to one of the slices, but since it's an open slicing, it would still allow them to exist in the array anyway -- and since neither slice is required (min is 0), validation would pass without anything in the slices. I think.
Of course, if it was closed slicing, or your slices had a min of 1 -- then it would be a different story. In that case I'm not sure what a validator would do, but I suspect you'd essentially need to require that those references be literal (i.e., use the reference).
My caveat is that I haven't tried any of this -- I'm just going based on past similar (but still different) experiences. The other caveat is that I think the validator may not know how to deal with profile-based discriminators anyway (see: https://chat.fhir.org/#narrow/stream/99-IG-creation/topic/discriminators.20based.20on.20profiles.20is.20not.20yet.20supported) -- so even if you do it right it might not validate.
Richard Townley-O'Neill (Jul 26 2018 at 06:30):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
