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 ID 945c2617-
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 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)
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
