Also noted the ISM and ISM_TRANSITION class, which are in use both in data and modeling, overlaps with DV_STATE and C_DV_STATE in scope.
Thomas explained in Discourse some details about the models and metamodels, which basically ends in: nor DV_STATE or C_DV_STATE will ever be implemented, also suggesting not doing any actions on that area and let those models go in preference of AOM2.
My comment about that was:
"[We might] remove, deprecate or [add] 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…"
"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."
My proposal is to update the data types and archetype profile specs to a new minor version with the deprecation of DV_STATE data type and C_DV_STATE constraint, without removing them yet. So this deprecation could lead to total removal on the next major version release.
From https://discourse.openehr.org/t/is-dv-state-and-its-profile-constraint-c-dv-state-used-anywhere-in-the-specs/2026
I've noticed the DV_STATE data type is not in use anywhere and C_DV_STATE constraint type from the Archetype Profile spec (https://specifications.openehr.org/releases/1.0.2/architecture/am/openehr_archetype_profile.pdf section 3) is not implemented on any modeling tool.
Also noted the ISM and ISM_TRANSITION class, which are in use both in data and modeling, overlaps with DV_STATE and C_DV_STATE in scope.
Thomas explained in Discourse some details about the models and metamodels, which basically ends in: nor DV_STATE or C_DV_STATE will ever be implemented, also suggesting not doing any actions on that area and let those models go in preference of AOM2.
My comment about that was:
"[We might] remove, deprecate or [add] 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…"
"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."
My proposal is to update the data types and archetype profile specs to a new minor version with the deprecation of DV_STATE data type and C_DV_STATE constraint, without removing them yet. So this deprecation could lead to total removal on the next major version release.