Advantages and Disadvantages: Event Driven Process Chain

Keywords: uml advantages and disadvantages

The reason to choose UML to create a model among the other choices is its simplicity and ease of use. The structure of the end model obtained using UML is easy to design. The given case on hospital procedures was simple to understand but when comes to addressing the problem with a model, its an entirely different story. This is because the given case consists of four core issues and each issue has to be addressed properly. We identified the actors use cases, functions and their attributes at the first place. The very next step was to interpret the identified elements into graphical units. These are pretty much the steps involved in designing the model using UML.

The first constraint to arise was how to handle external actors while using use case diagrams. Next on the priority list was whether to implement the model using swim lanes or normal flow when it came down to activity diagram. With reference to the hospital case, the entity �general practitioner� which was suppose to be interpreted as function it was rather used as a external actor. Similarly the standard swim lanes which were to be used in accordance with activity diagram protocol were replaced by using the alternate normal flow diagram.

The initial work of interpreting the given problem into workable modeling units was carried out. It was followed by dividing the complex issue into small modules so as to achieve better efficiency. The model is highly influenced by �modular programming approach�. That approach helped us a lot in understanding the complex issue by dividing it into number of sub-issues and addresses them individually. These collections of smaller solutions ultimately added up to the consolidated solution.

Reflection on the modeling process: (EPC)

It was an entirely different approach from UML model. As far as we are concern, this model is an enhancement of a basic flow chart. This is because, the shapes, the flow and the structure the model is highly influenced by a flow chart. The model required extensive analysis to segregate the model units from the given case. It takes quite some time to get accustomed to new rules of modeling difficulty arises when we tried to give a base model for the entire case so as to give a skeleton approach. Adding to the complexity, the use of logical connectors and splitters was a tedious job.

Modeling the various issues and the core processes posed a variety of problem during the early stages. For example usage of logical splitters and connectors was different from using other branching structures. And also the rules of using units like �events�, �functions� and the others was to be kept in memory prior to joining them with the other units. The structure of the model was a long one when compared with that of the previous model. Some portions of the problem given had to be modified, which in process gave away parts of the literal components.

Adjustments and modifications were carefully tailored so as to meet the conditions and rules of how the model to be made. The work was to pick out units with reference to EPC such as events, functions and organizational units etc. we identified events from all the core issues which were to be followed by functions. In a similar fashion the other model units were sorted out. After that these individual units were integrated as according to the rules of EPC. The areas in which logical connectors were to be used were identified and the connectors were put into their place. This ensures proper structure and flow of process.

Reflection on the modeling Language: (UML)

This is because; the given case is simple but an elaborate one. Thus, a reader could easily identify the number of entities involved and their roles and still could progress through the entire model which is an elaborate one without losing the track of the process. How and when a reader could get confused with the different models depends on the knowledge of the user, that goes as a different topic altogether. But even an ordinary reader could spot the persons, the different processes and the flow of the model readily and easily.

And also the UML diagram itself is quite easy to design which involves few graphical elements. Unlike other modeling languages, UML emphasizes on �use cases� which are in essence are nothing but notations of the essential activities results and the functions which constitutes to the entire process. It helps the user to easily get used to the protocols of using use cases and implement them. Since the actors and external actors are depicted against the use cases, its easy to connect the performers of the action and their sub sequent results. Complexity of producing a suitable model for business process is reduced to a greater extends.

As far as the hospital case is concerned, UML is the most suitable modeling language to aid the user as well as analyst due to the above said reasons. This case produces four core processes starting from admission of patient till the discharge of patient, which involves quite a lot of actors and their functions which in turn produce the given results. One could easily interpret statement into the business model using UML by just using a handful of graphical units without any ambiguities. We say this so because, the four critical issues are addressed with the specific actions being transferred into particular use cases one after the other in a typical UML fashion. Each actor is connected to their actions and the directional connectors indicate the flow of action.

For example: A nurse in this hospital performs the following actions like allotting bed, recording the admission time, conducting ward rounds, providing medical care and updating registers. It is evident from the above said reasons that the role of nurse involves quite a few activities and these activities are supposed to be recorded and depicted in business model to ensure complete data base of the events and their functions. Adding to these facts, one needs to know that these actions are not consecutive and happened in a sequence ware the activities performed by other actors coming in between them or preceding them or succeeding them. Only in UML we could connect the specific actions performed by distinct actors without getting entangled in the collection of various other functional units.

In a nut shell, a reader could grasp the flow of different actors and their functions at the same time in a single diagram.

The only substantial drawback of UML is not able to implement logical flow and branching options i.e. in the given hospital case, there are instances were two parallel events occur where one cannot use UML modeling to depict the parallel events occur For example: A nurse provides medical and general care whereas in parallel another nurse prepares the necessary test forms and forwards them to the physician. Using UML we interpreted this problem statement in the following manner �provides medical care�, �prepares test form�; a reader could not understand whether these two processes occurred at the same time or at different instances. So these processes were placed one after the other and connected to a �nurse�. From the above example we can infer that UML does not aid plotting of parallel events.

The key factor missing in UML is a lack of logical decision makers and branching functions example in discharging of patient, there is logical branching condition which needs to be satisfied, the condition is the patient is to be cured of diagnosis or else the entire treatment cycle has to be read. It is not possible in use case diagram as these two unique events need to be addressed as separate use cases rather than branched activities or events.

Comparison of Languages:

� Logical connections and decisions cannot be performed in UML use case models and it could be done in EPC.

� We have faced little difficulties while addressing parallel processes in use case diagram.

� Structure and integration could be expressed more efficiently in EPC rather than UML.

� Only in UML we could connect the specific actions performed by distinct actors without getting entangled to other functional units.

Advantages of UML:

UML is the popular approach of visualizing and documenting the software systems design. UML gives object oriented design concepts and it�s independent of specific programming language. UML is a popular and technique for documenting and modelling system.

It ensures set of symbols to represent graphically the various components and relationships within the system and UML can be used for business process modelling and requirements modelling, it mainly uses to support object oriented system analysis and to develop the object models. Real time UML, this approach is the application of UML to design the real-time system. It emphasises the system with structural and behavioural language models and those designing modelling include the architectural mechanical and detailed design .Object oriented methodologies have employed in the construction of the real time system.

The introduction of IT for hospital case is expected to be a major issue in re-designing the processes. Therefore, some of the functions will be speeded by developing suitable software and hardware artifacts. To do so, the business models should be seamlessly matched to software engineering models. As a standard, UML seems to be currently the best choice for expressing such models

Disadvantages of UML:

UML has still no structure and specification for modeling user interfaces. From our point view, the main disadvantage of this model is lack of formality. UML is used in a implementation process and we wish to use it for our stage of this process for consistency and to protect the user translating work into a innovative language. The other related reason is simply that if users are familiar with UML it may be worth keeping it, as a �front end� to a formal language.

Advantages of EPC:

One of the main advantages of the EPC is that it is both powerful and easily understandable for end-users. EPCs are often used for capturing and discussing business processes with people who have never been trained in any kind of modelling technique. Although EPCs can be understood even by untrained personnel, the same models can be refined and used for the requirements definition of an information system. This is one of the reasons that both many end-user companies and many software vendors are using EPCs for business process modelling. The existing connections with traditional modelling methods (e.g. data models, such as the entity relationship- model) have been very useful for developing information systems for process-oriented organizations. Therefore many users have asked for a similar kind of connection between EPCs and UML diagrams.

Comparison of process:

? UML is richer of concept than ARIS because of the presence of Stereotype, and this enables a higher view of modelling for specific cases.

? ARIS allows personalisation of the model as one concept is represented in many symbols.The software platform also allows integration of business and IS concepts.

? EPC method and UML have different scopes of business modelling. There is a need to use one language in both software and business fields.

? Logical connections and decisions cannot be performed in UML use case models and it could be done in EPC.

? We have faced little difficulties while addressing parallel processes in use case diagram.

? Structure and integration could be expressed more efficiently in EPC rather than UML.

? Only in UML we could connect the specific actions performed by distinct actors without getting entangled to other functional units.

Reasons for choosing EPC:

� The EPCs meet the requirements to put forward with respect to the ease of understanding by non-specialist in modelling.

� EPCs can offer a multi-level view of the process, since a function in an EPC could be explained in more detail by means of another EPC.

� EPCs give a consistent, formally supported process oriented language that can ensure simulation of the processes.

Comparison between EPC and UML:

When comparing the EPC and UML for modelling business processes, there are some aspects from which we can view the correspondences and differences between these two methods. The comparisons can be mainly grouped into three aspects:

Context:

This aspect covers in which context the EPC or UML are developed and used. Both diagrams can be used for modelling business processes, but both have different contexts under which they are developed.

Ambiguity:

In modelling business processes, it is possible that the EPC or UML diagrams that are created would be ambiguous. Examples of this are implicit decisions, possibility of having blocking, etc. Therefore it is necessary to take a look at the exactness or ambiguity of the diagrams constructed with EPC or UML Activity Diagram.

Notation/Terminology:

Both the EPC and UML activity diagrams have similar concepts � such as fork/join, branch/merge, atomic/extended activity, etc � but they are represented using different notation and terminology. Some notation does not have a counterpart in the other diagram. This indicates the semantic differences between them. Therefore we will compare both notations and terminologies to see the correspondence of symbols of one diagram in another diagram and the differences between them.

Context

Even though the EPC and UML Diagrams are used or can be used to denote business processes, they were developed in different contexts. This pragmatic difference comes from the different modelling approaches that drive the EPC and UML. There are two approaches to model a system.

Process-oriented modelling:

In process-oriented modelling, the main focus of modelling a system is the process inside the system. A process consists of sequences of events triggering activities. The events themselves are the results of other functions apart from initial events that trigger the whole process. By introducing logical operators, this event-driven control structure can be expanded to a complex control flow illustrating relevant decisions and potential for concurrency that happen in the process. This process-oriented modelling is the basis for the EPC, which found its way as a standard for modelling business processes of an enterprise. The basic EPC model can be extended by further semantic components to illustrate the elements participating in the process such as information objects and organization units.

Object-oriented modelling:

In object-oriented modelling, the main focus of modelling a system is the objects inside the system. A system is a bunch of objects that have relationships among them. These objects communicate each other by exchanging messages. An object is a discrete and differentiable entity in a system. Each object has properties and exchanges messages through operations. This object-oriented modelling is the basis for UML, which is mainly used in software development such as enterprise information system. Initially activity diagrams are targeted for modelling the dynamics of internal object�s actions. Because of its characteristics similar to flowcharts and its capability to visualize concurrent activities, they can be generalized to model operations, use case scenarios, workflows and business processes.

Exactness:

The formal description of EPC can be used to analyze the syntactical correctness of an EPC diagram. However in practice there are still some problems regarding the exact meaning of some elements in the EPC. The ambiguities arise from the analysis of how elements in an EPC diagram interact in a flow of process. Those ambiguities are:

Conjunction of start events:

An ambiguity concerning the modelling of start and end events occur in the EPC. It is obvious that nodes without input edges are the start events and similarly nodes without output edges are the end events. But the interpretation is left to the reader, which combination of start and end events he should see as admissible, that is, as seen in reality. The problem becomes obvious when there exists �events from the side� � meaning start events in the middle of the process which has been started some time before by the first start events. These usually represent communication with external entity. However this conjunction of start events is not explicitly modelled in EPC.

Semantics of logical connectors:

There are three logical connectors in EPC, that is, �XOR�, �OR�, and �AND� connectors. In chapter two we have already discussed how to connect these logical connectors to events and functions in the control flow. We know that because an event cannot be used to make decisions, an event cannot be followed by logical connectors �XOR� and �OR�. Nevertheless there is also an ambiguity in the semantic of logical connectors, especially in the �XOR� and �OR� connectors. Consider the case in figure 4.1. In the case of �AND� connector, the function F1 can only start when both events E1 and E2 occur. That is clear, the �AND� connector serves to synchronize by waiting until both events have occurred. In the case of �XOR� connector, the switching rule of the �exclusive or� connector says that if either event E1 or event E2 occurs, the following function F1 can start. One question arises, what does the rule mean, when both events occur one after another, for example E1 occurs first then after some time E2 occurs? Can the function then run twice: The first time after the occurrence of the first event, and the second time after the occurrence of the second event? There are several interpretations for what the modeller wants to express, when he uses this connector:

� When both events occur at the same time, they block the following function, or

� Both events cannot occur at the same time, or

� When the following function starts, then exactly one of both events must have occurred.

For the �OR� connector, the following rule applies: when at least one of the events occurs, the following function can start; when both events occur at the same time, the function can only start once. A similar question arises for the �OR� connector as for the �XOR� one � that is, whether the function runs once or twice. Again, there are several interpretations when the events occur one after another, but in the case of �OR� connector it is obvious that when both events have occurred the function is not blocked.

E1 E2 E1 E2 E1 E2

AND XOR OR

F1 F1 F1

Two events arriving at one connector

Deadlocks and Loops:

For simple EPC graphs it is easy to analyze whether the graphs work or not, but for complex graphs we need a tool to analyze them. It is possible that even when the graph is semantically correct according to the definition of EPC, still an analysis shows there can be deadlocks when executing the process according to the diagram. A deadlock means that in reality when the start events occur � thus the process runs � after some time the process is stuck somewhere in the graph unable to reach the end states. Possible causes of deadlocks are mismatches of logical connectors � especially in complex graphs where connectors link to other connectors � and different interpretation of logical connectors. For an example an �OR� connector can work either in �XOR� mode or in �AND� mode. If an opening �OR� connector works in ��XOR� mode but the closing �OR� connector works in �AND� mode or the other way around, a deadlock would happen. This can be solved if the closing �OR� connector �knows� in advance in which mode the opening �OR� connector works.

Another possible problem discovered by graph analysis is looping. A loop may cause a process to run forever. This is usually not intended to occur in business processes.

Notation/Terminology

Since both EPC and UML Activity Diagram serve to visualize processes and workflows, both diagrams have similar notations for some common terminologies such as activities, branches and merges, forks and joins, etc. as well as some notational differences between them. These notational correspondences and differences will be discussed here and we will use the result of these notational comparisons for the translation from EPC to UML.

The notational correspondences and differences of both diagrams can be categorized as follows:

Functions and Activity/Action States:

Both the functions in the EPC and activity/action states in UML Activity Diagrams are the active elements that represent what a person of an organization unit or an actor in a use case diagram do with respect to the process. Therefore it is clear that functions and activity/action states represent specific business tasks within a company. That means that they share the same role within their respective diagrams. An activity or a function usually takes some extended time to execute.

Events:

In the EPC an event is a passive element that triggers a function and is a result of another function. The events can also show the change of status of an object over the process chain. There is no correspondence of events in activity diagrams, even though the activity diagrams are based on state diagram, but the states are mostly activity states, while an event is not an activity. Nevertheless if we take a look at the example of EPC some of the events, especially those that are the direct results of a function, are redundant. For example in the figure 4.2 the result of the function �capture requirement� is �requirement captured� which means that the resulting event is just to show that when the function finishes control will pass to the event which in turn triggers the next function. However in activity diagram this intermediate result is not explicitly declared. This is because the transition in activity diagrams means that as soon as an activity state finishes it does not have to wait but instead it will trigger the next activity.

Control flow and Transitions:

Control flow in the EPC corresponds to the transitions in UML Activity Diagram. Control flow is used in a process-oriented approach to show the process chain over time from one event that triggers a business function that in turn results in another event. Activity diagrams are based on state diagrams in which transitions are defined; transitions show the change of states over time. Control flow and transitions are instantaneous; they are assumed not to take so much time. However in the EPC, between two functions there can be some time for the control/token to be kept in an event.

Logical connectors:

Logical connectors allow the splitting of control flow in the EPC and transitions in activity diagrams. For the splitting regarding to taking a decision between different alternative paths, both diagrams have a similar construct, which is known as branch/merge. The branching and merging of control flows in the EPC is represented using the logical �XOR� connector plus the events following it. The same mechanism in activity diagrams is implemented using the decision diamond symbol and transition labels. Both diagrams also support the notation of parallelism known as fork/join. The forking and joining in the EPC is shown using the logical �AND� connector while in activity diagrams it is shown using the synchronization bar. Actually a synchronization bar corresponds to an �AND� connector together with the events before it, because a synchronization bar waits for all transitions to arrive. The main difference between EPC and activity diagrams in the case of logical connectors is that EPC supports �inclusive or� connector while there is no notation in activity diagrams to denote the �OR� connector.

Organization units and Swim lanes:

An organization unit in the EPC is attached to a function its responsibility for the respective business task. In the activity diagrams this is accomplished by arranging the activities that belong to the same department in a company or activities being done by the same actor in a use case into swim lanes.

Iteration

Activity diagrams support the notation for iteration which is not available in the EPC.

The comparisons between EPC and activity diagrams are summarized in the following table:

EPC UML

Context Process-oriented modelling Object-oriented modelling

(business oriented) (IT oriented)

Exactness/Ambiguity �Event from the side�, –

deadlocks, loops, logical

connector semantics

Notation/Terminology

Active Element Function Activity/Action state

Passive Element Event –

Process chain Control flow Transition

Logical connectors

Branch/Merge �XOR� connector Decision diamond

Fork/Join �AND� connector Synchronization bar

�Inclusive or� �OR� connector –

Actor Organization unit Swimlane

Iteration – �*� (multiplicity sign)

Summary of comparison between EPC and UML

Translation between EPC and UML Diagram

In translating from EPC to activity diagram and the other way around, we will use the results from the comparison between EPC and UML Activity Diagram as already discussed before. To translate from an EPC diagram to an activity diagram, the following guidelines can be used.

� Determine the organization units involved in the process chain together with the functions that each of the organization is responsible for. Align the Organization units into separate swim lanes in an activity diagram.

� Transform each function into activity/action states in the activity diagram and put it in the swim lane of the organization unit being responsible for it. If the function is a complex hierarchical function (which is also called a process), the refined EPC for that specific function can be either drawn as a complex activity state (meaning that inside the activity state we must specify some actions performed in the activity as well as entry and exit actions) or it would be better to draw the function in a separate activity diagram.

� Transform the corresponding logical connectors from the EPC into the corresponding elements in the activity diagram. The branches and merges represented by �XOR� connectors are transformed into decision diamonds and the forks and joins represented by �AND� connectors are transformed into synchronization bars.

� Connect the activities and decision diamonds or synchronization bars according to the control flow in the EPC.

� Add the start event(s) and end event(s). It is possible to have multiple start events and end events. This can be considered as multiple start events in the EPC or can also be considered as several scenarios in one diagram.

However, there are some problems with regard to the translation from an EPC to an activity diagram:

� As can be seen from the comparison, not all logical connectors for splitting and joining the control can be modelled in a straightforward way. The main problem is with the �OR� connector; there is no corresponding element in activity diagram to represent this logical connector. One solution is to express this �OR� connection in terms of �XOR� and �AND� connectors. To show this, we know from the logic theory that for two variables x and y, the following equation applies:

Using this equation we can translate two alternate paths taken based on an opening and a closing �OR� connectors into the following diagram:

OR

F1 F2 F1 F2 F1 F2

OR

The branch/fork solution for the elementary or-connector

However if the �OR� connector connects more than two alternative paths the resulting translation in the activity diagram would be very complicated.

� The organizational responsibility for activities is expressed in activity diagrams using swim lanes. However, swim lanes are not sufficient for modelling advanced and precise organizational relationships. These are important for example for the definition of workflows when support through workflow management systems is intended.

� Another problem with respect to translation from EPC to activity diagram is related to the loss of important information contained in events and information/resource objects. Some of the events are related to the change of state of an information/resource object. We can show this change of object�s state as an object with the object flow in an activity diagram, but if there are many information/resource objects in an EPC, they would make the diagram very hard to read.

� The definition of activity diagrams as state machines is quite problematic for applying activity diagrams according to the UML definition for business process modelling because actually not all business functions can be regarded as internal action states, e.g. interaction with outside business units.

A reverse procedure can also be applied to translate an activity diagram into an EPC:

� Transform the activity/action states from the activity diagram into functions in the EPC.

� Transform the corresponding decision diamonds or synchronization bars into �XOR� or �AND� connectors.

� Create dummy events before and after each function. For self-explanatory events as the results of their respective previous functions it is easy to fill them. Conditions as transition labels especially after a branch can be more or less transformed into events after an �XOR� connector. If there is an object flow in the activity diagram that can be used as a guide to create the events e.g. the �requirement [captured]� object state can be transformed into the �requirement captured� event.

� Connect the elements (events, functions, and logical connectors) with the control flow according to the transitions in the activity diagram.

� Connect the functions with the respective organization units transformed from swim lanes using organization unit assignment.

Again, there are also problems with regard to the resulting EPC diagram:

� Since there is formally no information about events in an activity diagram, the main problem in translating from an activity diagram to an EPC is to create the events that trigger functions and events as the results of functions. Object flows and transition labels or guards can be used as a reference to create events, but that is not a general solution. The only guaranteed solution is to try to understand the process that is modelled with the activity diagram and use the events based on this domain knowledge, but this is not a very good one because in that case it would be more efficient to model directly using the EPC.

� Because activity diagrams contain no information about information or material object, the resulting EPC diagram is not a complete diagram; instead it contains only the control flow and organization units.

� Since there is no corresponding notation for iteration in the EPC, we need to construct a loop for that. An additional effort to control the loop is needed so that it works as in the activity diagram.

The Integration Approach: The Object-EPC (oEPC)

This section argues for an integrated approach to object-oriented process modelling and describes selected aspects of an exemplary approach by called the object-oriented EPC (oEPC).

Motivation for Integration

We have already discussed in the first part of this chapter the contextual background of EPC and UML diagrams. The EPC is developed in the context of business process modelling and the UML is developed in the context of software development. Nowadays the successful development of business information systems requires an integrated approach which includes the seamless design of both the business processes and information systems development supporting the business processes. The business processes are modelled in a process-oriented framework, while on the other hand object-oriented modelling methods are used only on aspects which are close to software implementation, not the business processes. However these two fields are moving closer together because of several driving forces:

� Object-oriented implementation languages such as C++ or Java play an increasingly important role for the development of business information systems. In order to give an overall description of a company�s business processes and its object-oriented information systems it is therefore necessary to integrate business process modelling languages with object-oriented modelling ones.

� Object-orientation becomes more and more popular not only as a software paradigm, but also as a way of mentally structuring complex systems. Thus, object-oriented approaches can also be used on the business level for identifying the objects to be dealt with in a business process and its relationships.

� With the development of business objects as software components which can be assembled to information systems according to the user�s specific requirements, it is necessary to provide means for defining how a business process is supported by the cooperation of business objects.

For these reasons and due to the fact that the translation approach between EPC and UML activity diagrams has posed some significant problems, it is reasonable to think of an approach for integrating the strengths and advantages of the EPC and the UML to create a method that cover both areas of business process modelling and object-oriented information system. The purpose of the integration approach is on the one hand to preserve the potential and the end user�s acceptance of the standard EPC method for business process modelling and on the other hand to integrate the object-oriented methods with the EPC. With this approach it is supposed to be possible to model all relevant aspects of a company�s business processes and its object-oriented information system without the need for switching between different modelling paradigms or for translating between different modelling languages.

Within this concept, a business process is defined as the event-driven processing and the corresponding interaction of business objects in the same diagram. The oEPC differentiates between business process, business object, the corresponding resources such as organization units, information resources and events. Business objects can be grouped into classes. Each business object class has attributes and methods or functions. For modelling business processes, the interaction between objects takes place via message exchanges denoted as event-driven control flow.

Re-Engineering:

The reason for reengineering the use case diagram is that the admission document is placed in the filing basket when the admission is offered before 3 P.M. speaking technically mo memory space in the data base has to be allocated for both patients admitted before and after 3 pm. One needs to know that this process is one and the same of admitting patients, so it unnecessary that to separate fields or data bases have to be created which ultimately adds up more space. Speaking logically, the nurse can easily update information in the computer without having to undergo the long procedure, starting from sorting out the number of patients and their corresponding details, checking out the filing basket and then finally placing the admission document in the filing basket. The end result is one in the same even if she hadn�t followed the tedious process.

The reengineering process consists of following steps:

We have sorted out the instance where the functional units corresponding to the problem statement are placed in both the models. After that, the conditional branching structure is replaced / removed.

The instance from where the admission time is recorded is reengineered by replacing the original ones with the newly created functional units in both the models. The event or activity of �updating information on the system� is fixed at this position. This unit encapsulates the entire remodelled logical flow of the process which eventually ends in placing the admission in the suspension folder.

Another issue which has been reengineered is the core process of patient care. The place where reengineering had occurred is where two separate nurses have to conduct ward rounding and forwarding the patient medical records to the physician respectively.

It is obvious that a single nurse can perform both the actions affectively and by also reducing the number of people involved and time taken. Elaborating on the step, as single nurse can conduct ward round, check the patients and collect their reports and prepare them in an orderly manner in order to forward to the physician.

So the other nurse need not wait for the ward nurse to give him/her the report that is to be readied. So the time taken by the nurse who is waiting for the report to arrive can be eliminated. Even if two nurses are involved in the process both of them cannot perform parallel as their respective jobs are not mutually exclusive.

This is the part we have reengineered for the above said reasons. The newly created flow involves conduction of ward rounds and preparing patient records by the single nurse. Rather than two separate events, the two events are sequentially structured.

Reengineered Patient admission diagram in EPC:

Patient transfer Reengineered Diagram: