Re: SNOMEDCT - correct representation

2017-05-20 Thread Thomas Beale


We should not understand the namespace "snomed-ct" in this way; instead 
it should resolve to whatever SNOMED there is in the local termology 
service, which might be some Norway national thing, or Spanish regional 
server etc. So the expected national extensions and translations would 
be present for archetypes containing codes that refer to concepts in 
those extensions.


One might argue that archetypes should carry a localisation code, not 
just for languages, but for terminology, of the same form as language 
tags, e.g. "fr-ca" would mean that French translation was expected, and 
that Canadian SCT national extension was assumed. Currently we don't 
have a way of marking archetypes like this, but possibly we should.


- thomas


On 25/04/2017 08:50, Diego Boscá wrote:
I think having this in a hardcoded terminology list is probably far 
from ideal (e.g. how do you put "snomed ct+norway national extension"? 
do we need an exhaustive listing of all possible extensions/versions?)



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


Re: SNOMEDCT - correct representation

2017-05-19 Thread Pablo Pazos
I totally agree with that, my argument was more about considering *only*
syntax improvements without considering tooling and modeler's issues /
challenges.

As a techie also I like simple and clear formalisms, but we can also read
"machine code", so we might need a "simple enough" solution for syntax.
without over-engineering it. Not saying this is the case, just mentioning
this because is part of my mantra when I get too idealist with the things I
create :)

On Fri, May 19, 2017 at 2:01 PM, Thomas Beale 
wrote:

> Hi Pablo,
>
> for clinical modellers I completely agree. It is mostly technical people -
> tool writers who work with the syntax form of things. But at the end of the
> day, it is them who build the systems and who must understand every last
> subtlety of the semantics of any of the languages we use - ADL, AQL, ODIN,
> SNOMED constraint syntax, just as for the mainstream languages they use,
> i.e. Java, C#, OWL, and so on.
>
> Determining a clean syntax for any part of a specification is part of
> designing what that specification is about (for specifications that have a
> syntax aspect). At the moment ADL, ODIN, BMM, and AQL are all cleartext
> context-free syntaxes. Yes they tend to be read and written by tools in
> operational circumstances, but to ignore the syntax is to ignore the
> activities of learning, developing, testing, and debugging.
>
> Imagine trying to teach someone programming with no recourse to a
> programming language, only in-memory compiler structures.
>
> Getting language right corresponds to obtaining clarity in a formalism.
> Working on the tools is of course a big priority, but a different exercise
> and (generally) people - it's a software development exercise. But they are
> linked. I'll give you an example. To implement an archetype flattener
> properly, as in the ADL Workbench, you need to know an algorithm for
> flattening two archetypes. That means understanding the differential form
> of archetypes. That means understanding paths, node ids and many other
> elements of archetypes. This is all primarily described in the ADL2 spec
> 
> because that is the easiest way to comprehend it. Some elements are
> described in the AOM2 spec, but it's harder to see, since now we are
> talking in-memory object structures defined by class models.
>
> So I remain convinced that languages have an important role to play in our
> design, learning and understanding of things. Others may disagree ;)
>
> - thomas
>
> On 18/05/2017 16:22, Pablo Pazos wrote:
>
> I really believe we should be teaching using tools not reading syntax,
> specially for clinical modelers. If we are doing that right now is because
> tools lack usability, features and maturity.
>
> For techies, we like to look at the syntax because we need to parse and
> process it.
>
> I'm not against improving the syntax, but since we don't have much
> resources as a community, shouldn't we focus were the real problem is with
> tools instead of patching the specs?
>
> Maybe clinical modelers can help software vendors on improving their tools
> and to create new ones to help on the modeling process, and there are some
> vendors creating such tools already but don't have input from the community.
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



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

http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-19 Thread Thomas Beale

Hi Pablo,

for clinical modellers I completely agree. It is mostly technical people 
- tool writers who work with the syntax form of things. But at the end 
of the day, it is them who build the systems and who must understand 
every last subtlety of the semantics of any of the languages we use - 
ADL, AQL, ODIN, SNOMED constraint syntax, just as for the mainstream 
languages they use, i.e. Java, C#, OWL, and so on.


Determining a clean syntax for any part of a specification is part of 
designing what that specification is about (for specifications that have 
a syntax aspect). At the moment ADL, ODIN, BMM, and AQL are all 
cleartext context-free syntaxes. Yes they tend to be read and written by 
tools in operational circumstances, but to ignore the syntax is to 
ignore the activities of learning, developing, testing, and debugging.


Imagine trying to teach someone programming with no recourse to a 
programming language, only in-memory compiler structures.


Getting language right corresponds to obtaining clarity in a formalism. 
Working on the tools is of course a big priority, but a different 
exercise and (generally) people - it's a software development exercise. 
But they are linked. I'll give you an example. To implement an archetype 
flattener properly, as in the ADL Workbench, you need to know an 
algorithm for flattening two archetypes. That means understanding the 
differential form of archetypes. That means understanding paths, node 
ids and many other elements of archetypes. This is all primarily 
described in the ADL2 spec 
 
because that is the easiest way to comprehend it. Some elements are 
described in the AOM2 spec, but it's harder to see, since now we are 
talking in-memory object structures defined by class models.


So I remain convinced that languages have an important role to play in 
our design, learning and understanding of things. Others may disagree ;)


- thomas


On 18/05/2017 16:22, Pablo Pazos wrote:
I really believe we should be teaching using tools not reading syntax, 
specially for clinical modelers. If we are doing that right now is 
because tools lack usability, features and maturity.


For techies, we like to look at the syntax because we need to parse 
and process it.


I'm not against improving the syntax, but since we don't have much 
resources as a community, shouldn't we focus were the real problem is 
with tools instead of patching the specs?


Maybe clinical modelers can help software vendors on improving their 
tools and to create new ones to help on the modeling process, and 
there are some vendors creating such tools already but don't have 
input from the community.




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

Re: SNOMEDCT - correct representation

2017-05-18 Thread Pablo Pazos
I really believe we should be teaching using tools not reading syntax,
specially for clinical modelers. If we are doing that right now is because
tools lack usability, features and maturity.

For techies, we like to look at the syntax because we need to parse and
process it.

I'm not against improving the syntax, but since we don't have much
resources as a community, shouldn't we focus were the real problem is with
tools instead of patching the specs?

Maybe clinical modelers can help software vendors on improving their tools
and to create new ones to help on the modeling process, and there are some
vendors creating such tools already but don't have input from the community.


On Tue, May 16, 2017 at 4:35 PM, Thomas Beale 
wrote:

> not at all - a lot of people work with ADL, ODIN, BMM, JSON etc in plain
> text for teaching, development of test archetypes, test data, looking at
> data, making small systems etc.
>
> - thomas
>
> On 16/05/2017 13:22, Pablo Pazos wrote:
>
> it would be good to ask them why they do that, maybe is for limitations on
> the modeling tools, or maybe they are cyborgs in disguise.
>
> On Tue, May 16, 2017 at 1:14 PM, Thomas Beale 
> wrote:
>
>>
>> sure. But there are a lot that do, just not the ones you know ;) We have
>> to make things work for everyone.
>>
>> - thomas
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



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

http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-16 Thread Thomas Beale

Bert

there is no resistance, in fact I at least agree with your general idea 
- see my other post. Just a question of getting the analysis right, 
implementing it and releasing a specification update. Then retroatively 
fitting it to ADL 1.4 (now we need ADL 1.5 ;)


- thomas


On 16/05/2017 13:24, Bert Verhees wrote:

On 16-05-17 18:14, Thomas Beale wrote:



sure. But there are a lot that do, just not the ones you know ;) We 
have to make things work for everyone.


So what about my suggestion a few weeks ago, to add a comment-section 
to a terminology-binding url to explain what the url does.
Most people will never be able to understand LOINC codes or 
SNOMED-post coordinated expressions or constraints.


So an explanation-section can do good work in that case. Good tooling 
can keep it up to date.


The point is that SNOMED constraints and expressions offer a wealth of 
possibilities to express clinical ideas in a language independent 
interoperable way.

I have difficulties to understand the resistance against this.

It can take OpenEHR, in my view, to a higher level, without changing 
much on the standard.



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


Re: SNOMEDCT - correct representation

2017-05-16 Thread Thomas Beale
not at all - a lot of people work with ADL, ODIN, BMM, JSON etc in plain 
text for teaching, development of test archetypes, test data, looking at 
data, making small systems etc.


- thomas


On 16/05/2017 13:22, Pablo Pazos wrote:
it would be good to ask them why they do that, maybe is for 
limitations on the modeling tools, or maybe they are cyborgs in disguise.


On Tue, May 16, 2017 at 1:14 PM, Thomas Beale 
> wrote:



sure. But there are a lot that do, just not the ones you know ;)
We have to make things work for everyone.

- thomas



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

Re: SNOMEDCT - correct representation

2017-05-16 Thread Pieter Bos
If anyone knows an editor that does ADL2 and supports enough options to make 
editing by hand no longer needed, we're interested.

Regards,

Pieter Bos

Op 16 mei 2017 om 18:23 heeft Pablo Pazos 
> het volgende 
geschreven:

it would be good to ask them why they do that, maybe is for limitations on the 
modeling tools, or maybe they are cyborgs in disguise.

On Tue, May 16, 2017 at 1:14 PM, Thomas Beale 
> wrote:


sure. But there are a lot that do, just not the ones you know ;) We have to 
make things work for everyone.

- thomas

On 16/05/2017 13:08, Bert Verhees wrote:
Most creators or users of archetypes I know, completely depend on tooling. They 
are never capable to read an ADL text, nor do they ever want to read it.

And as I suggested, with smart text-editors http-url encoding can be easily 
translated/showed into readable url's


On 16-05-17 16:06, Pablo Pazos wrote:
Not sure why readability is a requirement here. Shouldn't those expressions be 
generated and consumed by systems?

We should create simple to use GUIs not simple to read code :)

On Wed, May 3, 2017 at 9:31 AM, Diego Bosc? 
> wrote:
Or just use the "Long syntax" as described in point 5.2 from Expression 
Constraint Language, which keeps things readable enough
http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|

2017-05-03 14:20 GMT+02:00 Thomas Beale 
>:


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



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

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

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

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


Re: SNOMEDCT - correct representation

2017-05-16 Thread Bert Verhees

Sorry, I cannot reply now, I reply tomorrow
Bert


On 16-05-17 18:25, Thomas Beale wrote:



I think this idea is probably right, in some form. You can see the 
current formal definitions for the terminology structures here (ADL2 
, 
AOM2 
).


Terminology bindings are currently assumed to be a Hash >, where the outer key is terminology namespace id 
(e.g. 'snomed-ct', 'icd10' etc) and the inner is an archetype code or 
path.


So the bindings are currently of the form:

|term_bindings = < ["snomed_ct"] = < 
["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
 -- Apgar score at 1 minute 
["id26"] =  -- Total Apgar score 
(observable entity) > ["loinc"] = < ["/data[id3]/events[id4]"] = 
 -- 1-minute Apgar panel 
["/data[id3]/events[id4]/data[id2]/items[id6]"] = 
 -- 1 minute Apgar Heart rate ["at7"] = 
 -- No heart rate ... > ["umls"] = < 
["id1"] =  -- apgar result ["id6"] = 
 -- cardiac score > >|


but maybe we want something like this:

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


you get the idea - I just hacked this together to show possible syntax 
and structure. The semantics make no sense. In the second binding, you 
see that target is a String that can be interpreted as a SNOMED 
expression, due to the fact that it is inside a structure of type 
CONSTRAINT_BINDING (this doesn't exist today - we would need to add it 
to the AOM).


I don't claim to know what the proper design of these types are - 
presumably, things like min_version, notes, etc can make sense.


this is just my first thought, but I think it is clear that the right 
hand side of a binding can be a few diferent things:


  * a single concept code
  * a single code referring to an external value set known in SNOMED
  * a composition expression that refers to a more refined concept
  * a constraint expression that locally determines a value set
intensionally, to be resolved by application to the Terminology
service.

So we would need AOM types to accommodate all of that, and other 
meta-data we think we need as well.


- thomas

On 04/05/2017 03:06, Bert Verhees wrote:
Regarding the readability of the URI's containing SNOMED expressions, 
one can always consider adding a comment line containing the long 
(textual) expression format without URI encodings.


Maybe it is also possible to formalize that comment/description in a 
special ODIN tag. Also other terminology-codings do not explain 
themselves very well and an explanation/description can be very 
useful for the reader of plain text ADL


I think that SNOMED constraints and post coordinated expressions will 
soon become unavoidable in an EHR application, and that it is urgent 
to find a solution for this.


Best regards
Bert Verhees

Op 3 mei 2017 16:45 schreef "Diego Boscá" >:


well, nothing stops you for not encoding the query in definition
time, most services are ok with that
e.g.

http://diebosto2.pc.upv.es:/SnomedQuery/ws/JSONQuery?query=

<404684003:363698007=39057004

2017-05-03 16:31 GMT+02:00 Thomas Beale >:


On 03/05/2017 13:31, Diego Boscá wrote:

Or just use the "Long syntax" as described in point 5.2
from Expression Constraint Language, which keeps things
readable enough
http://snomed.info/ecl/descendantOrSelfOf
 73211009
|Diabetes mellitus|


at the very least, a %20 is needed for the spaces, and %7C
for the pipes, i.e.


http://snomed.info/ecl/descendantOrSelfOf%2073211009%20%7CDiabetes%20mellitus%7C



i.e. ... not readable...

- thomas





Re: SNOMEDCT - correct representation

2017-05-16 Thread Thomas Beale


I think this idea is probably right, in some form. You can see the 
current formal definitions for the terminology structures here (ADL2 
, 
AOM2 
).


Terminology bindings are currently assumed to be a Hash >, where the outer key is terminology namespace id 
(e.g. 'snomed-ct', 'icd10' etc) and the inner is an archetype code or path.


So the bindings are currently of the form:

|term_bindings = < ["snomed_ct"] = < 
["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
 -- Apgar score at 1 minute ["id26"] 
=  -- Total Apgar score (observable 
entity) > ["loinc"] = < ["/data[id3]/events[id4]"] = 
 -- 1-minute Apgar panel 
["/data[id3]/events[id4]/data[id2]/items[id6]"] = 
 -- 1 minute Apgar Heart rate ["at7"] = 
 -- No heart rate ... > ["umls"] = < 
["id1"] =  -- apgar result ["id6"] = 
 -- cardiac score > >|



but maybe we want something like this:

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



you get the idea - I just hacked this together to show possible syntax 
and structure. The semantics make no sense. In the second binding, you 
see that target is a String that can be interpreted as a SNOMED 
expression, due to the fact that it is inside a structure of type 
CONSTRAINT_BINDING (this doesn't exist today - we would need to add it 
to the AOM).


I don't claim to know what the proper design of these types are - 
presumably, things like min_version, notes, etc can make sense.


this is just my first thought, but I think it is clear that the right 
hand side of a binding can be a few diferent things:


 * a single concept code
 * a single code referring to an external value set known in SNOMED
 * a composition expression that refers to a more refined concept
 * a constraint expression that locally determines a value set
   intensionally, to be resolved by application to the Terminology service.

So we would need AOM types to accommodate all of that, and other 
meta-data we think we need as well.


- thomas

On 04/05/2017 03:06, Bert Verhees wrote:
Regarding the readability of the URI's containing SNOMED expressions, 
one can always consider adding a comment line containing the long 
(textual) expression format without URI encodings.


Maybe it is also possible to formalize that comment/description in a 
special ODIN tag. Also other terminology-codings do not explain 
themselves very well and an explanation/description can be very useful 
for the reader of plain text ADL


I think that SNOMED constraints and post coordinated expressions will 
soon become unavoidable in an EHR application, and that it is urgent 
to find a solution for this.


Best regards
Bert Verhees

Op 3 mei 2017 16:45 schreef "Diego Boscá" >:


well, nothing stops you for not encoding the query in definition
time, most services are ok with that
e.g.

http://diebosto2.pc.upv.es:/SnomedQuery/ws/JSONQuery?query=

<404684003:363698007=39057004

2017-05-03 16:31 GMT+02:00 Thomas Beale >:


On 03/05/2017 13:31, Diego Boscá wrote:

Or just use the "Long syntax" as described in point 5.2
from Expression Constraint Language, which keeps things
readable enough
http://snomed.info/ecl/descendantOrSelfOf
 73211009
|Diabetes mellitus|


at the very least, a %20 is needed for the spaces, and %7C for
the pipes, i.e.


http://snomed.info/ecl/descendantOrSelfOf%2073211009%20%7CDiabetes%20mellitus%7C



i.e. ... not readable...

- thomas




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-16 Thread Bert Verhees

On 16-05-17 18:14, Thomas Beale wrote:



sure. But there are a lot that do, just not the ones you know ;) We 
have to make things work for everyone.


So what about my suggestion a few weeks ago, to add a comment-section to 
a terminology-binding url to explain what the url does.
Most people will never be able to understand LOINC codes or SNOMED-post 
coordinated expressions or constraints.


So an explanation-section can do good work in that case. Good tooling 
can keep it up to date.


The point is that SNOMED constraints and expressions offer a wealth of 
possibilities to express clinical ideas in a language independent 
interoperable way.

I have difficulties to understand the resistance against this.

It can take OpenEHR, in my view, to a higher level, without changing 
much on the standard.


Bert



- thomas


On 16/05/2017 13:08, Bert Verhees wrote:
Most creators or users of archetypes I know, completely depend on 
tooling. They are never capable to read an ADL text, nor do they ever 
want to read it.


And as I suggested, with smart text-editors http-url encoding can be 
easily translated/showed into readable url's



On 16-05-17 16:06, Pablo Pazos wrote:
Not sure why readability is a requirement here. Shouldn't those 
expressions be generated and consumed by systems?


We should create simple to use GUIs not simple to read code :)

On Wed, May 3, 2017 at 9:31 AM, Diego Boscá > wrote:


Or just use the "Long syntax" as described in point 5.2 from
Expression Constraint Language, which keeps things readable enough
http://snomed.info/ecl/descendantOrSelfOf
 73211009 |Diabetes
mellitus|

2017-05-03 14:20 GMT+02:00 Thomas Beale
>:





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



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

Re: SNOMEDCT - correct representation

2017-05-16 Thread Pablo Pazos
it would be good to ask them why they do that, maybe is for limitations on
the modeling tools, or maybe they are cyborgs in disguise.

On Tue, May 16, 2017 at 1:14 PM, Thomas Beale 
wrote:

>
> sure. But there are a lot that do, just not the ones you know ;) We have
> to make things work for everyone.
>
> - thomas
>
> On 16/05/2017 13:08, Bert Verhees wrote:
>
> Most creators or users of archetypes I know, completely depend on tooling.
> They are never capable to read an ADL text, nor do they ever want to read
> it.
>
> And as I suggested, with smart text-editors http-url encoding can be
> easily translated/showed into readable url's
>
>
> On 16-05-17 16:06, Pablo Pazos wrote:
>
> Not sure why readability is a requirement here. Shouldn't those
> expressions be generated and consumed by systems?
>
> We should create simple to use GUIs not simple to read code :)
>
> On Wed, May 3, 2017 at 9:31 AM, Diego Boscá  wrote:
>
>> Or just use the "Long syntax" as described in point 5.2 from Expression
>> Constraint Language, which keeps things readable enough
>> http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|
>>
>> 2017-05-03 14:20 GMT+02:00 Thomas Beale :
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



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

http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-16 Thread Thomas Beale


sure. But there are a lot that do, just not the ones you know ;) We have 
to make things work for everyone.


- thomas


On 16/05/2017 13:08, Bert Verhees wrote:
Most creators or users of archetypes I know, completely depend on 
tooling. They are never capable to read an ADL text, nor do they ever 
want to read it.


And as I suggested, with smart text-editors http-url encoding can be 
easily translated/showed into readable url's



On 16-05-17 16:06, Pablo Pazos wrote:
Not sure why readability is a requirement here. Shouldn't those 
expressions be generated and consumed by systems?


We should create simple to use GUIs not simple to read code :)

On Wed, May 3, 2017 at 9:31 AM, Diego Boscá > wrote:


Or just use the "Long syntax" as described in point 5.2 from
Expression Constraint Language, which keeps things readable enough
http://snomed.info/ecl/descendantOrSelfOf
 73211009 |Diabetes
mellitus|

2017-05-03 14:20 GMT+02:00 Thomas Beale >:



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

Re: SNOMEDCT - correct representation

2017-05-16 Thread Bert Verhees
Most creators or users of archetypes I know, completely depend on 
tooling. They are never capable to read an ADL text, nor do they ever 
want to read it.


And as I suggested, with smart text-editors http-url encoding can be 
easily translated/showed into readable url's



On 16-05-17 16:06, Pablo Pazos wrote:
Not sure why readability is a requirement here. Shouldn't those 
expressions be generated and consumed by systems?


We should create simple to use GUIs not simple to read code :)

On Wed, May 3, 2017 at 9:31 AM, Diego Boscá > wrote:


Or just use the "Long syntax" as described in point 5.2 from
Expression Constraint Language, which keeps things readable enough
http://snomed.info/ecl/descendantOrSelfOf
 73211009 |Diabetes
mellitus|

2017-05-03 14:20 GMT+02:00 Thomas Beale >:

Daniel,

my fault - didn't read the front page properly - the things we
need are mooted for next release. But now I agree with Diego...

The expression constraint "< 404684003|Clinical finding|: <
47429007 |Associated with| = < 79654002 |Edema|"

  * http

://snomed.info/ecl/%

3C404684003%3A%3C%3C47429007%3D%3C%3C79654002


that is seriously unreadable. In a different universe, we
would have hoped for something like:

http://snomed.info/ecl/<404684003:<47429007
=<79654002

but of course that is illegal in URI syntax.

In terms of what we put in archetype bindings, I start to
wonder. Could it make sense to allow:

  * proper URIs for single terms, value set refs, module refs
etc (all the URIs that only include a single SCT code)
  * post-coordinated expressions in their syntax form
  * constraint expressions in their syntax form

where the latter two would be understood as standing for their
equivalent URIs? That's an awful hack though.

A more consistent argument would be to revert to not using
URIs in bindings, and use just codes and expressions.

The problem with doing that is that the ID concept URIs
include useful things like /id, /module, /field, etc.

If we just go with the kind of URIs like the above, archetype
bindings will cease to be self-documenting. I am starting to
think we need an expression syntax that covers all of:

  * single term references, including to SNOMED codes,
modules, versions, 
  * SNOMED post-coordinated expressions
  * SNOMED constraint expressions
  * and... the equivalent for non-SNOMED codes, e.g. LOINC,
ICDx, ICF, etc etc

We still don't have a universal terminology referencing
mechanism, but it's what I think we need. It could in theory
be achieved with the use of a new 'terminology' scheme space,
thus:

< 19829001|Disorder of lung|
 and < 301867009|Edema of
trunk| 

becomes

terminology:/snomed-ct/ecf/value="< 19829001|Disorder of lung|
 and < 301867009|Edema of
trunk|" 

(I won't try to work out the nicest syntax, let's just say we
agree that we could find one)

This would allow URIs of the form

terminology:/loinc/xyz/something-loinc-ish

and so on.

The sole purpose of a terminology scheme space might just be
to establish a universal id space whose ids are readable,
structured strings, that can be machine-converted to real URIs
for SNOMED, but also LOINC, ICDx, HL7, and all the other
terminologies.

- thomas


On 03/05/2017 12:09, Daniel Karlsson wrote:

See this page:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard


Please consider the language used when posting.
/Daniel

On May 3, 2017 13:03, Bert Verhees 
 wrote:

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

On 03/05/2017 11:40, Bert Verhees wrote:

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

The only missing part, now that I look at the
SNOMED Compositional Grammar

Re: SNOMEDCT - correct representation

2017-05-16 Thread Pablo Pazos
Mentioned that in general, don't see the point of arguing about readability
of things that are meant to be generated and processed by machines. not
read or processed by a person.

If modeling tools work as expected, no clinical modeler or terminologist
should deal with "source code". But I get that we don't live in a perfect
world and tools are not ideal, that is why I think is better to focus on
improving tools than have an ideal syntax.

On Tue, May 16, 2017 at 11:44 AM, Thomas Beale 
wrote:

> Hi Pablo,
>
> if you were talking XML or other such unreadable stuff I agree. But the
> whole point of context free grammars like programming languages, ADL, OWL,
> and also these SNOMED mini-languages is to be formal and human readable. It
> is via languages that humans learn the semantics of the formalism in a
> native way. The problem with GUIs is that everyone's is different, whereas
> everyone knows what this means (using standard logic as an example):
>
> ∃p:P | F(p) = blue
>
> I think that the SNOMED compositional and constraint grammars have a very
> readable and concise native syntax, and the fact is that people edit
> archetypes and related artefacts all the time, so we need to be able to see
> this kind of syntax in plain text.
>
> I now think that putting these expressions into URIs is not the way to go.
> We could probably handle the constraint in a separate ODIN attribute, in
> the way that Bert is probably thinking about. I'll try to work on a design
> for this as soon as possible, but others are always welcome to come up with
> something.
>
> - thomas
>
> On 16/05/2017 11:06, Pablo Pazos wrote:
>
> Not sure why readability is a requirement here. Shouldn't those
> expressions be generated and consumed by systems?
>
> We should create simple to use GUIs not simple to read code :)
>
> On Wed, May 3, 2017 at 9:31 AM, Diego Boscá  wrote:
>
>> Or just use the "Long syntax" as described in point 5.2 from Expression
>> Constraint Language, which keeps things readable enough
>> http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|
>>
>> 2017-05-03 14:20 GMT+02:00 Thomas Beale :
>>
>>> Daniel,
>>>
>>> my fault - didn't read the front page properly - the things we need are
>>> mooted for next release. But now I agree with Diego...
>>>
>>> The expression constraint "< 404684003 |Clinical finding|: < 47429007
>>> <4742%209007> |Associated with| = < 79654002 |Edema|"
>>>
>>>- http
>>>
>>>://snomed.info/ecl/%
>>>
>>>3C404684003%3A%3C%3C47429007%3D%3C%3C79654002
>>>
>>>
>>>
>>> that is seriously unreadable. In a different universe, we would have
>>> hoped for something like:
>>>
>>> http://snomed.info/ecl/<404684003:<47429007 <4742%209007>=<79654002
>>>
>>> but of course that is illegal in URI syntax.
>>>
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



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

http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-16 Thread Thomas Beale

Hi Pablo,

if you were talking XML or other such unreadable stuff I agree. But the 
whole point of context free grammars like programming languages, ADL, 
OWL, and also these SNOMED mini-languages is to be formal and human 
readable. It is via languages that humans learn the semantics of the 
formalism in a native way. The problem with GUIs is that everyone's is 
different, whereas everyone knows what this means (using standard logic 
as an example):


∃p:P | F(p) = blue

I think that the SNOMED compositional and constraint grammars have a 
very readable and concise native syntax, and the fact is that people 
edit archetypes and related artefacts all the time, so we need to be 
able to see this kind of syntax in plain text.


I now think that putting these expressions into URIs is not the way to 
go. We could probably handle the constraint in a separate ODIN 
attribute, in the way that Bert is probably thinking about. I'll try to 
work on a design for this as soon as possible, but others are always 
welcome to come up with something.


- thomas


On 16/05/2017 11:06, Pablo Pazos wrote:
Not sure why readability is a requirement here. Shouldn't those 
expressions be generated and consumed by systems?


We should create simple to use GUIs not simple to read code :)

On Wed, May 3, 2017 at 9:31 AM, Diego Boscá > wrote:


Or just use the "Long syntax" as described in point 5.2 from
Expression Constraint Language, which keeps things readable enough
http://snomed.info/ecl/descendantOrSelfOf
 73211009 |Diabetes
mellitus|

2017-05-03 14:20 GMT+02:00 Thomas Beale >:

Daniel,

my fault - didn't read the front page properly - the things we
need are mooted for next release. But now I agree with Diego...

The expression constraint "< 404684003|Clinical finding|: <
47429007 |Associated with| = < 79654002 |Edema|"

  * http

://snomed.info/ecl/%

3C404684003%3A%3C%3C47429007%3D%3C%3C79654002


that is seriously unreadable. In a different universe, we
would have hoped for something like:

http://snomed.info/ecl/<404684003:<47429007
=<79654002

but of course that is illegal in URI syntax.



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

Re: SNOMEDCT - correct representation

2017-05-16 Thread Pablo Pazos
Not sure why readability is a requirement here. Shouldn't those expressions
be generated and consumed by systems?

We should create simple to use GUIs not simple to read code :)

On Wed, May 3, 2017 at 9:31 AM, Diego Boscá  wrote:

> Or just use the "Long syntax" as described in point 5.2 from Expression
> Constraint Language, which keeps things readable enough
> http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|
>
> 2017-05-03 14:20 GMT+02:00 Thomas Beale :
>
>> Daniel,
>>
>> my fault - didn't read the front page properly - the things we need are
>> mooted for next release. But now I agree with Diego...
>>
>> The expression constraint "< 404684003 |Clinical finding|: < 47429007
>> <4742%209007> |Associated with| = < 79654002 |Edema|"
>>
>>- http
>>
>>://snomed.info/ecl/%
>>
>>3C404684003%3A%3C%3C47429007%3D%3C%3C79654002
>>
>>
>>
>> that is seriously unreadable. In a different universe, we would have
>> hoped for something like:
>>
>> http://snomed.info/ecl/<404684003:<47429007 <4742%209007>=<79654002
>>
>> but of course that is illegal in URI syntax.
>>
>> In terms of what we put in archetype bindings, I start to wonder. Could
>> it make sense to allow:
>>
>>- proper URIs for single terms, value set refs, module refs etc (all
>>the URIs that only include a single SCT code)
>>- post-coordinated expressions in their syntax form
>>- constraint expressions in their syntax form
>>
>> where the latter two would be understood as standing for their equivalent
>> URIs? That's an awful hack though.
>>
>> A more consistent argument would be to revert to not using URIs in
>> bindings, and use just codes and expressions.
>>
>> The problem with doing that is that the ID concept URIs include useful
>> things like /id, /module, /field, etc.
>>
>> If we just go with the kind of URIs like the above, archetype bindings
>> will cease to be self-documenting. I am starting to think we need an
>> expression syntax that covers all of:
>>
>>- single term references, including to SNOMED codes, modules,
>>versions, 
>>- SNOMED post-coordinated expressions
>>- SNOMED constraint expressions
>>- and... the equivalent for non-SNOMED codes, e.g. LOINC, ICDx, ICF,
>>etc etc
>>
>> We still don't have a universal terminology referencing mechanism, but
>> it's what I think we need. It could in theory be achieved with the use of a
>> new 'terminology' scheme space, thus:
>>
>><  19829001 |Disorder of lung| 
>>  and <  301867009 |Edema of trunk| 
>>
>> becomes
>>
>> terminology:/snomed-ct/ecf/value="<  19829001 |Disorder of lung|
>>   and <  301867009 |Edema of trunk|"
>> 
>>
>> (I won't try to work out the nicest syntax, let's just say we agree that
>> we could find one)
>>
>> This would allow URIs of the form
>>
>> terminology:/loinc/xyz/something-loinc-ish
>>
>> and so on.
>>
>> The sole purpose of a terminology scheme space might just be to establish
>> a universal id space whose ids are readable, structured strings, that can
>> be machine-converted to real URIs for SNOMED, but also LOINC, ICDx, HL7,
>> and all the other terminologies.
>>
>> - thomas
>>
>> On 03/05/2017 12:09, Daniel Karlsson wrote:
>>
>> See this page:
>> https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
>> Please consider the language used when posting.
>> /Daniel
>>
>> On May 3, 2017 13:03, Bert Verhees 
>>  wrote:
>>
>> On 03-05-17 12:53, Thomas Beale wrote:
>>
>> On 03/05/2017 11:40, Bert Verhees wrote:
>>
>> On 03-05-17 12:36, Thomas Beale wrote:
>>
>> The only missing part, now that I look at the SNOMED Compositional
>> Grammar  and Expression
>> Constraint Language 
>> specs, is how to create a URI (which is the type of a term binding in
>> ADL2
>> )
>> from a post-coordinated expression or constraint expression. This should be
>> trivial, but I don't see where SNOMED has specified it.
>>
>>
>> True, I was looking for that also, a few days ago. I don't have time to
>> read much now, but there is a document on the SNOMED site on URI's, maybe
>> it is in there?
>> I can take a look later or look in my documentation, I have course
>> materials. I come back to this tomorrow if not someone else already has.
>>
>>
>> The URI spec is here
>> ,
>> but it doesn't address URIs for expressions 

Re: SNOMEDCT - correct representation

2017-05-07 Thread Michael.Lawley

Hi Koray,


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


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


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


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


michael


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

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Koray Atalag <k.ata...@auckland.ac.nz>
Sent: Saturday, 6 May 2017 11:25 PM
To: For openEHR technical discussions
Subject: RE: SNOMEDCT - correct representation

Hi Michael,

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

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

Cheers,

-koray

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

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

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

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

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

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

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

Regards

Michael
Sent from my iPhone

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

2017-05-03 13:02 GMT+02:00 Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>>:
On 03-05-17 12:53, Thomas Beale wrote:
On 03/05/2017 11:40, Bert Verhees wrote:

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

The only missing part, now that I look at the SNOMED Compositional 
Grammar<https://confluence.ihtsdotools.org/display/DOCSCG> and Expression 
Constraint Language<https://confluence.ihtsdotools.org/display/DOCECL> specs, 
is how to create a URI (which is the type of a term binding in 
ADL2<http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>)
 from a post-coordinated expression or constraint expression. This should be 
trivial, but I don't see where SNOMED has specified it.

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

The URI spec is 
here<https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+St

RE: SNOMEDCT - correct representation

2017-05-06 Thread Koray Atalag
Hi Michael,

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

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

Cheers,

-koray

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

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

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

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

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

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

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

Regards

Michael
Sent from my iPhone

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

2017-05-03 13:02 GMT+02:00 Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>>:
On 03-05-17 12:53, Thomas Beale wrote:
On 03/05/2017 11:40, Bert Verhees wrote:

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

The only missing part, now that I look at the SNOMED Compositional 
Grammar<https://confluence.ihtsdotools.org/display/DOCSCG> and Expression 
Constraint Language<https://confluence.ihtsdotools.org/display/DOCECL> specs, 
is how to create a URI (which is the type of a term binding in 
ADL2<http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>)
 from a post-coordinated expression or constraint expression. This should be 
trivial, but I don't see where SNOMED has specified it.

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

The URI spec is 
here<https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard>, 
but it doesn't address URIs for expressions either.

(All the SNOMED language specs appear to be 
here<https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages>
 these days - nice and convenient, and also nicely published. We probably 
should go back to linking to them somewhere on the openEHR site).

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

Stupid.

Bert

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



--

[VeraTech for Health SL]<https://htmlsig.com/t/01C268PZ>

[Twitter] <https://htmlsig.com/t/01C47QQH>  [LinkedIn]  
<https://htmlsig.com/t/01C4DPJG>  [Maps]  
<https://htmlsig.com/t/01BZTWS7>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com<mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 961071863<tel:+34%20961%2007%2018%2063> / +34 
627015023<tel:+34%20627%2001%2050%2023>
www.veratech.es<http://www.veratech.es/>

Su dirección de correo electrónico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificación, cancelació

Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
well, nothing stops you for not encoding the query in definition time, most
services are ok with that
e.g.

http://diebosto2.pc.upv.es:/SnomedQuery/ws/JSONQuery?query=
<404684003:363698007=39057004

2017-05-03 16:31 GMT+02:00 Thomas Beale :

>
> On 03/05/2017 13:31, Diego Boscá wrote:
>
>> Or just use the "Long syntax" as described in point 5.2 from Expression
>> Constraint Language, which keeps things readable enough
>> http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|
>>
>>
> at the very least, a %20 is needed for the spaces, and %7C for the pipes,
> i.e.
>
> http://snomed.info/ecl/descendantOrSelfOf%2073211009%20%
> 7CDiabetes%20mellitus%7C
>
> i.e. ... not readable...
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-03 Thread Thomas Beale



On 03/05/2017 14:04, michael.law...@csiro.au wrote:

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

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


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


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


right - but this is the argument that the definition of structured value 
sets (i.e. intensional ref-sets) should live in terminology services 
somewhere, and not in archetypes or other source model locations (a view 
I espoused for many years, and not very popular...). The 
counter-argument is that while this is fine for subsets like 'blood 
phenotype' or whatever, no-one wants to pollute terminology services 
with thousands of ECL expressions that are purely local to an 
information artefact (i.e. some very specific permutation, also very 
common).


I am starting to think that we need a new artefact which is a kind of 
local terminology expression 'library' - probably just a file - that is 
associated with any collection of archetypes of similar information 
artefacts.


The specific problem we are trying to solve here is 'terminology 
binding', not just terminology expressions, which I think are pretty 
well defined. Where bindings live is not a simple question, because the 
answer depends on what the binding is to.


- thomas

Aside: the ontoserver tool is very nice, people should have a look if 
they have not already.





In case anyone wants to play with ECL expressions and their evaluation 
you can go here for an interactive page:

https://ontoserver.csiro.au/shrimp/ecl.html

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

Regards

Michael



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


Re: SNOMEDCT - correct representation

2017-05-03 Thread Thomas Beale


On 03/05/2017 13:31, Diego Boscá wrote:
Or just use the "Long syntax" as described in point 5.2 from 
Expression Constraint Language, which keeps things readable enough

http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|



at the very least, a %20 is needed for the spaces, and %7C for the 
pipes, i.e.


http://snomed.info/ecl/descendantOrSelfOf%2073211009%20%7CDiabetes%20mellitus%7C

i.e. ... not readable...

- thomas

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


Re: SNOMEDCT - correct representation

2017-05-03 Thread Michael.Lawley
I think this thread has gone a little off the rails.

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

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

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

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

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

Regards

Michael

Sent from my iPhone

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

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

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

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

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

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

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

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

Stupid.

Bert

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



--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  


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

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

VeraTech for Health SL
+34 961071863 / +34 
627015023
www.veratech.es

Su direcci?n de correo electr?nico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Org?nica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificaci?n, cancelaci?n y, en 
su caso oposici?n, enviando una solicitud por escrito a 
verat...@veratech.es.

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

Re: SNOMEDCT - correct representation

2017-05-03 Thread Bert Verhees

On 03-05-17 14:20, Thomas Beale wrote:

that is seriously unreadable.


I don't think that is a problem, all programming languages have 
libraries to en/decode that kind of strings, so archetype-tooling can do 
that without much programming effort, and also this can be done when 
copy and pasting to a clear-text editor.


Who is reading clear text ADL anyway? The people I know who are working 
on archetypes never care to see ADL text.


I would not advise going away from the URI-allowed syntax, because, that 
can cause incompatibilities on unexpected situations, maybe in the future


Bert



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


Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
Or just use the "Long syntax" as described in point 5.2 from Expression
Constraint Language, which keeps things readable enough
http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|

2017-05-03 14:20 GMT+02:00 Thomas Beale :

> Daniel,
>
> my fault - didn't read the front page properly - the things we need are
> mooted for next release. But now I agree with Diego...
>
> The expression constraint "< 404684003 |Clinical finding|: < 47429007 |
> Associated with| = < 79654002 |Edema|"
>
>- http
>
>://snomed.info/ecl/%
>
>3C404684003%3A%3C%3C47429007%3D%3C%3C79654002
>
>
>
> that is seriously unreadable. In a different universe, we would have hoped
> for something like:
>
> http://snomed.info/ecl/<404684003:<47429007=<79654002
>
> but of course that is illegal in URI syntax.
>
> In terms of what we put in archetype bindings, I start to wonder. Could it
> make sense to allow:
>
>- proper URIs for single terms, value set refs, module refs etc (all
>the URIs that only include a single SCT code)
>- post-coordinated expressions in their syntax form
>- constraint expressions in their syntax form
>
> where the latter two would be understood as standing for their equivalent
> URIs? That's an awful hack though.
>
> A more consistent argument would be to revert to not using URIs in
> bindings, and use just codes and expressions.
>
> The problem with doing that is that the ID concept URIs include useful
> things like /id, /module, /field, etc.
>
> If we just go with the kind of URIs like the above, archetype bindings
> will cease to be self-documenting. I am starting to think we need an
> expression syntax that covers all of:
>
>- single term references, including to SNOMED codes, modules,
>versions, 
>- SNOMED post-coordinated expressions
>- SNOMED constraint expressions
>- and... the equivalent for non-SNOMED codes, e.g. LOINC, ICDx, ICF,
>etc etc
>
> We still don't have a universal terminology referencing mechanism, but
> it's what I think we need. It could in theory be achieved with the use of a
> new 'terminology' scheme space, thus:
>
><  19829001 |Disorder of lung|   and <
>  301867009 |Edema of trunk| 
>
> becomes
>
> terminology:/snomed-ct/ecf/value="<  19829001 |Disorder of lung|
>   and <  301867009 |Edema of trunk|"
> 
>
> (I won't try to work out the nicest syntax, let's just say we agree that
> we could find one)
>
> This would allow URIs of the form
>
> terminology:/loinc/xyz/something-loinc-ish
>
> and so on.
>
> The sole purpose of a terminology scheme space might just be to establish
> a universal id space whose ids are readable, structured strings, that can
> be machine-converted to real URIs for SNOMED, but also LOINC, ICDx, HL7,
> and all the other terminologies.
>
> - thomas
>
> On 03/05/2017 12:09, Daniel Karlsson wrote:
>
> See this page:
> https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
> Please consider the language used when posting.
> /Daniel
>
> On May 3, 2017 13:03, Bert Verhees 
>  wrote:
>
> On 03-05-17 12:53, Thomas Beale wrote:
>
> On 03/05/2017 11:40, Bert Verhees wrote:
>
> On 03-05-17 12:36, Thomas Beale wrote:
>
> The only missing part, now that I look at the SNOMED Compositional Grammar
>  and Expression
> Constraint Language 
> specs, is how to create a URI (which is the type of a term binding in ADL2
> )
> from a post-coordinated expression or constraint expression. This should be
> trivial, but I don't see where SNOMED has specified it.
>
>
> True, I was looking for that also, a few days ago. I don't have time to
> read much now, but there is a document on the SNOMED site on URI's, maybe
> it is in there?
> I can take a look later or look in my documentation, I have course
> materials. I come back to this tomorrow if not someone else already has.
>
>
> The URI spec is here
> ,
> but it doesn't address URIs for expressions either.
>
> (All the SNOMED language specs appear to be here
> 
> these days - nice and convenient, and also nicely published. We probably
> should go back to linking to them somewhere on the openEHR site).
>
>
> I checked my course materials from last year, lucky I found it quickly,
> there is not any mentioning of URI's for 

Re: SNOMEDCT - correct representation

2017-05-03 Thread Thomas Beale

Daniel,

my fault - didn't read the front page properly - the things we need are 
mooted for next release. But now I agree with Diego...


The expression constraint "< 404684003|Clinical finding|: < 
47429007|Associated with| = < 79654002 |Edema|"


 * http
   
://snomed.info/ecl/%
   
3C404684003%3A%3C%3C47429007%3D%3C%3C79654002
   

that is seriously unreadable. In a different universe, we would have 
hoped for something like:


http://snomed.info/ecl/<404684003:<47429007=<79654002

but of course that is illegal in URI syntax.

In terms of what we put in archetype bindings, I start to wonder. Could 
it make sense to allow:


 * proper URIs for single terms, value set refs, module refs etc (all
   the URIs that only include a single SCT code)
 * post-coordinated expressions in their syntax form
 * constraint expressions in their syntax form

where the latter two would be understood as standing for their 
equivalent URIs? That's an awful hack though.


A more consistent argument would be to revert to not using URIs in 
bindings, and use just codes and expressions.


The problem with doing that is that the ID concept URIs include useful 
things like /id, /module, /field, etc.


If we just go with the kind of URIs like the above, archetype bindings 
will cease to be self-documenting. I am starting to think we need an 
expression syntax that covers all of:


 * single term references, including to SNOMED codes, modules,
   versions, 
 * SNOMED post-coordinated expressions
 * SNOMED constraint expressions
 * and... the equivalent for non-SNOMED codes, e.g. LOINC, ICDx, ICF,
   etc etc

We still don't have a universal terminology referencing mechanism, but 
it's what I think we need. It could in theory be achieved with the use 
of a new 'terminology' scheme space, thus:


   < 19829001|Disorder of lung|  and < 
301867009|Edema of trunk| 


becomes

terminology:/snomed-ct/ecf/value="< 19829001|Disorder of lung| 
 and < 301867009|Edema of trunk|" 



(I won't try to work out the nicest syntax, let's just say we agree that 
we could find one)


This would allow URIs of the form

terminology:/loinc/xyz/something-loinc-ish

and so on.

The sole purpose of a terminology scheme space might just be to 
establish a universal id space whose ids are readable, structured 
strings, that can be machine-converted to real URIs for SNOMED, but also 
LOINC, ICDx, HL7, and all the other terminologies.


- thomas


On 03/05/2017 12:09, Daniel Karlsson wrote:

See this page:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
Please consider the language used when posting.
/Daniel

On May 3, 2017 13:03, Bert Verhees  wrote:

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

On 03/05/2017 11:40, Bert Verhees wrote:

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

The only missing part, now that I look at the SNOMED
Compositional Grammar

and Expression Constraint Language

specs, is how to create a URI (which is the type of a
term binding in ADL2

)
from a post-coordinated expression or constraint
expression. This should be trivial, but I don't see
where SNOMED has specified it.


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


The URI spec is here

,
but it doesn't address URIs for expressions either.

(All the SNOMED language specs appear to be here


these days - nice and convenient, and also nicely published.
We probably should go back to linking to them somewhere on the
openEHR site).


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

Stupid.

Bert




___
openEHR-technical mailing list

Re: SNOMEDCT - correct representation

2017-05-03 Thread Bert Verhees




2017-05-03 13:09 GMT+02:00 Daniel Karlsson >:


See this page:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard


Please consider the language used when posting.



Sorry for that word.
What you point at is the solution for URI's for 
post-coordinated-expressions.


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

Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
For the expression constraint language seems strange to encode the
characters when there is already an official expression constraint language
alternative that avoids these kinds of characters

2017-05-03 13:09 GMT+02:00 Daniel Karlsson :

> See this page:
> https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
> Please consider the language used when posting.
> /Daniel
>
> On May 3, 2017 13:03, Bert Verhees  wrote:
>
> On 03-05-17 12:53, Thomas Beale wrote:
>
> On 03/05/2017 11:40, Bert Verhees wrote:
>
> On 03-05-17 12:36, Thomas Beale wrote:
>
> The only missing part, now that I look at the SNOMED Compositional Grammar
>  and Expression
> Constraint Language 
> specs, is how to create a URI (which is the type of a term binding in ADL2
> )
> from a post-coordinated expression or constraint expression. This should be
> trivial, but I don't see where SNOMED has specified it.
>
>
> True, I was looking for that also, a few days ago. I don't have time to
> read much now, but there is a document on the SNOMED site on URI's, maybe
> it is in there?
> I can take a look later or look in my documentation, I have course
> materials. I come back to this tomorrow if not someone else already has.
>
>
> The URI spec is here
> ,
> but it doesn't address URIs for expressions either.
>
> (All the SNOMED language specs appear to be here
> 
> these days - nice and convenient, and also nicely published. We probably
> should go back to linking to them somewhere on the openEHR site).
>
>
> I checked my course materials from last year, lucky I found it quickly,
> there is not any mentioning of URI's for expressions, so I guess it does
> not yet exist.
>
> Stupid.
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-03 Thread Daniel Karlsson
See this page:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
Please consider the language used when posting.
/Daniel

On May 3, 2017 13:03, Bert Verhees  wrote:
On 03-05-17 12:53, Thomas Beale wrote:
On 03/05/2017 11:40, Bert Verhees wrote:
On 03-05-17 12:36, Thomas Beale wrote:

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

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

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

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

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

Stupid.

Bert

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

Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
Seems like the only way right now is creating refsets and referencing them
with standard URIs...

2017-05-03 13:02 GMT+02:00 Bert Verhees :

> On 03-05-17 12:53, Thomas Beale wrote:
>
> On 03/05/2017 11:40, Bert Verhees wrote:
>
> On 03-05-17 12:36, Thomas Beale wrote:
>
> The only missing part, now that I look at the SNOMED Compositional Grammar
>  and Expression
> Constraint Language 
> specs, is how to create a URI (which is the type of a term binding in ADL2
> )
> from a post-coordinated expression or constraint expression. This should be
> trivial, but I don't see where SNOMED has specified it.
>
>
> True, I was looking for that also, a few days ago. I don't have time to
> read much now, but there is a document on the SNOMED site on URI's, maybe
> it is in there?
> I can take a look later or look in my documentation, I have course
> materials. I come back to this tomorrow if not someone else already has.
>
>
> The URI spec is here
> ,
> but it doesn't address URIs for expressions either.
>
> (All the SNOMED language specs appear to be here
> 
> these days - nice and convenient, and also nicely published. We probably
> should go back to linking to them somewhere on the openEHR site).
>
>
> I checked my course materials from last year, lucky I found it quickly,
> there is not any mentioning of URI's for expressions, so I guess it does
> not yet exist.
>
> Stupid.
>
> Bert
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-03 Thread Bert Verhees

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

On 03/05/2017 11:40, Bert Verhees wrote:

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


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




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


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


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


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


Stupid.

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

Re: SNOMEDCT - correct representation

2017-05-03 Thread Thomas Beale



On 03/05/2017 11:40, Bert Verhees wrote:

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


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




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


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


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


- thomas


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: SNOMEDCT - correct representation

2017-05-03 Thread Bert Verhees

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



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




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


Bert


- thomas


On 03/05/2017 11:23, Thomas Beale wrote:


Hi Koray,


On 03/05/2017 10:41, Koray Atalag wrote:


Hi again,

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


I’ve been doing a lot of terminology bindings using various 
ontologies and terminology lately and I think we need urgently a 
consistent way to make these bindings and get the tools support it. 
For example when term bindings (for the purpose of defining 
real-world meaning of a node) are done at archetype level you end up 
with local at codes that refer to each binding and then it is 
possible to link one or more terms from same or different 
terminology systems. For the purpose of providing a valueset to a 
DV_CODED_TEXT at archetype level we don’t have a very clear way – we 
keep on saying we’ll put a terminology query but it is not really 
usable or useful.




I'm unclear on the problem exactly. We can bind to a URI that points 
to a SNOMED CT subset.
If we upgrade the binding syntax in ADL 1.4 as per this SPECPR-215 
, then we can 
include SNOMED constraint expressions.

Let's assume we do this, and the tools follow suit.
What else is needed? (I agree that we need to address all this ASAP 
by the way. It is already addressed in ADL2, but the user-base is 
moving much more slowly than I expected towards it).


Tooling support is also not satisfactory. But when you do that at 
template level (e.g. define a valueset for a DV_TEXT by further 
constraining it to DV_CODED_TEXT or an existing DV_CODED_TEXT) it is 
just a list of terms, code and terminology system with 
version/release. It is not clear how we can refer to an external 
list defined by a terminology query or refset – at least I couldn’t 
figure out. There’s quite an inconsistency between archetype vs 
template defined valuesets within .opt – whereas they should be 
defined in the same way and share same semantics.


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




I'm not sure how using the FHIR terminology service solves the above 
problems. As far as I can see, the question of FHIR or CTS2 or xyz 
terminology service is orthogonal to the question of representing 
bindings to post-coordinated expressions.


- 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: SNOMEDCT - correct representation

2017-05-03 Thread Thomas Beale


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


- thomas


On 03/05/2017 11:23, Thomas Beale wrote:


Hi Koray,


On 03/05/2017 10:41, Koray Atalag wrote:


Hi again,

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


I’ve been doing a lot of terminology bindings using various 
ontologies and terminology lately and I think we need urgently a 
consistent way to make these bindings and get the tools support it. 
For example when term bindings (for the purpose of defining 
real-world meaning of a node) are done at archetype level you end up 
with local at codes that refer to each binding and then it is 
possible to link one or more terms from same or different terminology 
systems. For the purpose of providing a valueset to a DV_CODED_TEXT 
at archetype level we don’t have a very clear way – we keep on saying 
we’ll put a terminology query but it is not really usable or useful.




I'm unclear on the problem exactly. We can bind to a URI that points 
to a SNOMED CT subset.
If we upgrade the binding syntax in ADL 1.4 as per this SPECPR-215 
, then we can include 
SNOMED constraint expressions.

Let's assume we do this, and the tools follow suit.
What else is needed? (I agree that we need to address all this ASAP by 
the way. It is already addressed in ADL2, but the user-base is moving 
much more slowly than I expected towards it).


Tooling support is also not satisfactory. But when you do that at 
template level (e.g. define a valueset for a DV_TEXT by further 
constraining it to DV_CODED_TEXT or an existing DV_CODED_TEXT) it is 
just a list of terms, code and terminology system with 
version/release. It is not clear how we can refer to an external list 
defined by a terminology query or refset – at least I couldn’t figure 
out. There’s quite an inconsistency between archetype vs template 
defined valuesets within .opt – whereas they should be defined in the 
same way and share same semantics.


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




I'm not sure how using the FHIR terminology service solves the above 
problems. As far as I can see, the question of FHIR or CTS2 or xyz 
terminology service is orthogonal to the question of representing 
bindings to post-coordinated expressions.


- thomas


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

Re: SNOMEDCT - correct representation

2017-05-03 Thread Thomas Beale

Hi Koray,


On 03/05/2017 10:41, Koray Atalag wrote:


Hi again,

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


I’ve been doing a lot of terminology bindings using various ontologies 
and terminology lately and I think we need urgently a consistent way 
to make these bindings and get the tools support it. For example when 
term bindings (for the purpose of defining real-world meaning of a 
node) are done at archetype level you end up with local at codes that 
refer to each binding and then it is possible to link one or more 
terms from same or different terminology systems. For the purpose of 
providing a valueset to a DV_CODED_TEXT at archetype level we don’t 
have a very clear way – we keep on saying we’ll put a terminology 
query but it is not really usable or useful.




I'm unclear on the problem exactly. We can bind to a URI that points to 
a SNOMED CT subset.
If we upgrade the binding syntax in ADL 1.4 as per this SPECPR-215 
, then we can include 
SNOMED constraint expressions.

Let's assume we do this, and the tools follow suit.
What else is needed? (I agree that we need to address all this ASAP by 
the way. It is already addressed in ADL2, but the user-base is moving 
much more slowly than I expected towards it).


Tooling support is also not satisfactory. But when you do that at 
template level (e.g. define a valueset for a DV_TEXT by further 
constraining it to DV_CODED_TEXT or an existing DV_CODED_TEXT) it is 
just a list of terms, code and terminology system with 
version/release. It is not clear how we can refer to an external list 
defined by a terminology query or refset – at least I couldn’t figure 
out. There’s quite an inconsistency between archetype vs template 
defined valuesets within .opt – whereas they should be defined in the 
same way and share same semantics.


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




I'm not sure how using the FHIR terminology service solves the above 
problems. As far as I can see, the question of FHIR or CTS2 or xyz 
terminology service is orthogonal to the question of representing 
bindings to post-coordinated expressions.


- thomas

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

Re: SNOMEDCT - correct representation

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

Big +1

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

Regards

Michael

Sent from my iPhone

On 3 May 2017, at 7:43 pm, Koray Atalag 
<k.ata...@auckland.ac.nz<mailto:k.ata...@auckland.ac.nz>> wrote:

Hi again,

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

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

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

Cheers,

-koray

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

Yup – that’s the right URI format.

Cheers,

-koray

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




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

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

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

term_bindings = <
["SNOMED-CT"] = <
["id1"] = 
<http://snomed.info/id/163020007><http://snomed.info/id/163020007>
["id5"] = 
<http://snomed.info/id/163030003><http://snomed.info/id/163030003>
["id6"] = 
<http://snomed.info/id/163031004><http://snomed.info/id/163031004>
["id14"] = 
<http://snomed.info/id/246153002><http://snomed.info/id/246153002>
>
["openehr"] = <
["at1055"] = <http://openehr.org/id/125><http://openehr.org/id/125>
["at1056"] = <http://openehr.org/id/497><http://openehr.org/id/497>
["at1057"] = <http://openehr.org/id/146><http://openehr.org/id/146>
>
>
- thomas
On 25/

RE: SNOMEDCT - correct representation

2017-05-03 Thread Koray Atalag
Hi again,

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

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

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

Cheers,

-koray

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

Yup - that's the right URI format.

Cheers,

-koray

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




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

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

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

term_bindings = <
["SNOMED-CT"] = <
["id1"] = 
<http://snomed.info/id/163020007><http://snomed.info/id/163020007>
["id5"] = 
<http://snomed.info/id/163030003><http://snomed.info/id/163030003>
["id6"] = 
<http://snomed.info/id/163031004><http://snomed.info/id/163031004>
["id14"] = 
<http://snomed.info/id/246153002><http://snomed.info/id/246153002>
>
["openehr"] = <
["at1055"] = <http://openehr.org/id/125><http://openehr.org/id/125>
["at1056"] = <http://openehr.org/id/497><http://openehr.org/id/497>
["at1057"] = <http://openehr.org/id/146><http://openehr.org/id/146>
>
>
- thomas
On 25/04/2017 07:03, Ian McNicoll wrote:
SNOMED-CT is the official designator, based on the archetype editor terminology 
list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> wrote:
Congratulations about the new adoption!

The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our specs we 
are using SNOMED-CT as the name (it should be corrected to the name preferred 
by the IHTSDO). On 

Re: SNOMEDCT - correct representation

2017-04-26 Thread Daniel Karlsson
Hi All,

please use this link to refer to the SNOMED CT URI Standard: 
https://confluence.ihtsdotools.org/display/DOCURI

This page contains more info about SNOMED CT languages:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Languages+Project+Group

Thanks,
Daniel
On ons, 2017-04-26 at 14:00 +0100, Thomas Beale wrote:


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

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

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

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

["id5"] = 

["id6"] = 

["id14"] = 

>
["openehr"] = <
["at1055"] = 
["at1056"] = 
["at1057"] = 
>
>

- thomas

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

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

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

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

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



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

Currently we use ‘SNOMEDCT’ like below. Is this correct?

 
Høyre øye

  
SNOMEDCT
  
  18944008

  

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


___

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




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

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

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



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

--
[http://www.openehr.org/files/about/logoweb.png]
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: SNOMEDCT - correct representation

2017-04-26 Thread Thomas Beale


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


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


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


term_bindings = <
["SNOMED-CT"] = <
["id1"] = 
["id5"] = 
["id6"] = 
["id14"] = 
>
["openehr"] = <
["at1055"] = 
["at1056"] = 
["at1057"] = 
>
>

- thomas

On 25/04/2017 07:03, Ian McNicoll wrote:
SNOMED-CT is the official designator, based on the archetype editor 
terminology list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos > wrote:


Congratulations about the new adoption!

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

As for the term id, I've seen [snomed-ct::35917007 on the specs,
or SNOMED-CT on sample archetypes:

https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93=snomed=

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

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

>
>
>



On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss > wrote:

Norway just became a SNOMED country.

One simple question – what is the correct terminologyId to use
for SNOMED-CT.

Currently we use ‘SNOMEDCT’ like below. Is this correct?


Høyre øye


SNOMEDCT

18944008



Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10 


___

openEHR-implementers mailing list
openehr-implement...@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org




-- 
Ing. Pablo Pazos Gutiérrez

Cel:(00598) 99 043 145
Skype: cabolabs

http://www.cabolabs.com 
pablo.pa...@cabolabs.com 
Subscribe to our newsletter 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Ian McNicoll


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


--

*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: SNOMEDCT - correct representation

2017-04-25 Thread Bjørn Næss
Thanks Ian
You are right. The correct ID is  “SNOMED-CT” . Then the example will be as 
follows:
 
Høyre øye  

  
SNOMED-CT
  
  18944008

  
I don’t think any subsets should be used on this context. What we need is a way 
to say that the code_string “18944008” is defined by the terminology defined by 
terminology_id/value = “SNOMED-CT”.  This must be done the same way by all 
openEHR systems to enable a true open platform based on openEHR archetypes.

Thanks for the feedback from all of you!



Vennlig hilsen
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: tirsdag 25. april 2017 08.03
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>; 
For openEHR implementation discussions <openehr-implement...@lists.openehr.org>
Subject: Re: SNOMEDCT - correct representation

SNOMED-CT is the official designator, based on the archetype editor terminology 
list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> wrote:
Congratulations about the new adoption!

The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our specs we 
are using SNOMED-CT as the name (it should be corrected to the name preferred 
by the IHTSDO). On an event they explicitly asked to avoid the SNOMED-CT with 
the hyphen when referencing the standard.
As for the term id, I've seen [snomed-ct::35917007 on the specs, or SNOMED-CT 
on sample archetypes: 
https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93=snomed=
Tested on the Ocean's archetype editor and they use:

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


On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss <b...@dips.no<mailto:b...@dips.no>> 
wrote:
Norway just became a SNOMED country.
One simple question – what is the correct terminologyId to use for SNOMED-CT.

Currently we use ‘SNOMEDCT’ like below. Is this correct?

 
Høyre øye

  
SNOMEDCT
  
  18944008

  

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>


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



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

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

___
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
--
Ian McNicoll
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-04-25 Thread Diego Boscá
But you probably need to define national extensions in constraint binding
in templates. Templates are archetypes in the end

2017-04-25 11:47 GMT+02:00 Bert Verhees :

> On 25-04-17 09:50, Diego Boscá wrote:
>
>> I think having this in a hardcoded terminology list is probably far from
>> ideal (e.g. how do you put "snomed ct+norway national extension"? do we
>> need an exhaustive listing of all possible extensions/versions?)
>>
>
> When you use SNOMED in termbindings, you don't need to mention extensions,
> the code will do. But we need post coordinated expressions for the things
> which are not coded but still required to express in a SNOMED. At this
> moment, the ADL standard is not ready for that. I already made a JIRA entry
>
> When you need SNOMED in a terminology constraint, and you want to
> constrain to a subset, then it should be sufficient to use the code to that
> subset. The terminology service should be able to find out if it is a code
> to an entry, an hierarchy or a subset, and response appropriate.
>
> I am not sure about national extensions
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-04-25 Thread Diego Boscá
This should be used as the name at least then

2017-04-25 10:08 GMT+02:00 :

>
> There is a spec that tells you how to identify different editions and
> versions of SNOMED CT - see http://snomed.org/uri
>
> In short, http://snomed.info/sct is the identifier for any version of
> SNOMED CT.  for the Norway extension you need to know which module it is in
> (this is what will be used in the Module Dependency Reference Set for the
> Norway release) and then, if it was 12345668 for example, the identifier is
> http://snomed.info/sct/12345678
>
> Michael
>
> Sent from my iPhone
>
> On 25 Apr 2017, at 5:52 pm, Diego Boscá  wrote:
>
> I think having this in a hardcoded terminology list is probably far from
> ideal (e.g. how do you put "snomed ct+norway national extension"? do we
> need an exhaustive listing of all possible extensions/versions?)
>
> 2017-04-25 8:03 GMT+02:00 Ian McNicoll :
>
>> SNOMED-CT is the official designator, based on the archetype editor
>> terminology list.
>> On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
>> wrote:
>>
>>> Congratulations about the new adoption!
>>>
>>> The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our
>>> specs we are using SNOMED-CT as the name (it should be corrected to the
>>> name preferred by the IHTSDO). On an event they explicitly asked to avoid
>>> the SNOMED-CT with the hyphen when referencing the standard.
>>>
>>> As for the term id, I've seen [snomed-ct::35917007 on the specs, or
>>> SNOMED-CT on sample archetypes: https://github.com/openEHR/spe
>>> cifications-ITS/search?utf8=%E2%9C%93=snomed=
>>>
>>> Tested on the Ocean's archetype editor and they use:
>>>
>>> constraint_bindings = <
>>> ["SNOMED-CT"] = <
>>> items = <
>>> ["ac0001"] = >> ?subset=cabolabs>
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>> On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss  wrote:
>>>
 Norway just became a SNOMED country.

 One simple question – what is the correct terminologyId to use for
 SNOMED-CT.



 Currently we use ‘SNOMEDCT’ like below. Is this correct?



  
 Høyre øye
 
   
 SNOMEDCT
   
   18944008
 
   



 Vennlig hilsen
 Bjørn Næss
 Produktansvarlig
 DIPS ASA

 Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>



 ___

>>> openEHR-implementers mailing list
 openehr-implement...@lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-implemente
 rs_lists.openehr.org

>>>
>>>
>>>
>>> --
>>> Ing. Pablo Pazos Gutiérrez
>>> Cel:(00598) 99 043 145
>>> Skype: cabolabs
>>> 
>>> http://www.cabolabs.com
>>> pablo.pa...@cabolabs.com
>>> Subscribe to our newsletter 
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>
>> --
>> Ian McNicoll
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   

Re: SNOMEDCT - correct representation

2017-04-25 Thread Michael.Lawley

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

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

Michael

Sent from my iPhone

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

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

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

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

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

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

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



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

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

 
H?yre ?ye

  
SNOMEDCT
  
  18944008

  

Vennlig hilsen
Bj?rn Naess
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


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



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

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

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

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



--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  


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

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

VeraTech for Health SL
+34 961071863 / +34 
627015023
www.veratech.es

Su direcci?n de correo electr?nico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Org?nica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificaci?n, cancelaci?n y, en 
su caso oposici?n, enviando una solicitud por escrito a 
verat...@veratech.es.

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

Re: SNOMEDCT - correct representation

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

2017-04-25 8:03 GMT+02:00 Ian McNicoll :

> SNOMED-CT is the official designator, based on the archetype editor
> terminology list.
> On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
> wrote:
>
>> Congratulations about the new adoption!
>>
>> The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our
>> specs we are using SNOMED-CT as the name (it should be corrected to the
>> name preferred by the IHTSDO). On an event they explicitly asked to avoid
>> the SNOMED-CT with the hyphen when referencing the standard.
>>
>> As for the term id, I've seen [snomed-ct::35917007 on the specs, or
>> SNOMED-CT on sample archetypes: https://github.com/openEHR/
>> specifications-ITS/search?utf8=%E2%9C%93=snomed=
>>
>> Tested on the Ocean's archetype editor and they use:
>>
>> constraint_bindings = <
>> ["SNOMED-CT"] = <
>> items = <
>> ["ac0001"] = > release?subset=cabolabs>
>> >
>> >
>> >
>>
>>
>>
>> On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss  wrote:
>>
>>> Norway just became a SNOMED country.
>>>
>>> One simple question – what is the correct terminologyId to use for
>>> SNOMED-CT.
>>>
>>>
>>>
>>> Currently we use ‘SNOMEDCT’ like below. Is this correct?
>>>
>>>
>>>
>>>  
>>> Høyre øye
>>> 
>>>   
>>> SNOMEDCT
>>>   
>>>   18944008
>>> 
>>>   
>>>
>>>
>>>
>>> Vennlig hilsen
>>> Bjørn Næss
>>> Produktansvarlig
>>> DIPS ASA
>>>
>>> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>>>
>>>
>>>
>>> ___
>>>
>> openEHR-implementers mailing list
>>> openehr-implement...@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-
>>> implementers_lists.openehr.org
>>>
>>
>>
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> Cel:(00598) 99 043 145
>> Skype: cabolabs
>> 
>> http://www.cabolabs.com
>> pablo.pa...@cabolabs.com
>> Subscribe to our newsletter 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>
> --
> Ian McNicoll
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


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

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-04-25 Thread Ian McNicoll
SNOMED-CT is the official designator, based on the archetype editor
terminology list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos  wrote:

> Congratulations about the new adoption!
>
> The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our
> specs we are using SNOMED-CT as the name (it should be corrected to the
> name preferred by the IHTSDO). On an event they explicitly asked to avoid
> the SNOMED-CT with the hyphen when referencing the standard.
>
> As for the term id, I've seen [snomed-ct::35917007 on the specs, or
> SNOMED-CT on sample archetypes:
> https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93=snomed=
>
> Tested on the Ocean's archetype editor and they use:
>
> constraint_bindings = <
> ["SNOMED-CT"] = <
> items = <
> ["ac0001"] =
> 
> >
> >
> >
>
>
>
> On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss  wrote:
>
>> Norway just became a SNOMED country.
>>
>> One simple question – what is the correct terminologyId to use for
>> SNOMED-CT.
>>
>>
>>
>> Currently we use ‘SNOMEDCT’ like below. Is this correct?
>>
>>
>>
>>  
>> Høyre øye
>> 
>>   
>> SNOMEDCT
>>   
>>   18944008
>> 
>>   
>>
>>
>>
>> Vennlig hilsen
>> Bjørn Næss
>> Produktansvarlig
>> DIPS ASA
>>
>> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>>
>>
>>
>> ___
>>
> openEHR-implementers mailing list
>> openehr-implement...@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> Cel:(00598) 99 043 145
> Skype: cabolabs
> 
> http://www.cabolabs.com
> pablo.pa...@cabolabs.com
> Subscribe to our newsletter 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: SNOMEDCT - correct representation

2017-04-24 Thread Pablo Pazos
Congratulations about the new adoption!

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

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

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

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



On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss  wrote:

> Norway just became a SNOMED country.
>
> One simple question – what is the correct terminologyId to use for
> SNOMED-CT.
>
>
>
> Currently we use ‘SNOMEDCT’ like below. Is this correct?
>
>
>
>  
> Høyre øye
> 
>   
> SNOMEDCT
>   
>   18944008
> 
>   
>
>
>
> Vennlig hilsen
> Bjørn Næss
> Produktansvarlig
> DIPS ASA
>
> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>
>
>
> ___
> openEHR-implementers mailing list
> openehr-implement...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>



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

http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org