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.verh...@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.verh...@rosa.nl>: > >> I agree completely with you, Pablo >> >> Best regards >> Bert >> >> Op di 25 apr. 2017 06:24 schreef Pablo Pazos <pablo.pa...@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.verh...@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.verh...@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@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.pa...@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@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> openEHR-clinical mailing list >>>> 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 <099%20043%20145> >>> Skype: cabolabs >>> <http://cabolabs.com/> >>> http://www.cabolabs.com >>> pablo.pa...@cabolabs.com >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr- >>> clinical_lists.openehr.org >> >> > _______________________________________________ > openEHR-clinical mailing list > 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 pablo.pa...@cabolabs.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
