It's taken me a while to get back to the work I've been doing in Workflow for FHIR. I finally got the Task resource rebuilt as we had discussed back in late November so that people can see what it looks like as a resource, and so we can start playing with it hopefully at the next FHIR Connectathon.
The resource is based in part on IHE's Cross-Enterprise Document Workflow, and on WS-HumanTask, and from there back to a long list of prior workflow standards. The task resource represents a task to be performed. It has a name, possibly a code to go along with that, and hopefully a description. The subject of the task describes in some way, or provides the key input in indicating what should be done. This could be a procedure, an order, or some sort of request. The take basically says "do this thing", where the combination of the subject and the task type represents the thing to be done (e.g., refill a medication). In that example, type supplies the "verb", and the resource is the noun that is acted upon.
The task has a creator and may have an owner. Creator is important because creation of a task conveys some sort of privilege, as does ownership. I don't actually say what privileges are granted, because that might vary from system to system, or even within systems across different workflows. Task has a state machine that is loosely modeled after the state machine of human task.
There are a number of operations that I've defined on a Task resource which are shorthands for different kinds of things that are often done to tasks in a workflow. These operations can be readily mapped to WS-HumanTask operations in many cases. I've simplified and/or combined some because I could readily merge semantics. For example, setting an input or output to nothing effectively removes that input or output, so there is no need for a separate delete operation.
Some of these operations assign or delegate ownership of the task. Others set inputs or outputs. Yet others progress the task through its state machine. These operations need not be supported by all implementations, but their presence and definition allows for some very controlled access points to be established for task management. This allows access control mechanisms to be put into place that ensure that only authorized users are manipulating workflows in an appropriate fashion. A system implementer might allow unfettered read access of its workflow, but then only allow certain kinds of systems (based on their role [e.g., as owner or creator]) to access different operations, and restrict which operations can be performed based on the state of the task. For example, a completed task might not allow any access to the start operation. Only a system task might be allowed unfettered write access to the task resource.
This enables robust task management at one end of the spectrum, and very simple workflow management at the other end.
While IHE distinguishes between Workflow and Task, we recognized in FHIR that this view of workflows is really in the eye of the beholder. One person's (or organization's) task is another organizations workflow. The provider says "do this lab test", and thinks of that as a task, but the lab has a whole workflow around the test, involving receiving the specimen, staging it, performing the test using the automated equipment, validating the results, reporting on them, and properly disposing of, or preserving the specimen as necessary. So, there's only a task resource, and it can reference subtasks to address a complex workflow like that just mentioned.
I'm glad to have gotten this much done today, my first full build of FHIR today took me an unprecedented 103 minutes, although later full builds were down around 15-20 minutes or so. 've got quite a bit more to do to add documentation to this resource, before I'll consider it ready for some connectathon testing, but this is a good (re)start.
-- Keith
0 comments:
Post a Comment