Bert Verhees bert.verhees at
Tue Apr 18 04:49:18 EDT 2017

Op 17-4-2017 om 23:57 schreef Pablo Pazos:
> Currently the use of specific SNOMED CT codes in archetypes is for 
> further definition / specification of the clinical concepts.
> To use SNOMED CT at runtime, external constraints are used in the form 
> of URIs, that might point to a SNOMED domain or specific subset. If 
> the subset is local, the archetype might not be the place of setting 
> the constraints since archetypes should be general purpose & globally 
> valid.

Pablo, I have a slightly different opinion on your statement. But first 
I want to emphasize that it is generally a good guide line what you 
express. But I disagree with your way of expressing strongly.

In the case of local subset you are right. But in cases of non-local 
subsets, all SNOMED information can be used globally, depending on 
But even in case of local subsets, ADL offers the freedom the create 
archetypes for a very special small local domain.
There is nothing wrong with that, if you need it, then you need it. 
Although, it is better to look for a wider usability or of there is 
already something similar.

People can have good reasons to add SNOMED in archetypes, in 
term-bindings, or, for example, in restricting hierarchies in SNOMED.
But AOM is not that far right now that it can fully extensively use 
SNOMED. And ADL does not yet allow expressions in termbinding

So there is some way to go, but denying the need by stating that it is 
not right to do so does not seem right to me.
It is on people to decide what is right. OpenEHR should facilitate, not 
dictate. That has always been a part of base thinking.

I think the next generation  HealthICT will use the full extend of 
SNOMED, including post-coordinated expressions, hierarchies, subsets, 
etc. I hope OpenEHR will step on board of that train very soon.
This will surely change thinking about archetypes, CKM, and so on.

But good scotch needs time to grow up. ;-)
But be careful not to throw away scotch which will be very good in a few 

> A template might be the right place of setting those constraints 
> (specific, locally valid).
I disagree with this one also. There can be disadvantages against using 
specific constraints in templates instead of archetypes.
It must be reconsidered from case to case.

It has to do with code-reuse and code-maintenance, so called: the 
DRY-rule (Don't Repeat Yourself).
If a specific extra constraint on an archetype reoccurs inside a 
organization in more templates, then it is in my opinion better to 
specialize that archetype, because then there is one single point of 
The alternative to do it in a template every time, gives you more points 
of maintenance on the same specific part.

The DRY rule is very well-known and for good reason:

An important part of the power of OpenEHR is in the flexibility which 
offers solutions for exceptional situations.

Best regards
Bert Verhees

> Regards,
> Pablo.
> On Wed, Apr 12, 2017 at 5:56 AM, Bert Verhees <bert.verhees at 
> <mailto:bert.verhees at>> wrote:
>     Hi,
>     I needed to clean up archetypes from SNOMED bindings because of
>     license-reasons, I "grepped" the local directory from CKM.
>     To my surprise I found there SNOMED bindings in over 50 archetypes.
>     This can, I think, be a problem for countries which have no SNOMED
>     license.
>     Or is the opinion that SNOMED is allowed in archetypes even in
>     non-member-countries.
>     Bert
>     _______________________________________________
>     openEHR-clinical mailing list
>     openEHR-clinical at
>     <mailto:openEHR-clinical at>
>     <>
> -- 
> Ing. Pablo Pazos Gutiérrez
> Cel:(00598) 99 043 145
> Skype: cabolabs
> 	<>
> <>
> pablo.pazos at <mailto:pablo.pazos at>
> Subscribe to our newsletter <>
> <> 
> 	Virusvrij. 
> <> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list