openEHR-clinical Digest, Vol 59, Issue 20

William Goossen wgoossen at results4care.nl
Tue Apr 25 05:51:29 EDT 2017


Many questions are in SNOMEDCT eg observable entities 
Many answers are in LOINC, in particular the answers to questions for assessment scales.

ISO TS 13972 gives careful guidelines to choose the precise code from any code system for both questions and answers.

The blunt this does A and that does B will prove impossible for many concepts and I see no move to 100% redo SnomedCT nor LOINC (because it is unnecessary).

Vriendelijke groet,

Dr. William Goossen

Directeur Results 4 Care BV
+31654614458

> Op 25 apr. 2017 om 11:42 heeft openehr-clinical-request at lists.openehr.org het volgende geschreven:
> 
> Send openEHR-clinical mailing list submissions to
>    openehr-clinical at lists.openehr.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
> 
> or, via email, send a message with subject or body 'help' to
>    openehr-clinical-request at lists.openehr.org
> 
> You can reach the person managing the list at
>    openehr-clinical-owner at lists.openehr.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openEHR-clinical digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: SNOMED in CKM (GF)
>   2. Re: SNOMED in CKM (Bert Verhees)
>   3. Re: SNOMED in CKM (Bert Verhees)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 25 Apr 2017 09:57:08 +0200
> From: GF <gfrer at luna.nl>
> To: For openEHR clinical discussions
>    <openehr-clinical at lists.openehr.org>
> Subject: Re: SNOMED in CKM
> Message-ID: <DFE3D2F4-BA89-48EE-A464-7F636640FC63 at luna.nl>
> Content-Type: text/plain; charset="utf-8"
> 
> Pablo,
> 
> I agree.
> Attaching codes to nodes in the archetype is in order to disambiguate that archetype node concept/name.
> 
> In addition.
> I think that we should NOT use SNOMED-CT codes for that purpose.
> As far as I know this is the realm of LOINC. So we need LOINC codes to disambiguate nodes in an archetype.
> 
> In general LOINC is used to disambiguate the ?Question?.
> And SNOMED is used to disambiguate the ?Answer?; the ?Result'
> This implicates that LOINC must be used in all Archetype nodes that are NO leaf-nodes.
> SNOMED must be used in Leaf-nodes and stored as results and queried for as results.
> 
> 
> Gerard   Freriks
> +31 620347088
>  gfrer at luna.nl
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 25 Apr 2017, at 06:23, Pablo Pazos <pablo.pazos at cabolabs.com> wrote:
>> 
>> 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.
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170425/689a3876/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 25 Apr 2017 11:40:28 +0200
> From: Bert Verhees <bert.verhees at rosa.nl>
> To: For openEHR clinical discussions
>    <openehr-clinical at lists.openehr.org>
> Subject: Re: SNOMED in CKM
> Message-ID: <303abdc6-f82f-2c69-680b-221de985f198 at rosa.nl>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
>> On 25-04-17 09:32, Ian McNicoll wrote:
>> Hi Bert,
>> 
>> SNOMED CT Licensing re openEHR is under active discussion with SNOMED.
>> 
>> The principle will be that archetypes or templates containing SNOMED 
>> CT codes can be freely used within systems, unless the system actually 
>> uses SNOMED CT codes in the patient data i.e as part of a 
>> defining_code or mapping, in which case a SNOMED license will be required.
> 
> Ok, I misunderstood that, I thought you were in discussion about using 
> SNOMED in CKM term-bindings, and that users without affiliate license 
> should manually remove them.
> But as I understand it now, you are in discussion about permission for 
> using SNOMED in term-bindings, also when you have no affiliate license.
> 
> That would make life simpler for many (not for me, but our German friends)
> 
> Bert
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 25 Apr 2017 11:42:09 +0200
> From: Bert Verhees <bert.verhees at rosa.nl>
> To: For openEHR clinical discussions
>    <openehr-clinical at lists.openehr.org>
> Subject: Re: SNOMED in CKM
> Message-ID: <03d5a79b-6b49-80b5-4b38-c52e86d599b9 at rosa.nl>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
> 
>> 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.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
> 
> ------------------------------
> 
> End of openEHR-clinical Digest, Vol 59, Issue 20
> ************************************************





More information about the openEHR-clinical mailing list