FHIR Chat · operation in CapabilityStatement · implementers

Stream: implementers

Topic: operation in CapabilityStatement

Yunwei Wang (Mar 09 2022 at 18:59):

An implementer asked us a question about operation in CS which I think it worth some discussion here. Let's say an IG says that server SHALL support $validate operation on Patient in its "requirements" CS

{
          "type" : "Patient",
          "operation" : [
            {
              "extension" : [
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation",
                  "valueCode" : "SHALL"
                }
              ],
              "name" : "validate",
              "definition" : "http://hl7.org/fhir/OperationDefinition/Resource-validate"
            }
          ]
        },

The validate operation has three optional input parameter. One of them is profile
A server implementation, (Server A), decides that it does not support profile input parameter.
Questions

1. If ServerA adds base validate operation in its instance kind CS

              "name" : "validate",
              "definition" : "http://hl7.org/fhir/OperationDefinition/Resource-validate"

Does that mean ServerA support all three input parameters? Or ServerA MAY ignore any optional parameter it does support?
The problem for "ignore any optional parameter" is that client may expect server validating resource using profile uri provided while server actually does something different.

2. If ServerA create a constrained definition based on base validate operation with profile parameter as [0..0],

              "name" : "validate",
              "definition" : "http://my-server/OperationDefinition/Resource-my-validate"

Should this be ok considering the requirement CS in IG has different name/definition pair

3. Based on #2, in CS, implementer can specify a resource with multiple targetProfile but cannot specify an operation with multiple definitions. Should we consider add CS.rest.resource.operation.targetDefinition [0..*] to address this?

Lloyd McKenzie (Mar 09 2022 at 19:01):

Servers are allowed to invoke business rules on any operation. Ignoring parameters should only be done if it's safe to do so. Yelling is better. Also, it might be best to define a refined OperationDefinition that reflects exactly what the system does support that's derived from the original OperationDefinition

Yunwei Wang (Mar 09 2022 at 19:46):

Thanks Lloyd, how about question 2 and 3?

Lloyd McKenzie (Mar 09 2022 at 20:41):

The rules around multiple combinations of allowed parameters for an Operation are handled in the input profile with invariants. No need for multiple OperationDefinitions. It's definitely possible for a derived profile to constrain cardinality.

Last updated: Apr 12 2022 at 19:14 UTC