Is DV_STATE and it's profile constraint C_DV_STATE used anywhere in the specs?

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.

For DV_STATE, it seems that is not used anywhere in the RM, and testing the Archetype Editor and LinkEHR Editor, it doesn’t seem to be possible to create a constraint definition in an archetype for DV_STATE, which has a specific C_DV_STATE in the AOP (https://specifications.openehr.org/releases/1.0.2/architecture/am/openehr_archetype_profile.pdf).

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.

Thanks.

I’ve never seen it used or supported in any modelling tools.

1 Like

Been thinking about this, there is an overlap between DV_STATE/C_DV_STATE and ISM_TRANSITION/ISM.

Since the ISM (Instruction State Machine) could be represented by C_DV_STATE, which is a State Machine model.

And the ISM_TRANSITION kinds of models a DV_STATE + a TRANSITION.

I’m wondering why do we have forgot about all this in the models.

ism_transition

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 ?

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 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.

2 Likes

@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…

1 Like

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

I think that it is hugely unlikely it has ever been used and should be deprecated.

1 Like

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.

Yep. Let’s make it a SEC agenda item for next call.

1 Like

I have generated diagrams for the original RM release 1.0.2 if they are useful to those on 1.x.

@NeoEHR 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 tried the latest AOM 2.0.6 but my validator reports errors.

components/BASE/Release-1.0.4/openehr_expression_104.bmm:

  • “EXPR_OPERATOR” is specified twice in packages = <
  • Property name for VARIABLE_DECLARATION wasn’t found.
  • Property tag for ASSERTION wasn’t found.
  • Properties context, query_id, query_args for EXTERNAL_QUERY weren’t found.
  • Property item for EXPR_LEAF wasn’t found.
  • Properties precedence_overridden, symbol for EXPR_OPERATOR weren’t wound.

I tried fixing these but wasn’t successful. Does it validate for you?


Does a BMM for AOM 1.4 exist? I can add this one too but I couldn’t find it.

It did when I tried it in the ADL Workbench the other day… but I’ll check through your list.

1 Like

https://cloudehrserver.com/ and https://atomik.app/ are RM 1.0.2 and AOM / TOM 1.4.

Though I would like to invest some weekends to move them to RM 1.0.4, but that won’t happen this year.

1 Like

The first is an error which my validator doesn’t catch; the rest look correct to me in the file (ex: EXTERNAL_QUERY).

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.

All the diagrams for AOM 2.0.6, AOM 2.1.0, AOM 2.2.0, AOM 2.3.0 are now published.

Hi Borut,

Not sure if I understand point 1 - which types are missing? The ADL WB resolves everything, and computes this package structure:

Point 2 - openehr_expression_1.0.4 doesn’t have any includes at all - or am I misunderstanding here?

openEHR_am_206.bmm should definitely include openehr_base_1.0.4. I’m wondering if you are operating off some different BMM repository?

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 :blush:

The original doesn’t have them. I added the one for “openehr_base_1.0.4” to satisfy my validator.

I’m using GitHub - openEHR/specifications-ITS-BMM: BMM schemas for use with openEHR systems and tools. No problem here.