Hi Thio,
Thanks for this excellent explanation. Although it remains a steep
learning curve for a 'non-technical' person, it certainly provides a
better insight in this 'tough' material.
One last remark to explain my question. I while ago Thomas Beale
demonstrated the OI template builder, which is a really great tool.
From what I understood this template builder also can be used as a
GUI designer and that's where my interest lies. Thing is that
templates, as you stated, further constrain and bundle several
archetypes to fit a certain organisations data entry needs.
My point is that since the 'hidden classes' aren't present in the
originating archetype(s), there also aren't present in a GUI
constructed with this template builder. Therefore such a GUI lacks
certain 'essential' data entry classes/fields (for instance 'date and
time of measurement).
You can also see this in the 'example templates' made for/by the NHS-
UK and which can be found in the dev-uk-nhs part of the archetype
database.
So if you look for instance at the 'bloodpressure template (Archetype
Id openEHR-EHR-OBSERVATION.blood_pressure.v1 Template ID945c2617-
dc89-4c28-94cf-43ee46c1ecb0), you'll only see the data classes/fields
which where archetyped but none of the 'hidden' data classes/field
(such date/time of measurement but also performer of committer).
These are typical examples of data I would like to present in and/or
enter via a GUI. So I guess a template builder isn't suitable for
creating GUI's after all (or I've misunderstood this in the first
place).
Thanks again,
Stef
Op 31-mei-2007, om 1:50 heeft Thilo Schuler het volgende geschreven:
Hi Stef,
I have followed the thread and I will try to provide some hopefully
useful hints. I will start with the central idea, the
two-model-approach, and will try to cover your questions after that:
- Archetypes are a way of constraining and plug-and-playing (LEGO
principle) a relatively limited number of generic reference model
classes of the reference model, that are expected to stay stable over
a long period of time.
In that way the multitude of quickly changing medical concepts (the
medical knowledge) can be expressed and adapted to the current needs,
while the building blocks (the reference model classes) stay the same.
One big advantage of this approach is that software can be developed
based on the reference model without knowing the archetypes in advance
(future proof systems).
- Analogy: Reference model classes are the LEGO bricks, Archetypes are
the LEGO construction plans
- The constraining rules (grammar) of *all* archetypes (or more
precisely archetype instances) are defined in the archetype model.
That is where the name two-model-approach came from: firstly the
reference model and secondly the archetype model.
- Every archetype (e.g. for blood pressure) is an instance of the
archetype model.
There could be many notations invented to express this archetype
model. They only have to support the full semantics of the archetype
model. Of all the theoretically possible notations the archetype
editor currently supports ADL and can also transform the archetype
into an XML version.
- Every piece of medical information (the blood pressure values of
person X in simple case) is a bundle of several reference class
instances with the attributes set to certain values (to reflect the
state of the patient X). The archetype or a combination of archetypes
define(s) which classes, how many of them and what combination are in
the bundle. Further more it can define things like value ranges for
reference class attributes. Like archetyeps hese bundles could also be
expressed in several formats, but today mostly XML is used (this is
meant when Sam talks about data).
- So don't confuse an XML data bundle (validated by the reference
model schema) with an archetype expressed in XML.
- In a message etc you would send the XML data NOT (!) the XML
archetype that the archetype editor can output. Although there are
references to the archetypes (that where used during creating) in the
data. So the receiving system of the message can also retrieve the
archetypes from an archetype server to add meaning to the data.
- An archetype can validate (during creation or after reception) that
a data bundle conforms to the concept that the archetype describes. So
an archetype is a schema of a particular medical concept. Actually
the XML schema language was evaluated as a means of expressing
archetypes but was found to be not expressive enough. Therefore ADL
has been invented.
- As it was mentioned before (and as you correctly named hidden
reference model stuff) archetypes only contain the constraints on the
reference model which FURTHER constrain what is automatically by the
reference modle. So if the a reference model
class has an attribute of a date type and the archetype doesn't have a
further constraint on
