There’s a few things to note here.
- state machines are a first class entity in the UML meta-model, so just like we can define a ‘class’ (e.g. class
OBSERVATION) without defining the meta-model of class (class = a container with ‘properties’, ‘methods’ etc), we can define a state machine. The ISM in the UML specs is a state machine that is (like any other) an instance of the UML meta-model for state machine. So is the Version Lifecycle state machine in the RM, and also the Task Planning Task state machine.
- the reason
C_DV_STATEand its sub-model exists in the AOM1.4 openEHR profile was to enable a state machine to be defined as a constrainer for a ‘state’ (of anything - a medication order, a radiology exam, an appointment workflow) within data. In the data, a ‘state’ can just be a numeric or coded atomic datum (e.g. a DV_CODED_TEXT).
We never used the latter, because we came up with the standard Instruction state machine (ISM) which is completely generic, and we devised a way of mapping particular workflow steps in any particular workflow (‘careflow’) to states in the ISM (that all the clinical modellers are used to when creating
This latter approach is very nice, because it means you can just query for every ACTION (usually during some time-frame) that has
ISM_TRANSITION.current_state = active OR suspended - it doesn’t matter what the specific careflow step is (e.g. could be ‘dispense’ or ‘re-issue’ etc), the query will get all the active ACTIONS (‘suspended’ means still active, clinically).
So we don’t need a meta-model of state machines in the openEHR RM or anywhere similar.
The other two state machines in openEHR don’t happen to need this mapping approach (at least not yet).
BMM is a meta-model like UML, but with (nearly all) the broken bits fixed, and literally 1/8 of the size (a mini-me…). Something I have on the TODO list for BMM is indeed to add some meta-model for state machines, and it would look something like the
STATE_MACHINE class and its sub-parts that Pablo screen-shotted above. The reason to do this is to allow the three state machines to be represented natively in BMM, just as they are currently represented in UML.
UML is slowly dying, and I foresee the day that we treat BMM as the master model for everything, so we would need to do this at some stage. Right now however, we don’t need to do anything.
We also don’t (in my opinion) need to recreate C_DV_STATE in AOM2, since we don’t use it in AOM1.4, for the reasons described above. So I think we can allow it to have its natural obsolescence.