FHIR Chat · Constraints between parameters in OperationDefinition · implementers

Stream: implementers

Topic: Constraints between parameters in OperationDefinition


view this post on Zulip Morten Ernebjerg (Jun 28 2018 at 11:50):

We have a custom operation for which different subsets of the output parameters are returned depending on the input. That is, we have constraints between the optional output parameters A, B, and C of the form "Either (A AND B) are returned OR C is returned". Going further, the constraints actually depend on the value passed in the input parameters. Is there any (machine-readable) way to encode one of both of such constraints in the OperationDefinition resource, as one would do with FHIRPath constraints for a profile?

view this post on Zulip Jose Costa Teixeira (Jun 28 2018 at 11:55):

is your "input" a static thing (i.e. something that you define once and always behaves in a similar way or "dynamic", (e.g. it depends on a previous step in the sequence)?

view this post on Zulip Jose Costa Teixeira (Jun 28 2018 at 11:57):

We have a challenge about dynamic behaviour when looking at "workflow profiling".
example:
After receiving a medicationRequest, and after administration is given, the medicationAdministrationResource
a) MUST contain a .request value filled in
b) the value of the .request MUST be the same as the request ID that was received

view this post on Zulip Morten Ernebjerg (Jun 28 2018 at 13:54):

The constraints linked to input would roughly be of the form

If input parameter X has value"y", then the return Parameters resource must contain parameters A and B, otherwise it must contain parameter C.

(actually, these would be constraints on the possible parts of a multi-part parameters). Here, "y" would be a fixed value from a ValueSet, so I guess that would make it "static" in your parlance?

For us, even just having fixed constraints with no input dependence to specify possible consistent subsets of return parameters would also be interesting.

view this post on Zulip Morten Ernebjerg (Jun 28 2018 at 13:55):

Of course, I suppose any such constraints would be of limited value if there is no way to automatically check them (i.e. to validate a Parametersinstance against the corresponding OperationDefinition) and I am not aware of any way to do that. If there was a way to specify constraints in OperationDefinition, I suppose it would be possible to convert it into a profile on Parametersand validate using that.

view this post on Zulip Lloyd McKenzie (Jun 28 2018 at 18:34):

In R4, you can use Parameters.inputProfile to specify the profile that applies to the inbound Parameters instance. And you can declare a constraint on the root that reflects your invariant. In R3 and R2 you'll need an extension, though we should soon be publishing a standard extension for that purpose.

view this post on Zulip Morten Ernebjerg (Jun 29 2018 at 11:19):

@Lloyd McKenzie Perfect, thanks!


Last updated: Apr 12 2022 at 19:14 UTC