I’m working in the Conformance Testing Specification, in the section for data validation. This includes creating test cases for each data type and to express cases considering different constraints from AOM and AOP.
My question related to conformance validation is if this type should be considered at all, and a broader question is if this type is used/supported at all by any implementation.
Also note the STATE in C_DV_STATE has a String while DV_STATE has a coded value (IMO this is a mismatch and there should be a coded text or a code phrase in the STATE instead of a String).
I suspect that C_DV_STATE may be a historical artefact that has since been replaced by the ISM_TRANSITION structure but not been deprecated from the specs - @thomas.beale ?
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 ACTION archetypes).
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).
However…
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.
@thomas.beale considering it is not used, should the Archetype Profile spec be updated to remove the C_DV_STATE?
Also, if DV_STATE is not used, shouldn’t that be removed from the Data Types?
I mean remove, deprecate or something that clearly states this is not going to be in the future specs, because we are carrying many of these little things into new specs and ITS artifacts instead of letting them go…
We don’t support this domain type in the editor, however as the DV_STATE data type is allowed in the RM then it could have been used when creating archetypes
Well we treat this spec as technically obsolete, since it has no existence in the ADL2 spec set - it will naturally disappear. To actually update it would require transforming the old spec (PDF) to Asciidoctor to create it as a live spec.
It could be - probably should be a choice of combined implementers.
I’m afraid until this is explicitly deprecated and 1.x is still in use, this will still be a valid spec. I think this “natural death” approach works for software but not for specifications, I mean: anyone can come to openEHR and implement specs for ADL/OPT 1.4, 1.5, … and to be compliant they need to support C_DV_STATE and DV_STATE.
We need to consider current vendors that are in 1.x and not planning for 2.x anytime soon.
@borut.jures just an FYI - the most typical combination of AOM and RM today is AOM 1.4 (i.e. ‘ADL 1.4’) and RM 1.0.4 or 1.1.0. The later versions of the RM contain important changes mainly requested by the vendors, so they tend to adopt them quickly.
I am fairly sure there are no platform implementers still on RM 1.0.2.
However, upgrading all the existing archetypes and also operational systems from ADL 1.4. archetypes and OPTs (Operational Templates, made from archetypes) has proved to be more challenging.
I got it working. Here are the changes I had to make:
AOM 2.0.6:
“components/BASE/Release-1.0.4/openehr_expression_104.bmm” uses some base types but it doesn’t include them from “openehr_base_1.0.4”. I added the include.
Consequently I had to remove the cyclic include for “openehr_expression_1.0.4” from “openehr_base_1.0.4”.
In “openEHR_am_206.bmm” I removed the include for “openehr_base_1.0.4” and added one for “openehr_expression_1.0.4”.
These changes worked for me but they don’t “feel clean”. They are not needed for AOM 2.1.0 onwards.
AOM 2.3.0:
I added missing “CONSTRAINT_STATUS” to classes = <"C_REAL", "C_ORDERED",....
“components/AM/openEHR_am_230.bmm” is not in its Release folder like other releases.
It looks like my validator is too strict. But it catches some little inconsistencies. I prefer catching them at the specifications stage instead of looking for a bug in the implementation.
I validate each BMM file on its own and as part of the set of all BMM files included in the schema.
If you validate “openehr_expression_104.bmm” on its own it uses e.g. “String” which is in the “openehr_base_1.0.4”. Since the “base” is not included the validation fails. Without the include the “expression” knows nothing about the types in the “base”.
Validating “openehr_expression_104.bmm” as part of all the BMM files in the schema will succeed since some other BMM file will include the “openehr_base_1.0.4”.
It is not a problem at the schema level and it is not a problem from AOM 2.1.0 forward, so no need to fix it just for me
The original doesn’t have them. I added the one for “openehr_base_1.0.4” to satisfy my validator.
