Stream: implementers
Topic: Can you constrain nested properties of a reference element?
Chris Moesel (Mar 27 2019 at 13:58):
I have a profile on Observation and want to constrain a property of specimen (more specifically, make specimen.type "must support"). To do this, I would have to "unroll" or "drill down into" the Specimen type within the Observation profile. Observation.specimen, however, is a Reference. There is conflicting information on Zulip about whether or not drilling into a reference is valid.
Chris Moesel (Mar 27 2019 at 13:59):
For example, @Lloyd McKenzie says it is not valid:
A profile can assert a target profile for a reference - which would in turn restrict the referenced artifact. However, a profile can't "drill down" into the content of a referenced resource the way it can drill into the components of a data type.
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Profiling/near/153869408
Chris Moesel (Mar 27 2019 at 14:00):
But @Michel Rutten seems to say it is, and that Forge supports it:
Alternatively, a custom profile can specify inline constraints on referenced external type/resource profiles. For example, your custom profile could further constrain an element with (default) datatype Range by limiting the low/high values.
Chris Moesel (Mar 27 2019 at 14:03):
Nevermind! Upon reading it again, I see that @Michel Rutten was using the word "referenced" in a more general way -- he was not talking about actual FHIR references (as Range is not a reference in Observation).
So I will assume that it is not valid, as Lloyd clearly indicated in his previous comment. Thanks!
Michel Rutten (Mar 27 2019 at 14:07):
My earlier comments applied to constraints on regular datatypes (such as Range).
A referencing profile can further constrain a ResourceReference and it's child nodes, but not the referenced target profile, as this is not "inlined" in the referencing profile. Alternatively, you can specify FHIR Path constraints on the reference target using the "resolve" operator.
Michel Rutten (Mar 27 2019 at 14:10):
Note that not all FHIR servers will implement support for such complex constraints.
Chris Moesel (Mar 27 2019 at 14:49):
Thanks for the confirmation @Michel Rutten -- and sorry for initially misunderstanding your earlier comment. Eventually I figured it out! ;-)
Eric Haas (Mar 27 2019 at 15:01):
Just reference a Specimen profile that requires the code
Lloyd McKenzie (Mar 27 2019 at 15:35):
You can assert a targetProfile for the Reference or you can define a constraint that makes use of resolve(). Those are the only ways to influence what a Reference points to.
Chris Moesel (Mar 27 2019 at 16:39):
Thanks everyone! I'm not sure I want to create an entire profile on Specimen just to say that type is must support in this one use case for this one profile on Observation. And using a FHIRPath invariant to flag something as must support feels weird (and I'm not sure it's even possible since "must support" doesn't come through in instance data). But at least I know my options! Thanks again.
Lloyd McKenzie (Mar 27 2019 at 16:56):
True. I missed the "mustSupport" bit. There's no way to do that with a constraint. Your only choice around "mustSupport" is creating a profile or adding some other textual verbiage in the spec. (And based on proposed tightening of the rules for IGs, just verbiage in the spec might not cut it.)
Lloyd McKenzie (Mar 27 2019 at 16:56):
Creating a profile that just flags one element as mustSupport is actually pretty light work though...
Last updated: Apr 12 2022 at 19:14 UTC
