Re: SV: More generic reference model

[Bert Verhees]

I rewrote the part, I think it is easier to understand now. When someone 
will improve it, I am available to explain when something appears to be 
unclear.


https://openehr.atlassian.net/wiki/display/spec/Terminology+Querying+for+AQL


Op 13-9-2016 om 7:21 schreef Thomas Beale:



Can everyone who has concrete ideas on ways forward make an effort to 
update the wiki page 
 
we created for this, and/or add to the Questions facility 
for some of the useful 
peripheral questions that have been answered along the way.


The Specifications Editorial Committee will look at these issues in 
the near future, but some coherent material would be very helpful.


thanks

- thomas


On 12/09/2016 22:42, Bert Verhees wrote:


Even better, Pablo, it uses SCT, and does not stand in the way of 
other terminologies, it is a parallel process which fits inside the 
OpenEhr specs.


I tried to explain it before, maybe I did not well explain it. Tell 
me if so.


So, you can keep on proceeding as you were already doing, but you can 
add something which unlockes the SCT potential.


I explained it on my blog. Please comment on that, maybe you do not 
agree, if so, then I want to hear about that.


http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/





___
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 <openehr-technical-boun...@lists.openehr.org> on behalf 
of Bert Verhees <bert.verh...@rosa.nl>
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 <michael.law...@csiro.au>:
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 
> <thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> 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<mailto: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<mailto: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

[Bert Verhees]

I will give it a new try, I have explained it so much, I know where 
people stop to follow the explanation.


Op 13-9-2016 om 7:21 schreef Thomas Beale:



Can everyone who has concrete ideas on ways forward make an effort to 
update the wiki page 
 
we created for this, and/or add to the Questions facility 
for some of the useful 
peripheral questions that have been answered along the way.


The Specifications Editorial Committee will look at these issues in 
the near future, but some coherent material would be very helpful.


thanks

- thomas


On 12/09/2016 22:42, Bert Verhees wrote:


Even better, Pablo, it uses SCT, and does not stand in the way of 
other terminologies, it is a parallel process which fits inside the 
OpenEhr specs.


I tried to explain it before, maybe I did not well explain it. Tell 
me if so.


So, you can keep on proceeding as you were already doing, but you can 
add something which unlockes the SCT potential.


I explained it on my blog. Please comment on that, maybe you do not 
agree, if so, then I want to hear about that.


http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/





___
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

[Thomas Beale]

Michael,

Very nice tool, thanks for the link. One small comment - in a few places 
like where the SCT edition is chosen, something more human-readable than 
a concept code would be nice. Other than that, it's a very nice tool.


Can you give a quick idea on what the main intended eventual use is? 
Browsing by terminology authors? Browsing by users? Can it be used for 
ref-set perusal - i.e. where you choose 'SNOMED CT', would it one day be 
possible to load just a ref-set there? By ref-set I mean something 
structurally the same as SNOMED itself, with all relationships 
potentially, but just reduced content according to a ref-set def.


- thomas


On 12/09/2016 23:59, michael.law...@csiro.au wrote:

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


--

*Thomas Beale*
Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  Culture blog 




___
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

[Thomas Beale]

Grahame,

can you post a URL to that functionality / spec?

thanks

- thomas


On 12/09/2016 16:36, Grahame Grieve wrote:

yes. In our terminology, this is paging through an expansion

Grahame




___
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

[Thomas Beale]

Can everyone who has concrete ideas on ways forward make an effort to 
update the wiki page 
 
we created for this, and/or add to the Questions facility 
for some of the useful 
peripheral questions that have been answered along the way.


The Specifications Editorial Committee will look at these issues in the 
near future, but some coherent material would be very helpful.


thanks

- thomas


On 12/09/2016 22:42, Bert Verhees wrote:


Even better, Pablo, it uses SCT, and does not stand in the way of 
other terminologies, it is a parallel process which fits inside the 
OpenEhr specs.


I tried to explain it before, maybe I did not well explain it. Tell me 
if so.


So, you can keep on proceeding as you were already doing, but you can 
add something which unlockes the SCT potential.


I explained it on my blog. Please comment on that, maybe you do not 
agree, if so, then I want to hear about that.


http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/



___
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

[Bert Verhees]

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

[Shinji KOBAYASHI]

Dear Grahame,

I modeled ICF to an archetype for my ice bucket challenge, but forgot to
publish on CKM.
Do you need this?

Shinji Kobayashi

2016-09-12 23:37 GMT+09:00 Grahame Grieve <
grah...@healthintersections.com.au>:

> FHIR terminology servers can (and mostly do) handle all of those
> terminologies, though I don't know if anyone has handled ICF in practice.
>
> And expansions can preserve is-a relationships if you want, though... life
> is complicated and the answer is not automatically 'yes'
>
> Grahame
>
>
> On Mon, Sep 12, 2016 at 6:32 PM, Thomas Beale 
> wrote:
>
>>
>> we also still need a standard approach for non-SNOMED CT terminologies,
>> such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of
>> progress on this issue?
>>
>> - thomas
>>
>> On 12/09/2016 07:32, Diego Boscá wrote:
>>
>>> sure thing, that's why we need standard expressions
>>>
>>> 2016-09-12 8:27 GMT+02:00 Bert Verhees :
>>>
 Op 11-9-2016 om 20:32 schreef Diego Boscá:

> In practical terms however, you can't
> always expect to have all the access that you want to a given external
> service. e.g. I was banned from W3C once for launching a
> transformation (more like 10k...) that depended on a online schema.
>


>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> -
> http://www.healthintersections.com.au / grah...@healthintersections.com.au
> / +61 411 867 065
>
> ___
> 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: SV: More generic reference model

[Bert Verhees]

Even better, Pablo, it uses SCT, and does not stand in the way of other
terminologies, it is a parallel process which fits inside the OpenEhr specs.

I tried to explain it before, maybe I did not well explain it. Tell me if
so.

So, you can keep on proceeding as you were already doing, but you can add
something which unlockes the SCT potential.

I explained it on my blog. Please comment on that, maybe you do not agree,
if so, then I want to hear about that.

http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/

Op 12 sep. 2016 19:17 schreef "pablo pazos" <pazospa...@hotmail.com>:

> One solution would be to do everything on SCT and use mappings to the
> other terminologies (most are really classifications and have a much
> simpler internal structure).
>
>
> Sent from my LG Mobile
>
> -- Original message--
>
> *From: *Thomas Beale
>
> *Date: *Mon, Sep 12, 2016 05:33
>
> *To: *openehr-technical@lists.openehr.org;
>
> *Subject:*Re: SV: More generic reference model
>
> we also still need a standard approach for non-SNOMED CT terminologies, such 
> as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of 
> progress on this issue?- thomasOn 12/09/2016 07:32, Diego Boscá wrote:> sure 
> thing, that's why we need standard expressions>> 2016-09-12 8:27 GMT+02:00 
> Bert Verhees :>> Op 11-9-2016 om 20:32 schreef Diego Boscá:>>> In practical 
> terms however, you can't>>> always expect to have all the access that you 
> want to a given external>>> service. e.g. I was banned from W3C once for 
> launching a>>> transformation (more like 10k...) that depended on a online 
> schema.>>___openEHR-technical 
> mailing listopenEHR-technical@lists.openehr.orghtt 
> <+listopenEHR-technical@lists.openehr.orghtt>p://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

[Bert Verhees]

Thomas, from my phone, short. The Sct integration as I propose is optional.
No changes in openehr specs is needed. No software change is needed. It are
only additions except for two minor issues.

So if organization's do not want to use Sct, or are not allowed to use it,
they still can keep on using Openehr.  So you don't need to solve all those
mappings before integrating Sct. Organizations can start right now, I can
help, or another developer can help building the additional needed software
and the most beautiful,  an archetype editor based on SCT.

Op ma 12 sep. 2016 17:38 schreef Grahame Grieve <
grah...@healthintersections.com.au>:

> yes. In our terminology, this is paging through an expansion
>
> Grahame
>
>
> On Tue, Sep 13, 2016 at 1:34 AM, Thomas Beale 
> wrote:
>
>>
>> In other words something like a DB cursor to traverse large value sets
>> that reside on the server, in response to client (user) actions on the
>> screen? Has that been implemented in FHIR-land?
>>
>> - thomas
>>
>> On 12/09/2016 16:26, Grahame Grieve wrote:
>>
>>> The best way to resolve this is to make the terminology server part of
>>> the local system, and have the resolution a dynamic one between the
>>> systems. That allows you to optimise the performance implications of large
>>> value sets.
>>>
>>> Grahame
>>>
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
>
> --
> -
> http://www.healthintersections.com.au / grah...@healthintersections.com.au
> / +61 411 867 065
> ___
> 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

[Grahame Grieve]

yes. In our terminology, this is paging through an expansion

Grahame


On Tue, Sep 13, 2016 at 1:34 AM, Thomas Beale 
wrote:

>
> In other words something like a DB cursor to traverse large value sets
> that reside on the server, in response to client (user) actions on the
> screen? Has that been implemented in FHIR-land?
>
> - thomas
>
> On 12/09/2016 16:26, Grahame Grieve wrote:
>
>> The best way to resolve this is to make the terminology server part of
>> the local system, and have the resolution a dynamic one between the
>> systems. That allows you to optimise the performance implications of large
>> value sets.
>>
>> Grahame
>>
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
___
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

[Thomas Beale]

In other words something like a DB cursor to traverse large value sets 
that reside on the server, in response to client (user) actions on the 
screen? Has that been implemented in FHIR-land?


- thomas

On 12/09/2016 16:26, Grahame Grieve wrote:
The best way to resolve this is to make the terminology server part of 
the local system, and have the resolution a dynamic one between the 
systems. That allows you to optimise the performance implications of 
large value sets.


Grahame




___
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

[Thomas Beale]

On 12/09/2016 07:25, Bert Verhees wrote:

Op 11-9-2016 om 20:21 schreef Thomas Beale:
Not an unreasonable point of view, but it sort of implies that there 
are / will be no well-known / reliable terminology value sets out 
there - only specific value sets inside specific terminology services.


This problem hads been tackled by IHTSDO. They never allow a concept 
to disappear, and all members should install the latest updates. There 
is a lot of thought inside SCT about versioning.


indeed there is. But what I am talking about here is not whether Snomed 
value sets can be versioned but the non-technical question of whether 
specific, well-known value sets can be established globally, regardless 
of specific terminology servers etc and whether they can then be relied 
on globally to exist in the same way a specific concept code is assumed 
to exist. Specific value sets (generally large ones) have been defined 
on Snomed CT, what I am thinking about is a fast, efficient mechanism 
for creating curating and publishing any value set, of which thousands 
will be needed, or whether each health organisation will end up 
replicating this work and creating similar / same private value sets 
with different identifiers.


It may be that this is an argument for sharing value set definitions 
(i.e. the constraint expressions) within AQL queries and archetypes as 
being a way to do this.


- thomas


___
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

[Grahame Grieve]

The best way to resolve this is to make the terminology server part of the
local system, and have the resolution a dynamic one between the systems.
That allows you to optimise the performance implications of large value
sets.

Grahame


On Tue, Sep 13, 2016 at 1:21 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
>



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
___
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

[Thomas Beale]

On 12/09/2016 10:27, Bert Verhees wrote:

Op 12-9-2016 om 10:32 schreef Thomas Beale:


we also still need a standard approach for non-SNOMED CT 
terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... 
does anyone know of progress on this issue?

There is a detailed answer, I googled on SNOMED to ICD10
https://www.nlm.nih.gov/research/umls/mapping_projects/snomedct_to_icd10cm.html 



I think others on this list are better informed to answer this question 


I am aware of the SNOMED / ICD10 mapping project, but it's not directly 
helpful to all the routine users of ICDx (many variants, not just 
ICD10), who use it on its own and will do so for years.


- thomas

___
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

[Thomas Beale]

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

Re: SV: More generic reference model

[Grahame Grieve]

FHIR terminology servers can (and mostly do) handle all of those
terminologies, though I don't know if anyone has handled ICF in practice.

And expansions can preserve is-a relationships if you want, though... life
is complicated and the answer is not automatically 'yes'

Grahame


On Mon, Sep 12, 2016 at 6:32 PM, Thomas Beale 
wrote:

>
> we also still need a standard approach for non-SNOMED CT terminologies,
> such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of
> progress on this issue?
>
> - thomas
>
> On 12/09/2016 07:32, Diego Boscá wrote:
>
>> sure thing, that's why we need standard expressions
>>
>> 2016-09-12 8:27 GMT+02:00 Bert Verhees :
>>
>>> Op 11-9-2016 om 20:32 schreef Diego Boscá:
>>>
 In practical terms however, you can't
 always expect to have all the access that you want to a given external
 service. e.g. I was banned from W3C once for launching a
 transformation (more like 10k...) that depended on a online schema.

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



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
___
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

[Bert Verhees]

Op 12-9-2016 om 10:32 schreef Thomas Beale:


we also still need a standard approach for non-SNOMED CT 
terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... 
does anyone know of progress on this issue?

There is a detailed answer, I googled on SNOMED to ICD10
https://www.nlm.nih.gov/research/umls/mapping_projects/snomedct_to_icd10cm.html

I think others on this list are better informed to answer this question

___
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

[Bert Verhees]

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

Re: SV: More generic reference model

[Thomas Beale]

we also still need a standard approach for non-SNOMED CT terminologies, 
such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know 
of progress on this issue?


- thomas

On 12/09/2016 07:32, Diego Boscá wrote:

sure thing, that's why we need standard expressions

2016-09-12 8:27 GMT+02:00 Bert Verhees :

Op 11-9-2016 om 20:32 schreef Diego Boscá:

In practical terms however, you can't
always expect to have all the access that you want to a given external
service. e.g. I was banned from W3C once for launching a
transformation (more like 10k...) that depended on a online schema.





___
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

[Thomas Beale]

On 12/09/2016 07:01, michael.law...@csiro.au wrote:

I strongly recommend looking at the way terminology services are handled in 
FHIR.

A ValueSet Resource (ie the subsets you're talking about) has a URI, so that it 
can be replicated in a local TS and referenced by it's well-known identifier 
rather than just a URL.  It has a definition (which may be an explicit list of 
codes, or based on filters (ie rules) - for SNOMED CT you can use the 
Expression Constraint Language), and it also has an expansion - the enumeration 
of the codes that satisfy the definition with respect to a particular version 
of the underlying code system.


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.


- thomas


___
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

[Diego Boscá]

My comments were on the discussion 'expressions vs queries to external
terminology services in archetypes'

2016-09-12 8:40 GMT+02:00 Bert Verhees :
> Op 12-9-2016 om 8:32 schreef Diego Boscá:
>>
>> sure thing, that's why we need standard expressions
>
>
> Maybe I don't understand your point. But what I make of it, is that you are
> referring to the ever lasting discussion about a standardset of archetypes,
> or every medical institution making its own.
> SCT can maybe also solve this point, when every archetype has a post
> coordinated expression in it which represents the archetype, all information
> will be machine processable/understandable.
>
> At least, that is the way SCT wants to go, I cannot judge in how far this
> succeeds, but it succeeds better then OpenEHR does without SCT, I think.
>
>
>>
>> 2016-09-12 8:27 GMT+02:00 Bert Verhees :
>>>
>>> Op 11-9-2016 om 20:32 schreef Diego Boscá:

 In practical terms however, you can't
 always expect to have all the access that you want to a given external
 service. e.g. I was banned from W3C once for launching a
 transformation (more like 10k...) that depended on a online schema.
>>>
>>>
>>> A hospital can run its own SCT service (in member countries, this is
>>> free),
>>> and a hospital which has a large network problem is in big problems,
>>> independent from the fact if it uses SCT.
>>>
>>>
>>>
>>> ___
>>> 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

___
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

[Bert Verhees]

Op 12-9-2016 om 8:32 schreef Diego Boscá:

sure thing, that's why we need standard expressions


Maybe I don't understand your point. But what I make of it, is that you 
are referring to the ever lasting discussion about a standardset of 
archetypes, or every medical institution making its own.
SCT can maybe also solve this point, when every archetype has a post 
coordinated expression in it which represents the archetype, all 
information will be machine processable/understandable.


At least, that is the way SCT wants to go, I cannot judge in how far 
this succeeds, but it succeeds better then OpenEHR does without SCT, I 
think.




2016-09-12 8:27 GMT+02:00 Bert Verhees :

Op 11-9-2016 om 20:32 schreef Diego Boscá:

In practical terms however, you can't
always expect to have all the access that you want to a given external
service. e.g. I was banned from W3C once for launching a
transformation (more like 10k...) that depended on a online schema.


A hospital can run its own SCT service (in member countries, this is free),
and a hospital which has a large network problem is in big problems,
independent from the fact if it uses SCT.



___
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

[Bert Verhees]

Exactly Michael, that is what I was pointing at in my blogs a few days 
ago, making a golden pair of SCT and OpenEHR by combining the full 
potential of both.
Even go further then FHIR, because FHIR is a message system, while 
OpenEHR is so much more then that. OpenEHR is the base of an application 
generator.


Op 12-9-2016 om 8:01 schreef michael.law...@csiro.au:

I strongly recommend looking at the way terminology services are handled in 
FHIR.

A ValueSet Resource (ie the subsets you're talking about) has a URI, so that it 
can be replicated in a local TS and referenced by it's well-known identifier 
rather than just a URL.  It has a definition (which may be an explicit list of 
codes, or based on filters (ie rules) - for SNOMED CT you can use the 
Expression Constraint Language), and it also has an expansion - the enumeration 
of the codes that satisfy the definition with respect to a particular version 
of the underlying code system.

There are operations like $subsumes to test the relationship between two codes, 
and $closure to incrementally build up a subsumption graph in the client for 
subsets of codes (those actually in the patient records) to support efficient 
query.  For SNOMED CT, a 'code' may be a single SCTID or a post coordinated 
expression.

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 <openehr-technical-boun...@lists.openehr.org> on behalf of 
Diego Boscá <yamp...@gmail.com>
Sent: Monday, 12 September 2016 4:32 AM
To: For openEHR technical discussions
Subject: Re: SV: More generic reference model

I mean, I can see that there can be valid queries to known terminology
services, I'm not against that. In practical terms however, you can't
always expect to have all the access that you want to a given external
service. e.g. I was banned from W3C once for launching a
transformation (more like 10k...) that depended on a online schema. I
can imagine that could even be worse for terminology services
(downtimes and maintenance aside).

That's why I said standard (explicit?) expression definitions should
be preferred when available

2016-09-11 20:21 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>:

Not an unreasonable point of view, but it sort of implies that there are /
will be no well-known / reliable terminology value sets out there - only
specific value sets inside specific terminology services.


On 11/09/2016 19:10, Diego Boscá wrote:

The problem I see with depending on a given terminology service is
that the code you are defining may or may not be known by the
terminology service. This could be ok for templates, but not for
archetypes. In my opinion generic archetypes should be based on known
syntaxes rather than in specific queries to terminology services
whenever is possible




___
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




___
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

[Diego Boscá]

code subsets are important in data validation or query part, I would
say not so much in semantic label definition

2016-09-12 8:23 GMT+02:00 Bert Verhees :
> Op 11-9-2016 om 20:10 schreef Diego Boscá:
>>
>> The problem I see with depending on a given terminology service is
>> that the code you are defining may or may not be known by the
>> terminology service.
>
> I don't see that happen easily. Validate your archetypes on content also
> before using them.
>
>
> ___
> 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

[Bert Verhees]

Op 11-9-2016 om 20:32 schreef Diego Boscá:

In practical terms however, you can't
always expect to have all the access that you want to a given external
service. e.g. I was banned from W3C once for launching a
transformation (more like 10k...) that depended on a online schema.


A hospital can run its own SCT service (in member countries, this is 
free), and a hospital which has a large network problem is in big 
problems, independent from the fact if it uses SCT.



___
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

[Bert Verhees]

Op 11-9-2016 om 20:21 schreef Thomas Beale:
Not an unreasonable point of view, but it sort of implies that there 
are / will be no well-known / reliable terminology value sets out 
there - only specific value sets inside specific terminology services.


This problem hads been tackled by IHTSDO. They never allow a concept to 
disappear, and all members should install the latest updates. There is a 
lot of thought inside SCT about versioning.






On 11/09/2016 19:10, Diego Boscá wrote:

The problem I see with depending on a given terminology service is
that the code you are defining may or may not be known by the
terminology service. This could be ok for templates, but not for
archetypes. In my opinion generic archetypes should be based on known
syntaxes rather than in specific queries to terminology services
whenever is possible





___
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

[Bert Verhees]

Op 11-9-2016 om 20:10 schreef Diego Boscá:

The problem I see with depending on a given terminology service is
that the code you are defining may or may not be known by the
terminology service.
I don't see that happen easily. Validate your archetypes on content also 
before using them.


___
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

[Bert Verhees]

Op 11-9-2016 om 20:01 schreef Thomas Beale:




On 11/09/2016 15:48, pablo pazos wrote:


Hi Bert,


I was thinking about integrating SCT with path-based queries (I'm not 
in AQL yet), but maintaining the complexity of the SCT relationships 
and expressions on the terminology service (TS) side, so on queries 
there are just simple codes (specific concept ids, subsets or 
expressions identified just by one code). Then when evaluating a 
query, with the TS we can get all the terms and concept ids that 
match all the is_a relationships or subsets of expressions. I talked 
with several TS providers and hopefully we can build an integration 
next year to create and evaluate queries with SCT.



What I'm saying is that I prefer to delegate the complexity of SCT to 
the TS and create simpler queries in AQL or path-based queries, but 
your idea is interesting. One problem though is that query creators 
need to be experts in SCT.





this is also a real issue - and one that has no clear answer that I 
know of...


About the experts,

I remember when my kids were 4 years old (twins) in the swimmingpool (it 
must have been 2003 or so), I had printed out the OpenEHR documents, 
must have been a few hundreds pages hard the grasp text, reading under 
the sunny sky with sunglasses, a lot of noise of yelling kids around me. 
I never regretted doing that. It paid my bills for 10 years or so.


I imagine someone studying SCT query techniques in a similar situation 
now, and having all the technical advantages, like a tablet and Wifi in 
the swimmingpool. One will never regret studying SCT.








- 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

Re: SV: More generic reference model

[Bert Verhees]

Op 11-9-2016 om 16:56 schreef Diego Boscá:


I'm not a real fan of having just codes instead of expressions. 
Expressions are far more readable and may help in the understanding of 
the archetype. Just a single code representing the subset won't be as 
clear.




Diego, I think you are right, a golden developers rule is it write 
readable code. The time of mnemonics is of the buggy past.


___
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

[pablo pazos]

I understand the point,  and it makes perfect sense talking about a general 
solution.


But it also depends on the scope. Consider a nationwide project where 
terminologies are defined and subsets / expressions can be defined in a 
controlled way. In this context my approach would not be a problem. Even   if 
local codes are defined, those can be post coordinated / harmonized, and only 
those codes can be part of queries (I can imagine such rule in a real 
situation, maybe as part of a querying guideline).


Without considering context and scope, this is a thought problem to solve in a 
general way, but with each conversation we get closer to a solution, this is a 
great exercise.


Sent from my LG Mobile

-- Original message--

From: Diego Boscá

Date: Sun, Sep 11, 2016 15:33

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

I mean, I can see that there can be valid queries to known terminologyservices, 
I'm not against that. In practical terms however, you can'talways expect to 
have all the access that you want to a given externalservice. e.g. I was banned 
from W3C once for launching atransformation (more like 10k...) that depended on 
a online schema. Ican imagine that could even be worse for terminology 
services(downtimes and maintenance aside).That's why I said standard 
(explicit?) expression definitions shouldbe preferred when available2016-09-11 
20<tel:2016-09-11%2020>:21 GMT+02:00 Thomas Beale :> Not an unreasonable point 
of view, but it sort of implies that there are /> will be no well-known / 
reliable terminology value sets out there - only> specific value sets inside 
specific terminology services.>>> On 11/09/2016 19:10, Diego Boscá wrote:>>>> 
The problem I see with depending on a given terminology service is>> that the 
code you are defining may or may not be known by the>> terminology service. 
This could be ok for templates, but not for>> archetypes. In my opinion generic 
archetypes should be based on known>> syntaxes rather than in specific queries 
to terminology services>> whenever is possible>>>>>> 
___> openEHR-technical mailing 
list> 
openEHR-technical@lists.openehr.org<mailto:%20openehr-techni...@lists.openehr.org>>
 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org___openEHR-technical
 mailing 
listopenEHR-technical@lists.openehr.orghtt<mailto:%20listopenEHR-technical@lists.openehr.orghtt>p://lists.openehr.org/mailman/listinfo/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

[Diego Boscá]

I mean, I can see that there can be valid queries to known terminology
services, I'm not against that. In practical terms however, you can't
always expect to have all the access that you want to a given external
service. e.g. I was banned from W3C once for launching a
transformation (more like 10k...) that depended on a online schema. I
can imagine that could even be worse for terminology services
(downtimes and maintenance aside).

That's why I said standard (explicit?) expression definitions should
be preferred when available

2016-09-11 20:21 GMT+02:00 Thomas Beale :
> Not an unreasonable point of view, but it sort of implies that there are /
> will be no well-known / reliable terminology value sets out there - only
> specific value sets inside specific terminology services.
>
>
> On 11/09/2016 19:10, Diego Boscá wrote:
>>
>> The problem I see with depending on a given terminology service is
>> that the code you are defining may or may not be known by the
>> terminology service. This could be ok for templates, but not for
>> archetypes. In my opinion generic archetypes should be based on known
>> syntaxes rather than in specific queries to terminology services
>> whenever is possible
>>
>
>
>
> ___
> 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

[Thomas Beale]

Not an unreasonable point of view, but it sort of implies that there are 
/ will be no well-known / reliable terminology value sets out there - 
only specific value sets inside specific terminology services.



On 11/09/2016 19:10, Diego Boscá wrote:

The problem I see with depending on a given terminology service is
that the code you are defining may or may not be known by the
terminology service. This could be ok for templates, but not for
archetypes. In my opinion generic archetypes should be based on known
syntaxes rather than in specific queries to terminology services
whenever is possible





___
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

[Diego Boscá]

The problem I see with depending on a given terminology service is
that the code you are defining may or may not be known by the
terminology service. This could be ok for templates, but not for
archetypes. In my opinion generic archetypes should be based on known
syntaxes rather than in specific queries to terminology services
whenever is possible

2016-09-11 20:00 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>:
>
>
> On 11/09/2016 18:44, pablo pazos wrote:
>
> IMHO the clearness of the query should not depend on the AQL code, but the
> metadata associated with the query, like the ADL header and ontology, the
> AQL would be the "definition" of the query. To share queries between systems
> the AQL is not enough. We need a declaration of intent, purpose, use,
> misuse, etc and description of the query in natural language.
>
>
> exactly right - 'query libraries' and 'query sets', with all that
> meta-description. I thought we would be closer to that today than we are to
> be honest. In any case, it's key for creating proper query sets which are
> what we need to make CDS modules.
>
>
> Also, to manage queries we need something like the CKM and an editor.  Good
> AQL should not rely only on clearness and readability, but on specifying
> exactly what results we need.
>
>
> I think both options are valid: SCT expressions and just codes in AQL, but
> since I'm not an expert in SCT, I prefer someone else that knows SCT defines
> the expressions and relationships in the terminology server so I can create
> queries just using codes.
>
>
> Sent from my LG Mobile
>
> -- Original message--
>
> From: Diego Boscá
>
> Date: Sun, Sep 11, 2016 11:57
>
> To: For openEHR technical discussions;
>
> Subject:Re: SV: More generic reference model
>
> I'm not a real fan of having just codes instead of expressions.. Expressions
> are far more readable and may help in the understanding of the archetype.
> Just a single code representing the subset won't be as clear.
>
>
>
> what would you do when you want to query against a well-known ref-set that
> is already defined and living in a terminology server? Try to recreate the
> definition to put in the query? I'm not sure this is a great idea, but on
> the other hand you might say: how can you trust the ref set definition to
> always be associated with that code? Or even: how do we know the query
> author really understands the ref-set?
>
> I don't think we have a proper theory on the query/terminology interface
> with respect to such issues...
>
> - 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

Re: SV: More generic reference model

[Thomas Beale]

On 11/09/2016 15:48, pablo pazos wrote:


Hi Bert,


I was thinking about integrating SCT with path-based queries (I'm not 
in AQL yet), but maintaining the complexity of the SCT relationships 
and expressions on the terminology service (TS) side, so on queries 
there are just simple codes (specific concept ids, subsets or 
expressions identified just by one code). Then when evaluating a 
query, with the TS we can get all the terms and concept ids that match 
all the is_a relationships or subsets of expressions. I talked with 
several TS providers and hopefully we can build an integration next 
year to create and evaluate queries with SCT.



What I'm saying is that I prefer to delegate the complexity of SCT to 
the TS and create simpler queries in AQL or path-based queries, but 
your idea is interesting. One problem though is that query creators 
need to be experts in SCT.





this is also a real issue - and one that has no clear answer that I know 
of...


- thomas

___
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

[Thomas Beale]

On 11/09/2016 18:44, pablo pazos wrote:


IMHO the clearness of the query should not depend on the AQL code, but 
the metadata associated with the query, like the ADL header and 
ontology, the AQL would be the "definition" of the query. To share 
queries between systems the AQL is not enough. We need a declaration 
of intent, purpose, use, misuse, etc and description of the query in 
natural language.




exactly right - 'query libraries' and 'query sets', with all that 
meta-description. I thought we would be closer to that today than we are 
to be honest. In any case, it's key for creating proper query sets which 
are what we need to make CDS modules.




Also, to manage queries we need something like the CKM and an editor. 
 Good AQL should not rely only on clearness and readability, but on 
specifying exactly what results we need.



I think both options are valid: SCT expressions and just codes in AQL, 
but since I'm not an expert in SCT, I prefer someone else that knows 
SCT defines the expressions and relationships in the terminology 
server so I can create queries just using codes.



Sent from my LG Mobile

-- Original message--

*From: *Diego Boscá

*Date: *Sun, Sep 11, 2016 11:57

*To: *For openEHR technical discussions;

*Subject:*Re: SV: More generic reference model

I'm not a real fan of having just codes instead of expressions.. 
Expressions are far more readable and may help in the understanding of 
the archetype. Just a single code representing the subset won't be as 
clear.





what would you do when you want to query against a well-known ref-set 
that is already defined and living in a terminology server? Try to 
recreate the definition to put in the query? I'm not sure this is a 
great idea, but on the other hand you might say: how can you trust the 
ref set definition to always be associated with that code? Or even: how 
do we know the query author really understands the ref-set?


I don't think we have a proper theory on the query/terminology interface 
with respect to such issues...


- thomas

___
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

[Diego Boscá]

Didn't say otherwise, just that expressions should be preferable ;D

2016-09-11 19:15 GMT+02:00 Ian McNicoll <i...@freshehr.com>:

> Hi Diego,
>
> We really need both as many real-world SNOMED-CT subsets do not align to
> particular hierarchies or expressions.
>
> 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 11 September 2016 at 15:56, Diego Boscá <yamp...@gmail.com> wrote:
>
>> I'm not a real fan of having just codes instead of expressions.
>> Expressions are far more readable and may help in the understanding of the
>> archetype. Just a single code representing the subset won't be as clear.
>>
>> El 11/9/2016 16:49, "pablo pazos" <pazospa...@hotmail.com> escribió:
>>
>>> Hi Bert,
>>>
>>>
>>> I was thinking about integrating SCT with path-based queries (I'm not in
>>> AQL yet), but maintaining the complexity of the SCT relationships and
>>> expressions on the terminology service (TS) side, so on queries there are
>>> just simple codes (specific concept ids, subsets or expressions identified
>>> just by one code). Then when evaluating a query, with the TS we can get all
>>> the terms and concept ids that match all the is_a relationships or subsets
>>> of expressions. I talked with several TS providers and hopefully we can
>>> build an integration next year to create and evaluate queries with SCT.
>>>
>>>
>>> What I'm saying is that I prefer to delegate the complexity of SCT to
>>> the TS and create simpler queries in AQL or path-based queries, but your
>>> idea is interesting. One problem though is that query creators need to be
>>> experts in SCT.
>>>
>>>
>>> What do you think?
>>>
>>>
>>> Sent from my LG Mobile
>>>
>>> -- Original message--
>>>
>>> *From: *Bert Verhees
>>>
>>> *Date: *Sat, Sep 10, 2016 13:14
>>>
>>> *To: *For openEHR technical discussions;
>>>
>>> *Subject:*Re: SV: More generic reference model
>>>
>>> Hi Pablo, sorry I was bit slow with thinking through my plans. The way I
>>> see it now, there is no change necessary in the reference model to
>>> integrate the potential of SCT largely. Even you can keep on using the
>>> semantic rich entry types like Observation, etc.
>>>
>>> See my post in my blog.
>>> http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-ex
>>> pression-constraints-openehr-aql/
>>>
>>> If you, however, limit yourself to the Generic entry type, which even
>>> gives a better integration while keeping all OpenEhr functinality alive.
>>>
>>> http://www.bertverhees.nl/archetypes/snomed-ct-expression-co
>>> nstraints-openehr-aql-part-2/
>>>
>>> I am interested in what you think about that.
>>>
>>> Best regards
>>> Bert Verhees
>>>
>>> Op 10 sep. 2016 05:03 schreef "pablo pazos" <pazospa...@hotmail.com>:
>>>
>>>> Hi all,
>>>>
>>>>
>>>> Regarding the genericity of the openEHR IM, from the implementation
>>>> point of view we have at least 3 models:
>>>>
>>>>
>>>> + the implementation information model
>>>>
>>>> + the persistence information model
>>>>
>>>> + and the reference / canonic information model (the openEHR IM)
>>>>
>>>>
>>>> Others might have more than these 3 models on their openEHR
>>>> implementations.
>>>>
>>>>
>>>> I think some simplifications can still be done to the openEHR IM
>>>> without losing semantics, like removing ITEM_STRUCTURE and using just
>>>> CLUSTER/ELEMENT (we have a discussion about this on the wiki started some
>>>> years ago).
>>>>
>>>>
>>>> IMO we should not try to make the reference model simpler just in sake
>>>> of simplifying the implementation, since the other 2 models are for that.
>>>> In my systems I have different implementation models that are over
>>>> simplified openEHR IM implementations, and also very specific / optimized /
>>>> gene

Re: SV: More generic reference model

[pablo pazos]

IMHO the clearness of the query should not depend on the AQL code, but the 
metadata associated with the query, like the ADL header and ontology, the AQL 
would be the "definition" of the query. To share queries between systems the 
AQL is not enough. We need a declaration of intent, purpose, use, misuse, etc 
and description of the query in natural language.


Also, to manage queries we need something like the CKM and an editor.  Good AQL 
should not rely only on clearness and readability, but on specifying exactly 
what results we need.


I think both options are valid: SCT expressions and just codes in AQL, but 
since I'm not an expert in SCT, I prefer someone else that knows SCT defines 
the expressions and relationships in the terminology server so I can create 
queries just using codes.


Sent from my LG Mobile

-- Original message--

From: Diego Boscá

Date: Sun, Sep 11, 2016 11:57

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

I'm not a real fan of having just codes instead of expressions.. Expressions 
are far more readable and may help in the understanding of the archetype. Just 
a single code representing the subset won't be as clear.

El 11/9/2016 16:49, "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>> escribió:

Hi Bert,


I was thinking about integrating SCT with path-based queries (I'm not in AQL 
yet), but maintaining the complexity of the SCT relationships and expressions 
on the terminology service (TS) side, so on queries there are just simple codes 
(specific concept ids, subsets or expressions identified just by one code). 
Then when evaluating a query, with the TS we can get all the terms and concept 
ids that match all the is_a relationships or subsets of expressions. I talked 
with several TS providers and hopefully we can build an integration next year 
to create and evaluate queries with SCT.


What I'm saying is that I prefer to delegate the complexity of SCT to the TS 
and create simpler queries in AQL or path-based queries, but your idea is 
interesting. One problem though is that query creators need to be experts in 
SCT.


What do you think?


Sent from my LG Mobile

-- Original message--

From: Bert Verhees

Date: Sat, Sep 10, 2016 13:14

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

Hi Pablo, sorry I was bit slow with thinking through my plans. The way I see it 
now, there is no change necessary in the reference model to integrate the 
potential of SCT largely. Even you can keep on using the semantic rich entry 
types like Observation, etc.

See my post in my blog.
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

If you, however, limit yourself to the Generic entry type, which even gives a 
better integration while keeping all OpenEhr functinality alive.

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/

I am interested in what you think about that.

Best regards
Bert Verhees

Op 10 sep. 2016 05:03 schreef "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>>:

Hi all,


Regarding the genericity of the openEHR IM, from the implementation point of 
view we have at least 3 models:


+ the implementation information model

+ the persistence information model

+ and the reference / canonic information model (the openEHR IM)


Others might have more than these 3 models on their openEHR implementations.


I think some simplifications can still be done to the openEHR IM without losing 
semantics, like removing ITEM_STRUCTURE and using just CLUSTER/ELEMENT (we have 
a discussion about this on the wiki started some years ago).


IMO we should not try to make the reference model simpler just in sake of 
simplifying the implementation, since the other 2 models are for that. In my 
systems I have different implementation models that are over simplified openEHR 
IM implementations, and also very specific / optimized / generic persistence 
information models compatible with the openEHR IM. And I think the 
implementation / persistence models are the ones we can simplify and adjust to 
our needs, but not the reference model, since it's role is that: be the 
reference for all implementations.



--
Kind regards,
Eng. Pablo Pazos Guti??rrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>>
Sent: Friday, September 9, 2016 4:15:53 AM
To: For openEHR technical discussions
Subject: SV: SV: More generic reference model

Hi,

A related activity that might be useful to know is the “RFP for LOINC - SNOMED 
CT Cooperation 
Proje

Re: SV: More generic reference model

[Ian McNicoll]

Hi Diego,

We really need both as many real-world SNOMED-CT subsets do not align to
particular hierarchies or expressions.

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 11 September 2016 at 15:56, Diego Boscá <yamp...@gmail.com> wrote:

> I'm not a real fan of having just codes instead of expressions.
> Expressions are far more readable and may help in the understanding of the
> archetype. Just a single code representing the subset won't be as clear.
>
> El 11/9/2016 16:49, "pablo pazos" <pazospa...@hotmail.com> escribió:
>
>> Hi Bert,
>>
>>
>> I was thinking about integrating SCT with path-based queries (I'm not in
>> AQL yet), but maintaining the complexity of the SCT relationships and
>> expressions on the terminology service (TS) side, so on queries there are
>> just simple codes (specific concept ids, subsets or expressions identified
>> just by one code). Then when evaluating a query, with the TS we can get all
>> the terms and concept ids that match all the is_a relationships or subsets
>> of expressions. I talked with several TS providers and hopefully we can
>> build an integration next year to create and evaluate queries with SCT.
>>
>>
>> What I'm saying is that I prefer to delegate the complexity of SCT to the
>> TS and create simpler queries in AQL or path-based queries, but your idea
>> is interesting. One problem though is that query creators need to be
>> experts in SCT.
>>
>>
>> What do you think?
>>
>>
>> Sent from my LG Mobile
>>
>> -- Original message--
>>
>> *From: *Bert Verhees
>>
>> *Date: *Sat, Sep 10, 2016 13:14
>>
>> *To: *For openEHR technical discussions;
>>
>> *Subject:*Re: SV: More generic reference model
>>
>> Hi Pablo, sorry I was bit slow with thinking through my plans. The way I
>> see it now, there is no change necessary in the reference model to
>> integrate the potential of SCT largely. Even you can keep on using the
>> semantic rich entry types like Observation, etc.
>>
>> See my post in my blog.
>> http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-
>> expression-constraints-openehr-aql/
>>
>> If you, however, limit yourself to the Generic entry type, which even
>> gives a better integration while keeping all OpenEhr functinality alive.
>>
>> http://www.bertverhees.nl/archetypes/snomed-ct-expression-
>> constraints-openehr-aql-part-2/
>>
>> I am interested in what you think about that.
>>
>> Best regards
>> Bert Verhees
>>
>> Op 10 sep. 2016 05:03 schreef "pablo pazos" <pazospa...@hotmail.com>:
>>
>>> Hi all,
>>>
>>>
>>> Regarding the genericity of the openEHR IM, from the implementation
>>> point of view we have at least 3 models:
>>>
>>>
>>> + the implementation information model
>>>
>>> + the persistence information model
>>>
>>> + and the reference / canonic information model (the openEHR IM)
>>>
>>>
>>> Others might have more than these 3 models on their openEHR
>>> implementations.
>>>
>>>
>>> I think some simplifications can still be done to the openEHR IM without
>>> losing semantics, like removing ITEM_STRUCTURE and using just
>>> CLUSTER/ELEMENT (we have a discussion about this on the wiki started some
>>> years ago).
>>>
>>>
>>> IMO we should not try to make the reference model simpler just in sake
>>> of simplifying the implementation, since the other 2 models are for that.
>>> In my systems I have different implementation models that are over
>>> simplified openEHR IM implementations, and also very specific / optimized /
>>> generic persistence information models compatible with the openEHR IM. And
>>> I think the implementation / persistence models are the ones we can
>>> simplify and adjust to our needs, but not the reference model, since it's
>>> role is that: be the reference for all implementations.
>>>
>>>
>>>
>>> --
>>> Kind regards,
>>> Eng. Pablo Pazos Guti??rrez
>>> http://cabolabs.com <http://cabolabs.com/es/home>
>>> <http://twitter.com/ppazos>
>>> --
>>> *From

Re: SV: More generic reference model

[Diego Boscá]

I'm not a real fan of having just codes instead of expressions. Expressions
are far more readable and may help in the understanding of the archetype.
Just a single code representing the subset won't be as clear.

El 11/9/2016 16:49, "pablo pazos" <pazospa...@hotmail.com> escribió:

> Hi Bert,
>
>
> I was thinking about integrating SCT with path-based queries (I'm not in
> AQL yet), but maintaining the complexity of the SCT relationships and
> expressions on the terminology service (TS) side, so on queries there are
> just simple codes (specific concept ids, subsets or expressions identified
> just by one code). Then when evaluating a query, with the TS we can get all
> the terms and concept ids that match all the is_a relationships or subsets
> of expressions. I talked with several TS providers and hopefully we can
> build an integration next year to create and evaluate queries with SCT.
>
>
> What I'm saying is that I prefer to delegate the complexity of SCT to the
> TS and create simpler queries in AQL or path-based queries, but your idea
> is interesting. One problem though is that query creators need to be
> experts in SCT.
>
>
> What do you think?
>
>
> Sent from my LG Mobile
>
> -- Original message--
>
> *From: *Bert Verhees
>
> *Date: *Sat, Sep 10, 2016 13:14
>
> *To: *For openEHR technical discussions;
>
> *Subject:*Re: SV: More generic reference model
>
> Hi Pablo, sorry I was bit slow with thinking through my plans. The way I
> see it now, there is no change necessary in the reference model to
> integrate the potential of SCT largely. Even you can keep on using the
> semantic rich entry types like Observation, etc.
>
> See my post in my blog.
> http://www.bertverhees.nl/archetypes/needed-run-snomed-
> ct-expression-constraints-openehr-aql/
>
> If you, however, limit yourself to the Generic entry type, which even
> gives a better integration while keeping all OpenEhr functinality alive.
>
> http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-
> openehr-aql-part-2/
>
> I am interested in what you think about that.
>
> Best regards
> Bert Verhees
>
> Op 10 sep. 2016 05:03 schreef "pablo pazos" <pazospa...@hotmail.com>:
>
>> Hi all,
>>
>>
>> Regarding the genericity of the openEHR IM, from the implementation point
>> of view we have at least 3 models:
>>
>>
>> + the implementation information model
>>
>> + the persistence information model
>>
>> + and the reference / canonic information model (the openEHR IM)
>>
>>
>> Others might have more than these 3 models on their openEHR
>> implementations.
>>
>>
>> I think some simplifications can still be done to the openEHR IM without
>> losing semantics, like removing ITEM_STRUCTURE and using just
>> CLUSTER/ELEMENT (we have a discussion about this on the wiki started some
>> years ago).
>>
>>
>> IMO we should not try to make the reference model simpler just in sake of
>> simplifying the implementation, since the other 2 models are for that. In
>> my systems I have different implementation models that are over simplified
>> openEHR IM implementations, and also very specific / optimized / generic
>> persistence information models compatible with the openEHR IM. And I think
>> the implementation / persistence models are the ones we can simplify and
>> adjust to our needs, but not the reference model, since it's role is that:
>> be the reference for all implementations.
>>
>>
>>
>> --
>> Kind regards,
>> Eng. Pablo Pazos Guti??rrez
>> http://cabolabs.com <http://cabolabs.com/es/home>
>> <http://twitter.com/ppazos>
>> --
>> *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org>
>> on behalf of Mikael Nyström <mikael.nyst...@liu.se>
>> *Sent:* Friday, September 9, 2016 4:15:53 AM
>> *To:* For openEHR technical discussions
>> *Subject:* SV: SV: More generic reference model
>>
>>
>> Hi,
>>
>>
>>
>> A related activity that might be useful to know is the “RFP for LOINC -
>> SNOMED CT Cooperation Project”.http://www.ihtsdo.
>> org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project .
>>
>>
>>
>>  Regards
>>
>>  Mikael
>>
>>
>>
>> *Från:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org]*För *Bert Verhees
>> *Skickat:* den 9 september 2016 08:42
>> *Till:* openehr-technical@lists.

Re: SV: More generic reference model

[pablo pazos]

Hi Bert,


I was thinking about integrating SCT with path-based queries (I'm not in AQL 
yet), but maintaining the complexity of the SCT relationships and expressions 
on the terminology service (TS) side, so on queries there are just simple codes 
(specific concept ids, subsets or expressions identified just by one code). 
Then when evaluating a query, with the TS we can get all the terms and concept 
ids that match all the is_a relationships or subsets of expressions. I talked 
with several TS providers and hopefully we can build an integration next year 
to create and evaluate queries with SCT.


What I'm saying is that I prefer to delegate the complexity of SCT to the TS 
and create simpler queries in AQL or path-based queries, but your idea is 
interesting. One problem though is that query creators need to be experts in 
SCT.


What do you think?


Sent from my LG Mobile

-- Original message--

From: Bert Verhees

Date: Sat, Sep 10, 2016 13:14

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

Hi Pablo, sorry I was bit slow with thinking through my plans. The way I see it 
now, there is no change necessary in the reference model to integrate the 
potential of SCT largely. Even you can keep on using the semantic rich entry 
types like Observation, etc.

See my post in my blog.
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

If you, however, limit yourself to the Generic entry type, which even gives a 
better integration while keeping all OpenEhr functinality alive.

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/

I am interested in what you think about that.

Best regards
Bert Verhees

Op 10 sep. 2016 05:03 schreef "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>>:

Hi all,


Regarding the genericity of the openEHR IM, from the implementation point of 
view we have at least 3 models:


+ the implementation information model

+ the persistence information model

+ and the reference / canonic information model (the openEHR IM)


Others might have more than these 3 models on their openEHR implementations.


I think some simplifications can still be done to the openEHR IM without losing 
semantics, like removing ITEM_STRUCTURE and using just CLUSTER/ELEMENT (we have 
a discussion about this on the wiki started some years ago).


IMO we should not try to make the reference model simpler just in sake of 
simplifying the implementation, since the other 2 models are for that. In my 
systems I have different implementation models that are over simplified openEHR 
IM implementations, and also very specific / optimized / generic persistence 
information models compatible with the openEHR IM. And I think the 
implementation / persistence models are the ones we can simplify and adjust to 
our needs, but not the reference model, since it's role is that: be the 
reference for all implementations.



--
Kind regards,
Eng. Pablo Pazos Guti??rrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>>
Sent: Friday, September 9, 2016 4:15:53 AM
To: For openEHR technical discussions
Subject: SV: SV: More generic reference model

Hi,

A related activity that might be useful to know is the “RFP for LOINC - SNOMED 
CT Cooperation 
Project”.http://www.ihtsdo.org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project
 .

 Regards
 Mikael

Från: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]För
 Bert Verhees
Skickat: den 9 september 2016 08:42
Till: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Ämne: Re: SV: More generic reference model

Op 9-9-2016 om 8:37 schreef Bjørn Næss:
But in addition to that we need to map terms from different other terminologies 
like SNOMED-CT, LOINC and also Disease Ontologies.

There is a mapping effort by IHTSDO en Regenstrief, they started that a few 
years ago, and it will be finished, next year, I think.

http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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

[Bert Verhees]

Hi Pablo, sorry I was bit slow with thinking through my plans. The way I
see it now, there is no change necessary in the reference model to
integrate the potential of SCT largely. Even you can keep on using the
semantic rich entry types like Observation, etc.

See my post in my blog.
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

If you, however, limit yourself to the Generic entry type, which even gives
a better integration while keeping all OpenEhr functinality alive.

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/

I am interested in what you think about that.

Best regards
Bert Verhees

Op 10 sep. 2016 05:03 schreef "pablo pazos" <pazospa...@hotmail.com>:

> Hi all,
>
>
> Regarding the genericity of the openEHR IM, from the implementation point
> of view we have at least 3 models:
>
>
> + the implementation information model
>
> + the persistence information model
>
> + and the reference / canonic information model (the openEHR IM)
>
>
> Others might have more than these 3 models on their openEHR
> implementations.
>
>
> I think some simplifications can still be done to the openEHR IM without
> losing semantics, like removing ITEM_STRUCTURE and using just
> CLUSTER/ELEMENT (we have a discussion about this on the wiki started some
> years ago).
>
>
> IMO we should not try to make the reference model simpler just in sake of
> simplifying the implementation, since the other 2 models are for that. In
> my systems I have different implementation models that are over simplified
> openEHR IM implementations, and also very specific / optimized / generic
> persistence information models compatible with the openEHR IM. And I think
> the implementation / persistence models are the ones we can simplify and
> adjust to our needs, but not the reference model, since it's role is that:
> be the reference for all implementations.
>
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti??rrez
> http://cabolabs.com <http://cabolabs.com/es/home>
> <http://twitter.com/ppazos>
> --
> *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org>
> on behalf of Mikael Nyström <mikael.nyst...@liu.se>
> *Sent:* Friday, September 9, 2016 4:15:53 AM
> *To:* For openEHR technical discussions
> *Subject:* SV: SV: More generic reference model
>
>
> Hi,
>
>
>
> A related activity that might be useful to know is the “RFP for LOINC -
> SNOMED CT Cooperation Project”. http://www.ihtsdo.org/news-
> articles/rfp-for-loinc--snomed-ct-cooperation-project .
>
>
>
>  Regards
>
>          Mikael
>
>
>
> *Från:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *För *Bert Verhees
> *Skickat:* den 9 september 2016 08:42
> *Till:* openehr-technical@lists.openehr.org
> *Ämne:* Re: SV: More generic reference model
>
>
>
> Op 9-9-2016 om 8:37 schreef Bjørn Næss:
>
> But in addition to that we need to map terms from different other
> terminologies like SNOMED-CT, LOINC and also Disease Ontologies.
>
> There is a mapping effort by IHTSDO en Regenstrief, they started that a
> few years ago, and it will be finished, next year, I think.
>
> http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc
>
> ___
> 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

SV: SV: More generic reference model

[Mikael Nyström]

Hi,

A related activity that might be useful to know is the "RFP for LOINC - SNOMED 
CT Cooperation Project". 
http://www.ihtsdo.org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project
 .

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Bert Verhees
Skickat: den 9 september 2016 08:42
Till: openehr-technical@lists.openehr.org
Ämne: Re: SV: More generic reference model

Op 9-9-2016 om 8:37 schreef Bjørn Næss:
But in addition to that we need to map terms from different other terminologies 
like SNOMED-CT, LOINC and also Disease Ontologies.

There is a mapping effort by IHTSDO en Regenstrief, they started that a few 
years ago, and it will be finished, next year, I think.

http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc
___
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

[Bert Verhees]

Op 9-9-2016 om 8:37 schreef Bjørn Næss:
But in addition to that we need to map terms from different other 
terminologies like SNOMED-CT, LOINC and also Disease Ontologies. 


There is a mapping effort by IHTSDO en Regenstrief, they started that a 
few years ago, and it will be finished, next year, I think.


http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc

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

SV: More generic reference model

[Bjørn Næss]

This is perfect timing with ongoing activities in Norway.
There is a government lead activity to explore how to use SNOMED-CT and openEHR 
archetypes together. The first domain is to use SNOMED-CT to define anatomical 
location and structures.

The most important outcome for this is to be able to reason over data and use 
the hierarchical structure to query for all entries in lower left limb which 
should include knee and meniscus entries (pseudo-definitions given here).

In parallel with this activity we are involved in a project where they will 
build an ontology of all entities and make that ontology model/platform as a 
basis to query data from different sources (systems). We are involved since we 
think openEHR reference model with archetypes is such an ontology. But in 
addition to that we need to map terms from different other terminologies like 
SNOMED-CT, LOINC and also Disease Ontologies.

In the end I think we need a shared pattern on how to model and implement this 
- and as mentioned the most important thing is to be able to do queries on this 
hierarchical/graph structured ontologies/terminologies.



/ Bjørn Næss - Product Owner  | DIPS ASA
Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: tirsdag 6. september 2016 23.04
Til: openehr-technical@lists.openehr.org
Emne: Re: More generic reference model




I will actually have some time to start to look at this in the next few weeks - 
i.e. to facilitate / coordinate some work, and possibly do some. I would 
propose to proceed as follows:

  *   gather current unmet requirements
  *   examine current state of AQL spec to clarify what it alredy says, what it 
lacks
  *   propose changes to AQL

The question of adding e.g. an Antlr grammar for the IHTSDO constraint 
expression syntax to AQL is almost trivial; the real question to me is: what is 
the querying + terminology interaction model we are trying to achieve.

So some example queries (pseudo-code is fine) would help. If Bert and others 
who want more progress can at least post some ideas at the requirements level - 
clear and succinct as possible please - it will help a lot.

Here is a wiki page for gathering this 
information.
 As usual, contributors should feel free to change it as required.

- thomas

On 06/09/2016 13:05, Bert Verhees wrote:
Op 6-9-2016 om 19:01 schreef Erik Sundvall:

Many of us think that a better integration of the openEHR and the Snomed CT 
modelling efforts would be great. But there are not enough resources (e.g. 
dedicated time of people with the right knowledge) being put into doing this, 
since this is hard (but interesting) work usually requiring somebody to pay 
people...

Hi Erik,

I do not want to undermine the value of your statement, contrary, I think it is 
very good when some organization or country builds the thing, the money 
involved is a piece of cake for such an entity.
Let the people with good connections start working on getting this arranged
The sooner the better!!!
---
But on the other hand, we should sit down and wait until something will happen.
First, I think, we need a list of requirements. We could start with that.
We need that anyway, even if someone succeeds in getting a big company or 
government to finance the project.

In my opinion, the most difficult work is the definition, following the (to be 
defined) requirements, how is this project going to look like?
Someone with experience in modeling modeling-languages and query-languages, 
someone who is clever in thinking about syntaxes and structures.

The implementing itself is easier, it is just programming. With help of ANTLR 
and a good definition, this will not be too hard.
Like there are written ADL-parsers/AQL-parsers as open source.
When there is a prototype ready, others can improve it, or inspired by a lousy 
prototype, start a new better one.
That is how open source usually works, and it can create big things. We know 
that.

I can help, I have knowledge of AQL, ADL, and SCT (expression constraints), 
enough of all three to add sensible ideas. But I cannot do it on my own.
I do not feel too confident. There is also a risk of failure when doing this 
alone.

So, to set up the requirements, how can we cooperate on that?
Do you have an idea?

Maybe a wiki? Someone needs to take the lead. Say how things are to be done, 
facilitates, etc.

Maybe it is too much to ask for someone to take the lead.
Let first inventory who wants to help. It will cost maybe a few hours in this 
initial phase.

--
So, who wants to help with this sub-project:
- having ideas about features
- set up requirements
- set up some global architecture ideas.

Re: SV: More generic reference model

[Thomas Beale]

I realise that what I said made it sound like IHTSDO experts still think 
that terminology solves everything, but I didn't mean to do that, I 
actually meant to imply that there are people in user orgs who still 
think like this (I often run into them). Mikael's characterisation of 
IHTSDO thinking and strategy is of course more correct than mine.


- thomas

On 06/09/2016 06:11, Mikael Nyström wrote:


Hi,

My more recent impressions from inside the SNOMED CT community are not 
entirely in line with Tom’s impression below.


The people that believe that SNOMED CT is on its own are nowadays 
quite few. My impression is that most people understand that SNOMED CT 
needs to be implemented using powerful information models (or data 
structures) to achieve all its benefits. However, the problem is that 
there are so many information models for health records around and 
some of them are (more or less) standardized and some of them are ad 
hoc and some of them are proprietary so there is difficult to interact 
and engage with all of them.


IHTSDO’s primary focus is their member countries (and potential member 
countries) and IHTSDO therefore focus on solving the terminology and 
ontology needs in these countries. In these member countries are 
SNOMED CT a large part of the terminology and ontology solution for 
the health care system. IHTSDO therefore focus on SNOMED CT and 
collaborations with other terminologies and classifications that are 
well used in the member countries, like ICD and LOINC. However, it is 
understandable that for people in non-member countries it seems like 
IHTSDO assumes that the whole world uses SNOMED CT.


Regards

Mikael

Thomas Beale wrote:

Indeed. Ideally we would work more closely with IHTSDO on this (I 
spent 4 y on standing committees there), but I think there is not yet 
the interest in this. There are still people who believe that a) 
SNOMED CT on its own, with only trivial data structures is all that is 
needed (that's a categorical error of thinking) and/or b) that the 
whole world uses SNOMED CT and that therefore the only terminology 
approach is SNOMED CT (an error today, and I suspect for years to come).




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

SV: More generic reference model

[Mikael Nyström]

Hi,



My more recent impressions from inside the SNOMED CT community are not entirely 
in line with Tom's impression below.



The people that believe that SNOMED CT is on its own are nowadays quite few. My 
impression is that most people understand that SNOMED CT needs to be 
implemented using powerful information models (or data structures) to achieve 
all its benefits. However, the problem is that there are so many information 
models for health records around and some of them are (more or less) 
standardized and some of them are ad hoc and some of them are proprietary so 
there is difficult to interact and engage with all of them.



IHTSDO's primary focus is their member countries (and potential member 
countries) and IHTSDO therefore focus on solving the terminology and ontology 
needs in these countries. In these member countries are SNOMED CT a large part 
of the terminology and ontology solution for the health care system. IHTSDO 
therefore focus on SNOMED CT and collaborations with other terminologies and 
classifications that are well used in the member countries, like ICD and LOINC. 
However, it is understandable that for people in non-member countries it seems 
like IHTSDO assumes that the whole world uses SNOMED CT.



 Regards

 Mikael





Thomas Beale wrote:



Indeed. Ideally we would work more closely with IHTSDO on this (I spent 4 y on 
standing committees there), but I think there is not yet the interest in this. 
There are still people who believe that a) SNOMED CT on its own, with only 
trivial data structures is all that is needed (that's a categorical error of 
thinking) and/or b) that the whole world uses SNOMED CT and that therefore the 
only terminology approach is SNOMED CT (an error today, and I suspect for years 
to come).


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