SNOMED in CKM

Bert Verhees bert.verhees at rosa.nl
Tue Apr 25 00:34:36 EDT 2017


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


More information about the openEHR-clinical mailing list