Hi Ricardo,

Yes, I've integrated SNOMED Expressions into our path-based queries, that
is basically another syntax for openEHR queries, alternative to AQL.

What I did was adding the operator in_snomed_exp associated to
DV_CODED_TEXT, so you can say something like "retrieve all the compositions
that contain a path to a DV_CODED_TEXT, such as the code value on that is
in a expression e. This is at the syntax / query building level.

At the query evaluation level, if the evaluator finds a in_snomed_exp
operator, it resolves the expression e against a SNOMED CT expression
expansion service, provided by our partner VeraTech, and the expanded
expression is integrated into an SQL query, generated from the path-based
query evaluation. This mixed with complex conditions on other nodes, gives
a lot of possibilities on what can be done with the query results. Our
focus is CDS, so we mainly want those results to feed CDS rules.

Hope this helps to understand our approach.

Best,
Pablo.


On Mon, Nov 19, 2018 at 4:56 PM Ricardo Gonçalves <[email protected]>
wrote:

> Hi all,
>
> It's been a while since I've seen it but I think Pablo Pazos has some
> quite good work for that topic on EHRServer, at least for subsumption [
> https://ppazos.github.io/cabolabs-ehrserver/ mentions "Support of SNOMED
> CT Expressions on openEHR queries (simplifies complex queries)"]. There is
> also a demonstration video on YouTube. With regards to binding to the
> model, though, things might be tricky.
>
> Cheers,
> Ricardo Gonçalves.
>
> Em seg, 19 de nov de 2018 às 17:21, <
> [email protected]> escreveu:
>
>> Send openEHR-technical mailing list submissions to
>>         [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>> or, via email, send a message with subject or body 'help' to
>>         [email protected]
>>
>> You can reach the person managing the list at
>>         [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openEHR-technical digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Postcoordinated terminology expressions in openEHR
>>       (Thomas Beale)
>>    2. Re: Postcoordinated terminology expressions in openEHR
>>       (Ian McNicoll)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 19 Nov 2018 15:38:52 +0000
>> From: Thomas Beale <[email protected]>
>> To: [email protected]
>> Subject: Re: Postcoordinated terminology expressions in openEHR
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> I mostly agree with Ian, but with the small caveat that for very
>> specific and well-known cases such as body laterality, you just /might
>> consider/ post-coordination on body site e.g.
>>
>>   * 56459004 |foot structure| : 272741003 |laterality| = 7771000 |left|)
>>
>> However, even here, laterality often seems to be divided out in various
>> ways depending on what you are talking about. E.g. anything to do with
>> eyes, the whole exam is per-eye rather than each finding being marked as
>> being on the 'eye, left' or 'eye, right'. In other places, 'left' and
>> 'right' don't even have symmetrical meanings e.g. the heart (think
>> left-branch bundle etc).
>>
>> Nevertheless, for those body sites where findings are reported as being
>> on some X+left or right, I think we probably should consider
>> post-coordination of the site and the laterality at some point. For
>> everything else, it's a nice idea but forget it in data models.
>>
>> Where it could be used is via a /mapping formula /for multiple data
>> points, e.g. in an archetype. The archetype data would be defined
>> populated as a structure (as today), but a 'post-coordination formula'
>> that indicates how to bind the values of particular coded elements
>> together to obtain a Snomed expression could be used to generate such
>> expressions from the data, for consumption by inference engines. This is
>> the only place where they can be usefully computed with, in my opinion.
>>
>> Such a formula might look like this:
>>
>>   * 47933007 |$pain_finding| : 363698007 |finding_site| = (
>>     $finding_site: 272741003 |laterality| =? $laterality)
>>
>> where $pain_finding, $finding_site and $laterality are bound to paths in
>> the archetype.
>>
>> If the formula were evaluated, it might give this:
>>
>>   * 22253000 |pain| : 363698007 |finding site| = ( 56459004 |foot
>>     structure| : 272741003 |laterality| = 7771000 |left| )
>>
>> With minor adjustments in the binding part of the ADL2 grammar, such
>> formula bindings could be accommodated fairly easily I would think.
>>
>> Note: this is speculation, and has never been tried as far as I know.
>> Even if it does, it's only for SNOMED, unless the SNOMED model of
>> post-coordinated expressions is adopted by other terminologies...
>>
>> - thomas
>>
>>
>> On 19/11/2018 13:32, Ian McNicoll wrote:
>> > Basically - don't!!
>> >
>> > The UK has been trying to do this for over 20 years without success.
>> > It is a terminologists?dream but implementers?nightmare.
>> >
>> > Make a start with high-value use cases e.g Allergy agent "Allergic
>> > to?+ causative?agent" - so that you do not have to generate a new
>> > Snomed code for every potential allergen.
>> >
>> > Perhaps consider laterality. Beyond that, you risk delaying SNOMED?CT
>> > implementation, as has happened in the UK.
>> >
>> > Post-coordination is like nuclear fusion - a damned good idea but
>> > tricky to do without blowing everything up.
>> >
>> > Ian
>> > Ian
>> > Dr Ian McNicoll
>> > mobile +44 (0)775 209 7859
>> > office +44 (0)1536 414994
>> > skype: ianmcnicoll
>> > email: [email protected] <mailto:[email protected]>
>> > twitter: @ianmcnicoll
>> >
>> >
>> > Co-Chair, openEHR Foundation [email protected]
>> > <mailto:[email protected]>
>> > Director, freshEHR Clinical Informatics Ltd.
>> > Director, HANDIHealth CIC
>> > Hon. Senior Research Associate, CHIME, UCL
>> >
>> >
>> > On Mon, 19 Nov 2018 at 13:20, Bakke, Silje Ljosland
>> > <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> >     Hi everyone,
>> >
>> >     We?ve recently started an informal and practically oriented
>> >     regular contact with the Norwegian SNOMED CT NRC. One of the
>> >     things they were interested in discussing was how to use
>> >     postcoordinated SNOMED CT (expression constraint language)
>> >     expressions with openEHR, which I know nothing about. Does anyone
>> >     have any knowledge about or experience with this?
>> >
>> >     Kind regards,
>> >     *Silje Ljosland Bakke*
>> >
>> >     **
>> >
>> >     Information Architect, RN
>> >
>> >     Coordinator, National Editorial Board for Archetypes
>> >     Nasjonal IKT HF, Norway
>> >
>> >     Tel. +47 40203298
>> >
>> >     Web: http://arketyper.no <http://arketyper.no/>/ Twitter:
>> >     @arketyper_no <https://twitter.com/arketyper_no>
>> >
>> >     _______________________________________________
>> >     openEHR-technical mailing list
>> >     [email protected]
>> >     <mailto:[email protected]>
>> >
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> >
>> >
>> > _______________________________________________
>> > openEHR-technical mailing list
>> > [email protected]
>> >
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> --
>> Thomas Beale
>> Principal, Ars Semantica <http://www.arssemantica.com>
>> Consultant, ABD Project, Intermountain Healthcare
>> <https://intermountainhealthcare.org/>
>> Management Board, Specifications Program Lead, openEHR Foundation
>> <http://www.openehr.org>
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> <http://www.bcs.org/category/6044>
>> Health IT blog <http://wolandscat.net/> | Culture blog
>> <http://wolandsothercat.net/> | The Objective Stance
>> <https://theobjectivestance.net/>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20181119/0d1bc9a0/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 19 Nov 2018 15:53:30 +0000
>> From: Ian McNicoll <[email protected]>
>> To: For openEHR technical discussions
>>         <[email protected]>
>> Subject: Re: Postcoordinated terminology expressions in openEHR
>> Message-ID:
>>         <CAG-n1KyioGVnfV0PDmZEFN=
>> [email protected]>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Yes agree laterality is another potentially high value case.
>>
>> They should probably talk to the CIMI folks. Stan Huff has a good an idea
>> as anyone of both the potential and pitfalls of complex terminology
>> handling. I suspect that really held CIMI back at a critical moment but at
>> least they have a good understanding of te challenges.
>>
>> In spite of decades of attempts, I don't know of any national program that
>> is using post-coordination to any extent.
>>
>> Ian
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: [email protected]
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation [email protected]
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Mon, 19 Nov 2018 at 15:38, Thomas Beale <[email protected]>
>> wrote:
>>
>> > I mostly agree with Ian, but with the small caveat that for very
>> specific
>> > and well-known cases such as body laterality, you just *might consider*
>> > post-coordination on body site e.g.
>> >
>> >    - 56459004 |foot structure| : 272741003 |laterality| = 7771000
>> |left|)
>> >
>> > However, even here, laterality often seems to be divided out in various
>> > ways depending on what you are talking about. E.g. anything to do with
>> > eyes, the whole exam is per-eye rather than each finding being marked as
>> > being on the 'eye, left' or 'eye, right'. In other places, 'left' and
>> > 'right' don't even have symmetrical meanings e.g. the heart (think
>> > left-branch bundle etc).
>> >
>> > Nevertheless, for those body sites where findings are reported as being
>> on
>> > some X+left or right, I think we probably should consider
>> post-coordination
>> > of the site and the laterality at some point. For everything else, it's
>> a
>> > nice idea but forget it in data models.
>> >
>> > Where it could be used is via a *mapping formula *for multiple data
>> > points, e.g. in an archetype. The archetype data would be defined
>> populated
>> > as a structure (as today), but a 'post-coordination formula' that
>> indicates
>> > how to bind the values of particular coded elements together to obtain a
>> > Snomed expression could be used to generate such expressions from the
>> data,
>> > for consumption by inference engines. This is the only place where they
>> can
>> > be usefully computed with, in my opinion.
>> >
>> > Such a formula might look like this:
>> >
>> >    - 47933007 |$pain_finding| : 363698007 |finding_site| = (
>> >    $finding_site: 272741003 |laterality| =  $laterality)
>> >
>> > where $pain_finding, $finding_site and $laterality are bound to paths in
>> > the archetype.
>> >
>> > If the formula were evaluated, it might give this:
>> >
>> >    - 22253000 |pain| : 363698007 |finding site| = ( 56459004 |foot
>> >    structure| : 272741003 |laterality| = 7771000 |left| )
>> >
>> > With minor adjustments in the binding part of the ADL2 grammar, such
>> > formula bindings could be accommodated fairly easily I would think.
>> >
>> > Note: this is speculation, and has never been tried as far as I know.
>> Even
>> > if it does, it's only for SNOMED, unless the SNOMED model of
>> > post-coordinated expressions is adopted by other terminologies...
>> >
>> > - thomas
>> >
>> > On 19/11/2018 13:32, Ian McNicoll wrote:
>> >
>> > Basically - don't!!
>> >
>> > The UK has been trying to do this for over 20 years without success. It
>> is
>> > a terminologists dream but implementers nightmare.
>> >
>> > Make a start with high-value use cases e.g Allergy agent "Allergic to +
>> > causative agent" - so that you do not have to generate a new Snomed code
>> > for every potential allergen.
>> >
>> > Perhaps consider laterality. Beyond that, you risk delaying SNOMED CT
>> > implementation, as has happened in the UK.
>> >
>> > Post-coordination is like nuclear fusion - a damned good idea but tricky
>> > to do without blowing everything up.
>> >
>> > Ian
>> > Ian
>> > Dr Ian McNicoll
>> > mobile +44 (0)775 209 7859
>> > office +44 (0)1536 414994
>> > skype: ianmcnicoll
>> > email: [email protected]
>> > twitter: @ianmcnicoll
>> >
>> >
>> > Co-Chair, openEHR Foundation [email protected]
>> > Director, freshEHR Clinical Informatics Ltd.
>> > Director, HANDIHealth CIC
>> > Hon. Senior Research Associate, CHIME, UCL
>> >
>> >
>> > On Mon, 19 Nov 2018 at 13:20, Bakke, Silje Ljosland <
>> > [email protected]> wrote:
>> >
>> >> Hi everyone,
>> >>
>> >>
>> >>
>> >> We?ve recently started an informal and practically oriented regular
>> >> contact with the Norwegian SNOMED CT NRC. One of the things they were
>> >> interested in discussing was how to use postcoordinated SNOMED CT
>> >> (expression constraint language) expressions with openEHR, which I know
>> >> nothing about. Does anyone have any knowledge about or experience with
>> this?
>> >>
>> >>
>> >>
>> >> Kind regards,
>> >> *Silje Ljosland Bakke*
>> >>
>> >>
>> >>
>> >> Information Architect, RN
>> >>
>> >> Coordinator, National Editorial Board for Archetypes
>> >> Nasjonal IKT HF, Norway
>> >>
>> >> Tel. +47 40203298
>> >>
>> >> Web: http://arketyper.no / Twitter: @arketyper_no
>> >> <https://twitter.com/arketyper_no>
>> >>
>> >>
>> >> _______________________________________________
>> >> openEHR-technical mailing list
>> >> [email protected]
>> >>
>> >>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> >>
>> >
>> > _______________________________________________
>> > openEHR-technical mailing listopenEHR-technical
>> @lists.openehr.orghttp://
>> lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> >
>> > --
>> > Thomas Beale
>> > Principal, Ars Semantica <http://www.arssemantica.com>
>> > Consultant, ABD Project, Intermountain Healthcare
>> > <https://intermountainhealthcare.org/>
>> > Management Board, Specifications Program Lead, openEHR Foundation
>> > <http://www.openehr.org>
>> > Chartered IT Professional Fellow, BCS, British Computer Society
>> > <http://www.bcs.org/category/6044>
>> > Health IT blog <http://wolandscat.net/> | Culture blog
>> > <http://wolandsothercat.net/> | The Objective Stance
>> > <https://theobjectivestance.net/>
>> > _______________________________________________
>> > openEHR-technical mailing list
>> > [email protected]
>> >
>> >
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20181119/2ac763da/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> [email protected]
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>> ------------------------------
>>
>> End of openEHR-technical Digest, Vol 80, Issue 12
>> *************************************************
>>
> _______________________________________________
> openEHR-technical mailing list
> [email protected]
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
[email protected]
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to