Process modeling

From Clinfowiki
Jump to: navigation, search

Process Modeling refers to a model of production, responsibility, interaction, and control. Process Models are built upon the concepts of Process, Resource, Work Product, Input/Output, and RACI/Supports.

Key Concepts

The key concepts of Process Modeling are as follows:

  1. Process: The "engine" that gets work done.
  2. Resource: The fuel a process consumes to get work done. The agents that perform the work.
  3. Work Product: The "product of work." Anything a process produces.
  4. Input/Output: The relationships between work products and processes. A work product can be an input to a process. All work products are an output of a process
  5. RACI/Supports: The relationships between resources and work products, processes, and other resources. RACI is an acronym for Responsible, Accountable, Consulted, or Informed.

As such, Process Modeling can be defined as a methodology that lends clarity to how work gets done, the organizational structure surrounding the work environment, and the actual work performed.


Process Modeling (Process Modeling, 2011) has its roots in the simple system flowchart (Flowchart, 2011). With flowcharts, the primary focus is flow of control. The utility of a flowchart is that it presents a graphical representation of an algorithm. Complex processes, such as Clinical Support Processes, are highly algorithmic by their very nature, and are commonly represented in a graphical form depicting decisions, calculations, input/output steps, and flow-of-control interaction with other processes (NHLBI, 2006; Sorgie, 2004). Despite the ongoing enhancements made to Process Modeling since its inception as the lowly flowchart, the key concepts as stated remain at the heart of Process Modeling and are basic to the comprehension of any complex process.

As processes became more complex, the complexity of the systems required to support those processes followed suit. The processes that modern day Clinical Information Systems need to support, coupled with the intricacies of modern day Clinical Information Systems themselves, are excellent examples of this ever increasing complexity. To shed light on such complex processes, it becomes necessary to model not only their algorithmic structure, but the agents responsible for performing the work, the details of the actual work performed, and how the organizational elements of the process relate to each other; hence the introduction of the Resource, Work Product, and Input/Output and RACI/Supports relationship concepts.

Resources fall into two general categories: people and systems. When a resource is used by a process, it is typically said that the resource has been allocated to that process. When the process is done with the resource, it is said that the resource has been released by that process. During the period of time that a resource is allocated to a process, the process is said to be consuming that resource, which implies that the resource is (somewhat) unavailable and cannot be allocated to another process. For example, at this very moment you, the reader, as a resource, are allocated to a Reading process and are being consumed in that your time (or at least a portion of it) is fueling that process. A work product input to that Reading process is this Process Modeling wiki page itself.

Work Products are, quite literally, the "products of work," and represent the things processes consume resources to produce. This Process Modeling wiki page is a work product that was output by a Writing process. While it was being written, the author was allocated to that process. The Process Modeling wiki page work product is now an input to your Reading process.

The RACI/Supports relationships can be introduced to lend even further refinement to the model. Responsible, Accountable, Consulted, and Informed are used when the resource is a person, and Supports is used in all cases when the resource is a system (RACI, 2011; iGrafx Process, 2011).

Given this, the author's personal computer Supported his Writing process, and your computer system is Supporting your Reading process. The author was both Responsible and Accountable for the Writing process, as well as the Process Modeling wiki page work product itself. According to course guidelines, no one was Consulted during the Writing process, but various online systems did in fact Support the Writing process. The course TA requested that he be Informed when the Writing process was completed, the author was released from that process, and the Process Modeling wiki page work product was complete. You, dear reader, are both Responsible and Accountable for your Reading process. Your Reading process output yet another work product, represented by your comprehension of the information contained within this Process Modeling wiki page. In the future, this comprehension of information may serve as a work product input to another process. And so on.

Technical Advances

Flowcharts were introduced as early as 1921 by Frank Gilbreth to members of the American Society of Mechanical Engineers (ASME) (Flowchart, 2011). The concept of the basic flowchart continues to be extended; the Unified Modeling Language (UML) diagrams of today have their foundation in basic flowcharting principles.

Since the act of Process Modeling is itself a process, as computer systems have advanced, an abundance of tools have become available to assist in the Process Modeling process itself (Edraw, 2011; iGrafx Process, 2011; Microsoft Visio, 2011). Modern Process Modeling tools are highly graphical in nature with advanced features such as automatic collision avoidance algorithms that reroute connection lines around graphical elements, and support for the use of swimlanes to denote cross-functional and interdepartmental process steps (iGrafx Process, 2011). Process Modeling tools have also been extended to manage the creation of enhanced relationships among process elements and produce detailed analysis-specific reports. Process Modeling has evolved into Enterprise Modeling, which takes into account additional concepts such as the overall requirements, goals, and risks intrinsic to a system, as well as its interfaces to the outside world (Enterprise Modeling, 2011).

Process Modeling And Clinical Information Systems

Process Modeling is an effective and standardized means of communication that can be used by both CIS authors and their prospective clients to better document and facilitate the design, architecture, implementation, deployment, training, and support of Clinical Information Systems (Workflow and Process Mapping, 2010).

In order for Clinical Information Systems to be effective, they must integrate well with, and not disrupt, the clinical processes they strive to support. Process Modeling, even in its basic form, facilitates this desired supportive and non-disruptive integration by providing a clear representation of the clinical processes that could benefit from support, the information needed to provide that support, and the personnel and systems tasked with managing and supplying that support (Merrill, 2010).

Process Modeling can be used prior to even speaking with a CIS vendor. By modeling their own internal clinical processes, healthcare providers can achieve a better understanding of those processes and be better equipped to communicate their requirements to prospective CIS vendors, as well as better assess the responses from those vendors.

Process Modeling can be used to facilitate the ongoing CIS support process. Modeling how internal clinical processes have evolved over time is an effective tool for managing and supporting the development and training incurred from morphing CIS requirements.

Tools vs. The Thought Process

It is worth noting that the thought process intrinsic to Process Modeling is distinct from the Process Modeling tools themselves, just as, say, the thought process intrinsic to accounting is distinct from the spreadsheet programs used to manage accounting information. Thinking in Process Modeling terms provides a basis for the understanding of any complex system, especially those required to support complex processes with a wide range of clients, authors, requirements, and legacy interfaces such as those found in CIS, as well as providing a framework for understanding the complex clinical processes Clinical Information Systems themselves strive to support.

Don't procrastinate due to the lack of availability of a Process Modeling tool. Start the CIS Process Modeling thought process first, and when you and your colleagues feel you could use some help in managing your musings, seek out the tool that best supports your collective process of pondering.

Convergence with Data Mining

see Process Mining


  1. Edraw soft vector-based graphic design. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  2. Enterprise modeling. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  3. Flowchart. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  4. iGrafx Process. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  5. Merrill M. Top 5 reasons providers not ready for meaningful use. [Online] 2010 [cited 2011 Nov 16]; Available from: URL:
  6. Microsoft Office Visio. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  7. NHLBI: Practical guide to the identification, evaluation, and treatment of overweight and obesity in adults from the National Heart, Lung, and Blood Institute (2000). [Online] 2006 [cited 2011 Nov 16]; Available from: URL:
  8. Process modeling. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  9. RACI: Responsibility assignment matrix. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  10. Sorgie C. Process modeling, simulation, and TRIZ: an innovative and symbiotic solution. [Online] 2004 [cited 2011 Nov 16]; Available from: URL:
  11. UML: Unified modeling language. [Online] 2011 [cited 2011 Nov 16]; Available from: URL:
  12. Workflow and process mapping. [Online] 2010 [cited 2011 Nov 16]; Available from: URL:

Submitted by Charles Sorgie