IHE XBeR Workflow Profile in BPMN

The image below is what I generated as an example representation of the IHE Cross-Enterprise Basic eReferral Workflow profile in BPMN 2.0 notation that I generated Friday based on the work some of which has been discussed here so far.

If you want the BPMN file, you can get it here.

A discussion of each workflow participant's responsibilities follows:

Referral Requester

At the start of it's process the Referral Requester begins by executing the "Request Referral" subprocess.  When the subprocess starts, this participant may, but is not required to create the XDW document containing this XDW task in the CREATED state to indicate that work has started creating a referral for the patient.  The eReferral request is created and is an output of the user task [this user task is NOT recorded in the XDW Workflow document -- there should be a way to indicate that somehow, but I haven't figured that part out yet].  At that point the eReferral request document [and other relevant data, but again I haven't figured out how to represent that yet either] are used as inputs to the Schedule Referral CREATED message.  This message notation is the way that we show that the scheduling task must be created and recorded in the XDW document [the XBeR profile doesn't actually have this requirement -- there's some work to discuss here].  Finally the participant updates the XDW Document with the Request Referral Task in the COMPLETED state.

Referral Scheduler

The Referral Scheduler basically waits until a Schedule Referral Task is CREATED.  Arguably, according to the XBeR profile, this task is actually triggered by the completion of the Referral Request, and I think I could simply notate it that way, without having to deal with the Schedule Referral CREATED event.  However, from a best practice perspective, a Workflow Monitor will want to track task status change events, and time between CREATED, READY, IN_PROCESS and COMPLETED are all important and have well-understood semantics.  So even though CREATED on Schedule Referral task could be implied by a COMPLETED on the Request Referral, it seems best to me to make such dependencies explicit.  I think the way I did it last Friday may not be right though.

Now, this Perform Referral subprocess really cannot continue further without the patient participation, so I created a merge where a message [really the patient request to schedule the referral] needs to also occur before the workflow can continue.  At that stage, the Schedule Referral task is supposed to [according to the profile] go to the IN_PROGRESS state, which we show with the signal event.  Then the patient is scheduled.  Note that the data flow shows that the eReferral request coming from the incoming message being used in the Create Appointment user task.  The next task: Perform Referral is created, and then the Schedule Referral is marked as COMPLETED.

This diagram shows what happens if a patient does not schedule the referral after sufficient time has passed, which results in a failure of the Schedule Referral Task, resulting in a closure of this workflow with the referral workflow itself failing to complete in a normal state (as we use the Error State here in the final form).

Perform Referral  

Alright, I leave the description of this one as an exercise for the reader.  There's really very little in here that you haven't already seen.  Tell me if you cannot figure it out.