Stream: workflow
Topic: lifetime of a task
Eric Haas (Apr 14 2021 at 19:09):
We talked today about putting time limits on accessing a Task and I
looked to Task.restriction.period
Definition Over what time-period is fulfillment sought.
but I was informed this is not what it means. This Is confusing since I interpret the defintiion as the lifetime of a task - no matter the outcome
was does it mean and should there be a way to represent termination date on a Task?
@Lloyd McKenzie @Vassil Peytchev ?
Lloyd McKenzie (Apr 15 2021 at 05:54):
It means "when does the Task need to be executed". There's no general concept of a lifespan on a resource. In general, all resources are expected to hang around forever - which in practice means "until the system doesn't exist anymore" or "until performance considerations cause the data to be archived" or "until business rules say we're no longer required to expose it". So Tasks, once created, stay around forever unless someone deletes them or there are business rules that say otherwise.
Eric Haas (Apr 15 2021 at 14:15):
Lloyd McKenzie said:
It means "when does the Task need to be executed". ...
that is what Task.executionPeriod means
Vassil Peytchev (Apr 15 2021 at 14:22):
Can you elaborate what the use case is for "putting time limits on accessing a Task"? Is it that after a certain point in time, the Task is no longer "valid"?
Eric Haas (Apr 15 2021 at 16:52):
Vassil Peytchev said:
Can you elaborate what the use case is for "putting time limits on accessing a Task"? Is it that after a certain point in time, the Task is no longer "valid"?
essentially yes. a bit of background. these trackers from AMA re Payer access to Provider data...
When a task is complete what triggers the termination of a payer's ability to fetch data?
When and how do data servers terminate a client's set of requests? This should not be allowed indefinitely.
What method is used to determine the end of a client's access to a data server? Is that exposed by the client prior to first access data from the server, or is it left up to the client to simply "stop requesting" data?
Eric Haas (Apr 15 2021 at 16:54):
We discussed the first with the commenter and added some guidance business rules etc. but this triggered this question about the element in question - Task.restriction.period and why this concept of termination is not exposed in the Task itself
Eric Haas (Apr 15 2021 at 16:55):
also I think the first and third comment are duplicates and the second is handled by Task. executionPeriod but we have to discuss and get clarification from the commenter.
Eric Haas (Apr 15 2021 at 16:55):
@Celine A Lefebvre feel free to chime in here.
Vassil Peytchev (Apr 15 2021 at 17:31):
Form what I can tell, Task.status being set to complete is a sufficient trigger for the corresponding business rules. What is the value of having a timestamp? To indicate that the request must be performed by a given point of time, after which the task will be marked as complete?
Eric Haas (Apr 15 2021 at 18:11):
Still begs the question what is Task.restriction.period for?
Vassil Peytchev (Apr 15 2021 at 18:36):
The description of Task.restriction states
If the Task.focus is a request resource and the task is seeking fulfillment (i.e. is asking for the request to be actioned), this element identifies any limitations on what parts of the referenced request should be actioned.
To me that means that you can only use Task.restriction if the Task is for fulfillment of another request resource, and the restriction identifies what subset of the request is supposed to be fulfilled. A possible example could be a standing order (the request), and a single instantiation for fulfillment (the Task).
To answer the actual question, Task.restriction.period is only used in relation to another request resource, specifically regarding request.occurrence[x]
Eric Haas (Apr 15 2021 at 18:55):
ok thanks for clearing that up but it is certainly confusing and there should be clarifying language such as your comment added. Also an invariant to restrict its usage to only when focus is present.
Do you agree?
Eric Haas (Apr 15 2021 at 18:58):
What is the value of having a timestamp? To indicate that the request must be performed by a given point of time, after which the task will be marked as complete?
is that what Task.executionPeriod if for ( in other words, I need this done by next Friday)?
Eric Haas (Apr 15 2021 at 18:59):
i will make a tracker to clarify restriction FHIR#29680
Eric Haas (Apr 15 2021 at 19:03):
maybe an extension saying the output is available for some duration would be useful ( "you got 30 days to look at this")? I am spit-balling here but that is what I think the commenter is wanting the ability to control and expose to the requester. But I admit my ignorance here and this may be controlled by some other mechanism such as authentication scopes
Vassil Peytchev (Apr 15 2021 at 19:23):
is that what
Task.executionPeriodis for ( in other words, I need this done by next Friday)?
Doesn't look that way - the description references actual timings of the execution of the task, not requested ones. Currently it seems to me that you need a request resource to express that via request.occurrence - maybe restriction period can be loosened to not require focus...
Switching topics:
maybe an extension saying the output is available for some duration would be useful ( "you got 30 days to look at this")?
I assume this is in the context of one of the Da Vinci profiles, where the requester POSTs a Task, and the responder updates the Task with pointers to the resources to be pulled by the requester. In that case, can you add another output for this specific purpose? The implementation of the actual timing restriction, however, is best left to the authorization layer, I think. In general, the notion of disappearing resources is not something that is expected in a FHIR implementation
Eric Haas (Apr 15 2021 at 20:37):
thanks for your responses btw....
so in plain English Task.executionPeriod is just saying how long the task took if it is completed?
Eric Haas (Apr 15 2021 at 20:39):
Doesn't look that way - the description references actual timings of the execution of the task, not requested ones. Currently it seems to me that you need a request resource to express that via request.occurrence - maybe restriction period can be loosened to not require focus...
OK I'll update the tracker to propose that, it seems like a common thing to want to do...
Eric Haas (Apr 15 2021 at 20:39):
we all have deadlines
Eric Haas (Apr 15 2021 at 20:41):
I am out of my depths here, but is the authorization layer timeframes typically exposed to the data-consumer/end user ( "you got 30 days to look at this")?
Eric Haas (Apr 15 2021 at 20:42):
I think. In general, the notion of disappearing resources is not something that is expected in a FHIR implementation
its not that the resource disappears its that the requester's access to it terminates at some point.
Eric Haas (Apr 15 2021 at 20:56):
BTW I triaged FHIR-31900 and assigned to OO, will that be looked at by FHIR-I WF?
Vassil Peytchev (Apr 15 2021 at 21:37):
I am out of my depths here, but is the authorization layer timeframes typically exposed to the data-consumer/end user ( "you got 30 days to look at this")?
I don't think so. I meant that the implementation of the timing restriction (i.e. client X is not allowed to view resources A, B and C after time point T) is better done at the authorization layer (e.g. any authorization tokens are set to expire on the deadline). Indicating the deadline to a user is better done via something on the resource, my off-the cuff suggestion was to have an output of a special type to convey that.
Vassil Peytchev (Apr 15 2021 at 21:41):
BTW I triaged FHIR-31900 and assigned to OO, will that be looked at by FHIR-I WF?
From what I understand, OO will have to refer it to FHIR-I (and specify grouping of Workflow) in order to get a review there...
Eric Haas (Apr 15 2021 at 22:01):
OK I updated the tracker to FHIR-I /Workflow
John Moehrke (Apr 16 2021 at 12:38):
Note the specific use-case of authorizing access for a given reason for a given agent for a given time... seems like a good use-case to use for the development of the Permission resource. I am not saying what you have in Task is not right, but the authorization portion seems overloading Task; thus it might be okay for specific use but the permission concept would be a more reusable if we can get it well defined (it is not well defined today).
Vassil Peytchev (Apr 16 2021 at 17:42):
That's a good point - something for the Profile sponsors to consider. It is better that having a special output parameter.
Matt Reid (Apr 16 2021 at 18:06):
Would implementing a restriction at the authorization layer provide for Task limitations (e.g., this Task is allowed to reoccur for X patient(s) or this Task must be completed within 10 days) or would it limit the use of resources for specific tasks (e.g., using a resource for prior authorization but not for quality measurement) or both? Would the Permission resource provide for more granular control over resource use?
Last updated: Apr 12 2022 at 19:14 UTC
