ARIS Community - We Love BPM

BPMN Case Study: Collaboration Diagram for BPA Export Process

mcwendell's picture
by Wendel Souza in BPMN posted on 2010-09-23

Hello everyone,

I would like to share with you a BPMN collaboration diagram model for the BPA Export process. This process is related to the Brazilian healthcare industry, and is regularly performed by the healthcare providers (such as hospitals and clinics) contracted by SUS (Brazil's government-funded healthcare universal system). BPA stands for Bulletin of Ambulatorial Production and it is a production report consisting of detailed records of all medical procedures performed by the executing organization within a certain period (named monthly billing competency).

This production report must be delivered successfully validated according to several business rules mandated by SUS (such as, a given medical procedure must comply with certain ICD-10 codes). In the diagram, they are grouped within a sub-process called BPA Consistency and are not detailed for the purposes of this exercise.

I also modelled a rather complex activity which is a messaging broker acting as a relay/control in order to give to the end user full flexibility in executing the process, considering that upon validating each business rule certain user-defined parameters can be verified according to the validation resulting message. The message will then be sent to the messaging broker, which will verify if:

- which process can be triggered according to the message processed;

- the message must be shown to the user on screen;

- the message must be recorded in the audit trail;

- the message interrupts execution;

- additional messages that must be sent to external participants;

- etc.

Now, I would like to highlight some issues that I faced while drawing this diagram.

1. Converging sequence flows to a single point is rather difficult. For an example, each of the initial 3 tasks trigger an error event that must be sent to the messaging broker in another pool. In fact, as I stated earlier, any message must be to the broker. Initially, I tried to draw the message flow accross the pool boundary but the receiving object would accept only up to 3 connections. Then I tried an alternative - link event - and it seems to work, although now the message flows crossing the pool boundaries are not explicit.

2. Drawing result triggers with the task boundaries is neat, but adding too many events to it can make the model difficult to read, considering that a task can trigger several result messages (error, complete, business rule validated, business rule not validated, etc.) which is the case. Another issue with this point is that adding a description to the event can also make the model difficult to read due to weird positioning.

3. For readability purposes, I used exclusive gateways to converge message events that would be then sent as a single object to the messaging broker. I also did that with link events, and perhaps the later form is better because using gateways can imply that a decision has been made in a previous point.

4. Also for readability purposes, considering that each message event can have content AND/OR an user-defined interruption flag, I used an event gateway to split it, thus assigning the meaning that the system will behave according to the message's content and execution flag contained within.

5. For a message where content and execution flag (or 2 or more messages that are bundled together)  are mandatory, I used the parallel multiple event. I am not sure if a signal event (which is not explicit in most of the diagram) can be instantiated in runtime, because the signal event behavior is set by the message's execution flag. A workaround would be drawing the signal event along with the message event, as you can see in the end of the Messaging pool. If semantically correct, a neat way would be  drawing the parallel multiple event to assign the meaning that several events are contained within that must be treated in blocks. In programming (at least in C++ programming) this relationship can be implemented using a simple data structure (a matrix record with pointers).

6. BPA Consistency sub-process is a loop activity, because it goes through multiple records validating each one and verifying its compliance with SUS' business rules. It is unclear to me whether the loop conditions must be drawn within the sub-process or outside it. Thus, the BPA Consistency activity and its related objects may be incorrectly modelled in this diagram, considering that the messaging broker could be called within its execution flow. In order to make it work in that way that is designed now, BPA Consistency should be designed as an external sub-process thus requiring a call activity, which would control the loop execution, but in that case several tasks and some gateways would be necessary to be model the loop, thus effectively making  the call activity a sub-process.

7. I've read several posts on the Web by people complaining that BPMN 2.0 is too difficult for the common business user. I completely agree. From a business user perspective, he or she would lose it when seeing the weird markers on gateways, or the crosses on the events. Being myself a systems analyst with a decade's experience as a business consultant, considering that sometimes it's difficult to keep the two perspectives apart when modelling systems, my "business user persona" could not intuitively relate some established concepts/practices to BPMN 2.0 concepts, such as Exclusive AND is implemented by the parallel gateway. Other than that, I believe that BPMN 2.0 is a great tool that can empower the work of process consultants, but at least here in Brazil "many waters will flow below the bridge" until we see BPMN becoming standard practice mainly because notation languages are not regular courses on the curriculum of educational institutions, and most of business users (specially those that work in  the process-complex healthcare industry) are unable to draw even a basic workflow diagram. This is a true fact accross the organization, from bottom to top.

In closing, I would like to thank you in advance for any inputs/commentaries that you may want to add.

 

Cheers,

Wendel Souza

preview of BPMN Case Study: Collaboration Diagram for BPA Export Process ()
24046 Views
0 Likes
2 Comments
Sorry there are no tags
There are no attachments
Andreas Horn posted on 2010-09-24

Hi Mr. Souza,

thanks for sharing this model and your thoughts about it. It think it is a great example for logical process modeling with consideration of a lot of execution and runtime aspects.

First I would like to share my thoughts when I first read the model. Please don’t take this as a critic, it’s just what’s came to my mind while reading …

My overall impression is:

  • The model looks very complex and is difficult to read, especially the system pool
  • The reader must understand the exact differences in BPMN semantics
  • The model is going into execution semantics and seems to be rather on a logical layer (PIM) then on a business layer (CIM)
  • Who might be the target audience for this model? It seems to me that it might be an IT Architect or a Software Developer rather than a Business Analyst or Subject Matter Expert?

What I noticed in the Billing pool:

  • In the main process flow I am missing some sequence flows, it looks not very straight forward
  • Why aren’t the tasks “start bpa export” and “view export report” connected?
  • There is a start event with trigger (timer) but the end event is terminate one
  • “"This type of End indicates that there is a fatal error and that all activities in the Process should be immediately ended. The Process is ended without compensation or event handling."“
  • Gateway BPA Production found. Has no impact to the process flow (non interrupting event „Upon user interaction“. In any case a message is being sent to the message broker (but with different content).

What I noticed in the System pool:

  • There is a start event but no end event …
  •  The System process is started by the signal “to ad hoc messages” but there is no signal throwing modeled (instead there are link events)
  • There is a call actiity to start message broker, but used a sub process afterwards, is this the same or are these two separate tasks?

Now to your mentioned aspects:

1)      Yes, messages can be used for decoupling, but if there are too many of them visualizing all message flows can be tricky.

2)      Maybe different models for different purposes can help, e.g. one model for the happy case and one for exception handling.

3)      Hmmm. Have to think about this …

4)      This leads to the information architecture and data modeling. If there is a different content in the message, is the structure still the same? And are these messages different objects or they the same?

5)      As I have a technical background I can understand your solution with two events (one for the content and one for the execution flag). I am also not sure about signal events at runtime. I think it depends on the execution engine and on the runtime environment.  The signal events “continue execution” and “interrupt execution” are implying that the system process itself controls the execution. But what about a change of perspective: the system just sends messages and the user (billing pool) decides whether he would stop the execution?

6)      What about modeling the loop condition as an attribute of the task? What about an additional text annotation describing the loop condition? I agree with the first option: the message broker is one process and the BPA consistency is an external sub process (usage of call activity). I think which option you model depends on who controls the loop: either the external-sub process itself or the calling process. Again, sometimes a text annotation can help to make it clearer to the reader.

7)      Ok, the current debate, now it’s getting philosophical. ;-)
For me BPMN is just a language and you can be as simple or as precise / complex as you want, it depends on the stakeholders/ readers that are addressed with a BPMN  model and on the purpose of the modeling effort …

Some final thoughts:

  • What about splitting this whole exercise up into two or more models/diagrams (one for each pool plus collaboration)?
  • Did you already think about a choreography or a conversation diagram?
  • Maybe the content vs. control flag issue (which leads two a very complex event handling) can be solved with linking process perspective and with Data Architecture models in ARIS?

I would also be interested in what the other ARIS Community members think!

Best Regards,

Andreas Horn

Wendel Souza posted on 2010-09-27

Hi Mr. Horn,

Thank you for the reply. Indeed I greatly enjoyed your comments and I surely have benefited from your perspective. See my own comments below.

 

Comments on your overall impression:

  • The model was designed having IT people (Architects, Developers) as target audience, although business analysts with technical background (like me) could benefit from it too. Indeed it is based on a logical layer, otherwise architects/developers would have a hard time implementing the proposed solution architecture.

 

Comments on the billing pool:

  • The “Start BPA Export” and “View BPA Export Report” are not directly connected because the later task is only enabled after the system successfully completes the file export. The due message “BPA File Export successfully completed” is sent to the user, which then can view the report and/or download the file. I could add a decision gateway connecting these two tasks “Is BPA File Export successfully completed?” but in my opinion this would be only necessary if the diagram were designed to the business user audience, considering that the decision is performed by the system itself.
  • The end event is a message one, but indeed there is a flaw on the design. There should be a specific message end event for the “View BPA Export Error Report”, and not a link event as it is now. Thanks for noticing.
  • Gateway “BPA Production found?”: Perhaps the decision set should be moved to the system pool because it’s a system task, not user’s. Indeed a different message is sent out after the broker processes it and finds that the BPA Consistency sub-process can be initiated.

 

Comments on the system pool:

  • No end event in the system pool: I was unsure whether or not to add an end event even if there is a link-type start event. I couldn’t find a clear rule about this matter, I was used to model one start event and one end event for each process.
  • A start link event would be the correct type to initiate the system process.  Thanks for noticing. A multiple event is being thrown immediately afterwards, would it be redundant in this case?
  • The “Execute Messaging Broker” call activity is unnecessary.

 

Comments on the mentioned aspects:

1) Indeed there are many messages. For this process, there are at least 15 ~ 20 business rules being verified for each production record, and each rule validation can trigger multiple message outcomes.

2) After designing this model, and reading your comments, I agree that different models would be best because, as I have said, exception handling in this process is very complex.

4) Messages have different content, but same structure, except for the execution flag. Each message could be a different object but there could be an object with multiple messages (such as the return messages of  BPA Consistency’s execution).

5) In this scenario, the parameters’ message are user-defined prior to the process start. Since there are multiple thousand records being processed at once and dozens of rules being validated for each one, it is not advisable to send each error message to the billing pool because the user would thus be overwhelmed with uncountable messages. That is why I visualized a solution where the user would define the interruption conditions by setting parameters for each message that could be triggered by the process. This (message parameterization) task would be executed during deployment and seldom executed again after go-live. Thus, although the user does not interact with the system until processing is complete, he or she has complete control over the execution process by defining the interruption parameters for the desired messages that he or she wishes to control. This solution would also give the user total flexibility to add new rules that need to be validated and the possible outcomes (considering that the government may unexpectedly change the rules).

6) Thanks for clarifying the best approach for modeling loop conditions. I will keep this in mind in future drawings.

 

On your final thoughts:

  • I thought about modeling the solution using multiple diagrams but right now I have a hardware issue – ARIS Express runs very slowly on my computer – and thus it would be difficult to access the diagrams back and forth during the modeling. Now, the blame for the flaws in my diagram rests solely upon the computer JJokes aside, I would have 4 models for this process: one for the user pool, one high-level collaboration showing interactions between user and system, one for the messaging broker, and another for the BPA Consistency and BPA File Export sub-processes.
  • I didn’t consider a choreography/conversation diagram at this time because I need to do a further study of the BPMN 2.0 spec on this specific subject. The PDF has 550 pages! J
  • I still have to research the subjects “process perspectives” and “data architecture” on ARIS. I think that you are correct, because these messages are user-defined (thus  stored in the data layer) and its parameters are retrieved by the “fetch message parameters”. Thanks for the heads-up.

 

I would like to hear from the ARIS community too!

 

Cheers,

Wendel Souza

P.S. I have uploaded a new version of the BPA Export model addressing the issues raised by Mr. Horn. The file can be found at

https://docs.google.com/leaf?id=0BxycfmxHr16gMDgxNGZhYzMtMWQ0ZS00YjEzLWIzMWEtZmRjOGNiOWZmMDRk&hl=en.