SNOMED in CKM

Bert Verhees bert.verhees at rosa.nl
Tue Apr 25 03:14:32 EDT 2017


Pablo, you are allowed to use the SNOMED browser, even if you do not 
have a license, you get a temporary license to use SNOMED, here are some 
conditions (the important point)

When you use SNOMED in terminology binding in an archetype, how did you 
find that SNOMED code?

I think point 4b is important:

4. End Users, that do not hold an SNOMED International Affiliate 
License, may access SNOMED CT® using SNOMED International SNOMED CT 
Browser subject to acceptance of and adherence to the following 
sub-license limitations:

a) The sub-licensee is only permitted to access SNOMED CT® using this 
software (or service) for the purpose of exploring and evaluating the 
terminology.

b) The sub-licensee is not permitted the use of this software as part of 
a system that constitutes a SNOMED CT "Data Creation System" or "Data 
Analysis System", as defined in the SNOMED International Affiliate 
License. This means that the sub-licensee must not use SNOMED 
International SNOMED CT Browser to add or copy SNOMED CT identifiers 
into any type of record system, database or document.





On 25-04-17 06:58, Pablo Pazos wrote:
> 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.verhees at rosa.nl 
> <mailto:bert.verhees at 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.verhees at rosa.nl <mailto:bert.verhees at rosa.nl>>:
>
>         I agree completely with you, Pablo
>
>         Best regards
>         Bert
>
>
>         Op di 25 apr. 2017 06:24 schreef Pablo Pazos
>         <pablo.pazos at cabolabs.com <mailto:pablo.pazos at 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.verhees at rosa.nl <mailto:bert.verhees at 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.verhees at rosa.nl <mailto:bert.verhees at 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 at lists.openehr.org
>>                     <mailto:openEHR-clinical at 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.pazos at cabolabs.com
>>                 <mailto:pablo.pazos at 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_725265850614292706_m_7413263216575621585_m_9164379359524070019_m_61185112423032015_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>>
>>                 _______________________________________________
>>                 openEHR-clinical mailing list
>>                 openEHR-clinical at lists.openehr.org
>>                 <mailto:openEHR-clinical at 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 at lists.openehr.org
>                 <mailto:openEHR-clinical at 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.pazos at cabolabs.com
>             <mailto:pablo.pazos at cabolabs.com> Subscribe to our
>             newsletter <http://eepurl.com/b_w_tj>
>
>             _______________________________________________
>             openEHR-clinical mailing list
>             openEHR-clinical at lists.openehr.org
>             <mailto:openEHR-clinical at 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 at lists.openehr.org
>     <mailto:openEHR-clinical at 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.pazos at cabolabs.com 
> <mailto:pablo.pazos at cabolabs.com> Subscribe to our newsletter 
> <http://eepurl.com/b_w_tj>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170425/a07aaea9/attachment-0002.html>


More information about the openEHR-clinical mailing list