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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >> >>> 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 <[email protected]> >>> 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 <[email protected]>: >>>> >>>>> I agree completely with you, Pablo >>>>> >>>>> Best regards >>>>> Bert >>>>> >>>>> Op di 25 apr. 2017 06:24 schreef Pablo Pazos <[email protected] >>>>> >: >>>>> >>>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>>>>>> [email protected]http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openEHR-clinical mailing list >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>>>>> _______________________________________________ >>>>>> openEHR-clinical mailing list >>>>>> [email protected] >>>>>> http://lists.openehr.org/mailman/listinfo/openehr- >>>>>> clinical_lists.openehr.org >>>>> >>>>> >>>> _______________________________________________ >>>> openEHR-clinical mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> [email protected] >>> http://lists.openehr.org/mailman/listinfo/openehr- >>> clinical_lists.openehr.org >> >> _______________________________________________ >> openEHR-clinical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org > > -- > Ian McNicoll > > > _______________________________________________ > openEHR-clinical mailing > [email protected]http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > _______________________________________________ > openEHR-clinical mailing list > [email protected] > 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 [email protected] [email protected] 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 [email protected].
_______________________________________________ openEHR-clinical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
