Usually, a message recipient is ignorant of the workflow that resulted in the message being sent. The same message may be sent as part of multiple workflows, in multiple places within a single workflow, even multiple times within a single task. I think we need to fix that, because there are a variety of different ways services could be optimized or improved if we only knew what workflow was being done.
One of my present challenges in IHE is in defined how to describe an XDW Workflow Definition in BPMN. Mostly this involves mapping what has already been done in text in various workflow definition profiles to the appropriate BPMN representation. But there are some things that you can do in BPMN that we haven't addressing in IHE Workflow definitions yet, probably because we really didn't have a clue as to how useful that might be.
Two areas of present concern are Messages and Signals (I'll talk about signals in a later post). Now, in BPMN, a message is simply that. It could be used to represent an HL7 Version 2 message, an HL7 Version 3 message, a FHIR request, a SOAP Message, a DICOM service request, whatever. You name it. What I want to be able to do is associate a specific message with a workflow. Now, the metadata stored in the Workflow instance captures that association, but not in any way that is searchable. In other words, you need to know the workflow instance before you can determine the association with the message, and what I'm trying to find, given I only know about the message is the workflow instance.
Ideally, we'd all have workflow oriented systems, and this wouldn't be a problem. Each message would be linked back to a workflow and we'd know without much effort where and how that was done. But the reality is different. Some systems have and deal with defined workflows. Others don't. Some messages can occur as part of more than one workflow, or result from more than one task in a single workflow, or could occur multiple times in a single task. As the message receiver, figuring out where you are in the workflow be very valuable. At the very least it might provide you with some opportunities to optimize the work of the message based on the workflow (for example, you might cache patient data when that patient is involved in an active workflow).
So, what I'm proposing is that the sender of a message acting as a result of a workflow add the message identifier to the metadata for document describing workflow instance when that document is updated to describe the task that sent the message. The other piece of this would be to add that message identifier to the <taskEvent> element in the history. That way, once you've received a message, you could quickly and easily find the workflow and task instance which generated it.
Now, I don't advocate that services being performed should vary in what they do based on the workflow that they are part of. That would result in numerous private agreements inside services with different workflows. But it would allow for careful optimizations which could improve overall performance within and across workflows, and at the very least, would allow for information capture about the relationship of various workflows to activities affecting system integration. Imaging being able to say: 85% of XYZ messages received are result of ABC workflow. What would that do to your ability to optimize?
-- Keith
One of my present challenges in IHE is in defined how to describe an XDW Workflow Definition in BPMN. Mostly this involves mapping what has already been done in text in various workflow definition profiles to the appropriate BPMN representation. But there are some things that you can do in BPMN that we haven't addressing in IHE Workflow definitions yet, probably because we really didn't have a clue as to how useful that might be.
Two areas of present concern are Messages and Signals (I'll talk about signals in a later post). Now, in BPMN, a message is simply that. It could be used to represent an HL7 Version 2 message, an HL7 Version 3 message, a FHIR request, a SOAP Message, a DICOM service request, whatever. You name it. What I want to be able to do is associate a specific message with a workflow. Now, the metadata stored in the Workflow instance captures that association, but not in any way that is searchable. In other words, you need to know the workflow instance before you can determine the association with the message, and what I'm trying to find, given I only know about the message is the workflow instance.
Ideally, we'd all have workflow oriented systems, and this wouldn't be a problem. Each message would be linked back to a workflow and we'd know without much effort where and how that was done. But the reality is different. Some systems have and deal with defined workflows. Others don't. Some messages can occur as part of more than one workflow, or result from more than one task in a single workflow, or could occur multiple times in a single task. As the message receiver, figuring out where you are in the workflow be very valuable. At the very least it might provide you with some opportunities to optimize the work of the message based on the workflow (for example, you might cache patient data when that patient is involved in an active workflow).
So, what I'm proposing is that the sender of a message acting as a result of a workflow add the message identifier to the metadata for document describing workflow instance when that document is updated to describe the task that sent the message. The other piece of this would be to add that message identifier to the <taskEvent> element in the history. That way, once you've received a message, you could quickly and easily find the workflow and task instance which generated it.
Now, I don't advocate that services being performed should vary in what they do based on the workflow that they are part of. That would result in numerous private agreements inside services with different workflows. But it would allow for careful optimizations which could improve overall performance within and across workflows, and at the very least, would allow for information capture about the relationship of various workflows to activities affecting system integration. Imaging being able to say: 85% of XYZ messages received are result of ABC workflow. What would that do to your ability to optimize?
-- Keith
I added a couple of things to the FHIR Message Header for these workflow links in the beinning, but they got taken out on the 80% rule, since no one is actually doing them right now. (So it's extensions in FHIR)
ReplyDelete