# Concept Overload Caution

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2009-06-03 00:28 UTC
**Views:** 1
**Replies:** 7
**URL:** https://discourse.openehr.org/t/concept-overload-caution/14909

---

## Post #1 by @Tim_Cook2

Hi All,

The past 3 or 4 subjects on this list takes me back to conversations
that we had before \(maybe several years ago?\) when we were discussing
slots and links\.  Maybe they were here maybe they were on the ARB list\.
I do not recall now\.

But my feeling in both of these areas are that there is a tendency for
archetype developers to create archetypes that are more than one
clinical concept\.  IIRC, that is about the time that templates were
being thought of/designed to alleviate the pressure on archetypes to
serve everyone, everywhere\.

As Heath has just mentioned, templates are the better place for this
type of grouping\.  They tend to provide that ability to be more
localized\.  Remember that when you are creating or reusing archetypes
that they should be universally reusable\.  If they are not, then they do
not meet the basic requirement of being a single clinical concept\.  This
is fundamental to openEHR being future proof\.

The misuse of slots and probably any use of links in a particular
archetype; IMHO is a very bad thing and will lead us down the road that
we see with data model centric systems as opposed to our information
model\.

While I am not a clinician nor a lab tech I do ask those of you creating
archetypes to review the fundamental principles of archetypes and
templates\.  Then think twice before publishing an artifact\.

From what I am reading I think that there is becoming a tendency to put
too much runtime functionality into what is supposed to be singular data
items\.

My 2 cents/pence/centavos

\-\-Tim

---

## Post #2 by @Heath_Frankel3

Hi Tim,
Thank you for your post, I complete agree\.  Like you I am not a clinician
and feel that I am rocking the establishment of openEHR and the principles
of Archetypes by saying this, but I strongly believe that we need to have a
technical review process of archetypes before they are published\.  What I am
looking to review is not related to the clinical content, but the patterns
used to represent that clinical content\.  In particular, I would looking to
ensure that we have single concept representation, loose coupling,
reusability, appropriate use of specialisation, and most importantly I
believe, appropriate structures to support querying\.  These are all good
object\-oriented \(or general software\) design principles that technicians are
trained to be better at then clinicians\.

As part of the archetype governance and publishing process, I would like to
see a technical review process\.

I realise I am writing to a group of technicians on this list and this is
probably a topic for the clinical list, but I think there probably are
enough clinicians on this technical list to knock me around if they feel
that I am rocking it too hard\.

Please understand that I not trying to re\-empower the technician, I am
simply looking for good quality knowledge artefacts and believe this a
process that is missing in the current archetype development process\.

Regards

Heath

---

## Post #3 by @Peter_Gummer1

Heath Frankel wrote:
> Hi Tim,
> Thank you for your post, I complete agree\.  Like you I am not a clinician
> and feel that I am rocking the establishment of openEHR and the principles
> of Archetypes by saying this, but I strongly believe that we need to have a
> technical review process of archetypes before they are published\.  \.\.\.
>
> Please understand that I not trying to re\-empower the technician, I am
> simply looking for good quality knowledge artefacts and believe this a
> process that is missing in the current archetype development process\.
>  
I think it behoves us tech\-heads to get involved\. I \(and others\) have
been invited six months ago to help the CKM publishing process by
"adopting an archetype"\. I'm guilty of not having found the time to do so\.

\- Peter

---

## Post #4 by @Stef_Verlinden1

Hi Heath,

I complety agree with you\. Let's all do what we're best at\. What I
would like to add to your proposal is some feedback \(both ways\) so
doctors and technicians can learn from eachother\. Rather than de\-
empowering the one or the other I think we should team up to create a
properly working system that really adds value for the citizens/
patient who are the subject of this all\.

Also as I clinician I really would like an understandable \(at
technical lay\-mans level\) manual with clear examples who things can
work and why some solutions shoudl be avoided\. Maybe some best\-
practices of whatever you like to call that

Cheers,

Stef

---

## Post #5 by @system

Hi Heath and Peter

Peter Gummer wrote:
> Heath Frankel wrote:
>  
>> I strongly believe that we need to have a
>> technical review process of archetypes before they are published\.  \.\.\.
>>
>> Please understand that I not trying to re\-empower the technician, I am
>> simply looking for good quality knowledge artefacts and believe this a
>> process that is missing in the current archetype development process\.
>>    

I agree\. Technical input is essential\. We have the validation report in
CKM and this captures some errors, but many of the issues Heath
mentioned require a manual review of the archetype\.
> I think it behoves us tech\-heads to get involved\. I \(and others\) have
> been invited six months ago to help the CKM publishing process by
> "adopting an archetype"\.
>  

It would be very good to have a couple of technicians on there\.
Adopting is a good means for individual archetypes and as a rule
everybody who adopts an archetype in CKM will always be invited to
review the archetype\.
For consistency etc, I believe it would be even more benefitial if we
have more or less the same couple of technical reviewers for each archetype\.

I am not sure if this should be a totally separate process from the
clinical review process or part of it\.
If it is one process, it makes the handling of it a lot easier and more
streamlined, but on the other hand you wouldn't want too many technical
comments as part of the clinical review process and technicians may not
be satisfied with the more clinically oriented view of the archetype
presented during the review\.
I think we should test drive adding some volunteer technicians to the
review round of an archetype that is currently under review and see how
we go with this\.

Cheers
Sebastian

---

## Post #6 by @heather.leslie

Hi everyone,

I will point out that, ironically, Sebastian is actually fulfilling the role of 'token' technician in all archetype reviews at present and is contributing in exactly this way described. However we would welcome more, and it would make it much easier to involve others if they can nominate the archetypes they are interested in by adopting archetypes.

If others think it valuable we could organise editors to post a proposed review to the email lists, so that anyone interested can immediately adopt and be included in the review round.

By the way, if review rounds are already in progress, you can still adopt an archetype and the editor can add additional reviewers to subsequent review rounds.

I do think that the technical comments cannot take place in isolation and at this point would recommend that technicians and clinicians should agree content together. If this becomes unwieldy then we can review the situation later.

Cheers

Heather

---

## Post #7 by @ian.mcnicoll

Hi Tim et al,

Interesting comments. Certainly it is very common for newcomers to openEHR to model end-point datasets e.g. 'Diabetes consultation' as a single archetype, rather than as a set of archetypes , aggregated into a template. Sometimes this is due to a misunderstanding of the openEHR principles, in other cases, it arises from a pragmatic decision to generate a 'quick and dirty' data model to satisfy a local requirement. There is a particular difficulty with questionnaire type constructs where this kind of single-archetype per dataset construct is sometimes the best approach.

I'd be interested to know if you feel that any of the current CKM archetypes break the 'single-concept' per archetype rule as I could see that you might feel that some of the recent histopathology clusters for e.g melanoma, might fall into this category. These are 'my babies' to feel free to let fly!!

I was not sure what you meant by 'misuse of slots' - can you give some examples? At present , I see using slots for 2 distinct purposes:

1) To allow us to reuse structured content e.g. 'Lymph node metastases' that appears at different points within parent structures or in different archetypes
2) To provide an open-ended means of expansion of a clinical concept where it is simply not possible to fully define the concept e.g some aspects of physical examination which are horribly fractal, or where below a certain level, there is no clinical consensus e.g. wide variation in the microscopic reporting of breast cancer.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
[ian@mcmi.co.uk](mailto:ian@mcmi.co.uk)

Clinical Analyst Ocean Informatics [ian.mcnicoll@oceaninformatics.com](mailto:ian.mcnicoll@oceaninformatics.com)
BCS Primary Health Care Specialist Group [www.phcsg.org](http://www.phcsg.org)

2009/6/3 Tim Cook <[timothywayne.cook@gmail.com](mailto:timothywayne.cook@gmail.com)>

---

## Post #8 by @system

Hi everyone

There are a lot of technical people who have volunteered as reviewers on CKM
and we have had major input from a number of them\. There will be more issues
that arise when we have the first set of archetypes for publication to
ensure consistency\.

There is no doubt that we all benefit from people speaking up about what
their systems do and why\. This helps ensure archetypes are suitable to
support existing systems\.

Cheers, Sam

---


**Canonical:** https://discourse.openehr.org/t/concept-overload-caution/14909
**Original content:** https://discourse.openehr.org/t/concept-overload-caution/14909