# ISM\_TRANSITION
**URL:** https://discourse.openehr.org/t/ism-transition/12177
**Category:** Technical (archive)
**Created:** [31 October 2006 14:08 UTC](https://discourse.openehr.org/t/ism-transition/12177 "2006-10-31T14:08:24Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)
#### Post date: [31 October 2006 14:08 UTC](https://discourse.openehr.org/t/ism-transition/12177/1 "2006-10-31T14:08:24Z")
Hi,
I started wondering about different representations of ISM\_TRANSITIONs of the ism\_transition attribute in the ACTION archetypes. I found that the below example:
ISM\_TRANSITION matches {
current\_state matches {
CODED\_TEXT matches {
code matches {[openehr::524]}
}
}
careflow\_step matches {
CODED\_TEXT matches {
code matches {[local::at0001]} – Planned
}
}
}
ISM\_TRANSITION matches {
current\_state matches {
CODED\_TEXT matches {
code matches {[openehr::524]}
}
}
careflow\_step matches {
CODED\_TEXT matches {
code matches {[local::at0004]} – Requested
}
}
}
could be compressed into this:
ISM\_TRANSITION matches {
current\_state matches {
CODED\_TEXT matches {
code matches {[openehr::524]}
}
}
careflow\_step matches {
CODED\_TEXT matches {
code matches {[local::at0001, – Planned
at0004]} – Requested
}
}
}
The examples have the same semantic meaning. However, at data entry the second example would mean that a choice must be made concerning the careflow\_step, i.e. either at0001 or at0004. Should the archetype editors support both examples? The first example is the only one I’ve seen in archetypes…
Regards,
Mattias
---
### Author:  [@Mattias\_Forss1](https://discourse.openehr.org/u/Mattias_Forss1)
#### Post date: [31 October 2006 15:20 UTC](https://discourse.openehr.org/t/ism-transition/12177/2 "2006-10-31T15:20:04Z")
Hi again,
I should probably also mention that we need some document that provides recommendations about how archetypes should be created when there are more than one way to do it like the example below. Otherwise there is a risk that there are too many archetypes with different representations that essentially mean the same thing.
The rules that Thomas talked about in this thread [http://www.openehr.org/advice/implementers-priv/msg00311.html](http://www.openehr.org/advice/implementers-priv/msg00311.html) , i.e.
```auto
- if there is a plug-in C_DOMAIN_TYPE type available, always use it to
represent constraints for the corresponding RM type
- if there is a syntax equivalent for this type, then use it
- otherwise use generic ADL
```
Should also be documented somewhere.
Regards,
Mattias
2006/10/31, Mattias Forss \<[mattias.forss@gmail.com](mailto:mattias.forss@gmail.com)\>:
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [31 October 2006 21:01 UTC](https://discourse.openehr.org/t/ism-transition/12177/3 "2006-10-31T21:01:24Z")
Mattias Forss wrote:
> Hi again,
>
> I should probably also mention that we need some document that
> provides recommendations about how archetypes should be created when
> there are more than one way to do it like the example below. Otherwise
> there is a risk that there are too many archetypes with different
> representations that essentially mean the same thing.
>
> The rules that Thomas talked about in this thread
> [http://www.openehr.org/advice/implementers-priv/msg00311.html](http://www.openehr.org/advice/implementers-priv/msg00311.html) , i.e.
>
> - if there is a plug-in C\_DOMAIN\_TYPE type available, always use it to
>
> represent constraints for the corresponding RM type
> - if there is a syntax equivalent for this type, then use it
> - otherwise use generic ADL
Yes, such rules would certainly help. They can be even implemented in
the software. For example the editor should be able to recognize
different ways of representing the same archetype and "compress" it with
the best approach.
Cheers,
Rong