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
licensing.
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
years.
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
maintenance.
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:
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
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.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> 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@lists.openehr.org
<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com <http://www.cabolabs.com/>
pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virusvrij. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
