Continuing my researches into representing IHE XDW profiles in BPMN:
The <collaboration> element in BPMN would represent the Workflow Profile. That contains <participant> elements which would represent the Workflow Participants. So far that makes sense. What isn't clear here is <messageFlow>, because XDW's notion of communication is through input and output documents, rather than explicit messages, but maybe there's a mapping here.
Each <participant> has a name, a description (in documentation), and references some processes. Essentially, we are putting the workflow participants in the collaboration as swim-lanes. Again, this part makes sense to me. I've seen at least one workflow where partnerMultiplicity is useful (an order placer for a read of an imaging study in which several order fillers could respond).
There's a few places where some routing logic needs to be explained, and where triggers and timeouts need to be addressed. I'm looking for task transitions to be triggers for other workflow tasks.
I'm not entirely clear on the distinction between the terms task (in Human Task) and process (in BPMN), because task seems like it could be smaller or larger depending on context.
One of the places where it seems like there would need to be some refinement in ITI is in the DSUB profile, because I'd like to support DSUB style notifications of workflow participants when their created/owned tasks have been transitioned from one state to another (each task has an owner and a creator -- when the task has its state changed, both the owner and the creator may want to know about it).
I think these might be some additional DSUB-like queries, which might be addressed by the Workflow Monitor participant.
The <collaboration> element in BPMN would represent the Workflow Profile. That contains <participant> elements which would represent the Workflow Participants. So far that makes sense. What isn't clear here is <messageFlow>, because XDW's notion of communication is through input and output documents, rather than explicit messages, but maybe there's a mapping here.
Each <participant> has a name, a description (in documentation), and references some processes. Essentially, we are putting the workflow participants in the collaboration as swim-lanes. Again, this part makes sense to me. I've seen at least one workflow where partnerMultiplicity is useful (an order placer for a read of an imaging study in which several order fillers could respond).
There's a few places where some routing logic needs to be explained, and where triggers and timeouts need to be addressed. I'm looking for task transitions to be triggers for other workflow tasks.
I'm not entirely clear on the distinction between the terms task (in Human Task) and process (in BPMN), because task seems like it could be smaller or larger depending on context.
One of the places where it seems like there would need to be some refinement in ITI is in the DSUB profile, because I'd like to support DSUB style notifications of workflow participants when their created/owned tasks have been transitioned from one state to another (each task has an owner and a creator -- when the task has its state changed, both the owner and the creator may want to know about it).
I think these might be some additional DSUB-like queries, which might be addressed by the Workflow Monitor participant.
0 comments:
Post a Comment