Hi Bert,
The official name that SNOMED/IHTSDO use is 'SNOMED CT'.
The technical terminology descriptor that we use inside
terminology_id is 'SNOMED-CT'
Ian
On Tue, 25 Apr 2017 at 08:03, Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> wrote:
I thought so too, I even asked someone at ihtsdo but when you
read the license coming with the SNOMED-CT browser, it made
me doubt. Take a look at it yourself, I believe it is point 4
( I am on my mobile right now and it is inconvenient to look
now)
Bert
Op di 25 apr. 2017 06:59 schreef Pablo Pazos
<pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>>:
In terms of license, I don't think using archetypes that
reference snomed is a problem. The thing is when you want
to support snomed in your system, having or not
archetypes doesn't makes the difference IMO.
On Tue, Apr 25, 2017 at 1:39 AM, Bert Verhees
<bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote:
But I think that it is not allowed to use SNOMED-CT
in bindings when you're not explicitly permitted to
do so.
Bert
Op di 25 apr. 2017 06:34 schreef Bert Verhees
<bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>>:
I agree completely with you, Pablo
Best regards
Bert
Op di 25 apr. 2017 06:24 schreef Pablo Pazos
<pablo.pa...@cabolabs.com
<mailto:pablo.pa...@cabolabs.com>>:
Hi Bert,
Maybe my wording is the issue here since I
don't disagree with what you said.
Take into account that I use the word "might"
on every sentence, as the indication of an
ability. Never said that 1. applies to all
contexts, or 2. that those are hard rules. In
those cases I would use "must" instead of
"might".
With that being said, when a SNOMED CT code
is referenced directly as a bind to an
archetype node, the purpose is to add
definition to the archetype, not to use the
code as part of the record. That can be done,
but is not the purpose of having term
bindings on the archetype. That is explained
on the specs somewhere, is not my idea :)
Cheers,
Pablo.
On Tue, Apr 18, 2017 at 5:49 AM, Bert Verhees
<bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> wrote:
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
<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 <tel:099%20043%20145>
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>
<#m_-5175177527451187662_m_4958234606457841392_m_8135393484437096515_m_-4558998169760756438_m_725265850614292706_m_7413263216575621585_m_9164379359524070019_m_61185112423032015_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
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>
_______________________________________________
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 <tel:099%20043%20145> 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>
_______________________________________________
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>
_______________________________________________
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>
_______________________________________________
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>
_______________________________________________
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>
--
Ian McNicoll
_______________________________________________
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>
