# DV\_STATE

**URL:** <https://discourse.openehr.org/t/dv-state/12512>\
**Category:** Reference Implementation: Java (archive)\
**Created:** [13 October 2006 11:06 UTC](https://discourse.openehr.org/t/dv-state/12512 "2006-10-13T11:06:33Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mattias\_Forss1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)\
**Post date:** [13 October 2006 11:06 UTC](https://discourse.openehr.org/t/dv-state/12512/1 "2006-10-13T11:06:33Z")

</div>

Hi,

I'm wondering where the DV\_STATE is used in archetypes? I have only  
seen the ISM\_TRANSISTION state in the ACTION archetypes, but that is  
probably something else. I noticed there is a class C\_DV\_STATE in the  
archetype profile that constrains allowed values of the attribute  
'value' of the DV\_STATE, but I don't know what syntax a parser need to  
find in order to create an instance of a C\_DV\_STATE.

If the ISM\_TRANSITION is only supposed to correspond to an instance of  
a C\_COMPLEX\_OBJECT and not a C\_DV\_STATE then I guess there's nothing  
stopping me from implementing support for action archetypes in the  
editor, but since I originally thought the ISM\_TRANSITION corresponded  
to a C\_DV\_STATE I decided not to support action archetypes until the  
Java ADL parser was fixed.

Now, what are the minimum requirements on the reference implementation  
before I can start working on adding support for action and  
instruction archetypes? The Java reference implementation doesn't  
fully support archetype slots, the assertion package is not  
implemented and there is nothing in the parser that deals with  
C\_DV\_STATE. Can anyone point out the things that are needed before  
action and instruction are fully supported by the parser and the  
serializer?

Regards,

Mattias

---

<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:** [16 October 2006 12:13 UTC](https://discourse.openehr.org/t/dv-state/12512/2 "2006-10-16T12:13:34Z")

</div>

Mattias Forss wrote:

> Hi,
> 
> I'm wondering where the DV\_STATE is used in archetypes? I have only  
> seen the ISM\_TRANSISTION state in the ACTION archetypes, but that is  
> probably something else. I noticed there is a class C\_DV\_STATE in the  
> archetype profile that constrains allowed values of the attribute  
> 'value' of the DV\_STATE, but I don't know what syntax a parser need to  
> find in order to create an instance of a C\_DV\_STATE.
> 
> If the ISM\_TRANSITION is only supposed to correspond to an instance of  
> a C\_COMPLEX\_OBJECT and not a C\_DV\_STATE then I guess there's nothing  
> stopping me from implementing support for action archetypes in the  
> editor, but since I originally thought the ISM\_TRANSITION corresponded  
> to a C\_DV\_STATE I decided not to support action archetypes until the  
> Java ADL parser was fixed.

it may be that ISM\_TRANSITION should be changed to a DV\_STATE from a  
DV\_CODED\_TEXT. This would be a small change. I will raise this as an issue.

> Now, what are the minimum requirements on the reference implementation  
> before I can start working on adding support for action and  
> instruction archetypes? The Java reference implementation doesn't  
> fully support archetype slots, the assertion package is not  
> implemented and there is nothing in the parser that deals with  
> C\_DV\_STATE. Can anyone point out the things that are needed before  
> action and instruction are fully supported by the parser and the  
> serializer?  
> &nbsp;&nbsp;

I would not worry about assertions yet - there is a certain level of  
complexity, and they are in the category of the "80% of effort that  
supports 20% of use cases". Slots do need to be implemented, and I would  
encourage that to happen earlier rather than later (within the  
contraints of people's time;-). I would also assume the current model of  
ISM\_TRANSITION , as shown in  
[http://www.openehr.org/uml/release-1.0.1/Browsable/\_9\_0\_76d0249\_1109249648736\_872559\_12384Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)  
- i.e. not using DV\_STATE. If we decided to include DV\_STATE, then we  
should treat this as a CR when it comes, and it will incur a very small  
change in the RM, and I think small changes in the parser.

So - in summary, I would assume the RM as documented on the website in  
the Release 1.0.1 candidate (plus recent changes discussed among us, but  
not yet published online).

Let me know if this helps - or what further concerns need to be  
addressed so you can continue coding right now.

- thomas

---

<div class="post-metadata">

**Author:** ![Mattias\_Forss1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)\
**Post date:** [16 October 2006 13:26 UTC](https://discourse.openehr.org/t/dv-state/12512/3 "2006-10-16T13:26:37Z")

</div>

> \> Now, what are the minimum requirements on the reference implementation  
> \> before I can start working on adding support for action and  
> \> instruction archetypes? The Java reference implementation doesn't  
> \> fully support archetype slots, the assertion package is not  
> \> implemented and there is nothing in the parser that deals with  
> \> C\_DV\_STATE. Can anyone point out the things that are needed before  
> \> action and instruction are fully supported by the parser and the  
> \> serializer?  
> \>  
> I would not worry about assertions yet - there is a certain level of  
> complexity, and they are in the category of the "80% of effort that  
> supports 20% of use cases". Slots do need to be implemented, and I would  
> encourage that to happen earlier rather than later (within the  
> contraints of people's time;-). I would also assume the current model of  
> ISM\_TRANSITION , as shown in

Thanks for your answer Thomas.

So is it okay to change the implementation of the ArchetypeSlot class  
in the Java reference implementation to hold two sets of CString as  
includes and excludes instead of sets of Assertion?

Should it be possible to create different types of ArchetypeSlot  
instances, e.g. with domain concept matching, rm originator matching,  
concept name or specialisation name matching or should that be  
specified in the CString (later in the Assertion)? I don't know what's  
been specified concerning that part of the ARCHETYPE\_SLOT.

> [http://www.openehr.org/uml/release-1.0.1/Browsable/\_9\_0\_76d0249\_1109249648736\_872559\_12384Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)  
> - i.e. not using DV\_STATE. If we decided to include DV\_STATE, then we  
> should treat this as a CR when it comes, and it will incur a very small  
> change in the RM, and I think small changes in the parser.

All right, sounds fine, but should the parser treat the ISM\_TRANSITION  
classes of the ism\_transition attribute of ACTION as C\_COMPLEX\_OBJECT  
or something else?

Two more questions related to this:

1) Why isn't the transition attribute of ISM\_TRANSITION found in  
archetypes? I think there are some settings for it in the Ocean  
editor, but the ADL never changes when you modify these...

2) The attribute 'instruction\_details' of the ACTION class is never  
found in archetypes. Is this because the details of the instruction  
that caused the action are added when the action data is created  
(which always is created with the instruction that caused the action)?

> So - in summary, I would assume the RM as documented on the website in  
> the Release 1.0.1 candidate (plus recent changes discussed among us, but  
> not yet published online).

Yes, I try to assume this, but when I found the C\_DV\_STATE in the AOM  
constrained a thing in the RM which didn't seem to be used, I was  
unsure what I can implement before action archetypes can be fully  
supported. Is the C\_COMPLEX\_OBJECT form of the ISM\_TRANSITION that the  
parser currently instantiates the definite representation, or will it  
change to C\_DV\_STATE?

Regards

Mattias

---

<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:** [16 October 2006 14:41 UTC](https://discourse.openehr.org/t/dv-state/12512/4 "2006-10-16T14:41:24Z")

</div>

Mattias Forss wrote:

> &nbsp;&nbsp;  
> Thanks for your answer Thomas.
> 
> So is it okay to change the implementation of the ArchetypeSlot class  
> in the Java reference implementation to hold two sets of CString as  
> includes and excludes instead of sets of Assertion?  
> &nbsp;&nbsp;

yes, that would be a reasonable compromise at the moment - there are no  
archetypes so far for which the slot specification is not just a regex  
on the ids. So that is a safe thing to do.

> Should it be possible to create different types of ArchetypeSlot  
> instances, e.g. with domain concept matching, rm originator matching,  
> concept name or specialisation name matching or should that be  
> specified in the CString (later in the Assertion)? I don't know what's  
> been specified concerning that part of the ARCHETYPE\_SLOT.  
> &nbsp;&nbsp;

we don't even bother with that in the Ocean Editor, but doing that would  
probably not be hard to do - I would think of 2 drop-downs, or other  
choice controls, for the 1) domain concept and 2) the model - class  
combination (i.e. "EHR-Observation"). You could hardwire this at the  
moment - I know it doesn't feel good to do that in software, but in  
fact, the combinations of model and class won't change in the future, so  
that is one thing that won't break anytime soon.

> > [http://www.openehr.org/uml/release-1.0.1/Browsable/\_9\_0\_76d0249\_1109249648736\_872559\_12384Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)  
> > - i.e. not using DV\_STATE. If we decided to include DV\_STATE, then we  
> > should treat this as a CR when it comes, and it will incur a very small  
> > change in the RM, and I think small changes in the parser.  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > All right, sounds fine, but should the parser treat the ISM\_TRANSITION  
> > classes of the ism\_transition attribute of ACTION as C\_COMPLEX\_OBJECT  
> > or something else?  
> > &nbsp;&nbsp;

C\_COMPLEX\_OBJECT

> Two more questions related to this:
> 
> 1) Why isn't the transition attribute of ISM\_TRANSITION found in  
> archetypes? I think there are some settings for it in the Ocean  
> editor, but the ADL never changes when you modify these...  
> &nbsp;&nbsp;

I have to check up on this with the archetype group, but I would not be  
surprised not to see this specified in the archetype. Remember, the  
archetype editor only has to allow archetyping for "what makes sense to  
archetype", which is not everything in a reference model, only things  
that can be configured at design time. Some attributes will only be set  
at runtime, and ISM\_TRANSITION.transition is probably one of these.  
Since the current\_state attribute is archetyped, it doesn't matter what  
transition led to that state - that is most likely the design thinking.

> 2) The attribute 'instruction\_details' of the ACTION class is never  
> found in archetypes. Is this because the details of the instruction  
> that caused the action are added when the action data is created  
> (which always is created with the instruction that caused the action)?  
> &nbsp;&nbsp;

this is another thing that makes no sense to archetype. This object is  
used to record: what Instruction and Activity does this Action  
correspond to? So it is only ever set at runtime.

> &nbsp;&nbsp;
> 
> > So - in summary, I would assume the RM as documented on the website in  
> > the Release 1.0.1 candidate (plus recent changes discussed among us, but  
> > not yet published online).  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > Yes, I try to assume this, but when I found the C\_DV\_STATE in the AOM  
> > constrained a thing in the RM which didn't seem to be used, I was  
> > &nbsp;&nbsp;

it isn't yet;-)

> unsure what I can implement before action archetypes can be fully  
> supported. Is the C\_COMPLEX\_OBJECT form of the ISM\_TRANSITION that the  
> parser currently instantiates the definite representation, or will it  
> change to C\_DV\_STATE?  
> &nbsp;&nbsp;

no, it will always be C\_COMPLEX\_OBJECT. The only questoin is whether  
ISM\_TRANSITION.current\_state changes from C\_DV\_CODED\_TEXT to C\_DV\_STATE  
(which we will solve later).

- thomas

---

<div class="post-metadata">

**Author:** ![Mattias\_Forss1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)\
**Post date:** [16 October 2006 15:32 UTC](https://discourse.openehr.org/t/dv-state/12512/5 "2006-10-16T15:32:12Z")

</div>

> Mattias Forss wrote:  
> \>  
> \>\>  
> \>  
> \> Thanks for your answer Thomas.  
> \>  
> \> So is it okay to change the implementation of the ArchetypeSlot class  
> \> in the Java reference implementation to hold two sets of CString as  
> \> includes and excludes instead of sets of Assertion?  
> \>  
> yes, that would be a reasonable compromise at the moment - there are no  
> archetypes so far for which the slot specification is not just a regex  
> on the ids. So that is a safe thing to do.

Thanks... maybe I can do some coding in the reference implementation  
in order to support archetype slots in the editor. If you are reading  
this Rong, what are your opinions on this?

> \> Should it be possible to create different types of ArchetypeSlot  
> \> instances, e.g. with domain concept matching, rm originator matching,  
> \> concept name or specialisation name matching or should that be  
> \> specified in the CString (later in the Assertion)? I don't know what's  
> \> been specified concerning that part of the ARCHETYPE\_SLOT.  
> \>  
> we don't even bother with that in the Ocean Editor, but doing that would  
> probably not be hard to do - I would think of 2 drop-downs, or other  
> choice controls, for the 1) domain concept and 2) the model - class  
> combination (i.e. "EHR-Observation"). You could hardwire this at the  
> moment - I know it doesn't feel good to do that in software, but in  
> fact, the combinations of model and class won't change in the future, so  
> that is one thing that won't break anytime soon.

I actually think it's not that bad to hardwire it in this case,  
because the editor has only a fixed set of rm originator, model and  
class combinations that it supports.

On the other hand, we could have two text fields where the users are  
allowed to input any model and class combinations...

> \>\> [http://www.openehr.org/uml/release-1.0.1/Browsable/\_9\_0\_76d0249\_1109249648736\_872559\_12384Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)  
> \>\> - i.e. not using DV\_STATE. If we decided to include DV\_STATE, then we  
> \>\> should treat this as a CR when it comes, and it will incur a very small  
> \>\> change in the RM, and I think small changes in the parser.  
> \>\>  
> \>  
> \> All right, sounds fine, but should the parser treat the ISM\_TRANSITION  
> \> classes of the ism\_transition attribute of ACTION as C\_COMPLEX\_OBJECT  
> \> or something else?  
> \>  
> C\_COMPLEX\_OBJECT

Okay, great! Now I know I can start working on supporting the action  
and instruction archetypes. I actually could have done it long ago,  
but other usability and bug fixes has been made before I knew this.  
The original issue that blocked the progress on supporting action and  
instruction archetypes in the editor was that I thought lots of things  
were needed in the reference implementation before it could parse and  
output these archetypes.

Rong actually pointed out that he had to do major changes in the AOM  
(the assertion package etc.) before action and instruction could be  
supported, so I went on working with other things. Now if we could  
leave the assertions for archetype slots I guess I can start working  
on the stuff that have been left behind for far too long and maybe we  
can soon release a much more complete editor than before.

> \> Two more questions related to this:  
> \>  
> \> 1) Why isn't the transition attribute of ISM\_TRANSITION found in  
> \> archetypes? I think there are some settings for it in the Ocean  
> \> editor, but the ADL never changes when you modify these...  
> \>  
> I have to check up on this with the archetype group, but I would not be  
> surprised not to see this specified in the archetype. Remember, the  
> archetype editor only has to allow archetyping for "what makes sense to  
> archetype", which is not everything in a reference model, only things  
> that can be configured at design time. Some attributes will only be set  
> at runtime, and ISM\_TRANSITION.transition is probably one of these.  
> Since the current\_state attribute is archetyped, it doesn't matter what  
> transition led to that state - that is most likely the design thinking.

Yes I understand that, I just thought it was supposed to be in  
archetypes since the editor had a setting for transition.

> \> 2) The attribute 'instruction\_details' of the ACTION class is never  
> \> found in archetypes. Is this because the details of the instruction  
> \> that caused the action are added when the action data is created  
> \> (which always is created with the instruction that caused the action)?  
> \>  
> this is another thing that makes no sense to archetype. This object is  
> used to record: what Instruction and Activity does this Action  
> correspond to? So it is only ever set at runtime.

That was a 'yes' answer to my question, so I assumed what you said...

By the way, why doesn't the Ocean editor allow to set run-time name  
constraints for the Activity? An Instruction is supposed to have  
several Activities, and therefore I think it would be logical that  
they should be able to have different names at run-time. Also, the  
Activity class inherits Locatable, so it's legal for it to have the  
name attribute.

> no, it will always be C\_COMPLEX\_OBJECT. The only questoin is whether  
> ISM\_TRANSITION.current\_state changes from C\_DV\_CODED\_TEXT to C\_DV\_STATE  
> (which we will solve later).

Thanks a lot, your answer has helped me figuring out a lot of issues.  
I have tried to get a grip on these things several times, but maybe my  
questions have been too unspecified to get a clear answer. I guess my  
perseverance has finally paid off 😉

Regards,

Mattias

---

<div class="post-metadata">

**Author:** ![rong.chen](https://discourse.openehr.org/user_avatar/discourse.openehr.org/rong.chen/32/515_2.png) [@rong.chen](https://discourse.openehr.org/u/rong.chen)\
**Post date:** [16 October 2006 22:02 UTC](https://discourse.openehr.org/t/dv-state/12512/6 "2006-10-16T22:02:16Z")

</div>

Mattias Forss wrote:

> &nbsp;&nbsp;
> 
> > Mattias Forss wrote:  
> > &nbsp;&nbsp;&nbsp;&nbsp;
> > 
> > > Thanks for your answer Thomas.
> > > 
> > > So is it okay to change the implementation of the ArchetypeSlot class  
> > > in the Java reference implementation to hold two sets of CString as  
> > > includes and excludes instead of sets of Assertion?
> > 
> > yes, that would be a reasonable compromise at the moment - there are no  
> > archetypes so far for which the slot specification is not just a regex  
> > on the ids. So that is a safe thing to do.  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > Thanks... maybe I can do some coding in the reference implementation  
> > in order to support archetype slots in the editor. If you are reading  
> > this Rong, what are your opinions on this?  
> > &nbsp;&nbsp;

Actually it's just fixed as the last commit to AOM on the sandbox  
branch. The parser still needs to be updated for this.

/Rong