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
