Do we have a call today/tomorrow? I would like to look into this if possible: https://jira.hl7.org/browse/FHIR-38130

Right now workflow is every second week, and today is an 'off' week. (And next Monday, I'm out of town, so the call is cancelled.) It's possible we could have a 'special' call today to work through these if you wanted. Let me know.

i would appreciate that, so that i can put some work into those scenarios

k. Same call details as usual. Anyone who wants to come can, but we won't make formal decisions

in 40 mins, right?

25 now, y

is there a call this week?

Next week

Is there a call today?

@Lloyd McKenzie ?

It's not showing on my calendar and Lloyd said he will be late for the FHIR-I call after, so I would guess no.

ok, thanks

This is the 'off' week. Workflow is every second week. Should be a call next week.

For the call on Monday, March 2, 2026: Guidance on using the notification-authorization-hint extension outside of Subscription Notifications. Relevant to COW

For the COW call Tuesday (I hope I can attend), there is a frequent question - to send an entire "order" - even if it is just a group with the differentrequests, but can also be request+patient+supportinginfo+devicedefinition - we need a Bundle. Why a Bundle of type Subscription Notification, not collection or Transacction? I think that deserves some bullet points which then we need to add as guidance

can we have a discussion on this? 1. FHIR-55980

@Ralf Herzog

@Lloyd McKenzie my understanding is that the Bundle to send an order (e.g. a RequestGroup + 2 requests) would be the subscription notification, not a collection, transaction or document. Is that correct? I want to define a standard transaction for "sending orders" and this is fundamental. All implementers I discussed this with have asked - and I don't know if I am right or articulating this right.

i think this would be a great topic for Tuesday COW call, but it happens that IHE Pharmacy is meeting monday afternoon and I would like to have input for that (at least to see if I am seeing this right)

You mean send a Task seeing fulfillment of an order? If the Task lives elsewhere, then yes there'd be a Subscription notification that would contain the Task. If the notification includes resource content, the shape could include the Request and possibly resources associated to it.

I mean a system "depositing" a prescription for later fulfillment

so irrespective of a Task being already there or now

I think we need to be more specific about why an order or set of orders is sent (and what that means). E.g. - is this "communicate to a pharmacy that there is a set of orders someone would like them to to dispense", that would be a Task (or multiple Tasks if the requests can be fulfilled indepedently). If it's "communicate to a central repository the set of MedicationRequests authorized for a patient so that others can reference that later" that could be another interaction. It could be a subscription (where we treat the central repository as being subscribed to updates on MedicationRequests placed in that clinician's EMR), or it could be that there's a set of Create actions at that central repository (as a Batch, Transaction, etc.)

Agree. If you've subscribed to MedicationRequest or RequestGroup updates because you just want to keep track of what meds a patient is on, there wouldn't be a Task.

That is true, but if we remove Task from the two sides of the equation we get to my question: if i need to place an order to a central repository or to a filler or to an intermwdiary.... at once, in a Bundle, what Bundle is that?

This is for an IHE transaction (or more) and i get that question often. so i would like to have written guidance.

If you need to seek fulfillment of an order, you need a Task. The simplest is "POST the Task to the filler". If you can't do that, then the filler needs to subscribe to whatever server will have the Task created on it - and the existence of the Task will be communicated by a notification Bundle. The notification Bundle can contain the Task itself, and it can contain additional related resources if need-be. However, the filler is still going to need to be able to write to the system on which the Task exists to accept/reject the Task (and potentially to communicate the results). You wouldn't typically want a transaction, as you don't want to solicit creating the Request on the filler system. It'll create its own filler order if it decides to accept the Task. And POSTing a document, collection, or other Bundle isn't intended to trigger any action other than storing the data. Certainly you could invoke an operation, but that gets into custom territory that isn't obviously necessary here.

Ok let's leave it perhaps for tuesday call

I am just asking about what bundle type

Dont know how to take focus away from the Task. Not because it is not important, but because it is not the question.

Agree, no transaction. 1 down.