# Is DV\_STATE and it's profile constraint C\_DV\_STATE used anywhere in the specs?

**URL:** <https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026>\
**Category:** RM\
**Created:** [4 November 2021 00:14 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026 "2021-11-04T00:14:38Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [4 November 2021 00:14 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/1 "2021-11-04T00:14:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [4 November 2021 18:02 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/2 "2021-11-04T18:02:08Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [5 November 2021 20:35 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/3 "2021-11-05T20:35:53Z")

</div>

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.

 ![archetype_profile](https://discourse.openehr.org/uploads/default/original/2X/b/b87babb8d9c5fe1ec025a81aab5179e8c648af39.png)

 ![datatypes](https://discourse.openehr.org/uploads/default/original/2X/0/0f8e98617a5ba18a5ea76fb450e45981e77d9a1e.png)

![ism_transition](https://discourse.openehr.org/uploads/default/original/2X/c/c21f7e33549bec37693288fcdf47676b5d2ececb.png)

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

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [7 November 2021 14:25 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/4 "2021-11-07T14:25:39Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [7 November 2021 17:38 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/5 "2021-11-07T17:38:05Z")

</div>

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](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___18_5_2_83e026d_1524569120777_103424_5686) in the RM, and also the [Task Planning Task state machine](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___18_2_83e026d_1488734670310_710115_4985).
- the reason `C_DV_STATE`and 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](https://wolandscat.net/2019/03/07/the-long-slow-death-of-uml/) 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.

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [9 November 2021 04:21 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/6 "2021-11-09T04:21:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [9 November 2021 08:41 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/7 "2021-11-09T08:41:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [9 November 2021 08:43 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/8 "2021-11-09T08:43:59Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 November 2021 10:28 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/9 "2021-11-09T10:28:37Z")

</div>

> [@pablo](#):
>
> considering it is not used, should the Archetype Profile spec be updated to remove the C\_DV\_STATE

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.

> [@pablo](#):
>
> Also, if DV\_STATE is not used, shouldn’t that be removed from the Data Types?

It could be - probably should be a choice of combined implementers.

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [9 November 2021 11:57 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/10 "2021-11-09T11:57:22Z")

</div>

> [@thomas.beale](#):
>
> Well we treat this spec as technically obsolete, since it has no existence in the ADL2 spec set - it will naturally disappear.

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.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 November 2021 13:18 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/11 "2021-11-09T13:18:09Z")

</div>

> [@pablo](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![borut.jures](https://discourse.openehr.org/user_avatar/discourse.openehr.org/borut.jures/32/1391_2.png) [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Post date:** [9 November 2021 13:52 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/12 "2021-11-09T13:52:54Z")

</div>

> [@pablo](#):
>
> We need to consider current vendors that are in 1.x and not planning for 2.x anytime soon.

I have generated diagrams for [the original RM release 1.0.2](https://neoehr.com/openehr/uml/rm102) if they are useful to those on 1.x.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 November 2021 14:31 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/13 "2021-11-09T14:31:20Z")

</div>

> [@borut.jures](#):
>
> I have generated diagrams for [the original RM release 1.0.2](https://neoehr.com/openehr/uml/rm102) if they are useful to those on 1.x.

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

---

<div class="post-metadata">

**Author:** ![borut.jures](https://discourse.openehr.org/user_avatar/discourse.openehr.org/borut.jures/32/1391_2.png) [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Post date:** [9 November 2021 16:31 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/14 "2021-11-09T16:31:49Z")

</div>

> [@thomas.beale](#):
>
> the most typical combination of AOM and RM today is AOM 1.4 (i.e. ‘ADL 1.4’)

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.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 November 2021 16:37 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/15 "2021-11-09T16:37:38Z")

</div>

> [@borut.jures](#):
>
> Does it validate for you

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

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [9 November 2021 17:29 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/16 "2021-11-09T17:29:33Z")

</div>

> [@thomas.beale](#):
>
> I am fairly sure there are no platform implementers still on RM 1.0.2.

[https://cloudehrserver.com/](https://cloudehrserver.com/) and [https://atomik.app/](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.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 November 2021 23:03 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/17 "2021-11-09T23:03:20Z")

</div>

> [@borut.jures](#):
>
> - “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.

The first is an error which my validator doesn’t catch; the rest look correct to me in the file (ex: [EXTERNAL\_QUERY](https://github.com/openEHR/specifications-ITS-BMM/blob/master/components/BASE/Release-1.0.4/openehr_expression_104.bmm#L115)).

---

<div class="post-metadata">

**Author:** ![borut.jures](https://discourse.openehr.org/user_avatar/discourse.openehr.org/borut.jures/32/1391_2.png) [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Post date:** [10 November 2021 11:10 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/18 "2021-11-10T11:10:33Z")

</div>

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](https://neoehr.com/dashboard).

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [10 November 2021 12:04 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/19 "2021-11-10T12:04:34Z")

</div>

Hi Borut,

> [@borut.jures](#):
>
> 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”.

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

 ![base_104](https://discourse.openehr.org/uploads/default/original/2X/3/3449ae6345df2f03391ff90f4b1ebc86698fa568.png)

Point 2 - [openehr\_expression\_1.0.4](https://github.com/openEHR/specifications-ITS-BMM/blob/master/components/BASE/Release-1.0.4/openehr_expression_104.bmm) 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?

---

<div class="post-metadata">

**Author:** ![borut.jures](https://discourse.openehr.org/user_avatar/discourse.openehr.org/borut.jures/32/1391_2.png) [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Post date:** [10 November 2021 12:27 UTC](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026/20 "2021-11-10T12:27:42Z")

</div>

> [@thomas.beale](#):
>
> Not sure if I understand point 1 - which types are missing?

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 😊

> [@thomas.beale](#):
>
> Point 2 - [openehr\_expression\_1.0.4](https://github.com/openEHR/specifications-ITS-BMM/blob/master/components/BASE/Release-1.0.4/openehr_expression_104.bmm) doesn’t have any includes at all - or am I misunderstanding here?

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

> [@thomas.beale](#):
>
> 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’m using [GitHub - openEHR/specifications-ITS-BMM: BMM schemas for use with openEHR systems and tools](https://github.com/openEHR/specifications-ITS-BMM). No problem here.

[Next page](https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026.md?page=2)