I have been looking at the OpenEHR Information Model ( ehr_im.pdf ) to get a better understanding of the underlying classes used within the OpenEHR.
Whilst I am beginning to understand the main classes used within the archetypes, I am still confused as how they make it to the XML version of the archetypes.
For example if you consider the “Composition” class, it has a number of attributes ‘language’, ‘territory’ and ‘category’ all of which are looking to be mandatory.
Now if I look at one composition archetype , ie. openEHR-EHR-COMPOSITION.prescription.v1.xml
These attributes are not all present in the XML, why is this?. How can I know what will be present in the XML form of the archetype?
It's good that you are studying the EHR IM, many common confusions can
arise from starting with the AM or an archetype editor only.
Your current problem might be caused by one of the most common
counfusions regarding openEHR that we meet when introducing students
and others to the two level model of openEHR, tell me if this helps:
When an archetype is "silent" about something (e.g. an attribute) then
the RM (e.g. the attributes of the Composition class) are
unrestricted/untouched by the archetype and can be populated by
anything that the RM itself allows (in this case e.g. any language or
territory).
The fact that the archetype tools of today don't show what is
unrestricted/untouched in the RM probably make things more confusing
than neccesary, most tool developers are aware of this so changes
might come about sooner or later.
Another soundbite: An archetype not based on a reference model is
impossible (or at least pointless).
If I am understand you correctly, then :
- No attributes within an OpenEHR class can be assumed to be mandatory
within the XML representations, as in all cases the RM can be defaulted to.
I guess you mean attributes of an OpenEHR _RM_ class within XML
representations of _archetypes_. (Some things in the AM are mandatory
in archetypes.)
In the XML representations of _archetypes_ I don't think any RM
attributes are _mandatory_ but an "empty" archetype would be of
limited value... (I hope others correct me if I've overlooked
something.)
In the XML representations of (possibly archetyped) _patient data_ all
mandatory RM attributes will of course be mandatory and present in the
XML. If archetypes add even more mandatory attributes then those will
of course be mandatory and present in addition to the default
mandatory RM attributes.
- The fact that the current tools do not expose or use these attributes,
is a design decision made by the people writing the tools.
Well probably often a "decision" in lack of time/resources or (less
likely) lacking ideas of good/useful ways to present them. A tool
exposing the RM has to deal with both RM and AM in detail and thus
takes more time building than dealing with AM only.
Sorry if I'm repeating things you consider obvious.
I have no issues with the two level models used in OpenEHR, it makes
perfect sense to me to have an underlying RM for all archetypes to be
based on.
If I am understand you correctly, then :
- No attributes within an OpenEHR class can be assumed to be
mandatory within the XML representations, as in all cases the RM can
be defaulted to.
as Erik says, if the archetype says nothing, then whatever the RM model
(i.e. the particular classes in question) says goes.
- The fact that the current tools do not expose or use these
attributes, is a design decision made by the people writing the tools.
well, in hindsight, it was a bad idea - just that the initial builders
knew the models very well but underestimated the importance of making
the RM visible in these tools. Now we know better, but effort is needed
to add this facility to the tools. There is a tool made by the group at
Valencia Polytech in Spain that does this aspect quite well actually,
but doesn't do many of teh editing tasks yet. So - no tool available
today does all that is needed.
"An archetype not based on a reference model is impossible (or at least
pointless)."
Erik Sundvall
Erik,
I love this comment, it should be put up on the openEHR Web Site as the
"Play of the Day".
So many times I see people trying to use Archetypes without a RM, or even
worse using openEHR Archetypes without using the specified underlying
openEHR RM. Although the later is better than the former, it still causes
major confusion and badly designed Archetypes that cannot be used for
implementation.
> - The fact that the current tools do not expose or use these
attributes,
> is a design decision made by the people writing the tools.
Well probably often a "decision" in lack of time/resources or (less
likely) lacking ideas of good/useful ways to present them. A tool
exposing the RM has to deal with both RM and AM in detail and thus
takes more time building than dealing with AM only.
Actually I think it was more to try to keep the task of archetyping simple
as it is a task targeted at Domain Experts (Clinicians) without them
requiring to know about the RM (well so we thought). Unfortantly, hiding
some attributes that are commonly required by the clinician forces them to
put it in the archetype so they can see it. We are also finding more and
more RM attributes that we want to archetype other than just data structures
such as participations.
The challange is to find a visualisation of the archetype that is still
simple but can also expand out to include relevant RM attributes.
In Ocean's next generation of tools, mainly inspired by the requirements of
the Archetype Query Builder where criteria on RM attributes is common, we
will have a configurable tree view of templates where individual RM
attributes can be turned on or off, right down to the data type attributes
if needed. We are also looking at alternate visualisation of archetypes for
the next iteration of the Ocean Archetype Editor.
Regards
Heath
Heath Frankel
Product Development Manager
Ocean Informatics
Ground Floor, 64 Hindmarsh Square
Adelaide, SA, 5000
Australia
"An archetype not based on a reference model is impossible (or at least
pointless)."
Erik Sundvall
Erik,
I love this comment, it should be put up on the openEHR Web Site as the
"Play of the Day".
So many times I see people trying to use Archetypes without a RM, or even
worse using openEHR Archetypes without using the specified underlying
openEHR RM. Although the later is better than the former, it still causes
major confusion and badly designed Archetypes that cannot be used for
implementation.
or another permutation... since all archetypes are using some RM or
other - this is mathematically unavoidable - then we should say:
creating archetypes without knowing what reference model you are using
is pointless.