Re: Postcoordinated terminology expressions in openEHR

[Michael.Lawley]

I'm with Ian on this. The only use of post coordination is hard and requires 
complex tooling support that is way beyond any value you get.  I would say even 
laterality & other qualifiers should go in the information model and not in the 
terminology if you have the choice.

If you are instead talking about ECLs expression constraint language, then you 
might want to look at http://ontoserver.csiro.au/shrimp/ecl which provides a UI 
for constructing ECL expressions and evaluates them as well. It also has links 
to summary documentation and sample expressions.

Michael

Sent from my iPhone

On 20 Nov 2018, at 4:56 am, David Moner 
mailto:dam...@gmail.com>> wrote:

Hi, just for clarification, you have mixed are two different things:

- SNOMED CT postcoordinated expressions are structured combinations of one or 
more concepts to express a clinical idea. You use them to create new concepts 
not available in the SNOMED release. They are built using the SNOMED CT 
Compositional Grammar. In the archetypes they could be used for the semantic 
binding of the structure (at codes), or for data values in coded data 
typeshttps://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Compositional+Grammar
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Compositional+Grammar

- SNOMED CT Expression Constraint Language is an extension of the compositional 
grammar that allows building SNOMED CT subsets intensionally, i.e., by 
restriction or querying. This allows you to create a subset by defining an 
expresion. This can be used to constraint coded values (ac codes)
https://confluence.ihtsdotools.org/display/DOCECL/Expression+Constraint+Language+-+Specification+and+Guide

Now, if your question is about how to combine the modeling of archetypes and 
the modeling of SNOMED CT expressions, this paper could give you some hints. 
It's old, but still relevant. There are clear areas for modeling information as 
archetypes or with terminologies, but there is also a grey area where both 
solutions are applicable.

"Representing clinical information using SNOMED Clinical Terms with different 
structural information models", David Markwell, Laura Sato, Edward Cheetham
http://ceur-ws.org/Vol-410/Paper13.pdf

El lun., 19 nov. 2018 a las 14:21, Bakke, Silje Ljosland 
(mailto:silje.ljosland.ba...@nasjonalikt.no>>)
 escribió:
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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SMART on FHIR integration

[Michael.Lawley]

Broadly, the context is the current patient being looked at in the EMR, or 
other platform being used to launch the SMART App.

This allows the app to request authorisation for data specific to the 'current 
patient' and then launch directly into the task.

Michael

Sent from my iPhone

On 24 Apr 2018, at 5:23 pm, Seref Arikan 
> 
wrote:

Could you explain what you mean by context please?

On Tue, Apr 24, 2018 at 1:23 AM, 
> wrote:


The real value of SMART (whether its "on FHIR" or not) is that it sets a 
mechanism for EMRs to pass context to external apps.  This means apps are 
re-usable across different back ends.


Note that this is not really about authentication (SSO) but rather it is about 
authorisation.


michael


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical 
>
 on behalf of Pablo Pazos 
>
Sent: Tuesday, 24 April 2018 9:29 AM
To: For openEHR technical discussions
Subject: Re: SMART on FHIR integration

SSO is a front end feature, that is not on the current scope of the openEHR 
specs.

I think any openEHR implementer can do SSO at the front-end app level to access 
SMART apps.

On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz 
> wrote:
I see you have had discussions on FHIR and SMART on FHIR.  Is it on the roadmap 
for openEHR to support SMART on FHIR launch sequence 
(http://docs.smarthealthit.org/authorization/) for single sign on?  I know many 
customers who would like this seemless integration.

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SMART on FHIR integration

[Michael.Lawley]

The real value of SMART (whether its "on FHIR" or not) is that it sets a 
mechanism for EMRs to pass context to external apps.  This means apps are 
re-usable across different back ends.


Note that this is not really about authentication (SSO) but rather it is about 
authorisation.


michael


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical  on behalf 
of Pablo Pazos 
Sent: Tuesday, 24 April 2018 9:29 AM
To: For openEHR technical discussions
Subject: Re: SMART on FHIR integration

SSO is a front end feature, that is not on the current scope of the openEHR 
specs.

I think any openEHR implementer can do SSO at the front-end app level to access 
SMART apps.

On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz 
> wrote:
I see you have had discussions on FHIR and SMART on FHIR.  Is it on the roadmap 
for openEHR to support SMART on FHIR launch sequence 
(http://docs.smarthealthit.org/authorization/) for single sign on?  I know many 
customers who would like this seemless integration.

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: [Troll] Terminology bindings ... again

[Michael.Lawley]

Hi Heather,


In general, anyone is welcome to participate in the work; you don't need to be 
one of the small number of Advisory Group members.  That helps with travel 
costs, but most of the real work is done on teleconferences, not so much at the 
face to face meetings.


I would be very interested to hear people's articulations of where they think 
the boundary should be for this boundary line.  I'd also be interested to 
understand better what people think the problem is with having "extra" / 
unnecessary pre-coordinated concepts; what advantage is to be gained from 
removing them, and what is the perceived scale of the problem.


michael


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical  on behalf 
of Heather Leslie 
Sent: Thursday, 22 March 2018 9:46 AM
To: For openEHR technical discussions
Subject: RE: SV: [Troll] Terminology bindings ... again

Hi Mikael,

What efforts are being made to resolve the boundary problem?

I applied to get involved with the  SNOMED information modelling group but 
wasn’t successful, to try to engage on exactly that  point.

I’m not aware of any work going on. I’d be very pleased to get involved if I 
could. It’s a fiendish problem and we need cooperation and collaboration from 
both sides of the fence.

Regards

Heather

From: openEHR-technical  On Behalf 
Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions 
Subject: SV: SV: [Troll] Terminology bindings ... again

Hi Tom,

I believe that you proposal to ”move / remove the pre-coordinated codes out of 
SNOMED” is very appealing in theory. However it is very difficult in reality to 
agree on where the line between a suitable pre-coordinated concept and a 
concept that is better to post-coordinate or handle in another way are. The 
line between the two alternatives also seem to be use case dependent, which 
makes it even more difficult, and of cause also related to the boundary 
problem. However, until there is a strong agreement on where the line should be 
I continue to believe that it is better so include the concepts in the same 
pile and let each use case decide how to select the concepts they need and 
transform between the different representations.

I like discussions about SNOMED CT and I don’t have any problems at all with 
critical comments as long as they are fair. Those kinds of criticism quite 
often makes me writing change requests. I am also happy to answer questions 
about SNOMED CT. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on incorrect facts and/or SNOMED CT is bad because it isn’t optimized for 
their narrow use case.

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 21 mars 2018 14:17
Till: 
openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again




Nevertheless, I think it would have been good to move / remove the 
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, 
which would actually look a lot more like Philippe's (much smaller) terminology.

This relates to the old debate on reference v interface terminology, and just 
throwing out precoord concepts is probably not right - they need to be in a 
completely different hierarchy.

The post-coordination grammar in SCT is good, its theoretical challenge is the 
concept meta-model, i.e. what things like 'morphology', 'laterality' you can 
mention, and in what relationship. But this is hard for all of us, and requires 
some serious ontology work (Mikael and other experts know all about this of 
course).

What I would say is this: in a similar way that I think SNOMED should have 
separated out 'SNOMED technology' (representation, APIs etc) from content, I 
think the concept meta-model should have been / could be made a separate 
artefact, maybe even an OBO ontology - at the moment it is too hidden inside 
the giant content artefact. If that were done, we could work more effectively 
on aligning with information / content models, whose attribute names should, 
generally speaking relate to (or be the same as) the meta-model ontology 
entities. If we pursued this line, the ontology would instantly be expanded by 
examination of archetypes, and conversely, many archetypes could be fixed where 
they contain errors or questionable attribute names.

THis isn't to criticise experts or work done in SNOMED per se, but we should be 
perfectly happy to 

Re: Terminology bindings ... again

[Michael.Lawley]

Yes, it wasn’t part of STU3 (aka 3.0.1) but is now in the R4 spec - see 
http://build.fhir.org/snomedct.html#implicit

Michael

Sent from my iPhone

On 12 Mar 2018, at 8:39 pm, Diego Boscá 
> 
wrote:https://www.hl7.org/fhir/snomedct.html#implicit
Interesting to know, although I don't see that as an option in latest FHIR spec
https://www.hl7.org/fhir/snomedct.html#implicit

2018-03-12 11:15 GMT+01:00 
>:
FHIR also supports the expression language in the URL with, for example, 
http://snomed.info/sct?fhir_vs=ecl/<<123464:474748=<<84848484

But note that these URIs (the above and your isa/ one below) are defined by HL7 
FHIR, not SNOMED International. Technically they identify FHIR ValueSets that 
expand to the set of codes you want.

You could do a lot worse than adopting the FHIR ValueSet mechanism for binding. 
There are some excellent terminology servers out there (full disclosure, one of 
them, Ontoserver, is mine).

Michael


Sent from my iPhone

On 12 Mar 2018, at 7:00 pm, Diego Boscá 
> wrote:

Probably we should have a look at 
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
FHIR also uses the same base uri, but builds the URI using a custom syntax such 
as http://snomed.info/sct?fhir_vs=isa/138875005
But looking at the Snomed URI standard I assume they will just go with that in 
the future

2018-03-12 1:38 GMT+01:00 Pablo Pazos 
>:
Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.

About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.

I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:


term_bindings = <
["snomed_ct"] = <
["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<
target =  -- Apgar score at 
1 minute
notes = <"some notes">
min_version = <"2017-02-01">
etc = <"etc">
>
["id26"] = (CONSTRAINT_BINDING) <
target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">
   min_version = <"2017-04-01">
notes = <"some notes">
etc = <"etc">
>
>
>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.

I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?

I would like to get a 

Re: Terminology bindings ... again

[Michael.Lawley]

FHIR also supports the expression language in the URL with, for example, 
http://snomed.info/sct?fhir_vs=ecl/<<123464:474748=<<84848484

But note that these URIs (the above and your isa/ one below) are defined by HL7 
FHIR, not SNOMED International. Technically they identify FHIR ValueSets that 
expand to the set of codes you want.

You could do a lot worse than adopting the FHIR ValueSet mechanism for binding. 
There are some excellent terminology servers out there (full disclosure, one of 
them, Ontoserver, is mine).

Michael


Sent from my iPhone

On 12 Mar 2018, at 7:00 pm, Diego Boscá 
> wrote:

Probably we should have a look at 
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
FHIR also uses the same base uri, but builds the URI using a custom syntax such 
as http://snomed.info/sct?fhir_vs=isa/138875005
But looking at the Snomed URI standard I assume they will just go with that in 
the future

2018-03-12 1:38 GMT+01:00 Pablo Pazos 
>:
Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.

About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.

I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:


term_bindings = <
["snomed_ct"] = <
["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<
target =  -- Apgar score at 
1 minute
notes = <"some notes">
min_version = <"2017-02-01">
etc = <"etc">
>
["id26"] = (CONSTRAINT_BINDING) <
target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">
   min_version = <"2017-04-01">
notes = <"some notes">
etc = <"etc">
>
>
>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.

I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?

I would like to get a better idea of the requirements.

- thomas


--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog

Re: SNOMEDCT - correct representation

[Michael.Lawley]

Hi Koray,


The implicit FHIR ValueSets for SNOMED do not need to be explicitly defined and 
cover the finite set (with respect to a specific release) of ValueSets that 
correspond one-to-one with SNOMED reference sets. They also cover the unbounded 
set of ValueSets that can be defined as "descendants and self of XXX" where XXX 
is any SNOMED code OR and SNOMED post coordinated expression (FHIR does not 
impose an arbitrary distinction between a single code and a multi-code 
expression).  This gets you a very long way.


Currently, FHIR does not define any implicit ValueSets that correspond to a 
single ECL expression, but we could propose this and it would be 
straightforward for terminology services to support.


ValueSets in general go beyond this because they allow additional filtering 
operations beyond those supported by ECL, as well as UNION and EXCLUDE 
operations between ValueSets (good for re-use), and mixing of code from 
multiple code systems (hopefully a rare case).


Binding to define meaning is a slightly different use-case; you're binding to a 
single concept (possibly post coordinated) rather than defining the range of a 
property via a set of possible values.


michael


--
Dr Michael Lawley
Research Group Leader, Senior Principal Research Scientist
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical  on behalf 
of Koray Atalag 
Sent: Saturday, 6 May 2017 11:25 PM
To: For openEHR technical discussions
Subject: RE: SNOMEDCT - correct representation

Hi Michael,

You can only define and manage so many ECL valuesets and assign URIs – which is 
fine. Trouble is the combinations are endless. Therefore IMHO we definitely 
need ways to embed post-coordinated terms (for defining meaning) and ECL (for 
valuesets) in terminology bindings.

Tom I like your suggestion for a terminology referencing way to include all of 
the above. I would also argue that we should be able to mix terms from 
different terminology and ontology systems as well. In computational 
physiology, where they don’t have an uber-ontology like SNOMED, when defining 
semantic annotations (our terminology bindings) they can use kind of 
post-coordination (all URIs): [term1:ontologyA] [relation-may_be_defined_in 
ontology B] [term2:ontology C] etc. you’ll get the idea.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of michael.law...@csiro.au
Sent: Thursday, 4 May 2017 1:05 a.m.
To: openehr-technical@lists.openehr.org
Subject: [FORGED] Re: SNOMEDCT - correct representation

I think this thread has gone a little off the rails.

There are predefined (by FHIR) URIs for value sets that are defined just as 
descendants of a single concept, or members of a reference set.

For an enumeration of concepts and/or a snomed ECL expression, then you can use 
a Fhir ValueSet and give it a URI.  ValueSets also generalise beyond just 
SNOMED (LOINC for example).

Furthermore, there are existing tools to expand them to the set of member 
concepts, you can include metadata, manage versions etc.  This is much more 
than you get just by encoding ECL in a URI.

In case anyone wants to play with ECL expressions and their evaluation you can 
go here for an interactive page:
https://ontoserver.csiro.au/shrimp/ecl.html

Also, some brief documentation and click-through examples here
https://ontoserver.csiro.au/shrimp/ecl_help.html

Regards

Michael
Sent from my iPhone

On 3 May 2017, at 9:08 pm, Diego Boscá 
> wrote:
Seems like the only way right now is creating refsets and referencing them with 
standard URIs...

2017-05-03 13:02 GMT+02:00 Bert Verhees 
>:
On 03-05-17 12:53, Thomas Beale wrote:
On 03/05/2017 11:40, Bert Verhees wrote:

On 03-05-17 12:36, Thomas Beale wrote:

The only missing part, now that I look at the SNOMED Compositional 
Grammar and Expression 
Constraint Language specs, 
is how to create a URI (which is the type of a term binding in 
ADL2)
 from a post-coordinated expression or constraint expression. This should be 
trivial, but I don't see where SNOMED has specified it.

True, I was looking for that also, a few days ago. I don't have time to read 
much now, but there is a document on the SNOMED site on URI's, maybe it is in 
there?
I can take a look later or look in my documentation, I have course materials. I 
come back to this tomorrow if not someone else already has.

The URI spec is 
here, 
but it doesn't address URIs for expressions either.

(All the 

Re: SNOMEDCT - correct representation

[Michael.Lawley]

I think this thread has gone a little off the rails.

There are predefined (by FHIR) URIs for value sets that are defined just as 
descendants of a single concept, or members of a reference set.

For an enumeration of concepts and/or a snomed ECL expression, then you can use 
a Fhir ValueSet and give it a URI.  ValueSets also generalise beyond just 
SNOMED (LOINC for example).

Furthermore, there are existing tools to expand them to the set of member 
concepts, you can include metadata, manage versions etc.  This is much more 
than you get just by encoding ECL in a URI.

In case anyone wants to play with ECL expressions and their evaluation you can 
go here for an interactive page:
https://ontoserver.csiro.au/shrimp/ecl.html

Also, some brief documentation and click-through examples here
https://ontoserver.csiro.au/shrimp/ecl_help.html

Regards

Michael

Sent from my iPhone

On 3 May 2017, at 9:08 pm, Diego Bosc? 
> wrote:

Seems like the only way right now is creating refsets and referencing them with 
standard URIs...

2017-05-03 13:02 GMT+02:00 Bert Verhees 
>:
On 03-05-17 12:53, Thomas Beale wrote:
On 03/05/2017 11:40, Bert Verhees wrote:
On 03-05-17 12:36, Thomas Beale wrote:

The only missing part, now that I look at the SNOMED Compositional 
Grammar and Expression 
Constraint Language specs, 
is how to create a URI (which is the type of a term binding in 
ADL2)
 from a post-coordinated expression or constraint expression. This should be 
trivial, but I don't see where SNOMED has specified it.

True, I was looking for that also, a few days ago. I don't have time to read 
much now, but there is a document on the SNOMED site on URI's, maybe it is in 
there?
I can take a look later or look in my documentation, I have course materials. I 
come back to this tomorrow if not someone else already has.

The URI spec is 
here, 
but it doesn't address URIs for expressions either.

(All the SNOMED language specs appear to be 
here
 these days - nice and convenient, and also nicely published. We probably 
should go back to linking to them somewhere on the openEHR site).

I checked my course materials from last year, lucky I found it quickly, there 
is not any mentioning of URI's for expressions, so I guess it does not yet 
exist.

Stupid.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  


[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Bosc? Tom?s / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 / +34 
627015023
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 
verat...@veratech.es.

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

[Michael.Lawley]

Hi Koray, as I started to read your message I was thinking "why not re-use the 
terminology infrastructure already defined by FHIR", and then you proposed 
exactly that!

Big +1

There's a lot one can argue about with other parts of FHIR, but the terminology 
services part is self-contained and excellent.

Regards

Michael

Sent from my iPhone

On 3 May 2017, at 7:43 pm, Koray Atalag 
> wrote:

Hi again,

I’ve been snowed under for a while and just now catching up with this…I reckon 
there was a suggestion that we do not include SNOMED codes within archetypes, 
or more specifically post-coordinated expressions, if I understand correctly 
but to define these somewhere else and then include the external URI instead. 
While this would be a good solution for well-defined expressions, subsets etc. 
I think if you think about the vast amount of potential expressions with almost 
endless permutations of terms it quickly becomes too complex and unmanageable. 
Therefore there will always need for including specific expressions within 
archetypes and templates.

I’ve been doing a lot of terminology bindings using various ontologies and 
terminology lately and I think we need urgently a consistent way to make these 
bindings and get the tools support it. For example when term bindings (for the 
purpose of defining real-world meaning of a node) are done at archetype level 
you end up with local at codes that refer to each binding and then it is 
possible to link one or more terms from same or different terminology systems. 
For the purpose of providing a valueset to a DV_CODED_TEXT at archetype level 
we don’t have a very clear way – we keep on saying we’ll put a terminology 
query but it is not really usable or useful. Tooling support is also not 
satisfactory. But when you do that at template level (e.g. define a valueset 
for a DV_TEXT by further constraining it to DV_CODED_TEXT or an existing 
DV_CODED_TEXT) it is just a list of terms, code and terminology system with 
version/release. It is not clear how we can refer to an external list defined 
by a terminology query or refset – at least I couldn’t figure out. There’s 
quite an inconsistency between archetype vs template defined valuesets within 
.opt – whereas they should be defined in the same way and share same semantics.

I don’t know how to fix it – my guess is that this is not a commonly used 
feature so it was never a high priority for SEC group. I think it is time to 
bring loose ends together as more and more countries adopt SNOMED and there is 
clear pressure to do this.  FHIR terminology service is quite good and I think 
we should just start using it. If we need further bells and whistles it can be 
extended.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Koray Atalag
Sent: Tuesday, 2 May 2017 11:47 p.m.
To: For openEHR technical discussions
Subject: [FORGED] RE: SNOMEDCT - correct representation

Yup – that’s the right URI format.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 27 April 2017 1:01 a.m.
To: 
openehr-technical@lists.openehr.org
Subject: Re: SNOMEDCT - correct representation




In the new world of URIs representing SNOMED codes, this "SNOMED-CT" value for 
the terminology_id is understood as an openEHR-local (and maybe more widely 
agreed) namespace alias for the SNOMED CT namespace whose URI is 
http://snomed.info/sct (see 
http://doc.ihtsdo.org/download/doc_UriStandard_Current-en-US_INT_20140527.pdf).

Practically speaking this means that if other variants exist, e.g. 'snomed_ct', 
'SNOMED_CT' and so on, they can all be defined as aliases for SNOMED CT, in 
different contexts such as archetype tools, AQL queries and so on.

BTW, the ARchetype editor should generate URIs of this form for terminologies 
(from the ADL2 converted form of the CKM BP archetype):

term_bindings = <
["SNOMED-CT"] = <
["id1"] = 

["id5"] = 

["id6"] = 

["id14"] = 

>
["openehr"] = <
["at1055"] = 
["at1056"] = 
["at1057"] = 
>
>
- thomas
On 25/04/2017 07:03, Ian McNicoll wrote:
SNOMED-CT is the official designator, based on the archetype editor terminology 
list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
> wrote:

Re: SNOMEDCT - correct representation

[Michael.Lawley]

There is a spec that tells you how to identify different editions and versions 
of SNOMED CT - see http://snomed.org/uri

In short, http://snomed.info/sct is the identifier for any version of SNOMED 
CT.  for the Norway extension you need to know which module it is in (this is 
what will be used in the Module Dependency Reference Set for the Norway 
release) and then, if it was 12345668 for example, the identifier is 
http://snomed.info/sct/12345678

Michael

Sent from my iPhone

On 25 Apr 2017, at 5:52 pm, Diego Bosc? 
> wrote:

I think having this in a hardcoded terminology list is probably far from ideal 
(e.g. how do you put "snomed ct+norway national extension"? do we need an 
exhaustive listing of all possible extensions/versions?)

2017-04-25 8:03 GMT+02:00 Ian McNicoll 
>:
SNOMED-CT is the official designator, based on the archetype editor terminology 
list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
> wrote:
Congratulations about the new adoption!

The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our specs we 
are using SNOMED-CT as the name (it should be corrected to the name preferred 
by the IHTSDO). On an event they explicitly asked to avoid the SNOMED-CT with 
the hyphen when referencing the standard.

As for the term id, I've seen [snomed-ct::35917007 on the specs, or SNOMED-CT 
on sample archetypes: 
https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93=snomed=

Tested on the Ocean's archetype editor and they use:

constraint_bindings = <
["SNOMED-CT"] = <
items = <
["ac0001"] = 
>
>
>



On Mon, Apr 24, 2017 at 7:33 PM, Bj?rn Naess 
> wrote:
Norway just became a SNOMED country.
One simple question - what is the correct terminologyId to use for SNOMED-CT.

Currently we use 'SNOMEDCT' like below. Is this correct?

 
H?yre ?ye

  
SNOMEDCT
  
  18944008

  

Vennlig hilsen
Bj?rn Naess
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org



--
Ing. Pablo Pazos Guti?rrez
Cel:(00598) 99 043 145
Skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ian McNicoll

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  


[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Bosc? Tom?s / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 / +34 
627015023
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 
verat...@veratech.es.

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR and terminology servers

[Michael.Lawley]

I would argue the FHIR provides such an API. It also includes the SNOMED 
Expression Constraint Language (ECL) as part of the spec.  This is why we chose 
it as the basis I for our terminology server, Ontoserver, which is now the 
basis for Australia's National Clinical Terminology Service 
(www.healthterminologies.gov.au)

We also built a little UI to demonstrate use of ECL through FHIR at 
https://ontoserver.csiro.au/shrimp-fhir/ecl.html click on the help link for a 
range of simple and more complex query examples.

Michael

Sent from my iPhone

> On 4 Dec. 2016, at 7:58 pm, Ian McNicoll  wrote:
> 
> Hi Danial,
> 
> Very timely questions for us at Operon - we are working with
> terminology service providers to provide tight integration with
> openEHR services.
> 
> We definitely need to be able to expand valuesets in the context of
> an openEHR query
> 
> e.g Give me any patients with a problem/diagnosis of diabetes mellitus
> type 2 or children. i.e is_a relationships
> 
> We need to be able to channel this via AQL or other opeNEHR query languages.
> 
> We need to be able to manage and query over termsets/resultsets.
> 
> I'm not so sure about the need for more complex queries over other
> relationships / SNOMED concept model right now.
> 
> We definitely need some sort of vendor-agnostic API against which the
> majority of terminlogy service calls can be run. The FHIR service
> looks 'good enough' to me although I don't pretend to be an expert.
> 
> 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
> 
> 
>> On 2 December 2016 at 08:50, Daniel Karlsson  wrote:
>> Dear All,
>> 
>> while thinking about terminology server requirements for openEHR systems
>> I would like to ask all openEHR implementers about experiences of
>> different solutions. Are there any experiences of using openEHR systems
>> with e.g. the FHIR terminology services, CTS2, Ocean TQL, homebrew, etc?
>> What are the use cases when the terminology servers are used (e.g.
>> design time, data entry, querying, etc.)? What are the "terminological
>> queries" that are used/needed (e.g. subsumption testing, subset
>> membership, subset expansion, etc.)?
>> 
>> Thanks,
>> Daniel
>> 
>> --
>> 
>> Daniel Karlsson, PhD, sr lecturer
>> Department of Biomedical Engineering/Health informatics
>> Linköping university
>> SE-58185 Linköping
>> Sweden
>> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: More generic reference model

[Michael.Lawley]

Thanks Bert,


The difference between this one and the old one is that the old one was using 
our old terminology server through its proprietary APIs.


This new one is using generic FHIR APIs and can be pointed at an arbitrary FHIR 
Server that (correctly) implements the terminology services part of the FHIR 
spec >= 1.6.0


michael


--
Dr Michael Lawley
Principal Research Scientist
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical  on behalf 
of Bert Verhees 
Sent: Tuesday, 13 September 2016 2:49 PM
To: For openEHR technical discussions
Subject: Re: SV: More generic reference model


Hi Michael, I have seen it before a few months ago, a great tool. Very 
innovative. And easy to work with. I do not often see such a good work.

I will check it out today again, thanks for posting

Bert

Op 13 sep. 2016 01:00 schreef :
It is definitely possible - here's a pre-release version of our Shrimp browser 
using only FHIR APIs  http://ontoserver.csiro.au/shrimp??/

(Hope that Unicode works :-)

Michae

Sent from my iPhone

> On 13 Sep 2016, at 1:23 AM, Thomas Beale 
> > wrote:
>
> Bert,
>
> these are just selectors; what I mean is that in the generated result - the 
> actual value set - that IS-A relationships are returned as well as concept 
> codes. Without IS-A relationships a user can't navigate a value set larger 
> than a few terms in a useful way in a real system.
>
> - thomas
>
>> On 12/09/2016 10:23, Bert Verhees wrote:
>> Op 12-9-2016 om 10:30 schreef Thomas Beale:
>>> does the expansion preserve IS-A relationships (at least optionally)? 
>>> That's crucial for making any value set of more than about 20 terms usable 
>>> in a real system.
>>
>> I think you need to do that by additional refinements, f.e.
>>
>> < 19829001 |disorder of lung|: 116676008 |associated morphology| = 79654002 
>> |edema|
>>
>> or
>>
>> 19829001 |disorder of lung|: 116676008 |associated morphology| = 40829002 
>> |acute edema|
>>
>> or
>>
>> 19829001 |disorder of lung|: 116676008 |associated morphology| = 44132006 
>> |abscess|
>>
>>
>> Examples from: http://snomed.org/expressionconstraint
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: More generic reference model

[Michael.Lawley]

It is definitely possible - here's a pre-release version of our Shrimp browser 
using only FHIR APIs  http://ontoserver.csiro.au/shrimp/

(Hope that Unicode works :-)

Michae

Sent from my iPhone

> On 13 Sep 2016, at 1:23 AM, Thomas Beale  wrote:
> 
> Bert,
> 
> these are just selectors; what I mean is that in the generated result - the 
> actual value set - that IS-A relationships are returned as well as concept 
> codes. Without IS-A relationships a user can't navigate a value set larger 
> than a few terms in a useful way in a real system.
> 
> - thomas
> 
>> On 12/09/2016 10:23, Bert Verhees wrote:
>> Op 12-9-2016 om 10:30 schreef Thomas Beale:
>>> does the expansion preserve IS-A relationships (at least optionally)? 
>>> That's crucial for making any value set of more than about 20 terms usable 
>>> in a real system.
>> 
>> I think you need to do that by additional refinements, f.e.
>> 
>> < 19829001 |disorder of lung|: 116676008 |associated morphology| = 79654002 
>> |edema|
>> 
>> or
>> 
>> 19829001 |disorder of lung|: 116676008 |associated morphology| = 40829002 
>> |acute edema|
>> 
>> or
>> 
>> 19829001 |disorder of lung|: 116676008 |associated morphology| = 44132006 
>> |abscess|
>> 
>> 
>> Examples from: http://snomed.org/expressionconstraint
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[Michael.Lawley]

This is indeed the intent: the language has been design to cater exactly for 
this extension.  I can't say that there's any international content about to 
come out with this addition numeric modelling, but Australia has been 
publishing this kind of content in the Australian Medicines Terminology (AMT) 
since July 2014 (one release per month).

Michael

Sent from my iPhone

On 1 Oct 2015, at 6:43 PM, David Moner 
> wrote:

Hello,

At this point I think that is the only option. I want to believe that the 
SNOMED CT Expression Constraint Language has been designed with a future 
evolution of SNOMED CT in mind, where concepts will be enriched with numerical 
values. For example, SNOMED CT now contains a set of Virtual Medical Products 
(VMP) such as "[374649006] Amoxicillin 400mg/5mL suspension (product)" with two 
relationships:
- Has active ingredient →  Amoxicillin
- Has dose form →  Oral suspension
If these relationships are enriched with the medication strength, then the VMP 
concepts would be better defined and could be queried using the numerical 
options of the constraint language.


2015-09-30 9:20 GMT+02:00 Thomas Beale 
>:
On 30/09/2015 07:51, michael.law...@csiro.au 
wrote:
Imagine instead the example was using the corresponding AMT concepts (since 
snomed pure doesn't have any concrete domain modelling -- I.e. numeric values).

Then the focus concept would be the AMT amoxycillin Medicinal Product concept 
2141501136100 and the constraint matches would be MPUUs and TPUUs with 
capsule form and between 500 and 800 mg of amoxycillin as an active ingredient


ok - so the query would be applied to instances in a drug database (each 
instance there is a drug descriptor)?

- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[Michael.Lawley]

Imagine instead the example was using the corresponding AMT concepts (since 
snomed pure doesn't have any concrete domain modelling -- I.e. numeric values).

Then the focus concept would be the AMT amoxycillin Medicinal Product concept 
2141501136100 and the constraint matches would be MPUUs and TPUUs with 
capsule form and between 500 and 800 mg of amoxycillin as an active ingredient

Michael

Sent from my iPhone

On 30 Sep 2015, at 4:34 PM, Thomas Beale 
> 
wrote:


Hi Michael,

in that case, to what information base or DB could the amoxycillin query be 
applied? What is it for?

thanks

- thomas

On 29/09/2015 23:19, michael.law...@csiro.au 
wrote:
Hi Thomas,

These constraints are essentially queries over the snomed definitional content 
(ie the Relationships), not queries over external data (ie not EHRs).  The 
intent is to identify sets of snomed concepts that satisfy the constraint 
criteria. These sets could be subsequently used to join against/filter records 
in an EHR/EMR.

Work is ongoing for a full featured query language to address this larger 
problem, but the expression constraint language can be used to great effect 
when combined with SQL or other database tech to query health records.


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[Michael.Lawley]

Hi Thomas,

These constraints are essentially queries over the snomed definitional content 
(ie the Relationships), not queries over external data (ie not EHRs).  The 
intent is to identify sets of snomed concepts that satisfy the constraint 
criteria. These sets could be subsequently used to join against/filter records 
in an EHR/EMR.

Work is ongoing for a full featured query language to address this larger 
problem, but the expression constraint language can be used to great effect 
when combined with SQL or other database tech to query health records.

Michael

Sent from my iPhone

On 29 Sep 2015, at 11:11 PM, Thomas Beale 
> 
wrote:


The latest version of the SNOMED CT constraint language 
 proposes expressions like the 
following:

Section 6.3

To find those capsules  that have a strength between 500 and 800 mg 
(inclusive), the following expression  constraint  may be used:

<  27658006 |amoxicillin| :
46001 |has  dose form| = <<  385049006 | capsule|,
{ 15 |has basis of strength| =  ( 15 |amoxicillin only| :
15 |strength magnitude| >=  #500, 15 |strength magnitude| <= 
#800,
15 |strength unit| =  258684004 |mg|)}

The purpose of this is apparently as a query to find instances of Amoxycillin 
recorded somewhere - presumably in EHRs, or some kind of prescriptions 
database? However, the document talks of executing queries over a 'Substrate', 
defined as 'The SNOMED CT content over which an expression constraint is 
evaluated or a query is executed.'.

Elsewhere (p12) it says:

Please  note  that  the  substrate  over which  the  expression  constraint  is 
evaluated is  not  explicitly defined within the expression constraint, and 
must therefore be established by some other means. By  default,  the  assumed  
substrate  is the  set of  active  components  from  the  snapshot release  (in 
distribution normal form) of the SNOMED CT versioned edition currently loaded 
into the given tool.

It is also not clear what the query really means - is it a query for 
Amoxycillin that has been prescribed for a specific patient? For any patient in 
some cohort? Or for a medication order that has been suspended, postponed, or 
completed?

More generally, I am not clear how the one language is intended to be used 
across SNOMED CT itself (e.g. to generate intentional ref sets) and also across 
instance data. If it's the former, it can only be concept-based; if the latter, 
the query won't correspond to whatever information model is in use for the data.

How would it be used with data based on (for example) the openEHR medication 
item archetype in the UK clinical models 
CKM, shown below?




The recommendations in section 7.5 for executing the queries seem to imply that 
they are for evaluation against SNOMED CT.

There are various other oddities, but I'll leave them for later.

if anyone who is working with this can clarify, it would be most appreciated.

- thomas
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org