| Table of Contents |
|---|
Date
27 June 2019
Previous Meeting - Next Meeting
Agenda
Item / Topic | Presenter | Description |
|---|---|---|
| Continue review of proposed extensions to Item Definition metamodel /wiki/spaces/BPMPLUS/pages/420970781 | Stephen White (Unlicensed) | Walk through metamodel proposal |
| Review some notational /wiki/spaces/BPMPLUS/pages/420937838 | Stephen White (Unlicensed) | Walk through example diagrams |
Participants
Stephen White (Unlicensed); Claude Nanjo; John Svirbely (Unlicensed); Keith Salzman; @Marc Sainvil; Peter Haug; Robert Lario; @Adam; Sharnita Riley
Goals
List goals for this meeting (e.g., Set design priorities for FY19):
- Address any Situational Data Requirements from the Field Guide and OMG Meetings
Discussion all comments on the Item Definition update proposal
- Update document as appropriate
- Identify next steps
Notes (raw)
We discussed how we are using Data Objects in BPMN - by breaking up larger data structures into smaller structures that are appropriate for the context where they are being used.
For example, , we might be using the demographics of a patient in a decision. The demographics are part of a larger patient health record structure. It would add to the understandability of the diagram to have a Data Object named "Demographics" when we need it - instead of using the larger "Patient Health Record" Data Object.
However, a separate Demographics Data Object is indeed separate from Patient Health Record. There is no way to specify in BPMN (or CMMN) to specify that one Data Object is actually a sub-element of another Data Object.
These are our options:
- Ignore the issue and leave to the Consumers of a SCP to deal with the data appropriately.
- With this we don't need to change the Field Guide or add any requirements to SDMN.
- Change the Field Guide method to specify that we use only the top-level structures in processes and cases.
- This would be accurate, but the details of the SCP would be less clear.
- Change the Field Guide such that we add "conversion tasks" that map the data from the top-level structure objects to the context-specific objects.
- E.g., map the data from the Patient Health Record Data Object to the Demographics Data Object.
- The two objects would still be separate objects, but they would contain the same instance data.
- This would add extra clutter on the diagrams and extra work for the modelers.
- E.g., map the data from the Patient Health Record Data Object to the Demographics Data Object.
- Update BPMN and CMMN to allow that Data Objects can be defined as being sub-components of other Data Objects. That is, both data objects automatically hold the same instance data (to the extent that they share the data structure).
- The Field Guide would have to be updated to show how this works.
We didn't come up with any conclusions.
But we will investigate how the data specifications of the BPM+ models may be updated to address this issue.
Chat Log
There were no chat items during the call.
...