SNOMED in CKM

Pablo Pazos pablo.pazos at cabolabs.com
Tue Apr 25 00:58:05 EDT 2017


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_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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170425/ff840de0/attachment-0002.html>


More information about the openEHR-clinical mailing list