SNOMED in CKM

Bert Verhees bert.verhees at rosa.nl
Tue Apr 25 05:42:09 EDT 2017


On 25-04-17 09:42, Diego Boscá wrote:
> 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)

That is true, did not think about that.


>
> Regards
>
> 2017-04-25 8:27 GMT+02:00 Bert Verhees <bert.verhees at rosa.nl 
> <mailto: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
>>     <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
>>                             <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
>>>                                 <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_-5175177527451187662_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
>>>                             <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
>>                             <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
>>                         <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
>>                 <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
>>             <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
>>         <http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
>>
>>     -- 
>>     Ian McNicoll
>>
>>     _______________________________________________
>>     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
>>     <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
>     <http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
>
>
> -- 
>
> VeraTech for Health SL <https://htmlsig.com/t/000001C268PZ>
>
> Twitter <https://htmlsig.com/t/000001C47QQH>LinkedIn 
> <https://htmlsig.com/t/000001C4DPJG>Maps 
> <https://htmlsig.com/t/000001BZTWS7>
>
> Diego Boscá Tomás / Senior 
> developerdiebosto at veratech.es<mailto:diebosto at veratech.es> 
> yampeku at gmail.com <mailto:yampeku at gmail.com>
>
> VeraTech for Health SL +34 961071863 <tel:+34%20961%2007%2018%2063> / 
> +34 627015023 <tel:+34%20627%2001%2050%2023> www.veratech.es 
> <http://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 
> <mailto:veratech at veratech.es>.
>
> _______________________________________________
> 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/4b47582f/attachment-0002.html>


More information about the openEHR-clinical mailing list