You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

DCM concept of a case

Within the field of dynamic case management (DCM), the concept of a case (or in design time: case type) is the most important concept. When asked what a case is, people tend to give many different answers, naming different concepts within the definition, such as decision, process, document, phase etc. But all these different answers have one thing in common: The named concepts are all part of the case or contribute to a case. This is shown in the diagram below.

In this design guide

As show above, in DCM a case is a concept that combines many other concepts. We do not aim to give one precise definition of a case in this document, but try to explain which concepts can play a role when designing a case.

A case always has a goal, this is most likely singular. In order to reach that goal, decisions are made, in one or more processes. A case goes through phases, where a phase change is achieved formally by means of a milestone. A case can have different states, even more at once. Information is persisted within a case or outside of a case in a register. Within cases, some tasks are not really part of the main or other processes, but can always be executed. Such generic tasks are part of the case as well. Notes and appointments are similar to generic tasks, they are part of the case and are probably available throughout the life cycle of a case. Outside triggers or events can lead to actions that need to be performed in a case. Cases will most likely contain uploaded documents and will generate documents themselves as well. Finally, case management is about collaboration; people can be involved and teams, organizations and roles can be defined.

All afore mentioned concepts contribute to a case, but that does not mean that each case has to consist of all these concepts necessarily. However, most (or even all?) cases contain decisions, will have at least one process and will most likely store some data and/or produce a document.

Blueriq concept of a case

With Blueriq's proposition of Dynamic Case Management, many DCM concepts are available within the platform. However, not all concepts can be found in Blueriq Studio as a Blueriq-concept. Shown below is the same image as above, containing a case and all its related concepts. The concepts in blue deviate from the previous image; this means that the DCM concept itself is not available within the platform as such, but one or more Blueriq concepts are used to model the DCM-concept effectively.

In the diagram above, all pink concepts are DCM concepts that are part of Blueriq by default. The concept Decision is probably the most dominant one, but also processes, persistency and documents are used in many - if not all -  Blueriq applications. Teams and roles may not be as common as decisions, but are used very frequently.

The blue concepts in the diagram above indicate DCM concepts that are not available within the platform as a standard Blueriq module element, but can be modeled using out-of-the-box Blueriq functionality. For instance, the goal of a case, milestones and states; they can all be modeled using decisions, most likely decision tables or business rules. Notes and incoming documents can be modeled using specific containers. For triggers, incoming message events can be used. Appointments, involvements and organizations can be modeled with attributes.

The most protruding blue icons are that of the case and related cases; aggregates are used to model cases. This means that not only standard persistency by means of registers is done using aggregates, but also the case itself is an aggregate!

Not all aggregates are cases (an aggregate can also be used to model a register, but all cases are aggregates.

Comparison

The table below compares all DCM concepts with Blueriq concepts and briefly explains how standard Blueriq concepts can be used to model the DCM concept, if applicable.

Concept in DCMConcept in BlueriqRemarks
CaseAggregate 
GoalDecisionThe goal of the case could be to grant a permit, register an applicant, pay a benefit, sell a product etc. A goal can easily be modeled by an attribute with a default value false and a decision table or business rule which sets the attribute to true when the goal is reached.
DecisionDecision 
ProcessProcess 
MilestoneDecisionWhether a milestone is reached or not is a decision, based on the context of the case.
PhaseProcess 
StateDecision 
PersistencyAggregate 
Generic taskProcess 
Related caseAggregate 
NoteComment container 
AppointmentAttribute(s) 
TriggerIncoming external message 
Document inputFile upload container 
Document outputDocument 
InvolvementAttribute(s) 
TeamTeam 
OrganizationAttribute(s) 
RoleRole 

See also

More information on how to design dynamic processes in Blueriq can be found here: Designing dynamic processes.
Everything about persistency management and aggregates can be found here: Persistency Management guide.
A visualization of most concepts discussed in this article can be found here: Blueriq visuals.
Specifically for dynamic case management and persistency management, see

Dynamic case management

Dynamic Case Management

Persistency management

Aggregate


  • No labels