Some questions

[Mattias_Forss1 (Mattias Forss)]

Hello again,

I have some questions regarding archetypes.

First, I wonder if I can start implementing support for Demographic archetypes in the Java archetype editor or if I am dependent of some parts that need to be implemented in the Java reference implementation?

Second, I have a tendency to stumble upon new attributes of the different archetypes that are specified in the EHR IM document. There are several attributes there that don’t exist in any archetypes yet and I believe some aren’t even supposed to be “archetyped” attributes but I haven’t found any specification that tells me exactly which attributes should exist in the archetypes. I need to know if all attributes in the EHR IM document can be modeled in archetypes. If not, I think the EHR IM document is more usable to someone implementing a persistence layer than to someone writing the models which are used to create the data to be persisted.

As a concrete example to what i mean, I simply cannot find a class name called RELATED_PARTY for an OBSERVATION. Apparently things have changed a lot from some archetypes and maybe this is just obsolete but there are other things as well, for example the OBJECT_REF class that several attributes in the entry package declare but I don’t see what they and several other attributes (which to me declare completely unfamiliar class names) use are in archetypes.

Please help me understand…

Regards,

Mattias Forss

[thomas.beale]

Mattias Forss wrote:

Hello again,

I have some questions regarding archetypes.

First, I wonder if I can start implementing support for Demographic
archetypes in the Java archetype editor or if I am dependent of some
parts that need to be implemented in the Java reference implementation?

Second, I have a tendency to stumble upon new attributes of the
different archetypes that are specified in the EHR IM document. There
are several attributes there that don't exist in any archetypes yet
and I believe some aren't even supposed to be "archetyped" attributes
but I haven't found any specification that tells me exactly which
attributes should exist in the archetypes. I need to know if _all_
attributes in the EHR IM document can be modeled in archetypes. If
not, I think the EHR IM document is more usable to someone
implementing a persistence layer than to someone writing the models
which are used to create the data to be persisted.

As a concrete example to what i mean, I simply cannot find a class
name called RELATED_PARTY for an OBSERVATION.

this changed in 1.0 (probably earlier from memory) - see
http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html
or the current specs.

Apparently things have changed a lot from some archetypes and maybe
this is just obsolete but there are other things as well, for example
the OBJECT_REF class that several attributes in the entry package
declare but I don't see what they and several other attributes (which
to me declare completely unfamiliar class names) use are in archetypes.

there are quite a lot of attributes (and even some classes) in the RM
that don't make sense to archetype - these are attributes whose values
can only set at runtime, and there are no sensible deign-time
restrictions. E.g. there is usually no sensible constraint on
OBSERVATION.subject, or workflow_id. However, there occasionally is a
constraint on subject, and there might even be a constraint on
workflow_id one day. We used to have an idea of "profiling" the RM to
mark attributes that could possibly be archtyed, but I don't think
thisis a safe thing to do anymore...since there is no guarantee of what
might be controlled and what might not be. Nevertheless, attributes like
LOCATABLE.feeder_audit probably will nevre be archetyped. At the moment,
we take the approach of only allowing constraints on things for which
there have been meaningful examples. I know thisis not particularly
scientific, but I don't think there is a better approach at the moment.
Of course, you can assume at least that only Composition and lower
objects can be archetyped - you can naturally ignore all the
change_control classes, and quite a few others.

We also had a plan to create a subset model of the RM that defines what
can be archetyped - for the purposes of international standardisation.
This could still take place, but getting cooperation from international
standards groups is hard.

You are somewhat right that the RM is designed to help design for
persistence, but I think it is still close enough to work for
archetyping as well. If you think you can prpose objective rules for
profling the RM for archetyping, please let us know.

- thomas

[Mattias_Forss1 (Mattias Forss)]

2006/6/27, Thomas Beale <Thomas.Beale@oceaninformatics.biz>:

Mattias Forss wrote:

Hello again,

I have some questions regarding archetypes.

First, I wonder if I can start implementing support for Demographic
archetypes in the Java archetype editor or if I am dependent of some
parts that need to be implemented in the Java reference implementation?

Second, I have a tendency to stumble upon new attributes of the
different archetypes that are specified in the EHR IM document. There
are several attributes there that don’t exist in any archetypes yet
and I believe some aren’t even supposed to be “archetyped” attributes
but I haven’t found any specification that tells me exactly which
attributes should exist in the archetypes. I need to know if all
attributes in the EHR IM document can be modeled in archetypes. If
not, I think the EHR IM document is more usable to someone
implementing a persistence layer than to someone writing the models
which are used to create the data to be persisted.

As a concrete example to what i mean, I simply cannot find a class
name called RELATED_PARTY for an OBSERVATION.
this changed in 1.0 (probably earlier from memory) - see
http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html
or the current specs.
Apparently things have changed a lot from some archetypes and maybe
this is just obsolete but there are other things as well, for example
the OBJECT_REF class that several attributes in the entry package
declare but I don’t see what they and several other attributes (which
to me declare completely unfamiliar class names) use are in archetypes.
there are quite a lot of attributes (and even some classes) in the RM
that don’t make sense to archetype - these are attributes whose values
can only set at runtime, and there are no sensible deign-time
restrictions. E.g. there is usually no sensible constraint on
OBSERVATION.subject , or workflow_id. However, there occasionally is a
constraint on subject, and there might even be a constraint on
workflow_id one day. We used to have an idea of “profiling” the RM to
mark attributes that could possibly be archtyed, but I don’t think
thisis a safe thing to do anymore…since there is no guarantee of what
might be controlled and what might not be. Nevertheless, attributes like
LOCATABLE.feeder_audit probably will nevre be archetyped. At the moment,
we take the approach of only allowing constraints on things for which
there have been meaningful examples. I know thisis not particularly
scientific, but I don’t think there is a better approach at the moment.
Of course, you can assume at least that only Composition and lower
objects can be archetyped - you can naturally ignore all the
change_control classes, and quite a few others.

We also had a plan to create a subset model of the RM that defines what
can be archetyped - for the purposes of international standardisation.
This could still take place, but getting cooperation from international
standards groups is hard.

You are somewhat right that the RM is designed to help design for
persistence, but I think it is still close enough to work for
archetyping as well. If you think you can prpose objective rules for
profling the RM for archetyping, please let us know.

Hi Thomas,

Our group has just discussed how to profile the RM, and the suggestions we have are simple ones and not too hard to implement.

The first suggestion is to keep track of all the archetyped attributes and classes for each release and mark them in the specifications. It can be as simple as just adding an extra asterisk. The idea of doing this at each release also helps the tool developers to find out what has changed since previous versions.

Another idea is to make a separate document that lists all the archetyped attributes and classes and this document could be versioned each time some new archetypes are out which uses meaningful examples of previously unarchetyped attributes or classes. A document like this means more work than the previous suggestion but it would also help tool developers to quickly see exactly which version of the document that the tool is most in line with.

Hope some of these suggestions appeal to you.

Regards,

Mattias

[thomas.beale]

Mattias Forss wrote:

Hi Thomas,

Our group has just discussed how to profile the RM, and the
suggestions we have are simple ones and not too hard to implement.

The first suggestion is to keep track of all the archetyped attributes
and classes for each release and mark them in the specifications. It
can be as simple as just adding an extra asterisk. The idea of doing
this at each release also helps the tool developers to find out what
has changed since previous versions.

we were going to mark the RM like this a couple of years ago....one of
my concerns was that we would have to change the RM docs if we wanted to
change the profile of "archetypable" attributes....on the other hand, a
separate document as you suggest below is more work, and harder to keep
in sync with the RM.

Another idea is to make a separate document that lists all the
archetyped attributes and classes and this document could be versioned
each time some new archetypes are out which uses meaningful examples
of previously unarchetyped attributes or classes. A document like this
means more work than the previous suggestion but it would also help
tool developers to quickly see exactly which version of the document
that the tool is most in line with.

the main problem remains: what is the definitive list of classes and
attributes? We can easily list the packages to include and exclude, but
classes and attributes are harder...my most recent intention (no tme to
do it yet) was to express a subset of the RM as a schema that could be
read into the ADL tools and used to check anything the user was
archetyping. The problem I guess is that quite a bit of the archetype
editor is hard-wired to the semantics of the model, and this is why you
need a definitive list of what to include and what not to include. I
will talk with Sam about this - he may have some opinions on how we can
develop a dependable profle.

- thomas

[Mattias_Forss1 (Mattias Forss)]

2006/6/27, Thomas Beale <Thomas.Beale@oceaninformatics.biz>:

Mattias Forss wrote:

Hi Thomas,

Our group has just discussed how to profile the RM, and the
suggestions we have are simple ones and not too hard to implement.

The first suggestion is to keep track of all the archetyped attributes
and classes for each release and mark them in the specifications. It
can be as simple as just adding an extra asterisk. The idea of doing
this at each release also helps the tool developers to find out what
has changed since previous versions.
we were going to mark the RM like this a couple of years ago…one of
my concerns was that we would have to change the RM docs if we wanted to
change the profile of “archetypable” attributes…on the other hand, a
separate document as you suggest below is more work, and harder to keep
in sync with the RM.

Another idea is to make a separate document that lists all the
archetyped attributes and classes and this document could be versioned
each time some new archetypes are out which uses meaningful examples
of previously unarchetyped attributes or classes. A document like this
means more work than the previous suggestion but it would also help
tool developers to quickly see exactly which version of the document
that the tool is most in line with.
the main problem remains: what is the definitive list of classes and
attributes? We can easily list the packages to include and exclude, but
classes and attributes are harder…

Do we need the definitive list? I would be content if some tool was developed that ran through validated archetypes and collected class and attribute names and stored them in some hierarchy that then could be generated to documents and/or UML models.

my most recent intention (no tme to
do it yet) was to express a subset of the RM as a schema that could be
read into the ADL tools and used to check anything the user was
archetyping. The problem I guess is that quite a bit of the archetype
editor is hard-wired to the semantics of the model, and this is why you
need a definitive list of what to include and what not to include. I
will talk with Sam about this - he may have some opinions on how we can
develop a dependable profle.

Yes, when developing user-interfaces it is hard to make something so general as the RM but also understandable and usable at the same time. Otherwise we’d just loose the point of an archetype editor if it allowed creating whatever the user wanted, for example add an attribute my_attribute with the class MY_COMPLEX_OBJECT as a child. The purpose of an editor would be to create archetypes that are valid to the fullest extent possible and help the user understand the limitations of what can be modeles and what cannot.

/Mattias

[thomas.beale]

Mattias Forss wrote:

2006/6/27, Thomas Beale <Thomas.Beale@oceaninformatics.biz
<mailto:Thomas.Beale@oceaninformatics.biz>>:

    Mattias Forss wrote:
    >
    >
    > Hi Thomas,
    >
    > Our group has just discussed how to profile the RM, and the
    > suggestions we have are simple ones and not too hard to implement.
    >
    > The first suggestion is to keep track of all the archetyped
    attributes
    > and classes for each release and mark them in the specifications. It
    > can be as simple as just adding an extra asterisk. The idea of doing
    > this at each release also helps the tool developers to find out
    what
    > has changed since previous versions.
    we were going to mark the RM like this a couple of years ago....one of
    my concerns was that we would have to change the RM docs if we
    wanted to
    change the profile of "archetypable" attributes....on the other
    hand, a
    separate document as you suggest below is more work, and harder to
    keep
    in sync with the RM.
    >
    > Another idea is to make a separate document that lists all the
    > archetyped attributes and classes and this document could be
    versioned
    > each time some new archetypes are out which uses meaningful examples
    > of previously unarchetyped attributes or classes. A document
    like this
    > means more work than the previous suggestion but it would also help
    > tool developers to quickly see exactly which version of the document
    > that the tool is most in line with.
    the main problem remains: what is the definitive list of classes and
    attributes? We can easily list the packages to include and
    exclude, but
    classes and attributes are harder...

Do we need _the_ definitive list? I would be content if some tool was
developed that ran through validated archetypes and collected class
and attribute names and stored them in some hierarchy that then could
be generated to documents and/or UML models.

Not a bad idea...one of my tools could probably be extended to do
that.....I'll look into it. Good thought.

- thomas