The potentially relevant object types are:

1. diagnostic departments (the organizational units that own/manage their diagnosis business processes);
2. patients;
3. the seven spaces/rooms: waiting area, ECG room, ECG technician room, ECG storage room, ultrasound room, "doctors on call" room, doctors resting room;
4. the six resource object types ECG spots, ECG technicians, ECG machines, US beds, US machines and doctors.

Potentially relevant types of events and activities are:

1. arrivals of new patients;
2. patients walking to the ECG room;
3. ECG technicians (a) walking to the ECG storage room, (b) moving an ECG machine from the ECG storage room to the ECG room, (c) performing an ECG on a patient, (d) returning the ECG machine to the storage room, (e) walking back to the ECG technician room, and (f) resting for five minutes;
4. patients going from the ECG room to the US room,
5. doctors (a) walking from the "doctors on call" room to the patient's bed in the US room, (b) performing an US scan on the patient, (c) walking to the doctors resting room, (d) resting for some time, and (e) going back to the "doctors on call" room;
6. departure of patients.

When making a process model, we normally adopt the perspective of the organization (or organizational unit) that "owns" the business process to be modeled, here: the diagnostic department. Notice the conceptual issue that the activities performed by patients (walking to the ECG room, going to the US room) are not ordinary business activities, since they are not performed by an organizational actor, such as a technician or doctor, counting as a resource. In their case, the performer (a patient) is not a resource. For this reason they will be modeled without a performer role.

Object, event and activity types, together with their participation associations, can be visually described in a conceptual information model in the form of a conceptual Object Event (OE) class diagram. The following OE class model describes the core elements of our diagnostic department viewed as a business system.

While this model defines primary business activity types together with their resource roles (association ends annotated with «rr»), associated resource types and corresponding resource pools (association ends annotated with «rp»), it does not capture the types of secondary business activities of

1. ECG technicians (a) walking to the ECG storage room, (b) moving an ECG machine from that storage room to the ECG room, (c) returning the ECG machine to the storage room, (d) walking back to the ECG technician room, and (e) resting for five minutes;
2. doctors (a) walking from the "doctors on call" room to the patient's bed in the US room, (b) walking to the doctors resting room, (c) resting for some time, and (d) going back to the "doctors on call" room.

These secondary business activities are described in the following OE class diagrams.

As service processes, health care processes can be viewed/modeled as Processing Networks (PNs). Since PNs are more high-level than Activity Networks (ANs), it is preferable to model the Diagnostic Department as a PN.

The following BPMN process diagram shows a coarse-grained conceptual process model of the primary business activities of the Diagnostic Department, with two swimlanes for the two performers of the process:

Unfortunately, as an AN modeling language, BPMN does not provide any special elements for modeling PNs. While BPMN allows modeling the performers of activities with lanes, it does not support modeling other types of resource objects. As a workaround, we have included the resource objects ECG spot, ECG machine and US bed in the form of BPMN Data Objects. But this does not allow to clearly display the processing nodes of a processing network as a combination of a processing station (like ECG spot) with its processing activity (like perform ECG).

An even more severe issue of the BPMN model is its uniform (semantically overloaded) use of "sequence flow" arrows for representing different types of flows: event flows, activity flows and processing flows. While in the case of an activity, incoming arrows do not mean that an activity is started, but rather that a new planned activity (or task) is enqueued and only started when all required resources become available, in the case of a processing node, an incoming arrow represents a processing flow, which is a combined object-event flow of processing objects and their delayed processing activity start events.

These issues of BPMN have been solved in DPMN, which supports the visual modeling of processing networks with processing nodes connected by processing flow arrows, as shown in the following DPMN process diagram:

This conceptual DPMN process diagram is based on the underlying OE class model discussed in the previous section. Notice that a two-part name of a processing node (like "ECG spot / perform ECG") contains both the name of the node's processing station ("ECG spot") and the name of the node's processing activity ("perform ECG"). For the processing node "ECG spot / perform ECG", the model specifies three resource objects: an "ECG technician" as the performer, the processing station "ECG spot" (specified in the node name), and an additional resource object "ECG machine".

Run this model from the OESjs GitHub website

While this model attains a highly compact description of the Diagnostic Department system by compressing "ECG spot" resources and the "perform ECG" activity, as well as "US bed" resources and the "perform US scan" activity, into a corresponding processing node, it abstracts away from the activities of patients walking to the ECG room and walking from the ECG room to the US room.

The above model can be further refined by explicitly modeling the two patient activities "walk to ECG spot" and "walk to US bed". While the first of them requires an "ECG spot" as a resource, the second one requires a "US bed". In the following DPMN process diagram, we do not display the rectangular container (called Pool) for the Diagnostic Department, leaving it implicit.

Notice that in this refined model, the processing nodes of the previous model have been resolved into corresponding processing activities (and associated resources).

According to DPMN's declarative resource modeling principles, a required resource will be allocated before an activity starts and, unless the follow-up activity also requires a resource of that type, released after it has completed. In the case of the activity sequence of "perform ECG" and "walk patient to US bed", however, the resource "ECG spot" must not be released before the follow-up activity "walk patient to US bed" starts, because it represents the location of the patient (in the ECG room), which only becomes available when the patient leaves the room (for going to the US room) and not when the "perform ECG" activity ends.

DPMN allows to mark such a deferred resource de-allocation with the help of a special resource role association end (a dot with a bar), as can be seen in the diagram at the "ECG spot" resource type rectangle. It means that this resource is not released when the activity (here "perform ECG") ends, but only when the follow-up activity (here "walk patient to US bed") starts.

In this example, the requirement for deferred resource de-allocation stems from the ambiguity of the ECG room (with three spots) representing both a spatial resource for the activity "perform ECG" and an input buffer for the processing activity "walk to US bed". This points to an intricate relationship between the concepts of spatial resources and input buffers in PNs, which requires further research.

Run this model from the OESjs GitHub website

T.B.D.

An information design model, in the form of an OE class diagram as shown below, is derived from a conceptual information model by abstracting away from items that are not design-relevant and possibly adding certain computational details.

An OE class design diagram like the one above, defines resource roles, resource role types and resource multiplicity constraints for all types of activities. Normally, in an OE simulation there is a one-to-one correspondence between resource role types and resource pools. By convention, a resource pool has the same name as the corresponding resource role type, yet pluralized and starting with a lowercase character.

T.B.D.

A process design model, in the form of a DPMN process diagram as shown below, is derived from a conceptual process model by abstracting away from items that are not design-relevant and possibly adding certain computational details.

A DPMN process design model essentially defines the admissible sequences of events and activities together with their dependencies and effects on objects, while its underlying OE class design model defines the types of objects, events and activities, together with the participation of objects in events and activities, including the resource roles of activities, as well as resource multiplicity constraints, parallel participation constraints, alternative resources, and task priorities.

It is an option, though, to enrich a DPMN process design model by displaying more computational details, especially the recurrence of exogenous events, the duration of activities and the most important resource management features defined in the underlying OE class design model, such as resource roles (in particular, performer roles can be displayed in the form of Lanes) and resource multiplicity constraints. The following model shows an enriched version of :

Such an enriched DPMN process design model includes all computational details needed for an implementation without a separate explicit OE class design model. In fact, such a process model implicitly defines a corresponding class model. For instance, the enriched DPMN model of implicitly defines the OE class model of above.

The notation for defining performer roles in Lanes consists of a performer role name (such as pizzaMakers) and and an object type name (such as PizzaMaker) denoting its range, separated by a colon. When the performer role name is appended by a multiplicity expression in brackets, as in pizzaMakers[2], this denotes a resource multiplicity constraint (stating that exactly 2 pizzaMakers are required). When only a performer type prefixed with a colon (such as :OrderTaker) is provided, this means that the implicit performer role name is obtained by lowercasing the performer type name (as in orderTaker:OrderTaker).

Notice that the model of does not include any element representing a resource pool. It is assumed that for any organizational position described in the underlying OE class model, the organization under consideration has a corresponding resource pool. By default , each resource role of an activity type is associated with a resource pool having the same (yet pluralized) name, such that its resources are instances of a corresponding resource role type, which is an organizational position in the case of human resources.

Combined with its underlying OE class design model, a DPMN process design model provides a computationally complete specification of a simulation model.