FHIR Chat · Task vs Provenance · workflow

Stream: workflow

Topic: Task vs Provenance


view this post on Zulip Michelle (Moseman) Miller (Mar 05 2020 at 16:06):

Do we have any guidance on the boundaries between Task vs Provenance?

The context behind asking this question is around measuring productivity of practitioners (such as schedulers, coders, clinicians) and/or turn-around-times from order to fulfillment (each step in that process). In order to do so, we need to represent who did what when. In some way, both Task and Provenance represent a form of someone doing something.

For example, thinking about appointments, schedulers take actions, such as book/create, reschedule/modify, check-in/patient arrived, cancel/patient no show. This seems to align with Provenance since the Appointment resource/status is being updated, but there are additional actions like communication/reminders or eligibility checking -- that don't always update the Appointment resource. Can we have a Provenance instance that doesn't actually impact the version of its target resource?

We also considered Task. Task does imply that it includes "actions" like signing an order or admitting a patient. However, is it really appropriate to create a Task to represent every "action" a user takes on a given resource? Task feels appropriate for some actions, but less appropriate as the means to document every little modification made to a resource.

view this post on Zulip Lloyd McKenzie (Mar 05 2020 at 16:27):

Task is a means of asking for something to be done and then tracking execution against that ask. So you'd only have Tasks if you were tracking the request. Provenance is about actions that involve creation/transformation of data. AuditEvent involves all actions - including those that don't create/transform but merely access data or don't actually touch data at all. So Audit event would let you capture things like log-on, log-off, looked at record A, created record B, went inactive, activated terminal, updated record B, etc. If you're talking about productivity analysis, I think AuditEvent is your best bet. Some of the audit events may involve creation/updates to Tasks, but there will be lots of non-Task stuff you'll care about.

view this post on Zulip Michelle (Moseman) Miller (Mar 06 2020 at 18:50):

@Lloyd McKenzie Was it intentional to add relevantHistory to Request pattern, but not Event pattern?

view this post on Zulip Lloyd McKenzie (Mar 06 2020 at 21:45):

Request resources tend to have more complex state transitions and many of the resources had history, while events typically have simpler state transitions and haven't generally tracked history. If we see several event resources adding history, we'd certainly add it to the pattern


Last updated: Apr 12 2022 at 19:14 UTC