SNOMED in CKM

Diego Boscá yampeku at gmail.com
Tue Apr 25 03:42:04 EDT 2017


For interoperability, we need to tell more things from a terminology that
are nowadays still not possible: terminology version, date, license,
probably oid, etc.
Is more important to know the exact version (which would solve the 'name'
problem)

Regards

2017-04-25 8:27 GMT+02:00 Bert Verhees <bert.verhees at rosa.nl>:

> Hi Ian, not to be troublesome, but wouldn't it be better, for
> interoperability, to use the name IHTSDO uses.
>
> I think Pablo has a point here.
>
> Bert
>
> Op 25-4-2017 om 08:20 schreef Ian McNicoll:
>
> 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_-5175177527451187662_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
>
>
> _______________________________________________
> 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
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/000001C4DPJG> [image: Maps]
<https://htmlsig.com/t/000001BZTWS7>

Diego Boscá Tomás / Senior developer
diebosto at veratech.es
yampeku at gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a veratech at veratech.es.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170425/f218bab9/attachment-0002.html>


More information about the openEHR-clinical mailing list