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
<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=<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
Please consider the language used when posting.
/Daniel
On May 3, 2017 13:03, Bert Verhees <[email protected]> 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
[email protected]
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
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
