Hello all,
I don't know the OI template editor yet, so I can't make any statement
about its capabilities.
I just had a look at the template section in the dev-uk-nhs part of the
archetype repository. It shows form-like html views of templates. I
assume that they have been created to make it easier for clinicians as
us to picture the end result of such a template in use. But as you
mentioned, and as acknowledged by Heather, Erik and Thomas, it would be
better to display the hidden fields as well in some way. I am in
favorite of Erik's idea of a lean ehr test system. most conveniently
already included in the archetype/template editor. That would make such
issues more clear and would also be advertisement for the IMO brilliant
openEHR concept.
Interested (clinical) people could fairly easily experience the power of
openEHR without having to get into technical details. Developers could
look at the code and would probably quickly get what components are
necessary to build an openEHR based system (the often mentioned "kernel"
plays - as the name suggests - in central role by implementing both the
reference model and the archetype object model and thus allowing things
like archetype based object creation).
For both the clinicians and the developers this lean but functional ehr
system would big a great incentive to use openEHR despite the sometimes
admittedly steep learning curve.
Stef, looking at the NHS stuff especially the tabular version provides
many examples of what I have written in my last post. You see that a
e.g. a composition template contains many archetypes in a nested fashion
that can be further constraint if needed. It also shows what you have
been saying: It starts with an element called "other_context". The
composition class from the reference model adds context attributes that
are fixed (can't be archetyped) to fulfill e.g. legal requirements. The
"tdl" directory in the NHS part of the archetype directory is empty as
there hasn't been a formal specification for templates released yet.
Regarding GUIs templates are not enough to specify the form fields of a
GUI but it could be the input into a GUI generator component. The
generator would probably interact with the "kernel" to build an in
memory tree reference model object tree by traversing the template and
its nested archetypes recursively. This tree would include all the
rules/constraints from the nested archetypes (sometimes replaced by
"stricter" ones from the template). During traversal every time an
archetype reference is encountered it has to be retrieved from an
archetype server. Every time an reference model node is encountered this
class will be instantiated (archetype based object creation).
If the form(s) stay(s) always the same the number of
templates/archetypes is limited. In such a case a GUI can also be
hardcoded by linking the fields to the leaf nodes in the object tree
within the kernel. The kernel would then validate the input data
according to the underlying archetypes. Obviously the developer of the
GUI needs knowledge about the archetype(s) and the used reference model
classes in order to know what fields to include in the GUI. Some leaf
nodes could also by populated invisibly by the system without any input
fields filled in by the user e.g. when hitting the send button the
committal time stamp would be created automatically by the system and
stored in the appropriate context attribute of the composition reference
model class. Still the developer would have to be aware of and implement
such things in the code.
At the end of this post I would like to re-stress the importance of a
lean EHR system proposed by Erik. For the reasons mentioned above, we -
the openEHR community - should give this goal a high priority. Through
the great and ongoing work by Rong et al (Java implementation project)
the essential kernel component already exists. Let's use it to get a
simple but functional openEHR system up and running soon.
Cheers, Thilo
Stef Verlinden schrieb:
> 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
>>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
