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 , 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
>
> Should also be documented somewhere.
>
> Regards,
>
> Mattias
>
> 2006/10/31, Mattias Forss <mattias.forss at gmail.com 
> <mailto:mattias.forss at gmail.com>>:
>
>     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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>   

_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



Reply via email to