FHIR Chat · Operations · implementers

Stream: implementers

Topic: Operations

James Agnew (Mar 25 2016 at 21:31):

If I define an Operation via its OperationDefinition as having a parameter of type token, am I allowed to invoke that operation via a Parameters resource? If so, how does the resource look?

Grahame Grieve (Mar 25 2016 at 22:01):

It's a string type. Current build makes this clear as of 48 hours ago

James Agnew (Mar 25 2016 at 22:03):

Ahhhhh right, suddenly I remember the FHIR-I discussion where this was decided. Thanks!

James Agnew (Mar 26 2016 at 15:17):

Ok, I'm putting support for this into HAPI now.

Is it reasonable to assume that if an operation uses a token named foo, it's ok to invoke it with a qualifier, such as $myoperation?foo:below=http://system|value

If so, what about when invoking it via the parmeters resource? Ie, is it ok for the Parameters resource to have a part named foo:below even though the definition defined the part as being called foo?

Josh Mandel (Mar 26 2016 at 15:28):

That would be a surprising result to me, at least.

Josh Mandel (Mar 26 2016 at 15:30):

But I never understood https://chat.fhir.org/#narrow/stream/implementers/subject/OperationDefinition.2Eparameter.2EsearchType/near/7336 (and I don't think anyone provided an example to clarify).

James Agnew (Mar 26 2016 at 15:32):

Yeah, agreed. Don't know that I see any obvious better ways though.

• Define an extension for the qualifier
• Disallow qualifiers when invoking by Parameters
• Add another field to Parameters for the qualifier

James Agnew (Mar 26 2016 at 15:36):

Yeah, I think your question goes hand in hand with this one. Is there a way of merging streams? :)

The invariant on OperationDefinition.parameter.searchType does agree with Grahame's answer above though. If an operation uses a search parameter, the OperationDefinition.parameter.type has to be string or (missing)

James Agnew (Mar 26 2016 at 15:37):

So.. I guess the part in OperationDefinition makes sense to me, but I think we still have work to do in terms of explaining how qualifiers work with this.

Josh Mandel (Mar 26 2016 at 15:51):

(You can rename topics...) But anyway: my question was whether there is an example of how "searchType" is used. I didn't see it in the examples but may have missed it. If you understand this James maybe you can help explain it to me.

James Agnew (Mar 26 2016 at 16:05):

I don't know of any examples yet, but I do remember the discussion on FHIR-I well at least.

The idea is that for some people it might be useful to define operations where the parameter parts are search parameters. I guess the obvious use case for that would be for operations that are basically specialized searches, since that was you can make the URLs have the same semantics as other searches.

In this case, you'd set type to string and searchType would be set to token or date or whatever. E.g from the unit test I'm writing as we speak:

   <parameter>
      <name value="valtok"/>
      <use value="in"/>
      <min value="0"/>
      <max value="1"/>
      <type value="string"/>
      <searchType value="token"/>
   </parameter>

James Agnew (Mar 26 2016 at 16:19):

tracker filed to clarify this

Josh Mandel (Mar 26 2016 at 16:19):

I see, thanks! I guess I would argue for making this a get-only feature. Failing that, then using x-www-urlencoded for POST, to stay parallel with normal search. Failing that, adding a "modifier" to params.

Josh Mandel (Mar 26 2016 at 16:21):

(BTW what you call "qualifiers" FHIR calls "modifiers".)

James Agnew (Mar 26 2016 at 16:22):

Ugh yes, bad habit. HAPI named them that before FHIR gave them a name :)

Grahame Grieve (Mar 26 2016 at 20:01):

Josh - https://hl7-fhir.github.io/patient-operations.html#match though I see I have a red rendering problem there

Grahame Grieve (Mar 26 2016 at 20:01):

agree that how to do modifiers is unresolved

James Agnew (Jun 11 2016 at 19:16):

And now, a new OperationDefinition question, per a HAPI ticket raised by @Michael Lawley

The definition of OperationDefinition.instance is "Indicates whether this operation can be invoked on a particular instance of one of the given types.". Given the word "can", I take this to mean that:

• a value of true means the operation can be applied at both the type and instance level
• a value of false means that the operation can be applied at the type level
• there is no way of indicating that the resource can only be applied at the instance level

Does my interpretation make sense? Is this a problem?

James Agnew (Jun 11 2016 at 19:17):

I do note that Grahame's server exposes only a single OperationDefinition for the validate operation, presumably covering both the type and instance variants. This seems to confirm my interpretation..

Michael Lawley (Jun 13 2016 at 23:16):

makes sense to me :)
It would make more sense to me to separate the definition into two, one for type level and one for instance level because they often have parameters that make sense only in one invocation context and currently the only way to determine this (AFAIK) is to read the text

Grahame Grieve (Jun 13 2016 at 23:34):

I don't know about separating the definition into 2. While it serve some forms of computation better, it doubt it would be better overall.

Grahame Grieve (Jun 13 2016 at 23:34):

but there is a common pattern where the operation works at either type or instance, and some parameters are proxies for 'the identity of the thing'

Christiaan Knaap (Jun 14 2016 at 06:55):

Conformance has Rest 0-* with mode (client | server) allowing to differentiate capabilities for the two modes. Would something like that be useful for OperationDefinition? Differentiation on OperationDefinition should be limited to a small set of properties, maybe just parameters. Otherwise it would effectively still be split into 2, albeit in one Resource then.

James Agnew (Jun 14 2016 at 17:58):

IMO we probably don't need anything fancy here. One more boolean that indicates that the operation can be invoked at the type level would allow for this to be unambiguous.

Grahame Grieve (Jun 14 2016 at 23:36):

yes it's clearly appropriate to do at least that.

Josh Mandel (Sep 20 2016 at 13:51):

http://hl7-fhir.github.io/operations.html#executing indicates that:

Some Operations with primitive input types and a single Resource output parameter named 'return' can be invoked using a GET directly, with parameters as HTTP URL parameters.

Do/should we have an equivalent "nice syntax" for inputs -- that is, allowing clients to just pass in a single resource, rather than aParameters?

Grahame Grieve (Sep 20 2016 at 14:03):

we do

Josh Mandel (Sep 20 2016 at 14:03):

Can you show me where?

Grahame Grieve (Sep 20 2016 at 14:04):

"If the only parameter to the operation is a resource, then the operation can also executed by a POST with that parameter as the body of the request."

Grahame Grieve (Sep 20 2016 at 14:04):

http://hl7-fhir.github.io//operations.html#request

Josh Mandel (Sep 20 2016 at 14:04):

Thanks! So it's up to the client to decide, and a server needs to support both ways?

Grahame Grieve (Sep 20 2016 at 14:05):

pretty much, yes

Josh Mandel (Sep 20 2016 at 14:07):

Got it. And re:

If the only parameter to the operation is a resource

Is there a reason we can't take in (complex) datatypes this way, too?

Grahame Grieve (Sep 20 2016 at 14:10):

it simplifies all the implementations greatly - wrap it in a resource wrapper - use Parameters

Michael Lawley (Sep 20 2016 at 20:30):

That text might be a little ambiguous - does it mean "the only declared parameter" (in the op definition) or does it mean "the only actual parameter" (in a specific invocation)? It's the latter, I know, but the wording could be more explicit.

Grahame Grieve (Sep 20 2016 at 21:39):

do you want to make a task to clarify the wording?

Michael Lawley (Sep 21 2016 at 00:59):

Done http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12070

Grahame Grieve (Sep 21 2016 at 10:17):

thx

Mounika (Jun 19 2017 at 06:59):

Hi all, We are using HAPI-FHIR server and perfoming some operations like ActivityDefinition/[id]/$apply, CapabilityStatement/$subset, CapabilityStatement/$implements , CodeSystem/$lookup, CodeSystem/$subsumes , CodeSystem/$compose, Composition/$document.I want to know whether the HAPI-FHIR server is supports these operations or not? If yes how?

Angus Millar (Apr 27 2018 at 09:45):

Is there any hard rule that $Operations cannot occur on the DELETE verb? In my case, I have created an operation for the users (admin users) to load into the server CompartmentDefinition resources. That operation looks like this: POST [base]/CompartmentDefinition$x-setcompartment and takes a single CompartmentDefinition resource. It checks its validity and then make it an active Compatment on the server. This then begs the question how do they remove that active Compartment from the server. I feel like I want to implement another operation using the DELETE verb, something like DELETE [base]/CompartmentDefinition$x-delete-compartment?code=Patient, which removes the active compartment from the server. It that allowed?

Grahame Grieve (Apr 27 2018 at 23:23):

well, here's how i'd think about:

Grahame Grieve (Apr 27 2018 at 23:24):

• POST/PUT the compartment to the server
• so now it's [base]/Compartment/[the-id]
• operation: [base]/Compartment/[the-id] /$set-active
• now the compartment is good to go. maybe tagged by the server so you know it's active
• operation: [base]/Compartment/[the-id] /$set-inactive
• DELETE [base]/Compartment/[the-id]

Grahame Grieve (Apr 27 2018 at 23:24):

I can't imagine what it means to 'set a compartment active'

Angus Millar (Apr 28 2018 at 02:49):

Thanks Grahame, I understand you view and had considered it. I was concerned that haveing the server active CompartmentDefiniton resource in the general resource repository ran the risk of it being modified without the awareness of the consequences of that modification on the active server compartment. Would I be correct in thinking that your view is that any PUT, DELETE on that resource would be applied to the server active Compartment without calling $set-active again?

Grahame Grieve (Apr 28 2018 at 03:47):

I'd probably refuse to change it if it was active

Christiaan Knaap (May 01 2018 at 08:01):

It is for such reasons that Vonk has a separate /administration endpoint. If you change resources there, you change the behaviour of Vonk.
Although Vonk does not provide an operation like the one @Angus Millar describes. A compartment is conveyed per request, based on the compartment in the url ('compartment search') or in the authorization token.
I'm curious what the usecase is set a CompartmentDefinition to active for the server as a whole.

Angus Millar (May 02 2018 at 01:49):

@Christiaan Knaap I think we are doing something similar. On the first install, my server begins its life with no active Compartments. That means users can not do a search as follows [base]/Patient/[id]//Observation?identifier=http://acme.com/lab/reports/Observations|obs00000006. That search would return an error of "No active Patient Compartment exist in this server.". Yet if the user adds a CompartmentDefinition resource to the server at the endpoint [base]/CompartmentDefinition/10 and then calls an Operation I have defined call $x-set-CompartmentDefinition-active and called like this [base]//CompartmentDefinition/10/$x-set-CompartmentDefinition-active the server then processes that CompartmentDefinition resource with the id=10, checking it is valid, and then sets it as Active in the server. Active here meaning that now the search [base]/Patient/[id]//Observation?identifier=http://acme.com/lab/reports/Observations|obs00000006 will work.

Christiaan Knaap (May 02 2018 at 12:12):

Ah, I get it. Similar indeed. But to Vonk not the $x-set-CompartmentDefinition-active is the trigger but the fact that it is posted to the [base]/administration/CompartmentDefinition instead of the normal [base]/CompartmentDefinition.

Yunwei Wang (May 02 2018 at 20:03):

I would use the same operation with one input parameter for the status: boolean isDelete := true | false

Last updated: Apr 12 2022 at 19:14 UTC