If you are like most people, you worry much more about your kids not getting a balanced breakfast then you do them getting brain tumors. At least that's the case for me. And if I had to worry about the latter problem, I'd probably not be worrying quite so much about the former. Because the magnitude (cost, effort, impact, however you want to measure it) of the latter problem is so much bigger than the magnitude of a single instance of that other challenge (failing to get a balanced breakfast). But when you multiple that other problem by the thousands of times that it occurs, it could still have just as big an impact. Even so, these aren't equations that balance out prettily like those examples in physics or math texts.
This is one of the reason's that I've catapulted myself right into the middle of the workflow muddle in Health IT. IHE's XDW profile has a lot to offer here for both sides, the provider doing a simple task thousands of times, and in those crazy-expensive collaborations like tumor boards, where having multiply expensive specialists wasting even a minute of time is worth paying attention to.
What I'm trying to do right now is figure out how to make both of these different kinds of workflows be able to benefit from precise descriptions. Yesterday I explained how to integrate messages into a workflow, today, I'm going to discuss some of what I've discovered about event handling and signaling.
In BPMN, a signal is "like a message", except that it is broadcast to anyone who is interested in it. Rather than having a single sender and receiver (as in a message), a signal has a single thrower, and many possible catchers. One of the things I'm using signals for in the IHE representation of an XDW workflow in BPMN is a XDW workflow task state change. The XDW task I represent as a BPMN activity (specifically a sub-process). Within that subprocess, each state change that forces an update of the XDW document in the XDS repository "signals" the change. The event itself is named after the task and the final state. Start events are "caught" by the task which the event is named for. End events (either COMPLETED or FAILED) are thrown by the task for which the event is named. I use the error event to represent the FAILED case, and the normal end event in BPMN to represent the usual COMPLETED condition. Intermediate events for READY or IN_PROGRESS can be caught or thrown by anyone. The "thrower" is responsible for recording the new task state in the XDW document. The catcher simply waits until the task state is reached before doing anything else.
There's more I have to figure out in these cases, because I also have to figure out data flow with these signals, and also tie the signals into the IHE DSUB profile. That's for later posts.
Keith
This is one of the reason's that I've catapulted myself right into the middle of the workflow muddle in Health IT. IHE's XDW profile has a lot to offer here for both sides, the provider doing a simple task thousands of times, and in those crazy-expensive collaborations like tumor boards, where having multiply expensive specialists wasting even a minute of time is worth paying attention to.
In BPMN, a signal is "like a message", except that it is broadcast to anyone who is interested in it. Rather than having a single sender and receiver (as in a message), a signal has a single thrower, and many possible catchers. One of the things I'm using signals for in the IHE representation of an XDW workflow in BPMN is a XDW workflow task state change. The XDW task I represent as a BPMN activity (specifically a sub-process). Within that subprocess, each state change that forces an update of the XDW document in the XDS repository "signals" the change. The event itself is named after the task and the final state. Start events are "caught" by the task which the event is named for. End events (either COMPLETED or FAILED) are thrown by the task for which the event is named. I use the error event to represent the FAILED case, and the normal end event in BPMN to represent the usual COMPLETED condition. Intermediate events for READY or IN_PROGRESS can be caught or thrown by anyone. The "thrower" is responsible for recording the new task state in the XDW document. The catcher simply waits until the task state is reached before doing anything else.
There's more I have to figure out in these cases, because I also have to figure out data flow with these signals, and also tie the signals into the IHE DSUB profile. That's for later posts.
Keith
0 comments:
Post a Comment