Maybe this question should be asked on the technical mailing list, since there’s no reaction on the clinical list:-)
Cheers,
Stef
Begin doorgestuurd bericht:
Hi Stef
Great. Does this also mean that this ‘hidden’ reference model stuff will/can be a part of a template? From my point of view I would like to ‘control’ (view and/or enter) thing as date/time of measurement via a template.
This would always be available for data entry. It is not sensible to constrain this in an archetype (fixed for every data instance)
Another question related to that. The way I think to understand it (as a non-technical person:-) ) we can use the XML message’s created by the archetype editor to display and post data to and from a UI/website.
The XML instances that conform to the archetype - we can use the archetype id and paths to describe layout of instances and as a basis for queries - but all data are an instance of the reference model schema (which conform to one or more archetypes).
But here again, this XML message comprises only the classes that are created in the archetype but not the ‘hidden’ stuff.
No - the hidden attributes are in the data (unless they are optional and not populated)
Is there an ‘overhead’ XML message in which the ‘specific’ AT XML message can be embedded/nested so one has access to all available data?
The kernel creates the instance according to the reference model - and conforms to the archetype specification. All reference model attributes are available unless constrained out by an archetype (of which I know of no instance so far - we tend to do that in templates).
Cheers, Sam
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)
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
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: