SNOMED in CKM

Pablo Pazos pablo.pazos at cabolabs.com
Tue Apr 25 00:23:09 EDT 2017


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


More information about the openEHR-clinical mailing list