Re: SV: More generic reference model

[Michael.Lawley]

Thanks Bert,


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


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


michael


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

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


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

I will check it out today again, thanks for posting

Bert

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

(Hope that Unicode works :-)

Michae

Sent from my iPhone

> On 13 Sep 2016, at 1:23 AM, Thomas Beale 
> 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
> 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]

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" :

> 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

[pablo pazos]

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.orghttp://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: More generic reference model

[GF]

Thomar,

I know of the SOLOR project where SNOMED is harmonised with LOINC and RxNorm

http://wiki.hl7.org/index.php?title=CIMI_Quality_Modeling_Collaboration
http://www.healthcare-informatics.com/blogs/david-raths/interoperability/can-solor-snomed-loinc-rxnorm-project-create-terminology
http://www.businesswire.com/news/home/2016071900/en/Healthcare-Services-Platform-Consortium-Launches-Data-Standard-Integration

Gerard


> On 12 sep. 2016, at 10:32, 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


___
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: How can I model multiple checkboxs options with terminology?

[Ian McNicoll]

Hi Tiago,

This should only be an issue if you have to perform an update. My best
understanding is that known of the well-known implementations try to
perform a 'diff' in event of an update they simply create a full new
version of the composition based on the new data.

Whilst this is a bit inefficient, the realities for performing diffs safely
across the full range of potential scenarios is quite daunting and raises
many potential clinical safety issues.

My suggestion would just to recreate the composition each time.

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 12 September 2016 at 05:16, Tiago Santos da Silva 
wrote:

> I understood.
>
> The solution is using multiples DV_CODED_TEXT and uniqueness is
> implemented by software.
>
> In this case I think that the data persistence is made of many leaf paths
> (one value by leaf). I don't see the problem in saving the entire
> composition in a contribution, but if I send only changed data I have to
> find a way of delete a leaf when "checkbox" is deselected. I know how to
> update key/path data but I didn't find deletion in the openEHR
> specification (Probably I failed when I was searching for this).
>
> I think that is just a implementation problem and I wont't find that in
> specification. Am I correct?
>
> Thanks, you helped me a lot!
>
> 2016-09-10 20:48 GMT-03:00 Tiago Santos da Silva :
>
>> I understand that you can use a cluster with multiple Boolean. But I
>> would like that the values came from a terminology.
>>
>> Maybe a better example would be the following:
>>
>> 1) Select the laboratory tests that should I request:
>>   [ ] Blood Glucose
>>   [ ] Blood Culture
>>   [ ] Albumin
>>  < 100 other tests ...>
>>   [ ] Amylase
>>
>> Can't I use the values of a terminology such as list of options using
>> openEHR? Do I must write all the laboratory tests in the archetype like
>> booleans?
>>
>> I have trouble understanding how openEHR handles lists of values. I think
>> I have to use the field "occurrences 0.*" but I'm not sure if that is the
>> correct way.
>>
>> Maybe I'm not thinking right about how to use OpenEHR.
>>
>> Thanks for helping.
>>
>> - Tiago
>>
>> 2016-09-10 16:37 GMT-03:00 Tiago Santos da Silva :
>>
>>> Hi,
>>>
>>> Can anyone tell how I can model the example below?
>>>
>>> "What parts of the body hurt? [ ] right leg [ ] left leg [ ] head [ ]
>>> right arm .."
>>>
>>> I know to model a single option (radio-buttom) but I don't know to model
>>> a multiple options (checkbox)
>>>
>>> The idea is that the options are of the terminology, so I can't model
>>> right in the archetype.
>>>
>>> I'm using the key-path  strategy for data persistence. In the case of
>>> the radiobutton leaf is a DV_CODED_TEXT but I don't know when use checkbox.
>>>
>>> Note: English is not my native language I hope it is clear the doubt.
>>>
>>> Thank you!
>>>
>>
>
> ___
> 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á]

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