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á <yamp...@gmail.com
<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
<http://snomed.info/ecl/descendantOrSelfOf> 73211009 |Diabetes
mellitus|
2017-05-03 14:20 GMT+02:00 Thomas Beale <thomas.be...@openehr.org
<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 <tel:4742%209007>|Associated with| = < 79654002 |Edema|"
* http
<http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002>://snomed.info/ecl/%
<http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002>3C404684003%3A%3C%3C47429007%3D%3C%3C79654002
<http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002>
that is seriously unreadable. In a different universe, we
would have hoped for something like:
http://snomed.info/ecl/<404684003:<47429007
<tel: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|
<http://snomed.info/id/19829001> and < 301867009|Edema of
trunk| <http://snomed.info/id/301867009>
becomes
terminology:/snomed-ct/ecf/value="< 19829001|Disorder of lung|
<http://snomed.info/id/19829001> and < 301867009|Edema of
trunk|" <http://snomed.info/id/301867009>
(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
<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 <bert.verh...@rosa.nl>
<mailto:bert.verh...@rosa.nl> 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
<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
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
-- Thomas Beale Principal, Ars Semantica
<http://www.arssemantica.com> Consultant, ABD Team,
Intermountain Healthcare
<https://intermountainhealthcare.org/> Management Board,
Specifications Program Lead, openEHR Foundation
<http://www.openehr.org> Chartered IT Professional Fellow,
BCS, British Computer Society
<http://www.bcs.org/category/6044> Health IT blog
<http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/>
_______________________________________________
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
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
--
VeraTech for Health SL <https://htmlsig.com/t/000001C268PZ>
Twitter <https://htmlsig.com/t/000001C47QQH>LinkedIn
<https://htmlsig.com/t/000001C4DPJG>Maps
<https://htmlsig.com/t/000001BZTWS7>
Diego Boscá Tomás / Senior
developerdiebo...@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ón y, en su caso
oposición, enviando una solicitud por escrito a
verat...@veratech.es <mailto:verat...@veratech.es>.
_______________________________________________ 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
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
--
Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs
<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
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
