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 
mailto:thomas.be...@openehr.org>> 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 
mailto:pablo.pa...@cabolabs.com>> 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 
mailto:thomas.be...@openehr.org>> 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? 
mailto:yamp...@gmail.com>> 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 
mailto:thomas.be...@openehr.org>>:


___
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&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=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 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 mailto:thomas.be...@openehr.org>>:


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
h

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 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 mailto:thomas.be...@openehr.org>>:


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


--
Thomas Beale
Princip

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
mailto:thomas.be...@openehr.org>>:





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



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

Re: 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 mailto:thomas.be...@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 
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 mailto:thomas.be...@openehr.org>>:

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

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 mailto:thomas.be...@openehr.org>>:

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 either.
>>
>> (All the SNOMED language specs appear to be here
>>