SNOMED in CKM

Ian McNicoll ian at freshehr.com
Tue Apr 25 03:32:07 EDT 2017


Hi Bert,

SNOMED CT Licensing re openEHR is under active discussion with SNOMED.

The principle will be that archetypes or templates containing SNOMED CT
codes can be freely used within systems, unless the system actually uses
SNOMED CT codes in the patient data i.e as part of a defining_code or
mapping, in which case a SNOMED license will be required.

Ian


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian at freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 25 April 2017 at 09:14, Bert Verhees <bert.verhees at rosa.nl> wrote:

> 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>
> 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>:
>>
>>> I agree completely with you, Pablo
>>>
>>> Best regards
>>> Bert
>>>
>>> Op di 25 apr. 2017 06:24 schreef Pablo Pazos <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>
>>>> 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 <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
>>>>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>>>>>> lists.openehr.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ing. Pablo Pazos Gutiérrez
>>>>> Cel:(00598) 99 043 145 <099%20043%20145>
>>>>> Skype: cabolabs
>>>>> <http://cabolabs.com/>
>>>>> http://www.cabolabs.com
>>>>> 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_-4064804286928937838_m_725265850614292706_m_7413263216575621585_m_9164379359524070019_m_61185112423032015_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> openEHR-clinical mailing listopenEHR-clinical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>>>>>
>>>>> _______________________________________________ openEHR-clinical
>>>>> mailing list openEHR-clinical at lists.openehr.org
>>>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>>>>> lists.openehr.org
>>>>
>>>> --
>>>> Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 <099%20043%20145>
>>>> Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com
>>>> 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
>>>
>>> _______________________________________________ openEHR-clinical
>> mailing list openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> lists.openehr.org
>
> --
> Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 <+598%2099%20043%20145>
> Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com
> pablo.pazos at cabolabs.com Subscribe to our newsletter
> <http://eepurl.com/b_w_tj>
>
> _______________________________________________
> openEHR-clinical mailing listopenEHR-clinical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
>
> _______________________________________________
> 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/5015b92c/attachment-0002.html>


More information about the openEHR-clinical mailing list