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 it, any valid date could go in there. In the
archetype you could further constrain that only dates from e.g.
9.9.1999 onwards are valid for that attribute in this context.
- The template specification is not released yet, so I could be wrong.
But from what I understand templates further constrain and bundle
several archetypes to fit a certain organisations data entry needs. In
contrast archetypes are mainly designed for interoperability reasons
i.e. share common meaning (So archetypes are purposely designed on a
higher level to reflect a sensible "common denominator" of a concept.
A common misunderstanding is that archetypes do what templates are
thought for.
E.g. if a coded term in an archetype has to interchangeable codes
associated with it - like one SNOMED and one LOINC - the template
could preselect always the LOINC one because organisation has no
SNOMED license.
- Still, if all dates are allowed a template wouldn't constrain (and
therefore wouldn't mention) a reference model date attribute either.
So a GUI designer would have to know the used archetypes and the
referenced reference model classes including attributes to sensibly
create the GUI.
Hope this was of any help,
Thilo (openEHR informed medical student)
