Re: openEHR-technical Digest, Vol 80, Issue 12

[Pablo Pazos]

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 
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, <
> openehr-technical-requ...@lists.openehr.org> escreveu:
>
>> Send openEHR-technical mailing list submissions to
>> openehr-technical@lists.openehr.org
>>
>> 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
>> openehr-technical-requ...@lists.openehr.org
>>
>> You can reach the person managing the list at
>> openehr-technical-ow...@lists.openehr.org
>>
>> 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 +
>> From: Thomas Beale 
>> To: openehr-technical@lists.openehr.org
>> Subject: Re: Postcoordinated terminology expressions in openEHR
>> Message-ID: 
>> 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 

Re: openEHR-technical Digest, Vol 80, Issue 12

[Ricardo Gonçalves]

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, <
openehr-technical-requ...@lists.openehr.org> escreveu:

> Send openEHR-technical mailing list submissions to
> openehr-technical@lists.openehr.org
>
> 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
> openehr-technical-requ...@lists.openehr.org
>
> You can reach the person managing the list at
> openehr-technical-ow...@lists.openehr.org
>
> 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 +
> From: Thomas Beale 
> To: openehr-technical@lists.openehr.org
> Subject: Re: Postcoordinated terminology expressions in openEHR
> Message-ID: 
> 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: i...@freshehr.com 
> > twitter: @ianmcnicoll
> >
> >
> > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> > 
> > Director, freshEHR Clinical Informatics Ltd.
> > Director, HANDIHealth CIC
> > Hon. Senior Research Associate, CHIME, UCL
> >
> >
> >