Today was an exercise in patience for me, something that I do not do terribly well. During it, I heard from two different people with different viewpoints about how we should approach the Radiology Remote Read profile. I also realized that one of the reasons for the different viewpoints was that they were operating from different perspectives on workflow, and that the solutions each proposed was optimized for ONE of these perspectives.
One viewpoint is that of the service provider, who is only interested in their tasks, and accepting and processing them as quickly as possible. But another viewpoint is that of the overseer of the entire workflow for a patient, who is interested in seeing what is happening across all the different tasks associated with completing the work for that one patient. Yet another viewpoint is that of an overseer of the whole process, who is interested not just in what happens for one patient, but also looking at a roll-up aggregated view of what happens to patients in general.
I see a cube, painted with a workflow in various swimlanes, rotated in one direction, it shows a patient view, in another, a viewpoint of the service provider (workflow performer) and the tasks they must perform, aggregated and cut differently with some visibility down through the cube, perhaps the final viewpoint.
XDW works well when the patient view is at the forefront. It optimizes workflows around the patient. Task oriented structures like Universal Procedure Step optimize differently, for the processors of work list items, and the viewers of the queues managed using that structure. The two compete for attention, and neither adapts well to the viewpoint of the other.
Over the long term, I think XDW needs to shift from a Document Based workflow storage structure, to a resource based storage structure, where the resources are workflow instances, and task instances, and the workflow instance resources reference the various task instances. This would work fairly well I think in FHIR, because you could reference task resources in the Workflow Instance, and ask the tasks change state, the composition that is constructed of the Workflow Instance and all of its associated tasks becomes the "Current Workflow Document", yet its management is much simpler. To change the state of a task means that you only need ensure transactional integrity around the task itself, not the entire document. In the real world this happens. Given two performers of different tasks, they complete and update the task independently. It adds some complexity because it means that certain activities (services) need to be able to complete fully (this task completes as that one starts). We don't have those capabilities in XDW yet, and likely will not until the necessary task and workflow instances resources have a home, perhaps in FHIR, or perhaps elsewhere.
I say this, because if we had an infrastructure like this, I think the standards selection process we are going through now would be a lot less painful. I may even propose this tomorrow, because if I have to sit through another four and a half hours of the kind of discussion I sat through yesterday, I think my head must explode. The task instance resource becomes the way to implement the "task oriented queue". A query on the task instance resource for task instances of a particular type becomes the base query for the "queue" of tasks of that type to be performed in a system.
Where does that leave our poor Remote Read profile? It is perhaps a profile proposal ahead of its time. But, if we did this right, it might become a profile proposal that would be completed with half of what it needs, and be there to push us forward with its unmet requirements. Hopefully this will all gel in my brain before the next few hours of calls to discuss this profile.
In the meantime, to quote a friend ... please send more brains...
One viewpoint is that of the service provider, who is only interested in their tasks, and accepting and processing them as quickly as possible. But another viewpoint is that of the overseer of the entire workflow for a patient, who is interested in seeing what is happening across all the different tasks associated with completing the work for that one patient. Yet another viewpoint is that of an overseer of the whole process, who is interested not just in what happens for one patient, but also looking at a roll-up aggregated view of what happens to patients in general.
I see a cube, painted with a workflow in various swimlanes, rotated in one direction, it shows a patient view, in another, a viewpoint of the service provider (workflow performer) and the tasks they must perform, aggregated and cut differently with some visibility down through the cube, perhaps the final viewpoint.
XDW works well when the patient view is at the forefront. It optimizes workflows around the patient. Task oriented structures like Universal Procedure Step optimize differently, for the processors of work list items, and the viewers of the queues managed using that structure. The two compete for attention, and neither adapts well to the viewpoint of the other.
Over the long term, I think XDW needs to shift from a Document Based workflow storage structure, to a resource based storage structure, where the resources are workflow instances, and task instances, and the workflow instance resources reference the various task instances. This would work fairly well I think in FHIR, because you could reference task resources in the Workflow Instance, and ask the tasks change state, the composition that is constructed of the Workflow Instance and all of its associated tasks becomes the "Current Workflow Document", yet its management is much simpler. To change the state of a task means that you only need ensure transactional integrity around the task itself, not the entire document. In the real world this happens. Given two performers of different tasks, they complete and update the task independently. It adds some complexity because it means that certain activities (services) need to be able to complete fully (this task completes as that one starts). We don't have those capabilities in XDW yet, and likely will not until the necessary task and workflow instances resources have a home, perhaps in FHIR, or perhaps elsewhere.
I say this, because if we had an infrastructure like this, I think the standards selection process we are going through now would be a lot less painful. I may even propose this tomorrow, because if I have to sit through another four and a half hours of the kind of discussion I sat through yesterday, I think my head must explode. The task instance resource becomes the way to implement the "task oriented queue". A query on the task instance resource for task instances of a particular type becomes the base query for the "queue" of tasks of that type to be performed in a system.
Where does that leave our poor Remote Read profile? It is perhaps a profile proposal ahead of its time. But, if we did this right, it might become a profile proposal that would be completed with half of what it needs, and be there to push us forward with its unmet requirements. Hopefully this will all gel in my brain before the next few hours of calls to discuss this profile.
In the meantime, to quote a friend ... please send more brains...
0 comments:
Post a Comment