SNOMED in CKM

Bert Verhees bert.verhees at rosa.nl
Tue Apr 25 02:27:11 EDT 2017


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 
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>                 <mailto: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
>                     <mailto: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
>>                         <mailto: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
>>                             <mailto: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 <tel:099%20043%20145>
>>                         Skype: cabolabs
>>                         	<http://cabolabs.com/>
>>                         http://www.cabolabs.com
>>                         <http://www.cabolabs.com/>
>>                         pablo.pazos at cabolabs.com
>>                         <mailto: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 list
>>                         openEHR-clinical at lists.openehr.org
>>                         <mailto: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
>                         <mailto: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 <tel:099%20043%20145>
>                     Skype: cabolabs
>                     	<http://cabolabs.com/>
>                     http://www.cabolabs.com <http://www.cabolabs.com/>
>                     pablo.pazos at cabolabs.com
>                     <mailto: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
>                     <mailto: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
>             <mailto: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 <http://www.cabolabs.com/>
>         pablo.pazos at cabolabs.com <mailto: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
>         <mailto: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
>     <mailto:openEHR-clinical at lists.openehr.org>
>     http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
> -- 
> Ian McNicoll
>
>
> _______________________________________________
> 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/9147dd63/attachment-0002.html>


More information about the openEHR-clinical mailing list