FHIR Chat · optionf: how would addended results work? · workflow

Stream: workflow

Topic: optionf: how would addended results work?

---

Isaac Vetter (Dec 27 2021 at 22:36):

Looking at: https://www.hl7.org/fhir/workflow-management.html#optionf. In this case the placer stores the Task and request resources, but the Fulfiller stores the result resources. The Fulfiller updates the task.status to complete in order to trigger the placer to retrieve the result.

How would you expect an addended or corrected result to work in this case?

Isaac Vetter (Dec 27 2021 at 22:36):

Requiring bidirectional polling/pubsub is a pretty high bar.

Isaac Vetter (Dec 27 2021 at 22:40):

Oh, maybe just updating Task.output?

Vassil Peytchev (Dec 28 2021 at 02:05):

In general, updating the Task (usually businessStatus + output) is the way to make the Placer aware of changes in the state. In the case of an amended or corrected result, you may need a secondary Task, linked via partOf to the original one, since I believe a completed Task is not expected to be further updated.

Isaac Vetter (Dec 28 2021 at 15:27):

Thanks, Vassil. Specifically for optionf, having the fulfiller create a Task requires additional capabilities, that are only needed for amended/corrected workflows. Ways around this would be:

Isaac Vetter (Dec 28 2021 at 15:27):

1. modify step 9 - placer queries fulfiller for results, to instead have fulfiller POST results to placer; therefore amended/corrected results would also be a FHIR update.

Isaac Vetter (Dec 28 2021 at 15:27):

2. Add an additional amended/modified/corrected value to TaskStatus

Isaac Vetter (Dec 28 2021 at 15:27):

Why are the above bad ideas?

Vassil Peytchev (Dec 28 2021 at 17:19):

1. Option F is specifically for cases where both sides have a FHIR server. Changing step 9 moves you to option H, which is a generalized representation of multiple sub-cases of having a single FHIR server - one in the middle as depicted, one where the server is actually part of the Placer, and one where the server is part of the fulfiller.

2. Task.status is about the status of a Task in general, and it is not clear what a corrected/modified/amended status means in general. Use case specific statuses are supposed to go in Task.businessStatus, with the various stakeholders defining an appropriate binding. Having a code representing "output corrected/amended" or even "results corrected/amended" in businessStatus seems perfectly reasonable.

I agree that an additional Task for indicating corrected/amended results might be a burden for either side, so a reasonable first question for me would be, can we allow updates to a Task with a status of completed.

Vassil Peytchev (Dec 28 2021 at 18:03):

Looking at Task itself, it looks like the resource can be subject to any appropriate FHIR RESTful interaction even after the status is completed. The only restriction is that the status itself cannot be changed from completed to something else.

Isaac Vetter (Dec 28 2021 at 19:32):

1. Ah, optionH, yes, exactly. (I got confused/intimidated by this flowchart, but in reality, this is one of the simplest uses of Task -- in that there's only one FHIR server and it doesn't require bidirectional authnz). Thank you.

Isaac Vetter (Dec 28 2021 at 19:32):

1. Okay, yeah, thanks for explaining. We'd just use businessStatus to replicate/duplicate status functionality. I wonder if the Task resource's most important use-case is filling an order, and therefore having a first-class, or at least clearly specified corrected / amended task output is important.

Isaac Vetter (Dec 28 2021 at 19:32):

p.s. Vassil, I'd just Teams you, but I'm pretty sure you're out of the office on vacation ... happy holidays!

Lloyd McKenzie (Jan 03 2022 at 04:40):

Technically, the Task doesn't need to change at all - just the output changes. I.e. If you submitted a Task asking for a ServiceRequest to be fulfilled and the Task was marked 'complete' with an output of a DiagnosticReport, if the report later gets updated, that doesn't do anything to the Task at all. It's up to the requester to monitor the DiagnosticReport for change (by subscribing or polling) if they care to receive changes or, alternatively, for the system that maintains the DiagnosticReport to 'push' the updated version to anyone who'd accessed the original version. This process would be completely outside the 'fulfillment' process addressed by the original Task. (A whole lot of people might have seen the DiagnosticReport, and any or all of them might care that it had changed.)

Vassil Peytchev (Jan 03 2022 at 06:37):

I think the ability to change the businessStatus while the status is completed avoids some significant increase in complexity that would be present if the amendment/correction process is kept outside of the fulfillment process. I would expect that in the majority of the cases, there are business reasons to keep them part of the same process.

Lloyd McKenzie (Jan 03 2022 at 07:00):

But not all systems that will care about the change to the output resource will have an awareness of or even access to the Task. The fact the output (or one of the outputs) has changed is completely independent of the fulfilment workflow. We shouldn't mix Task into it.

Vassil Peytchev (Jan 03 2022 at 07:27):

Solving the general problem of how does everyone interested in the diagnostic report learn that there is an amendment/correction is a separate issue. What needs to be resolved here is how the Placer, who only gets informed about the existence of the DiagnosticReport through the Task, gets informed about the amendment/correction. Adding an additional and separate process outside the fulfillment process for this particular case seems to go against established business processes.

For the general problem, this extrapolates to: depending on the way a data consumer has become aware of the existence of the original DiagnosticReport, the data provider would use a similar way to make them aware of the amendment/correction. I.e. if there was a subscription, a subscription notification will be sent; if there was an operation, a similar operation would be used.

Virginia Lorenzi (Jan 03 2022 at 07:42):

We have defined our Business Statuses for Patient Request for Corrections and happen to have one that says Record Amended corresponding to Task.status=completed. I know this is not quite the same thing as what you are talking about but seems similar enough for me to pipe up. And in Patient Request for Corrections, we do see business statuses changing at times when status stays the same (for example when status = in-progress)

Lloyd McKenzie (Jan 03 2022 at 18:29):

Keep in mind too that the Task might just point to the DiagnosticReport - and what gets changed might be one of the Observations the DiagnosticReport points to. Having the business status on the Task changed when some arbitrary thing downstream of the Task changes seems unreasonable to me. Once you become aware of a resource and decide it's relevant to you, it's your job to monitor it for change. That's not part of the fulfillment process any longer.

Vassil Peytchev (Jan 03 2022 at 19:11):

I fully expect that if any of the DiagnosticReport.result Observations are amended, the DiagnosticReport.status would be appropriately modified. Any IG or profile that doesn't explicitly require this would be deficient. So we are explicitly talking about the DiagnosticReport.status getting the value amended, corrected, or appended within the context of Option F for managing a fulfillment workflow. Under these circumstances, I don't see anything unreasonable in changing the Task business status accordingly.

Lloyd McKenzie (Jan 03 2022 at 19:16):

Why would the DiagnosticReport status change if it wasn't changed itself?

Vassil Peytchev (Jan 03 2022 at 19:36):

I think that is a business rule. It is reflected in the way amended final results are conveyed using HL7 v2 messages - OBR -25 and OBX-11 both represent the corrected status.

---

Last updated: Apr 12 2022 at 19:14 UTC