LEAD Reference Content:Case Management - Example - Revision history

Admin at 16:20, 18 January 2017

2017-01-18T16:20:59Z

Admin at 15:51, 18 January 2017

2017-01-18T15:51:54Z

Admin at 15:50, 18 January 2017

2017-01-18T15:50:17Z

Admin at 15:32, 18 January 2017

2017-01-18T15:32:56Z

Admin at 15:31, 18 January 2017

2017-01-18T15:31:01Z

Admin at 14:17, 18 January 2017

2017-01-18T14:17:21Z

Admin at 13:51, 18 January 2017

2017-01-18T13:51:58Z

Admin at 13:46, 18 January 2017

2017-01-18T13:46:31Z

Admin at 13:45, 18 January 2017

2017-01-18T13:45:45Z

Admin at 13:44, 18 January 2017

2017-01-18T13:44:55Z

@@ Line 8: / Line 8: @@
 For example, prisoners, illegal immigrants, people under hospital order, etc. What makes court case management interesting is that each worker needs real-time access to the full case information, and that information can easily change as new evidence is filed, evidence is deemed inadmissible, milestones are reached, notifications are generated, etc. Figure 1 provides an overview of a criminal system roles and their specific case handling needs. The same complexity and similar requirements are present in the civil system.
 [[File:Case Management - The New OMG Standard - Figure 2.png|thumb|800px|left|alt=Figure 1: Typical roles, their requirements, and needs around a court case management system.|Figure 1: Typical roles, their requirements, and needs around a court case management system.]]
@@ Line 16: / Line 15: @@
 The content management requirements include handling the storage and retention policies of the legislation, the court cases and the verdicts. Case management in a court system could be very complex as it needs to coordinate a large set of parties. Figure 2 is an example of a layered architecture view of a civil system.
 [[File:Case Management - The New OMG Standard - Figure 3.png|thumb|800px|left|alt=Figure 2: Layered architecture view illustrating court case handling.|Figure 2: Layered architecture view illustrating court case handling.]]
@@ Line 57: / Line 55: @@
 === Roles ===
 In CMMN, roles are defined at the case level. Roles can be used as performers for human tasks, to do case planning, and to raise user events. However, roles do not have a graphical notation, and not everything a role does is modeled. In particular, a role may be allowed to do planning that may not be explicitly modeled; a role may also add, create, modify, or remove documents from the case file which may not be explicitly modeled. The plaint receipt process prototype described by Rungruangpattana, and Achalakul uses six roles. For simplification, the Authority role was omitted.
 Table 1, describes the remaining roles, the documents they create, the tasks they execute, and the stages they can complete.
 {| class="wikitable" style="text-align: left; width: 80%;"
@@ Line 101: / Line 97: @@
 === Information model ===
 Table 2, describes the different case file items. In this example, the case file items are documents. The table describes the role that produces the document, and the task in which the document is produced. Note that some documents originate outside the case management system; and for those documents produced within a task in the system, there is no explicit modeling of that fact.
 {| class="wikitable" style="text-align: left; width: 70%;"
@@ Line 147: / Line 142: @@
 === Milestones ===
 Milestones represent accomplishments during the process of the case. Due to the large variations between case instances, milestones are important to understand the progress of a particular case instance. Table 3, describes the milestones and the condition that should be meet for the milestone to be achieved.
 {| class="wikitable" style="text-align: left; width: 60%;"
@@ Line 173: / Line 167: @@
 === Stages ===
 Stages are behavioral containers, and they are used to manage the complexity of the model by using nesting to hide details. Table 4, describes the stages in this example, and when they are executed (entry criteria).
 {| class="wikitable" style="text-align: left; width: 60%;"
@@ Line 219: / Line 212: @@
 === Tasks ===
 Tasks in CMMN are similar to tasks or activities in BPMN. Table 5, describes the tasks and when they are executed (entry criteria).
 {| class="wikitable" style="text-align: left; width: 60%;"
@@ Line 289: / Line 281: @@
 === The plaint receipt process CMMN model ===
 The following CMMN model describes the plaint receipt process. This section presents the model and informally describes the semantics. Figure 3, provides the case model with all the stages collapsed. The arrival of the Plaint (I1) document starts the case. The case is created and the Plaint (I1) document added to the case file. That can be done manually, although some tools, like IBM Case Management, can be configured to automatically create the case when a document arrives to a content repository via any means including email. The arrival of Plaint (I1) to the case file triggers the entry criteria of the Inspect plaint (S1) stage that start execution. For the case to complete, Inspect plaint (S1), Collect payment (S2), and Process plaint (S3) must execute, indicated by the exclamation sign (!).
 [[File:Case Management - The New OMG Standard - Figure 4.png|thumb|600px|left|alt=Figure 3: Plaint receipt process.|Figure 3: Plaint receipt process.]]
@@ Line 297: / Line 288: @@
 By looking at Figure 3, we don’t know which CMMN element inside S1 may generate the event expected by the milestone entry criterion. A connector between a task or stage and an entry or exit criteria does not means the completion of the task or stage will provide the expected event. By the description in Table 3, we know the expected event in M1 is completion of S1. Connectors are optional in CMMN, and could be omitted from the model.
 [[File:Case Management - The New OMG Standard - Figure 5.png|thumb|600px|left|alt=Figure 4: Expanding stage Inspect plaint (S1).|Figure 4: Expanding stage Inspect plaint (S1).]]
@@ Line 303: / Line 293: @@
 In Figure 4, Classify the case (T1) becomes available for execution when the stage Inspect plaint (S1) starts executing. Inspect the plaint (T2) is repeatable, and become available for execution when Classify the case (T1) completes or Amend Plaint (I2) arrives to the case. T2 is repeatable, because multiple I2s may arrive. Inform litigant to amend the plaint (dT1) is a discretionary non-blocking human task, that may be used by the competent officer if needed.
 [[File:Case Management - The New OMG Standard - Figure 6.png|thumb|600px|left|alt=Figure 5: Expanding stage Collect payment (S2).|Figure 5: Expanding stage Collect payment (S2).]]
@@ Line 309: / Line 298: @@
 As modeled in Figure 5, the entry criterion of Issue a receipt of court fee (T4) requires an event from both a Payment (I3) and the Asses plaint docs to charge court fee (T3). Collect payment (S2) is required for the case to complete and will automatically complete when T3, T4, and T5 complete.
 [[File:Case Management - The New OMG Standard - Figure 7.png|thumb|600px|left|alt=Figure 6: Process plaint (S3).|Figure 6: Process plaint (S3).]]
@@ Line 315: / Line 303: @@
 Process plaint (S3) becomes available when a Judge is assigned as modeled in Figure 3, and it is manually activated by the Judge. As modeled in Figure 6, Order (T6) is the main task. T6 is required and can be executed multiple times. As described in Table 5, T6 initially start execution when S3 start executing; and then T6 executes again every time an Accepted Amended plaint (I4) or a Report on plaint (I5) arrives to the case. The Judge doing T6 can select one of the discretionary stages associated with T6 planning table by doing planning.
 [[File:Case Management - The New OMG Standard - Figure 8.png|thumb|600px|left|alt=Figure 7: Expanding discretionary stage Accept (dS1).|Figure 7: Expanding discretionary stage Accept (dS1).]]
@@ Line 321: / Line 308: @@
 The Accept (dS1) discretionary stage modeled in Figure 7 starts by instantiating a required stage (S4). S4 contains two repeatable blocking human tasks. Examine witness (T7) is optional, and if used, it must be activated manually. Review evidence (T8) is required, but still must be activated manually. Because, both T7 and T8 are repeatable, then S4 was modeled as requiring manual completion. This avoids premature completion of S4. For example, let say that T8 is completed, and so, no required tasks are remaining in S4 that condition under auto complete will signalize to the case management system to complete S4; however in this case more witnesses may be scheduled to be examined (T7) in the future, and so, we don’t want S4 to auto-complete.
 [[File:Case Management - The New OMG Standard - Figure 9.png|thumb|600px|left|alt=Figure 8: Expanding discretionary stage Reject (dS2).|Figure 8: Expanding discretionary stage Reject (dS2).]]
@@ Line 327: / Line 313: @@
 The Reject (dS2) discretionary stage modeled in Figure 8 contains a single task. The Sentence, issue the number of decided case in the judgment list (T10) task is required and after completion, Reject (dS2) will automatically complete.
 [[File:Case Management - The New OMG Standard - Figure 10.png|thumb|600px|left|alt=Figure 9: Expanding discretionary stage Return (dS3).|Figure 9: Expanding discretionary stage Return (dS3).]]
@@ Line 342: / Line 327: @@
 '''Document''': [[Media:Case Management - The new OMG standard.pdf|Download the 'Case Management - The new OMG standard' document.]]
 [[Category: Case Management]]

← Older revision		Revision as of 15:51, 18 January 2017
Line 339:		Line 339:

	We used the plaint receipt process followed by the Central Intellectual Property and International Trade Court in Thailand to illustrate the CMMN modeling capabilities. The plaint receipt process was introduced in the literature as a case management use case by Rungruangpattana, and Achalakul. In the example, we presented the case modeling notation and how it forces a structured way of thinking, working and modeling; which is different than traditional BPM. Traditional workflow and BPM technology requires that all aspects of the problem be modeled. CMMN, in the other hand, rely on the worker’s judgment and collaboration technology to minimize modeling and make the process more flexible and data centric.		We used the plaint receipt process followed by the Central Intellectual Property and International Trade Court in Thailand to illustrate the CMMN modeling capabilities. The plaint receipt process was introduced in the literature as a case management use case by Rungruangpattana, and Achalakul. In the example, we presented the case modeling notation and how it forces a structured way of thinking, working and modeling; which is different than traditional BPM. Traditional workflow and BPM technology requires that all aspects of the problem be modeled. CMMN, in the other hand, rely on the worker’s judgment and collaboration technology to minimize modeling and make the process more flexible and data centric.
		+
		+
		+	'''Document''': [[Media:Case Management - The new OMG standard.pdf\|Download the 'Case Management - The new OMG standard' document.]]


	[[Category: Case Management]]		[[Category: Case Management]]

← Older revision		Revision as of 15:50, 18 January 2017
Line 292:		Line 292:

	[[File:Case Management - The New OMG Standard - Figure 4.png\|thumb\|600px\|left\|alt=Figure 3: Plaint receipt process.\|Figure 3: Plaint receipt process.]]		[[File:Case Management - The New OMG Standard - Figure 4.png\|thumb\|600px\|left\|alt=Figure 3: Plaint receipt process.\|Figure 3: Plaint receipt process.]]
		+
		+
		+	Note the connector (dotted line) between Plaint (I1) and the entry criterion in Inspect plaint (S1). That connector indicates that a state change in Plaint (I1) generates an event that is expected in the entry criterion of Inspect plaint (S1). In this case, the entry criterion is expecting a document of type Plaint (I1) to be created. There may also be a condition in the entry criterion to Inspect plaint (S1), for example the type of Plaint (I1) document. The connector between for Inspect plaint (S1) and milestone Inspected plaint (M1) indicates that a state change inside the Inspect plaint (S1) is being expected in the milestone entry criterion.
		+
		+	By looking at Figure 3, we don’t know which CMMN element inside S1 may generate the event expected by the milestone entry criterion. A connector between a task or stage and an entry or exit criteria does not means the completion of the task or stage will provide the expected event. By the description in Table 3, we know the expected event in M1 is completion of S1. Connectors are optional in CMMN, and could be omitted from the model.
		+
		+
		+	[[File:Case Management - The New OMG Standard - Figure 5.png\|thumb\|600px\|left\|alt=Figure 4: Expanding stage Inspect plaint (S1).\|Figure 4: Expanding stage Inspect plaint (S1).]]
		+
		+
		+	In Figure 4, Classify the case (T1) becomes available for execution when the stage Inspect plaint (S1) starts executing. Inspect the plaint (T2) is repeatable, and become available for execution when Classify the case (T1) completes or Amend Plaint (I2) arrives to the case. T2 is repeatable, because multiple I2s may arrive. Inform litigant to amend the plaint (dT1) is a discretionary non-blocking human task, that may be used by the competent officer if needed.
		+
		+
		+	[[File:Case Management - The New OMG Standard - Figure 6.png\|thumb\|600px\|left\|alt=Figure 5: Expanding stage Collect payment (S2).\|Figure 5: Expanding stage Collect payment (S2).]]
		+
		+
		+	As modeled in Figure 5, the entry criterion of Issue a receipt of court fee (T4) requires an event from both a Payment (I3) and the Asses plaint docs to charge court fee (T3). Collect payment (S2) is required for the case to complete and will automatically complete when T3, T4, and T5 complete.
		+
		+
		+	[[File:Case Management - The New OMG Standard - Figure 7.png\|thumb\|600px\|left\|alt=Figure 6: Process plaint (S3).\|Figure 6: Process plaint (S3).]]
		+
		+
		+	Process plaint (S3) becomes available when a Judge is assigned as modeled in Figure 3, and it is manually activated by the Judge. As modeled in Figure 6, Order (T6) is the main task. T6 is required and can be executed multiple times. As described in Table 5, T6 initially start execution when S3 start executing; and then T6 executes again every time an Accepted Amended plaint (I4) or a Report on plaint (I5) arrives to the case. The Judge doing T6 can select one of the discretionary stages associated with T6 planning table by doing planning.
		+
		+
		+	[[File:Case Management - The New OMG Standard - Figure 8.png\|thumb\|600px\|left\|alt=Figure 7: Expanding discretionary stage Accept (dS1).\|Figure 7: Expanding discretionary stage Accept (dS1).]]
		+
		+
		+	The Accept (dS1) discretionary stage modeled in Figure 7 starts by instantiating a required stage (S4). S4 contains two repeatable blocking human tasks. Examine witness (T7) is optional, and if used, it must be activated manually. Review evidence (T8) is required, but still must be activated manually. Because, both T7 and T8 are repeatable, then S4 was modeled as requiring manual completion. This avoids premature completion of S4. For example, let say that T8 is completed, and so, no required tasks are remaining in S4 that condition under auto complete will signalize to the case management system to complete S4; however in this case more witnesses may be scheduled to be examined (T7) in the future, and so, we don’t want S4 to auto-complete.
		+
		+
		+	[[File:Case Management - The New OMG Standard - Figure 9.png\|thumb\|600px\|left\|alt=Figure 8: Expanding discretionary stage Reject (dS2).\|Figure 8: Expanding discretionary stage Reject (dS2).]]
		+
		+
		+	The Reject (dS2) discretionary stage modeled in Figure 8 contains a single task. The Sentence, issue the number of decided case in the judgment list (T10) task is required and after completion, Reject (dS2) will automatically complete.
		+
		+
		+	[[File:Case Management - The New OMG Standard - Figure 10.png\|thumb\|600px\|left\|alt=Figure 9: Expanding discretionary stage Return (dS3).\|Figure 9: Expanding discretionary stage Return (dS3).]]
		+
		+
		+	The Return (dS3) discretionary stage modeled in Figure 9 consists of a single stage (S5). S5 was required, because a discretionary stage cannot have an exit criterion. Note that Return (dS3) is repeatable, and so, it can be planned multiple times. The contained stage (S5) has an automatic non-blocking human task to inform the litigant to amend the plaint (T11). When an Amended plaint (I6) arrives, it is processes by accept the plaint (T12) task. Note the amended plain (I6) is the same case file item as I2. If the timer E1 expires, then do reports to the Judge (T13) may be executed, and that may trigger the exit criterion of S5. If the exit criterion is met then all the activity inside S5 will forced to terminate and S5 will complete.
		+
		+
		+	=== Conclusion ===
		+	This ‘how to guide’ described the main characteristics of Case Management and how it can be used to solve the case handling requirements. We introduced the CMMN specification, and described its relationship to BPM, collaboration, and content management technology. In particular, we described the differences between case management and BPM, because CMMN is not intended to replace BPMN but it is complementary to BPMN. CMMN is expected to be used in conjunction with BPMN.
		+
		+	We used the plaint receipt process followed by the Central Intellectual Property and International Trade Court in Thailand to illustrate the CMMN modeling capabilities. The plaint receipt process was introduced in the literature as a case management use case by Rungruangpattana, and Achalakul. In the example, we presented the case modeling notation and how it forces a structured way of thinking, working and modeling; which is different than traditional BPM. Traditional workflow and BPM technology requires that all aspects of the problem be modeled. CMMN, in the other hand, rely on the worker’s judgment and collaboration technology to minimize modeling and make the process more flexible and data centric.


	[[Category: Case Management]]		[[Category: Case Management]]

@@ Line 288: / Line 288: @@
 === The plaint receipt process CMMN model ===
-The following CMMN model describes the plaint receipt process. This section presents the model and informally describes the semantics. Figure 4, provides the case model with all the stages collapsed. The arrival of the Plaint (I1) document starts the case. The case is created and the Plaint (I1) document added to the case file. That can be done manually, although some tools, like IBM Case Management , can be configured to automatically create the case when a document arrives to a content repository via any means including email. The arrival of Plaint (I1) to the case file triggers the entry criteria of the Inspect plaint (S1) stage that start execution. For the case to complete, Inspect plaint (S1), Collect payment (S2), and Process plaint (S3) must execute, indicated by the exclamation sign (!).
+The following CMMN model describes the plaint receipt process. This section presents the model and informally describes the semantics. Figure 3, provides the case model with all the stages collapsed. The arrival of the Plaint (I1) document starts the case. The case is created and the Plaint (I1) document added to the case file. That can be done manually, although some tools, like IBM Case Management, can be configured to automatically create the case when a document arrives to a content repository via any means including email. The arrival of Plaint (I1) to the case file triggers the entry criteria of the Inspect plaint (S1) stage that start execution. For the case to complete, Inspect plaint (S1), Collect payment (S2), and Process plaint (S3) must execute, indicated by the exclamation sign (!).
 [[Category: Case Management]]

← Older revision		Revision as of 15:31, 18 January 2017
Line 215:		Line 215:

	Table 4: Stages.		Table 4: Stages.
		+
		+
		+	=== Tasks ===
		+	Tasks in CMMN are similar to tasks or activities in BPMN. Table 5, describes the tasks and when they are executed (entry criteria).
		+
		+
		+	{\| class="wikitable" style="text-align: left; width: 60%;"
		+	\|- style="vertical-align: top;"
		+	\| style="width: 15%; background: #0b98d6; color: #ffffff;" \| '''Task'''
		+	\| style="width: 15%; background: #0b98d6; color: #ffffff;" \| '''Entry criteria'''
		+	\| style="width: 30%; background: #0b98d6; color: #ffffff;" \| '''Description'''
		+	\|- style="vertical-align: top;"
		+	\| Classify the case (T1)
		+	\| None. Created when S1 becomes active.
		+	\| Requited, and blocking human task.
		+	\|- style="vertical-align: top;"
		+	\| Inspect the plaint (T2)
		+	\| T1 completes OR a new I2 is created.
		+	\| Requited, repeatable, and blocking human task; because multiple I2s may be created. First time is expected to execute based on T1 completion, and if there is a problem with plaint the case worker can plan dT1 in which case a new I2 may be submitted by the party. Note that if the task is being executed and a new I2 is present, then I4 may be created by the competent officer during the execution of this task.
		+	\|-
		+	\| Asses plaint docs to charge court fee (T3)
		+	\| None. Created when S2 becomes active.
		+	\| Requited, and blocking human task.
		+	\|-
		+	\| Issue a receipt of court fee (T4)
		+	\| T3 completes AND I3 is created.
		+	\| Required tasks implemented by a process.
		+	\|-
		+	\| Assign a judge (T5)
		+	\| T4 completes.
		+	\| Requited, blocking human task
		+	\|-
		+	\| Order (T6)
		+	\| S3 becomes active OR a new I4 is created OR a new I5 is created.
		+	\| Required, repeatable, and blocking human task. This task is expected to execute the first time when a judge is assigned, and after that each time a new I4 or I5 are created.
		+	\|-
		+	\| Examine witnesses (T7)
		+	\| None. Created when S4 becomes active.
		+	\| Repeatable, manually activated, and blocking human task
		+	\|-
		+	\| Review evidence (T8)
		+	\| None. Created when S4 becomes active.
		+	\| Requited, repeatable, manually activated, and blocking human task.
		+	\|-
		+	\| Sentence (T9)
		+	\| S4 completes.
		+	\| Requited, and blocking human task. Note that I7 will be created by the judge during the execution of this task.
		+	\|-
		+	\| Sentence (T10)
		+	\| None. Created when dS2 becomes active.
		+	\| Requited, and blocking human task. Note that I7 will be created by the judge during the execution of this task.
		+	\|-
		+	\| Inform litigant to amend the plaint (T11)
		+	\| None. Created when S5 becomes active.
		+	\| Requited, and non-blocking human task.
		+	\|-
		+	\| Accept the plaint (T12)
		+	\| New I6 is created
		+	\| Optional and blocking human task. Note that I4 will be created by the competent officer during the execution of this task.
		+	\|-
		+	\| Do report to the Judge (T13)
		+	\| Timer E3 completes.
		+	\| Optional and blocking human task. Note that I5 will be created by the competent officer during the execution of this task.
		+	\|-
		+	\| Inform litigant to amend the plaint (dT1)
		+	\| None. Discretionary task.
		+	\| Non-blocking human task.
		+	\|}
		+
		+	Table 5: Tasks.
		+
		+
		+	=== The plaint receipt process CMMN model ===
		+	The following CMMN model describes the plaint receipt process. This section presents the model and informally describes the semantics. Figure 4, provides the case model with all the stages collapsed. The arrival of the Plaint (I1) document starts the case. The case is created and the Plaint (I1) document added to the case file. That can be done manually, although some tools, like IBM Case Management , can be configured to automatically create the case when a document arrives to a content repository via any means including email. The arrival of Plaint (I1) to the case file triggers the entry criteria of the Inspect plaint (S1) stage that start execution. For the case to complete, Inspect plaint (S1), Collect payment (S2), and Process plaint (S3) must execute, indicated by the exclamation sign (!).


	[[Category: Case Management]]		[[Category: Case Management]]

← Older revision		Revision as of 14:17, 18 January 2017
Line 143:		Line 143:

	Table 2: Information model.		Table 2: Information model.
		+
		+
		+	=== Milestones ===
		+	Milestones represent accomplishments during the process of the case. Due to the large variations between case instances, milestones are important to understand the progress of a particular case instance. Table 3, describes the milestones and the condition that should be meet for the milestone to be achieved.
		+
		+
		+	{\| class="wikitable" style="text-align: left; width: 60%;"
		+	\|- style="vertical-align: top;"
		+	\| style="width: 15%; background: #0b98d6; color: #ffffff;" \| '''Milestone'''
		+	\| style="width: 15%; background: #0b98d6; color: #ffffff;" \| '''Entry criteria'''
		+	\| style="width: 30%; background: #0b98d6; color: #ffffff;" \| '''Description'''
		+	\|- style="vertical-align: top;"
		+	\| Inspected plaint (M1)
		+	\| Completion of stage S1
		+	\| Triggered when a plaint has been accepted
		+	\|- style="vertical-align: top;"
		+	\| Judge assigned (M2)
		+	\| Completion of task T5
		+	\| Triggered when a Judge has been assigned to the case
		+	\|-
		+	\| Case decided (M3)
		+	\| Creation of I7
		+	\| Triggered when the case have been decided and a sentence has been produced
		+	\|}
		+
		+	Table 3: Milestones.
		+
		+
		+	=== Stages ===
		+	Stages are behavioral containers, and they are used to manage the complexity of the model by using nesting to hide details. Table 4, describes the stages in this example, and when they are executed (entry criteria).
		+
		+
		+	{\| class="wikitable" style="text-align: left; width: 60%;"
		+	\|- style="vertical-align: top;"
		+	\| style="width: 15%; background: #0b98d6; color: #ffffff;" \| '''Stage'''
		+	\| style="width: 15%; background: #0b98d6; color: #ffffff;" \| '''Entry criteria'''
		+	\| style="width: 30%; background: #0b98d6; color: #ffffff;" \| '''Description'''
		+	\|- style="vertical-align: top;"
		+	\| Inspect plaint (S1)
		+	\| Arrival of a plaint (I1)
		+	\| Required stage, but not auto-complete; because T1, T2, and dT1 may complete before an I2 arrives
		+	\|- style="vertical-align: top;"
		+	\| Collect payment (S2)
		+	\| Completion of Inspected plaint (M1)
		+	\| Required and auto-complete stage
		+	\|-
		+	\| Process plaint (S3)
		+	\| Completion of Judge Assigned (M2)
		+	\| Required and manually activated stage
		+	\|-
		+	\| (S4)
		+	\| None. Starts when dS1 transitions to active
		+	\| Required stage, but not auto-complete; because T7 add T8 can be executed multiple times and T7 is optional
		+	\|-
		+	\| (S5)
		+	\| None. Starts when dS3 transitions to active
		+	\| This stage has an exit criteria that is triggered when T13 is completed
		+	\|-
		+	\| Accept (dS1)
		+	\| None. Discretionary and may be added to the plan during the execution of T6.
		+	\| Auto-complete discretionary stage
		+	\|-
		+	\| Reject (dS2)
		+	\| None. Discretionary and may be added to the plan during the execution of T6.
		+	\| Auto-complete discretionary stage
		+	\|-
		+	\| Return (dS3)
		+	\| None. Discretionary and may be added to the plan during the execution of T6.
		+	\| Auto-complete and repeatable discretionary stage. It is repeatable because the plaint (I1) could be returned multiple times to the party
		+	\|}
		+
		+	Table 4: Stages.


	[[Category: Case Management]]		[[Category: Case Management]]

← Older revision		Revision as of 13:51, 18 January 2017
Line 96:		Line 96:
	\|}		\|}

		+	Table 1: Roles.

		+
		+	=== Information model ===
		+	Table 2, describes the different case file items. In this example, the case file items are documents. The table describes the role that produces the document, and the task in which the document is produced. Note that some documents originate outside the case management system; and for those documents produced within a task in the system, there is no explicit modeling of that fact.
		+
		+
		+	{\| class="wikitable" style="text-align: left; width: 70%;"
		+	\|- style="vertical-align: top;"
		+	\| style="width: 20%; background: #0b98d6; color: #ffffff;" \| '''Case file item'''
		+	\| style="width: 20%; background: #0b98d6; color: #ffffff;" \| '''Produced by'''
		+	\| style="width: 30%; background: #0b98d6; color: #ffffff;" \| '''Produced at task'''
		+	\|- style="vertical-align: top;"
		+	\| Plaint (I1)
		+	\| Party
		+	\|
		+	\|- style="vertical-align: top;"
		+	\| Amended plaint (I2)
		+	\| Party
		+	\|
		+	\|-
		+	\| Payment (I3)
		+	\| Party
		+	\|
		+	\|-
		+	\| Accepted Amended Plaint (I4)
		+	\| Competent officer
		+	\| Inspect the plaint (T2)<br>Accept the plaint (T12)
		+	\|-
		+	\| Report on Plaint (I5)
		+	\| Competent officer
		+	\| Do report to the judge (T13)
		+	\|-
		+	\| Amend Plaint (I6)
		+	\| Party
		+	\|
		+	\|-
		+	\| Sentence (I7)
		+	\| Judge
		+	\| Sentence (T9)<br>Sentence (T10)
		+	\|-
		+	\| Receipt (I8)
		+	\| Finance officer
		+	\| Issue a receipt of court fee (T4)
		+	\|}
		+
		+	Table 2: Information model.


	[[Category: Case Management]]		[[Category: Case Management]]

@@ Line 70: / Line 70: @@
 |- style="vertical-align: top;"
 | Competent officer
 | Accepted Amended Plaint (I4)<br>Report on Plaint (I5)
 Accepted Amended Plaint (I4)<br>
 Report on Plaint (I5)
 | Classify the case (T1)<br>Inspect the plaint (T2), including planning<br>Asses plaint docs to charge court fee (T3)<br>inform litigant to amend the plaint (dT1)<br>Assign a judge (T5)<br>Accept the plaint (T12)<br>Do report to the judge (T13)
+|
@@ Line 79: / Line 77: @@
 | Filing clerk
+|
-| Inform litigant to amend the plaint (T11)<br>
+| Inform litigant to amend the plaint (T11)<br>Inform litigant to amend the plaint (dT1)
 Inform litigant to amend the plaint (dT1)
 | Prototype of Civil Court Case Management in Thailand
 |-
@@ Line 90: / Line 87: @@
 | Judge
 | Sentence (I7)
-| Manually schedule Process plaint (S3)<br>
+| Manually schedule Process plaint (S3)<br>Order (T6), including planning<br>Examine witnesses (T7)<br>Review evidence (T8)<br>Sentence (T9)<br>Sentence (T10)
 Order (T6), including planning<br>
 Examine witnesses (T7)<br>
 Review evidence (T8)<br>
 Sentence (T9)<br>
 Sentence (T10)
 | Process plaint (S3) (S5)
 |-
 | Party
-| Plaint (I1)<br>
+| Plaint (I1)<br>Amended plaint (I2)<br>Payment (I3)<br>Amend Plaint (I6)
 Amended plaint (I2)<br>
 Payment (I3)<br>
 Amend Plaint (I6)
+|
+|