SNOMED in CKM

Ian McNicoll ian at freshehr.com
Tue Apr 25 02:20:13 EDT 2017


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.verhees at 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.pazos at 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.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_4958234606457841392_m_8135393484437096515_m_-4558998169760756438_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
>> 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

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


More information about the openEHR-clinical mailing list