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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>:
I agree completely with you, Pablo
Best regards
Bert
Op di 25 apr. 2017 06:24 schreef Pablo Pazos
<[email protected]
<mailto:[email protected]>>:
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
<[email protected]
<mailto:[email protected]>> 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
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
<[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
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/>
[email protected]
<mailto:[email protected]>
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_4958234606457841392_m_8135393484437096515_m_-4558998169760756438_m_725265850614292706_m_7413263216575621585_m_9164379359524070019_m_61185112423032015_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
openEHR-clinical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
[email protected]
<mailto:[email protected]>
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/>
[email protected]
<mailto:[email protected]>
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________
openEHR-clinical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
[email protected]
<mailto:[email protected]>
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/>
[email protected] <mailto:[email protected]>
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________
openEHR-clinical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
Ian McNicoll
_______________________________________________
openEHR-clinical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
