Stream: workflow
Topic: Task adding and changing outputs
Virginia Lorenzi (Jan 24 2021 at 04:44):
In a similar way, as a task progresses, it could produce outputs. Maybe it produced a preliminary output that is later replaced with a more final output. Maybe it produces different outputs at different times that are all useful information. There is no way to sequence outputs or to timestamp them. Also, to someone queries the Task over a period of time, if they see Task.outputs have A on first query A, B on second query, C, B on third, and D on fourth, would that mean all outputs A, B, C, D are valid or only D is? Or only D is at the end but A, B, and C were all valid at an earlier point but now aren't? Or D is replacing A, B, and C? I am guessing you will say - that is up to the IG. It seems having ability to tie inputs and outputs to status, business status, and/or to have a timestamp on each one might help. Task.inputs and Task.outputs remind me of the V2 snapshot update mode problem.
Vassil Peytchev (Jan 24 2021 at 05:08):
Any time you allow write access to a client, you can have problems. What you are describing are fundamental issues of concurrent programming, and they have solutions.
FHIR distinguishes between update and patch, and has strong recommendations for update. These recommendations can become requirements in an Implementation guide.
A single Task instance doesn't have to contain all the pieces of the request for corrections - for example, the request to notify other participants of an accepted correction can be another Task...
Lloyd McKenzie (Jan 24 2021 at 20:45):
Can you give a concrete example of when you'd have multiple outputs and would care what order they'd been added? (With history, you could find that out, but I really can't think of a situation where it would matter.)
Virginia Lorenzi (Jan 27 2021 at 05:25):
Order matters if we are trying to use inputs and outputs to represent a conversation. But forgetting that, I still think you have the repeating segment update problem with Task.inputs and Task.outputs that we had in V2 because in essence they are the same as V2 repeating segments.
There is no way to signal the delete of a specific input, addition of a specific input, or replace of a specific input (in V2 this would be done with action code and unique key) @Paul Knapp @Debi Willis
V2 had two solutions:
Snapshot mode - sender must send all, receiver must assume that senders list is the current list and delete whatever it has.
or
Action Code/Unique Key - each segment (in this case each input and each output) would include an action code (add/delete/replace) and a unique key. The sender would mark each segment with the appropriate action code. The receiver would find the right piece of data using the unique key and then carry out the action specified by the action code on that piece of data. Any data items not specified by the receiver would be ignored.
Here is an example, suppose I have a Task to concoct a compound medication and the inputs are ingredients. On an update I would want to be clear which inputs are being changed and how (add/update/delete) or I could end up with the wrong compound.
Inputs and outputs do not have actioncodes and unique keys, so only snapshot mode is possible. In my V2 experience, we still rarely ever deleted the stuff on the receiver side because we just did not feel safe that the sender knew what they were doing. An important example of this was an update message with a list of allergies.
René Spronk (Jan 27 2021 at 08:25):
Given that the references are from the Task to 'various inputs', it is indeed snapshot mode (to use a v2 term). The ordering party is assumed to know whet they're doing, so if a an 'input' no longer appears when the Task is updated, then apparently there's a reason for it no longer being there. If you want a server to have control over this, you could define an operation which performs some additional server-side processing on any task updates.
Lloyd McKenzie (Jan 27 2021 at 14:59):
inputs and outputs should not be used to represent a conversation. Task.input indicates information that is necessary to allow fulfillment of the Task and Task.output represents the result of the Task.
Lloyd McKenzie (Jan 27 2021 at 15:00):
In most situations, all inputs should be present at the time the Task is submitted and outputs don't show up until completed. If outputs show up sooner, they represent work in progress or work done to-date.
Debi Willis (Jan 27 2021 at 15:28):
Lloyd McKenzie said:
inputs and outputs should not be used to represent a conversation. Task.input indicates information that is necessary to allow fulfillment of the Task and Task.output represents the result of the Task.
I think this comment and the statement that notes is for internal comments made about that task pretty much pushes conversations to be captured via communication.
Vassil Peytchev (Jan 27 2021 at 19:27):
the statement that notes is for internal comments made about that task
What statement is that?
Virginia Lorenzi (Jan 27 2021 at 19:29):
A process can''t have an output from a particular state in the process (like accepted)? We had a case for that. Having outputs at the end only would make it easier. Not allowing inputs to change would also be helpful
Virginia Lorenzi (Jan 27 2021 at 22:58):
Lloyd said that.
Five formal communications:
We have the patient requesting a correction
We have the patient expressing their disagreement to a denial.
We have the denial explanation and patient recourse explanation
We have the correction being accepted with proof of correction
We have the provider side rebuttal.
And less formal communications but still important:
We need to extend an additional 30 days.
Can you explain this part of your request?
What is the contact information for the provider you listed?
Here is explanation blah blah.
Her address is blah blah blah.
My understanding of notes would be stuff like this (which I don't think is as useful for the patient as the other two)
- lisa assigned
- Reached out to Dr. Smith
- Dr. Smith is no longer with practice - reached out to Dr. Allen
- need input from patient. Called and left message
- Need additional time - invoking 30 day extension
But maybe we just didn't really fully understand. Task is a meaty resource.
Virginia Lorenzi (Jan 27 2021 at 23:18):
@Jeffrey Danford also has expressed concerns about using Task.note to contain the conversation between patient and provider, but I am not sure what his concerns are.
I would think that I would need very well-behaved clients and servers such that the only part of Task changed is the addition of new notes that are clearly from the patient. Perhaps use PATCH or put careful logic behind the PUT. Need to be able to tell its a new note entry authored by the patient.
I can understanding having high standards for the server but how will I know every client will do the right thing?
Contrasting that to the post of a communication resource which seems to make ownership of fields more clear. (the communication resource the requester posts originated from them.
Lloyd McKenzie (Jan 27 2021 at 23:56):
My recommendation would be that "requesting a correction" and "requesting notice of agreement" being separate tasks - they are separate requests and will have separate statuses. The output from a request for a correction will either be a rejection or an indication that the change(s) have been made. If we allow a request to cover multiple changes, it might also be a mixture - i.e. change A and C done, change B won't be done, here's why. The output from a request for notice of disagreement would be "disagreement published (and possibly 'with this rebuttal')". Extension to timeline would be captured as business status and/or notes.
All of the back and forth can be captured as 'notes'. There's no guidance on Task.notes that says that it's for "internal comments only" (and I don't really understand what that would mean). The whole point of notes is to allow anyone involved with the Task to capture comments related to it. Those can be questions, answers, plans, status updates or other things. It would not provide a targeted back and forth, but given that there will typically only be two parties involved with the Task, it should be fine. And if you end up with multiple parties (patient, patient rep(s), provider(s), medical records staff), they probably all need to be looped in on the information being shared, so putting stuff in notes may actually be better than targeted back and forth messages. Yes, you'd have intermingling of "request/response" notes and "workflow" notes, but it's not clear that'd be problematic.
I'm not saying that we can't pursue a generic "email over FHIR" mechanism, but I don't think we need to get that in place in order to have a "good enough" solution that uses Task and Task alone.
Virginia Lorenzi (Jan 28 2021 at 10:11):
Disagreement was always a separate task.
Virginia Lorenzi (Jan 28 2021 at 10:13):
I am not thinking granular at all. I think it should be Request blob. Provider comes back with outcome which could be accepted and corrected, denied, or a mix. if its either of the last two patient could do a disagreement
Debi Willis (Jan 28 2021 at 20:37):
Vassil Peytchev said:
the statement that notes is for internal comments made about that task
What statement is that?
When we were designing the IG, we were told that notes were used by staff to document comments about the task. It could contain "Sent to Dr. Smith for review", "With legal", "Patient very angry. Said they are calling their lawyer." They might not be something that is meant to be shared with the patient. It is the only place the staff has to share comments about what they are doing on the task. @Jeffrey Danford also commented during the connectathon that notes was for internal use and not a good place to put the conversation with the patient.
Lloyd McKenzie (Jan 28 2021 at 21:29):
The notion of notes being 'internal' vs. 'shared' is an interesting one. I think that's going to be a fun issue everywhere notes can appear. We might actually want to look at adding an additional element (or at least a standard extension) to the Annotation type to capture 'audience' or 'restriction' or something - because notes on procedures, observations, etc. might well contain things that are deemed 'sensitive' (don't tell patient) and other things that the patient absolutely ought to see. (We'll leave aside, for a moment, when/if it's a appropriate to put stuff in the patient record that the patient can't actually see.)
Lloyd McKenzie (Jan 28 2021 at 21:32):
I think the notion that none of the notes on Task would ever be visible to the Patient is problematic. If we resolve that issue, that may make the desire to use a separate mechanism for patient discussion less necessary. (I'm not totally opposed to having separate Communication instances for conversation, but think that added complexity should be avoided if we can find a way to make Task work alone.)
Last updated: Apr 12 2022 at 19:14 UTC
