Hi!
I know that it is technically possible. 
I was trying to ask if it
was clinically possible to identify clusters etc in this specific
case. Sorry for not being specific enough in the question.
After I asked some good suggestions regarding template use have been
posted as a good reminder that there is usually more than one
solution. Thanks!
// Erik
I agree with Heather, this is the way to go if one wants to
accomplish maximal interoperability and queryability. We should as
much as possible try to avoid multiple archetypes for the same
knowledge domain because it will restrict exchangeability of data
Cheers,
Stef
ah - 'data quality' in other words - i.e. markers / meta-data relating
to the data capture from the source, not the integrity of the data as
represented on the openEHR system?
I would like to expand that to data quality assurance. How can one
objectively and according to locally accepted standards establish
that data is of good quality, i.e. (re)usable, or should be rejected/
ignored. IMHO this is one of the crucial points for a functional EHR.
What's the use of a centralized system to store and retrieve
semantically interoperable data if the data is of poor/unknown
quality. It also has a legal aspect. When one uses data provided by a
third party one also takes over/ shares responsibility from/with that
third party if one willingly accept data of poor quality. My guess is
that not many people want to do that.
Cheers,
Stef
Hi Erik,
Yes, clusters used in the way you describe can be queried upon just like any
other class of archetype. It is one way to handle these issues, but still
the 'purer' methodology for a Pap smear report, in this case, would be to
aim for a maximal Pap report archetype and use the template to constrain it
for specific purpose.
Clusters are in use all through the NHS archetypes/templates. I have found
them especially useful in examination-related archetypes for very simple and
universal concepts eg dimension, inspection, etc. These clusters will pop
up amongst a large range of archetypes. So you will be able to query for a
width or length in whatever part of the EHR a dimension cluster is used.
I guess that it could follow that it is possible to consider using the
cluster as the common 'child' archetype within 2 distinct 'parent' entry
archetypes to mimic multiple inheritance. But it is not recommended. The
cluster class has limited functionality compared to entry classes - eg it is
limited without event model etc - a cluster has just data and no state,
events, protocol associated with it. These data elements would be necessary
in a Pap report - I don't think you could get away with these being in each
parent. After all you are already losing some of the commonality - the very
thing that you are trying to use the cluster for - if you have to put the
same event or state data back up into each 'parent' entry archetype.
Hope this helps clarify rather than confuse.
Heather
From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Erik Sundvall
Sent: Thursday, 18 October 2007 1:00 PM
To: For openEHR technical discussions
Subject: Re: Multiple parents and max number of nested specialized
archetypes?
Hi Erik,
Yes, clusters used in the way you describe can be queried upon just like any
other class of archetype. It is one way to handle these issues, but still
the âpurerâ methodology for a Pap smear report, in this case, would be to
aim for a maximal Pap report archetype and use the template to constrain it
for specific purpose.
I agree.
Clusters are in use all through the NHS archetypes/templates. I have found
them especially useful in examination-related archetypes for very simple and
universal concepts eg dimension, inspection, etc. These clusters will pop
up amongst a large range of archetypes. So you will be able to query for a
width or length in whatever part of the EHR a dimension cluster is used.
In other words there are âatomic archetypesâ.
These 'atomic archetypeâs re-appear in normal archetypes to be finally constrained in Templates.
The Template is the profiling tool to make things explicit in a defined healthcare context.
I guess that it could follow that it is possible to consider using the
cluster as the common âchildâ archetype within 2 distinct âparentâ entry
archetypes to mimic multiple inheritance. But it is not recommended. The
cluster class has limited functionality compared to entry classes - eg it is
limited without event model etc - a cluster has just data and no state,
events, protocol associated with it. These data elements would be necessary
in a Pap report - I donât think you could get away with these being in each
parent. After all you are already losing some of the commonality - the very
thing that you are trying to use the cluster for - if you have to put the
same event or state data back up into each âparentâ entry archetype.
Here I need some explanatory elaborations to make things very explicit.
Hi,
I am still working on a concrete use-case but now I understand and agree with Heather's recommendation about having a top level parent encompassing all of items for both PAP archetypes. I just did not know enough about templates to see how it goes. I guess I need to participate to some openEHR events to have hands on experience with them
For the requirements part I will shortly express them for Bethesda report in the clinical list.
Thanks for all your input.
Cheers,
-koray
I have been watching this thread curiously. We need to remember that
Archetype Specialisation is actually a constraining process NOT extension as
in OO inheritance. You can-not add things that didn't exist in the parent,
only provide more specific semantics.
Using laboratory observation archetype as an example, the Any Result element
can be used to record anything of any type, but in the laboratory-lipids
this Any Result has added additional semantics to Any Result to give mean to
data elements such as Total Cholesterol as a quantity type, LDL as a
quantity, HDL as a quantity, etc. These are not new data elements but
constraints on the existing Any Result element.
Therefore, there must be generic concepts in the base archetype that can be
used in specialised archetypes that can be further constrained.
I think this is in-line with what Sebastian and Heather are suggesting.
Heath
From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Heather Leslie
Sent: Thursday, 18 October 2007 6:55 PM
To: 'For openEHR technical discussions'
Subject: RE: Multiple parents and max number of nested specialized
archetypes?
My approach would is in synch with Sebastian - ideally one maximum data
set
of all content for one pap archetype, from any source or standard, then
constrained in a template for Bethesda's purposes, NHS' needs etc. Then
the
data has maximal interoperability and queryability.
In this case you wouldn't need multiple inheritance - I think the key is
in
Heath
Templates are the main means of constraint on archetypes - Specialisations are mainly about adding attributes. Consider the scenario where an organisation requires attributes on an archetype that are not available. They will have two choices - to push for a revision of the source archetype with the addition of their attribute as an optional element OR creating a specialisation of the archetype for local use. Both enable them to proceed, for their data to be queried by all etc.
Hope this is helpful.
Cheers, Sam
Heath Frankel wrote:
Templates are the main means of constraint on archetypes - Specialisations are mainly
about adding attributes.
Sam, surely those attributes are available by virtue of the fact that the parent
archetype says nothing about them. Something in an archetype can never 'add'
an attribute. All archetypes can do is constrain. And the specialised archetype
can never remove a constraint of the parent surely?
For example, an observation archetype that says nothing about the
'State' attribute
imposes no constraints on that attribute. A specialisation of the
archetype could
impose extra constraints on 'State', but can't add the attribute in. I
mean, there is
either a 'state' attribute there in the RM or not - the archetype
can't add attributes.
Of course this all leads to a much more interesting theoretical question - aside
from the immediate syntactic differences, what exactly is the difference between
a template and a specialisation?
Andrew
Templates are the main means of constraint on archetypes - Specialisations are mainly
about adding attributes.Sam, surely those attributes are available by virtue of the fact that the parent
archetype says nothing about them. Something in an archetype can never âaddâ
an attribute. All archetypes can do is constrain. And the specialised archetype
can never remove a constraint of the parent surely?For example, an observation archetype that says nothing about the
âStateâ attribute
imposes no constraints on that attribute. A specialisation of the
archetype could
impose extra constraints on âStateâ, but canât add the attribute in. I
mean, there is
either a âstateâ attribute there in the RM or not - the archetype
canât add attributes.Of course this all leads to a much more interesting theoretical question - aside
from the immediate syntactic differences, what exactly is the difference between
a template and a specialisation?
Andrew, this is indeed a very interesting question. It seems to me that all the constraints done in templates can be done with archetypes. The âartificialâ divide between templates and archetypes are probably to do with their different intended uses. Archetypes are semantically coherent and are supposed to be shared between systems. Templates are, on the other hand, created to meet local specific requirements, therefore not supposed to be shared across sites. But the line of distinct seems to be blurred. How local is a local requirement and thus justify the use of a template? Can one start with a template for local use, and later convert the template into an archetype for shared use?
Also if all constraints can be expressed using the AOM semantics (which is already very generic and powerful), we perhaps could re-use the same object model to represent template constraints, which would facilitate the conversion between archetypes and templates.
Cheers,
Rong
The demarcation between templates and a specialisation are very clear to me â very different entities. Let me start at the beginning, although it may be so obvious to most that you have overlooked it to focus on the constraint issues, but I thought Iâd state it for completeness.
At the simplest and most obvious level, an archetype is a data specification for a single clinical concept. A specialisation is a type of archetype. A template is an aggregation of archetypes, some of which may be specialised, that are combined to carry out a particular clinical purpose eg a discharge summary.
In the following discussion, I will assume that our goal is to design internationally interoperable archetypes, and excludes the specific archetype that is used only for a niche purpose and has no intention of being shared at design timeâŚ
An archetype, whether specialised or not, in the purest methodological sense, is a MAXIMAL data set for that given single clinical concept â something that seems to often get overlooked when trying to model clinical concepts. It is also a data set that should have the MINIMAL constraints on it, in order to MAXIMISE interoperability. Any constraints that are included in an archetype should be only added when it applies UNIVERSALLY. For example the current Blood Pressure archetype contains constraints for both the Systolic and Diastolic readings, but they are obviously not in keeping with accepted clinical practice - in the realm of 0-1000mmHg or so. Why? â to exclude the real extremes that are clearly and absolute errors, but at the same time giving the freedom for later constraint to practical and usable levels in, preferably and most likely, a template, but also possibly in a specialisation. It is universally acceptable that a systolic blood pressure will not exceed 1000mmHg but there is debate at what is the most reasonable figure, so at design we went for a number that was easy and unlikely to be exceeded â 10 too low, 100 too low, 1000 will work! Could have picked 500 â very unlikely to get a BP over 500, but could never say it was impossible to record â this is a grey zone, so to be universally acceptable, and interoperable, we avoided it.
An archetype should be designed for stability and longevity â so it is able to withstand all uses that can be imagined. It will never be possible to imagine all, and so there is the potential to revise archetypes, but it is desirable to keep the revision process to a minimum. Hence the need to consult widely at the time of designing an archetype â across specialties, organisations etc etc to try to gauge all needs. This is a critical component of good archetype design when interoperability is the goal. STABLE archetypes should be the result and that stability is needed to support implementation. Good initial design will minimise impact downstream from having to revise archetypes in systems. The constraints have to be considered as part of this process.
Specialisations are used to resolve issues related to the archetyping of overlapping concepts with slightly different information requirements. The reference model allows for new data points to be added in a specialisation (the most common use), and to a lesser degree, permits further constraint on existing data points and for optional data points to be dropped. An example is inspection cluster, specialised to inspection-skin, and further specialised to inspection-skin-rash or inspection-skin-wound â where additional data points have been added to capture the depth and breadth of the more specific aspects of inspection. Note that all still have the original (most unconstrained and generic) inspection archetype in common â and this is important to facilitate effective archetype-enabled querying. Specialisation of an archetype should still hold true to the rule of keeping the archetype as unconstrained as is possible so as to ensure interoperability.
Templates are use-case, region-, provider- or enterprise-specific. They comprise multiple archetypes. The beauty of templates is that they are FLEXIBLE â it is a key feature. Combine the stable archetypes in ways that achieve various purposes. Constrain the stable archetypes down to make them more practical and useable for the local clinicians, including making optional data points mandatory and binding data points to terminology subsets appropriate for that given clinical setting.
My 20c (more words than a 2c commentJ)
Heather
We are hitting the philosophical - no one is saying anything contradictory - but we have two levels so lets just consider how to get a clear message:
Is this clearer?
Cheers, Sam
Rong Chen wrote:
Great explanation, clear and useful.
Thank you.
Alain Maskens
HEALTH One Global
Sam Heard wrote:
We have specialised archetypes which take all the constraint
statements made by a parent archetype and add more -
importantly they can make further constraint statements
about the reference model - this is what I mean when I say
that a specialised archetype might add an element.
Importantly it will have a larger ontology than the parent -
it may make a statement that is not in the parent.
Yes - these are still constraint statements on the reference
model but they are additional to the parent. They do not
have to be wholely within the parent archetype - only
whole consistent with it but have additional statements
that are unknown to the parent.
That sounds very much the same to me as the âextension-specialization paradoxâ, as described by Meyer, âObject-Oriented Software Constructionâ, 2nd edition, page 499:
Inheritance is sometimes viewed as extension and sometimes as specialization. Although these two interpretations appear contradictory, there is truth in both  but not from the same perspective.
It all depends, again, on whether you look at a class as a type or a module. In the first case, inheritance, or is, is clearly specialization; Âdog is a more specialized notion than ÂanimalÂ, and Ârectangle than ÂpolygonÂ. This corresponds, as noted, to subset inclusion: if B is heir to A, the set of run-time objects represented by B is a subset of the corresponding set for A.
But from the module perspective, where a class is viewed as a provider of services, B implements the services (features) of A plus its own. Fewer objects often allows more features, since it implies a higher information value; going from arbitrary animals to dogs we can add the specific property of barking, and from arbitrary polygons to rectangles we can add the feature diagonal. So with respect to features implemented the subsetting goes the other way: the features applicable to instances of A are a subset of those for instances of B. âŚ
Inheritance, then, is specialization from the type viewpoint and extension from the module viewpoint. This is the extension-specialization paradox: more features to apply, hence fewer objects to apply them to.
Dear Heather,
Your 50c worth is really an excellent explanation. Well done, and I hope many readers on the list will find it helpful.
With best wishes,
Dipak
A couple more questions (by the way Leslies description was awesome
and makes total sense).
Interfaces
a) When creating a generic outbound or inbound interface with an
extrernal system - do you build based upon the archetypes only - i.e.
provide as many values possible? or your specializations? or is this
all mute and we stick with HL7?
Templates, as a collection for a use case. I looked out in Subversion
but only see one out there:
http://svn.openehr.org/knowledge/templates/dev/html/
b) Do templates or specializations or archetypes define workflow
e.g.
record results, based upon results collect additional information or not?'
In the case were a doc just wants to replicate a paper form but not
improve it would I build a template or stick with Archetypes? So
implementing a form like this:
http://home.cogeco.ca/~epiphany/FPDoctor-Perfect-Progress-Note-2.0.pdf
thanks!
Greg Caulton
Boston, MA
http://www.patientos.org
Hi All
I think that there is a clear need for a distinction between archetypes (specialized or not) and templates and this relates mainly as Rong has said as to their intended use. Archetypes are for interoperability and so they need to be designed to be able to handle any usage of the particular concept that they are modelling. This means that valid ranges in archetypes should be set so that valid values will never fall outside the range. ie the bp archetype sets the max systolic value to 1000. Archetypes should be kept as generic as possible for the particular concept and are maximal data sets and so should contain every concept that is required for any use of that concept.
Templates are specific use cases of a particular archetype or groups of archetypes and can be constrained down for a particular usage ie for the bp archetype, you may constrain it to just contain the systolic and diastolic in an âany eventâ and remove any other non mandatory elements. Templates are useful for turning a generic archetype into something more specific i.e. the laboratory archetype can be constrained in a template (or at runtime) to be a specific type of laboratory result. This means that instead of 5000 specific laboratory archetypes, we only need one generic and probably 20 or 30 agreed specializations. Templates can also be used for creating very complex documents such as an antenatal visit which is made up of many different archetypes. Templates can be made up of nested archetypes as well as nested templates all of which can be further constrained within the limits of the archetypes used - this allows for the development of concepts and documents with any arbitrary level of complexity that still conform to archetypes.
The question has been raised as to the difference between a specialization of an archetype and a template and when to use each. There is no absolute answer to this, but there is a need to examine the need for specializations of archetypes to see whether the archetype is general enough to be used everywhere. If it meets this test, then it is reasonable to create it and submit it as an archetype, otherwise a template should be used constraining some more general archetype. I think that over time it will become clear that there are some templates that should become archetypes.
regards Hugh
Rong Chen wrote:
Hi
Could we put the comments of the two H. Leslies on the openEHR.org FAQs somewhere?
I think together they are the best explanation of archetypes, templates, and their distinction that I have read so far.
Sebastian
Hi all
I think that in the absence of a template specification it is indeed difficult to see, from a technical viewpoint, the difference between templates and âaggregation archetypesâ (which is what I think Rong means by âall the constraints done in templates can be done with archetypesâ). Heather and Hugh point out that such archetypes would not be universal in their applicability and therefore less shareable. This still leaves a blurry line between where the archetype ends and the template begins. There are some features of templates that do make this line clear, however.
The best example I can think of is default values (not to be confused with assumed values). At some point youâll want to be able to say things like âthe default temperature scale is Centigradeâ or âthe default number of foeti is 1â. If the default value is free text or even a coded term, this implies that the template is targeted to a specific language/culture, thus NOT universal. Therefore the template specification, when it arrives, is likely to include ways to define default values and the target language/culture of the template. A template is language/culture-specific. There is provision made for default values in the AOMâs archetype constraint model but the TYPE of a default is left open. Since the TYPE of these values cannot be constrained by the AOM, default values can never be meaningfully applied in ADL. Rather they can only be applied in the template (which knows about the reference model and target language/culture of the data). This connects to Rongâs point about expressing template constraints in AOM semantics. I fully agree the template specification should make use all useful parts of the archetype constraint model or âbuild on top ofâ the AOM.
If a template was ever suddenly considered to encapsulate a structure which was universally (or near-universally) applicable, as Hugh suggests, the default values would have to be discarded (as well as other culture-specific structures or assumptions). And for the archetype to be practical in a more universal sense, any items added to the ontology in the template (in the templateâs target language) would probably need to be translated into the other languages. Therein lies the distinction.
Regards
Lisa
Hugh Leslie wrote:
I havenât followed this whole thread, in particular I havenât seen Rongâs emails about templates and aggregation archetypes but I thought I would provide a little input about the future of the template specifications.
If you have a look at the Template Object Model as published as a draft in R1.0.1 you will find two packages. The first is the TEMPLATE_SPEC package. This provides a mechanism to specify a template using references to archetypes and aggregating them together. In addition it provides a series of constraint rules of various kinds to do things like constrain cardinalities or specify default values. We have been recently comparing this with the current proprietary template definition used within the Ocean Template Designer and have found that there are very few required template semantics that cannot be expressed using the R1.0.1 TEMPLATE_SPEC draft.
The second model is the operational template model. We have actually implemented this and have needed to augment and change this model slightly, but the principles expressed in the R1.0.1 draft (a Template object with definition specified by a C_COMPLEX_OBJECT and list of path and default value pairs) has work fine. This implementation experience will be feed back into the openEHR community for the next release.
So in summary, Rongâs premise that we can express templates using the AOM is true, but what he calls an âaggregation archetypeâ is an operational template. The TEMPLATE_SPEC is just another representation of the same template where it references the existing archetype artefacts and constrains them using rules. The TEMPLATE_SPEC is used to store and maintain the template definition within an authoring environment while the operational template is derived from the TEMPLATE_SPEC and is used within software at run-time.
We are just completing the testing of a new export function in the Ocean Template Designer that generates an operational template from its proprietary template definition. This operational template will be used for all sort of purposes including the generation and validation of RM objects that conform to the template.
Hope this helps keep you up to date with progress in this area. If you have interest in this area from the technical perspective I suggest that we progress this further in a collaborative manner.
Regards
Heath
Heath Frankel
Product Development Manager
Ocean Informatics
Ground Floor, 64 Hindmarsh Square
Adelaide, SA, 5000
Australia
ph: +61 (0)8 8223 3075
mb: +61 (0)412 030 741
email: heath.frankel@oceaninformatics.com